Introduction UML présentation des diﬀérents diagrammes – Cours et formation gratuit

(1)

M´ethode de Conception Orient´ee Objet A. Lewandowski

Introduction Concepts de base Diagrammes UML Introduction à UML Diagramme de cas d’utilisation Diagramme de classes Diagramme de packages Diagramme d’objets Diagramme de communication Diagramme de séquence Diagramme d’activité Diagramme d’états Autres diagrammes Démarche de conception OO

46

Introduction ` a UML

Pr´ esentation des diff´ erents diagrammes

Diagramme

Diagramme Structurel

Diagramme Comportemental

Diagramme de classes

Diagramme de composants

Diagramme d'objets

Diagramme de packages

Diagramme de déploiement Diagramme de

structure composite

Diagramme d'activités

Diagramme de cas d'utilisation

Diagramme de séquence

Diagramme de timing Diagramme de communication

Diagramme global d'interactions

Diagramme d'états

Diagramme d'Interaction

57

Diagramme de cas d’utilisation (Use case)

592 UML Superstructure Specification, v2.1.1

case might require simultaneous (concurrent) action by two separate actors (e.g., in launching a nuclear missile) or it might require complementary and successive actions by the actors (e.g., one actor starting something and the other one stopping it).

Notation

A use case is shown as an ellipse, either containing the name of the use case or with the name of the use case placed below the ellipse. An optional stereotype keyword may be placed above the name and a list of properties included below the name. If a subject (or system boundary) is displayed, the use case ellipse is visually located inside the system boundary rectangle. Note that this does not necessarily mean that the subject classifier owns the contained use cases, but merely that the use case applies to that classifier. For example, the use cases shown in Figure 16.5 on page 592 apply to the “ATMsystem” classifier but are owned by various packages as shown in Figure 16.7.

Figure 16.5 - Example of the use cases and actors for an ATM system Customer

Administrator

«subsystem»

ATMsystem

Bank Withdraw

Transfer Funds

Deposit Money

Register ATM at Bank

Read Log 0..1 1

0..1 1

1 0..1

0..1 1

0..*

1

0..*

1

[Vue Fonctionnelle]

58

Diagramme de cas d’utilisation

Use Case

• Utilis´ e pour

• recueillir, analyser et organiser les besoins

• recenser les fonctionnalit´ es d’un syst` eme

• ce qu’il devra faire (et pas « comment »)

• description du comportement sous forme d’actions/r´ eactions

• vision plutˆ ot orient´ ee « utilisateur »

• d´ eterminer les limites du syst` eme

• Pour le construire

• identifier les rˆ oles qui interagissent avec (acteurs)

• d´ eterminer les grandes cat´ egories d’utilisation (Use cases)

• d´ ecrire textuellement les interactions (sc´ enarios)

59

Diagramme de cas d’utilisation

Les ´ el´ ements du diagramme

• Le diagramme est constitu´ e de

• syst` eme

• acteurs

• cas d’utilisation

• Exemple :

Client

Boutique en ligne

Acheter CD Visual Paradigm for UML Community Edition [not for commercial use]

acteur

cas d'utilisation système

Diagramme de cas d’utilisation

Les Acteurs

Qu’est-ce qu’un acteur ?

• abstraction d’un rˆ ole jou´ e par des entit´ es externes (utilisateur, dispositif mat´ eriel, etc.)

• il interagit directement avec le syst` eme

• il est actif (prend des d´ ecisions, initiatives, etc.)

Client

• Attention : acteur 6= utilisateur

• une personne peut jouer plusieurs rˆ oles (acteurs)

• plusieurs personnes peuvent jouer le mˆ eme rˆ ole

• un acteur n’est pas forc´ ement « humain »

Diagramme de cas d’utilisation

Les Acteurs

Repr´ esentation

Client

«actor»

Banque

stick man mot-clé

acteurs

non-humains

(2)

62

Diagramme de cas d’utilisation

Les Use Cases

Un cas d’utilisation :

• fonctionnalit´ e du syst` eme d´ eclench´ ee par un acteur externe

