Université catholique de Louvain (UCL) Institut dAdministration et de gestion (IAG) Unité de Systèmes dinformation (ISYS) Place des Doyens, 1 B-1348 Louvain-la-Neuve

1

Université catholique de Louvain (UCL)Institut d’Administration et de gestion (IAG)Unité de Systèmes d’information (ISYS)Place des Doyens, 1B-1348 Louvain-la-Neuve (Belgium)

Presenté par

Notes de coursNotes de coursGETI 2351 Séminaire d’informatiqueGETI 2351 Séminaire d’informatique

Jean Vanderdonckt

[email protected]

http://www.isys.ucl.ac.be/bchi/members/jva

2

PlanPlan

Présentation d’UML UML et le design du logiciel interactif

– Modèles et architectures typiques– Aspect statiques : modèles de classes et Design

Patterns– Aspects dynamiques : programmation par

événements et StateCharts

UML et le design de l’interaction– Use Cases– Processus de conception centré sur l’utilisateur

3

Historique d’UMLHistorique d’UML

Fin des années 80 : compétition des méthodes d’analyse et de conception OO– Booch : particulièrement adaptée au design et à

l’implémentation– OOSE (Jacobson) : expression des besoins– OMT-2 (Rumbaugh) : analyse et applications

orientées-données

1994 : Rumbaugh rejoint Booch chez Rational 1995 : Jacobson rejoint Rational 14 novembre 1997 : UML adopté par l’OMG

4

Qu’est-ce qu’UML ?Qu’est-ce qu’UML ?

« UML est un langage pour visualiser, spécifier, concevoir et documenter les artefacts d’un système à base logicielle »– Langage : lexique (graphique), syntaxe

(diagrammes), sémantique– Visualiser : représentation graphique– Spécification : précis, complet, non-ambigu– Construction : translation vers des langages de

programmation– Documentation : des besoins aux tests

5

Le LangageLe Langage

langage = syntaxe + sémantique– syntaxe = Règles par lesquelles les éléments du

lexique (e.g., mots) sont assemblées en expressions (e.g., phrases, clauses)

– sémantique = Règles par lesquelles on donne un sens aux expressions syntaxiques

UML Notation Guide – définit la syntaxe graphique d'UML

UML Semantics – définit la sémantique d'UML

6

Les briques de base de l’UMLLes briques de base de l’UML

Des choses…– Structurelles

• Classe, Interfaces, Collaborations, Use Cases…

– Comportementales• Messages et machines à états

Des relations– Dépendances, Associations, Généralisation,

RéalisationDes diagrammes

7

Concepts unificateursConcepts unificateurs

dichotomie classifieur-instance– e.g., un objet est l’instance d’une classe OU

une classe est le classifieur d’un objet

dichotomie spécification-réalisation– e.g., une interface est une spécification d'une

classe OUune classe est une réalisation d’une interface

8

Les diagrammes de l’UMLLes diagrammes de l’UML

Diagramme de Classe Diagramme d’Objets Diagramme Use Case Diagrammes d’interactions

– Diagramme de Séquence– Diagramme de Collaboration

StateCharts Diagramme d’Activité Diagrammes de Composants Diagramme de Déploiement

isomorphes

9

UML par lui-mêmeUML par lui-même

© Chuck Suscheck 2000, communication personnelle

CollaborationDiagram

DeploymentDiagram

UseCaseRealization

ComponentDiagram

SequenceDiagram

UseCaseDiagram

ActivityDiagram

ObjectDiagram

ClassDiagramRequirement

Component

StateChart

UseCase

Object

Class

1

0..*

Instance of

Supports

Mirrors

Snapshot

Behavior specified by


1..*

1..*

Modeled By


Shows behavior for


1

1

Realized by

Deployed upon

10

Fonction des diagrammesFonction des diagrammes

Diagrammes prescriptifs : décrivent le système tel qu’il doit être ou se comporter à tout moment– Classe, StateCharts, Use Cases, Activités,

Composants, Déploiement

Diagrammes descriptifs : illustrent un état ou un comportement possible et typique du système– Objet, Séquence, Collaboration

11

Modèles structurelsModèles structurels

Qu'est-ce qu'un modèle structurel ? Concepts Diagrammes structurels Quand produire des modèles structurels Trucs et astuces

12

Modèle structurelModèle structurel

Une vue d'un système qui met l'accent sur la structure des objets, avec leurs classificateurs, leurs relations, leurs attributs et leurs opérations

13

Elément Description Syntaxe

classe Description d’un ensemble d’objetsqui ont même attributs, opérations,méthodes, relations et sémantique.

interface Ensemble nommé d’opérations quicaractérisent le comportement d’unélément.

