1. 2 u.m.l. unified modeling language (1 ère partie) françoise schlienger 4 ème année 2004-2005

2

U.M.L.Unified Modeling Language

(1ère partie)

Françoise Schlienger

4ème année 2004-2005

Département Informatique

3

Plan de la première partie

• Les méthodes d’analyse de 1960 à 1990 5

• Les méthodes Objet 9

• UML : généralités 16

• Les diagrammes d ’UML 17

• Les mécanismes communs 19

• Les diagrammes de classes 31

• Les diagrammes d ’objets 61

4

Booch

Unified MethodUnified Method0.8

etc...

OOSE(Jacobson et al.)

UML 0.9UML 0.9

1996

etc.ROOMCatalysis

OMGOMG

UML 1.1UML 1.1

Nov. 1997Nov. 1997

UML 1.3UML 1.3

UML 1.4UML 1.4

UML 2.0UML 2.0

Juin 1999Juin 1999

FinFin 200 20011

……

HOOD

OMT (Rumbaugh et al.)

1995

RationalRational

ROOM

Classe-Relation

Fusion

OOSE

Booch

OMT

Fin 1990

5

Méthodes d ’analyse (60-80)

MERISE(1962)

PETRI(1962)

HIPO(1970)

SD(1974)

Idef-0(1974)

LCS(1974)

HDM(1979)

SADT(1976)

SA(1978)

E-R(1976)

SDS(1977)

HOS(1975)

MACH(1980)

DREAM(1978)SARA

(1978)

IA-NIAM(1975)

1960-1974

1975-1980

6

Méthodes d’analyse (60-80)

1960 - 1974

• HIPO : Hierarchy plus Input Process Output (IBM/USA).

• PETRI : les réseaux de Petri ; outil pour la synchronisation (Allemagne)

• LCS : Lois de Construction de Systèmes (Warnier - France).

• SD : Structured Design (IBM : Stevens, Myer, Constantine, USA).

• Idef-0 : Icam definition-0 (DoD, US air force).

1975 - 1980

• IA-NIAM : Niijsen Information Analysis Methodologie, modèle relationnel binaire (Pays Bas).

• E-R : Entity-Relationship model (P. Chen, USA).

• SADT : Structured Analysis Design Technique (D.T. Ross, USA).

• SA : Structured Analysis (F. Yourdon, T. Demarco, USA).

• MERISE : méthode mise au point dans le cadre du ministère de l'industrie (Tardieu, Rochfeld ...)

7

Méthodes d ’analyse (80-90)

HOOD(1987)

OOD-86(1986)

SA-RT-2(1986)

OOA (C&Y)(1989) TOCATTA

(1987)

MASCOT3(1986)STATEMATE1

(1987)

MACH-2(1987)

1985-1990

JSD(1981)

SASD(1981)

MAIA(1984)

OOD-83(1983) SA-RT-1

(1984) CORE(1983)

AXIAL(1984)

SSADM(1982)

1981-1985

8

Méthodes d’analyse (80-90)

1981 - 1985• JSD : Jackson System Development (Michael Jackson, USA).• SASD : Structured Analysis and Structured Design (L. Constantine, USA).• SSADM : Structured Systems Analysis and Design Method (UK)• OOD-83 : Object Oriented Design (G. Booch, USA).• SA-RT-1 : Structured Analysis Real Time (P. Ward, S. Mellor, USA).• AXIAL : (P. Pellaumail, IBM-France).

1985 - 1990• OOA : Object Oriented Analysis (P. Coad, E. Yourdon, USA).• SA-RT-2 : Structured Analysis Real Time (D. Hatley, I. Pirbaï, USA).• HOOD : Hierarchical Object Oriented Design (Agence spatiale européenne).• TOCCATA : Techniques d'Organisation de la Conception par Comportements Abstraits

et Types Abstraits (CGE Alsthom, France).

9

Les méthodes objet

OBJECTORY(1992)

FUSION(1994)

CLASSERELATION

(1991)

OOA(S&M)(1991)

OMT(1991)

G. BOOCH(1991)

OOM(1991)

OBJETSNATURELS

(1991)

MERISE 2(1993)

EUROMETHODE

UML

MERISE +

1990-1995

Actuellement

?

UML 2

10

OOA : Coad et Yourdon* Analyse orientée objets (version 2) P. Coad et E. Yourdon, Masson 1993* Conception orientée objets P. Coad et E. Yourdon, Masson 1993

OOA : Shlaer et Mellor* Object-Oriented Systems Analysis : Modeling the World in Data

S. Shlaer et S. Mellor, Yourdon Press 1988* Object-Lifecycles : Modeling the World in States

S. Shlaer et S. Mellor, Yourdon Press 1992

Grady Booch : méthode orientée Ada 1991* Conception orientée objets et applications

Grady Booch, Addison-Wesley 1992

OOSE : version simplifiée d'Objectory (intéressant pour les aspects USE-CASE)* Le génie logiciel orienté objet

Ivar Jacobson, Christerson, Jonsson, Övergaard, Addison-Wesley 1993

Les méthodes objet (1)

11


Méthode classe-relation

* Ingénierie des objets, Approche classe-relation, application à C++

P. Desfray (version 2), Masson 1993

La méthode FUSION* Object Oriented Development : the FUSION method

D. Colemen, P. Arnold, S. Bodoff, Prentice-Hall, Englewood Cliffs, NJ, 1994

Évolution de Merise Merise/2

* MERISE/2 : modèles et techniques MERISE avancésG. Panet, R. Letouche, Éditions d'organisation 1994

OOM : Orientation Objet pour Merise* De Merise à OOM. Pourquoi changer ?

M. Bouzegoub, A. Rochfeld, Édition Hermès 1996

12

OMT : Rumbaugh et al. * premier livre en 1991, première conférence en France : 1993

* O.M.T. : Modélisation et conception orientées objet (édition française revue et augmentée) Rumbaugh et al., Masson 1995 * O.M.T. : Solution des exercices Rumbaugh et al., Masson 1996


13

UML : Unified Modeling Language

• octobre 94 : Grady Booch (Méthode Booch) et James Rumbaugh (OMT) commencent à unifier leurs 2 méthodes.

--> Unified Method 0.8

• fin 1995 : Ivar Jacobson introduit certains concepts de sa méthode (OOSE)

Langage de modélisation unifié avec pour objectifs de :

- ne plus faire évoluer les méthodes de manière indépendante les unes des autres,

- unifier la sémantique et les notations et amener ainsi une stabilité sur le marché "orienté-objet "

- rassembler leurs efforts pour résoudre des problèmes qu'aucune des trois méthodes ne peut bien résoudre.

14


• octobre 1996 : UML 0.9 (Unified Modeling Language)diffusion au sein de la "communauté informatique" et intégration des remarques.

• 16 janvier 1997 : le document UML a été soumis à l'OMG (Object Management Group). .

• 14 novembre 1997 : adoption d'UML 1.1 comme standard par l'OMG.• Novembre 1998 : UML 1.3• 2000 : UML 1.4• 2004 : UML 2

Sites officiels : www.omg.orgwww.uml.org

15

Bibliographie

• Modélisation objet avec UML Pierre-Alain Muller, Eyrolles 1997, Eyrolles 2000Pierre-Alain Muller, Nathalie Gaertner, Eyrolles 2003• Intégrer UML dans vos projetsN. Lopez, J. Migueis, E. Pichon, Eyrolles 1997• UML pour l'analyse d'un système d'informationChantal Morley, Jean Hugues, Bernard Leblanc , Dunod 2000

• Le guide de l'Utilisateur UMLGrady Booch, James Rumbaugh, Ivar Jacobson, Eyrolles 2000

nouvelle version prévue pour UML 2 en mai 2005 (en anglais)• Le processus unifié de développement logiciel Grady Booch, James Rumbaugh, Ivar Jacobson, Eyrolles 2000

16


UML propose :

• des éléments de modélisation qui représentent les abstractions du système en cours de modélisation

• des éléments de visualisation qui procurent des projections textuelles ou graphiques permettant la manipulation des éléments de modélisation

17

Diagrammes d ’UML

• les diagrammes de cas d'utilisation qui représentent les fonctions du système du point de vue de l'utilisateur,

• les diagrammes de classes qui représentent la structure statique en termes de classes et de relations,

• les diagrammes d'objets qui représentent les objets et leurs relations.

• les diagrammes d'états-transitions qui représentent le comportement des classes en termes d'états,

• les diagrammes de séquence qui sont une représentation temporelle des interactions entre les objets.

• les diagrammes de collaboration qui sont une représentation spatiale des objets et de leurs interactions.

18

Diagrammes d ’UML

• les diagrammes d'activités qui représentent le comportement d'une opération en termes d'actions (proches des organigrammes).

• les diagrammes de composants qui représentent les composants physiques d'une application.

• les diagrammes de déploiement qui représentent le déploiement des composants sur des dispositifs matériels.

19

Les mécanismes communs

Sont applicables sur chaque modèle :

• les notes

• les étiquettes

• les contraintes

• les relations de dépendances

• les stéréotypes

20

Les notes

Elles permettent d’ajouter des informations à un modèle comme des commentaires (sans contenu sémantique) mais aussi des exigences, des observations, des révisions ou des explications.

Ceci est une note qui peut être reliée à tout élément de modélisation par des pointillés.

21

Les étiquettes

Nommées également « Tagged values », elles permettent la création de nouvelles informations dans la spécification d’un élément. Elles se présentent sous la forme de paires {nom, valeur}

{version , 3.2} peut être ajouté sur un modèle