• mod´ elise un ensemble de s´ equences correspondant ` a un mˆ eme type d’interaction (cas g´ en´ eral)

Acheter CD

Pour identifier les cas d’utilisation :

• identifier les acteurs et ce qu’ils pourront faire avec le syst` eme (intentions m´ etier)

• d´ eterminer les s´ equences d’interactions ou sc´ enarios (cf. diagramme de s´ equence)

63

Diagramme de cas d’utilisation

Les sc´ enarios Sc´ enarios

• s´ equence particuli` ere de messages dans le CU

• « chemin » particulier

• peut ˆ etre vu comme une instance du CU

• tous les sc´ enarios d’un CU sont issus du mˆ eme acteur et ont le mˆ eme objectif

• sc´ enarios servent de base aux jeux d’essais

début

fin normale

erreur

64

Diagramme de cas d’utilisation

Documentation d’un CU

Fiche de description textuelle d’un CU

• pas normalis´ e par UML, mais fortement recommand´ e

• champs de description (nom, acteur principal, pr´ econditions, etc.)

• lisible et informel

• fran¸ cais, phrases descriptives

• pas trop long

65

Diagramme de cas d’utilisation

Documentation d’un CU

Structuration de la fiche

1 Sommaire d’identification

• obligatoire

• titre, r´ esum´ e, version, responsable, auteur, etc.

2 Description des sc´ enarios

• obligatoire

• sc´ enario nominal (d´ eroulement « classique » du CU), sc´ enarios alternatifs, sc´ enarios d’erreur, pr´ econditions, postconditions

3 Exigences non-fonctionnelles

• optionnel (si pertinent)

• fr´ equence, disponibilit´ e, confidentialit´ e, performances, concurrence, contraintes d’interface, etc.

Diagramme de cas d’utilisation

Relations

Relation acteur-cas d’utilisation :

• l’association : cas o` u l’acteur participe au cas d’utilisation (peut poss´ eder des multiplicit´ es)

Client

Acheter CD Visual Paradigm for UML Community Edition [not for commercial use]

Diagramme de cas d’utilisation

Relations Relation acteur-acteur

• relation de g´ en´ eralisation/sp´ ecialisation

Client

Boutique en ligne

Consulter Produits

Acheter CD Internaute

Consulter Produits Visual Paradigm for UML Community Edition [not for commercial use]

(3)

68

Diagramme de cas d’utilisation

Relations

Note :

• les communications externes entre acteurs ne sont pas mod´ elis´ es dans les diagrammes d’utilisation

• seules les interactions acteurs-syst` eme sont repr´ esent´ ees

69

Diagramme de cas d’utilisation

Relations

Relation cas d’utilisation-cas d’utilisation :

• g´ en´ eralisation/sp´ ecialisation : principe d’h´ eritage entre CU (´ eviter)

• l’inclusion : la r´ ealisation d’un CU n´ ecessite la r´ ealisation d’un autre CU

• l’extension : le comportement d’un CU peut ˆ etre compl´ et´ e par un autre CU (avec condition ´ eventuelle)

70

Diagramme de cas d’utilisation

Relations Exemple :

Client

Acheter CD Identification

Payer Payer par CB

< < I n c l u d e > >

< < E x t e n d > >

code promotion

Réduction

< < I n c l u d e > >

Payer par Paypal Visual Paradigm for UML Community Edition [not for commercial use]

71

Diagramme de cas d’utilisation

Quelques conseils

• bref et concis !

• La vue fonctionnelle sera compl´ et´ ee par d’autres diagrammes (s´ equence, activit´ e)

Diagramme de cas d’utilisation

La d´ emarche

• identifier les acteurs

• identifier les cas d’utilisation

• construire le diagramme de CU

• d´ ecrire textuellement les CU

• compl´ eter les descriptions par des diagrammes dynamiques (activit´ e, s´ equence)

• organiser et structurer les CU

Les diagrammes UML

Diagramme

Diagramme d'objets

structure composite

Diagramme d'états Diagramme

d'Interaction

(4)

75

Diagramme de classes

30 UML Superstructure Specification, v2.1.1

Figure 7.10 - Features diagram of the Kernel package

[Vue Statique]

76

Diagramme de classes

• Collection d’´ el´ ements de mod´ elisation statique

• Filtre les aspects dynamique et temporel

• Pour un mod` ele complexe, on peut avoir plusieurs diagrammes de classes compl´ ementaires

