Méthodologie de Conception gp Orientée Objet des …...Objectifs du module Conception OO Les objectifs visés consistent à permettre aux étudiant de: Savoir mettre en œuvre les

Institut Supérieur d’Administration des Affaires SfaxConception Orientée Objet

Méthodologie de Conception des Affaires-SfaxConception Orientée Objet

g pOrientée Objet des Systèmes

d’informationd information

Mohamed Amine CHAÄBANEISAA-SFAX

Rafik BOUAZIZ Faïez GARGOURIRafik BOUAZIZ -- Faïez GARGOURIFSEG-SFAX ISIM- SFAX

1M.A.CHAÂBANE -- R. BOUAZIZ -- F. GARGOURI

Plan du module COOSI

I. Introduction aux méthodes de conception OOII. Diagrammes de classes et diagrammes d’objetsIII. Diagrammes d’Etat-TransitionsgIV. Diagrammes de cas d’utilisation (use cases)V. Diagrammes de collaborationgVI. Diagrammes de SéquencesVII. Diagrammes d’activitésg

2M.A.CHAÂBANE -- R. BOUAZIZ -- F. GARGOURI 2

Objectifs du module Conception OO

Les objectifs visés consistent à permettre aux étudiant de:

Savoir mettre en œuvre les concepts de l’OrientéObjet (OO) pour la modélisation des Systèmed’I f id’Information.

Connaître UML et maîtriser le construction de sesprincipaux diagrammes.

Connaître le Processus Unifié pour l’aide à lapconstruction des SI.


Institut Supérieur d’Administration des Affaires Sfax

Conception Orientée Objetdes Affaires-Sfax

p j

I. Introduction aux méthodes de conception OOde conception OO

Mohamed Amine CHAÄBANEMohamed Amine CHAÄBANEISAA-SFAX

Rafik BOUAZIZ Faïe GARGOURIRafik BOUAZIZ -- Faïez GARGOURIFSEG-SFAX ISIM- SFAX


I. IntroductionI.1. Systèmes d’information et Méthodes de C ti

Système d'Information (SI) :Conception

- Système : ensemble de composants travaillant en collaboration pour accomplir des tâches bien définiescollaboration pour accomplir des tâches bien définies.

- Information : nécessitant différents traitements :. collecte, vérification, validation, représentation, .... codage, affinage, stockage, manipulation, .... codage, affinage, stockage, manipulation, ...


SI et Méthodes de ConceptionLe développement d’un SI nécessite :

- des méthodes d'analyse et de conception (MERISE, OMT,HOOD, …),

des environnements de programmation (classique modèle- des environnements de programmation (classique, modèlerelationnel, OO, …).

Dans [Galacsi 1984] un SI est définiDans [Galacsi 1984], un SI est définicomme : « l'ensemble des moyens, humains etmatériels, et les méthodes se rapportant au traitement desmatériels, et les méthodes se rapportant au traitement desdifférentes formes d'information rencontrées dans lesorganisations ».


SI et Méthodes de ConceptionUne méthode est composée de :+ U bl d dèl i t d i t d

p

+ Un ensemble de modèles exprimant des points de vuedifférents.

+ Un ensemble de concepts, et leurs règles d’utilisationpermettant la représentation des modèles.

+ Un ensemble d’étapes successives : des démarches.

Une méthode =

un langage (concepts + modèles + règles d’utilisation)+ des démarches


+ un outil logiciel

Concepts orientés objet

I.2. Concepts orientés objetL’OBJET

Est un élément du réel à modéliser :La facture 100567, la personne Ali, le cours COOSI.

Possède sa propre identité : OID (Object Identifier) :p p ( j )OID : est une valeur indépendante des valeurs despropriétés de l’objet.OID : Attribuée par le système et elle est totalementtransparente à l’utilisateur.



L’OBJET (suite)Peut avoir plusieurs états durant son cycle de vie :

Etat d’un objet : situation significative que peut d d f dprendre un objet, déterminée en fonction des

valeurs des différents attributs et liens de l’objet.C l d i l ét t t d bj t Cycle de vie : les états que peut prendre un objet, entre sa création et sa suppression, et les conditions de passage d’un état à un autre.conditions de passage d un état à un autre.

Exemples :La facture 100567 : {100567, 27/1/2005, ...}{ , / / , }Les états que peut prendre une facture : {saisie, en attente de livraison, livrée, soldée, …}


{saisie, en attente de livraison, livrée, soldée, …}

9


La CLASSERegroupe un ensemble d'objets semblables :

les mêmes propriétés structurelles (attributs) ;les mêmes propriétés structurelles (attributs) ;le même comportement (opérations, méthodes) ;les mêmes relations avec les autres objets ;les mêmes relations avec les autres objets ;et ayant un intérêt pour l'application.

Encapsule les données et les traitements :Encapsule les données et les traitements :La classe Facture : {NumFacture, DateFacture, …, Imprimer(), Solder(), ...}.p (), (), }



La CLASSE (suite)

Exemple :

CLASSE PersonneAttributsAttributs

Nom : Chaîne; Prénom : Chaîne; Age : entierOpérationsOpérations

Créer(); Supprimer()FIN CLASSE PersonneFIN CLASSE Personne.


Concepts orientés objetp jL’ENCAPSULATION

Est un principe qui consiste à :

cacher les données et les détails d'implantation (algorithmes) et

laisser visible la partie interface (signatures des laisser visible la partie interface (signatures des opérations publiques) des classes.


Concepts orientés objetExemple :

Considérons la classe COMPTE suivante :CLASSE ComptePROPRIETES Programme utilisateur :Numéro : Integer ... a = Lire(NuméroCompte); S ld I t b C l l I té êt( )Solde : Integer b = CalculerIntérêt(a);METHODES Partie invisible à l’utilisateur : Créer() CalculerIntérêt(x: integer){Créer() CalculerIntérêt(x: integer){ CalculerIntérêt() return (x.solde*4%) }

FIN CLASSE CompteFIN CLASSE Compte

En cas de changement du taux d’intérêt,


g ,le programme utilisateur reste identique


L’HERITAGEEst un mécanisme permettant le partage descaractéristiques d’une classe (généralisation) par uneq (g ) pou plusieurs autres classes (spécialisations).

Héritage simple

Personne Nom, Prénom, Adresse, ...

Enseignant Etudiant Cours, Diplôme, ... Année, ...

Héritage multiple Etudiant_Enseignant Numéro, TD, ...



LE POLYMORPHISMEEst la capacité d’une méthode héritée à être appliquée sur des objets de types différents.des objets de types différents.

Afficher() Objet

Entête FenêtreAffi h () Affi h ()

L’opération Afficher() s’applique : à une fenêtre et à uneentête

Entête FenêtreAfficher() Afficher()

entête


Concepts Orientée objet

Les différents points de perception d’un systèmeLa vision statique :

Description des entités représentant l’univers de discours et de leurs relations. De quoi est fait le système ?

La vision dynamique :Description des évolutions, dans le temps, des entités représentant l’univers de discoursreprésentant l univers de discours.Comment peut-il évoluer ?

La vision fonctionnelle :Description du fonctionnement (des différentes fonctionnalités) du système.


fonctionnalités) du système.Comment fonctionne-t-il ?

16

Concepts Orientée objet

Modèle statique

Décrire les objets :structures de données

Modèle statique

Décrire comment contrôler les. structures de données. opérations. liens entre les classes

Décrire comment contrôler lesévolutions, dans le temps,

des objets du systèmeModèle

dynamique

Décrire le fonctionnementdu système

Modèle fonctionnel

y


Introduction à UML

I.3. Introduction à UMLDurant les dernières décennies, plus d’une cinquantaine de

méthodes objet ont été proposées :

Les méthodes inspirées et dédiées à un langage de programmation :

HOOD [H it 1989] ADAHOOD [Heitz 1989] pour ADA.

OOD [Booch 1991] pour Smalltalk.


Introduction à UML

Les méthodes inspirées et dédiées aux applications é ltemps réel :

OOAD [Shlear 1991].OOSE [J b 1992] OOSE [Jacobson 1992].

Les extensions de méthodes classiques : OMT [Rumbaugh 1991].OOM [Bouzeghoub 1994], [Morejon 1994].

Les méthodes purement orientées objets :O* [Brunet 1993].MCO [Castellani 1993].


Introduction à UML

Suite à cette multitude de propositions :p p

divers concepts sont utilisés,

divers modèles proposés,

diverses démarches suivies,

diverses notations graphiques supportées,

diverses sémantiques accordées aux mêmes concepts.


Introduction à UML

UNE JUNGLE UNE JUNGLE MÉTHODOLOGIQUE

Plusieurs propositions de méthodes unifiées :Fusion Eurométhode Fusion, Eurométhode, …Le résultat : une nouvelle méthode et non une méthode unifiée


Introduction à UML

Un besoin d’unification:

Unified …

P l déli ti Pour la modélisation :Modelling …

Sous forme de langage :

Language …

UML


Remarque : Pourquoi langage et non méthode ?

Introduction à UML

UML :

Regroupe les plus récentes propositions :Concepts de modélisation des données Concepts de modélisation des données. Modélisation des processus d’affaires (WorkFlow).Modélisation objetModélisation objet.Modélisation des composants.

Peut être associé à toute démarche de conception :à n’importe quelle étape de la démarche,p q p ,avec différents environnements de programmation.


Introduction à UML

Unification des concepts et des modèles dei i l t t i éth dprincipalement trois méthodes connues :

OOD (Object-Oriented Design)de Grady BOOCH.

OMT (Object Modelling Techniques)de James RUMBAUGH.

OOSE (OO Software Engineering)de Ivar JACOBSON.


La Genèse d’UML UML 3.0 2005 : On parle de UML 3.0

2003 : Publication d’UML 2.0

Infrastructure plus solideRenforcement de l’approche par composantsUML 2.0

UML 3.0

2000-2002 : Publication d’UML 1.4

1999 : Standardisation par l’OMG Guide de l’utilisateur

Apparition de MDA(Model Driven Architecture)UML 1.4

1999 : Standardisation par l’OMG

1997 : Soumission à l’OMG(Object Management Group) Spécifications disponibles

Guide de l utilisateurManuel de référenceGuide du processus

UML 1.0

UML 1.3

(Object Management Group)

OOPSLA ‘96

Spécifications disponibles sur le web

UML 0.9

UML 1.0

OOPSLA ‘95

Booch ’93 OMT-2 ’94

Méthode Unifiée 0.8PartenairesIndustriels

Autres méthodes

Booch ’91 OMT-1(Rumbaugh)

OOSEJacobson ’92


Principales étapes d'élaboration d'UML

Introduction à UML

DiagrammeUML 2.0 13 diagrammes

Diagramme de structure

Diagramme comportemental

Diagramme d’objets

Diagramme de package

Diagramme d’activités

Diagramme de cas d’utilisation

Diagramme de composants

Diagramme de classes

Diagramme de structure composite

Diagramme de déploiement

Diagramme de transition d’état

Diagramme d’interactions

Diagramme de é

Diagramme vue d’ bl d

Chacun représente t ti li séquence

Diagramme de communication

d’ensemble des interactions

Diagramme de timing

un aspect particulier du SI à modéliser


Introduction à UML

Diagrammes de structurede quoi est fait le système ?

Vue statique :Vue statique :

Diagramme de classes (UML 1) : décrit les classes et leurslrelations.

Diagramme d’objets (UML 1) : présente des instances deg jclasses et de relations.

Diagramme de package ou de paquetage ou de paquetsDiagramme de package ou de paquetage ou de paquets(UML 2) : regroupe des classes, des cas d’utilisation ou despaquets pour renforcer la modularité et la cohérence du


paquets, pour renforcer la modularité et la cohérence dumodèle global.

27

Introduction à UML

Diagramme de structure composite ou d’architecture(UML 2) : montre la décomposition hiérarchique d’une classe complexe en parties internes, avec des ports d’interfaces externes, lors de l’exécution.,

Diagramme de composants (UML 1) : décrit l’architecture d’un logiciel en terme de modules et montre les dépendances g pde compilation ou d’exécution entre ces modules.

Diagramme de déploiement (UML 1) : décrit les unités de g p ( )programmes et leurs processus d’affectation. Il montre la disposition des matériels et la répartition des composants sur ces matériels.


Introduction à UML

Diagrammes comportementauxComment se comporte le système ?

Vue fonctionnelle :Vue fonctionnelle :Diagramme de cas d’utilisation (UML 1) : décrit lesfonctionnalités du système et les interactions avec lesfonctionnalités du système et les interactions avec lesutilisateurs.

Vue dynamique :Vue dynamique :Diagramme d’états-transitions (UML 1) : décrit le cycled i d’ bj t (ét t t t iti )de vie d’un objet (états et transitions).

Diagramme de timing (UML 2) : montre l’évolution del’ét t d’ bj t d’ d’ bj t f ti


l’état d’un objet ou d’un groupe d’objets en fonctiond’événements temporels.

29

Introduction à UML

Diagramme de séquence ou d’interaction (UML 1) :représente les interactions entre les objets d’une manièreordonné dans le temps.

Diagramme de communication ou de collaboration (UML 1)

: décrit les interactions entre les objets en montrant les liens: décrit les interactions entre les objets, en montrant les liens.

Diagramme d’activités (UML 1) : décrit les activités et lesDiagramme d activités (UML 1) : décrit les activités et lesméthodes en termes d’actions, en montrant le comportementprocédural et parallèle.procédural et parallèle.

Diagramme de vue d’ensemble des interactions (UML 2) :Mi d di d’ ti ité t d di d é


Mixage du diagramme d’activités et du diagramme de séquence.

30

Conception Orientée ObjetConception Orientée Objet

II. Diagrammes de classes et Diagrammes d’objetset Diagrammes d objets

Mohamed Amine CHAÄBANEISAA-SFAX

Rafik BOUAZIZ Faïez GARGOURIRafik BOUAZIZ -- Faïez GARGOURIFSEG-SFAX ISIM- SFAX


Introduction

Diagramme de classesDiagramme de classesDiagramme central du modèle du SI.Montre les classes et leurs relations statiques.Le plus riche en notations.L’équivalent du modèle E-A.équ a e t du odè eLes erreurs dans ce diagramme ont souvent

i t l t diun impact sur les autres diagrammes.


Concept de classe

Avec UML, une classe :est représentée par un rectangle avec :

Attributs etopérations. NOM DE CLASSE

AttributsopérationsExceptionsExceptions

Classe = Attributs + Opérations + Mécanisme d’instanciation (Constructeur)


Concept de classe

Pour une classe :On peut :

ne pas représenter ses attributs et/ou ses opérationssur un diagramme,

un filtre visuel pour donner un certain niveau d'abstraction à son modèle ; on peut se limiter aux noms des classes ;

ne pas spécifier les niveaux de protection des membres d'une classe,

ne veut pas dire que l'on ne représente que les membres publics.


Concept de classe

Remarque : Par abus de langageRemarque : Par abus de langageAttribut = propriété = donnée-membre, …

O é i é h d f i bOpération = méthode = fonction-membre, …


Concept de classe

Pour une classe :Le nom de la classe, selon la norme UML est en gras,gras, mais on peut se limiter à l’écrire en majuscule.

U tt ib t d’ l tit élé t dUn attribut d’une classe constitue un élément de l'état de ses objets,

participe à la caractérisation des objets.

Une opération représente un service spécifiqueoffert par les objets de la classe.


Concept de classe

Les attributs et les opérations :Les attributs et les opérations :sont décrits dans le deuxième et troisième

ti tcompartiments.

NOM DE CLASSE

NomAttribut [: type [= valeur initiale] ]

Opération ()


Concept de classe

Exemple :Nom

p

DateDeRéceptionCOMMANDE

Attributs DateDeRéceptionEstPrépayéeLignes

Attributs

Expédier()F ()

PrixOpérations

Fermer()


Concept de classe

Commentaire ou note :Commentaire ou note :Commentaire

COMMANDEDateDeRéceptionEstPrépayéeLignesPrix

t iCommentaireExpédier()Fermer()

-- commentaire-- Commentaire


Fermer()


Les diagrammes d’objets ou d’instances :Les diagrammes d objets ou d instances :présentent l’état d’un système à un instant donné,

montrent :des objets (instances de classes) dans un état

ti li tparticulier et des liens (relations sémantiques : instances d’associations) entre ces objetsd associations) entre ces objets,