Dans les AGL, elles sont souvent utilisées pour indiquer des propriétés relatives à la génération de code.

22

Les contraintes

Elles permettent d’étendre la sémantique d’un élément d’UML en ajoutant de nouvelles règles ou en modifiant celles qui existent déjà.

Elles sont placées entre accolades sans syntaxe particulière.

{ la femme d'une personne est de genre 'féminin'}

{ la mari d'une personne est de genre 'masculin'}

Souhaits de spécialités dans l'ordre de préférence:

ETUDIANT

Nom : string

SPECIALITE

Libellé : string

sesSpé

*

{ordonné}

*

0..1SaFemme

PERSONNE

-Nom-Genre

SonMari0..1

23

Limite des contraintes informelles

PERSONNE

-Nom-Genre

0..1SaFemme

SonMari0..1 P1:PERSONNE

Nom = ‘Paul’Genre = ‘Masculin’

P2:PERSONNE

Nom = ‘Marie’Genre =‘Féminin’

P3:PERSONNE

Nom = ‘Anne’Genre =‘Féminin’

P4:PERSONNE

Nom = ‘Pierre’Genre = ‘Masculin’

SonMari

SonMari

SaFemme

SaFemme

Il faudrait ajouter :Si une personne est mariée, l’épouse du mari de cette personne est elle-même.Si une personne est mariée, l’époux de la femme de cette personne est lui-même.

Besoin de contraintes formelles : OCL

24

Les relations de dépendances (1)

Une dépendance est une relation sémantique entre deux éléments tels qu’un changement

apporté à l’un (élément source) peut affecter la sémantique de l’autre (élément cible).

Elle est représentée par une ligne en pointillés avec une flèche du coté de l’élément cible.

Elle peut être stéréotypée à l'aide d'un stéréotype standard.

E1:ENSEIGNANT

nom = ‘Dupont’

M1:MATIERE

libellé = ‘Génie logiciel’

MATIERE

libellé : string

enseigne >* 1..*

ENSEIGNANT

nom : string

« instantiates » « instantiates »

25

Les relations de dépendances (2)

PERSONNE PROJET

Participe

Responsable

{sous-ensemble}

Une contrainte peut être associée à plusieurs éléments par une relation de dépendance.

1 0..2

* *

- nom- prénom- e-mail

- nom- durée- dateDébut

26

Les stéréotypes

Ce sont des mécanismes d’extensibilité, permettant aux utilisateurs d’ajouter de nouveaux éléments de modélisation.

Les noms des stéréotypes sont mis entre « …. »

Dans une définition de classe on peut préciser

les constructeurs « create » et les destructeur « destroy »,

pour distinguer les différents types d’opérations.

Lorsqu’un stéréotype est utilisé fréquemment, on peut lui associer une notation particulière.

Client

<<actor>>

Client

<<actor>>

Client

CLIENT

<<create>>CLIENT()<<destroy>>Détruire()

27

Le stéréotype paquetage (« package »)

Les packages permettent de regrouper des classes, des associations et éventuellement d’autres packages.

On parle de PRODUIT :: Article

PRODUIT

ARTICLE LOCALISATION

FABRICANT1..*

* 1

*

28

Interface (1)

• Une interface est un ensemble d’opérations utilisées pour décrire un service d ’une classe.

• Contrairement à une classe, elle ne décrit aucune structure (elle ne peut donc pas inclure d’attributs) ni aucune implémentation (elle ne peut donc pas inclure de méthodes qui fournissent l’implémentation d’une opération).

• Une interface est en général liée (liaison de réalisation) à la classe qui la réalise.

• Une interface est représentée par un cercle et son nom. Le nom d’une interface commence généralement par un I.

PERSONNEI-PERSONNE

29

• On peut également représenter une interface par une classe stéréotypée, en indiquant les opérations qu ’elle fournit.

• Quand un objet joue un rôle spécifique, il présente un aspect particulier et les clients attendent un certain comportement.

Interface (2)

PERSONNE«interface»

I-PERSONNE

getHistoEmploi()getRémunération()getPrestation()

« realize »

30

Le stéréotype « interface »

Une interface

Une classe« use »

Une classe

« interface »Vue A

Un utilisateur X

« interface »Vue B

Un utilisateur Y

« use » « use »

« use » caractérise une relation de dépendance

« realize » « realize »

31

Diagrammes de classes / Diagrammes d’objets

32

Il existe plusieurs niveaux de notation :

a) niveau sans détail

PERSONNE

PERSONNE

NomPrénomAdresse

ModifierAdresse

b) niveau détail d'analyse

On y précise : le type des variables (integer, string, date …) les valeurs par défaut les signatures des opérations éventuellement, le niveau de visibilité : + public(accessible par tout utilisateur) par défaut

- privé(accessible seulement par la classe elle-même) # protégé(accessible par les descendants)

c) niveau de détail de conception

Notation des classes

33

• Attribut [ visibilité ] NomAttribut [: type] [= <valeur par défaut>]

•Opération[ visibilité ] NomOpération [(liste Paramètres)] [: typeRetour]

Paramètre[direction] Nom : type[ = valeur par défaut]

direction : in | out | inout (par défaut : in)

Notation des attributs et opérations

NOMDECLASSE

Opération()

Attributs

+EstSur(in p :POINT): boolean

-Longueur :integer =5

SEGMENT

34

Opérations / méthodes

• Une opération définit un service qui peut être demandé à n’importe quel objet de la classe.

• Une méthode est une implémentation d’une opération.

• La méthode associée à une opération fournit un algorithme exécutable. Cet algorithme est donné dans un langage de programmation ou dans du texte structuré.

35

Classe-1 Classe-2

Nom d’association

rôle-1 rôle-2

PERSONNE EstEnfantDe

Mère

Fils

PERSONNE APPARTEMENTLoue >

SonPropriétaire SesPropriétés

Propose >

SonLocataire SaLocation

Association entre classes

^

36

Exactement 1 1Exactement n nPlusieurs (0 ou plus) *Au plus 1 0..11 ou plus 1..*Cardinalité spécifiée 1..2 4

Nombre de propriétaires Nombre d ’appartements proposés

Cardinalité d’une association

PERSONNE APPARTEMENTPropose >1 *

37

Association : un exemple (1)

Un appartement n’a qu’un propriétaire et une personne peut proposer à la location plusieurs appartements (sous-entendu, elle peut aussi ne pas proposer d’appartement).

Remarque : on précisera toujours les noms des rôles. Le nom de l ’association est facultatif.

PERSONNE APPARTEMENT

Propose >1 0..*


38

Association : un exemple (2)

PERSONNE APPARTEMENT

Propose >1 0..*


-Code-Adresse-Surface-MontantLoyer

APPARTEMENT a un attribut implicite SonPropriétaire : PERSONNE

Un constructeur « complet » d’appartement doit avoir en paramètres le Code, l ’Adresse, la Surface, le MontantLoyer d ’un nouvel appartement mais aussi une instance de la classe PERSONNE.

39

Un qualificatif est un attribut dont les valeurs permettent de partitionner l’ensemble des objets reliés par la même association à un autre objet. Il permet de réduire la multiplicité effective d’une association

Ex1 : à un nom de fichier dans un répertoire ne correspond qu'un fichier

Les associations qualifiées (1)

REPERTOIRE NomFichier FICHIER11

1

REPERTOIRE **1 FICHIER

NomFichier

40

Ex2 : dans un cabinet médical, chaque médecin peut effectuer des actes de 3 types : visite,consultation, petite chirurgie.

On peut représenter le problème de 2 manières :

Les associations qualifiées (2)

Les actes médicaux sont rattachés au médecin par type.

MEDECIN CodeType ACTE-MEDICAL

MEDECIN * ACTE-MEDICAL1

CodeType

1*

41

Un attribut dérivé est un attribut calculé. Cela signifie qu’il peut être calculé à partir d ’autres informations du système à n’importe quel moment.

(et non pas qu’il a été calculé à un moment donné).

Exemple : pour une personne, l’attribut Age est un attribut calculé à condition que sa DateDeNaissance ait été enregistrée.Un attribut calculé est noté /Attribut

Par contre : si on met à jour une QuantitéEnStock par ajout ou suppression, sans conservertout l’historique des mouvements, alors QuantitéEnStock n’est pas une rubrique calculée.

L’attribut QuantitéEnStock est dit « modifiable » (par défaut tout attribut est « modifiable »)

« gelé » (« frozen ») est réservé aux attributs qui, une fois initialisés, ne peuvent être modifiés.

Attribut dérivé

42

Une association dérivée est une association déduite d’une autre.

Une association dérivée ne se justifie que pour faciliter des traitements.

Association dérivée

ENTREPRISE SERVICE EMPLOYESesServices SesEmployés

SesEmployés

SonService

/Emploi

Le nom de l’association est précédé d’un /

43

Contrairement à Merise, UML autorise :

• Une classe avec une seule instance et des attributs multivalués.

• Les attributs calculés (attributs dérivés) précédés par un / On précise alors, dans une note, la règle de calcul.

• Les associations dérivées (stéréotype « derive ») qui faciliteront un traitement.

Les identificateurs explicites (identifiants) ne sont pas indispensables. Ils ne sont pas soulignés (seuls les attributs de classe sont soulignés).

On peut les préciser à l’aide d’une note.

On peut représenter des « paramètres » (Merise) par le biais de variables de classe.

Remarques sur les classes

{identifier}

44

Contrairement à Merise ...

Exemple

Emploie>

ENTREPRISE

-Nom-Adresse

+ModifierAdresse()+AjouterPersonne()

1

PERSONNE