Par ex :

• les classes associ´ ees ` a la r´ ealisation d’un sc´ enario

• les classes qui composent un package

• la structure hi´ erarchique d’un ensemble de classes

• ...

• permet de mod´ eliser plusieurs niveaux (conceptuel, impl´ ementation, etc.)

77

Diagramme de classes

Classe

Repr´ esentation d’une classe

• rectangle ` a 3 compartiments

• nom (singulier, majuscule)

• attributs

• op´ erations

Opération 1 Opération 2 Attribut 1 Attribut 2

Une classe

• plus ou moins de d´ etails en fonction des besoins

Une classe Une classe

78

Diagramme de classes

Attributs et Op´ erations

Repr´ esentation des attributs :

visibilit´ e nom : type [multiplicit´ e] = valeur initiale {propri´ et´ es}

public + privé - protégé #

facultatif mais impératif pour l'implémentation

facultatif par défaut: 1

[0..1] élément pouvant être nul [4] tableau de 4 éléments [2..*] tableau dynamique d'au moins 2 éléments

facultatif ex. {frozen}

facultatif

Diagramme de classes

Attributs et Op´ erations

Repr´ esentation des op´ erations :

visibilit´ e nom (liste param` etres) : type retour {propri´ et´ es}

• Param` etre :

in|out|inout nom : type = valeur par d´ efaut

• Propri´ et´ es :

{frozen}, {abstract}, {sequential}, {query}, etc.

Diagramme de classes

Attributs et Op´ erations

Remarques

• soulign´ e : attribut ou op´ eration statique (de classe)

• op´ eration abstraite

• op´ erations = comportement d’une classe ; trouv´ ees grˆ ace aux diagrammes d’interaction

• m´ ethode = impl´ ementation d’une op´ eration (sp´ ecification de l’algorithme)

• pr´ e et post-conditions, descriptions : dans les

commentaires

(5)

81

Diagramme de classes

Attributs et Op´ erations Exemples

name: String shape: Rectangle + size: Integer [0..1]

/area: Integer {readOnly}

height: Integer = 5 width: Integer

Classe A

id {redefines name}

shape: Square height = 7 /width

Classe B démarrer()

accélérer() freiner() portes carburation nb_cv

/consommation {readOnly}

Voiture

82

Diagramme de classes

Relations entre classes

Les associations

• connexion s´ emantique bidirectionnelle entre classes

• abstraction des liens qui existent entre les objets (instances)

Exemple :

Personne conduit ▶ Voiture

83

Diagramme de classes

Relations entre classes

Repr´ esentation des associations

Classe 1 nom association ▶ Classe 2

rôle 1 rôle 2

x..y x..y

{mots-clés}

• Nom : forme verbale, avec un sens de lecture

• Rˆ oles : forme nominale, d´ ecrit une extr´ emit´ e de l’association

• Multiplicit´ e : 1, 0..1, 0.., 1.., n..m

• Mots cl´ es : set, ordered set, list

84

Diagramme de classes

Relations entre classes

Exemple

Entreprise ◀ travaille pour Personne

employeur employé

1..*

0..*

emploie ▶

0..1

* employés

patron dirige ▼

Association réflexive

Diagramme de classes

Relations entre classes Remarques sur les associations :

• Les associations sont ind´ ependantes les unes des autres

• Les associations sont h´ erit´ ees

• Tout objet doit ˆ etre accessible par un lien

• Directionnalit´ e des associations

• bidirectionnelles par d´ efaut

• la navigation peut ˆ etre restreinte ` a une seule direction

(association ` a navigabilit´ e restreinte) Exemple