composant Partie physique et remplaçabled’un système qui encapsule uneimplémentation et fournit laréalisation d’un ensembled’interfaces.

Nœud Objet physique qui représente uneressource de calcul

«interface»

Éléments de modélisation structurelleÉléments de modélisation structurelle

14

Elément Description Syntaxe

contrainte¹ Condition ou restrictionsémantique. {constra in t}

¹ Mécanisme d’extension.

Éléments de modélisation Éléments de modélisation structurelle (suite)structurelle (suite)

15

Modélisation structurelle: Modélisation structurelle: RelationsRelations

16

Relation Description Syntaxe

réalisation Relation entre spécification etimplémentation.

Modélisation structurelle:Modélisation structurelle: Relations Relations (suite)(suite)

17

Diagrammes structurelsDiagrammes structurels

Montrent la structure statique d'un modèle– Les entités qui existent (e.g., classes, interfaces, composants, nœuds)– Leur structure interne– Leurs relations avec d'autres entités

Ne montrent pas– Des informations temporelles ou dynamiques

Catégories– Diagrammes structurels statiques

• diagramme de classe• diagramme d'instances

– Diagrammes d'implémentation• diagrammes de composants• diagrammes de déploiement

18

Définition d'une classeDéfinition d'une classe

Description d'un ensemble d'objets qui ont même structure et même sémantique– Nom– Attributs– Opérations– Responsabilités

• Exprimées en langage naturel

19

ClassesClasses

Fig. 3-17, UML Notation Guide

Window

display ()

size: Areavisibility: Boolean

hide ()

Window

Window

+default-size: Rectangle#maximum-size: Rectangle

+create ()

+display ()

+size: Area = (100,100)#visibility: Boolean = invisible

+hide ()

-xptr: XWindow*

-attachXWindow(xwin:Xwindow*)

{abstract,author=Joe,status=tested}

Personne

-Naissance : Date

-Nom : String

-Prenom : String

+age() : int

20

Opérations (méthodes)Opérations (méthodes)

Implémentation d'un service offert par l'objet, correspondant à une partie de ses responsabilités– Accesseurs : une opération qui renvoie une

information sur l'état de l'objet (fonction)– Modifieur : une opération qui modifie l' état

de l'objet (procédure)– Constructeur : une opération de la classe

qui permet d'initialiser une nouvelle instance

21

Utilisation des attributsUtilisation des attributs

Utilisation plus limitée que dans une modélisation de type entité-association– La définition d'un attribut contraint l'implémentation

future de la classe

– Préférer des accesseurs / modifieurs

A réserver à des types primitifs (entier, réel) ou des « structures de données » simples (string, date)

Ne pas utiliser de structures de type tableau, liste, …– Sauf exception...

22

Visibilité des attributs / MéthodesVisibilité des attributs / Méthodes

Public (+)– Visible et utilisable par toute autre classe (utilisation

très limitée)