-Nom-Prénoms-Adresse-DateDeNaissance/-Age

+CréerPersonne()+GetCoordonnées()+CalculerAge

0..*

SesEmployés SonEntreprise

. {Age=DateCourante - DateNaissance}

+AjouterPersonne(in P : PERSONNE)

45

C ’est un type particulier d ’association "composé-composant" ou "partie de"

Agrégation (par référence) : 0..1

EQUIPE SPORT JOUEUR

Un joueur peut faire partie de plusieurs équipes

EQUIPE SPORT JOUEUR

Agrégation-Composition

SesParticipantsSonEquipe

*

SesParticipantsSesEquipes

**

Un objet peut faire partie de plusieurs composites à la fois.

46

Agrégation-Composition

La destruction du composite entraîne la destruction des composants.Un objet ne fait partie que d’un seul composite à la fois.

Composition (par valeur)

1 *

SaCommande SesLignesCOMMANDE LIGNE-COM

La durée de vie d’une ligne (de commande) est incluse dans celle de sa commande

Commande

Ligne annulée

Ligne ajoutée

Ligne non modifiée

Temps

47

Exercice

Réaliser un diagramme de classes permettant :• de représenter un train composé d’un ensemble de

wagons • de représenter les sièges répartis dans les différents

wagons

48

APPARTEMENTPropose >

Classe-Association (Classe associative)

AGENCE0..* 0..*

LOCATIONPrix : realSetPrix(P:real)GetPrix() : real

AGENCE 1

LOCATIONPrix : realSetPrix(P:real)GetPrix() : real

APPARTEMENT0..*0..* 1

49

Elles permettent de regrouper des opérations et des attributs communsà une ou plusieurs classes données et de préciser que les classes les plus spécifiqueshéritent des classes les plus générales.

COMPTE-BANCAIRE-Crédit : integer-Débit : integer….

+Déposer(S:integer)+Retirer(S:integer)+GetSolde()

COMPTE-EPARGNE-Taux : float

+CalculerIntérêts()

Généralisation Spécialisation

Relations de généralisation-spécialisation

50

Qualité d’une association qui permet le passage d’une classe vers une autre.En général, on peut naviguer dans les 2 sens. On peut cependant limiter la navigabilité :

Exemple :CLASSE-1 CLASSE-2

Nom d’association

Il doit être facile de passer directement d’un produit à son fabriquant.La commande d’un produit fait référence à l ’adresse de « SonRéalisateur »

Il y a demande de service (GetAdresse) de PRODUIT à FABRIQUANT.

Navigabilité d’une association

1..* 1SonRéalisateurSesProduits

FABRIQUANT

-Adresse

+GetAdresse()

PRODUIT

-QttéRéappro

+Commander()

51

Un attribut de classe décrit une valeur commune à une classe d'objets dans son ensemble.

Une opération de classe est une opération sur la classe elle- même. La plus commune est celle destinée à créer des nouvelles instances de classe.

Attributs et opérations de classe sont soulignés. (Attention : ne pas les confondre avec les identifiants de Merise.)

ARTICLE

-Référence-PrixHT-NbInstances

+CalculerPrixTTC()+Créer()+CompterInstances()

Attributs et opérations de classes

52

Un ‘ singleton ’ permet de référencer l’instance d ’une classe, unique par construction.

Forme générique d ’une classe implémentant un singleton.

L ’opération getInstance() est chargéede rapporter à l’appelant la référencede l objet unique.

Utilisation fréquente dans le cas d ’objets centralisateurs tels que‘superviseur’, ‘contrôleur’,

Application au design pattern ‘ singleton ’

SINGLETON

Instance : SINGLETON = null

getInstance() : SINGLETON

if (instance == null)instance := newSingleton()

return instance;

Le singleton se charge de construirel’objet lors du premier appel.

53

Classe et Opération abstraites / Polymorphisme

• Classe qui ne peut avoir aucune instance directe ; on écrit son nom en italique.

• Une opération abstraite ne fournit d’implémentation qu’au travers d’une instance d’une classe fille de celle qui la contient.

• Remarque : les noms des éléments abstraits sont écrits en italique ou préfixés par Abs.

FORME

-Nom : string

+CalcSurface()+GetNom()

54

RECTANGLE

- Long : float- Larg : float

+CalcSurface() + Type()

CERCLE

- Rayon : float

+CalcSurface()+ Type()

Opérationspolymorphes

Classe et Opération abstraites / Polymorphisme

FORME

-Couleur : string

+CalcSurface()+Type()

return ’rectangle’ return ’cercle’return Long * Larg

return PI * Rayon * Rayon

55

Attributs et opérations implicites (1)

ETUDIANT

Nom : string

Pour chaque attribut on ajouteimplicitement :

Ces opérations ne sont pas obligatoirement publiques. SetNom peut ne pas exister.

ETUDIANT

Nom : string

<constructeur>Etudiant ()<destructeur>~Etudiant()

<sélecteur ou accesseur>GetNom () : string<modificateur>SetNom (N:string) : bool

Pour la classe on ajoute implicitement :

56


ETUDIANT

Nom : string

ETUDIANT

Nom : stringSonGroupe : GROUPE

<sélecteur ou accesseur>GetSonGroupe () :GROUPE<modificateur>SetSonGroupe(G:GROUPE)RetirerSonGroupe() … si le minimum est à 0

GROUPE

Numéro : int

SonGroupe

0..1

Pour chaque association navigable

de cardinalité 0..1, 1..1 on ajoute :

un attribut

… et les opérations correspondantes

57

Remarque concernant la navigation

ETUDIANT

Nom : string

GROUPE

Numéro : integer

SonGroupe

0..1

Pour un étudiant on peut obtenir son groupe, mais il n’est pas prévud’obtenir la liste des étudiants à partir du groupe.

SesEtudiants

0..*

58


ETUDIANT

Nom : string

ETUDIANT

Nom : stringSesOptions : ensemble(OPTION)

<modificateur>AjouterOption(O:OPTION):boolRetirerOption(O:OPTION):boolGetSesOptions() : ensemble(OPTION)

OPTION

Libellé : string

SesOptions

0..*

Pour chaque association navigable

de cardinalité 0..*, 1..* on ajoute : un attribut de type ensemble,

… et les opérations

pour gérer ce type ensemble.

59

Remarque concernant la navigation

ETUDIANT

Nom : string

OPTION

Libellé : string

SesEtudiants SesOptions

0..* 0..*

Nouvelle hypothèse :

Pour un étudiant on peut obtenir ses options et on veut pouvoir obtenir la liste des étudiants à partir d’une option.

En ajoutant une flèche vers SesEtudiants, on ajoute implicitement SesEtudiants : ensemble (ETUDIANT) dans OPTION et les opérations correspondantes.

60


REPERTOIRE NomFichier FICHIER11

1

Dans répertoire on trouvera une opération :

Chercher (NomFichier : string) : FICHIER

61

Diagrammes d’objets

• Ils modélisent les instances d’éléments qui apparaissent sur les diagrammes de classe.

• Ils montrent un ensemble d ’objets et leurs relations à un moment donné.

– Instances nommées

– Instances anonymes

– Instances avec valeurs d ’attributs

Bouton2:RECTANGLE

Longueur : float = 13.5Nom : string = “bouton-poussoir”

Largeur : float = 3.2

:CERCLE

Bouton1:RECTANGLENomInstance:NOMCLASSE

:NOMCLASSE

62

MATIERE

libellé : string

Diagramme d’objets (exemple)

E1:ENSEIGNANT

nom = ‘Dupont’

E2:ENSEIGNANT

nom = ‘Martin’

E3:ENSEIGNANT

nom = ‘Duval’

M3:MATIERE

libellé = ‘Système’

M1:MATIERE


M2:MATIERE

libellé = ‘Réseau’

enseigne >* 1..*

ENSEIGNANT

nom : string

63

MATIERE

libellé : string

Diagramme d’objets (nécessité de préciser l’association)

enseigne

enseigne

enseigne

enseigne >* 1..*

ENSEIGNANT

nom : string0..1 *

estResponsable >

estResponsable >

estResponsable >

E1:ENSEIGNANT

nom = ‘Dupont’

E2:ENSEIGNANT

nom = ‘Martin’

E3:ENSEIGNANT

nom = ‘Duval’

M3:MATIERE

libellé = ‘Système’

M1:MATIERE


M2:MATIERE

libellé = ‘Réseau’

66

U.M.L.Unified Modeling Language

(2ème partie)


4ème année 2004-2005

Département Informatique

67

Plan de la deuxième partie

• Les diagrammes de cas d’utilisation (Use-Case) 69

• Les diagrammes d’interactions 82

• Les diagrammes de séquences 84

• Les diagrammes de collaboration 102

• Les diagrammes d’états 105

• Les diagrammes d’activités 134

• Les diagrammes de composants 143

• Les diagrammes de déploiement 147

68

Booch


etc...


UML 0.9UML 0.9

1996

etc.ROOMCatalysis

OMGOMG

UML 1.1UML 1.1

Nov. 1997Nov. 1997

UML 1.3UML 1.3

UML 1.4UML 1.4

UML 2.0UML 2.0

Juin 1999Juin 1999

FinFin 200 20011

……

HOOD


1995

RationalRational

ROOM

Classe-Relation

Fusion

OOSE

Booch

OMT

Fin 1990

69

Les cas d ’utilisation (1)

Un cas d'utilisation indique une fonctionnalité du système déclenchée par un acteur externe au système.

L'acteur représente un rôle joué par une personne (ou un autre système) qui interagit avec le système en cours de modélisation.