Citoyen * vote pour ▶ 0..1 Candidat

Diagramme de classes

Relations entre classes Les multiplicit´ es :

• 1 : un et un seul

• 0..1 : z´ ero ou un (optionnel)

• m..n : de m ` a n

• * : plusieurs

• 0..* : de z´ ero ` a plusieurs

• 1..* : de un ` a plusieurs (au moins un) Exemple

Droite est l'intersection de ▶ 2..*

Point 0..*

(6)

87

Diagramme de classes

Relations entre classes Les contraintes

• Les associations alternatives

• contrainte {xor} : ou exclusif

• lorsqu’une seule des associations ne peut ˆ etre instanci´ ee

Exemple :

Société a pour titulaire ▶

Compte

Personne a pour titulaire

▶ {xor}

88

Diagramme de classes

Relations entre classes

Associations : l’ordre

• Les objets du cˆ ot´ e « plusieurs » d’une association n’ont pas d’ordre explicite

• par d´ efaut : contrainte {unordered}

• On peut les ordonner

• contrainte {ordered}

Exemple

Événement Historique 1..*

{ordered}

89

Diagramme de classes

Relations entre classes Les associations qualifi´ ees

• S´ election d’un sous-ensemble des objets qui participent

`

a l’association ` a l’aide d’une cl´ e (attribut)

• Cet attribut (la qualification) fait partie de l’association (pas de l’entit´ e)

ligne colonne

◀ est sur N° compte

Personne 0..1 Banque

*

Pièce 0..1

Échiquier

1..*

est dans ▲ nom_fichier

Fichier Répertoire

90

Diagramme de classes

Relations entre classes

L’Agr´ egation et la Composition

• Il s’agit d’une association non sym´ etrique (une classe joue un rˆ ole plus important que l’autre)

• Dans quels cas ?

• une classe B fait partie int´ egrante d’une classe A

• une action sur la classe A implique une action sur la classe B

• les valeurs d’attributs de la classe A se propagent dans les valeurs d’attributs de la clase B

• les objets de la classe B sont subordonn´ es ` a ceux de la classe A

Diagramme de classes

Relations entre classes L’Agr´ egation

• relation non nomm´ ee

• relation de type « compos´ e-composant »

Agrégat 1..* 0..*

Élément

La Composition

• cas particulier d’agr´ egation

• compos´ es physiquement contenus par l’agr´ egat

• implique la multiplicit´ e 0..1 cˆ ot´ e agr´ egat

Composite 1 0..*

Élément

• la destruction du compos´ e entraˆıne celle des composants

Diagramme de classes

Relations entre classes

Exemple

• Une voiture se compose de roues, portes, d’un moteur, d’un chassis, etc.

• Les roues, les portes et le moteur peuvent ˆ etre chang´ es durant la vie de la voiture et appartenir ` a une autre voiture

Véhicule

Roue Porte Moteur Chassis Habitacle

0..*

0..* 0..*

3,4 3..5 1 1 1

(7)

93

Diagramme de classes

Relations entre classes

Agr´ egation, Composition, ou simple Association ?

• Questions ` a se poser

• asym´ etrie et lien de subordination ? agr´ egation/composition

• ind´ ependance des objets ? association

• propagation d’op´ erations ou d’attributs du tout vers les parties ? agr´ egation/composition

• cr´ eation/destruction des parties avec le tout ? composition

• Dans le doute, toujours utiliser l’association

94

Diagramme de classes

