Informatique S4-POO Programmation Orient´ee Objet

(1)

Informatique S4-POO

Programmation Orient´ ee Objet

— UML —

C´ edric Buche

Ecole Nationale d’Ing´ ´ enieurs de Brest (ENIB)

20 novembre 2013

C´edric Buche (ENIB) POO 20 novembre 2013 1 / 135

(2)

Plan

1 Introduction

2 Diagramme de classes (4 UC)

3 Diagramme de cas d’utilisation (1 UC)

4 Diagrammes d’interaction (2 UC)

(3)

Plan

1 Introduction

2 Diagramme de classes (4 UC)

3 Diagramme de cas d’utilisation (1 UC)

4 Diagrammes d’interaction (2 UC)

(4)

Objectifs du cours – pr´ erequis

Objectifs :

Connaˆıtre le langage de mod´ elisation UML

Comprendre la s´ emantique des principaux ´ el´ ements des diff´ erents mod` eles

Pr´ erequis :

Maˆıtriser les principes de la programmation orient´ ee–objet

(5)

Importance de la mod´ elisation

La niche, la maison familiale et l’immeuble

: quelques planches, des clous, un marteau et quelques outils.

: plans g´ en´ eraux, plans d’ex´ ecution d´ etaill´ es (pi` eces, ´ electricit´ e, plomberie, chauffage)

: planification d´ etaill´ ee, nombreux plans et ´ etudes

(6)

Importance de la mod´ elisation

La niche, la maison familiale et l’immeuble

: quelques planches, des clous, un marteau et quelques outils.

: plans g´ en´ eraux, plans d’ex´ ecution d´ etaill´ es (pi` eces,

´

electricit´ e, plomberie, chauffage)

: planification d´ etaill´ ee, nombreux plans et ´ etudes

(7)

Importance de la mod´ elisation

La niche, la maison familiale et l’immeuble

: quelques planches, des clous, un marteau et quelques outils.

: plans g´ en´ eraux, plans d’ex´ ecution d´ etaill´ es (pi` eces,

´

electricit´ e, plomberie, chauffage)

: planification d´ etaill´ ee, nombreux plans et ´ etudes

(8)

Pourquoi mod´ eliser ?

Mieux comprendre le syst` eme en d´ eveloppement

Appr´ ehender ces syst` emes dans leur enti` eret´ e → mod` eles de syst` emes complexes

(9)

Pourquoi mod´ eliser ?

Mieux comprendre le syst` eme en d´ eveloppement

Appr´ ehender ces syst` emes dans leur enti` eret´ e → mod` eles de syst` emes complexes

(10)

Pourquoi mod´ eliser ?

Mieux comprendre le syst` eme en d´ eveloppement

Appr´ ehender ces syst` emes dans leur enti` eret´ e → mod` eles de syst` emes complexes

(11)

Pourquoi mod´ eliser ?

Mieux comprendre le syst` eme en d´ eveloppement

Appr´ ehender ces syst` emes dans leur enti` eret´ e → mod` eles de syst` emes complexes

(12)

Introduction logiciel

Des logiciels au g´ enie logiciel

Etude projet informatique 16 % conformes 53 % d´ epassements 31 % abandon

⇒ G´ enie Logiciel

(13)

Des logiciels au g´ enie logiciel

Etude projet informatique 16 % conformes 53 % d´ epassements 31 % abandon

⇒ G´ enie Logiciel

(14)

Des logiciels au g´ enie logiciel

Etude projet informatique 16 % conformes 53 % d´ epassements 31 % abandon

⇒ G´ enie Logiciel

(15)

Des logiciels au g´ enie logiciel

Etude projet informatique 16 % conformes 53 % d´ epassements 31 % abandon

⇒ G´ enie Logiciel

(16)

1 Introduction

2 Diagramme de classes (4 UC)

3 Diagramme de cas d’utilisation (1 UC)

4 Diagrammes d’interaction (2 UC)

(17)

1 Introduction

2 Diagramme de classes (4 UC)

3 Diagramme de cas d’utilisation (1 UC)

4 Diagrammes d’interaction (2 UC)

(18)

UML : Unified Modeling Language