• La même personne physique peut jouer le rôle de plusieurs acteurs (enseignant, responsable)

• Plusieurs personnes peuvent également jouer le même rôle, et donc agir comme le même acteur (tous les clients)

ActeurCas d'utilisation

70

Les cas d'utilisations permettent d'exprimer les désirs des utilisateurs du logiciel en cours de modélisation.

Les cas d ’utilisation décrivent le comportement du système, du point de vue d'un utilisateur, sous la forme d'une séquence d'actions et de réactions.

On peut préciser le comportement d’un cas d’utilisation en décrivant les flots d ’événements à l’aide d’un texte. Puis au fur et à mesure que l’on affine sa compréhension des exigences du système, on utilise des diagrammes d’interaction pour préciser graphiquement ces flots.

Les cas d ’utilisation (2)

71

Achat sur site Internet

Les acteurs : propriétés

Une relation de généralisation/spécialisation peut être appliquée aux acteurs.

Internaute

Consulter info.

Client Acheter livre

72

Un cas d’utilisation modélise un ensemble de séquences dans lequel chaque séquence représente une variation possible d’un même type d’interaction.

Chaque séquence est un scénario.

–Scénario : cas d’utilisation spécifique(exemple : « Le client Pierre retire 100 euros avec sa carte VISA à partir du distributeur installé 5 rue du château »)

–Cas d’utilisation : modélise le cas général, donne une vision synthétique de scénarios similaires.(exemple : « un client retire de l’argent à partir d’un distributeur »)

flot d’événements principal

On peut avoir d’autres scénarios : carte VISA périmée flot d’événements exceptionnel

Cas d ’utilisation et scénarios

73

Le système voiture

Garagiste Conducteur

Se déplacer

Écouter de la musique

Faire la vidange

Réparer

Exemple de cas d ’utilisation

74

Relation d’inclusion « include »

Le système voiture

Garagiste

Faire la vidange

Réparer

<<include>>

Activer pont élévateur

<<include>>

Permet d’incorporer le comportement d’un autre cas d’utilisation. Le cas d’utilisation inclus

n’est jamais exécuté seul, mais seulement en tant que partie d’un cas de base plus vaste.

75

Relation d’extension « extend »

Le système voiture

Garagiste

Faire la vidange

Réparer

Commander pièce

<<extend>>

Permet de modéliser la partie d’un cas d’utilisation considérée comme conditionnelle dans le comportement du système.

76

Spécialisation

Le système voiture

Garagiste

Réparer

Réparer Diesel

Les cas d’utilisation peuvent être hiérarchisés par généralisation/spécialisation. Les cas d’utilisation descendants héritent de la sémantique de leurs parents. Ils peuvent comprendre des interactions spécifiques supplémentaires ou modifier des interactions héritées.

Réparer essence

77

Le cas d’une coopérative de libraires

Pour chacun des cas d'utilisation, on fournira une spécification sous forme de texte ou d'un diagramme d'interaction (séquence ou collaboration)

Créer Nouveau Client

Vérifier solvabilité client

EmployéPasser une commande

urgente

Enregistrer une commande

<<extend>>

<<include>>

Ce cas peut être considéré comme exceptionnel.

On peut factoriser des comportements

<<extend>>

78

Spécification sous forme textuelle (rédigée avec l’aide de l ’utilisateur)

Système : coopérativeActeur primaire : l’employé de la coopérativeObjectif : enregistrer une commande « normale » de livresPrécondition : le libraire existeScénarios :

1 - vérification de sa solvabilité (à partir de son numéro)

Pour chaque livre :2 - vérification de l’existence du livre (à partir de l ’ISBN)

3 - précision de la quantité

Exception :1a - le libraire n’est pas solvable

(l ’employé est informé)2a - le livre n’existe pas

(l ’employé est informé)

79

Diagramme de classe (version de base)

CATALOGUELIVRE

LIGNE-COMMANDE

COMMANDE-LIBLIBRAIRE

REGISTRE-LIBRAIRE -SesDemandes

-SesLignes

*1

-SesCommandes-SonDemandeur

-SonCatalogue-SesLivres

*1-SonLivre

1

-SesLibraires

1

*

-SonRegistre

-SaCommande

*

1

*

EDITEUR

-SesLivres

-SonEditeur

*

1

80

Spécification sous forme textuelle (proposition technique)

Système : coopérativeActeur primaire : l ’employé de la coopérativeObjectif : enregistrer une commande de livresPrécondition : le libraire existeScénarios :

1 - vérification de la solvabilité du libraire (à partir de son numéro)

* une instance de commande est créée Pour chaque livre :

2 - vérification de l ’existence du livre* une instance de ligne de commande est créée

* l ’instance est reliée à la commande3 - précision de la quantité

* la quantité est ajoutée

Exceptions :1a - le libraire n ’est pas solvable * un message est renvoyé2a - le livre n ’existe pas * un message est renvoyé

81

Diagramme de classe (version 2)

CATALOGUE

LIVRE

LIGNE-COMMANDE

COMMANDE-LIB

LIBRAIRE

REGISTRE-LIBRAIRE

-NumISBN : integer-Titre : string

-DateEdition : Date

-SesCommandes

+TrouverLibraire(In Numéro:integer):LIBRAIRE

+TrouverLivre(In numéro:integer):LIVRE

-SonRegistre1

-SonCatalogue -SesLivres

1 *

+Solvable?():boolean

-SonDemandeur

1-NumLib : integer-NomLib : string-AdresLib : string-Etat : string

-SesLibraires*

+Créer(In Lib:LIBRAIRE,In NumCom:integer, In DateCom:Date)

*

-NumCom : integer-DateCom : Date

-SaCommande1

+SetQuantité(In Nb:integer)

-Quantité : integer

-SesDemandes

-SonLivre

*

1

+Créer(In Liv:LIVRE ,In Com:COMMANDE-LIB ,In Quantité:integer)

*-SesLignes

EDITEUR

-Nom : string-Adresse : string

-SesLivres

-SonEditeur

*

1

82

Diagrammes d’interaction

83

Diagramme d’interaction

Les diagrammes d’interaction représentent les objets les uns par rapport aux autres et montrent comment ces objets communiquent au cours d’une interaction.

Il existe deux sortes de diagrammes d’interaction :

• les diagrammes de séquence qui sont une représentation temporelle des interactions entre les objets.

• les diagrammes de collaboration qui sont une représentation spatiale des objets et de leurs interactions.

84

Diagramme de séquence

Un diagramme de séquence permet de décrire une simulation du fonctionnement d ’un cas d ’utilisation. Il met en jeu :

• un acteur

• un ensemble d ’objets

• la chronologie des échanges entre les objets (messages avec leurs paramètres et leur valeur de retour)

• les contraintes de temps.

85

Diagrammes de séquence : principes généraux

nom2:Classe1

objet du diagramme de classes

ligne de vie (durée de l’interaction)activation

nom3:Classe2

message

nom (…)

retour

nom1:Acteur

nom(…)

acteur

86

Diagramme de séquence : notation

Inst.1:Acteur

CallAction()

Inst.3:Class-BCréer()

CallAction()

Inst.4:CLASSE-C

Détruire()

CallAction()

Inst.2:CLASSE-A

87

Diagramme de séquence « système »

Il permet de décrire le fonctionnement du système. C ’est une reformulation du texte du cas d ’utilisation.

Il met en jeu :

• un acteur

• l ’objet de la classe SYSTEME

• la chronologie des échanges entre les objets

• les contraintes de temps

88

Diagramme de séquence « système » : exemple

Le système est traité comme une boîte noire.

Pour chaque livre commandéSolvableLibraire (num)

TrouverLivre (ISBN)

SetQuantité (n)

: Système

Livre

réponse

Ou réponse négative

89

Diagramme de séquence : message avec retour

Monsieut TRUC:LeResponsable

Unlivre:LIVRE

GetTitre()

Titre

90

Diagramme de séquence : création et message sans retour

UnLivre:LIVRECréer(NumISBN, Titre, DateEdition)

LeCatalogue:CATALOGUE

AjouterLivre(self)


self ou this

91

Ajouter un nouveau livre : autre manière


L:LIVRECréer(Numéro, Titre, AnnéeEdition)

L


AjouterLivre(L)

92

Ajouter un nouveau livre : solution préférable


NouveauLivre(NumISBN, Titre, DateEdition)


UnLivre:LIVRECréer(NumISBN, Titre, DateEdition)

UnLivre

AjouterLivre (UnLivre)

93

Ajouter un nouveau livre en lui attribuant un numéro

L:LIVRE



NouveauLivre(Titre, AnnéeEdition)

Créer(Numéro, Titre, AnnéeEdition)L

AjouterLivre(L)

CalculerNuméro()

Numéro

Cela suppose que l’on conserve le dernier

numéro attribué

94

Diagramme de séquence : branchement conditionnel(2 objets différents)

Instance:CLASSE1 Instance1:CLASSE2 Instance2:CLASSE3

[X] CallAction1()

[non X] CallAction2()

95

Diagramme de séquence : branchement conditionnel(même objet)

Instance:CLASS1 Instance1:CLASSE

[X] CallAction1()

[non X] CallAction2()

96

Diagramme de séquence (exemple)

Monsieut TRUC:Responsable

LeRegistre:REG-LIBRAIRE UnLibraire:LIBRAIRE

SolvableLibraire?

b

Solvable?()

b

TrouverLibraire

UnLibraire

Vérification de la solvabilité d’un libraire identifié par un numéro.

(numéro)

(numéro)

97

Diagramme de séquence en escalier (décentralisé)