Relations entre classes

« Changeabilit´ e » des associations

• Si les liens peuvent changer durant la vie des objets (ajout, destruction), aucune indication

• Si aucun lien ne peut changer apr` es sa cr´ eation et son initialisation, alros propri´ et´ e {frozen}

• Si seulement l’ajout de liens est autoris´ e, alors propri´ et´ e {addOnly}

Exemple

Événement Historique 1..*

{ordered, addOnly}

95

Diagramme de classes

Relations entre classes Attributs d’associations

• Concept regroupant attributs et associations unidirectionnelles

• Comment choisir

• attribut dans la classe : pour les types de donn´ ees de moindre importance

• attribut sur l’association : quand on veut insister sur les classes

Exemple

+ dateRéception: Date[0..1]

+ prépayée: Booléen {readOnly}

. . .

Commande

+ prépayée: Booléen {readOnly}

. . .

Commande Date

+ dateRéception

* 0..1

96

Diagramme de classes

Relations entre classes Classes d’association

• Dans quels cas ?

• pour ajouter des attributs/op´ erations ` a une association

• associations de type n..n entre deux classes + informations li´ ees

• note : la dur´ ee de vie des instances d´ epend de l’association

Exemple

Société Personne

employeur employé

1..* 0..*

Salaire

Emploi

Diagramme de classes

Relations entre classes

Association n-aire

• En g´ en´ eral, les associations sont binaires

• N-aires : au moins trois instances impliqu´ ees

A n’utiliser que lorsqu’aucune autre solution n’est ` possible !

Diagramme de classes

Relations entre classes Exemple

• un seul prof pour un ´ el` eve donn´ e et un cours donn´ e

• un ´ el` eve donn´ e et un prof donn´ e peuvent se rencontrer dans plusieurs cours

• un prof donne un cours donn´ e ` a au moins un ´ el` eve

Prof Élève 1..*

Cours

*

(8)

99

Diagramme de classes

Relations entre classes Les associations r´ ecursives

• Structure en arbre n-aire « infini »

Personne 0..*

enfant père

P1:Personne

P2:Personne P3:Personne

P4:Personne père père

père

enfant enfant

100

Diagramme de classes

Relations entre classes Les associations r´ ecursives

• Structure en arbre n-aire « fini »

Personne 0..1

* employé

patron dirige ▼

P1:Personne

P2:Personne P3:Personne

P4:Personne patron patron

patron

employé employé

employé

101

Diagramme de classes

Relations entre classes

Les associations r´ ecursives

• Formes sym´ etriques

Personne 0..1

épouse époux

0..1 Personne

0..*

ami

ami 0..*

102

Diagramme de classes

Interfaces Les Interfaces

• Une interface sp´ ecifie un ensemble d’op´ erations (comportement)

• C’est un contrat

• Les classes li´ ees s’engagent ` a respecter le contrat

• elles doivent mettre en œuvre les op´ erations de l’interface

+ opération1() + opération2() . . .

«interface»

Interface 1

Représentation synthétique

Représentation détaillée

Diagramme de classes

Interfaces

Les interfaces : impl´ ementation et utilisation

List

ArrayList

. . . - lignes: List [*]

- adresses: Collection [*]

. . . Commande

Utilisation

Implémentation

. . .

«interface»

Collection

Diagramme de classes

G´ en´ eralisation/Sp´ ecialisation

G´ en´ eralisation / Sp´ ecialisation

• Interpr´ etation

• Niveau conceptuel : un concept plus g´ en´ eral qu’un autre

• Niveau impl´ ementation : h´ eritage des attributs et op´ erations

• Pour que ¸ ca fonctionne

• principe de substitution : toutes les propri´ et´ es de la classe parent doivent ˆ etre valables pour les classes enfant

• principe du « A est un B » ou « A est une sorte de B » :

toutes les instances de la sous-classe sont aussi

instances de la super-classe