Langage graphique de mod´ elisation pour sp´ ecifier,

concevoir, construire, et documenter

des applications informatiques

Synth` ese des bonnes pratiques de l’ing´ enierie informatique Unification de mod` eles

Standardisation par l’OMG (Object Management Group)

(19)

Objectifs

Fournir un langage visuel et expressif Fournir des m´ ecanismes d’extension

Etre ind´ ependant des technologies et langages d’impl´ ementation Fournir une base formelle pour la mod´ elisation

(20)

3 axes de mod´ elisation

Approche classique - projet

1

Fonctionnel

Cahier des charges : diag. cas d’utilisation → sc´ enarios ´ ecrits Sc´ enarios formels : diag. seq / comm → objets/classes

2

Statique

classes : diag. classes

3

Dynamique

dynamique chaque objet : diag. ´ etats/transitions dynamique globale : diag. activit´ es

(21)

Pour quelles tˆ aches ?

Conception (

forward engineering

)

→ →

R´ etro conception (

reverse engineering

)

→

Documentation d’un syst` eme

→

(22)

Plan

1 Introduction

2 Diagramme de classes (4 UC)

3 Diagramme de cas d’utilisation (1 UC)

4 Diagrammes d’interaction (2 UC)

(23)

Plan

1 Introduction

2 Diagramme de classes (4 UC)

3 Diagramme de cas d’utilisation (1 UC)

4 Diagrammes d’interaction (2 UC)

(24)

Classe, attribut et op´ eration : notations

nommés Compartiment

identification, propriétés

Nom attribut1

attribut2 Compartiment

des attributs

operationB operationA operationC

Compartiment des opérations

nomElement1 nomCompartiment nomElement2

Compartiment(s) optionnels

(25)

Attribut : syntaxe

(26)

Attribut : syntaxe

(27)

Attribut : syntaxe

(28)

Attribut : syntaxe

(29)

Attribut : syntaxe

(30)

Attribut : syntaxe

(31)

Attribut : visibilit´ e

Accessibilit´ e : quels ´ el´ ements peuvent le r´ ef´ erencer ?

+ public tout ´ el´ ement qui acc` ede ` a la classe

# protected seul un ´ el´ ement de la classe ou de ses des- cendants

- private seul un ´ el´ ement de la classe

∼ package seul un ´ el´ ement du mˆ eme package que la classe

´

el´ ement : une classe qui r´ ef´ erence la classe consid´ er´ ee

(32)

Exemple

(33)

Op´ eration : syntaxe

(34)

Op´ eration : syntaxe

(35)

Op´ eration : syntaxe

(36)

Op´ eration : syntaxe

(37)

Op´ eration : syntaxe

(38)

Op´ eration : syntaxe

(39)

Op´ eration : syntaxe

(40)

Op´ eration : syntaxe

(41)

Op´ eration : syntaxe

(42)

Op´ eration : syntaxe

(43)

Op´ eration : direction des param` etres

information que l’objet serveur ne poss` ede pas, mais qui est n´ ecessaire ` a la r´ ealisation de l’op´ eration : direction = in information n´ ecessaire ` a la r´ ealisation de l’op´ eration et transform´ ee par celle-ci : direction = inout

information produite par l’ex´ ecution de l’op´ eration, donc inexistante avant ; direction = out ou return

(44)

Exemple

(45)

Exemple

(46)

Types

Réalisation

Association Généralisation Dépendance

(47)

Relation de d´ ependance entre classes (classifier )

<<use>>

A B

client serveur (fournisseur)

Indique une d´ ependance entre les propri´ et´ es

d’une classe (le client) et une autre classe (le serveur, supplier) En cons´ equence, une modification du serveur peut affecter le comportement du client

Exemples :

une op´ eration de la classe A fait appel ` a une op´ eration de la classe B une op´ eration de A a comme param` etre un objet B

(48)

Exemple de d´ ependance entre classes

(49)

St´ er´ eotypes de d´ ependance entre classes

access import du contenu d’un autre package create la classe cr´ ee des instances d’une autre

classe

instantiate la m´ ethode d’une classe cr´ ee des instances d’une autre

permit donne acc` es aux ´ el´ ements priv´ es use un ´ el´ ement requiert un autre ´ el´ ement