facilitent la compréhension des structures de données complexesdonnées complexes,

servent durant la phase exploratoire de l’analyse.



Représentation des objets :p j

N Obj t N Obj t CLASSE CLASSE

Objet anonyme

Nom Objet Nom Objet : CLASSE :CLASSE

Mohamed Mohamed : PERSONNE :PERSONNE

Un groupe d’objets :Un groupe d objets ::PERSONNE



Valeurs des attributs des objets :jLe rectangle représentant un objet peut comporter une partie contenant les valeurs de ses attributs :

: VOITURECouleur = rouge

Ahmed : ADHERENTNom = Mohamed

Puissance = 4Prénom = AhmedAdresse = Sfax Marque = Peugeot

L’état d’un objet :est déterminé par les valeurs prises par ses attributs,

:CHAMBRE [Occupée]

est déte é pa es a eu s p ses pa ses att buts,à un instant donné, un objet est dans un état particulier, conséquence des opérations de modifications


appliquées.

Syntaxe de classe

La syntaxe de description des attributs est :

[Visibilité] NomAttribut [Multiplicité][ : Type [=Valeur Initiale] [{Propriété}]*]

Visibilité t pe d'accessibilitéVisibilité = type d'accessibilité :+ : public, visible et modifiable par tout objet du même

paquetagepaquetage.- : private, seulement visible et modifiable par les

opérations de l'objet auquel il appartient. p j q pp# : protected, seulement accessible et modifiable par

les opérations des classes descendantes.


Syntaxe de classe

Multiplicité : intervalle ou nombre

Multiplicité := (Intervalle|nombre)

Le type des attributs peut être :

Un type primitif (supporté par les LP) : Entier, chaîne, …Une classe (type utilisateur) : BOUTON RECTANGLEUne classe (type utilisateur) : BOUTON, RECTANGLE, …Expression : chaîne de caractères dont la syntaxe est en dehors de la portée d’UML.dehors de la portée d UML.


Syntaxe de classe

Propriété :Propriété :

Mutabilité (gelé, variable, ajout Uniquement, …)

Gelé : attribut non modifiable (const de C++).Variable : attribut modifiable (propriété par défaut)Variable : attribut modifiable (propriété par défaut).Ajout Uniquement : seul l’ajout est possible

(multiplicité > 1)(multiplicité > 1).

Contrainte :Exemples : - num_sec_soc : string[10] = " " {Unique}


Syntaxe de classe

Un attribut peut être …………….. (/Attribut) :Il peut être déduit par application d’une formulesur d’autres attributs.Il t d i i lé t ti àIl peut conduire en implémentation à une opération.

RECTANGLELongueurNote

RECTANGLELongueur Longueur

Largeur

Surface ()

LongueurLargeur/Surface

Surface =

longueur * largeurSurface ()

Niveau Analyse Niveau Conception

Opérations


y p

Syntaxe de classe

PRODUIT- PrixHT- TVA

PRODUIT

TVA-/PrixTTC {PrixTTC = PrixHT* (1+TVA) }


Syntaxe de classe

Exemple : CANALp

TELEVISIONOnOff : BOUTON

HAUT-PARLEUR

CANAL

OnOff : BOUTONCouleur : énum {gris,noir}Marque : ChaîneTélé B lé V i

BOUTON

PARLEUR

Télétexte : Booléen = VraiChaînes [2..*] : CANALPrix : Réel

<<énumération>>TypeTV

HautParleurs [2..6] : HAUT-PARLEURType : TypeTV {gelé} … 16/9

3/4


Classes

Syntaxe de classe

Les stéréotypes : mécanismes d’extension des constructions UML.

Appliqués aux classes, ils permettent d’avoir desAppliqués aux classes, ils permettent d avoir des classes particulières répondant à un besoin donné. Exemples : énumération, interface, utilitaire, …


Syntaxe de classe

Classes utilitairesStructuration des variables et des constantesglobales.Représentées par des classes stéréotypées.Les données membres sont statiques.

«utility»V i bl Gl b l

- var12

VariablesGlobales

- var2


Syntaxe de classe

Syntaxe de description des opérations :y p p[Visibilité] NomOpération [[Arguments] :

TypeRetourné [{Propriété}*]]TypeRetourné [{Propriété} ]]

Exemple : + fact(n:int) : int {récursive}

Remarque :Une opération : un service qu’une instance de la classe peut réaliser.Une méthode est l’implémentation d’une opération.

Abus de langage : opération = méthode


Syntaxe de classe

Visibilité : +, -, #

Arguments : [Direction] NomArgument[: TypeArgument] [= ValeurDefaut][: TypeArgument] [ ValeurDefaut]

Direction (idem PL/SQL) : in, out, inout( ) , ,in est la valeur par défaut

In : argument est un paramètre en entrée seule ; a gu e t est u pa a èt e e e t ée seu e ;non modifié par l’exécution de cette opération.Out : argument est un paramètre en sortie seule ; g pl’appelant peut récupérer sa valeur. InOut : argument est un paramètre en entrée-sortie ;


passé à l’opération, modifiable et récupérable.

Syntaxe de classe

Propriété : prequête : l’opération ne modifie pas les attributs ;abstrait : l’opération n’est pas implémentée dans la p p pclasse ; estFeuille : l’opération ne peut pas être redéfinie ;estRacine : l’opération est définie pour la première fois dans la hiérarchie ; récursive : l’opération est récursive ;récursive : l’opération est récursive ; …


Syntaxe de classe

Représentation détaillée (conception)p ( p )

D t D Ré ti [0 1] D tCOMMANDE

- DateDeRéception [0..1 ] : Date# EstPrépayée [1] : Boolean = False

Lignes [1 *] : LigneCommande

+ Expédier() : Boolean

- Lignes [1 ..*] : LigneCommande- Prix : Real+ Expédier() : Boolean+ Fermer()


Syntaxe de classe

Visibilité et portée des attributs et pdes opérations statiques :

CLASSE+ AttributPublic

PRODUITNumProduit+ AttributPublic

# AttributProtégé- AttributPrivéAtt ib tD Cl

Attribut de classeSouligné

NumProduitIntituléProduitPrixProduitNbreDeProduitsAttributDeClasse

Idem pour les

g

Visibilité globale : l’attribut est considéré

NbreDeProduits

Créer()opérations

l attribut est considéré comme un objet partagé par les instances d’une

l

()Supprimer()


classe

Syntaxe de classe

Correspondent aux membres static en C++ ou Java

RESERVATION- Identifiant : Integer-Date : Date

tP h i Id tifi t() I t

Date : Date-Compteur : Integer+ getProchainIdentifiant() : Integer


Concept de relation

Les relations entre classes :Les relations entre classes :Association.A é tiAgrégation. Composition.Héritage.

Remarque : par rapport au modèle E/A de base, les Représentations Conceptuelles UML sont :

+ riches sémantiquement et

+ proches de la réalité


+ proches de la réalité.

Concept de relation --- Les associations

Les associations :Une association exprime une connexion sémantique bidirectionnelle entre n classes (n>=1).q ( )

EmprunterADHERENTN EmprunterNomPrénomAdresse

EXEMPLAIRE

Créer()

Une association est instanciable dans unUne association est instanciable dans un diagramme d'objets sous forme de liens, ou dans un diagramme de collaboration sous forme de messages,


g gentre objets issus des classes associées.


C1 C2Diagramme de

classesAssociation

Classes

:C1 :C2 :C1 :C2Lien Message

Objets

Diagramme d’objets Diagramme de collaboration



Une association représente donc une relationUne association représente donc une relation conceptuelle durable entre n classes (n>=1).Les instances d’une association sont des tuples des pinstances des classes reliées par cette association.

ADHERENTEmprunter

ADHERENTNomPrénomAdresse

EXEMPLAIREAdresseCréer()

Des instances de l’association Emprunter :{ (A1, E1), (A1, E2), …. (A2, E4), (A2, E7), ….}



Les multiplicités ou cardinalités :Par rapport au modèle Entité/Association :

Entité 2P21A1Card1 Card2

Entité 1P11

Diagramme Entité /

P22 …

A1P11P12 …

Association

Card1 Card2 Diagramme de classes A1

Classe 1P11 P12 …

Classe 2P21 P22 …



Nommage des associationsUne association peut être nommée : c’est optionnel.

[ N A i i ] Classe2Classe1 [ Nom Association ]

Les noms peuvent être en forme verbale active ou passiveLe sens de lecture d’une association peut être préciséLe sens de lecture d’une association peut être précisélorsqu’il est ambigu :

HÔTELhéberge>

SOCIÉTÉest employée par>

PERSONNE



Arités des associations :Une association peut être binaire ou n-aire (à éviter).Exemple : on désire représenter le fait suivant : Un p pprofesseur enseigne dans une salle des étudiants d’une classe.

PROFESSEUR

SALLE CLASSE

Enseigner

Comment interpréter les multiplicités ?


Comment interpréter les multiplicités ?


Association à navigabilité restreinte :gPar défaut, une association est navigable dans les deux sens.On peut la limiter à un seul sens dans un modèle

indique que les instances d'une classe « ne voient pas » les instances de l’autre.

ELECTEUR CANDIDATVoter

ELECTEUR CANDIDAT

ConnaîtreETUDIANT ENSEIGNANT





La notion de rôle :L’extrémité d’une association peut avoir un nom, appelé rôle, qui décrit comment une classe source voit une classe destination au travers de l’association.

CLASSE2CLASSE1 [ Nom Association ] CLASSE2CLASSE1 [ ][Rôle1] [Rôle2]

Rôle 1 : le rôle joué par Classe 1 dans l’associationRôle 2 : le rôle joué par Classe 2 dans l’association

PERSONNESOCIÉTÉEmployéesEmployeur

Emploi


Employéesp y


L’indication des rôles est nécessaire pour les passociations ambiguës.

Ô ClientsHÔTEL PERSONNE

Directeur

Clients

Directeur

ParentsPERSONNE

Parents

Parenté

Enfants



Attention : La présence d’un grand nombre p gd’associations entre deux classes peut être le signe d’une mauvaise modélisation.

PERSONNE VOITURE

Conduire

LaverPERSONNE VOITUREArrêter

Conduire

PERSONNE VOITURELaver



Les multiplicités (cardinalités) p ( )précisent les nombres min et max d’objets d’une classe qui peuvent être liés à un objet de l’autre.

1 U l

PERSONNESOCIÉTÉEmployées

Employeur1

1..*

1 Un et un seul0 .. 1 Zéro ou unN N ( ti t l)

Valeurs de cardinalité

conventionnelles N N (entier naturel)M .. N (3..7) De M à N (entiers naturels)* De 0 à plusieurs

conventionnelles

* De 0 à plusieurs0 .. * De 0 à plusieurs


1 .. * De 1 à plusieurs


Contraintes : Il s’agit de règles sémantiquesdéfi i d i ti Ell tt tdéfinies sur des associations. Elles permettent :

d’étendre ou de préciser la sémantique,de restreindre le nombre d'instances visées.

Elles peuvent s'exprimer en :p pLangage Naturel (L’âge d’un étudiant est supérieur à 16) ou graphiquement avec un {texte} ({longueur > largeur}) ou En OCL (Object Constraint Language)( j g g )



Exemples : soit le diagramme de classes suivant :

-Adresse : StringHÔTEL -Étage : Integer

-Numéro : Integer

CHAMBRE-lesChambres

0 1-NbLits : Integer1..*

0..1

l Ch b 0 1-laChambre 0..1

1 PERSONNE- lesClients*

-Nom : String-Prénom : String-Age : Integer

- Directeur- lesRésidents


*


// Etage maximum : 12// Etage maximum : 12

context Chambre inv: self.étage <= 12

// Pas plus de résidents que de lits sauf s’il y a un enfant de moins de 4 ans

context Chambre inv:lesRésidents->size <= nbLits or

(lesRésidents->size = nbLits + 1 andl Ré id t > i t ( P | â < 4))lesRésidents->exists(p : Personne | p.âge < 4))



Les types de contraintes exprimables sur lesLes types de contraintes exprimables sur les associations :

Ordonné ;Ordonné ; Sous-ensemble ; Ou ;Ou ; Partition (Ou-exclusif) ; …

Elles sont placées entre accolades.p



Ordonné :

COMPTEPERSONNE 1 0..*

La collection des comptes d’une personne est triée

{ordonné}

La collection des comptes d une personne est triée



On désire représenter les règles de gestion suivantes :1 U l é t ff té à l i

COMPTEPERSONNE{ordonné}

1 0..*1. Un employé est affecté à un seul service.2. Plusieurs employés sont affectés à un service.3 Un service est dirigé par un seul employé{ordonné}3. Un service est dirigé par un seul employé.4. Le directeur d’un service est obligatoirement l’un des

employés affectés à ce service

SERVICE EMPLOYEAffecter1 1 *

employés affectés à ce service.

Numéro_S Nom_S

Numéro Nom {sous-ensemble}

Affecter1 1..

... ....Diriger0..1 1

Toute instance de Diriger est aussi instance de Affecter


Toute instance de Diriger est aussi instance de Affecter


Application des opérateurs de couverture et de disjonction :

Non Disjonction Disjonction

de couverture et de disjonction :

x xx x

x xx

x x x xxx x x x xCouverture

x x x

x x x x

x xx x x x x x x x x x x x x x

NonCouverture

x x x

x X



Exemples :Exemples :

UNIVERSITÉ-Affectation0 1 0 10..1