(9)

105

Diagramme de classes

G´ en´ eralisation/Sp´ ecialisation

Notation :

Classe B

Classe A

Super-classe:

plus générale

Sous-classe:

plus spécialisée

106

Diagramme de classes

G´ en´ eralisation/Sp´ ecialisation

Exemple :

Véhicule à Moteur

Véhicule à Voile Véhicule à

Pédales

accélérer() freiner() nb_places

Véhicule ◀ dirige

Personne 1..*

107

Diagramme de classes

G´ en´ eralisation/Sp´ ecialisation

• G´ en´ eralisation

• Factoriser les ´ el´ ements communs (attributs, op´ erations, contraintes)

• Sp´ ecialisation

• Extension coh´ erente de classes

• Relation non-r´ eflexive, non-sym´ etrique !

Classe A

Classe B Impossible !

108

Diagramme de classes

G´ en´ eralisation/Sp´ ecialisation Ensemble de g´ en´ eralisation

• Les relations d’h´ eritage peuvent ˆ etre regroup´ ees selon un discriminant

• On obtient un ensemble de g´ en´ eralisation

• Une seule propri´ et´ e de discrimination par ensemble Exemple :

Véhicule

propulsion

Véhicule à Moteur

Véhicule à Voile Véhicule à

Pédales

discriminant

Véhicule à Moteur

Véhicule à Voile Véhicule à

Pédales propulsion

Véhicule

Diagramme de classes

G´ en´ eralisation/Sp´ ecialisation

Propri´ et´ es d’Ensemble de g´ en´ eralisation

• Propri´ et´ e de distribution :

• {disjoint}

Un v´ ehicule est ` a moteur OU ` a voile

• {overlapping} sinon

Un v´ ehicule peut ˆ etre ` a moteur ET ` a voile

• Propri´ et´ e de couverture :

• {complete}

toutes les sous-classes possibles sont d´ efinies

• {incomplete} sinon

Un v´ ehicule peut ˆ etre ` a moteur, ` a voile, mais aussi...

• par d´ efaut : {incomplete, disjoint}

Diagramme de classes

G´ en´ eralisation/Sp´ ecialisation

Exemple :

Animal

genre

Mâle

Insecte

Femelle {disjoint, complete}

{disjoint, incomplete}

Mammifère

Reptile

famille

(10)

111

Diagramme de classes

G´ en´ eralisation/Sp´ ecialisation G´ en´ eralisation multiple

• Autoris´ ee en UML

• Attention aux conflits ! Exemple

Véhicule

Terrestre Véhicule

Aérien Véhicule

Aquatique {overlapping}

Automobile Aéroglisseur Bateau Avion

112

Diagramme de classes

G´ en´ eralisation/Sp´ ecialisation

Comment ´ eviter l’h´ eritage multiple ?

• Premi` ere solution : d´ el´ eguer

Classe A Classe B

Classe C

Classe A Classe B

Classe C

113

Diagramme de classes

G´ en´ eralisation/Sp´ ecialisation

Comment ´ eviter l’h´ eritage multiple ?

• Deuxi` eme solution : h´ eriter de la classe la plus importante et d´ el´ eguer les autres

Classe A Classe B

Classe C

Classe A Classe B

Classe C

114

Diagramme de classes

Classes Abstraites

Les classes abstraites

• n’ont pas d’instances directes

• ce sont leurs sous-classes qui sont instanciables

• Repr´ esentation : nom en italique Op´ erations abstraites :

• signature d´ efinie dans la classe abstraite

• impl´ ementation sp´ ecifi´ ee dans les sous-classes

Diagramme de classes

Classes Abstraites Exemple :

+ calculeSurface() + type() + colorier(string) - couleur: string

FormeGéométrique

+ calculeSurface() + type() - longueur - largeur

Rectangle

+ calculeSurface() + type() - rayon

Cercle classe abstraite