(50)

G´ en´ eralisation – sp´ ecialisation

Généralisation

+ operation1(in arg1: integer)

CA

CB

Spécialisation

+ operation1(in arg1: integer) redéfinition

d’une opération

A

AA AB

ABA ABB ABC

Héritage

Dérivation

Sous−classe

classe dérivée Super−classe

(51)

G´ en´ eralisation – sp´ ecialisation : exemple

(52)

G´ en´ eralisation : vocabulaire

A est une sp´ ecialisation de B A est une sous-classe de B

A d´ erive de B

A h´ erite de B

B est une g´ en´ eralisation de A B est une super-classe de A

(53)

Association : principe

(54)

Association : rˆ oles

nomRoleB

A R B

nomRoleA

nomRole : indique ce que repr´ esente l’ensemble des instances associ´ ees

`

a une instance de la classe par la relation R.

L’acc` es peut ˆ etre +, # ou -

nomRoleB nom de l’ensemble des instances de la classe B qui sont en relation avec 1 instance de la classe A par la relation R.

nomRoleA nom de l’ensemble des instances de la classe A qui sont en relation avec 1 instance de la classe B par la relation R.

(55)

Association : multiplicit´ es

multB

A R B

multA

valeurs possibles du cardinal de l’ensemble des instances associ´ ees ` a une instance de la classe par la relation R.

multB cardinal de l’ensemble des instances de la classe B qui sont en relation avec 1 instance de la classe A par la relation R.

multA cardinal de l’ensemble des instances de la classe A qui sont en relation avec 1 instance de la classe B par la relation R.

(56)

Multiplicit´ e : notation

notation : min .. max abreg. signification

1..1 1 exactement 1

0..1 – z´ ero ou un (optionnel) 0..* * aucun ou plusieurs

1..* – au moins 1

n..m, p – entre n et m ou exactement p

(57)

Association unidirectionnelle

(58)

Contraintes sur une association

enseignants

CA R CB

0..1 0..*

collection

{ordered}

Promotion Personne

0..1 2..*

{subset}

delegues eleves

2 0..1

Etablissement Personne

* {or}

eleves

* 0..1

ecole 1

residenceAdministrative

(59)

Types d’association

R1

Agrégation B2

A2

R2

Agrégat élément

Composition

A3 R3 B3

Composant Composite

Association A1 B1

(60)

Agr´ egation

Agr´ egation : association simple + contraintes d’int´ egrit´ e + graphe acyclique + ´ el´ ements partageables

(61)

Composition

Composition : agr´ egation + contrainte de dur´ ee de vie + composants non partageables

(62)

Agregation/composition : exemple

(63)

Agregation/composition : exemple

(64)

Package

grouper dans des ensembles coh´ erents.

structurer les diagrammes et donnent une vision globale plus claire.

(65)

Navigation

pkg1

AA

AB

BB

CC +c1

0..1 0..1

+op1()

#op2() -op3()

#b2 0..1 +b1 0..1

-b3 0..1

#c2

(66)

Classe abstraite

Propri´ et´ e optionnelle d’une classe

D´ efinition :

classe non instanciable

ensemble de propri´ et´ es communes ` a diff´ erentes classes mais partiellement d´ efinies.

donc, seuls des objets d’une classe d´ eriv´ ee sont instanciables

Deux raisons :

1

bien que l’instanciation d’un tel objet serait possible cela n’aurait pas de sens

ex. Personne – Eleve – Prof

2

au moins une des propri´ et´ es de la classe n’est pas d´ efinie ex. Shape op´ eration draw

Notation :

<< abstract >> : tagged-value plac´ ee apr` es le nom de la classe NomClass : en italique

(67)

Attribut d´ eriv´ e

sa valeur se calcule ` a partir d’autres proprietes de la classe (attributs ou autres)

symbolis´ es par l’ajout d’un

/

devant leur nom

(68)

Interface

+ operationB + attribut1

+ attribut2 être maintenues

signal1

reception signal2

éventuellement un protocole + description de services

<<interface>>

Nom

Variables d’état devant

Services + operationA

(69)