On parle aussi de délégation ou propagation des messages .

Instance:A Instance1:B Instance2:C Instance3:D Instance4:E

CallAction()

CallAction()

CallAction()

CallAction()

98

Diagramme de séquence en fourche (centralisé)

On parle aussi de supervision (un objet envoie tous les messages)

Instance:A Instance1:B Instance2:EInstance3:C Instance4:D

CallAction()

CallAction()

CallAction()

CallAction()

CallAction()

99


UnLibraire:LIBRAIRE C :COMMANDE-LIB L:LIGNE-COMMANDE SonLivre:LIVRE

GetDétailCommandes()

{Date +{Titre,Quantité}}

GetDétailCommande()

Date +{Titre,Quantité}

GetInfoLigne()

Titre,Quantité

GetTitre()

Titre

GetDate()

Date

GetLivre()

SonLivre

GetSesLignes()

SesLignes

GetQuantité()

GetSesCommandes()

Spécification sous forme de diagramme de séquence

Pour chaque commande C prise dans SesCommandes

Pour chaque ligne L prise dans SesLignes

SesCommandes

100


UnLibraire:LIBRAIRE C :COMMANDE-LIB L:LIGNE-COMMANDE SonLivre:LIVRE


GetDétailCommande()

GetInfoLigne()

Titre,Quantité

GetTitre()

Titre

Spécification sous forme de diagramme de séquence


Pour chaque ligne L prise dans SesLignes

Date +{Titre,Quantité}


101

Spécification sous forme de diagramme de séquence(trop centralisé)


C :COMMANDE-LIB L :LIGNE-COMMANDE unLivre:LIVREUnLibraire:LIBRAIRE

GetSesLignes()

GetQuantité()

Quantité

GetLivre()

unLivre

GetTitre()

Titre

GetDateCom()

Date


GetSesCommandes()

SesCommandes


Pour chaque ligne prise dans SesLignes

SesLignes


102

Diagramme de collaboration

Un diagramme de collaboration est une extension du diagramme d ’objets.

Il permet de décrire :

* un aspect structurel : un ensemble d ’objets, les liens entre ces objets, les rôles de ces objets dans la collaboration

* un aspect de communication : les messages et les numéros de séquence des échanges entre les objets de cette collaboration.

103

Spécification sous forme de diagramme de collaboration

MonsieurTRUC: Responsable

UnLibraire: Libraire

C: CommandeLib

L: LigneCommande

SonLivre : Livre

2: GetSesCommandes ( )

4: GetDate ( )5: GetSesLignes ( )

7: GetLivre ( )9: GetQuantité ( )

1: GetDétailCommandes ( )

3: GetDétailCommande ( )

6: GetInfoLigne ( )

8: GetTitre ( )

104

Diagramme de classe

CATALOGUE

LIVRE

LIGNE-COMMANDE

COMMANDE-LIB

LIBRAIRE

REGISTRE-LIBRAIRE

+Solvable?():boolean

-NumLib : integer-NomLib : string-AdresLib : string-Etat : string

+GetSesCommandes()+GetDétailCommandes()

-SesLivres

*

-NumCom : integer-SesCommandes

+SolvableLibraire?(In Numéro:integer):boolean

+GetSesLibraires()

SonCatalogue

1+TrouverLivre(In numéro:integer):LIVRE+AjouterLivre(In L:LIVRE)

+TrouverLibraire(In Numéro:integer):LIBRAIRE

*

SonRegistre

-SesLibraires

1

-SonDemandeur

1

-NumISBN : integer-Titre : string

-DateEdition : Date

+GetTitre():string

+Créer(In Numéro:integer ,In Titre:string ,In DateEdit:Date)+GetNumISBN():integer

-Quantité : integer

+MajQtté(In Nb:integer)+GetQuantité():integer

+GetInfoLigne()+GetSonLivre():LIVRE

-DateCom : Date

1

*

-SaCommande

-SesLignes

1

*

-SonLivre

-SesDemandes

+Créer(In Liv:LIVRE ,In Com:COMMANDE-LIB ,In Qtt:integer)

*

+Créer()

+GetDateCom():Date+GetDétailCommande()

+GetSesLignes(): Set (n)LIGNE-COMMANDE

+AjouterLigne(In L:LIGNE-COMMANDE)

EDITEUR

-Nom : string-Adresse : string

SesLivres

SonEditeur

*

1

105

Diagrammes d’états

106

Le diagramme d’états

Un diagramme d’état modélise l’existence (cycle de vie) d’un objet, que ce soit une instance de classe ou un système pris dans son ensemble.

Il repose sur différents concepts :

• les états

• les transitions

• les événements.

107

Les états

Un état correspond à la manière d’être d’un objet pendant un intervalle de temps plus ou moins long.

Un état se compose de plusieurs parties :

• le nom

• les actions d’entrée/sortie : ce sont des actions effectuées au moment de l ’entrée ou de la sortie de l’état

• les activités

• les actions liées aux transitions internes ( ces transitions n’occasionnent aucun changement d’état).

108

Transitions et Evénements

Une transition indique le passage d’un état (état source) dans un autre (état cible).

Elle est représentée par une flèche.

Un événement représente quelque chose qui arrive à un moment précis.

Il peut déclencher un changement d ’état.

Exemple : une télévision.

EtatTransition

Arrêtée En veilleMise sous tension

Evénement

109

Activités - Actions

Une activité représente une opération qui nécessite un certain temps d ’exécution.Une activité peut être interrompue à chaque instant par un événement générant une

transition.Une activité est associée à un état. Un état peut ne pas avoir d ’activité.

Une action représente une opération instantanée ; sa durée est insignifiante. Une action est toujours intégralement réalisée.Une action est associée à un événement.Si aucune action ne résulte d’un événement qui se produit alors on peut mentionner

l’action : « defer ». Cela permet d’insister sur le fait que l’événement peut arriver mais qu’il est sans effet dans l’état où l ’objet se trouve. L’événement sera traité par le même objet, dans un autre état, sans avoir besoin de se reproduire.

110

Forme générale d’un état

NOM D ’ETAT

entry / action-entréedo : activitéon Evénement-1/action-1…on Evénement-n / action-nexit / action-sortie

Début

Fin

111

Forme générale d ’une transition

Etat1

entry/action-entrée1do : activité1on Event-11/action-11…on Event-1n /action-1nexit/action-sortie1

Etat2

entry / action-entrée2do : activité2on Event-21/action-21…on Event-2m/action2mexit/action-sortie2

Événement [garde] / action

Actions et activités sont exprimées avec des verbes.

Remarque : suivant les cas, événement, garde (condition), action peuvent être omis.

112

Diagramme d’états : système d’alarme

EN-VEILLE

do : garder détecteur sous tension

EN-ALERTE

entry / mettre sonnerieDétection-Pb / envoyer message

poste de surveillance

Événement

Activité

Action

113

Dans une bibliothèque on enregistre tous les nouveaux livres avant de les mettre à disposition des lecteurs.

Cas 1 : les livres enregistrés sont mis à disposition à 15h.

Dès qu’un livre est enregistré il est mis à disposition

Diagramme d’états

ENREGISTREMENT

do / enregistrer

A DISPOSITION

entry / placerWhen 15 heures

ENREGISTREMENT

do / enregistrer

A DISPOSITION

entry / placer

114

États composés / Sous-états

Un sous-état est un état emboîté dans un autre état (état composé).

Forme générale :

Etat1 Etat2

Etat3 Etat4

Event-1

Event-5 Event- 3Event-2

Event-4

115

Exemple d’états composés

Un magnétoscope peut être * en fonctionnement

* hors fonctionnement.

* en veille

En fonction, il peut être * en enregistrement

* en diffusion.

HORS FONCTION EN-ENREGISTREMENT

EN-DIFFUSIONEN VEILLE

Event-1

Event-5 Event- 3Event-2

Event-4

EN FONCTION

Event-6

Event-7

116

États composés / Sous-états

Etat1 Etat2

Etat3 Etat4

Event-1

Event-5

Event- 3Event-2Event-4

Autre forme de modélisation équivalentePoint d ’entrée de l’état composé.

117

États à historique

Un état à historique permet à un état composé qui contient des sous-états de se souvenir du dernier sous-état actif avant la transition réalisée depuis l’état

composé.

Etat1 Etat2

Etat3 Etat4

Event-1

Event-5

Event- 3Event-2

Event-4

H

Point d’entrée pour la première fois.

118

États à historique (exemple)

Exemple : une machine à laver peut être arrêtée dans un état (lavage, rinçage, essorage). Elle redémarrera du même état.

Arrêtée

En lavage

En rinçage

En essorage

Mise en fonctionnement

H

Fin du cycle

Arrêt

119

Diagramme d’états : exemple de la montre

Une montre digitale simple possède un cadran et 2 boutons que l’on nomme A et B, pour la mettre à l’heure. La montre a deux modes d’opération : affichage de l’heure et mise à l’heure.

Le mode de mise à l’heure a deux sous-modes, heures et minutes.

Le bouton A s’utilise pour les modes. A chaque fois que l’on appuie dessus le mode change suivant la séquence : affichage, configurer heures, configurer minutes, affichage, etc.

Dans un des 2 sous-modes ‘ configurer heures ’, ‘ configurer minutes ’, le bouton B s’emploie pour avancer les heures ou les minutes à chaque fois que l’on appuie dessus. Les boutons doivent être relâchés avant de pouvoir produire un autre événement.

120

Diagramme d’états

EnAffichageHeureAppuyerA

AppuyerA

EnModificationH

on AppuyerB/IncrémenterH()