return PI x rayon²

return longueur x largeur opération

abstraite

Diagramme de classes

Les d´ ependances

Relations de d´ ependance

• relation entre plusieurs entit´ es

• pour les relations qui ne peuvent pas s’exprimer autrement

• 3 grands types :

• abstraction

• ex. : « refine », « derive », « trace »

• permission d’utilisation

• ex. : « permit »

• utilisation

• ex. : « use », « create », « call »

(11)

117

Diagramme de classes

Les d´ ependances

Exemples :

Classe A «refine» Classe B

Tableau «create» Case

passage

concept/implémentation

utilisation

118

Diagramme de classes

La surcharge d’association

Plusieurs cas de surcharge d’association

• changement de multiplicit´ es

• changement de classe associ´ ee

• changement d’agr´ egation

119

Diagramme de classes

La surcharge d’association

Exemple

Moyen de Transport

Avion Bateau

Moteur

«refine»

0..*

1..*

120

Diagramme de classes

Classes param´ etrables

Les classes param´ etrables (ou Templates)

• il s’agit de mod` eles de classe

• les attributs et op´ erations sont d´ efinis en fonction de param` etres

• une classe param´ etrable n’est pas instanciable

• il faut d´ efinir les param` etres

• on obtient une classe « r´ eelle »

Diagramme de classes

Classes param´ etrables

Exemple

FArray

T, k : Integer = 10

contents: T [0..k]

AddressList

«bind» <T -> Address, k -> 3>

Tab : FArray <T -> Point>

Diagramme de classes

El´ ´ ements d´ eriv´ es

Les attribus d´ eriv´ es

• attribut qui peut ˆ etre d´ eduit d’autres attributs

• calcul´ e ` a partir d’autres infos ` a n’importe quel moment

• notation : /attribut Exemple

dateNaissance /age

Personne {age = dateActuelle - dateNaissance}

(12)

123

Diagramme de classes

El´ ´ ements d´ eriv´ es Les associations d´ eriv´ ees

• association redondante d´ eduite d’une ou de plusieurs autres

• quand ? pour faciliter les traitements ou aider ` a la compr´ ehension

Exemple

Entreprise SSII

Prestataire employeur 1..*

*

client sous-traitant

0..1

*

0..1

◀ /travaille *

*

124

Les diagrammes UML

Diagramme

Diagramme d'objets

structure composite

Diagramme d'états

125

Diagramme de packages

UML Superstructure Specification, v2.1.1 221

Other Actions

Actions are defined for accepting events, including operation calls, and retrieving the property values of an object all at once. The StartClassifierBehaviorAction provides a way to indicate when the classifier behavior of a newly created object should begin to execute.

Structured Concepts

These actions operate in the context of activities and structured nodes. Variable actions support the reading and writing of variables. The abstract metaclass VariableAction statically specifies the variable being accessed. Variable actions can only access variables within the activity of which the action is a part. An action is defined for raising exceptions and a kind of input pin is defined for accepting the output of an action without using flows.

11.2 Abstract Syntax

The package dependencies of the Actions chapter are shown in Figure 11.1.

Figure 11.1 - Dependencies of the Action packages

[Vue Statique]

126

Diagramme de packages

Package

• M´ ecanisme g´ en´ eral pour

• organiser les ´ el´ ements et les diagrammes du mod` ele (notamment les classes)

• partitionner, regrouper, hi´ erarchiser

• clarifier

• les nommer

• un package d´ efinit un espace de nom

• dans un mˆ eme package, deux ´ el´ ements ne peuvent avoir le mˆ eme nom

Diagramme de packages

Utilisation

• Organisation globale du mod` ele

• hi´ erarchie de packages

• Organisation des classes en packages

• contrˆ oler la structure du syst` eme

• comprendre, partager

• application plus ´ evolutive et facile ` a maintenir : – ne pas se faire d´ eborder par les modifs – viser la g´ en´ ericit´ e et la r´ eutilisabilit´ e des packages