Relation de r´ ealisation : entre classes et interfaces

realisation

CA IB

<<interface>>

service1 service2 service2

service1 operationA attr1

(70)

Interface : Exemple

(71)

Relations avec une interface

I7

<<interface>>

I1 <<interface>> I2

<<interface>>

I2

<<interface>>

I3 I4

CA I5 CA I5

<<interface>>

I3 I4

I1

CB I6 CB I6

I7 CD

CC CD CC

(72)

Interface : exemple

saisie mot de passe

<< uses >>

Password Ilog

description symbolique de l’interface

source de l’interface

symbole de l’interface

lien d’utilisation

(73)

Classe–association

cas particuliers d’association

Classe−association

A ^mB B

mA R

rA rB

C

L’association entre les classes A et B est r´ ealis´ ee par un objet de la classe C (sous sa responsabilit´ e)

la classe C a des propri´ et´ es qui lui sont propres (attributs, op´ erations...)

(74)

Classe–association

exemple

(75)

Association qualifi´ ee

R A

mA

rA

B valeurClé: TypeClé

^mB

rB

Cl´ e : attribut de la relation R permettant de d´ efinir (qualifier) le sous-ensemble des instances de la classe B (rˆ ole rB) associ´ ees ` a 1 instance de la classe A

le couple (Instance de A, valeur Cl´ e) identifie le sous-ensemble rB.

Multiplicit´ e : mB = cardinal de rB Exemple : annuaire invers´ e

(76)

Association qualifi´ ee : exemple

Entreprise

Personne emploie

1 .. *

sans qualifiant

Personne emploie

1 .. *

avec qualifiant 1 .. * fonction Entreprise

Fichier Repertoire

Fichier

contient

1

avec qualifiant Repertoire

contient 1 .. *

*

sans qualifiant

nom fich

*

(77)

Association qualifi´ ee

exemple

(78)

Association qualifi´ ee

exemple

(79)

Diagramme de classes (4 UC) Elaboration

D´ emarche pour bˆ atir une diagramme de classes (1/2)

1

Trouver les classes du domaine ´ etudi´ e En collaboration avec un expert du domaine.

Les classes correspondent g´ en´ eralement ` a des concepts ou des substantifs du domaine.

2

Trouver les associations entre classes

Les associations correspondent souvent ` a des verbes, ou des

constructions verbales, mettant en relation plusieurs classes, comme

est compos´ e de

,

pilote

,

travaille pour

.

Attention, m´ efiez vous de certains attributs qui sont en r´ ealit´ e des relations entre classes.

(80)

Diagramme de classes (4 UC) Elaboration

D´ emarche pour bˆ atir une diagramme de classes (2/2)

3

Trouver les attributs des classes

Les attributs correspondent souvent ` a des substantifs, ou des groupes nominaux, tels que

la masse d’une voiture

ou

le montant d’une transaction

.

Les adjectifs et les valeurs correspondent souvent ` a des valeurs d’attributs.

4

Organiser et simplifier le mod` ele

En ´ eliminant les classes redondantes et en utilisant l’h´ eritage.

5

V´ erifier les chemins d’acc` es aux classes

6

It´ erer et raffiner le mod` ele

Un mod` ele est rarement correct d` es sa premi` ere construction.

(81)

Plan

1 Introduction

2 Diagramme de classes (4 UC)

3 Diagramme de cas d’utilisation (1 UC)

4 Diagrammes d’interaction (2 UC)

(82)

Plan

1 Introduction

2 Diagramme de classes (4 UC)

3 Diagramme de cas d’utilisation (1 UC)

4 Diagrammes d’interaction (2 UC)

(83)

Exprimer les besoins

Comment donner un moyen simple d’exprimer les besoins d’utilisateurs non informaticiens ?

Premi` ere ´ etape UML d’analyse d’un syst` eme

(84)

Exigences fonctionnelles

Mod` ele construit en phase de d´ efinition des exigences fonctionnelles et enrichi pendant la phase d’analyse en utilisant d’autres mod` eles (entre-autres les mod` eles d’interaction)

Objectifs :

1

identifier les fonctionnalit´ es du logiciel

2