EnModificationM

on AppuyerB/IncrémenterM()

AppuyerA

EnModification

121

La montre : diagramme de classes

MONTRE

-Heures : integer-Minutes : integer+AppuyerA()+AppuyerB()-IncrémenterH()-IncrémenterM()

122

La montre : diagramme de classes

ModifierHeures

+ EtatSuivant()+avance()

Montre

-heures : Type-heure-minutes : Type-minute

+AppuyerA()+AppuyerB()+IncH()+IncM()

AffichageHeure

+ EtatSuivant()

ModifierMinutes

+ EtatSuivant()+avance()

EtatMontre

+EtatSuivant()

+avance()état

*1

AffichageHeure: EtatMontreModifierHeure: EtatMontreAffichageMinutes : EtatMontre

123

Les événements « appel »

• Un événement « appel » est un événement interne (il survient entre les objets du système).

• Il représente le déclenchement d ’une opération.

• Un événement « appel » implique au moins 2 objets :

– celui qui invoque l’opération

– celui vers lequel l’événement est dirigé. Ce dernier devra contenir une opération de même nom que l’événement.

• Notation :

^objet-destinataire.événement-appel

124

Les événements « appel » : exemple

• Autoradio :

• Voyant lumineux

EN FONCTIONEntry : ^Voyant.Allumerdo : DiffuserSon

HORS FONCTION

Entry : ^Voyant.Eteindre

MettreBouton (‘off ’)

MettreBouton (‘on’)

ALLUME

Entry : SetLumière(‘vrai’)

ETEINT

Entry : SetLumière(‘faux’)

Eteindre

Allumer

125

Opérations publiques - Opérations privées

• Les opérations correspondant aux événements externes et aux événements appel correspondent à des opérations publiques (opérations déclenchées par un autre objet).

• Les opérations effectuées à l’intérieur d ’un état correspondent à des opérations privées (opérations d ’un objet sur lui-même).

126

Opérations publiques - Opérations privées : exemple

• L’utilisateur peut activer MettreBouton(‘off ’), MettreBouton(‘on’) mais c’est l’autoradio qui active l’opération DiffuserSon() suivant l’état dans lequel il est.

• L’autoradio envoie un message Allumer(), Eteindre() au voyant mais c’est le voyant qui active l’opération setLumière en fonction de son état.

SonVoyant

SonAutoradio

VOYANT

-Lumière : booléen

+Allumer()

+Eteindre()

- SetLumière(b:bool)

AUTORADIO

+MettreBouton(e: string)

- DiffuserSon()

127

Les événements temporels

• Les événements temporels sont causés par l’expiration d ’une temporisation. Ils peuvent être :

• absolus ( spécification d’une date ou d’une heure) et sont traduits par le mot clef when.

ex : when date = 1/01/02, pour indiquer le passage de l ’état où la monnaie était en francs à l ’état où la monnaie est en euros.

Monnaie en francs Monnaie en euroswhen date = 1/01/02

128

Les événements temporels

• relatifs (spécification d’une durée par rapport à un état) et sont traduits par le mot clef after

ex : after 10 jours, pour indiquer le passage de l’état consommé à un état périmé dans le cas de produits qui se détériorent rapidement.

Médicament consommé Médicament périmé

Médicament consommable

Ouverture flacon

after 10 jours

when date du jour >= date limite

129

Les événements « appel » : exemple

• Autoradio :

• Voyant lumineux

EN FONCTIONEntry : ^Voyant.Allumerdo : DiffuserSon

HORS FONCTION

Entry : ^Voyant.Eteindre

MettreBouton (‘off ’)

MettreBouton (‘on’)

ALLUME

Entry : SetLumière(‘vrai’)

ETEINT

Entry : SetLumière(‘faux’)

Eteindre

Allumer

130

Opérations publiques - Opérations privées

• Les opérations correspondant aux événements externes et aux événements appel correspondent à des opérations publiques (opérations déclenchées par un autre objet).

• Les opérations effectuées à l’intérieur d ’un état correspondent à des opérations privées (opérations d ’un objet sur lui-même).

131

Opérations publiques - Opérations privées : exemple

• L’utilisateur peut activer MettreBouton(‘off ’), MettreBouton(‘on’) mais c’est l’autoradio qui active l’opération DiffuserSon() suivant l’état dans lequel il est.

• L’autoradio envoie un message Allumer(), Eteindre() au voyant mais c’est le voyant qui active l’opération setLumière en fonction de son état.

SonVoyant

SonAutoradio

VOYANT

-Lumière : booléen

+Allumer()

+Eteindre()

- SetLumière(b:bool)

AUTORADIO

+MettreBouton(e: string)

- DiffuserSon()

132

Petit rappel sur les relations

Il existe 4 types de relations dans UML :• la dépendance représentée par une ligne en pointillés, fléchée.

• L’association représentée par une ligne continue qui peut être fléchée (navigation).

L’agrégation est une association particulière.

• La généralisation représentée par une ligne continue fléchée avec une pointe creuse.

• La réalisation représentée par une ligne en pointillés fléchée avec une pointe creuse.

133

Les diagrammes d ’activités

Un diagramme d’activités est essentiellement un organigramme qui représente l ’activité au cours du temps.

Il peut s’utiliser :

• pour préciser un cas d ’utilisation en indiquant les flux, les synchronisations, les conditions d’exécution des activités.

(on peut représenter éventuellement qui est responsable d’une activité)

• pour spécifier un algorithme associé à une opération.

134

Les diagrammes d ’activités (formalisme)

– Activité (traitement)

– Transition

– Synchronisation

– Flots de données

– Flots de données dans un état particulier

– Production et consommation de flot de données

– Branchement conditionnel [garde]

Faire ...

objet:Classe

objet: [état]

[cond.1]

[cond.2]

135

Commander produit

Traiter commande

Sortir article

Expédier commande

Recevoir commande

Facturer commande

Recevoir facture

Expédier facture

Payer facture

Clôturer commande

Recevoir paiement

136

Les travées

Une travée permet de diviser les activités en groupes, chaque groupe représentant le département responsable de ces activités. (niveau organisationnel de Merise)

Dans un diagramme d’activité divisé en travées, chaque activité appartient à une seule travée, même si les transitions peuvent passer d’une travée à l’autre.

Les travées sont délimitées par des barres verticales. Chaque travée a un nom.

137

Commander produit

Traiter commande

Sortir article

Expédier commande

Recevoir commande

Facturer commande

Recevoir facture

Expédier facture

Payer facture

Clôturer commande

Client Service ventes Entrepôt

Recevoir paiement

138

Commander produit

Traiter commande

Sortir article

Expédier commande

Recevoir commande

Facturer commande

Recevoir facture

Expédier facture

Payer facture

Clôturer commande

Client Service ventes Entrepôt

f: facture[due]

f: facture[payée]Recevoir paiement

139

Les composants (1)

Un composant est une partie physique remplaçable d’un système qui fournit la réalisation d’un ensemble d’interfaces. Un composant existe rarement indépendamment des autres. Un composant donné collabore avec d’autres composants.

Un composant est représenté par un rectangle avec des onglets :

Composant1

140

Un composant représente en général le regroupement physique d’éléments habituellement logiques tels que les classes et leurs interfaces en tenant compte de leurs collaborations.

On peut préciser les classes qu’implémente un composant par une liaison :

Les composants (2)

Composant1

Class1 Class2

Composant1

Class1

Class2

141

Les composants (3)

De la même manière que pour les classes on peut représenter les composants qui réalisent des interfaces, et les autres composants qui ont accès aux services à travers les interfaces.

Composant1Class

Composant

Lien de dépendance(accès au service)

Réalisation

Composant1<<interface>>

Class Composant

142

Composants standards

UML définit 5 stéréotypes standard qui s’appliquent aux composants :

• « file » précise un composant qui représente un document contenant du code source ou des données

• « executable » précise un composant qui peut être exécuté

• « table » précise un composant qui représente une table de base de données

• « library » précise une bibliothèque objet statique ou dynamique

• « document » correspond à un document quelconque (fichier de données, d’installation, document d’aide …)

143

Les diagrammes de composants

Ils montrent l’organisation et les dépendances au sein d’un groupe de composants.

En règle générale les diagrammes de composants contiennent

• des composants

• de interfaces

• des relations

– de dépendances

– de généralisation

– d’association

– de réalisation

144

Les diagrammes de composants (exemple de fichiers)

signal.h {version = 3.5}



« parent » « parent »

irq.h

interp.cpp

device.cpp

signal.cpp {version = 4.1}

145

Les nœuds

Un nœud est un élément physique qui intervient lors d’une phase d’exécution ; il représente une ressource de calcul et dispose généralement au moins d’un peu de mémoire et souvent d’une capacité de traitement.

Un nœud est en général représenté par un cube.

« mémoire »Disque

« processeur »PC

« dispositif »Modem

146

Les nœuds

Les nœuds sont probablement les briques de base les plus stéréotypés en UML.

Des icônes sont souvent associées aux stéréotypes, pour fournir des repères visuels explicites pour le public auquel ils sont destinés.

147

Les diagrammes de déploiement

Ils permettent de représenter l’architecture physique d’un système en visualisant les classes de nœuds (ou des instances de nœuds) et les relations de dépendances et d’associations entre ceux-ci.

Ils peuvent également comporter les composants qui doivent résider sur un nœud.

Remarque :

si on développe un logiciel sur une seule machine avec en interfaces des périphériques standards, on peut se passer de diagrammes de déploiement.

Nœud

Composant

Nœud

Composant

148

