Modélisation par UML 1 Denis Laurendeau, P.h.D., ing. Département de génie électrique et de...
-
Upload
ancel-duchesne -
Category
Documents
-
view
117 -
download
5
Transcript of Modélisation par UML 1 Denis Laurendeau, P.h.D., ing. Département de génie électrique et de...
Modélisation par UML
1
Denis Laurendeau, P.h.D., ing.
Département de génie électrique et de génie informatique
Modélisation en langage UML
Modélisation par UML
2
UML: UUnified MModeling LLanguage
• Travail initié par G. BoochBooch et J. RumbaughRumbaugh en 1994• Objectif: unifier les méthodes de modélisation de:
– Booch
– OMT de Rumbaugh
– OOSE de JacobsonJacobson
• Version 1.0 de UML apparaît en Janvier 1997• L ’OMG’OMG a adopté UML comme langage de
modélisation
Modélisation par UML
3
Objectifs de UML
• Modélisation de systèmessystèmes divers en utilisant des concepts orientés objetsconcepts orientés objets
• Établir un couplage entre les conceptsconcepts et leur implantationimplantation
• Aborder la description des problèmes d ’échelleéchelle propres aux systèmes complexescomplexes
• Offrir une approche de description utilisable par les humainshumains et les machinesmachines
Modélisation par UML
4
Usages de UML
• Systèmes d ’informationSystèmes d ’information pour la présentation d ’informations diverses à des usagers
• Systèmes techniquesSystèmes techniques pour la commande d ’équipements
• Systèmes temps-réelSystèmes temps-réel embarqués
• Systèmes répartisSystèmes répartis sur des réseaux (locaux ou non)
• Systèmes logicielsSystèmes logiciels (exploitation, bases de données, interfaces GUI,etc.)
• Systèmes commerciauxSystèmes commerciaux (description de la structure et du fonctionnement des entreprises: règles, stratégies, politiques, etc)
Modélisation par UML
5
Étapes de développement d ’un système• Analyse des besoinsbesoins: recherche des points points
fonctionnelsfonctionnels (Use Cases)• AnalyseAnalyse (recherche des abstractions principales
composant le système: classes et objets)• ConceptionConception des abstractions principales et
implantation d ’abstractions secondaires• ProgrammationProgrammation des abstractions dans un langage
orienté objet• TestsTests du système
Modélisation par UML
6
Types de visualisation dans UML
Composantes
ConcurrenceRépartition
Use-Case
Logique
Modélisation par UML
7
Visualisation « Use Cases »Use Cases »
Use-Case
Modélisation par UML
8
Use casesUse cases• Décrivent la fonctionnalitéfonctionnalité
d ’un système• S’adressent aux clientsclients,
concepteursconcepteurs, responsablesresponsables du développementdéveloppement, responsablesresponsables des teststests
• Un Use Case décrit un point point fonctionnelfonctionnel du système
• Le fonctionnement globalfonctionnement global du système est décrit par l’ensemble des Use Casesl’ensemble des Use Cases
Assuré
Contracter une police d'assurance
Compiler statistiquesdes ventes Assureur
Compiler statistiquesdes clients
Modélisation par UML
9
Use Cases dans UML
• Sont représentés par une ellipseellipse dans laquelle est inscrit le nom du Use Case
• Sont généralement connectés à un acteuracteur avec une association
Symbole UML d ’un Use Case
Symbole UML d ’un acteur
Symbole UML d ’une associationActeur
UseCase
Modélisation par UML
10
Liens entre Use Cases
• « extendsextends » signifie qu ’un Use Case est une spécialisation d ’un autre Use Case plus général. Le Use Case plus spécifique n ’inclut pas nécessairement tout le comportement du Use Case qu ’il spécialise
• « usesuses » signifie qu ’un Use Case utilise intégralement la fonctionnalité du Use Case plus général en plus de lui ajouter des fonctionnalités additionnelles
Modélisation par UML
11
Description d ’un Use Case
• ObjectifsObjectifs du Use Case• FlotFlot des messagesmessages entre l ’acteur’acteur et le Use CaseUse Case• Flot secondaireFlot secondaire des messages entre l ’acteur et le
Use Case• Condition de finCondition de fin pour le Use Case et information information
retournéeretournée à l ’acteur lors qu ’il se termine
Modélisation par UML
12
Qu’est-ce qu’un bon Use Case
• Un bon Use Case représente une fonctionnalitéfonctionnalité du système qui est complètecomplète du début jusqu ’à la fin.
• Un bon Use Case doit normalement apporter quelque chose de valable à un acteur (i.e. un résultat résultat tangibletangible à une de ses commandes ou à une de ses actions sur le système.
• Il n ’y a pas de consensus sur la « grosseurgrosseur » que devrait prendre un Use Case en termes de fonctionnalité.
Modélisation par UML
13
Visualisation « Logique Logique »»
Logique
Modélisation par UML
14
Types de visualisation logique
Visualisation statiquestatique
Visualisation dynamiquedynamique
Modélisation par UML
15
Visualisation statiquestatique
de Classes d'Objets
Diagrammes
Modélisation par UML
16
Visualisation dynamiquedynamique
d'états séquentiels de collaboration d'activité
Diagrammes
Modélisation par UML
17
Vision statiqueVision statique
Diagrammes de classesclasses
Modélisation par UML
18
ClassesClasses et objetsobjets• Une classeclasse sert à décrire de manière génériquegénérique une
catégoriecatégorie d ’objets participant aux actions du système
• Un objetobjet est relié à une classe de la même manière qu ’une variablevariable est associée à un typetype de données dans un langage de programmation procéduralprocédural
• Les fondements de la programmation orientée objet sont les classesclasses, les objetsobjets, et les relationsrelations entre eux.
• Ces classesclasses, objetsobjets, et relationsrelations sont représentés par des diagrammesdiagrammes en langage UMLUML
Modélisation par UML
19
Diagramme de classes
• est un modèle statiquestatique du système• décrit le système en termes de ses classesclasses et des
relationsrelations entre celles-ci• sert de basebase aux autres diagrammes où d ’autres
facettes du système sont décrites (tels les diagrammes d ’états des objets ou les diagrammes de collaboration qui sont des diagrammes dynamiques)
Modélisation par UML
20
Recherche des classes• La recherche des classes est une étape de créationcréation.• pour trouver les classes pertinentes à un problème, il
faut se poser les questions suivantes:– Est-ce qu ’une information doit être analyséeanalysée ou stockéestockée?– Est-ce que le système interagit avec d ’autres systèmes’autres systèmes?– Existe-t-il des patronspatrons, des librairieslibrairies, ou des composantescomposantes
réutilisablesréutilisables dans le système?– Le système doit-il manipuler des périphériquespériphériques
(« devices »)?– Quels rôles les acteursacteurs jouent-ils?– Le système possède-t-il des pièces structuralespièces structurales (parts) (parts)?
Modélisation par UML
21
Types classiques de classes
• EntityEntity: servent à modéliser des catégories d ’objetscatégories d ’objets qui ont une durée de vie importantedurée de vie importante dans le système (i.e. elles sont des parties intégrantes du système)
• BoundaryBoundary: servent à faciliter la communicationcommunication des classes Entity avec l ’extérieur’extérieur du système (soit un autre système, avec l ’utilisateur ou encore avec un périphérique)
• ControlControl: servent à coordonnercoordonner les échanges de messages entre les autres classes pour réaliser un Use case
Modélisation par UML
22
Représentation des classes en UML• une classeclasse est représentée par
un rectanglerectangle divisé en trois trois compartimentscompartiments:– le compartiment du nomnom– le compartiment des attributsattributs– le compartiment des opérationsopérations
• la syntaxe dans les différents compartiments est indépendanteindépendante des langages de programmation
nom
attributs
operations()
Modélisation par UML
23
Compartiment de nom
• Contient le nom de la classe• centré dans le compartiment• imprimé en caractères gras nom
attributs
operations()• Le nom ne doit pas être
ambigu• il doit être tiré du domaine
propre au problème
Modélisation par UML
24
Compartiment des attributs• Les attributsattributs servent à décrire les caractéristiquescaractéristiques
des objets appartenant à la classe (i.e. décrivent l ’état’état de l ’objet)
• chaque attribut possède:– un typetype (primitif ou défini par l ’usager)– un niveau de visibiliténiveau de visibilité (publicpublic (+), protectedprotected (#) ou
privateprivate (-))– une valeur par défautvaleur par défaut– optionnellement, on peut aussi indiquer qu ’un attribut
possède une portéeportée s ’appliquant à la classeclasse (class scope)– …et une chaîne de propriétéschaîne de propriétés indiquant les valeurs que
peut prendre l ’attribut
Modélisation par UML
25
Exemples de classe avec attributs
Auto
noEnregistrement : StringnbRoues : int = 4noPlaque : String
Private(-)
Protected(#)
Public(+)
type
Valeur pardéfaut
Modélisation par UML
26
Compartiment des opérations• Les opérationsopérations permettent de manipulermanipuler les attributs
et d ’effectuer d ’autres actions. Elles sont appelées pour des instances (objets) de la classe.
• La signaturesignature des opérations comprend:– un typetype de retour– un nomnom– 0 ou plus paramètresparamètres (ayant chacun un type, un nom et
possiblement une valeur par défaut)– une visibilitévisibilité (private(-), protected(#), public(+))
• Les opérations constituent l ’interface’interface de la classe avec le monde extérieur
Modélisation par UML
27
Exemple de classe avec opérations
Auto
noEnregistrement : StringnbRoues : int = 4noPlaque : String
getNoPlaque()demarre()pleinEssence()
Méthodes public
Modélisation par UML
28
Spécification de l ’opération
• Pré-conditionsPré-conditions: doivent être vérifiées avant que l ’algorithme ne s ’exécute
• Post-conditionsPost-conditions: doivent être vraies une fois l ’opération complétée
• AlgorithmeAlgorithme: effet que l ’opération a sur l ’objet
Modélisation par UML
29
Relations entre les classes
• Un diagramme de classes montre les classes d ’un système mais également les relationsrelations entre celles-ci:
• On compte quatrequatre principales catégories de relations entre classes:– les associationsassociations– les généralisationsgénéralisations (héritage)– les dépendancesdépendances– les raffinementsraffinements
Modélisation par UML
30
Les associationsassociations de classes
Modélisation par UML
31
Les associations
• Il existe plusieurs typestypes d ’associations:• normalenormale• récursiverécursive• agrégationagrégation par référenceréférence• agrégationagrégation par compositioncomposition
Modélisation par UML
32
Association normale• Une association normale est une connexionconnexion entre classes• elle possède un nomnom• elle est généralement navigablenavigable de manière bidirectionnelle
(dans ce cas elle a un nom dans les deux sens si nécessaire)• elle a une multiplicitémultiplicité• elle peut être dotée de rôlesrôles
Auto
noEnregistrement : StringnbRoues : int = 4noPlaque : String
getNoPlaque()demarre()pleinEssence()
Personne
nom : Stringprenom : StringpermisConduire : Boolean = FALSE
getNom()getPrenom()getPermis()setNom()setPrenom()setPermis()
0..*possede 0..*
+conducteur +autoFlotte
Modélisation par UML
33
Association récursive
• Une classe peut être connectée à elle-mêmeelle-même via une association récursive
• elle représente une connexion sémantiqueconnexion sémantique entre des objets mais avec la différence que ceux-ci appartiennent à la même même classeclasse
ContainerJava
0..*0..*
Modélisation par UML
34
Les agrégationsagrégations de classes
Modélisation par UML
35
Agrégation par référence• Indique une relation tout-tout-
partiepartie• se représente par une ligne
avec un losangelosange du côté « tout » de l ’agrégation. Ce losange ne peut apparaîtra qu ’à une seule extrémité
• elle possède des rôlesrôles, multiplicitémultiplicité, etc, comme une association normale
Wagon
Train
0..*
contient
0..*
Modélisation par UML
36
Agrégation par composition• Indique une relation tout-tout-
partie avec inclusion partie avec inclusion « physique »« physique »
• se représente par une ligne avec un losangelosange pleinplein du côté « tout » de l ’agrégation. Ce losange ne peut apparaîtra qu ’à une seule extrémité
• elle possède des rôlesrôles, multiplicitémultiplicité, etc, comme une association normale
Cytoplasme
Cellule
1
contient
1
Chromosomes
Noyau
11
contient
1..*
contient
1..*
Modélisation par UML
37
Les généralisationsgénéralisations de classes
Modélisation par UML
38
Les généralisations• Une généralisation est une relationrelation entre une classe
généralegénérale et une classe plus spécifiquespécifique• la classe spécifique spécifique est appelée sous-classe sous-classe• la classe générale générale est appelée super-classe super-classe• la sous-classe hérite hérite des attributs attributs et opérations opérations de
la super-classe (en fonction de la visibilité de la généralisation)
• une sous-classesous-classe peut être la super-classesuper-classe d ’une autre classe dans ce que l ’on appelle une hiérarchiehiérarchie
Modélisation par UML
39
Représentationdes généralisations• On représente les
généralisationsgénéralisations par une flècheflèche allant de la classe spécifique à la classe générale
• Lorsqu ’une classe spécifique hérite de plusieurs super-classes, on dit qu ’il y a héritage héritage multiplemultiple
Train
Wagon
noSerie : Integer = 0capacite : Double = 0.0longueur : Double = 0.0
getCapacite()getNoSerie()setNoSerie()setCapacite()getLongueur()setLongueur()
0..*0..*contient
Conteneur
hauteur : Double = 0.0largeur : Double = 0.0
setLargeur()getLargeur()setHauteur()getHauteur()setCapacite()
Citerne
diametre : Double = 0.0
getDiametre()setDiametre()setCapacite()
estUnestUn
généralisationgénéralisation
Modélisation par UML
40
Interfaces• Les interfacesinterfaces sont des classes
contenant seulement des opérationsopérations sans implantationimplantation.
• Une classe peut implanterimplanter une interface
• Le symbole d ’implantation est une flèche pointilléeflèche pointillée allant de la classe versvers l ’interface
• Ici, la classe A implante les interfaces Storable et Runnable et B utilise ces implantations
Storable<<Interface>>
Runnable<<Interface>>
B
A
uses
Modélisation par UML
41
Vision statiqueVision statique
Les PackagesPackages
Modélisation par UML
42
Les Packages• Pour les systèmes comprenant plusieurs classes, il
convient de regrouper celles-ci en entités logiques, les packagespackages
• Un package est un ensemble de packagesensemble de packages et de classesclasses reliés sémantiquement entre eux
• Chaque package est muni d ’une interfaceinterface (ses classes publicclasses public) qui lui permet de communiquer sa fonctionnalité aux autres packages qui peuvent l ’importer
Modélisation par UML
43
Les Packages (suite…)• Un package est représenté par un dossierdossier (folder)• Les Packages ont eux aussi un niveau de visibiliténiveau de visibilité
est des relationsrelations qui sont ici: la dépendancedépendance, le raffinementraffinement, et la généralisationgénéralisation
AssociationsSimples Agregations Heritage
InterfacesGUIClasses
Modélisation par UML
44
Vision statiqueVision statique
Les TemplatesTemplates
Modélisation par UML
45
Les Templates• UML supporte les
templatestemplates (aussi appelés « parameterized parameterized classesclasses »)
• Ils sont symbolisés par un symbole de classe avec symbole de classe avec un ajout identifiantun ajout identifiant le fait que le template doit être « instancié » avant de pouvoir créer des objets de la classe correspondant au template
T, n
Array
ColorArray
"bind" <color,50>
Array<Auto,100>
« Instanciation »
Raffinement
Modélisation par UML
46
QualitésQualités d ’un modèle statique• Le modèle peut-il être
communiquécommuniqué aux autres membres de l ’équipemembres de l ’équipe de même qu ’au client client ?
• Le modèle a-t-il une utilitéutilité pour décrire le système?
• Le modèle embrasse-t-il les caractères essentielscaractères essentiels du système (permet-il entre autres de bien répéter les use-cases?
• Les noms des classesnoms des classes du modèle reflètent-ils les noms des éléments du noms des éléments du systèmesystème (i.e. les noms sont-ils pertinents)?
• Des modèles différentsmodèles différents de la même chosemême chose sont-ils intégrésintégrés et coordonnéscoordonnés entre eux?
• Les modèles sont-ils simplessimples (même pour les systèmes complexes?
Modélisation par UML
47
OufOuf...
Modélisation par UML
48
Visualisation « Dynamique Dynamique »»
Modélisation par UML
49
Modélisation dynamique• Sert à montrer comment les
objetsobjets d ’un système collaborentcollaborent pour réaliser une fonctionnalitéfonctionnalité du système.
• Montre comment les objetsobjets s ’échangent des messagesmessages (i.e. comment un objet, le le clientclient, invoque une opérationopération sur un autre objet, le serveurle serveur). Ces échanges sont appelés interactionsinteractions.
• Les interactions sont montrées via trois principaux diagrammesdiagrammes:– séquenceséquence
– collaborationcollaboration
– activitéactivité
• Un autre diagramme, le diagramme d ’état décrit le comportement d ’un objet mais cette fois-ci pris isolément.
Modélisation par UML
50
Les 4 modèles dynamiques• Diagramme d ’étatsDiagramme d ’états: décrit les étatsétats que peut
prendre un objet durant son cycle d ’existence et le comportementcomportement de ces états de même que les événementsévénements qui provoquent un changement d ’étatchangement d ’état de l ’objet
• Diagramme séquentielDiagramme séquentiel : montre comment les objets interagissentinteragissent et communiquentcommuniquent entre eux pour accomplir une tâchetâche du système. La variable indépendante est ici le tempstemps.
Modélisation par UML
51
Les 4 modèles dynamiques (suite…)• Diagramme de collaborationDiagramme de collaboration: montre comment les
objets interagissentinteragissent et communiquentcommuniquent entre eux pour accomplir une tâchetâche du système. La variable indépendante est ici le l ’espacel ’espace. Par espace on entend ici les relations (liensliens) entre les objets dans le système.
• Diagramme d ’activitéDiagramme d ’activité: montre comment les objets interagissentinteragissent et communiquentcommuniquent entre eux pour accomplir une tâchetâche du système. La variable indépendante est ici le le travail accompli par les le travail accompli par les objets.objets.
Modélisation par UML
52
Interactions entre les objets (messages)
• En programmation orientée objet, les interactions entre les objets sont modélisées comme des messagesmessages envoyés d ’un objet à un autre
• Ces messages sont simplement des appels appels d ’opérationsd ’opérations d ’un objet par un autre avec le contrôle qui revient à l ’objet appelant avec une valeur de retourvaleur de retour
SynchroneSynchrone
AsynchroneAsynchrone
SimpleSimple
SynchroneSynchroneavec retouravec retourimmédiatimmédiat
Modélisation par UML
53
Le diagramme d ’étatsdiagramme d ’états
Modélisation par UML
54
Le diagramme d ’états• Il sert à décrire le cycle de viecycle de vie d ’objets’objets, de sous-sous-
systèmessystèmes, et de systèmessystèmes• Il montre les étatsétats que les objets peuvent prendre et
comment les événementsévénements (messages reçusmessages reçus, temps temps écouléécoulé, occurrence d ’erreursoccurrence d ’erreurs, conditions conditions logiquement vraieslogiquement vraies)
• Un tel diagramme doit être associé à toute classe dont les objets peuvent prendre des états identifiables. Il décrit le comportementcomportement de ces objets et comment celui-ci évolueévolue en fonction de l ’état ’état présentprésent
Modélisation par UML
55
AuPremierEtageEnAscension
entry: delai = 0do: MonteAL'etageexit: sonette.ring(bip)
PointMort
arrivé
EnDescente
do: descendAL'etagearrivé
EnDeplacementVersLePremierEtage
arrivé
monte( noEtage )
monte( noEtage )
descend( noEtage )
[ delai=delaiMinutes ]
Exemple
Ascenseur
etageCourant : Integer = 1delai : Integer = 0<<const>> delaiMinutes : Integer = 3
monte()descend()
Nom de l ’étatTransition
Actions
Etat de départ
Modélisation par UML
56
Diagrammes d ’états - détails• Ces diagrammes peuvent
avoir un seulun seul point de point de départdépart et plusieursplusieurs points points d ’arrivéed ’arrivée
• Un point de départdépart est symbolisé par un disquedisque.
• Un point d ’arrivée’arrivée est symbolisé par un cerclecercle circonscrivant un disquedisque
• Un étatétat est symbolisé par un rectangle aux coins rectangle aux coins arrondisarrondis
• Les transitionstransitions sont symbolisées par une flècheflèche
Point de départ
Point d ’arrivée
Etat
Transition
Modélisation par UML
57
Etats• En UMLUML, un état comprend 33
compartiments. Seulement 22 sont disponibles dans RoseRose (notation de State Charts de Harel).
• Le premierpremier compartiment contient le nomnom de l ’état
• Le secondsecond compartiment contient les actionsactions (aussi appelées événementsévénements) effectuées en entrantentrant (entryentry), durantdurant (dodo), en quittantquittant l ’état (exitexit), ou sur une conditioncondition
EnAscension
entry: delai = 0do: MonteAL'etageexit: ^sonette.ring(bip)
• Les événementsévénements peuvent être des actionsactions (do) ou des « sendsend »
Actions
Send
Modélisation par UML
58
Etats (suite…)La syntaxe pour les actionsactions dans un état est la suivante:
Event-name argument list / action expression
La syntaxe pour la transitiontransition entre les états est la suivante:
Event-signature [guard-condition] / action expression ^ send-clause
Event-name (parameter, parameter, ...)
Destination-expression.destination-event-name (argument,...)
Modélisation par UML
59
La signature des événements• Elle consiste en un nomnom d ’événement, une liste de liste de
paramètresparamètres séparés par des virgules. Le type des paramètres peut être indiqué comme suit:
Parameter-name : type-expression, Parameter-name: type-expression,...
Exemples:Dessine(f:Forme,c:couleur)redessine()redessineimprime(facture)
Modélisation par UML
60
Condition de garde
• C ’est une expression booléenneexpression booléenne placée sur une transition d ’état.
• Si elle est combinée à un signature d ’événement, l ’événement et la condition de garde doivent tous tous les deuxles deux être vérifiés pour que la transition ait lieu.
• Exemples de conditions de garde:
[t = 15 sec][nombre de factures = 20]retrait(montant) [solde >= montant]
Conditions seules
Avec événement
Modélisation par UML
61
Expression d ’action sur une transition• Elle consiste à une action procéduraleaction procédurale qui
s ’exécute lors de la transition. Elle peut s ’exprimer comme un appel d ’opérationappel d ’opération sur l ’objet proprement dit ou comme paramètres dans la paramètres dans la signature de l ’événementsignature de l ’événement.
• Il peut y avoir plusieurs actionsplusieurs actions lors d ’une transition mais il faut les séparer par un « / »
• Exemples de transitions avec actions:
Augmente()/n:=n+1/m:=m+1additionne(n)/somme := somme + n/clignote
Avecévénement
Sans
Modélisation par UML
62
La send-clause
• C ’est un cas spécial d ’action’action.• Elle utilise une syntaxe explicite pour illustrer l ’envoi
d ’un message durantdurant la transition entre deux états.• Par exemple, l ’action suivante:
[temps = max]/descend(premierEtage)• peut s ’écrire avec la syntaxe de send-clause:
[temps = max]^self.descend(premierEtage)
Modélisation par UML
63
Les événements• Représentent une chose qui
se produit et qui peut déclencher une actionaction.
• La relationrelation entre un événementévénement et une actionaction est causalecausale (i.e. ne peut être probabiliste)
• UML considère quatrequatre types principaux d ’événements:– Une conditioncondition qui devient
« vraie » (représentée par une «guard conditionguard condition »)
– la réceptionréception explicite d ’un signalsignal par l ’objet (le signal est lui-même un objet). On appelle ceci un messagemessage)
– la réception d’un appel appel d’opérationd’opération par un autre objet (ou par l’objet lui-même). Il s ’agit également d ’un messagemessage)
– l ’écoulement’écoulement d ’une période de tempstemps donnée (représentée par une expression temporelleexpression temporelle sur la transition)
Modélisation par UML
64
Exemple d ’un diagramme d ’état
Affichage
do: affiche temps actuel
AjusteHeures
do: afficheHeuresAjusteMinutes
do: afficheHeures
inc / heures:=heures+1 inc / minutes:=minutes+1
boutonDeMode boutonDeMode
boutonDeMode
MontreNumerique
boutonDeMode()incremente()
MontreNumerique
boutonDeMode()incremente()
Modélisation par UML
65
Le diagramme séquentielsdiagramme séquentiels
Modélisation par UML
66
Les diagrammes séquentielsséquentiels
• Ils illustrent comment les objetsobjets interagissent entre eux.
• Ils se concentrent sur la séquence des messages séquence des messages envoyés entre les objetsenvoyés entre les objets (c ’est-à-dire commentcomment et quandquand les messages sont envoyés et reçus entre les objets)
• Ils possèdent deux axesdeux axes: l ’axe vertical’axe vertical montre le tempstemps tandis que l ’axe horizontal’axe horizontal montre l ’ensemble des objets en interactionobjets en interaction dans un scénarioscénario ou une scènescène spécifique d ’un scénario.
Modélisation par UML
67
Les diagrammes séquentiels ...séquentiels ...
• Ils peuvent être utilisés sous deux formesformes:– forme génériqueforme générique: elle décrit toustous les déroulements
possibles d ’un scénario et peut contenir des branchementsbranchements, des conditionsconditions, et des bouclesboucles.
– forme d ’instanciationforme d ’instanciation: elle décrit le comportement du système pour un aspect spécifiqueaspect spécifique d ’un scénario et ne peut donc contenir aucunaucun branchementbranchement et aucune conditioncondition ou boucleboucle.
Modélisation par UML
68
Les messages dans les diagrammes séquentiels• Ils représentent une communicationcommunication entre objets
véhiculant une informationinformation avec l ’anticipation qu ’une actionaction sera entreprise (comme pour les diagramme d ’états)
• La réceptionréception d ’un messagemessage est généralement appelée événementévénement.
• Les messagesmessages peuvent être des signauxsignaux («signals»), des appels d ’opérationappels d ’opération (ou quelque chose de semblable comme un RPCRPC ou une RMIRMI en Java)
Modélisation par UML
69
Les messages ...• Quand un objet reçoit un message, on dit qu ’il entre
dans sa phase d ’activation. Un objet dans cette phase peut:– exécuter son propre code– attendre les résultats retournés par un autre objet à qui il a
envoyé un message
• L ’activation d ’un objet est représentée par un rectangle étroit sur la ligne de vie de l ’objet
• L ’exemple suivant montre un diagramme séquentiel simple pour les échanges entre une imprimante et un ordinateur
Modélisation par UML
70
Diagramme des classes de l ’exemple
FileImprimante
Print()
QueueImpression
Store()
ServeurImprimante
Print()
Acteur
(from Use Case View)
Ordinateur
Print()
Modélisation par UML
71
Diagramme séquentiel de l ’exemple
: Acteur
: Ordinateur : ServeurImprimante
: Imprimante : QueueImpression
Print(File) Print(File)Print(File)
Store(File)
Si imprim. libre
Si imprim. occupée
Messagesynchrone
Nom dumessage
Retour Lignesdevie
Activationde l ’objet
Objets
Modélisation par UML
72
Le diagramme de collaboration collaboration
Modélisation par UML
73
Les diagrammes de collaboration collaboration
• Les diagrammes de collaboration montrent les interactionsinteractions et les liensliens entre un ensemble d ’objets participant à un scénario.
• Ils focalisent leur attention sur l ’aspect spatial’aspect spatial des interactions.
• Ils sont particulièrement utiles pour montrer la réalisation de use-casesréalisation de use-cases (sans que les aspects temporels des interactions ne soient nécessairement rendus explicites).
Modélisation par UML
74
Les diagrammes de...
• Les objetsobjets sont dessinés comme des classesclasses mais leurs nomsnoms sont soulignéssoulignés.
• Les liensliens sont illustrés par des ligneslignes (qui ressemblent à des lignes d ’associations dans les diagrammes de classes mais sans les informations de multiplicité).
• Un messagemessage, accompagné d ’une étiquetteétiquette, peut être associé à un lien pour montrer le senssens et l ’ordonnancement’ordonnancement de la transmission du message.
Modélisation par UML
75
Les diagrammes de...• Les étiquettes de message associées aux liens
adoptent la syntaxe suivante:
Predecessor guard-condition sequence-expression return-value := signature
Expression pour la synchronisation synchronisation de threadsde threads signifiant que les messages reliés à des numéros de séquence spécifiques doivent être traités avant que le message courant soit transmis.
ConditionCondition à vérifier avant de transmettre le messageSyntaxe:[condition]
Syntaxe:[integer] | name] [recurrence] :integer: numéro dans la séquencename: thread de contrôlerecurrence: répétition.Syntaxe:* [iteration-clause] [condition-clause]
La «return-value» doit être affectée à la valeur retournée par la signaturesignature du message
Modélisation par UML
76
Les liensliens dans les diagrammes de collaboration
• Un lienlien indique une connexionconnexion entre deux objets.• Le rôlerôle de chaque objet peut être inclus aux
extrémités de la connexion avec les qualificatifs du lien (rappel: les rôles et qualificatifs sont aussi inclus dans le diagramme de classe)
• Le stéréotypestéréotype du lien peut aussi être inclus dans la connexion.
• On compte les stéréotypesstéréotypes suivants:– globalglobal, locallocal, parameterparameter, selfself, votevote, broadcastbroadcast
Modélisation par UML
77
Les stéréotypesstéréotypes de liensliens• GlobalGlobal: associé à un rôle du lien pour montrer que
l ’instanciation en présence est globaleglobale (visible dans tout le système).
• LocalLocal: associé à un rôle du lien pour montrer que l ’instanciation est une variable locale dans une opération.
• ParameterParameter: montre que l ’instance est visible parce que c ’est un paramètre d ’une opération
• SelfSelf: montre qu ’un objet peut s ’envoyer des messages
• VoteVote: contrainte imposée à un message limitant l ’éventail des valeurs de retour (spécifie que la valeur de retour est choisie au vote majoritaire entre différentes valeurs de retour)
• BroadcastBroadcast: contrainte appliquée à un ensemble de messages pour signifier qu ’ils ne sont pas exécutés dans un ordre donné
Modélisation par UML
78
Exemple pour l’ascenseur : ClassesClasses
Requête
CreeDemande()
QueueAscenseur
AppelleJob()RecupereJob()
ControleurAscenseur
AppelAscenseur()
+jobBoutonAscenseur
presser()
Acteur
(from Use Case View)
Ascenseur
etageCourant : Integer = 1delai : Integer = 0<<const>> delaiMinutes : Integer = 3
monte()descend()
(from Elevator)
Modélisation par UML
79
Exemple pour l’ascenseur :CollaborationCollaboration
: QueueAscenseur
transient
: Requête
transient
: BoutonAscenseur
persistent
: ControleurAscenseur
persistent
: Acteur
: Ascenseur
persistent
P
2: AppelAscenseur(int)
3: CreeDemande( )4: AppelleJob(job)
1: presser( )
5: RecupereJob( )
L
nextjob
Modélisation par UML
80
Le diagramme de d ’activité d ’activité
Modélisation par UML
81
Le diagramme d ’activités
• Focalise son attention sur l ’implantation’implantation des opérations dans les classes.
• Représente donc une façon de visualiser l ’activité ’activité interneinterne d ’un objet non pas en fonction des ses changements d ’états mais plutôt en termes des activités effectuées dans ces états.
• L ’implantation d ’une opération est vue comme une suite d ’actions’actions reliées entre elles. Ces actions sont par la suite transcrites en lignes de code.lignes de code.
Modélisation par UML
82
Le diagramme d ’activités
• Les actionsactions sont représentées par des rectangles aux coins rectangles aux coins arrondis.arrondis.
• Les transitionstransitions entre les actions sont représentées par des flèchesflèches.
• Le diagramme comprend unun point de départdépart et unun ou plusieursplusieurs points d ’arrivée’arrivée.
• Un événementévénement peut accompagner la transition du point de départ seulement
• Des conditions de gardeconditions de garde, des «send-clausessend-clauses », et des actionsactions peuvent accompagner les transitions entre les actions.
• Des boîtes de décisionboîtes de décision (losanges) peuvent faire partie du diagramme.
• Des actionsactions peuvent être exécutés concurremmentconcurremment
• en les plaçant en parallèle sur le diagramme.
Modélisation par UML
83
Le diagramme d ’activités. Exemple...
FenetreClients
ImprimeTousLesClients()
Affiche Message d'impression à l'écranFenetreClients.ImprimeTousLesClients()
CréeFichierPostscript
EffaceMessageEcran Imprimante.ImprimeFichier()
Send-clause
Action
TransitionDépart
Arrivée
Événement
Classe
Modélisation par UML
84
OufOuf...
Modélisation par UML
85
Architecture « physiquephysique »
Modélisation par UML
86
Architecture physiquephysique• L ’architecture physique’architecture physique du système s ’intéresse à la
description détaillée de celui-ci sur les plans du hardwarehardware et du softwaresoftware.
• Elle illustre la structure du hardwarehardware en incluant les différents nœuds de calculnœuds de calcul et les liensliens entre ceux-ci
• Elle montre également la structurestructure, les dépendancesdépendances entre modules de logiciel qui implantent les concepts et les algorithmes de la description logique, et la distributiondistribution de ces modules en termes de processusprocessus, programmesprogrammes et composantescomposantes.
Modélisation par UML
87
Architecture physiquephysique...• L ’architecture physique répond aux questions
suivantes:– Dans quels programmesprogrammes ou processusprocessus les classesclasses et
objetsobjets du modèle logique résidentrésident-ils physiquementphysiquement?– Sur quel(s) processeurprocesseur(s) ces programmesprogrammes et processusprocessus
s ’exécutent’exécutent-ils?– Quels types d ’ordinateurstypes d ’ordinateurs composent le système et
comment sont-ils reliés physiquementphysiquement?– Quelles sont les dépendancesdépendances entre les différents fichiersfichiers
ou packagespackages de classes (lors d ’un changement de fichier, quels autres fichiers doivent être recompilés)?
Modélisation par UML
88
Architecture physiquephysique...
Mapping
•Composantes,•Processus•Ordinateurs
Physique
•Classes,•Objets,•Mécanismes,•Messages,•Algorithmes,
Logique
Modélisation par UML
89
DiagrammesDiagrammes de l ’architecture physique
• En UMLUML, l ’architecture physique est principalement décrite par deuxdeux diagrammesdiagrammes:– le diagramme des composantesdiagramme des composantes (« component component
diagramdiagram »): contient les composantes logiciellescomposantes logicielles du projet (unités de code et fichiers concrets-binaires et sources).
– le diagramme de déploiementdiagramme de déploiement (« deployment diagram »deployment diagram »): décrit l ’architecture physique du run-time du système en couvrant les dispositifs physiquesdispositifs physiques (ordinateursordinateurs, processeursprocesseurs, etc.) et le logiciellogiciel qui leur est respectivement associé.
Modélisation par UML
90
Le hardwarehardware
• La partie hardwarehardware d ’un système est divisée en troistrois éléments:– Les processeursprocesseurs: ce sont les ordinateurs qui exécutent les
programmes du système.
– Les «devicesdevices»: ce sont les périphériques de support tels les imprimantes, routeurs, lecteurs de disquettes/CD, etc. Ils sont généralement connectés à un processeur qui les contrôle. Il y a souvent peu de différence entre un processeur et un device.
– Les connexionsconnexions: ce sont les liens physiques entre les processeurs (câbles-fibre optique et/ou protocoles p.e. TCP/IP)
Modélisation par UML
91
Le softwaresoftware• En UMLUML, un système logiciel est divisé en packages packages
de classesde classes• Un packagepackage rassemble un certain nombre de
classesclasses en un groupe logiquegroupe logique mais ne définit aucune sémantique pour le groupe.
• Il est fréquent d ’utiliser une ou quelques composantescomposantes du package comme façadefaçade du groupe. Cette façade est la seule partie visibleseule partie visible du groupe à l ’extérieur du package et constitue son interfaceinterface.
• Seule l ’interface’interface possède une dépendancedépendance avec d ’autres modulesmodules.
Modélisation par UML
92
Le software...software...
• Un packagepackage contient un package de façadepackage de façade qui références d ’autres éléments mais qui ne contient lui-même aucun élément. Il est en quelque sorte le représentantreprésentant de son package.
• On lui donne le stéréotypestéréotype « façadefaçade » en UMLUML.• Il est aussi possible d ’utiliser une classe classe
d ’interfaced ’interface au package au lieu d ’un package de façade. Cette classeclasse devient une classe de façadeclasse de façade.
Modélisation par UML
93
Le software...software...• Les principaux concepts servant à décrire la partie
software d ’un système sont:– Les composantescomposantes (« componentscomponents »): elles sont des parties
réutilisables qui offrent le packaging physiquepackaging physique d ’un ensemble d ’instanciations d ’éléments du modèle (par exemple, un fichier source) qui implantent des éléments du modèle logique.
– Les processusprocessus et les threadsthreads: ils représentent respectivement des flots de contrôleflots de contrôle « heavyweightheavyweight » et « lightweightlightweight ». Les deux sont décrits comme des classes classes actives stéréotypéesactives stéréotypées et les objets actifsobjets actifs correspondent à un component exécutablecomponent exécutable.
– Les objetsobjets: les objets passifspassifs sont ceux sanssans thread propre.
Modélisation par UML
94
Le software...software...
• DeuxDeux principaux diagrammesdiagrammes servent à décrire physiquementphysiquement les systèmes:
les diagrammes de composantescomposantes (« componentscomponents »)
les diagrammes de répartitionrépartition (« deploymentdeployment » )
Modélisation par UML
95
Le diagramme de composantes composantes(« component diagram »« component diagram »)
Modélisation par UML
96
Le diagramme de composantes
• Il décrit les composantes logiciellescomposantes logicielles et leur interdépendanceinterdépendance.
• Il représente par conséquent la structurestructure du codecode.• Les composantescomposantes sont les implantations implantations
physiquesphysiques des conceptsconcepts et fonctionnalitésfonctionnalités définis dans le modèle logiquemodèle logique du système (i.e., les classesclasses, les objetsobjets, les liensliens et les collaborationscollaborations).
• Les composantescomposantes sont typiquement les fichiers fichiers d ’implantationd ’implantation des éléments logiques du système.
Modélisation par UML
97
Les composantes• UMLUML définit trois types principaux de composantescomposantes:
– les composantes sourcescomposantes sources: ce type de composante prend toute sa signification lors de la compilationcompilation. Elle est un fichier source implantant une ou plusieurs classesclasses.
– Les composantes binairescomposantes binaires: elles représentent le code code objetobjet résultant de la compilation des sourcescompilation des sources. Il peut s ’agir d ’un fichier objetfichier objet, d ’une librairie statiquelibrairie statique, ou d ’une librairie dynamiquelibrairie dynamique. Une composante binairecomposante binaire prend toute sa signification lors de l ’édition des liens’édition des liens, dans le cas des librairies statiqueslibrairies statiques, ou au run-timerun-time, dans le cas des librairies dynamiqueslibrairies dynamiques.
– Les composantes exécutablescomposantes exécutables: programmesprogrammes résultant de l ’édition des liens des composantes binairescomposantes binaires.
Modélisation par UML
98
Les composantes...• En UMLUML, une composantecomposante est représentée par un
grand rectanglegrand rectangle avec une ellipseellipse et deux petits deux petits rectanglesrectangles placés à la gauche du grand rectangle.
• Le nomnom de la composante est inscrit en dessous ou à l ’intérieur du grand rectangle.
• Les composantescomposantes sont des typestypes et seules les composantes exécutablesexécutables peuvent être instanciéesinstanciées.
• Les composantes instanciées sont montrées dans un diagramme de répartitiondiagramme de répartition où les différences instances de ces composantes sont allouées et où le processeur sur lequel elles s ’exécutent est montré.
Modélisation par UML
99
Les composantes...• Les dépendancesdépendances entre composantes sont illustrées
par une ligne pointilléeligne pointillée avec une flèche simpleflèche simple.• Une dépendancedépendance signifie qu ’une composante a
besoin d ’une autre pour que sa définitiondéfinition soit complètecomplète.
• Dans un langage compilécompilé, si un module A dépend d ’un module B, cela signifie que module A doit être recompilé si des changements sont apportés à B.
• Si les composantes sont exécutablesexécutables, les dépendances montrent les librairies dynamiques qui sont nécessaires lors de l ’exécution d ’un programme.
Modélisation par UML
100
Les composantes...
• Une composantecomposante peut avoir une interfaceinterface qui est visible aux autres composantes.
• Ces interfacesinterfaces peuvent être définies au niveau du code sourcecode source (comme en Java) ou au niveau du code exécutablecode exécutable utilisable au run-time (comme en OLE).
• Une interfaceinterface est montrée par une ligneligne terminée par un cerclecercle.
• Le nomnom de l ’interface’interface est inscrit près de ce cercle.
Modélisation par UML
101
Exemple de diagramme de composantes de code sourcecomposantes de code source
Composante
Dépendancehome.html<<page>>
logoAnimation.java<<file>>
logoAnimation.doc<<document>>
animateur.java<<file>>
animateur.doc<<document>>
Modélisation par UML
102
Exemple de diagramme de composantes run-timecomposantes run-time
commmanip.dll<<library>>
graphics.dll<<library>>
dbhandler.dll<<library>>
browser.exe<<application>>
Modélisation par UML
103
Le diagramme de répartition répartition(« deployment diagram »« deployment diagram »)
Répartition
Modélisation par UML
104
Le diagramme de répartitionrépartition• Ce diagramme montre l ’architecture run-time’architecture run-time des
processeursprocesseurs, des périphériquespériphériques, et des composantes logiciellescomposantes logicielles qui s ’exécutent sur cette architecture.
• Il est la description finaledescription finale de la topologie du topologie du systèmesystème car il unit les facettes hardwarehardware et softwaresoftware du système.
• Dans ce type de diagramme, il devrait être possible d ’observer un nœudnœud de la topologie et de voir les composantescomposantes qui s ’y exécutent, et quelles structures logiquesstructures logiques sont implantées dans ces composantes.
Modélisation par UML
105
Diagramme de répartitionrépartition...
• Il comprend:– des nœudsnœuds– des connexionsconnexions– des composantescomposantes– des objetsobjets
Modélisation par UML
106
Diagramme de répartitionrépartition...• NœudsNœuds: unités physiquesphysiques (matérielles) dotées
d ’une puissance de calculpuissance de calcul donnée (processeurs, imprimantes,lecteurs de cartes, périphériques de communication, etc). Les nœudsnœuds peuvent être des typestypes ou des instanciations de typesinstanciations de types. Un nœudnœud est représenté par un cube en trois dimensionscube en trois dimensions avec son nomnom à l ’intérieur (souligné si c ’est une instanciation)
• Les périphériquespériphériques sont aussi représentés par des nœudsnœuds avec un stéréotypestéréotype ou au moins un nom qui indique clairement que le nœud n ’en est pas un de calcul.
Modélisation par UML
107
Processeur I
traiteData
preemptive
Processeur II
manual
acquisi tion
Imprimante Échantillonneur A/N
Ecran <<Vidéo>> <<TCP/IP>>
<<Parallèle>> <<BNC>>
Diagramme de répartitionrépartition…exemple simple
Nœud
Lien
Périphérique (device)
Process
Scheduling
Modélisation par UML
108
OufOuf...
Modélisation par UML
109
Un dernier exemple: le pattern proxyproxy en UML
Client Sujet
Requête()
<<Abstract>
SujetRéel
Requête()
Proxy
Requête()
refèreA->Requête();refèreA
Modélisation par UML
110
Un dernier exemple: le pattern proxyproxy en UML
unClient : Client
unProxy : Proxy
unSujetRéel : SujetRéel
Requête( ) Requête( )
Modélisation par UML
111
Processus de développement et UML
Modélisation par UML
112
Processus de développementProcessus de développement de logiciel• UMLUML est un outil de modélisationmodélisation de systèmes.• Il doit être utilisé dans un contexte de
développementdéveloppement contrôlé par un processusprocessus orienté orienté objetobjet bien établi. Un outiloutil n ’est pas une méthodeméthode.
• Une méthodeméthode de design orientée objetorientée objet repose sur trois trois basesbases:
– une notationnotation permettant de décrire les modèlesmodèles;– un processusprocessus de construction des modèlesmodèles;– des outilsoutils facilitant la construction et la description des
modèles.
Modélisation par UML
113
Le processus Le processus permet de...
• respecter les exigences fonctionnellesexigences fonctionnelles (parfois informelles) du système;
• se conformer aux limitesconformer aux limites de la machine exécutant le logiciel;
• se conformer aux ressources disponiblesressources disponibles;• satisfaire des critères de designcritères de design;• satisfaire les contraintescontraintes et les limiteslimites du
processus de designprocessus de design lui-même (un design doit être effectué dans un temps raisonnable).
Modélisation par UML
114
Le processus Le processus doit permettre de limiter
• la complexitécomplexité du problèmeproblème; • la complexitécomplexité de gestion du processusprocessus de
conception du logiciel par une équipe d'ingénieurs: plusieurs solutions sont possibles et il faut choisir la meilleure;
• la complexitécomplexité associée à la flexibilitéflexibilité offerte par le logiciel;
• la complexitécomplexité associée à la difficulté de décrire des systèmes discretssystèmes discrets..
Modélisation par UML
115
Le processus Le processus doit tenir compte du fait que...• Les systèmessystèmes adoptent une structure hiérarchiquestructure hiérarchique. • Le choix des composantes de basecomposantes de base de ces
systèmes est généralement arbitrairearbitraire; • Les liensliens intra-composantesintra-composantes sont généralement plus
forts que les liensliens inter-composantesinter-composantes; • Les systèmessystèmes sont généralement composés d'un
nombre restreint de sous-systèmessous-systèmes arrangésarrangés de diverses manières ou combinéscombinés de façons diverses;
• Les systèmessystèmes découlent de systèmes plus simplessimples dont ils sont une évolution.
Modélisation par UML
116
OOA-OOD-OOP
Modélisation par UML
117
OOA-OOD-OOPOOA-OOD-OOP• L ’analyse orientée objet’analyse orientée objet (OOA) est une méthode qui examine les
exigences d'un projet dans une perspective de classesclasses et d'objetsd'objets tirés du domaine de l'application.
• La conception orientée objetconception orientée objet (OOD) est une méthode de designdesign comprenant un processus ce décompositiondécomposition par objetsobjets et une notationnotation permettant de dépeindre les modèles logiques/physiquesmodèles logiques/physiques et statiques/ statiques/ dynamiquesdynamiques du système en cours de développement.
• La programmation par objetsprogrammation par objets (OOP) est une méthode d'implantationd'implantation par laquelle les programmes sont organisés en un ensemble d'objets un ensemble d'objets coopératifscoopératifs, chaque objet représentant une instance d'une classe, chaque classe faisant partie d'une hiérarchiehiérarchie de classes unies par des relations d'héritagerelations d'héritage.
Modélisation par UML
118
ModélisationModélisation par objetsobjets• La modélisationmodélisation par objets comporte quatrequatre
éléments principauxprincipaux:
– l'abstractionl'abstraction: représentation des caractéristiques caractéristiques essentiellesessentielles d'un objet qui permettent de le distinguer de tous les autres;
– l'encapsulationl'encapsulation: processus de compartimentationcompartimentation des éléments d'une abstraction qui constituent sa structure et son comportement;
– la modularitémodularité: capacité qu'a un système d'être décomposé en un ensemble de modules cohérentscohérents et faiblement faiblement coupléscouplés;
– la hiérarchiehiérarchie: ordonnancementordonnancement d'abstractions;
Modélisation par UML
119
ModélisationModélisation par objetsobjets• et troistrois éléments secondairessecondaires:
– le typagetypage: renforcement de la classe d'un objet telle que des objets de types différents ne puissent pas être intervertis;
– la concurrenceconcurrence: distingue un objet actifactif d'un objet inactifinactif. Un objet actif en est un qui représente un thread et implique les notions de synchronisation avec d'autres objets, ce qui n'est pas le cas des objets inactifs qui ne nécessitent pas de synchronisation temporelle avec les autres objets;
– la durabilitédurabilité: propriété grâce à laquelle un objet peut transcender le tempstemps (i.e. l'objet continue d'exister après que son créateur soit mort) et/ ou l'espacel'espace (i.e. l'espace mémoire occupé par l'objet se modifie par rapport à celui où il a été créé).
Modélisation par UML
120
Modèle WATERFALL
ExigencesExigences
DesignDesign
ImplantationImplantation
TestTest
MaintenanceMaintenanceFlop!!!
Modélisation par UML
121
Modèle WATERFALL(suite)Activité Phase
Design Codage Test Maintenance
Design 49.2 34.1 10.3 6.4
Codage 6.9 70.3 15.9 6.9
Test 4.7 43.4 26.1 25.8
!!!
Modélisation par UML
122
Méthode de conception Unified
Modélisation par UML
123
Méthode d ’analyse UnifiedUnifiedDévelopper un
modèle du système(analyse)
Développer unmodèle du système
(analyse)
Établir lesexigences centrales
du projet(conceptualisation)
Établir lesexigences centrales
du projet(conceptualisation)
Concevoir unearchitecture du
système(design)
Concevoir unearchitecture du
système(design)
Raffinerl ’implantationdu système(évolution)
Raffinerl ’implantationdu système(évolution)
Apporter lescorrectifs ausystème final
(entretien)
Apporter lescorrectifs ausystème final
(entretien)
Modélisation par UML
124
Méthode d ’analyse UnifiedUnifiedIdentification des
classes etdes objets
Identification desclasses etdes objets
Identification dela sémantique des
classes et desobjets
Identification dela sémantique des
classes et desobjets
Identificationde la relation entre
les classeset les objets
Identificationde la relation entre
les classeset les objets
Définition del interface et
de l ’implantationdes classes et
des objets
Définition del interface et
de l ’implantationdes classes et
des objets
Modélisation par UML
125
ApplicationApplication de la méthode
Processus itératif
Processus incrémental
Modélisation par UML
126
Formation de l ’équipe’équipe
Architecte DéveloppeursIng. de
réutilisation
Contr. de qualité
Superviseur
Resp. doc.
Modélisation par UML
127
AppelleAscenseurPassager
Modélisation par UML
128
BoutonAppel
presser()
BoutonEtage
lum : VoyantLumineux
presser()
VoyantLumineux11<<hasA>>
Porte
statusOuverture : Boolean = false<<const>> noEtage : int
ouvre()ferme()getStatusOuverture()setStatusOuverture()
Ascenseur
arrivé : BooleanenMouvement : BooleanprochReq : RequêtenoEtageCourant : intnoEtageDestination : int
monte()descend()getArrivé()setArrivé()getenMouvement()setEnMouvement()getNoEtageCourant()setNoEtageCourant()getNoEtageDestination()setNoEtageDestination()
QueueRequêtes
PutRequête()GetRequête()
Requête
noEtage : int
getNoEtage()setNoEtage()Requête()
0..*0..*
<<hasA>>
ControleurAscenseur
appelleAscenseur()
Bouton
on : Boolean
<<abstract>> presser()getOn()
<<isA>> <<isA>>
Modélisation par UML
129
Au premier étage
do: Attend
En Montée
do: vérifie no étage
monte( noEta )[ porte.statusOuverture = false ]
A l'arrêt
entry: commande ouverture portedo: Attend
[ arrivé=true ]monte( noEta )[ porte.statusOuverture=false ]
EnDescente
do: vérifie no étage
descend( noEta )[ porte.statusOuverture=false ]
[ arrivé=true ]
Modélisation par UML
130
Fermée
entry: setStatusOuverture(false)
Ouverte
entry: setStatusOuverture(true)
ferme()[ Ascenseur.getEnMouvement() = false ]
ouvre()[ Ascenseur.getNoEtage(Destination)=noEtage ET Ascenseur.getEnMouvement() = false ]
Modélisation par UML
131
Denis : PassagerMonterEtage1 : Bouton
Appel : ControleurAscenseur
ReqCourante : Requête
: QueueRequêtesNordEst : Ascenseur
presser( )appelleAscenseur(n) Requête(n)
PutRequête(ReqCourante)
GetRequête( )
getNoEtage( )
Modélisation par UML
132
Denis : Passager
MonterEtage1 : BoutonAppel
: ControleurAscenseur
ReqCourante : Requête
: QueueRequêtes
NordEst : Ascenseur
G
G
1: presser( )
G
G
2: appelleAscenseur(n)
L
3: Requête(n)G
L
4: PutRequête(ReqCourante)
L
L
G
6: getNoEtage( )
P
G
5: GetRequête( )