en d´ efinir le p´ erim` etre

3

identifier les ´ el´ ements externes en interaction directe

(85)

Diagramme de cas d’utilisation (1 UC) El´ements des diagrammes

Acteur

D´ efinition :

rˆ ole jou´ e par une entit´ e externe qui interagit avec le syst` eme il peut consulter et/ou modifier l’´ etat du syst` eme par messages

Comment les identifier ? utilisateurs humains

syst` emes connexes qui interagissent ´ egalement avec le syst` eme

Comment les repr´ esenter ?

Acteur3

<<actor>>

Acteur3

symbole

Acteur1

stick man mot−clef

Exemple : Client, Conseiller financier, SI Banque ...

(86)

Cas d’utilisation

D´ efinition :

S´ equences d’actions r´ ealis´ ees par le syst` eme (r´ esultat observable pour un acteur)

Comportement attendu (6= mode de r´ ealisation) : ce que le futur devra faire

pas comment il le fera

(87)

Cas d’utilisation

Comment les identifier ?

Ensemble des cas utilisation == exigences fonctionnelles du syst` eme Un cas == fonction m´ etier selon le point de vue des acteurs

Pour chaque acteur :

rechercher ses utilisations m´ etiers

d´ eterminer dans le cahier des charges les services attendus Nommez les cas d’utilisation (point de vue acteur) :

verbe ` a l’infinitif + compl´ ement

Comment les repr´ esenter ?

Exemple : Consulter un compte, Retirer de l’argent, D´ eposer un ch` eque ...

(88)

Cas d’utilisation et acteurs

Nom_sujet

Nom_acteur_1 Nom_acteur_2

Nom_cas_utilisation_1

Nom_cas_utilisation_2

Acteur :

´

el´ ement externe en interaction directe avec le sujet Cas d’utilisation :

ensemble fonctionnel coh´ erent, identifiable ext´ erieurement et fourni par un classeur (le sujet)

Association Acteur – Cas :

chemin de communication indiquant la participation de l’acteur

`

a la r´ ealisation du cas

(89)

Association : Exemple

(90)

Acteurs principaux et secondaires

Un acteur est qualifi´ e de principal pour un cas d’utilisation lorsque ce cas rend service ` a cet acteur.

Les autres acteurs sont alors qualifi´ es de secondaires.

Un cas d’utilisation a au plus un acteur principal.

Le st´ er´ eotype

primary

vient orner l’association reliant un cas d’utilisation ` a son acteur principal

Le st´ er´ eotype

secondary

est utilis´ e pour les acteurs secondaires

(91)

Acteurs principaux et secondaires : Exemple

(92)

Types et repr´ esentation

CB3

CA1 CB1

<<include>>

CA2 CB2

<<extend>>

CA3

CA1 inclut CB1 1 r´ ealisation de CA1

⇒ 1 r´ ealisation de CB1 CA2 ´ etend CB2

dans un certain contexte Selon le contexte,

on r´ ealise soit CA2, soit CB2 CA3 sp´ ecialise CB3

Selon le contexte,

on r´ ealise soit CA3, soit CB3

(93)

Exemple relation d’inclusion

Le cas inclus est ajout´ e obligatoirement au cas de base

(94)

Exemple relation d’inclusion

Identifier une partie commune aux diff´ erents cas d’utilisation et de la factoriser dans un nouveau cas inclus dans ces derniers.

(95)

Exemple relation d’extension

Enrichir un cas d’utilisation par un autre, cependant, cet enrichissement est optionnel.

(96)

Exemple relation d’extension

L’extension se fait dans le cas d’utilisation de base, en un point pr´ ecis appel´ e point d’extension

(97)

Exemple relation G´ en´ eralisation/Sp´ ecialisation

Formaliser les variations importantes sur le mˆ eme cas d’utilisation

(98)

Exemple complet

(99)

G´ en´ eralisation

La seule relation possible entre deux acteurs est la g´ en´ eralisation un acteur A est une g´ en´ eralisation d’un acteur B si l’acteur A peut ˆ etre substitu´ e par l’acteur B

tous les cas d’utilisation accessibles ` a A le sont aussi ` a B, mais l’inverse n’est pas vrai.