Les diagrammes de déploiementavec des icônes

149

Diagramme de déploiement : diagramme de spécification

Modélisation de la répartition des composants

kiosque

console

tour de disques RAID10-T Ethernet

RS-232

<<executable>>user

<<executable>>admin

<<executable>>config

10

20

1serveur

<<executable>>dbadmin

<<executable>>tktmstr

vitesseProcesseurmémoire

150

Diagramme de déploiement : diagramme d’instances

s:Serveurk1:kiosque

k2:kiosque

c1:console

t:tour de disques RAID

vitesseProcesseur = 2Ghzmémoire=256Mo

153

De l’analyse … à la conception

L’analyse des besoins est l’activité essentielle au début du processusde développement d’un logiciel.

Le futur utilisateur exprime ses besoins sous une forme textuelle informelle, parfois accompagnée de modèles d’IHM permettant de mieux préciser des souhaits.

Analyse des besoins

154

Le cas bibliothèque.

La bibliothèque d’une école d’ingénieurs met à disposition des élèves et des enseignants des livres techniques qui peuvent être empruntés. Chaque emprunteur dispose d'un badge, comportant un numéro, son nom et son prénom, qu'il doit présenter pour accéder à la bibliothèque. Il peut emprunter autant de livres qu'il le désire.

La durée de l'emprunt n'est pas limitée.

Chaque livre est repéré par un numéro, un titre, le nom de l'auteur principal, l'année d'édition.

155

Le cas bibliothèque.

On ne cherche pas à faire d'historique des emprunts. On veut seulement savoir quelle personne détient un livre de manière à pouvoir la contacter si une autre souhaite consulter l'ouvrage. Pour cela, on dispose pour chaque personne de son “ e- mail ”.

Il est nécessaire de pouvoir enregistrer un nouveau livre, un nouvelemprunteur. On voudrait pouvoir éditer des statistiques.

156

Le cas bibliothèque : IHM - retour anonyme

Retour anonyme :

Entrer le numéro du livre : 1 2 3 4 5 (RC) Le génie logiciel orienté Objet

157

Le cas bibliothèque : IHM - retour d’un étudiant

Retour d’un étudiant :

Retour d’ étudiantEntrer le numéro de l’emprunteur : 456 (RC)

Jean Dupuy

Livres empruntés : Le génie logiciel orienté Objet OCL pour les nuls

158

Spécification globale

Le but de cette activité est d'établir une première description du futur système.

L’expression préliminaire des besoins donne lieu à une modélisation par des

Cas d’utilisation

et à une maquette d’IHM.Il faudra donc :

• identifier les acteurs• identifier les cas d’utilisation• ajouter si besoin des relations entre cas d’utilisation.

Il sera utile d’établir une priorité entre les cas d’utilisation de manièreà aider le chef de projet à planifier ses itérations (modèle de la spirale).

159

Le cas bibliothèque : cas d’utilisation

Enregistrer Retour

Enregistrer EmpruntBibliothécaire

Enregistrer Nouveau Livre

Priorité 2

Enregistrer Nouvel Emprunteur

Éditer Statistiques

160

EnregistrerRetourAnonyme

Enregistrer Retour

Bibliothécaire

Le cas bibliothèque : cas d’utilisation

EnregistrerRetourEtudiant

161

Spécification globale (2)

Il s’agit ensuite de créer une représentation visuelle des objets du monde réel dans un domaine donné.Ils seront représentées dans un

Diagramme de classes d’analyse

ne mettant en évidence que peu d’opérations.

Par contre les attributs évoqués (caractéristiques d’un livre, d’un emprunteur, etc.) dans les cas d’utilisation ainsi quetoutes les associations suggérées (emprunt caractérisé comme une association entre LIVRE et PERSONNE) devront y figurer.

162

Le cas bibliothèque : diagramme de classes d’analyse

1

*

SaBiblio

BIBLIOTHEQUE

SesLivresSaBiblio

*1

SesEmprunteurs

PERSONNE

LIVRE

SesEmprunts

NumeroNomPrénomE-mail

SonEmprunteur

0..1

*

Professeur

Numéro Titre AuteurAnnéeEdition

Dans la phase d’analyseil n’est pas indispensable de faire apparaître la classe du domaine.

163

Spécification détaillée des exigences

Une fiche de description textuelle de chaque cas d’utilisation doit être fournie.Il est nécessaire de fournir :• le scénario qui permet de satisfaire les objectifs des acteurs par le chemin le plus direct de succès.• les extensions qui comprennent tous les scénarios de succès ou d’échec.Il faut également préciser :• les pré conditions qui définissent ce qui doit être vrai en amont ducas d’utilisation pour que celui-ci puisse démarrer.• Les post conditions qui définissent ce qui doit être vrai lorsque lecas d’utilisation se termine.

164

Le cas bibliothèque : scénario

Système : la Bibliothèque

Acteur Primaire : un bibliothécaire

Objectif : enregistrer les retours de livres d'un étudiant qui présente sa carte.

Scénario :1 - Rechercher à partir d'un numéro de carte, le nom de l’étudiant et la liste des titres des livres qu’il a empruntés.2 - Pour chaque livre sélectionné, enregistrer le retour.

Exception :1a -le numéro saisi est inconnu --> demander de recommencer.

Pré condition : le livre retourné figure dans la liste des livres empruntés.

165

Spécifications OCL

context EnregistrerEmprunt( NumL, NumP : integer) {signals echec}pre :Valide : boolean =

Il existe une instance de Livre avec numéro Numl.Cette instance n’est pas déjà empruntée.Il existe une instance de Personne avec numéro NumP.

post :not Valide implies echec.sent()Valide implies

L’instance de Livre avec numéro NumL a comme emprunteur la Personne avec numéro NumP.L’instance de Livre avec numéro NumL figure dans les emprunts de la Personne avec numéro NumP.

166

Spécifications OCL

context EnregistrerEmprunt( NumL, NumP : integer) {signals echec}pre :Valide : boolean =

Livre.allInstances exists ( L | L.Numéro =NumL)Personne.allInstances exists ( P | P.Numéro =NumP)let L1 : Livre | L1.Numéro = NumL inL1.sonEmprunteur isEmpty()


let L1 : Livre | L1.Numéro = NumLP1 : Personne | P1.Numéro = NumP inL1.SonEmprunteur = P1P1.SesEmprunts = P1.SesEmprunts@pre including (L1)

167

Spécifications OCL

context EnregistrerRetour( NumL : integer) {signals echec}pre :Valide : boolean =

Il existe une instance de Livre avec numéro Numl.Cette instance est empruntée par une Personne.


L’instance de Livre avec numéro NumL n’a pas d’emprunteurL’instance de Livre avec numéro NumL ne figure pas dans les emprunts de la Personne qui l’avait avant l’enregistrement de retour.

168

Spécifications OCL

context EnregistrerRetour( NumL : integer) {signals echec}pre :Valide : boolean =

Livre.allInstances exists ( L | L.Numéro =NumL)let L1 : Livre | L1.Numéro = NumL inL1.sonEmprunteur notEmpty()


let L1 : Livre | L1.Numéro = NumLP1 : Personne | P1= L1.SonEmprunteur@pre inL1.SonEmprunteur isEmptyP1.SesEmprunts = P1.SesEmprunts@pre excluding (L1)

169

Spécification détaillée des exigences

Les cas d’utilisation décrivent les interactions des acteurs avec lesystème.On peut représenter ces échanges à l’aide de

Diagrammes de séquence système.

Le comportement du système est décrit vu de l’extérieur, sanspréjuger de comment il sera réalisé.

170

Le cas bibliothèque : diag de séquence système - retour étudiant

:LeSystème:Bibliothécaire

TrouverLivres(NumEtu)

NomEtu +{titre}

EnregistrerRetour(titre)

171

Spécification détaillée (suite)

Il est nécessaire de contrôler la validité du texte des cas d’utilisationpar rapport aux informations définies dans le diagramme de classesconceptuelles.

Afin de pouvoir relier les diagrammes de cas d’utilisation audiagramme de classes conceptuelles, il est nécessaire d’identifierles principales classes d’IHM ainsi que les opérations qui vontmontrer la logique de l’application.

On va définir un diagramme supplémentaire appelé

Diagramme de classes de conception

172

Typologie des classes de conception

• Les classes qui modélisent les interactions entre le système et les utilisateurs, appelées classes « dialogue ».

• Les classes qui représentent les processus, les ressources etl’organisation d’une entreprise, appelées classes « métier ».Elles sont souvent permanentes.

• Les classes qui contiennent la cinématique de l’application, appelées classes « contrôle ». Elles font la transition entre les classes dialogues et les classes métiers et contiennent les règles métiers.

173

Les classes « métier »

Ce sont les classes étudiées jusqu’à présent. Celles-ci représentent en général des informations persistantes de l’application.

Métier MM

donnée1donnée2donnée3

opér1()opér2()

174

Les classes « dialogue »

Elles possèdent des attributs et des opérations. Les attributs vont représenter des champs de saisie ou des résultats. Les résultats sont distingués en utilisant la notation de l’attribut dérivé.Les opérations représentent des actions de l’utilisateur sur l’ IHM, oudes actions de la classe de contrôle.

Dialogue DD

champ1champ2/résultat

action1()action2() saisir ou afficher

175

Les classes « contrôle »

Elles possèdent uniquement des opérations.Elles montrent :

• la logique de l’application, • les règles métier, • les comportements du système informatique.

Contrôle CC

opération1()opération2()

176

Règles de composition des diagrammes de classes de conception