• vue claire des flux de d´ ependances entre packages

• ` a minimiser !

Diagramme de packages

Packages

Un package

• contient des ´ el´ ements

• y compris d’autres packages (hi´ erarchie de packages)

• peut en importer d’autres

• peut poss´ eder des interfaces

• nommage : noms qualifi´ es

• ex. : package java::util

• classe java::util::Date

(13)

129

Diagramme de packages

Notation Repr´ esentation

Types Types

Integer Date

Types

+

130

Diagramme de packages

Exemple

Clientèle

Véhicules

- nom: String - adresse: Adresse

Personne

Roue

Fournisseur::Pneu

0..1 4

- marque: String - modèle: String - immat.: String Voiture

possède

*

131

Diagramme de packages

D´ ependances entre packages

• d´ ecoulent des d´ ependances entre leurs ´ el´ ements

• non-transitives

• modifier Fournisseur n’oblige pas ` a modifier Client` ele

Clientèle Véhicules

Fournisseur

132

Diagramme de packages

D´ ependances entre packages

St´ er´ eotypes de d´ ependance

• « import » :

les ´ el´ ements du package import´ e passent dans l’espace de nommage

• importation publique

• ex. : classe Date depuis le package qui importe

• « access » :

• idem, mais import priv´ e

Auxiliary

ShoppingCart WebShop

Types «import»

«access»

«import»

Diagramme de packages

D´ ependances entre packages

St´ er´ eotypes de d´ ependance

• « merge » :

• op´ eration permettant de fusionner deux packages

• utilis´ e en m´ eta-mod´ elisation

• implique des transformations

• contraintes ` a respecter

P1

P2

«merge»

P1 P2

P2' package

"mergé" package

"récepteur"

package

"résultat"

devient merge

P3

«import»

Diagramme de packages

D´ ecoupage en packages

Principe de d´ ecoupage en packages

• Coh´ erence interne du package (relations ´ etroites entre classes)

• fermeture commune

• les classes changent pour des raisons similaires

• r´ eutilisation commune

• les classes sont r´ eutilis´ ees ensemble

• Ind´ ependance par rapport aux autres packages

(14)

135

Diagramme de packages

Gestion des d´ ependances

Principe de gestion des d´ ependances

• Minimiser les d´ ependances pour maintenir un couplage faible

• d´ ependances unidirectionnelles

• cf. associations navigables

• pas de cycles

• stabilit´ e des d´ ependances

• plus il y a de d´ ependances entrantes, plus les interfaces de package doivent ˆ etre stables

136

Les diagrammes UML

Diagramme

Diagramme d'objets

structure composite

Diagramme d'états

137

Diagramme d’objets

[Vue Statique]

138

Diagramme d’objets

• Repr´ esentation d’instances d’´ el´ ements du diagramme de classes

• Utilisation :

• Pour repr´ esenter un « instantan´ e » du syst` eme (snapshot)

• les objets et leurs liens ` a un moment donn´ e

• les diff´ erents ´ etats possibles d’une classe peuvent ˆ etre repr´ esent´ es par diff´ erents objets (1 par snapshot)

• Pour illustrer, exemplifier

• quand une structure complexe est trop difficile ` a comprendre avec un diagramme de classes (ex. : r´ ecursivit´ e, associations multiples, etc.)

Diagramme d’objets

Attention :

• point de vue statique

• objet = ´ el´ ement de mod` ele

(6= ´ el´ ement dynamique qu’il repr´ esente)

Diagramme d’objets

Notation

• Instances nomm´ ees

• Instances anonymes

• Instances avec valeurs d’attributs

nomInstance: NomClasse

bouton1: Bouton

: NomClasse

: Cercle

nomVille: String

"Calais"

numero : Integer = 32 nomRue = "rue Stine"

monAdresse: Adresse