ne

0..1

e

Ens

eig

Etu

die

E

{ou}

PERSONNE- lesEnseignants*

- lesEtudiants*



Partition (Ou-exclusif) : Indique que pour un objet donné,Partition (Ou exclusif) : Indique que pour un objet donné, un seul lien est valide.

Enseign-UnivENSEIGNANT

ETAB-UNIVER0..1

{Partition}

Technologue ISET0..1



Une classe d'association (classe associative) :( )Permet de représenter une association par une classe pour définir des attributs et/ou des popérations dans l’association.Possède les caractéristiques d’une classe et d’une qassociation.

0 * 1 *ENTREPRISE EXPERTEmbauche0..* 1..*

CONTRATSalaire, Emploi


p


Et si CONTRAT devient une classe tout court ?Et si CONTRAT devient une classe tout court ?

Que devient la solution ?

Est-elle équivalente à la précédente ?

Un attribut de lien :

EXAMENETUDIANT Passe >* *

note



Considérons les règles de gestion suivantes :Un client passe une ou plusieurs commandes.Une commande est passée par un seul client et concerne un ou plusieurs produits.Un produit peut être commandé par plusieurs

dcommandes.Chaque commande est envoyée à un ou plusieurs dépôts pour être satisfaitedépôts pour être satisfaite.Chaque dépôt ayant satisfait la partie qui le concerne d’une commande, génère une facture correspondant à , g pcette partie. Toute facture générée sera envoyée au client


correspondant.


CLIENT * *1 COMMANDE PRODUIT1..n

QtéCdée*1

FACTURE

*

*Attribut de lien :

(Cde produit QteCdée)DEPOT

* (Cde, produit, QteCdée)

Classe d’association :

QteCdée est un simple attribut(Cde, Dépôt, Facture)

Facture est une classe à part entière : elle a ses propres attributs opérations et liens


elle a ses propres attributs, opérations et liens


Une classe d'association :D’un point de vue implantation :

Classe Facture Classe CommandeClasse Facture Classe CommandePROPRIETES PROPRIETES

NumFac, NumCde, DateFac DateCdeDateFac, DateCde,NumClient, Prods : SET(PRODUIT, QteCdée),NumCde, Depots: SET(DEPOT), NumDep,p,…, METHODES

…

METHODESMETHODESCréerFac(),SolderFac(),


…


La qualification permet de sélectionner unLa qualification permet de sélectionner un sous-ensemble d'objets, parmi ceux participant à une association.participant à une association.Elle est définie par un qualificatif ou une clé (au sens relationnel du terme) qui est utilisé(au sens relationnel du terme), qui est utilisé avec un objet de la classe source et permet de sélectionner les objets de la classe ciblede sélectionner les objets de la classe cible.

0..1 Num_comptePERSONNE BANQUE*Titulaire



N

Assimilable à une table associative.Le qualificateur (Nproduit) permet d’identifier 0 ou une ligne de la commande.Pour manipuler (ajouter, consulter, etc.) une ligne d’une commande, il faut obligatoirement un produit.


Diagramme d’objets et associations

Représentation des liens entre objets :Représentation des liens entre objets :

Les liens entre objets :Les liens entre objets :

sont des instances d’associations entre les l d bj t ti i tclasses des objets participants ;

permettent une représentation plus concrète que celle produite par les diagrammes de classes.

Voyons des exemples !Voyons des exemples !



Exemple :

MOTEURVOITURE 1 1:MOTEURV1:VOITURE

1

4ROUE

4R2:ROUE R3:ROUER1:ROUE R4:ROUE

Diagramme de Classes




Exemple :

Personne -- mère- père- enfants

0 1 0 1

*nom prénom = Olfa

Olfa : PersonneépouseKALLEL=

0 1

- nom- prénom

- enfants - épouse

0..1 0..1

* 0..1prénom = Olfa

mère

0..1- époux

Nom = MALLEKPrénom = Sana

Sana : Personne Moncef : PersonneNom = MALLEKP é MoncefPrénom = Sana

M h Ppère

Prénom = Moncef

nom = MALLEKprénom = Maher

Maher : Personneépoux



Représentation des liens entre objets :p jLes liens entre objets peuvent être n-aires.Exemple :Exemple : RB: PROFESSEUR

A1: SALLE I3: CLASSE

On peut indiquer les noms des objets et des liens :

Ahmed : ADHERENT E tAhmed : ADHERENTNom = MohamedPrénom = AhmedAdresse = Sfax

Soukaria : EXEMPLAIREEmprunter


Adresse = Sfax


Remarque :

C di t til d t lCes diagrammes ne sont utiles que durant la phase exploratoire d’un domaine.

Le nombre d’instances doit être limité.

Autrement ils deviennent vite compliqués etAutrement, ils deviennent vite compliqués et illisibles.


Concept de relation --- L’agrégation

L’agrégation est une relation non symétrique, elle :exprime un couplage fort et une relation de subordination.représente une relation de type "ensemble/élément".peut notamment (mais pas nécessairement) p ( p )exprimer :

qu'une classe (un "élément") fait partie d'une autre("l'agrégat"), qu'un changement d'état d'une classe entraîne un changement d'état d'une autrechangement d état d une autre, qu'une action sur une classe, entraîne une action sur une autre.


une autre.

Concept de relation --- L’agrégation

Une instance d'élément agrégé peut :g g pêtre liée à plusieurs instances d'autres classes :

l'élément agrégé peut être partagé ;l élément agrégé peut être partagé ;

exister sans agrégat (et inversement) :les cycles de vie de l'agrégat et de ses élémentsles cycles de vie de l agrégat et de ses éléments agrégés peuvent être indépendants :

La création (ou la suppression) de l’un( pp )n’implique pas celle de l’autre.

Exemple :

AgrégationADRESSE PERSONNE


Elément agrégé agrégat

Concept de relation --- La composition

La composition est une agrégation forte qui p g g qexprime « une partie de ».

Les cycles de vies (CV) des composants et du composé ne sont pas indépendants :

Si le composé est détruit (ou copié), ses composants le sont aussicomposants le sont aussi.Une instance de composant ne peut être crééequ’avec ou après la création du composé. qu a ec ou ap ès a c éat o du co poséElle ne peut être liée qu'à un seul composé.Les "objets composites" sont des instances de l éclasses composées.

LIVRE CHAPITRE


Composition


Une classe composant peut faire l’objet de plusieurs iticompositions.

Un objet de la classe composant ne peut appartenir qu’à un seul objet d’un composéqu à un seul objet d un composé.Cycles interdits !D é d i d t i l d ll dDurée de vie du composant incluse dans celle du composé.La « navigabilité » peut être bidirectionnelle ou nonLa « navigabilité » peut être bidirectionnelle ou non.

1..*ChapitreLivre Thème

3..10 Thème-Principal



Relations entre les CV des objets :CV du composé

CV composant 1

CV composant 2

CV composant 3

CV composant 4

TempsCréer() Supprimer()

CV composant 4

Créer() Supprimer()

Remarque : toutes les conventions relatives aux cardinalitésrestent valables pour les agrégations et les compositions


restent valables pour les agrégations et les compositions.

Diagramme d’objets et compositions

Exemple de représentation des objetsExemple de représentation des objets composites :

Un objet composite est composé d’autres objetsUn objet composite est composé d autres objets (sous-objets).Le nombre d’instances du composant peut êtreLe nombre d’instances du composant peut être spécifié. Exemple :

Un Composite

:Partie1 N1 :Partie2 N2

Eau : MOLÉCULE

Hydrogène : ATOME 2:Partie1 N1 :Partie2 N2 Hydrogène : ATOME 2

Oxygène : ATOME 1


Concept de relation ---Association agrégation et compositionAssociation, agrégation et composition

Exemple récapitulatif :Une personne peut posséder des immeubles.Dans un immeuble, on peut trouver des ascenseurs.Un immeuble est composé d’étages.Une personne peut posséder des comptes et une dadresse.

Explications :Une personne peut posséder des immeubles :

Un lien conceptuel : les objets ont des CV i dé d tindépendants. Ce lien exprime une relation temporaire.

A i ti


Association


Dans un immeuble on peut trouver des ascenseurs :Dans un immeuble, on peut trouver des ascenseurs :Un lien : ensemble/élément, les CV des objets ne sont pas forcément dépendants. p pla suppression d’un immeuble n’entraîne pas obligatoirement celle d’un ascenseur.Un ascenseur ne peut être utilisé (au même temps) par plus qu’un immeuble. Mais, dans le temps, le même ascenseur peut être utilisé par différents immeublesascenseur peut être utilisé par différents immeubles.

AgrégationAgrégation



Un immeuble est composé d’étages :U li é/ t l CV d bj tUn lien : composé/composants : les CV des objets coïncident.La création de l’immeuble la création de sesLa création de l immeuble la création de ses étages.La suppression de l’immeuble la suppression de ses étages.Un étage ne peut pas être partagé par différents immeublesimmeubles.

CompositionComposition



Diagramme de Classes :

PERSONNEIMMEUBLE Posséder ** PERSONNEAdresse

IMMEUBLE Posséder **1

ASCENSEUR COMPTE1..* *

*

ETAGE


La généralisation / spécialisation

L’héritage, avec UML, est désigné par GénéralisationLa généralisation peut être :

SimpleSimple

C GÉNÉRALISEEC_GÉNÉRALISEE

Est UneEst Une

C SPÉCIALISEE

Multiple : La spécialisation a plus d’une généralisation

C_SPÉCIALISEE


Multiple : La spécialisation a plus d’une généralisation

La généralisation / spécialisation

Attention : à ne pas confondre héritage et instanciationAttention : à ne pas confondre héritage et instanciation

dèlVoiture

- modèle- cylindrée- couleur

NON !NON !Vx

Ferrari ; 6 CJaune


La généralisation

Contraintes et propriétés de la généralisation :La contrainte exprimée par le mot-clé {Disjoint}

Tout objet est au plus instance d’une seule sous-classeclasse.C’est une décomposition exclusive : {Exclusif}

C’est l’option par défaut.C est l option par défaut.

ETUDIANT

{Disjoint}ETUDIANT-1C ETUDIANT-3C

{Disjoint}


Inter (ETUDIANT-1C, ETUDIANT-3C) = Vide

La généralisation

La contrainte exprimée par le mot-clé {Complet}Indique que la spécialisation est terminée (couverture) :

Il n’est pas possible d’ajouter d’autres sous-classes.La contrainte exprimée par le mot-clé {Incomplet}

Indique que la spécialisation est extensible : elle peut avoir d’autres sous classesavoir d’autres sous classes.

ENSEIGNANT ETUDIANT

{I l t}

ENSEIGNANT

{Complet}{Incomplet}

E PERMANENT E VACTAIRE

{Complet}

ET-1C ET-3CET-2C


E_PERMANENT E_VACTAIRE ET-1C ET 3CET-2C

La généralisation

Une classe générique peut être spécialisée selondiffé t itèdifférents critères.La contrainte exprimée par le mot-clé {inclusif} ou {chevauchement} ou {overlapping}{chevauchement} ou {overlapping}

Une instance de l’une des spécialisations peut être simultanément une instance d’une autre.

VEHICULEPremier critère :M t i ti

Deuxième critère : Mili

{Chevauchement}

Motorisation Milieu

V_TERRSETRE V_MARINV_A_VOILE V_A_MOTEUR


CAMION

La généralisation

Application des opérateurs de couverture et de disjonction :

Non Disjonction Disjonction

de couverture et de disjonction :

x xx x

x xx

x x x xxx x x x xCouverture

x x x

x x x x

x xx x x x x x x x x x x x x x

NonCouverture

x x x

x X


Divers

Quelques représentations trivialesQuelques représentations triviales

CClasses sans relations.Classes sans attributs.Classes sans opérations.Relation 1-1.

Pas forcément une erreur,mais toujours se poser la question.


Divers

La pratiquep qNe pas utiliser systématiquement toutes les notations :

En phase d’analyse : concepts fondamentaux.En phase de conception/implémentation :p ase de co cept o / p é e tat oconcepts avancés.

Bien utiliser UML ne veut pas dire bien modéliser !pLa théorie ne remplace pas l’expérience.Les patrons de modélisation (design patterns)p ( g p )peuvent améliorer le modèle de conception.


Divers

Exemple :Exemple :Un contrat d’édition est un accord entre un auteur (éventuellement collectif) et un éditeur(éventuellement collectif) et un éditeur. Les conditions générales d’un contrat sont stipulées dans un contrat typestipulées dans un contrat type.Les clauses particulières sont ajoutées au contratcontrat.Le contrat ne concerne qu’un ouvrage, qui ne peut être édité chez un autre éditeurpeut être édité chez un autre éditeur.


Divers

Auteur EditeurContratTypeAuteur Editeur1

1 e

1

0..*

1

*

/édi

te

{disjoint, complète}0..*

AuteurIndividuel AuteurCollectif OuvrageContratEdition

1

porte sur0..*2..* regroupe

{ordered}



A2. Compléments pour les diagrammes de classesdiagrammes de classes

Rafik BOUAZIZ -- Faïez GARGOURI

FSEG – Sfax ISIM – Sfax

314R. BOUAZIZ -- F. GARGOURI

Les classes abstraites

Les classes abstraites ne sont pas instanciables directementdirectement.Elles servent de spécification générale pour manipuler les objets instances de leurs sous-classes.Le nom d’une classe abstraite s’écrit en italique.

ICÔNE

ICÔNEREGULIAIRE ICÔNE ARBITRAIREREGULIAIRE

Utilité : montrer les caractéristiques à diffé l


TOUCHE communes à différentes classes


Opérations et classes abstraitesNotées en italique.Les classes abstraites ont les mêmes relations que les autres classes.

Liste

+begin() : Booleanbool arrivée = begin();+next() : Boolean+getValue () : Object+isEmpty() : Boolean

g ();int t = 0 ;while (next())

t++; p y()+size() : Integer+get(in i : Integer) : Object

t++;return t ;



Concrétisation = héritage Liste

+begin() : Boolean+next() : Boolean

tV l () Obj t+getValue() : Object+isEmpty() : Boolean+size() : Integer+get(in i : Integer) : Object+get(in i : Integer) : Object

ListeChaineeElement 1

+begin() : Boolean+next() : Boolean+getValue() : Object

-valeur : Object-suivant : Element -eltDébut


get a ue() Object+isEmpty() : Boolean

Les compartiments Exceptions et Responsabilités d’une classeResponsabilités d une classe

Les compartiments responsabilités et exceptions ne sont pas obligatoiressont pas obligatoires.Il n’y a pas de syntaxe standard pour leur définition. Une responsabilité est un contrat ou une obligationUne responsabilité est un contrat ou une obligationqu’une classe doit respecter.Exemple : GABp GAB

Attributs