• Les « dialogues » ne peuvent être reliés qu’aux « contrôles ».• Les « métiers » ne peuvent être reliées qu’aux « contrôles » ou autres « métiers ».• Les « contrôles » ont accès à tout type de classes, y comprisd’autres contrôles.

Contrôle CC

opération1()opération2()

Dialogue DD

champ1champ2/résultataction1()action2()

Métier MM

donnée1donnée2donnée3opér1()opér2()

177

Un exemple simple

Écran de saisieNouveau Livre

CréerNouveau Livre

Livre

CtrCréation

créerLivre(titre, auteur)

Saisie Livre

titreauteur

saisir(titre, auteur)

Livre

numérotitreAuteur+Livre(titre, auteur)

- nouveauNuméro()

178

RetourAnonyme

NumLivre

/titre+AfficherTitre()+ EnregRetour()

CtrRetourAnonyme

+EnregRetour (NumLivre)-AfficherTitre(NumLivre)-TrouverLivre (NumLivre)

Livre

-numéro-titre-auteur

+RetirerEmprunteur(P:Personne)

Le cas bibliothèque : diag de classes d’analyse - retour anonyme

Personne

-numéro-nom-prénom

+RetirerLivre(L:Livre)

SonEmprunteur

0..1

*

SesEmprunts

179

RetourEtudiant

NumEtud/nom

+AfficherNom(N:string)+AffTitreLivre()

CtrRetourEtudiant

+AffTitreLivre(NumEtud)-AfficherNom(NumEtud)-AfficherTitre(T:sting)+EnregRetour (L:Livre)

Livre

-numéro-titre-auteur

Livre-Dialogue

/titre

+Créer()+sélectionner()

Le cas bibliothèque : diag de classes d’analyse - retour étudiant

Etudiant

-numéro-nom-prénom

SonEmprunteur

0..1

*

SesEmprunts

180

La conception

Elle vise principalement à préciser le modèle d’analyse de telle sorte qu’il puisse être implémenté avec les éléments d’architecture dont ondispose.• Les classes deviennent plus précises, avec des attributs typés.• Au niveau des « ensembles », il est nécessaire de préciser s’ils serontimplémentés sous forme de listes, de tableaux …• Les opérations sont complètement qualifiées ; on précise leur visibilité.• La navigation doit être mentionnée.

Pour ces 2 derniers points, il est nécessaire de répartir les responsabilités entre les différents objets. On a recours aux diagrammes de séquence.

181

Diagrammes de séquence.

:LeSystème

:Acteur

Action1()

retour

:Acteur

Action1()

retour

:Dialogue :Contrôle :Métier

Opération1()

GetDonnées()

182

Le cas bibliothèque : diag de séquence - retour Anonyme

:Bibliothécaire

EnregistrerRetour(Num))

RetourAnonyme CtrRetourAnonyme L: Livre SonEmp:Personne

EnregistrerRetour(Num)

Afficher(Titre)

TrouverLivres(Num)

SupprimerEmprunt()

getTitre()

Titre

RetirerLivre(self)

RetirerEmprunteur()

L

183

Le cas bibliothèque : diag de séquence - retour Étudiant

:Bibliothécaire

AffTitreLivre(num)

RetourEtudiant CtrRetourEtudiant P : Personne L:Livre

AffTitreLivre(Num)

TrouverEtud(num)

getNom()

getTitre()

Livre-dial

Titre

Nom

{Titre}

Afficher(Nom)

AffTitreLivre()

Créer(Titre)

Pour chaque livre L...

Pour chaque livre de la liste établie.

P

184

Le cas bibliothèque : diag de séquence - retour Étudiant

:Bibliothécaire

Sélectionner(L:Livre)

CtrRetourEtudiant L: Livre SonEmp:Personne

Sélectionner()

Livre-dial

RetirerLivre(self)

RetirerEmprunteur()

SupprimerEmprunt()

185

Quelques règles générales de présentation des diagrammes

• Disposer les éléments de façon à éviter que les lignes se croisent.

• Organiser les éléments de façon à ce que les éléments proches du point de vue sémantique soient également proches du point de vue physique.

• Ne JAMAIS présenter un diagramme et les commentaires s’y rapportant en recto-verso.

• Ne JAMAIS présenter des diagrammes se rapportant au même problème sur des pages recto-verso.

186

Quelques règles de définition du diagramme de classes

• Nommer les attributs avec des noms courts ou des petites expressions nominales qui représentent une des propriétés de la classe.

• Nommer les opérations avec des verbes courts ou de petites expressions verbales qui représentent certains comportements de leur classe englobante.

• Les noms de classes sont notés en majuscules : PERSONNE.

• Les noms d’attributs, d’opérations, de rôles commencent par une majuscule et les noms composés sont accolés, chacun commençant par une majuscule : DateDeNaissance.

• En règle générale les attributs sont privés et les opérations publiques.

187

Règles de définition du diagramme de classes (suite)

• Les opérations seront notées sous la forme :NomOpération(liste de paramètres) : type résultat

Ex : RechercherProduit(Code : integer) : PRODUITSauf consigne particulière on précisera paramètres et type de retour.

• On ne met JAMAIS en paramètre l’objet qui contient l’opération.

• Les opérations qui permettent d ’accéder aux attributs sont de la forme GetAttribut(). Ex : GetNom() : string (… mais CalcPrixTTC() : real )

• Les opérations qui permettent de modifier un attribut sont de la forme SetAttribut(paramètre). Ex : SetAdresse (A : string)

188

Règles de définition du diagramme de classes (suite)

• Les noms des rôles avec cardinalité 0..1 ou 1 commencent par Son ou Sa (Ex : SonPropriétaire, SaForme).

• Les noms des rôles avec cardinalité 0..* ou 1..* commencent par Ses (Ex : SesPropriétés).

• La navigabilité sera explicitée (flèche dans un ou deux sens).

189

Règles de définition des diagrammes de séquence

• Les opérations mises en évidence sur les diagrammes de séquence doivent figurer sur le diagramme de classes. On vérifiera que les paramètres sont cohérents entre les deux diagrammes.

• Les opérations seront précisées avec les paramètres (noms de variable plutôt que types de variables).

• Les messages de retour seront précisés dans la mesure du possible.

Notation : la répétition d ’information sera indiquée avec des accolades

{date + { titre + quantité }}

190

Règles de définition des diagrammes de séquence (suite)

• Lorsqu’un message est adressé à plusieurs instances I d’une même classe, on le mentionne dans une note associée au message.

Cette note est de la forme :

‘ Pour chaque instance I prise dans l’ensemble des instances ’

et le message est adressé à une instance nommée I.

• On privilégie les diagrammes de séquence de type décentralisé ou en escalier.

• On évite les conditions ; si besoin on fait 2 diagrammes de séquence.

191

Règles de définition des diagrammes d’états

• Les noms des événements de transition et les noms des événements internes (derrière le mot clef on ) sont des noms d’opérations publiques de l’objet pour lequel est fait le diagramme d’état.

• Les opérations effectuées en entrée ou en sortie d’un état, et les opérations effectuées au sein d’une activité sont des opérations privées de l’objet pour lequel est fait le diagramme d’état.

• Toutes ces opérations doivent figurer sur le diagramme de classes avec visibilité (public/privé) et paramètres cohérents entre les deux diagrammes.

192


ETUDIANT

Nom : string

ETUDIANT

Nom : stringSesVoeuxDOptions : liste(OPTION)

<modificateur>AjouterOption(OPTION):boolEnleverOption(OPTION):boolGetSesOptions() : liste(OPTION)

OPTION

Libellé : string

SesVoeuxDOptions

0..*{ordonné}

L’introduction de la contrainte{ordonné}

permet de traiter SesVoeuxDOptioncomme une liste

193

Diagramme de déploiement : exemple des portes (diagramme de spécification)

Serveur

SGBD

PC

Pilote

Portes

TX

RNIS

1

*

TCP/IP

Console

3 1

Maître

1

1..10

Imprimante

1

1

194

Diagramme de déploiement : exemple des portes (diagramme d’instances)

PC4 : PC

P2 :PorteP3 : Porte

P1 : Porte

Remarque : les instances sont soulignées.

195

La CBM (Computer Books by Mail) est une sociétéde distribution d'ouvrages d'informatique qui agitcomme intermédiaire entre les librairies et leséditeurs. Elle prend des commandes en provenancedes libraires, s'approvisionne (à prix réduit) auprèsdes éditeurs concernés et livre ses clients à réceptiondes ouvrages. Il n'y a donc pas de stockage. Seulesles commandes des clients solvables sont prises encompte.

Exemple de base

196

Le design pattern : State

ConcreteStateB

+Handle()

Context

+request(…)

ConcreteStateA

+Handle()

état

*

State

+Handle()1

200

U.M.L.

Unified Modeling Language

(3ème partie)


FIIFO4 2003-2004

201

Plan de la troisième partie

• Les diagrammes d’activités 139

• Les diagrammes de composants 149

• Les diagrammes de déploiement 153

• De l’analyse … à la conception 159

202

Booch


etc...


UML 0.9UML 0.9

1996

etc.ROOMCatalysis

OMGOMG

UML 1.1UML 1.1

Nov. 1997Nov. 1997

UML 1.3UML 1.3

UML 1.4UML 1.4

UML 2.0UML 2.0

Juin 1999Juin 1999

FinFin 200 20011

……

HOOD


1995

RationalRational

ROOM

Classe-Relation

Fusion

OOSE

Booch

OMT

Fin 1990

1. 2 u.m.l. unified modeling language (1 ère partie) françoise schlienger 4 ème année 2004-2005

Documents