Protected (#)– Visible et utilisable par toute spécialisation de la

classe

Private (-)– Visible uniquement par la classe elle-même

Sinon ?– On utilisera la sémantique de java (package)

23

InterfacesInterfaces


HashTable

Hashable

Comparable

String. . .

isEqual(String):Booleanhash():Integer

contents*

Comparable«interface»

isEqual(String):Booleanhash():Integer

. . .

«use»

24

AssociationsAssociations

Expriment une relation permanente entre instances de 2 ou plusieurs classes– Nom de l'association– Sens de lecture– Cardinalités et rôles– Visibilité des rôles– Navigabilité

25


Représentant

Cardinalités

Rôles

Client-interlocuteur

1

-Clientèle

1..*

Visite

26


Person

Manages

JobCompany

boss

worker

employeeemployer

0..1

Job

Account

Person

Corporation

{Xor}

salary

27


PlayerTeam

Year

Record

goals forgoals againstwinslosses

goalkeeper

season

team

ties

Associations ternairesAssociations ternaires

28

Relation de compositionRelation de composition

Relation « du tout à la partie »– Plus forte que l'association : implique une

relation de cycle de vie entre les instances (la création/destruction du tout entraîne celle de ses parties)

– Navigabilité souvent asymétrique : les parties ne connaissent pas le tout

29

CompositionComposition


Window

scrollbar [2]: Slidertitle: Headerbody: Panel

Window

scrollbar title body

Header Panel

2 1 1

Slider

111

30

Agrégation / CompositionAgrégation / Composition


Polygone

-estVisible : boolean

+deplace( origine : Point )

AttributGraphique

-CouleurTrait : int

-Epaisseur : int

-Remplissage : int

Point

-coordX : int

-coordY : int <<ordered>>

#points

3..*

Contient

-bundle 1

31

GénéralisationGénéralisation

Relation de spécialisation (est-un, is-a-kind-of) entre classes– La classe spécialisée (sous-classe) hérite

des méthodes et des attributs de la classe-générale (super-classe)

– Elle peut ajouter des attributs / méthodes– Elle peut redéfinir le comportement des

méthodes (mais pas les attributs !)Principe de substituabilité de Liskov

32

GénéralisationGénéralisation

Shape

SplineEllipsePolygon

Shape

SplineEllipsePolygon

Shared Target Style

Separate Target Style

. . .

. . .


33

Spécialisation multipleSpécialisation multiple


Vehicle

WindPoweredVehicle

MotorPoweredVehicle

LandVehicle

WaterVehicle

venue

venuepowerpower

SailboatTruck

{overlapping} {overlapping}

34

DépendanceDépendance

Une relation transitoire entre classes, qui n'est pas représentable par association ou composition– Un objet sert à créer des objets d'une autre

classe (factory object)– Un objet utilise un autre sans qu'il fasse

partie de ses attributs• Il peut recevoir un objet en tant que paramètre

ou valeur de retour d'une méthode

35

DépendancesDépendances

«friend»ClassA ClassB

ClassC

«instantiate»

«call»

ClassD

operationZ()«friend»

ClassD ClassE

«refine»ClassC combines

two logical classes


36

ObjetsObjets


triangle: Polygon

center = (0,0)vertices = ((0,0),(4,0),(4,3))borderColor = blackfillColor = white

triangle: Polygon

triangle

:Polygon

scheduler

37

Diagramme d’objetsDiagramme d’objets

P1: PolygoneestVisible : true

: PointcoordX : 100coordY : 200




G: AttibutGraphiquecouleurTrait : ROUGE

Epaisseur : 2Remplissage : VERT

38

Use CasesUse Cases

Les Use Cases permettent d’analyser les besoins, en décrivant comment le système doit être utilisé et dans quel but.– Forte similarités avec les techniques

d’analyse de la tâche.Support UML pour les Use Cases :

Nouvelle CommandeNouvelle Commande

39

Définition des Use CasesDéfinition des Use Cases

Jacobson, 1992– « … une façon spécifique d’utiliser le système en utilisant une

partie de sa fonctionnalité. [Un use case] constitue une séquence complète d’interaction qui a lieu entre un acteur et le système »

Rumbaugh et al, 1999: 488 – « …la spécification de séquences d’actions, pouvant inclure des

variantes ou des séquences d’erreur, qu’un système, sous-système ou classe peuvent exécuter en interagissant avec des acteurs extérieurs »

Fowler, 1997: 43– « … une interaction typique entre un utilisateur et un système

informatique … [qui] capture une fonction d’intérêt pour l’utilisateur … [et qui] permet d’atteindre un but discret pour l’utilisateur »

40

Éléments des Use CasesÉléments des Use Cases

Construct Description Syntax

use case A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.

actor A coherent set of roles that users of use cases play when interacting with these use cases.

system boundary

Represents the boundary between the physical system and the actors who interact with the physical system.

UseCaseNam e

ActorNam e

41


association The participation of an actor in a usecase. i.e., instance of an actor andinstances of a use case communicatewith each other.

extend A relationship from an extension usecase to a base use case, specifyinghow the behavior for the extensionuse case can be inserted into thebehavior defined for the base usecase.

generalization A taxonomic relationship between amore general use case and a morespecific use case.

Use case : RelationsUse case : Relations

<<extend>>

42


include An relationship from a base use caseto an inclusion use case, specifyinghow the behavior for the inclusion usecase is inserted into the behaviordefined for the base use case.

Use Case : relationsUse Case : relations

<<include>>

43

Diagrammes de Use CasesDiagrammes de Use Cases

Permettent d’organiser les Use Cases qui décrivent un système de manière structurée– Use Cases– Acteurs (plutôt rôle !)– Relations : dépendance, généralisation,

association

44

Exemple de diagrammeExemple de diagramme

Titulaire stagiaire

Operateur

System Boundary Box

Commande Express

Valider Utilisateur

Vérification mot de passe

Nouvelle Commande

identification rétinienne

Gérer les commandes

11

<<extends>>

<<includes>>

<<includes>>

Commande Express

Valider Utilisateur

Vérification mot de passe

Nouvelle Commande

identification rétinienne

Gérer les commandes

Titulaire stagiaire

Operateur

45

Narration « continue »Narration « continue »

A cash withdrawal transaction is started from within a session when the customer chooses cash withdrawal from the menu of possible transaction types. The customer chooses a type of account to withdraw from (e.g., checking) from a menu of possible accounts, and then chooses a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request. If not, it reports a failure to the session, which initiates the Failed Transaction Extension to report the problem. If there is sufficient cash, it sends the customer's card number, PIN, chosen account and amount to the bank, which either approves or disapproves the transaction. If the transaction is approved, the machine dispenses the correct amount of cash and issues a receipt. If the transaction is disapproved due to an incorrect PIN, the Incorrect PIN extension is executed. All other disapprovals are reported to the session, which initiates the Failed Transaction Extension. The bank is notified whether or not an approved transaction was completed in its entirety by the machine; if it is completed then the bank completes debiting the customer's account for the amount. [Bjork, 1998]

46

Séquence NumérotéeSéquence Numérotée

Withdraw Money– 1. The use case begins when the Client inserts an ATM card. The system reads

and validates the information on the card.– 2. System prompts for PIN. The Client enters PIN. The system validates the PIN.– 3. System asks which operation the client wishes to perform. Client selects

“Cash withdrawal.”– 4. System requests amounts [sic]. Client enters amount.– 5. System requests type. Client selects account type (checking, savings, credit).– 6. The system communicates with the ATM network to validate account ID,PIN,

and availability of the amount requested.– 7. The system asks the client whether he or she wants a receipt. This step is

performed only if there is paper left to print the receipt.– 8. System asks the client to withdraw the card. Client withdraws card. (This is a

security measure to ensure that Clients do not leave their cards in the machine.)– 9. System dispenses the requested amount of cash.– 10. System prints receipt.

47

Narration PartitionnéeNarration Partitionnée

Action utilisateur Réponse du système– insert card in ATM– read card– request PIN– enter PIN– verify PIN– display option menu– select option– display account menu– select account– prompt for amount– enter amount– display amount– confirm amount– return card– take card– dispense cash if available

48

Autres techniquesAutres techniques

Pseudo-Code– until customer_done repeat– if valid_user_code then do…end_do

else do…end_do end_ifDiagrammes d’interaction

49

Pré et Post-ConditionsPré et Post-Conditions

Place Order– Preconditions: A valid user has logged into the system.– Flow of events:

• Basic Path– 1. The use case starts when the customer selects Place Order– 2. The customer enters his or her name and address.– 3. If the customer enters only the zip code, the system will supply city

and state.– 4. The customer will enter product codes for the desired product.– 5. The system will supply a product description and price for each item.– 6. The system will keep a running total of items ordered as they are

entered.– 7. The customer will enter credit card information.– 8. The customer will select Submit.– 9. The system will verify the information, save the order as pending, and

forward payment information to the accounting system.– 10. When payment is confirmed, the order is marked Confirmed, an order

ID is returned to the customer, and the use case ends.• Alternative paths

– In step 9, if any information is incorrect, the system will prompt the customer to correct the information.

– Postcondition: The order has been saved and marked confirmed.

50

RéférencesRéférences

Rumbaugh, J., Jacobson, I., and Booch, E. (1999) The Unified Modeling Language Reference Manual. Reading, MA: Addison-Wesley.

Jacobson, I., Christerson, M., Jonsson, P., and Övergaard, G. (1992) Object-Oriented Software Engineering: A Use Case Driven Approach. Reading, MA: Addison-Wesley.

Fowler, M. (1997) UML Distilled: Applying the Standard Object Modeling Language. Reading, MA: Addison-Wesley.

Constantine, L. L., & Lockwood, L. A. D. (1999) Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. Boston: Addison-Wesley.

51

SourceSource

R. Bastide, Introduction à UML, Tutoriel n°11, Conférence IHM-HCI’2001

52

Ressources WebRessources Web

"CHI'98 Workshop "From Task to Dialogue: Task-Based User Interface Design"Web page, April 1998. http://www.uni-paderborn.de/fachbereich/AG/szwillus/chi98ws/

"Experimental Object Technologies - xjCharts." Web page, http://xjtek.com/products/xjcharts/

"For Use - Constantine & Lockwood, Ltd. home page for practitioners of usage-centered design." Web page, http://www.foruse.com/default.htm

"Incorporating Work, Process and Task Analysis Into Commercial and Industrial Object-Oriented Systems Development." Web page, 1998. http://www.primaryview.org/CHI98/BulletinFinal.html

"Use Cases Still Dangerous : Editorial : uidesign.net." Web page, http://www.uidesign.net/1999/imho/oct_imho.html.

Documents

Université catholique de Louvain (UCL) Institut dAdministration et de gestion (IAG) Unité de Systèmes dinformation (ISYS) Place des Doyens, 1 B-1348 Louvain-la-Neuve