Responsabilité{Opérations Consultation de

compteResponsabilitéConsultation de compte

Retraits et dépôts d’argentImpression de relevé de compte

Use cases{ Retrait /dépôt espècesImpression de relevé de compte

ExceptionsCarte non valide

C d t i t

{espèces

{Scénariod’échec


Code secret incorrect{d échec

Les interfaces

Interfaces« Sorte » de classe définie exclusivement par des opérations abstraites.Sert à l’implémentation d’autres classes et non à leur structure.Deux notationsDeux notations.Exemple de l’interface Conteneur :

«interface»Conteneur

Conteneur

+ get( in i : Integer ) : Object+ size () : Integer


Les interfaces

Une interface décrit une partie du comportementUne interface décrit une partie du comportement visible d’une classe, d’un paquetage, … . Ce comportement est défini par une liste d’opérationsp p ppubliques.Elle ne fournit aucune implémentation des opérations.p pElle ne définit aucun attribut.

U l t tili t t ti dUne classe peut utiliser tout ou une partie desservices décrits dans une interface.


Les interfaces

<<interface>>Notation :

NOMBREComparaison Comparaison

comparer()⇔

NOMBRE

Relation de Réalisation⇔

La classe qui réalise une interface est indiquée par

NOMBRE

La classe qui réalise une interface est indiquée par une relation de réalisation :

la classe Nombre réalise l’interface Comparaison.pUne classe réalisant une interface doit implémenter

tous les services décrits par cette interface.


tous les services décrits par cette interface.

Les interfaces

Une interface ne peut pas avoir d’associations.Elle peut avoir des implémentations.

«interface»

+ get( in i : Integer ) : Object+ size() : Integer

«interface»Conteneur Conteneur

b i () B l

Liste

+ begin() : Boolean+ next() : Boolean

Liste + begin() : Boolean+ next() : Boolean+ getValue () : Object+ isEmpty() : Boolean+ next() : Boolean

+ getValue () : Object+ isEmpty() : Boolean+ size() : Integer+ get( in i : Integer ) : Object

p y()+ size () : Integer+ get( in i : Integer ) : Object


get( in i : Integer ) : Object

Les interfaces

Elle peut avoir des dépendances :Commande

Relations sémantiques mais non structurelles

Commande

-lignes[*]

Commande

«interface»Conteneur

-lignes[*]-lignes[*]

+get(in i : Integer) : Object+size() : Integer ConteneurConteneur

+begin() : Boolean

Liste

+begin() : Boolean

Liste

+begin() : Boolean

Liste

+begin() : Boolean+next() : Boolean+ getValue() : Object+ isEmpty() : Boolean+size() : Integer

+begin() : Boolean+next() : Boolean+ getValue() : Object+ isEmpty() : Boolean+size() : Integer

+begin() : Boolean+next() : Boolean+getValue() : Object+isEmpty() : Boolean+size() : Integer


+get(in i : Integer) : Object +get(in i : Integer) : Object+get(in i : Integer) : Object

Les interfaces

DépendancesDépendancesRelation sémantique mais non structurelle.La modification de la cible peut avoir desLa modification de la cible peut avoir des répercussions sur la source.


Les interfaces

Plusieurs stéréotypes :« call » : la source appelle une opération de la cible« call » : la source appelle une opération de la cible.« create » : la source crée une instance de la cible.« permit » : le source est amie de la cible.« permit » : le source est amie de la cible.« use » : la source a besoin de la cible pour être implémentée.


Les interfaces

Exemple

BANQUEC édit<<utilise>>Réalise

CLIENTBANQUECrédit

<<utilise>>

ut se

Réalise<<Interface>>Virement

Avec UML 2 :

Réalise

CLIENT BANQUE(FournitRequiert

Avec UML 2 :

(Crédit


Les classes paramétrables

Classe paramétrable = classe template (de C++)Un modèle de classes.Classe sans instances.Ne peut pas être utilisée telle quelle :

Il faut lier les paramètres formels à des paramètres aut e es pa a èt es o e s à des pa a èt eseffectifs.

Classe surtout utilisée en implémentation.

Les paramètres de généricité sont identifiés dans un rectangle à traits tiretés.g



Paramètres formels Type

Classe paramétrable

formelsCollection

Créer(), Supprimer(), Trier()

Une classe instance est liée (bind) à une classe paramétrable par une flèche tiretée

Liste

T

ListePersonne «bind»(Personne)

-élément : T-élément : Personne



Exemple de classe paramétrablep p

Element, NbLi

TABLEAUNbLignes,

NbColonnes

élé t [NbLi NbC l ] d T-éléments[NbLignes, NbColonnes] de Type

+Elément(ligne,colonne):Type+Elément(t:Type, ligne,colonne)

<<lie>>(Case,8,8)

Echiquier

<<lie>>(Case,8,8)Tableau<Réel, 3, 4>


Une classe instance Un objet : une instanciation implicite

Les classes utilitaires

Une classe utilitaire représente des bibliothèquesp qUne classe utilitaire permet de grouper des éléments au sein d’un module sans en construireéléments au sein d un module sans en construire une classe complète.

<<utilitaire>>MATH

Pi

⇒ Elle contient des opérations et/ou des attributs globaux (statiques)

Pisin()cos()

Elle est indiquée par le stéréotype <<utilitaire>>

()...


Les paquetages

Un paquetage (ou package) regroupe des éléments de modélisation (EM) : classes, associations et packages.Notation :

Client

Un paquetage contient un sous ensemble d’un modèle.La décomposition de modèles en paquetages se fait selon un critère purement logique.L’objectif de la décomposition en paquetages est d’avoir une cohérence forte entre éléments d’un même paquetage et un couplage faible entre


même paquetage et un couplage faible entre paquetages.

Les paquetages

La hiérarchie des paquetages et les relations entreLa hiérarchie des paquetages et les relations entre eux décrivent l’architecture du système.Deux éléments de modélisation contenus dansDeux éléments de modélisation contenus dans deux packages différents peuvent porter le même nom.nom.Deux éléments de modélisation ayant le même nom contenus dans des packages différents nenom, contenus dans des packages différents ne sont pas forcément identiques.Les éléments contenus dans un packageLes éléments contenus dans un package possèdent chacun un nom unique.


Les paquetages

Les relations de dépendance entre les ppackages sont de deux types :

<<importe>>: ajoute les éléments du package destination a package so rcedestination au package source.<<accède >>: permet de référencer des éléments du package destination.du package destination.

FACTURATIONCLIENTCLIENT

CLIENT

1*FACTURATIONCLIENT

<<accède >><< èd >>

COMMANDE

Facturation::Acheter*

Concerner 10..1

1

1..n

**

Utiliser la classe Facture COMPTABILITE

<<accède >> PRODUITFacturation::

FACTURE


du package Facturation

Les stéréotypes

Les stéréotypes sont des mécanismes d’extension ypprévus par UML. Appliqués aux classes, ils permettent d’avoir des pp q , pclasses particulières répondant à un besoin donné. Exemples : énumération, interface, utilitaire, …

extensions des concepts de base de UML

Exemples :<<utilitaire>>Stéréotypes

Concepts de base

de base de UML <<acteur>><<interface>><<signal>>

UML évolue mais reste stable

g….


UML évolue mais reste stable


III. Diagrammes d’Etats – Transitions

Mohamed Amine CHAÂBANEISAA SfaxISAA – Sfax

Rafik BOUAZIZ -- Faïez GARGOURIRafik BOUAZIZ Faïez GARGOURI

FSEG – Sfax ISIM – Sfax

114M.A. CHAÄBANE--R. BOUAZIZ -- F. GARGOURI

Introduction

Les objets d’une classe ne sont pas figés :Les objets d’une classe ne sont pas figés :Ils peuvent évoluer et changer d’états au cours de l l d i (CV i t ll d t t lleur cycle de vie (CV : intervalle de temps entre la création et la suppression de l’objet)

Un diagramme d’états – transitions (DET)permet d’étudier l’aspect dynamique d’unepermet d étudier l aspect dynamique d une classe, compte tenu de l’importance de son comportement.comportement.


Introduction

Un DET est une description des changementsUn DET est une description des changementsd'états d'un objet (ou d'un composant) :

en réponse aux interactions avec d'autresen réponse aux interactions avec d autres objets/composants ou avec des acteurs.

Une classe n’a pas obligatoirement un DET, comme elle peut en avoir plusieurs, selon différentes sémantiquesdifférentes sémantiques.

L'ensemble des DET forme une partie du pmodèle dynamique du SI modélisé.


Introduction

Un DET d’une classe est une description d é l ti ibl d bj tdes évolutions possibles de ses objets. Il donne :

la liste des états que peut prendre un objet durant son CV ;les événements déclenchant les changements d’états ;les éventuelles conditions qu’il doit vérifier avant de changer d’état ;les opérations qui le font passer d'un état à un autre.


Sémantique

Les conventions graphiques représentant un h t ( t iti ) d’ét t tchangement (une transition) d’états sont :

Etat iEvt([Att]) [Condition(s)]/Action

Etat j

Ta

A l’instant Ta , suite à l’arrivée d’un événement Evt, ayant les attributs Att, et sous certaines conditions Conditions, l’objet passe de l’Etat i à l’Etat j par l’activation de l’action Action.


L’état d’un objet

L’état d’un objet est une situation donnéeL état d un objet est une situation donnéedurant la vie de cet objet.

Dans un état donné l’objet satisfait à desDans un état donné, l objet satisfait à des conditions, réalise des actions, ou il est tout simplement en attente d’événements.pL’état d'un objet est déterminé par l’ensemble desvaleurs de ses attributs et de la présence de liensvaleurs de ses attributs et de la présence de liens avec d’autres objets.Un état se caractérise par sa durée et sa stabilité.Un état se caractérise par sa durée et sa stabilité.



Dans un DET, on distingue deux états particuliers :, g p

L’état initial : état avant la création de l’objetL état initial : état avant la création de l objet

L’état final : état après la destruction de l’objetL état final : état après la destruction de l objet

1. L’état initial correspond à l’état dans lequel se trouve l’objet avant sa création.

2 L’ét t fi l d à ét t à ti d l l’ bj t2. L’état final correspond à un état à partir duquel l’objet ne peut plus évoluer.



Remarques :Remarques :La seule opération possible, partant de l’état initialest la créationest la création.Aucune transition ne peut avoir comme origine l’état finall état final.Les opérations conduisant à un état final sont, par exemple la suppression le nettoyageexemple, la suppression, le nettoyage, ...Dans un DET, on peut ne pas avoir un état final, comme on peut avoir plusieurs états finauxcomme on peut avoir plusieurs états finaux.


Les événements

Un événement correspond à l’occurrence d’ f it ti li d l d i d’ét dd’un fait particulier dans le domaine d’étude.

C’est une information instantanée.Typologie des événements :

Evénement externe :Déclenché par un acteur externe au domaine de l’application.Exemple : l’arrivée d’un bon de commandeExemple : l arrivée d un bon de commandeclient.


Les événements

Evénement interne :Déclenché par un acteur ou un objet interne du domaine de l’application.E l D d d’A h t dExemple: une Demande d’Achat dans une gestion des approvisionnements.

Evénement temporel :Déclenché selon une condition temporelle.Exemple : Supprimer toute réservation non confirmée 24 heures avant la date de fin de réservationréservation.


Les événements

La spécification complète d’un événement p pcomprend :

le nom de l’événement,la liste des paramètres éventuels,l’objet expéditeur,l’objet destinataire,la description de la signification de l’événement.p g

Généralement :O li i à d l d l é éOn se limite à donner le nom de l’événement.


Les transitions

Une transition représente le passage i t t é d' ét t tinstantané d'un état vers un autre.

Etat iEvt([Att]) [Condition(s)]/Action

Etat j

Elle est déclenchée par un événement : c’est l'arrivée d'un événement qui conditionne la transition.


Les transitions

Elle peut être conditionnée à l'aide de "gardes" :Elle peut être conditionnée à l aide de gardes : expressions booléennes, exprimées en langage naturel, encadrées par des crochets.

Disponible ¬ Disponible[QteDispo<QteMin]Entrée Stock Sortie Stock

Disponible ¬ DisponibleSortie Stock

[QteDispo>=QteMin]


Les transitions

Une garde (ou condition de garde) :E t diti b lé d t dé d lEst une condition booléenne dont dépend le déclenchement d’une transition lors de l’occurrence d’un événement.d un événement.

Etat A Etat BEvt [Garde]

Est évaluée dès l’arrivée de l’événement de déclenchement.

Il fait trop chaud [hiver]

Etat A Il fait trop

chaud [été]

Climatisée Aérée

chaud [hiver]chaud [été]


Les transitions

Les actionsLes actionsLes actions spécifiées dans une transition sont les actions à exécuter lors du déclenchement de laactions à exécuter lors du déclenchement de la transition par l’événement.

Chaque action est instantanée et atomique, donc ininterruptible.

Une action peut comporter des appels d’opération, la création ou la destruction d’un objet, ….


Les transitions

Les activitésLes activitésUne activité est un calcul non-atomique qui se produit pendant qu’un objet est dans un étatproduit pendant qu un objet est dans un état donné.L’activité peut être interrompue par la survenanceL activité peut être interrompue par la survenance d’un nouvel événement.Exemple : quand un objet est en rupture de stockExemple : quand un objet est en rupture de stock et qu’une activité de réapprovisionnement a été lancée, l’arrivée d’une entrée de stock peut , pinterrompre cette activité

(si QteDispo devient > QteMin)


Les transitions

Les transitions composites :pfactorisent et partagent des connexions :

Plusieurs transitions peuvent se rejoindre pour partager des actions.Une transition peut se ventiler en des connexions

t ll t l imutuellement exclusives.Ouvert

Vé ifi ti

Ouvert

OUVérification[toutes les

pièces fournies] [pièces[toutes les

pièces

VérificationOUVérification

[pièces manquantes]

Incomplet E i t ti

pièces fournies]

I l t E i t ti

[pièces manquantes]

pièces fournies]

manquantes]


Incomplet En instruction Incomplet En instruction

Les transitions

Les points de jonction statique :L d té è l i t d’i t ti tLes gardes notées après le point d’interaction sont évaluées avant que la transition ne soit empruntée.

Les points de jonction dynamique :Les points de jonction dynamique :Les gardes situées après le point de jonction sont évaluées quand le point de jonction est atteint.q p j

Validation/ somme := Prix()

Commande

[somme=0]

Validation/ somme := Prix()

[sinon]

Cde Annulée Cde traitée Compte à vérifier

[somme<500]


Concepts avancés sur les états

On peut préciser les actions à exécuter quand un objet p p q jest à un état donné :

Entrée : action à exécuter dès l’entrée à un état.Sortie : action à exécuter lors de la sortie d’un état.état.Faire : activité à exécuter pendant qu’un objet est dans un état particulier.dans un état particulier.Inclure : introduit une invocation d’un sous-automateautomate

action interne provoquée par un événement sans provoquer un changement d’état.


sans provoquer un changement d état.


On peut préciser les actions à exécuter quand l’objet est à un état donné : Exemple

Nom de l’état En préparationNom de l état

Entrée / action en entréeSortie / action à la sortie

En préparation

Entrée / choisirFournisseur()Entrée / fixerQuantités()Sortie / action à la sortie

Faire / une activitéInclure/ un sous-automate

Entrée / fixerQuantités()Faire / modifierCommande()Sortie / EnregistrerDateExpédition()

Etat « En préparation » d’une commande


d une commande


Etat composite (ou composé)p ( p )Un état composite est décomposé en sous-états. Un sous-état est un état emboîté dans un étatUn sous état est un état emboîté dans un état composite.Les sous-états peuvent être emboîtés à n’importeLes sous états peuvent être emboîtés à n importe quel niveau.

⇒ plus de clarté apportée aux DET⇒ plus de clarté apportée aux DET

DisponiblePanne

Non Disponible[Irréparable]

Disponible

Réparation terminée

Non Disponible



Exemple :

Disponible

Non-disponible

En pannepanne [Irréparable]

En cours de é tiréparationRéparation terminée


Exemple

défectueux

drendre[non réparé ]

en cours de réparation

en cours de réparation envoyer

en panne

pannevendre()

réparation terminée

disponible quand( newKilom.-oldKilom >10000Km )

en

remettre[ dateRéservation= dateSystème ]

entretien terminé

en location

en entretienrendre / majKilométrage()

136M.A. CHAÄBANE--R. BOUAZIZ -- F. GARGOURI DET d’un véhicule de location

Exemple

Gestion commerciale :Quand on gère les stocks de produits, il est nécessaire de prévoir, à tout moment, lesnécessaire de prévoir, à tout moment, les différents états possibles de chaque stock de produit. p

Généralement, quand on crée un nouveau produit, il est automatiquement mis "en rupture de stock"il est automatiquement mis en rupture de stock . Il ne sera disponible que s’il y a une entrée (une livraison d’une commande de ce produit).livraison d une commande de ce produit).


Exemple

Pour bien gérer les approvisionnements, on se fixe une quantité minimale (QteMin) au dessous de laquelle on commande systématiquement le

d it Qt Mi i à l titéproduit. QteMin servira à comparer la quantité disponible (QteDispo) du produit. Une fois commandé, on doit attendre la livraison du produit pour qu’il redevienne disponible. Quand un produit est disponible, toute opération d’ajout ne le fait pas changer d’état.

Donner, en utilisant les conventions UML, le diagramme d’ét t t iti d l’ bj t P d it


d’états-transitions de l’objet Produit.

Exemple

DET d’un ProduitEntrée Sortie

DET d un Produit

[QteDispo >= QteMin]

[QteDispo < QteMin]En ruptureDisponible

Sortie

ProduitMAJ(QteDeMAJ)

En ruptureDisponible

Li P d it(Qt Li é )

ProduitMAJ(QteDeMAJ) ProduitCommandé(QteCdée)

En rupture Commandé

En rupture Livré

LivrerProduit(QteLivrée)


Exemple

Alarme de Construction()

Alarme de voiture Neutralisée

Activer()

Activée

Activer()()Désactiver

Activée

Bip()/ Clignotement Bip()/ Clignotement

En veille

Effraction()

Neutraliser()Bip()/ Clignotement

Alarme

Effraction()


Alarme

Super état

Super étatDisjoints Parallèle

État

Disjoints

État

Parallèle

tat

A

tat

AA A

B B

• Un seul sous-état est actif • Tous les sous-états sont actifs


• A et B peuvent être des super états

État historique

État historiqueÉtat historiqueLorsqu’une transition s’arrête à la frontière d’un super état l’objet revient dans le dernier sous étatsuper état, l’objet revient dans le dernier sous-état considéré.

Pseudo-état historique : indique l’état lors de la première transition (l ’il ’ it d’hi t i )(lorsqu’il n’y avait pas d’historique).


ExempleAllumé

HeureCourante HeureRéveilhHeureC

hHeureR

Radio CDH ad oH

hRadio hCD

Pseudo-état historique On Off

Eteint



IV. Diagrammes de Cas d’utilisationUse CasesUse Cases

Mohamed Amine CHAÄBANEISAA-Sfax

[email protected]

Rafik BOUAZIZ -- Faïez GARGOURIFSEGS Sfax ISIM Sfax


FSEGS – Sfax ISIM – Sfax

Introduction

La phase d’analyse des besoins nécessite :de comprendre les besoins à couvrir par le système,p p yd’exprimer et de formaliser ces besoins.

Moyens pour représenter les besoins en UML :Moyens pour représenter les besoins en UML :Diagramme de cas d’utilisation :

organisation générale représentant l'utilisation dusystème par ses acteurs (les utilisateurs).

+ d'autres diagrammes.


Introduction

Constat : Le système existe pour servir sesConstat : Le système existe pour servir ses utilisateurs.

Cas d’utilisation (use cases) [Jacobson 92].Cas d utilisation (use cases) [Jacobson 92].

Idée : description du comportement du tè d i t d d tili tsystème du point de vue de son utilisateur.

Comportement = {Actions} + {Réactions}

UserBesoin/action

User

SystèmeFonctionnalité / Réaction


SystèmeRéaction

Introduction

Intérêts des cas d’utilisation :Intérêts des cas d utilisation : Recentrer l'expression des besoins sur les utilisateursutilisateurs.Faciliter la structuration des besoins des utilisateurs en une représentation simple et expressiveen une représentation simple et expressive.

⇒ Faciliter l'expression des besoins des utilisateurs et leur communication avec les experts et les informaticienscommunication avec les experts et les informaticiens.

⇒ Réduire la complexité de la détermination des besoins.


Introduction

Obliger les utilisateurs à définir la manière dont ils gvoudraient interagir avec le système (contrôler).Eviter de dériver vers des spécifications inutiles pet/ou inadaptées (ne pas aller trop dans les détails).

⇒ Exprimer les limites (domaine d’étude) et les objectifs (les fonctionnalités demandées) d èdu système.


Définitions

Définition : Un cas d’utilisation (CU) est uneDéfinition : Un cas d utilisation (CU) est une représentation décrivant un ensemble de séquences d’actions réalisées par le système, et q p y ,produisant un résultat observable pour un acteur.⇒ Un CU représente une exigence fonctionnelle⇒ Un CU représente une exigence fonctionnelle

envers le système dans son ensemble.⇒ Un CU correspond à une manière spécifique⇒ Un CU correspond à une manière spécifique

d’utiliser le système.⇒ C’est la représentation d’une fonctionnalité⇒ C est la représentation d une fonctionnalité

déclenchée en réponse à une stimulation du système.


Définitions

Notation des cas d’utilisation :

Passer commande Calculer devis

Gérer fournisseursGérer fournisseurs

Dans la pratique, les noms des CU sont de petites phrases verbales actives qui décrivent le comportement existant dans le vocabulaire du système en cours deexistant, dans le vocabulaire du système en cours de modélisation.Les CU sont acti és par des acte rs


Les CU sont activés par des acteurs.

Définitions

Définition : Un acteur est une entité (utilisateur humain, dispositif matériel, ou autre système) qui interagit directement avec le système étudié et qui représente un rôle bien déterminé.

Un acteur agit sur le système il peut :Un acteur agit sur le système, il peut :échanger de l’information avec ce système,consulter ou modifier l'état du systèmeconsulter ou modifier l'état du système.

Il joue un rôle bien déterminé.


Définitions

Notation : <<acteur>><<acteur>>Client

Client

Un acteur peut être :Un acteur peut être :Principal :

qui utilise les fonctions principales du systèmequi utilise les fonctions principales du système.Secondaire :

i ff t d tâ h d i i t ti dqui effectue des tâches administratives ou de maintenance.


Définitions

Un acteur peut être (suite) :Un acteur peut être (suite) :Un matériel externe :

c‘est à dire un dispositif matérielc est-à-dire un dispositif matériel,autre que les machines sur lesquelles s’exécute l’application,s exécute l application,faisant partie du domaine de l’application etnécessaire au fonctionnement du système.y

Un autre système avec qui le système étudié doit interagir.g


Définitions

Exemple : Cas d’utilisation p« Traiter le passage d’un client à une caisse »

Acteur Principal : CaissierActeur Principal : CaissierActeur Secondaire : Gestionnaire des caisses

(celui qui arrête les situations et les réinitialise)(celui qui arrête les situations et les réinitialise)Matériel externe : Lecteur de cartes bancairesAutres systèmes avec qui le système spécifié doit interagir :

S tè d ti d t kSystème de gestion des stocks.Systèmes d’autorisation des paiements, Et


Etc.

Définitions

Les acteurs se déterminent en observant les utilisateurs du système, ceux qui sont responsables de son exploitation ou de sa maintenance, i i l t tè i i t i tainsi que les autres systèmes qui interagissent avec

le système en question.La détermination des acteurs permet de préciser les limites du système.Ne pas confondre acteur et personne utilisant le système :

L ê t j l ôl d l iLa même personne peut jouer le rôle de plusieurs acteurs.Plusieurs personnes peuvent jouer le même rôle


Plusieurs personnes peuvent jouer le même rôle.

Définitions

Pour chaque acteur :qchoisir un identificateur représentatif du rôle,éventuellement, l’accompagner d’une brève , p gdescription textuelle.

Personne qui visite le site pour chercher des ouvrages et éventuellement passer des commandes

Internaute


Définitions

Un acteur peut participer à des relations de p p pgénéralisation avec d'autres acteurs.

Internaute Client

Liens d’héritage Est unEst un

Acheteur Client distant


Définitions

Un acteur est connecté à un cas d'utilisationUn acteur est connecté à un cas d utilisation uniquement par une association qui indique que l'acteur et le CU communiquent entre eux, chacun q ,pouvant envoyer et recevoir des messages.

Valider achat

Clientassociation


Définitions

Le diagramme de CU représente les cas d'utilisationg pidentifiés et les acteurs associés à chacun.Exemple : Diagramme des CU relatif à un projet de

développement d'un site web pour une librairie.

Rechercher des ouvragesMaintenir le catalogue

Gérer panierInternauteLibraire

Maintenir les informations édit i l

Effectuer une commandeéditoriales


Webmaster Maintenir le site

Définitions

Remarque : Dans cet exemple, il n’y a pas de liensRemarque : Dans cet exemple, il n y a pas de liensentre les cas d’utilisation. C’est un cas particulier.

La représentation de ces cas d’utilisation est faiteLa représentation de ces cas d utilisation est faite par acteur :

comme si on a autant de systèmes que d’acteurs.


Cas d'utilisation et scénarios

La représentation graphique des CU :donne une vue d’ensemble (sans détails) sur les

différentes fonctionnalités du système ;peut être affinée par des scénarios.

Un CU est une collection de scénariosUn CU est une collection de scénarios de succès ou d'échec qui décrivent la façon dont un acteur particulier utilise un système pour atteindreun acteur particulier utilise un système pour atteindre un objectif.CU ++ scénarios : de succès (le CU se réalise)CU ++ scénarios : de succès (le CU se réalise)

ou d’échec (le CU ne se réalise pas).


Cas d'utilisation et scénarios

Définition : Un scénario est une suite spécifique d'interactions entre les acteurs et le système.

C'est une instance du DCU, un chemin particulier dans sa combinatoire.

Chaque scénario est composé d'éléments,Chaque scénario est composé d éléments,qui peuvent être de trois sortes :

Un message d'un acteur au systèmeUn message d un acteur au système.Une validation ou un changement d'état du système.yUn message du système vers un acteur.


Cas d'utilisations et scénarios

Dans la description d'un CU on trouve :un scénario nominal : celui qui permet de satisfaire les objectifs des acteurs par le chemin le plus direct de succès ;le chemin le plus direct de succès ;des extensions qui regroupent tous les autres scénarios de succès (alternatifs : fin normale) ouscénarios de succès (alternatifs : fin normale) ou

d'échec (exception).

En résuméEn résuméUn scénario nominal : le CU se réalise selon le cas le plus ordinairecas le plus ordinaire.Un scénario alternatif : le CU se réalise mais pas selon le cas le plus ordinaire.


Un scénario d’échec : le CU ne se réalise pas.

Spécification détaillée des cas d'utilisation

Le CU doit avoir un début et une fin clairement identifiés.Il faut préciser les variantes possibles d'un CU : p pscénario nominal et scénarios d’extension

(alternatifs et d’échec).Pour détailler un CU, on recense de façon textuelle toutes les interactions entre les acteurs et le système.

Il n’existe pas de norme UML établie pour laIl n existe pas de norme UML établie pour la description textuelle des cas d’utilisation.


Spécification détaillée des CU

Un format proposé dans la littérature :p p<Nom du cas d'utilisation>

Acteur principal :Acteur principal :Acteurs secondaires :Objectifs :Objectifs : Préconditions :Postconditions :Postconditions :Scénario nominal :Extensions :Extensions :Exigences supplémentaires :



Préconditions : définissent les conditions quiPréconditions : définissent les conditions qui doivent être satisfaites pour que le CU puisse démarrer.

Postconditions : définissent ce qui doit être vrai l l CU t i è 'il ' itlorsque le CU se termine avec succès, qu'il s'agit d'un scénario nominal ou d'un scénario alternatif.

Exigences supplémentaires : définissent les exigences non fonctionnelles et les contraintes de conception se rapportant à la spécification du CU (performance, sécurité, ergonomie, …)



Exemple :Effectuer une commandeActeur principal : InternauteObjectifs : A tout moment, l'internaute doit pouvoir

accéder au formulaire approprié pour passer un bon de commande. Par ailleurs, il peut y saisir ses coordonnées et les informations nécessaires au

t d li ipayement des livraisons.Préconditions : Le panier de l'internaute n'est pas vide

t il éd f l i d det il a pu accéder au formulaire de commande.Postconditions : Une commande a été enregistrée et

i i C d


transmise au service Commandes.


Scénario nominal :1. L'internaute saisit l'ensemble des informations

nécessaires au paiement et à la livraison, à savoir :- Son @ e-mail avec un mot de passe pour pouvoir suivre la commande.Les coordonnées de l'@ de facturation- Les coordonnées de l'@ de facturation

(nom, prénom, @ postale complète, tél.).- Les coordonnées de l'@ de livraison si elle est différente @de celle de facturation

(nom, prénom, @ postale complète, tél.).- Un numéro de carte de crédit avec son type et sa date devalidité.



Scénario nominal (suite) :Scénario nominal (suite) :2. Le système affiche un récapitulatif de la commande.3 L'i t t lid d3. L'internaute valide sa commande.4. Le système envoie la commande validée au service

Commandes.5. Le système confirme la prise en compte de la

commande à l'internaute.



Extensions :1a. L'internaute est déjà client (alternatif)

1. L'internaute s'identifie avec son e-mail et son1. L internaute s identifie avec son e mail et son mot de passe.

2. Le système affiche les données sauvegardées concernant l'@ de facturation et l'@ de livraison ; le CU continue à l'étape 2 du scénario nominal.

2a. Le système ne connaît pas le client.Le système avertit l'internaute que son e-mail et/ou

t d d t àson mot de passe ne correspondent pas à ceux d'un client connu. Il lui propose de s'identifier de nouveau (retour à 1 a 1)


nouveau (retour à 1.a.1).


3.a. L'internaute annule sa commande (Echec)( )1. Le système revient sur l'affichage du panier et

le CU est terminé.

Exigences supplémentaires :Exigences supplémentaires : Pour garantir la sécurité et la confidentialité des

échanges il est impératif que l'envoi de donnéeséchanges, il est impératif que l envoi de données se fasse de manière cryptée.

Les cartes bancaires acceptées sont les e DinarsLes cartes bancaires acceptées sont les e-Dinars, Master Card, Visa, American Express.


Relations entre CU

Relation d’inclusion :<<i l t>>

CU1

<<inclut>>

Le CU source (CU1) incorpore le comportement décrit par le CU destination (CU2) en un point

CU1 CU2

décrit par le CU destination (CU2) en un point d'insertion déterminé.Le CU destination n'est jamais tout seul il faitLe CU destination n est jamais tout seul, il fait toujours partie d'un CU qui l'englobe.Cette relation permet d'éviter de décrire la mêmeCette relation permet d éviter de décrire la même suite d'interactions plusieurs fois, et ce en rangeant le comportement commun dans un CU


g papproprié.

Relations entre CU

Exemplep

Suivre <<inclut>>Commandes Valider

Utilisateur

<<inclut>>

Gérer Clients <<inclut>>

Les Cas d’utilisation « Suivre Commandes » et « Gérer Clients » ont en commun le comportement décrit par

le cas d’utilisation «Valider Utilisateur »


le cas d’utilisation «Valider Utilisateur ».

Relations entre CU

Relation d’extension :<<étend>>

CU1 CU2

<<étend>>[condition]Une instance

du CU destination

son comportement par l’ajout de celui du CU source (CU2)

CU1 CU2(CU1) étend

source (CU2).Le comportement ajouté est inséré au niveau d’un point d’extension défini dans le CU destinationpoint d extension, défini dans le CU destination.Cette relation permet de modéliser des variantes de comportement d’un CUde comportement d un CU.L'extension est soumise à une condition. La condition d’extension est spécifiée à côté du


La condition d extension est spécifiée à côté du mot-clés <<étend>>

Relations entre CU

Point d’extension :P èd <N d CU>Possède un nom.Décrit un emplacementdans le CU destination

<Nom du CU>Point d’extension

dans le CU destinationoù le comportement du CU source sera inséré.

• <Nom du point d'extension >: <Emplacement>

UML ne définit aucun format de description Passer

Commandede point d’extension.Exemple :

Commande

<<étend>>

Gérer Panier

Internaute


Gérer Panier

Relations entre cas d’utilisation

Relation de généralisation :

CU Parent

CU Enfant

Le CU enfant hérite du comportement du CU parent. Le CU enfant peut compléter ou remplacer leLe CU enfant peut compléter ou remplacer le comportement du CU parent.



Exemplep

Internaute Rechercher ouvrages

Effectuer Eff t recherche

g

Effectuer recherche rapide

Effectuer recherche

Effectuer recherchepar thème

Effectuer recherche avancée



ExemplepConsidérons les règles de gestion suivantes :

Un client peut être distant ou localUn client peut être distant ou local.Un client distant effectue ses virements par Internet.Les virements par Internet sont des cas particuliersLes virements par Internet sont des cas particuliers de virements.Tout type de virement nécessite une identificationTout type de virement nécessite une identification du client.Dans le cas où le montant du virement dépasse 500Dans le cas où le montant du virement dépasse 500, on est obligé de vérifier le solde du compte du client.


Relations entre CU

Modélisation des CU de l’exemple :

Cli t

Virement

<<étend>>

Client

<<Inclut>>

étend[Montant > 500]Client

Local

Client Distant

Identification Vérification solde compte

VirementI t t


solde compteInternet

Processus d'élaboration du diagramme des CUg

1. Définir un guide de style pour la rédaction des CU qui contient :contient :

la mise en page des CU,le ni ea de détaille niveau de détail,un modèle de CU.

2 Id ifi l i di l l è2. Identifier les acteurs qui dialoguent avec le système. Les acteurs possibles sont les :

les groupes qui exigent un certain comportement ou− les groupes qui exigent un certain comportement ou− ceux dont on a besoin pour accomplir les fonctions

du système.y3. Organiser les acteurs en identifiant les rôles généraux

et les rôles spécialisés.


Processus d'élaboration du diagramme des CUg

4. Pour chaque acteur, identifier globalement les CU en les décrivant par une ou deux phrases et en distinguant le cas nominal des variantes.

5. Approfondir la compréhension et la description de chaque CU :

Dét i l é i t l diti dDéterminer les scénarios et les conditions de différenciation entre scénarios, à partir de la connaissance du domaine et des rencontres avec les utilisateurs.

6. Appliquer les relations d'inclusion et d'extension pour pp q pfactoriser les comportements communs et distinguer les cas qui étendent les scénarios nominaux.


Conseils

Il faut se rappeler qu'un CU est une abstraction d'un pp qensemble de comportements fonctionnellement liés :

La présence d'un grand nombre de détails est le signe d'un é i l d' CUscénario plus que d'un CU.

Un grand nombre de CU est le signe d'un manque d'abstraction.d abstraction.

Quelles que soit la taille et la complexité d'un système, il y a relativement peu de CU, mais beaucoup de scénarios.p , pUn grand nombre de CU signifie que les objectifs du système ne sont pas bien compris.Dans la description d'un CU, il ne faut pas aller expliquer comment le système réalise les interactions avec l'acteur.


Exemple récapitulatif

Fonctionnement des caisses enregistreuses gd’un super marché :

Un client arrive à la caisse avec des articles à payer.Le caissier enregistre le numéro d’identification de chaque article, ainsi que la quantité si elle est > 1.La caisse affiche le prix de chaque article et son libellé.Quand tous les achats sont enregistrés, le caissier signale la fin de la vente.La caisse affiche alors la fin des achats et le prix total à payer.



Fonctionnement des caisses enregistreusesFonctionnement des caisses enregistreuses d’un super marché (suite) :

Après la saisie des articles le client peut présenterAprès la saisie des articles, le client peut présenter des coupons de réduction pour certains articles.Le client choisit son mode de paiement :Le client choisit son mode de paiement :

Liquide : le caissier encaisse l’argent reçu, la caisse indique le montant à rendre au client.qChèque : le caissier vérifie la solvabilité du client, en transmettant une requête à un centre d’autorisation i l ivia la caisse.

Carte de crédit : un terminal bancaire fait partie de la caisse et transmet une demande d’autorisation en


caisse et transmet une demande d autorisation en fonction du type de la carte.


Fonctionnement des caisses enregistreusesFonctionnement des caisses enregistreuses d’un super marché (suite) :

La caisse enregistre la vente et imprime le ticket.La caisse enregistre la vente et imprime le ticket.Le caissier donne le ticket au client.Quand le paiement est terminé, la caisse transmet Q p ,l’information sur les articles vendus au système de gestion des stocks.Chaque matin, le responsable du magasin initialise les caisses pour la journée.

D l di d d’ tili tiDonner le diagramme de cas d’utilisationrelatif au passage d’un client à la caisse. Donner les scénarios relatif à ce diagramme


Donner les scénarios relatif à ce diagramme.


Un système de caisse enregistreuses de super marché :

Initialiser les caissesGestionnaire Prendre en compte coupons<<ét d>>Gest o a ecaisse Prendre en compte coupons<<étend>>

[Client présente des coupons]

<<Acteur>>Gestion des

stocksCaissier Traiter le passage en caisse

<<inclut>><<Acteur>>

Centre autorisation

cartesClient

Traiter le Paiement cartes

<<Acteur>>Centre

autorisation

Traiter le Paiement

P i t C t


autorisationchèquesPaiement Chèque

Paiement CartePaiement Liquide


Sommaire d’identification

Titre : Traiter le passage en caisseRésumé : un client arrive à une caisse avec des articles à acheter.

L i i i t l h t t é è l i tLe caissier enregistre les achats et récupère le paiement. A la fin de l’opération, le client part avec les articles.

Acteurs : Caissier (P), Client (S), Gestion des stocks (S)Date de création : …………….…. Date de mise à jour : ………………Version : 1 Auteur(s) : ……………………………….………………

Description des Enchaînements :Description des Enchaînements :Pré-conditions : La caisse est en service : un caissier y est connectéScénario nominal :

Représente le déroulement normal d’un cas d’utilisation : les différentes interactions utilisateur / système

permettant l’exécution réussie du traitement.


(voir suite)


1. Ce CU commence quand un client arrive à la caisse avec des articles

Utilisateur Système

arrive à la caisse avec des articles qu’il veut acheter.2. Le caissier enregistre chaque article.

3. La caisse détermine le prix de l’article et ajoute les informations de

S’il y a plus d’un exemplaire par article, le caissier indique également la quantité.

jl’article à la vente en cours.La caisse affiche la description et le prix de l’article en question.

4 Après avoir enregistré tous les 5 La caisse calcule et affiche le4. Après avoir enregistré tous les articles, le caissier indique que la vente est terminée.

5. La caisse calcule et affiche le montant total de la vente.

6. Le caissier annonce le montant total au client.7. Le client choisit le type de

paiement :En cas de paiement en liquide

8. La caisse enregistre la vente et imprime …

a. En cas de paiement en liquide …b. En cas de …c. En cas de …9. Le caissier donne le ticket de


9. Le caissier donne le ticket de caisse au client.


Enchaînement alternatif :Quand l’enchaînement précisé par le scénario nominal ne peut pas se dérouler comme prévu :p p p

Le cas d’utilisation converge tout de même.Exemple :p

Numéro d’identification d’un article est inconnu :L’enchaînement démarre au point 2 du scénario nominalL enchaînement démarre au point 2 du scénario nominal.3. La caisse indique que le numéro d’identification de

l’article est inconnu. L’article ne peut pas alors être pris p p pen compte dans la vente en cours.

Le scénario reprend au point 2.



Enchaînement d’erreur :Quand l’enchaînement précisé par le scénario nominal ne peut pas se dérouler :

Le cas d’utilisation se termine par un échec.

Exemple :Client ne pouvant payer (ou le centre d’autorisation refuse le payement) :

L’ h î t dé i t 6 d é i i lL’enchaînement démarre au point 6 du scénario nominal.7. Le client ne peut pas payer le total avec aucun des moyens

autorisés.8. Le caissier annule l’ensemble de la vente et le cas d’utilisation

se termine en échec :la vente ne peut pas avoir lieu


la vente ne peut pas avoir lieu.

Conclusion

Les cas d’utilisation :Sont de bons moyens pour modéliser les besoinsdes utilisateurs par les utilisateurs.pLes avantages :

Un formalisme simple :Un formalisme simple :Les concepts proposés sont faciles à comprendre et à utiliser.

Les résultats de la modélisation (Les diagrammes de CU) :

F il à d à li t à i t étFaciles à comprendre, à lire et à interpréter.Un bon moyen de communication : utilisateur/analyste et analyste/concepteur


utilisateur/analyste et analyste/concepteur

Conclusion

Les cas d’utilisation :Les limitations :

Ne sont pas formels : pas de vérification automatique p p qpossible, ni de génération d’autres diagrammes, …Pas de standard pour la représentation des CU.

Remarque :Il ne faut pas confondre

« cas d’utilisation » et « algorithme »



V Diagrammes de CollaborationV. Diagrammes de Collaborationou de communication


[email protected]

Rafik BOUAZIZ -- Faïez GARGOURIFSEGS Sfax ISIM Sfax


FSEGS – Sfax ISIM – Sfax

Introduction

Les cas d’utilisation (CU) ont permis :aux utilisateurs d’exprimer leurs besoins, etde dresser une première liste des intervenantsp(objets et acteurs) constituant le système.

L’analyse des besoins a nécessité le recensement de l’ensemble des traitements demandés par pl’utilisateur (Que faire).

Il faut maintenant détailler ces besoins parIl faut maintenant détailler ces besoins par les informaticiens (Comment faire).


Introduction

Les cas d’utilisation ont permis de spécifier les p ptraitements :

Préciser comment les intervenants doiventPréciser comment les intervenants doivent travailler ensemble pour réaliser chaque besoin.

L i t t t l tè d i tLes intervenants composant le système doiventcollaborer pour réaliser les besoins exprimés par les CUCU.

Les diagrammes de collaboration (appelés aussi de communication dans UML-2).aussi de communication dans UML 2).


Sémantique

Les diagrammes de collaboration sont des gdiagrammes d'interaction qui représentent une vue dynamique du système.Un diagramme de collaboration :décrit le comportement collectif d’un ensemble p

d’objets,en vue de réaliser une opération, un CU ou tout un diagramme de CUdiagramme de CU,

en décrivant leurs interactions modélisées par des envois (éventuellement numérotés) de messages.envois (éventuellement numérotés) de messages.


Sémantique

Les diagrammes de collaboration présentent :g pdes rôles joués par des objets dans un contexte particulier, et ples liens entre ces objets.

Ces liens impliquent des associations entre les classes correspondant à ces objets dans le p jdiagramme de classes.


Sémantique

Représentation Générale :

1 : événement 2 O é i 13: Opération2 (paramètre)

Objet 1 :nom classe Objet 2

1 : événement 2 : Opération1

4 : Opération3

5 : Opération4 (paramètres)Objet 3 :Nom de classe

5 : Opération4 (paramètres)Nom acteur

:Nom de classe

Flux de données

(Réponse à opération4)


Sémantique

Les diagrammes de collaboration permettent :une représentation spatiale des objets et des liens, par un graphe dont , p g p

les nœuds = intervenants et les arcs = les interactions ;

une représentation temporelle limitée(ordre de déclenchement), ( )

par l’ajout de numéros de séquence des messages échangés. C d t é t i l t dCependant, on ne représente ni le temps de déclenchement, ni la durée de ces échanges.


Sémantique

L’objectif est de construire un modèle expliquant laL objectif est de construire un modèle expliquant la coopération entre les objets pour la réalisation d’une fonctionnalité (d’un CU ou d’un DCU).( )Une collaboration définit les éléments (objets et liens) utiles pour l'obtention d'un objectif particulier, en p j p ,spécifiant le rôle de ces éléments dans le contexte de la collaboration et les envois de messages entre eux.Les objets participant à une collaboration sont représentés par leur nom, leur rôle et/ou leur classed'appartenance.


Interprétation des représentations graphiques

:C Un objet anonyme de la classe C :PERSONNE

/R:C Un objet anonyme de la classe C /Lecteur:PERSONNE/R:C jouant le rôle R /Lecteur:PERSONNE

/R Un objet anonyme jouant le rôle R /Lecteur

O/R:CUn Objet O, instance de la classe C, jouant le rôle R Ali/Lecteur:PERSONNE


Exemple

1: RevenuDeLocation(pourLesMaisons)

/Loueur : PERSONNE

1: RevenuDeLocation(pourLesMaisons)

:GERANT 1.1 *[i:=1..n]:Loyer()

:LOCATION1.1.i : Valeur()

/Loué:LOGEMENT

L é t ti d’ t d di dLa représentation d’un acteur dans un diagramme de collaboration permet de montrer le déclenchement des interactions par un élément externe au système


interactions par un élément externe au système.

Messages et envois de messages

Un message est la matérialisation d'une communication( d l ll d i f ti t tt t)(au cours de laquelle des informations se transmettent) pouvant permettre l'obtention de résultats.U i d t é tt t é tUn envoi de message entre émetteur et récepteur nécessite que le récepteur puisse réaliser l'activité définie par le messagedéfinie par le message.



Les catégories d'envoi de messages sont :Appel d'une opération ou flot de contrôle emboîté.

U édit

L’expéditeur invoque une opération du destinataire

:Un destinataire:Un expéditeurOpération()

L’expéditeur invoque une opération du destinataire.

- Les objets qui contrôlent le flot sont dits actifs. - Un objet actif peut activer un objet passif en lui envoyant un message. Une fois le message traité le flot de contrôle est- Une fois le message traité, le flot de contrôle estrestitué à l'objet actif.



Flot de contrôle asynchrone :

:Un destinataire:Un expéditeur

Envoi asynchrone : Le message est envoyé sans attendre la fin de l’opération invoquée.

Flot de contrôle à plat : progression non procédurale

:Un destinataire:Un expéditeur

Un messageGénéralement utilisé pour modéliser les


échanges entre acteurs et systèmes.

Interactions

Une interaction définit la communication entre les instances des éléments d'une collaborationsous forme d'un ensemble partiellement ordonné de messages.Les éléments d'une interaction sont :Les éléments d une interaction sont :

les instances (objets de classes), l li i li t l i tles liens qui relient les instances, les messages qui déclenchent les opérations,les rôles joués par les extrémités des liens.


Interactions

Les diagrammes de collaboration montrentgsimultanément :

les interactions etles interactions et les liens structurels qui permettent ces interactions.


Interactions

Les objets et les liens créés ou détruits au cours d' i t ti t ti t td'une interaction peuvent respectivement porter des contraintes :

{nouveau} : l'instance ou le lien est créé pendant l'exécution de l'interaction.{détruit} : l'instance ou le lien est détruit avant la fin de l'exécution de l'interaction.{transitoire} : l'instance ou le lien est créé pendant l'exécution de l'interaction, mais détruit avant la fin d tt é tide cette exécution.


Interactions

On peut représenter un envoi répétitif de p p pmessages (éventuellement en parallèle) entre un objet et une collection d'objets d'une classe.

Approche intéressante lorsqu'un groupe d'objetsest, dans son ensemble, traité de manière uniforme., ,

:CLASSE


Interactions

On peut représenter hors d'un groupe d'objets, p p g p j ,un objet particulier, en tant que composant de l’un de ces objets, pour lui appliquer des messages particuliers.

L'objet est associé au groupe via un lien de j g pcomposition :


Interactions

Diagramme de collaboration relatif au

C CONCOURS1: d :=SélectionDossier (numéro dossier)

CU Réception de candidature

: ScolaritéConcours courant : CONCOURS

1.1: Sélection (numéro dossier)

{ }: DOSSIER

2: Création (informations)

{nouveau}I : INSCRIPTION{nouveau}

Lien de composition

d : DOSSIER


Syntaxe détaillée des messages

La syntaxe d'un message est la suivante :

[Synchronisation] Séquence : [Résultat :=][Synchronisation] Séquence : [Résultat :=] Nom_message [(Arguments)]

Séquence : indique le niveau d'emboîtement de l'envoi de message : g

Le premier message commence généralement par 1.par 1.

Si les messages suivants sont de même niveau, leur séquence est incrémentée (2 3 )


leur séquence est incrémentée (2, 3, …).

Syntaxe détaillée des messagesy g

Si des messages sont déclenchés par un autre message (par exemple des appels de procédures emboîtés dans l’appel englobant 2),

leurs numéros de séquence sont composésleurs numéros de séquence sont composésà partir du message englobant (2.1, 2.2, …).

Le numéro de séquence peut être suivi d'uneLe numéro de séquence peut être suivi d'une lettre s'il y a des messages concurrents : (1.2a, 1.2b).(1.2a, 1.2b).

Une séquence peut contenir une itération.Exemple : 1 2 *[i:=1 n]: MessageExemple :

: A1.2 *[i:=1..n]: Message

1.2 *||: Message: Bou



L’ itération *[i:=1..n]: sous-entend l'envoi séquentiel[ ] qde messages.L'itération parallèle est représentée par *||

Une séquence peut contenir une conditionExemple : 1.1 [x>y]: m1Exemple :

1 1 [S ld >Mt] Eff t Vi t(Mt)

: A : B1.1 [x y]: m1

: CLIENT : COMPTE1.1 [Solde>Mt]: EffectuerVirement(Mt)

Le message EffectuerVirement n'est envoyé que si la condition est vérifiée.



Résultat : une liste de valeurs retournées par un message. Ces valeurs peuvent être utilisées comme paramètres pour les autres messages de l'interaction.

1.1: Rép := Question(): A : B

Une valeur de retour peut aussi être représentée

: A

Une valeur de retour peut aussi être représentée graphiquement

1.1: Question()()Rép

: A : B



Nom_message : correspond généralement à une opération définie dans la classe de l'objet destinataire du message.Encapsulation : Question est une opération publique de B.

1.1: Rép := AfficherSolde()p (): CLIENT : COMPTE

AfficherSolde est une opération publique de la classe Compte



Arguments : liste des paramètres du messageséparés par des virgules.

E l 1.1: Message (p1, p2)Exemple : 1.1: Message (p1, p2): A : B

Les arguments peuvent aussi être représentés hi tgraphiquement.

p1 p21.1: Message

p1, p2: A : B



S h i ti L i t d h i ti tSynchronisation : Le point de synchronisation est exprimé sous la forme d'une séquence d'envois de messages terminée par '/'messages, terminée par / .

Il faut avoir envoyé tous les messages de la listeavant de pouvoir envoyer le message considéréavant de pouvoir envoyer le message considéré.

A1, B3 / C1: Message: A : B

A1 et B3 sont envoyés avant C1



Exemple récapitulatif : Diagramme de collaboration l’é l ti d’ t k d d itpour l’évaluation d’un stock de produits.

Auditeur E al er StockCU

1 Total Vale rStock()

Auditeur Evaluer StockCU :DC :

:ENTREPRISE1:Total :=ValeurStock()

2: Afficher(Total) :SRéel1.1.1: Créer(0)1.1.2.i: Ajout(P)1.1: CalculValeur()

:Auditeur

:STOCK:AFFICHEUR :PRODUIT

1 1 2 * [i 1 ] P V l P()


1.1.2 * [i:=1..n]: P:=ValeurP()

En résumé

Remarques :Remarques :Les scénarios et les règles de gestion permettent de détailler les diagrammes de CU en diagrammesde détailler les diagrammes de CU en diagrammes de collaboration.

L t d di d d’ tili tiLes acteurs du diagramme de cas d’utilisationsont aussi présents au niveau du diagramme de collaboration :collaboration :

Ils permettent d’initier les interactions.


En résumé

Remarques :Les cas d’utilisation donnent lieu à un ou plusieurs messages échangés entre les intervenants du di d ll b idiagramme de collaboration :

On détaille les cas d’utilisation en précisant les différents échanges de messagesdifférents échanges de messages.

Il y a plus d’intervenants et de liens au niveau du diagramme de collaboration qu’au niveau dudiagramme de collaboration qu au niveau du diagramme de cas d’utilisation :

Conséquence normale de la spécification détailléedes cas d’utilisation.



VI. Diagrammes de Séquence


[email protected]

Rafik BOUAZIZ -- Faïez GARGOURIFSEGS – Sfax ISIM – Sfax


Introduction

Les diagrammes de collaboration ont permis de :détailler les scénarii des diagrammes de CU ;préciser comment les objets et les acteurs doivent collaborer ensembles pour réaliser les CU.

Les diagrammes de séquence (DS) :g q ( )Explicitent la dimension temporelle évoquée dans les diagrammes de collaboration,gse concentrent sur la séquence des messages envoyés entre les objets (c.à.d. quand et commentles messages sont envoyés et reçus par les objets qui participent à une interaction)


Définition

Le diagramme de séquence :montre les interactions entre objets, comme le diagramme de collaboration,se concentre sur la séquence des envois de message selon un point de vue temporel(l i t t d dé t t d’ i é t l d é d(les instants de départ et d’arrivée et la durée de l’envoi),

t l t à déli l' t d i d'est plus apte à modéliser l'aspect dynamique d'un scénario complexe mettant en œuvre peu d'objets.

La plupart des éléments utilisés par les diagrammes de collaboration sont aussi utilisés


par les diagrammes de séquence.

Représentation générale

O1 :C1 O2 :C2

Message-1t1t2

Message-2 Message-3t2t1<t2 Message-4

Chaque objet est matérialisé par un rectangle et une barre verticale appelée ligne de vie.

L'ordonnancement horizontal des objets n'a pas de significationL ordonnancement horizontal des objets n a pas de signification particulière, mais vise à améliorer la présentation des interactions.L'objet qui débute l'interaction se place à gauche.La dimension verticale représente l'écoulement du temps. Elle peut être graduée afin d'exprimer des contraintes temporelles.L'ordre d'envoi des messages est donné par la position de ces


L ordre d envoi des messages est donné par la position de ces messages sur les lignes de vie des objets.

Activation et envoi de messages

Les diagrammes de séquence permettent de représenter g q p ples périodes d'activité des objets. Un objetUne période d'activitépcorrespond au temps pendant lequel un objet effectue une action soit directement soit paraction, soit directement, soit par l'intermédiaire d'un autre objet.

A BMessage

Exemple d'objet qui active un autre : g

dans cet exemple :La période d'activité de A

recouvre celle de B


recouvre celle de B


La syntaxe des messages échangés entre les objets est la même que celle des diagrammes de collaborationest la même que celle des diagrammes de collaboration.La numérotation des messages est optionnelle. Elle est plutôt remplacée par l’ordre d’apparition desest plutôt remplacée par l ordre d apparition des messages (ligne verticale).

O1 O2

t1 Message()Hypothèse par défaut :

Temps d'envoi de t1

t2

g ()

Opération(Arg)t2 > t1 Message() par O1

=Temps de réception

T

p pde Message() par O2

=t1


Temps t1


Un message peut être réflexif : :COMPTE

VérifierSolde()

Les types d'envois de messages :Flots de contrôle à plat.Appel d’opération (dit aussi de procédure) ou flot de contrôle emboîté.R t d’ l d édRetour d’un appel de procédure.Flot de contrôle asynchrone : Envoi asynchrone, le message est envoyé sans attendre la fin de


message est envoyé sans attendre la fin de l’opération invoquée.


Les flots de contrôle à plat :indiquent la progression vers la prochaine étapeq p g p pd’une séquence.Les messages de cette catégorie sont asynchrones signalés par une flèche simplesignalés par une flèche simple.



Exemple : Diagramme de séquence du CU « Effectuer une commande »« Effectuer une commande »

: Internaute:Librairie électronique : Service: Internaute : Service

ClientsCommander( )Formulaire de commande

SaisirInfos( )

Ré it l tif dRécapitulatif commande

Valider( ) Commande validée( )Confirmation


Un résultat


Exemple : Diagramme de séquence du CU « Effectuer une commande »« Effectuer une commande »

: Internaute:Librairie électronique : ServiceRemarques :

: Internaute : Service Clientscommander( )

formulaire de commande1. L’objectif est ici de représenter l’enchaînement des

envois de messages entre les intervenants : expliciter

saisirInfos( )

é it l tif d

les CU.

2. Il s’agit du scénario nominal du cas d’utilisation récapitulatif commande

valider( ) commande validée

Effectuer une commande.

3. Absence de la période d’activité.( )confirmation

commande validée4. Les temps d’envoi = temps de réception de tous les

messages.


Un résultat


Appel de procédure ou flot de contrôle emboîté :é l d l ôl iLa séquence appelante ne reprend le contrôle que si

celle emboîtée se termine.Les messages de cette catégorie sont signalés parLes messages de cette catégorie sont signalés par une flèche pleine.

O1 O3O2Procédure Sous procédure

• O2 récupère le contrôle quand O3 termine sa tâche. • O1 récupère le contrôle quand O2 termine sa tâche.• La fin de la sous-procédure est signalée par la fin de la durée de

O


l’activation de O3.


Exemple :

:COMMANDE :CATÉGORIE:CLIENTN° CdeD Cd

N° ClientAdresse Client

:COMMANDE :CATÉGORIE:CLIENT

CréerClt() CréerCat()

Date Cde

N° CatégorieIntitulé Catégorie

Taux remiseN° Produit …N ProduitQté Cdée,

…



Retour d’un appel de procédureLe retour d'une opération est implicite à la fin de l’activation de l’objet receveur.

M i l t ti "Ré M " t êt tili éMais la notation "Rés := Message" peut être utilisée pour représenter les flots de retour.

L fl t d tt té i t i êt i léLes flots de cette catégorie peuvent aussi être signalés par une flèche en pointillé.

Expéditeur Destinataire

Calculer()


Val:=Calculer()

Val⇔


Val est retournée à Expéditeur


Exemple : Diagramme de séquence du CU MAJ stock produit

:FenêtreProduits :Stock :ProduitMAJStock(Référence, Qté)

Rép:= Existe(Référence)

si (Rép=vrai) alorssi (Rép=vrai) alors

sinon"Produit n’existe pas" Créer(Référence, Intitulé)

MAJ(Référence, Qté)

Produit n existe pas , nouvellement créé

Initialiser(Référence, Qté)


La ligne de vie des objets

La ligne de vie d’un objet,i t é té li i tilléqui est représentée par une ligne en pointillé,

peut débuter et s’interrompre dans un diagramme :Si l’objet est créé et/ou détruit pendant la duréeSi l objet est créé et/ou détruit pendant la durée définie par le diagramme spécifié.

Un objet

Créer()Créer() Un autre objet…

Détruire()

X L fi d i


X : La fin de vieTemps

Contraintes temporelles

Cas où le délai de transmission d’un message est non négligeable : flèche représentée obliquementnégligeable : flèche représentée obliquement


tExpéditeur Destinataire

Délai t’- t

tt’

Les contraintes temporelles peuvent être représentées dans la marge en nommant les instants d’émission des messages.

Objet 1 Objet 3Objet 2

X{y x < 2s}

Message1

Y{y-x < 2s}

Message2


Message2 doit être envoyé au plus deux secondes après Message1

Contraintes temporelles

Pour exprimer les contraintes temporelles, on peut utiliser des :utiliser des :

annotations temporelles (temps : message)fonctions temporelles (TempsEnvoi, TempsRéception, …)

Exemple :: Porte: Ascenseur usager

Déplacement vers l’étage d’appel

(pas d’autres appels)

Appel extérieur

Déplacementt

{ > 8s }

(pas d autres appels) a:ouvertureb:ouverte

F t

{b.TempsRéception -a.TempsEnvoi < 5 s.}

Ouvrir()

* { > 8s }Fermeture

FerméeL’usager peut

prendre l’ascenseurPréciser l’étage

Fermer()

*


Déplacement

Structures de contrôle

Contrôle centralisé (I) et Contrôle décentralisé (II)

A B C D A B C D

(I) (II)A centralise les envois de L’envoi de messages est

dé t li é


messages décentralisé


Les diagrammes de séquence peuvent être g q pcomplétés par des indications textuelles exprimées sous forme de texte libre ou pseudo-code.Représentation de la boucle While :

O1 O2

MWhile X

O1 O2

*[X] MessageMessageloop

End loop

*[X] Message⇔d oop

X = condition(s)


( )


Exemple :

While ¬RéponsePolice

:SystèmeSurv :PosteDePolice

e épo se o celoop

End loopSOS()

⇔

p

* ¬ é

:SystèmeSurv :PosteDePolice

*[¬RéponsePolice] SOS()



Branchements conditionnels :Si X = Vrai Aors

A B CSi X = Vrai Aors

Envoyer(A, B, Message1) Sinon

If XElse

Message1

Message2

Envoyer(A, C, Message2)FINSI

End Ifg

Ou bienbien

A

[X] Message1

B C A

[X] Message1

B C

[X] Message1

[non X] Message2

[X] Message1

[non X] Message2



Traitement alternatif d'un message reçu :Les branchements alternatifs, du côté du destinataire du message, sont représentés en dédoublant la ligne de vie du destinataire.g

:Abonné :Livre :Responsable

Retourner [bon état ] C

Retourner [mauvais état] Informer ()

C Ch l’é d li di ibl


C : Changer l’état du livre : disponible


Traitement alternatif d'un message reçu :Les branchements conditionnels, du côté du destinataire du message, sont représentés en dédoublant la ligne de vie du destinataire.

1. Les deux périodes d’activation du Livrecorrespondent à des actions différentes réalisées par

tt l f ti d l ditig

:Abonné :Livre :Responsablecette classe en fonction de la condition.

2. La condition est exprimée après le message pour dire Retourner [bon état ]

*qu’elle sera vérifiée à la réception du message et

non à son envoi.

Retourner [mauvais état] Informer ()

* h l’é d li di ibl


* : changer l’état du livre : disponible

Remarques

Les diagrammes de séquence :g qsont un bon moyen pour représenter les interactions, organisées dans le temps, entre les objets ;s’approchent davantage de l’implémentation avec l’utilisation des boucles, des structures de contrôles, … ;permettent de détecter les erreurs qu’on ne voit d’habitude qu’au niveau de l’implémentation : i t bl d’ linterblocage d’appels, … ;conviennent bien aux applications critiques et temps réelréel.


Exemple

Organisation d’une conférence internationale.

<<Inclut>>1 2Considérons les Règles de gestion suivantes :

L ité d’ i ti d l à1 2- Le comité d’organisation adresse un appel à communication aux auteurs intéressés par les thèmes de la conférence.

<<Inclut>>

thèmes de la conférence. - Un auteur soumet un papier décrivant ses travaux dans l’un des thèmes de la conférence.

<<Inclut>>3 4

dans l un des thèmes de la conférence. - Un comité de programme est responsable de l’affectation des papiers reçus à des examinateursl affectation des papiers reçus à des examinateurs spécialisés pour évaluation.- Chaque examinateur évalue les papiers attribués


q p ppar le comité de programme.

Exemple

Le diagramme de cas d’utilisation est comme suit :

1 2

Comité d’organisation

Appel aux auteurs

Soumission d’un papier

Auteurd organisation

3 4

Affectation examinateurs

Comité de programme

ExaminateurEvaluation d’un papier


Exemple

Le diagramme de collaboration correspondant est :2.1 : Rédiger

2.2 : Envoi de papier

:Comité d'organisation:Auteur 1 : Appel à communication

3 : Adresser le papier

:Comité programme

6 : Affecter Examinateur

5 : Papier enregistré

7.1 : Evaluer4 : Enregistrer()

6 : Affecter Examinateur

:PAPIER

:RAPPORT7.2 : Noter

:Examinateur


:PAPIER

Exemple

Le diagramme de séquence correspondant est ::Comité de programme

:Comitéd'organisation

PAPIER

:Auteur

Appel( )

:Examinateur

:PAPIER

Envoi(Papier) Rédiger( )

Adresser Papier(RéfPapier)

Papier enregistré

Enreg_Papier(true)

:RAPPORT

g

Affecter_Lecteur(RéfPapier)

Evaluer(RéfPapier )

Rédiger(RéfPapier )Papier évalué


Conclusion

Les diagrammes de CU : besoins des utilisateursd’ iè b t itd’une manière abstraite.Les diagrammes de collaboration : ont explicité les CU en montrant les différentes collaborations (sousCU en montrant les différentes collaborations (sous forme d’échanges de messages) entre les différents acteurs.Les diagrammes de séquence : ont explicité la dimension temporelle et ont permis aussi d’exprimer les contraintes temporelles dans les envois de pmessages.Les diagrammes de collaboration et de séquence :diagrammes d’interactiondiagrammes d interaction.



VII. Diagrammes d’activitésg

Rafik BOUAZIZ -- Faïez GARGOURIFSEGS – Sfax ISIM – Sfax


Introduction

Un diagramme d’activités (DA) représente le flotUn diagramme d activités (DA) représente le flot d’une activité à l’autre.

Les activités sont non atomiquesLes activités sont non atomiques. Elles consistent à exécuter une séquence d’actions composée de calculs atomiques quid actions, composée de calculs atomiques qui aboutissent :

à un changement de l’état du système et/ouà un changement de l’état du système et/ou au retour d’une valeur.


Introduction

Le DA est une variante duLe DA est une variante du diagramme d’états - transitions (DET) :

Dans le DET les états et les transitions sont misDans le DET, les états et les transitions sont mis en avant, Alors que dans le DA se sont les activités et lesAlors que dans le DA, se sont les activités et les transitions qui sont mises en avant. Le DA utilise beaucoup d’éléments du DETLe DA utilise beaucoup d’éléments du DET.

Un DA correspond à un diagramme d’états vu sous forme « procédurale », avec une mise en évidence des actions/activités (d’où son nom).


Introduction

Un diagramme d’activités peut être rattaché à un CU à DCU à l é li ti d’ é ti àCU, à un DCU, à la réalisation d’une opération, ou à un processus impliquant l’utilisation d’un ou de plusieurs objetsplusieurs objets.Tous les mécanismes dynamiques peuvent être décrits par un diagramme d'activités mais seuls lesdécrits par un diagramme d activités, mais seuls les mécanismes complexes méritent d'être représentés(faisant intervenir plusieurs objets, créant ou ( p j ,modifiant divers objets, …).

Une activité : plusieurs actionsUne activité : plusieurs actions.DA : représente l’enchaînement des différentes activités.

La fin d’une activité engendre le début d’une autre


La fin d une activité engendre le début d une autre.

Les états d’action (et d’activités)

Un état d’action modélise une étape dans l’exécution pd’un algorithme ou d’un flot.C’est un état simplifié dans lequel figure une action p q gd’entrée et duquel part au moins une transition vers un autre état, déclenchée par la fin de l’action.

Etudier devis Index = recherche(e)+7Etudier devis Index = recherche(e)+7

Exemples d’états d’actionp


Les transitions

Une transition peut être automatique ou gardée.Une transition automatique est franchiequand l’activité précédente est finie.q p

ActivitéDemande dossierActivité dossier

Recevoir dossier

Autre ActivitéCompléter

d iTransitions automatiques

dossier

Enregistrer


Enregistrer

Les transitions

Une transition gardée est franchie quand l’activité précédente est finie et si la condition est vérifiée

/i=0Examen

précédente est finie et si la condition est vérifiée.

Afficher(i)

/i=0candidature

[rejetée] [retenue][i<10]/ i=i+1[sinon]

Rédiger lettre de refus

Envoyer convocation

Transitions gardéesLe niveau d’abstraction d’un DA peut être :

(I) (II)


Le niveau d abstraction d un DA peut être : de haut niveau (I) ou de bas niveau (II) : algorithmique

Synchronisation

Il est possible de synchroniser les transitions à l'aide de barres de synchronisation (BS)l aide de barres de synchronisation (BS).

Une BS permet d'ouvrir et/ou de fermer des branches parallèles au sein d'un flot d'exécution.branches parallèles au sein d un flot d exécution.Les transitions qui partent d'une barre de synchronisation ont lieu en même temps.

Activité 1

Activité 2

Activité 1

Activité 3

La fin de A1 engendre les débuts simultanés

de A2 et A3Activité 2 Activité 3 de A2 et A3


Synchronisation

On ne franchit une barre de synchronisation qu'après réalisation de toutes les transitions qui s'y rattachentréalisation de toutes les transitions qui s y rattachent.

Activité 2Activité 1 Le début de A3 ne se fait

Activité 3que si A2 et A1 sont

terminées

Exemples :

VérifierVérifierEnregistrer Vérifier Dossier

Vérifier situation assuré

gcommande

Etudier dossierPréparer facture

Préparer bon de livraison


Les travées

Les diagrammes d’activités peuvent être découpés g p pen travées (ou couloirs d’activité) pour montrer les responsabilités au sein d’un mécanisme ou d’ i tid’une organisation.Chaque activité appartient à une seule travée,mais les transitions peuvent passer d’une travée à l’autre.Les travées permettent d'organiser un diagramme d'activités

Exemple


couloirs d’activitéLes travées

MagasinierVendeurClient

couloirs d activité

Commander produit

Traiter commande Sortir articles

Expédier commande

Recevoir commande F t li t

Expédier commande

Recevoir commande

Payer Facture

Facturer client

Clôturer commande

Payer Facture


Flot d’objets

Il est possible de faire apparaître les objets dans un DA. Ce sont ceux qui :

initient les actions,sont utilisés ou modifiés par les actions.

Un objet utilisé par une action est visualisé par une flèche en pointillés pointant vers l’état d’action.

Un objet créé ou modifié par une action est j pvisualisé par une flèche en pointillés orientée de l’état d’action vers l’objet.

Il est possible de montrer l’état d’un objet et les valeurs de ses attributs modifiés.


MagasinierVendeurClient

Commander produitDA = DCU + DClasses + D. Collaboration + D. ET

Traiter commande

Sortir articlesC d

Expédier commandec:Commande

[en cours]

Recevoir commande Facturer clientc:Commande

[traitée]

Payer Facturef:Facture

[due]

Cloturer commandef:Facture[payée]


Les DA pour la modélisation des processus métierprocessus métier

Un processus métier (business process) est l’ensemble des activités internes d’un métier dont l’objectif est dedes activités internes d’un métier, dont l’objectif est de fournir un résultat observable et mesurable pour un utilisateur individuel du métier.utilisateur individuel du métier.Exemples : Gérer commandes, Gérer retours, …La modélisation des processus métier fournit leLa modélisation des processus métier fournit le contexte dans lequel les fonctionnalités du SI informatisé seront définies, et leur opportunité., ppLes DA permettent de « formaliser » les processus métier. Les travées permettent de diviser les états ét e es t a ées pe ette t de d se es étatsd’action (ou d’activités) en groupes sur le DA. Un groupe représente l’unité responsable.


Client Exemple de Processus métier :

Demander retour MagasinierService Ventes Comptabilité

pGérer les retours

Attribuer num retour

Expédier article

Recevoir articlea:Article[retourné]

Restocker article

Créditer comptea: Article

[disponible]


Exemple de Processus Recevoir

CommandeNœud Initial ActivitéDébranchement

Processus métier

EnvoyerFDécision Préparer

Commande Facture

[commande urgente ] Arc

Décision p

LivraisonExpresse

LivraisonNormale

RecevoirPaiement

g ]

ClôturerJonctionFusion


ClôturerCommande

Exemple de Processus métier

Service FinancierService CommercialService Logistique

Recevoir commande

FacturerPréparer commande

Recevoir PaiementLivrer commande

Clôturer commande


Les DA pour la modélisation des opérations

On peut développer un DA pour une opération.Dans ce contexte, le DA est un organigramme des actions d’une opération.Le principal avantage d’un DA dans ce cas est que les éléments qu’il contient sont sémantiquement q qliés à un modèle sous-jacent riche.



Pour modéliser une opération, il faut :rassembler les abstractions impliquées dans cette opération :

èt- paramètres, - attributs de la classe d’appartenance de l’opération,

et certaines classes voisines ;- et certaines classes voisines ;identifier les préconditions à l’état initial de l’opération et les postconditions à son état finall’opération et les postconditions à son état final, ainsi que les invariants qui doivent se maintenir pendant l’exécution de l’opération ;pendant l exécution de l opération ;spécifier les activités et les actions, en commençant par l’état initial.


par l état initial.


Lorsque cela est nécessaire utiliser les

[pente=l.pente]nécessaire, utiliser les branchements conditionnels et les itérations. x= (l.delta-delta)/(pente-l.pente)

[sinon]

Si l’opération appartient à une classe qui peut en

( ) (p p )

y=(pente*x)+deltaactiver d’autres, utiliser la synchronisation. Retourner Point(x, y)

Retourner Point(0,0)

Modélisation de l’opération intersection (in l: Ligne) : Point de la classe LIGNE


: Point de la classe LIGNE


Les signaux :La réception d’un signal déclenche une activité.La réception d un signal déclenche une activité.

Lors du déroulement d’un flot, un signal peut être émisémis.

Un délai est un signal émis automatiquement.


Autres aspects de synchronisation y

P dPrendre Réservation Recevoir Confirmation

Envoi Billet Enregistrer Vol

OUOU

Annuler Vol

OU

48h

Emission RéceptionEmission d’un signal

Réception d’un signal Délai


DET vs DA

DET D AReprésente l’évolution des objets Représente l’évolution de

l’exécution d’une opération ou d’un CU

Etat (objet) Etat (activité / opération)Etats : initial / Final Etats : initial / FinalTransition (gardée / automatique) Transition (gardée /

automatique)BS BS


Documents

Méthodologie de Conception gp Orientée Objet des …...Objectifs du module Conception OO Les objectifs visés consistent à permettre aux étudiant de: Savoir mettre en œuvre les