(100)

G´ en´ eralisation : Exemple

(101)

Sc´ enario

D´ efinition :

succession particuli` ere d’enchaˆınements s’ex´ ecutant du d´ ebut ` a la fin du cas

Un cas d’utilisation contient : un sc´ enario nominal

plusieurs sc´ enarios alternatifs (qui se terminent normalement) plusieurs sc´ enarios d’erreur (qui se terminent par un ´ echec)

(102)

En pratique ...

La fiche de description textuelle d’un cas d’utilisation n’est pas normalis´ ee...

Cependant, on peut utiliser la structuration suivante :

Sommaire d’identifica- tion (obligatoire)

Inclut titre, r´ esum´ e, dates de cr´ eation et de modification, version, responsable, acteurs ...

Description des sc´ enarios (obligatoire)

D´ ecrit le sc´ enario nominal, les sc´ enarios d’erreur, les pr´ e/post- conditions

Exigences non- fonctionnelles (op- tionel)

Ajoute, si c’est pertinent, les infor- mations suivantes : fr´ equence ; dis- ponibilt´ e, fiabilit´ e, confidentialit´ e ...

(103)

Exemple sc´ enario

Sommaire Sc´ enario nominal

R´ eserver un v´ ehicule

Description 1. Le client saisit son code et son login d’identification 2. Le syst` eme v´ erifie le code et le login d’identification

3. Le syst` eme demande au client de saisir les informations sur la r´ eservation

4. Le client saisit les informations sur la r´ eservation

5. Le syst` eme interroge l’acteur syst` eme bancaire pour v´ erifier l’acompte

6. Le syst` eme bancaire donne une r´ eponse favorable

7. Le syst` eme envoie au client, un message de confirmation de la demande

(104)

Exemple sc´ enario

Sommaire Sc´ enario alternatif

R´ eserver un v´ ehicule

Description SA1 : code d’identification erron´ e pour la premi` ere ou la deuxi` eme fois

SA1 d´ emarre au point 2 du sc´ enario nominal

3. Le syst` eme indique au client que le code est erron´ e, pour la premi` ere ou la deuxi` eme fois.

Le sc´ enario nominal reprend au point 1.

(105)

Exemple sc´ enario

Sommaire Sc´ enario d’erreur

R´ eserver un v´ ehicule

Description SE1 : code d’identification erron´ e pour la troisi` eme fois SE1 d´ emarre au point 2 du sc´ enario nominal

3. Le syst` eme indique au client que le code est erron´ e pour la troisi` eme fois.

Le cas d’utilisation se termine en ´ echec (l’objectif n’est pas at- teint).

(106)

Quand utiliser les cas d’utilisation ?

En phase d’´ elaboration

En discutant avec les utilisateurs

Remarque : Un projet de 10 ann´ ees-hommes devrait comprendre environ 12 cas d’utilisation ¹

1. R´ esulat issu d’une commission de l’OOPSLA

(107)

Plan

1 Introduction

2 Diagramme de classes (4 UC)

3 Diagramme de cas d’utilisation (1 UC)

4 Diagrammes d’interaction (2 UC)

(108)

Plan

(109)

Du diag. de cas d’utilisation au diag. d’interactions

diag. cas d’utilisation → sc´ enarios sc´ enario → diag. seq/comm

(110)

Cas d’utilisation Piloter

sc´ enario nominal pourrait ˆ etre : un pilote d´ emarre une voiture ce qui allume un moteur.

Comment formaliser les communications entre instances (d´ emarrer, allumer) ? → diag. de communication.

Comment formaliser le s´ equencement des interactions (1 : d´ emarrer ; 2 : allumer) ? → diag. s´ equence.

Avant cela, il faut repr´ esenter les instances (objets) (un pilote, une voiture, un moteur)

(111)

Objet : instance de classifier

nom d’instance : nom de classe Exemple

jean : Personne pierre : Personne

(112)

Objets : instances de classifier

:NomActeur nomObjet:nomClasse

attr1 = valeur1

nomObjet: :NomClasse

<<stereotype>>

:NomClasse

nomObjet:NomClasse

nomObjet:nomClasse [etat]

(113)

Diagramme de s´ equence : dur´ ee de vie et flots

lignes de vie message

objets

flots d’exécution

objet1: objet2:

temps (logique) : séquencement

(114)

Messages

l’envoi d’un signal ;

l’invocation d’une op´ eration ;

la cr´ eation ou la destruction d’une instance.

(115)

Messages asynchrones

(116)

Messages synchrones

(117)

Messages de cr´ eation et destruction d’instance

(118)

Ev´ ´ enements et messages

(119)

Syntaxe des messages et des r´ eponses

(120)

Syntaxe des messages et des r´ eponses

(121)

Ex´ ecution de m´ ethode et objet actif

(122)

Ex´ ecution de m´ ethode et objet actif

(123)

Diagramme de s´ equence : fragements d’interaction combin´ es

Articulation d’interactions par des op´ erateurs : choix et boucle : alternative, option, break, loop

contrˆ ole d’envoi en parall` ele de messages : parallel, critical region

contrˆ ole d’envoi de messages : ignore, consider, assertion, negative

ordre d’envoi des messages : weak sequencing, strict sequencing

(124)

Diagramme de s´ equence : structures de contrˆ ole

[else]

sd nom seq ref seqA

alt

ref

ref [condition]

(125)

Diagramme de s´ equence : structures de contrˆ ole (exemple)

(126)

Diagramme de s´ equence : structures de contrˆ ole (exemple)

(127)

Diagramme de s´ equence : structures de contrˆ ole (exemple)

(128)

Diagramme de s´ equence : structures de contrˆ ole (exemple)

(129)

Diagramme de s´ equence : structures de contrˆ ole (exemple)

(130)

Diagramme de s´ equence : parall´ elisme et s´ equencement

strict sd nom seq

par

(131)

Diagramme de s´ equence : parall´ elisme et s´ equencement

(132)

Diagramme de s´ equence : parall´ elisme et s´ equencement (exemple)

(133)

Diagramme de s´ equence : parall´ elisme et s´ equencement (exemple)

(134)

Diagramme de s´ equence : section critique (exemple)

(135)

Diagramme de s´ equence : Ignorer (exemple)

(136)

Diagramme de s´ equence : Consid´ erer (exemple)

(137)

Diagramme de s´ equence : N´ egatif (exemple)

(138)

Diagramme de s´ equence : invariants d’´ etat

msg2

obj1 obj2 obj3

msg1 sd nom seq

etat2 etat1

(139)

Diagramme de communication : Lignes de vie

Les lignes de vie sont repr´ esent´ ees par des rectangles contenant une ´ etiquette dont la syntaxe est :

[<nom du r^ ole>] : [<Nom du type>]

(140)

Diagramme de communication : Connecteurs

Les relations entre les lignes de vie sont appel´ ees connecteurs se repr´ esente par un trait plein reliant deux lignes de vies les extr´ emit´ es peuvent ˆ etre orn´ ees de multiplicit´ es.

(141)

Communication : interactions entre objets par messages

struct. controle

message

(arguments)

arg1, arg2 évaluable dans prédécesseur condition séquence valeur_retour := nom

seq1, seq2/

liste labels séquence /

expression logique

récurrence label

nombre (séq.) nom (parall.)

*[iteration]

*[condition] contexte courant

(142)

Messages : structures de contrˆ ole — exemples

condition r´ ecur. message [x > 0] : msg()

∗ : msg()

∗ [x > 0] : msg() [x > 0] ∗ [i := 1..n] : msg()

(143)

Diagramme de communication : exemple

(144)

Diagramme de communication : exemple

(145)

Diagramme de communication : exemple

(146)

Diagramme de communication : exemple

(147)

Diagramme de communication : exemple

(148)

Diagramme de communication : exemple

(149)

Diagramme de communication : exemple

(150)

Diagramme de communication : exemple

(151)

Diagramme de communication : exemple

(152)

Diagramme de communication : exemple

(153)

Diagramme de communication : exemple

(154)

Diagramme de communication : exemple

(155)

Lien avec le diagramme de classes

diag. cas d’utilisation → sc´ enarios sc´ enario → diag. seq/comm diag. seq/comm → diag. classe

(156)