cours d'introduction à uml

Introduction à UML – C. Vaudry 1

Introduction à UML

Christophe Vaudrymél : [email protected] blog : thegeekintheshell.blogspot.comsite Web : cvaudry.developpez.com


Présentation• Cours d'introduction

– Cours donné en 2ème année de l'ISAIP Dijon en 2005-2006

• Objectifs de ce cours d'introduction– Savoir modéliser un système.– Maîtrise d'un langage de modélisation et de la

modélisation objet.– Connaître le langage UML et être capable de l'utiliser

dans un cadre d'ingénierie logicielle, système ou réseau.

• Organisation – Généralité et rappels de conception objet– Les cas d'utilisation– Les diagrammes de classes


Organisation• Une introduction en 7 parties

– Généralité sur UML et rappels de conception objet– Les cas d'utilisation– Les diagrammes de classes– Les diagrammes de séquences– Les diagrammes d'états– Les diagrammes d'activités– Les autres diagrammes


Outils• Outils gratuits pour la création de diagramme UML (1)

– Logiciels de dessin• Dia : le logiciel de dessin open source, propose des

diagrammes UML : http://www.gnome.org/projects/dia/ et http://dia-installer.sourceforge.net/

• Visio : Il n'est pas gratuit mais par ailleurs il est très répandu dans le milieu professionnel

– Il est possible de l'avoir gratuitement et légalement si vous êtes étudiant ou enseignant et que votre établissement possède une licence MSDNAA

– Attention, le module UML n'est pas systématiquement installé avec Visio...

http://www.gnome.org/projects/dia/

http://dia-installer.sourceforge.net/


Outils• Outils gratuits pour la création de diagramme UML (2)

– Logiciels de modélisation• ArgoUML (En Java) : http://argouml.tigris.org/ • Umbrello UML Modeller (sous KDE) :

http://uml.sourceforge.net/index.php • Omondo EclipseUML (plug-in Eclipse) :

http://www.omondo.com/ . • Poseidon UML Community Edition (basé sur

ArgoUML): http://www.gentleware.com/index.php • BOUML: http://bouml.free.fr/• UML Pad :

http://web.tiscali.it/ggbhome/umlpad/umlpad.htm• Sur Apple Macintosh, CanonSketch et TaskSketch :

http://dme.uma.pt/projects/canonsketch/ et http://dme.uma.pt/projects/tasksketch/

• StarUML : http://staruml.sourceforge.net/en/– Cette liste n'est pas exhaustive et peut se trouver

rapidement obsolète...

http://argouml.tigris.org/

http://uml.sourceforge.net/index.php

http://www.omondo.com/

http://www.gentleware.com/index.php

http://bouml.free.fr/

http://web.tiscali.it/ggbhome/umlpad/umlpad.htm

http://dme.uma.pt/projects/canonsketch/

http://dme.uma.pt/projects/tasksketch/

http://staruml.sourceforge.net/en/


Bibliographie (1)• Ressources bibliographiques (1)

– A conseiller• « UML 2.0 » de Martin Fowler chez CampusPress

– Un livre très clair présentant l'essentiel sur UML. • « Modélisation et conception orientées objet avec UML

2 » de Michael Blaha et James Rumbaugh chez Pearson Education

– Très complet sur la conception objet avec UML– Intéressant

• « UML 2 en action » de Pascal Roques et Frank Vallée chez Eyrolles

• « UML 2 par la pratique » de Pascal Roques chez Eyrolles

– Pour ceux qui veulent aller plus loin...• « UML 2.0 – Guide de référence » de James Rumbaugh,

Ivar Jacobson, Grady Booch chez CampusPress• « UML 2 et les design patterns » de Craig Larman, M.-

C. Baland, L. Carité, E. Burr chez Pearson Education


Sources d'inspiration• Le contenu de ce cours doit beaucoup à :

– « UML 2.0 » de Martin Fowler chez CampusPress– « Modélisation et conception orientées objet avec UML

2 » de Michael Blaha et James Rumbaugh chez Pearson Education

– « UML 2 en action » de Pascal Roques et Frank Vallée chez Eyrolles


Webographie• Ressources concernant UML sur le Web

– A conseiller : • http://uml.developpez.com/

– Partie du site www.developpez.com dédié à UML et à la modélisation. Site en français avec de nombreux tutoriels, exercices et liens

– Intéressant• Un bon site sur UML en français mais n'est pas à jour

pour la norme UML 2– http://uml.free.fr/

– Pour ceux qui veulent aller plus loin...• Le site de Martin Fowler : http://martinfowler.com/• Le site d'Alistair Cockburn : http://alistair.cockburn.us/

– Notamment sur les cas d'utilisation : http://alistair.cockburn.us/usecases/usecases.html

• Le site de Constantine et Lockwood : http://foruse.com/

http://uml.developpez.com/

http://www.developpez.com/

http://uml.free.fr/

http://martinfowler.com/

http://alistair.cockburn.us/

http://alistair.cockburn.us/usecases/usecases.html

http://foruse.com/


Introduction• Intérêt d'une notation graphique

– Un diagramme peut • contribuer à véhiculer des idées sur une conception de

manière concise• aider à comprendre un logiciel ou un processus métier

– Les diagrammes constituent un outil de communication • C'est un bon moyen de communication au sein d'une

équipe de développement et dans certain cas avec un client

– De manière générale une notation graphique est• Un support et une aide au raisonnement• Un outil de communication

– Les langages de modélisation graphique existent depuis longtemps dans l'industrie logicielle

• Les langages de programmation ne se situent pas à un niveau d'abstraction suffisant pour faciliter les échanges lors de la conception.


UML (1)• Une première définition

– UML : Unified Modeling Language– UML est une famille de notations graphiques

s'appuyant sur un métamodèle unique.• Un métamodèle est un modèle du modèle. En clair nous

avons un modèle unique qui décrit la famille de notations graphiques

– UML permet de décrire et de concevoir des sytèmes logiciels

• notamment des sytèmes logiciels orientés objets mais pas seulement

• Un standard– UML est un standard ouvert contrôlé par l'OMG

• OMG : Object Management Group– L'OMG est un consortium ouvert d'entreprises– Il a été fondé pour construire des standards facilitant

l'interopérabilité des systèmes


UML (2)• Un standard

– UML est un standard ouvert contrôlé par l'OMG• OMG : Object Management Group

– L'OMG est un consortium ouvert d'entreprises– Il a été fondé pour construire des standards facilitant

l'interopérabilité des systèmes – L'OMG a défini notamment le standard CORBA

(Common Object Request Broker Architecture)• La fusion de plusieurs notations

– UML est issu de l'unification de nombreux langages de modélisations graphiques développer dans les années 1980-1990.

– UML est apparu en 1997• Les 3 amigos : Grady Booch, Ivar Jacobson et Jim

Rumbaugh• Les comités de l'OMG


Mode d'utilisation d'UML (1)• 3 modes d'utilisations pour le développeur

– Esquisse– Plan– Langage de programmation

• 2 directions d'utilisation d'UML– En mode esquisse et plan on peut utiliser UML en pro-

ingénierie ou en retro-ingénierie

Mode esquisse

Mode plan

Mode langage de programmation

pro-ingénierie retro-ingénierie

Diagrammes UML générés avant le code

Diagrammes UML générés à partir du code

existant

Conception détaillée avec des diagrammes UML

Informations détailléessur le code

Non applicable Non applicable


Mode d'utilisation d'UML (2)• Mode esquisse

– Le mode esquisse est dans une démarche informelle et dynamique

• Elles sont exécutées rapidement et de manière collaborative généralement dans le cadre de réunion sur un tableau

– Les esquisses sont un outil d'exploration• Les esquisses sont également utiles pour la

documentation– L'accent est mis sur la communication plutôt que sur

l'exhaustivité• En mode esquisse les outils utilisés sont des outils

graphiques légers• En mode esquisse toutes les règles d'UML ne sont pas

toujours strictement respectées– L'essence du mode esquisse est la sélectivité


Mode d'utilisation d'UML (3)• Mode esquisse (suite)

– En pro-ingénierie• On ébauche des solutions liées à certains problèmes de

codage afin les analyser avec des membres de l'équipe de développement

– Les esquisses servent à communiquer des idées et des solutions possibles

– On met l'accent sur les problèmes importants que l'on veut aborder en premier ou des éléments de conception que l'on veut visualiser avant de commencer à programmer et non de l'ensemble du code sur lequel on va travailler.

– En rétro-ingénierie• Les esquisses sont utilisées pour expliquer comment une

partie du système fonctionne– On ne représente pas toutes les classes mais

seulement les plus pertinentes pour la compréhension de l'ensemble.


Mode d'utilisation d'UML (4)• Mode plan

– Par opposition au mode esquisse le mode plan vise à l'exhaustivité

– Les plans sont un outils de définition• Les réalisations en mode plan nécessite des outils

beaucoup plus élaborés que celle d'esquisses pour pouvoir gérer le niveau de détails qu'implique la tâche.


Mode d'utilisation d'UML (5)• Mode plan (suite)

– En pro-ingénierie• Les plans sont développés par un concepteur dont la

tâche consiste à construire une conception détaillée qu'un programmeur codera

– Cette conception détaillée doit être suffisamment complète

• Toutes les décisions de conception sont représentées afin que le programmeur puisse la suivre sans se poser (trop) de question.

• En général elle est réalisée par un développeur plus expérimentée pour une équipe de programmeurs

• Les plans en pro-ingénierie peuvent servir à représenter tous les détails de l'ensemble du système ou ne concerner qu'une partie ou un domaine particulier.


Mode d'utilisation d'UML (6)• Mode plan (fin)

– En retro-ingénierie• Les plans ont pour but de véhiculer des informations

détaillées sur le code– Ils peuvent montrer tous les détails d'une classe sous

forme imagée, plus facile à comprendre pour les développeurs.


Mode d'utilisation d'UML (7)• Mode langage de programmation

– Les développeurs créent des diagrammes qui sont directement compilés en code exécutable

• UML devient le code source– MDA : Model Driven Architecture

• MDA est une méthode standard d'utilisation d'UML comme langage de programmation contrôlé par l'OMG

• MDA divise le travail de développement en 2 domaines principaux

– On représente une application donnée en créant un PIM (Platform Independent Model)

• Le PIM est un modèle indépendant de toute plateforme ou technologie

– Un outil permet ensuite de transformer le PIM en PSM (Platform Specific Model)

• Le PSM est un modèle de système ciblant un environnement d'exécution spécifique.

• Un ensemble d'autres outils traitent le PSM et génèrent un code exécutable pour cette plateforme.


Vue d'ensemble des diagrammes UML• 13 diagrammes avec UML 2.0

– UML 2 décrit 13 types de diagrammes officiels• Les types de diagrammes ne sont pas particulièrement

rigides– On peut souvent utiliser légalement les éléments

d'un type de diagramme dans un autre.– Le standard UML indique que certains éléments

appartiennent généralement à certains diagrammes• Ce n'est qu'une recommandation


Intérêts et limites d'UML (1)• Avantages

– UML est langage unifié pour la modélisation objet• C'est un langage formel normalisé• Il permet un gain de précision et est un gage de stabilité

– UML encourage l'utilisation d'outils– UML est un support de communication performant qui

cadre l'analyse. – UML facilite la compréhension de représentations

abstraites complexes. – Son caractère polyvalent et sa souplesse en font un

langage universel. – UML peut-être utilisé en mode plan pour une

modélisation détaillée, en mode esquisse comme outil de travail et de communication entre développeur et comme « langage de programmation » (MDA)


Intérêts et limites d'UML (2)• Limite majeure

– UML est un langage qui permet de représenter des modèles. Cependant il ne définit pas le processus d'élaboration des modèles

• trouver un "bon" modèle est une tâche difficile mais capitale!

• donc avec UML, utilisé hors de toute méthodologie, le succès d'une bonne représentation repose avant tout sur une bonne compréhension de la problématique.

– Il existe différents processus de construction utilisant UML comme langage de modélisation pour pallier cette limitation

• Par exemple le RUP– Cette limite peut-être vue comme un avantage d'une

certaine manière• On peut utiliser UML dans son propre processus.• On peut même utiliser UML sans avoir une approche

objets !


Analyse et modélisation• Analyser un problème = se poser les bonnes

questions– Il faut délimiter le sujet : répondre à la question, à la

question en entier mais rien qu'à la question !• Quelle est le système que je modélise ? Quelle est sa

limite ?• Quelles sont les objets qui interviennent dans le problème

ou dans le système? • Quelles sont les relations entre ces objets? • Quelles sont les opérations que l'on peut effectuer sur

ces objets?• Quelles sont actions que peuvent accomplir les objets ?• Quelles sont les responsabilités d'un objet ? Quels autres

objets l'aide à les accomplir ?• A quelle famille d'objets appartient un objet ? Quels sont

les liens entre les familles d'objets ?


Conception Orienté Objet (1)• L'approche objet (1)

– Programmation dirigé par les données et non par les traitements

• Contrairement à l'approche procédural on se concentre en premier lieu sur les entités que l’on manipule avant de se concentrer sur la façon dont on les manipule.

– Exemple du menuisier


Conception Orienté Objet (2)• Encapsulation

– Principe de l'encapsulation• Un objet est une structure informatique regroupant les

données et les procédures qui permettent de décrire ou de manipuler cette entité réelle ou imaginaire

– Une pile de données– Une voiture

• C'est le principe de l'encapsulation– Un objet regroupe à la fois la description de la

structure (données) et du comportement (procédures ou méthodes ou fonctions membres) de l'entité qu'il modélise.

– Fondement de l'approche objet• Faire correspondre à une entité « réelle » ou abstraite un

objet qui en fournit une modélisation informatique


Conception Orienté Objet (3)• Exemple d'objet métier : un compte bancaire

– Une structure de données permettant de décrire• Le solde• Le type de compte• La rémunération qu'il propose• ...

– Des méthodes permettant de réaliser des opérations usuelles sur un compte bancaire

• Créditer• Débiter• Solder• ...

– Cet objet contient tout ce qui est nécessaire pour décrire et utiliser la modélisation d'un compte bancaire au sein d'une application.


Conception Orienté Objet (4)• Exemple d'objet technique : une pile de donnée

– Une structure de données permettant de sauvegarder les données et un pointeur de pile

– Des méthodes permettant de réaliser des opérations usuelles sur une pile

• Empiler un élément• Dépiler un élément• Tester si la pile est vide• ...

– Cet objet contient tout ce qui est nécessaire pour créer et utiliser des piles.

• Les objets utilisateurs de cette pile n'ont besoin de connaître que les méthodes publiées de cette pile pour pouvoir l'utiliser.


Conception Orienté Objet (5)• Modéliser avec des objets

– Identifier les entités qui sont nécessaires à la réalisation d'une application

– Décrire chaque entité à l'aide d'un objet– Mettre en relation ces entités afin qu'elles réalisent, par

leur collaboration, les fonctionnalités attendues de l'application.

• Avantages induits par l'encapsulation– Une plus grande expressivité

• On travaille à plus haut niveau ce qui permet une meilleur compréhension des problèmes

– Une plus grande modularité qui se traduira dans le code, facilitant la maintenance et l'évolutivité de ces derniers.


Conception Orienté Objet (6)• Un modèle uniforme de la conception à la

programmation– Le développeur utilise un concept uniforme d'objet de

puis l'analyse jusqu'à l'étape d'implémentation du logiciel

• Pas de changement de paradigme entre la conception et la réalisation.

– L'abstraction « objet » est proche du processus de réflexion humaine

• Il est plus facile de concevoir un système en termes d'objets.


Conception Orienté Objet (7)• Attributs d'un objet

– La structure d'un objet est décrite par un ensemble de variables appelées attributs de l'objet

• Un attribut est défini par– Son nom– Son type– Sa valeur

– L'ensemble des valeurs des attributs d'un objet à un instant donné, décrivent l'état de l'objet.

– Synonyme d'attributs : données membres, propriétés.


Conception Orienté Objet (8)• Méthodes d'un objet

– Le comportement d'un objet est décrit par un ensemble de procédures appelées les méthodes ou opérations de l'objet.

– Une méthode est décrite par une signature comportant• Un nom• Un ensemble de paramètres définis par leur nom et leur

type• Un type de valeur de retour

– Les méthodes décrivent l'ensemble des fonctionnalités proposées par un objet pour consulter son état (accesseurs) ou modifier son état (mutateurs)


Conception Orienté Objet (9)• Les messages

– L'activation d'une méthode d'un objet s'effectue en lui adressant une demande d'exécution d'une de ses méthodes à l'aide d'un message.

• Tout langage de programmation orienté-objet dispose d'un mécanisme d'envoi de message qui repose sur la donnée de

– L'identifiant de l'objet destinataire du message– Le nom de la méthode invoquée– La liste des paramètres


Conception Orienté Objet (10)• Visibilité

– Dans un objet, les données et les procédures peuvent être :

• Accessibles depuis l'extérieur de l'objet• Accessibles seulement depuis les méthodes de l'objet lui-

même.– On parle de visibilité des attributs et des méthodes

• Partie publique d'un objet, connue dans son contexte de définition

• Partie privée d'un objet, connue uniquement de l'objet.– En toute rigueur, il faudrait que

• Les attributs soient toujours privés : ils ne devraient pouvoir être lues ou modifiées que par l'intermédiaire des méthodes de l'objet afin de prendre en charge les vérifications et les effets de bord éventuels.

• Seules les méthodes de l'objet destibées à être utilisées directement par d'autres objets, soient visibles : il faut cacher les méthodes utilitaires propres à l'objet lui-même.


Conception Orienté Objet (11)• Interface et implémentation

– L'ensemble des méthodes visibles d'un objet constitue son interface

• i.e. les points d'entrée que peuvent avoir des objets extérieurs pour agir sur lui

• L'interface décrit les fonctionnalités réalisables par un objet.

– L'ensemble des attributs et des méthodes invisibles d'un objet constitue son implémentation

• i.e. une solution technique imaginée par le programmeur pour réaliser l'interface de l'objet.

– L'interface • propose une vue abstraite des capacités d'un objet qui

masque les détails de sa réalisation à ses utilisateurs• Définit le protocole qui est compris par l'objet et qui doit

être utilisé pour interagir avec lui.– C'est le principe de l'abstraction


Conception Orienté Objet (12)• Interface et implémentation : intérêt

– La dichotomie interface/implémentation permet de faire évoluer plus facilement les programmes

• Pourvu que les fonctionnalités de l'interface ne changent pas, rien n'empêche de changer de solution technique (i.e. de changer l'implémentation) pour les réaliser.

– L'interface garantit que l'utilisation de l'objet est réalisée à l'aide des seules opérations prévues par le concepteur de l'objet

• L'interface impose une utilisation cohérente et le respect de l'intégrité des objets.


Conception Orienté Objet (13)• Classe et objets

– Une classe est une description générique d'une famille d'objets ayant une même structure et un même comportement

• la classe est un modèle décrivant les caractéristiques communes et le comportement d’un ensemble d’objets

– Pour désigner les objets, on utilise également le terme d’instance d’une classe

– la classe est un moule et l’objet est ce qui est produit à partir de ce moule

– La notion de classe peut être vue comme une extension de la notion de type défini par l'utilisateur

• Dans des langages comme C++ ou Java, chque nouvelles classes créées définies un nouveau type de donnée.


Conception Orienté Objet (14)• Classe et objets (fin)

– Les caractéristiques communes des objets sont définis dans la classe

• les propriétés descriptives qui sont variables ou constantes

– on parle d’attributs, de champs, de propriétés ou de données membres.

• les comportement communs aux ensembles d’objets– Ils sont représentés par les méthodes ou les

fonctions membres.– Dans certains cas le terme propriété désigne aussi

bien un attribut qu'une méthode.


Conception Orienté Objet (15)• Instances et instanciation d'une classe

– Le processus de création d'un objet à partir d'une classe s'appelle instanciation.

• L'instanciation est le processus qui consiste à donner une valeur à l'ensemble des attributs définies dans la classe.

– Les objets sont également appelés instances• Une instance est un représentant physique d'une classe

– C'est une entité individuelle qui possède un état propre, i.e. une valuation de ses attributs qui est indépendante de celle des autres objets.

– Par contre toutes les instances d'une classe ont la même structure et le même comportement, définis par un même ensemble d'attibuts et de méthodes

– Une classe définit un type d'objet• Les instances d'une classe sont manipulés par le même

ensemble d'opérations définies par leur interface commune.


Conception Orienté Objet (16)• Exemple

– On considère le constructeur automobile français Cinaultgeot qui commercialise depuis peu la Cléo 3.

– Chacune des Cléo 3 achetées par un particulier est différente et constitue un objet à part entière qui a une existence concrète.

• Chacune peut avoir une puissance, une couleur de carrosserie, des options différentes.

• Pourtant chacune à des caractéristiques communes et un comportement commun.

– Les couleurs de la carrosserie peuvent être différente, mais toutes ont une couleur de carrosserie (et une carrosserie ! :-)

• Elles ont une structure commune– Toutes vont avoir une clé de contact, vont pouvoir

être démarrer, vont pouvoir être manœuvrées avec un volant, etc.

• Elles ont une interface (d'utilisation) commune


Conception Orienté Objet (17)• Exemple (suite)

– Pour des raisons de rentabilité de la production à la chaîne, Cinaultgeot a défini un plan de construction commun de cette voiture, en prenant bien soin de définir les parties variables communes de ces voitures

• En quelque sorte, et pour simplifier un peu, on a un plan commun à toutes les Cléo 3 et on sait quels vont être les parties variables (la couleur de la carrosserie par exemple).

• C’est lors de la réalisation concrète d’une Cléo 3 que l’on donne une valeur particulière à ces parties variables (par exemple telle voiture sera peinte en rouge, telle autre en noire)

– Chaque Cléo 3 créée est conçu pour réagir d’une certaine manière aux (inter)actions du conducteur

• Quand ce dernier agit sur le volant ou le levier de vitesse.• Cela fait partie des éléments relevant du comportement

commun à toutes les Cléo 3 définit dans les plans de constructions de cette voiture.


Conception Orienté Objet (18)• Exemple (fin)

– Chaque Cléo 3 créée correspond à une instance.– Le plan de construction des Cléo 3 correspond à une

classe.• Une classe est équivalent à un moule, à un plan de

construction et l’objet est une entité concrète créée à partir de ce moule.

• Dans ce plan de construction– les parties variables comme la couleur de la

carrosserie correspondent aux attributs de l’objet.• Les attributs sont définis dans la classe (i.e. le plan

de construction) mais se voient affecter une valeur au moment de la création de l’objet.

– les comportements communs des voitures correspondent aux méthodes

• Une méthode correspond aux actions, aux messages auxquels peut réagir l’objet.

• Comme pour les attributs, ces méthodes sont définis dans la classe.


Conception Orienté Objet (19)• Notation d'une classe en UML

+Démarrer()+Accélérer()+Freiner()+Avancer()+Reculer()+Arrêter()

-Couleur-Puissance

Cleo3


Conception Orienté Objet (20)• Comment construire les classes (1ère approche)

– On part de la situation concrète et on repère les objets• On essaie de voir les liens entre les différents objets et

s'ils partagent des caractéristiques communes– Puis on remonte vers une « généralisation », « une

abstraction » : la classe • La classe est le plan de construction des futurs objets

manipulés par le programme et la description de leur comportement

• chaque entité manipulée dans le programme est un représentant (ou instance) d'une de ces classes.

• « l'univers de l'application » est par conséquent composé d'un ensemble d'objets définis et créés à partir de la définition d’une classe.

– Les caractéristiques statiques (propriétés variables et constantes) et les caractéristiques dynamiques (i.e. le comportement) de ces objets sont définis dans la classe.


Conception Orienté Objet (21)• La classe : synthèse

– Classe : description d’une famille d’objets ayant une même structure et un même comportement.

– Elle est caractérisée par :• Un nom• Une composante statique :

– des attributs (ou champs ou propriétés ou données membres) nommés ayant une valeur.

– Les attributs caractérisent l’état des objets pendant l’exécution du programme

• Une composante dynamique : – des méthodes ou fonctions membres ou

opérations représentant le comportement des objets de cette classe.

– Les méthodes manipulent les attributs des objets et caractérisent les actions pouvant être effectuées par les objets.


Conception Orienté Objet (22)• Héritage : exemple introductif (1)

– On souhaite réaliser un jeu vidéo de type « wargame » • Le joueur manipule des petites entités que nous

nommerons ici « personnage », qu’il utilise pour conquérir des territoires ou défendre les siens.

• Il y a différents types de personnage, ayant sur certains points des caractéristiques communes et des différences entre eux.



– On considère ici un « wargame » de type moyen-ageux et fantastique (dans le style « Warcraft ™ »), avec, pour simplifier, comme types de personnage des guerriers, des magiciens, des prêtres et des paysans.

• Les guerriers savent manier les armes et se battre. On distingue parmi eux les fantassins et les cavaliers. Les cavaliers sont identiques aux fantassins mais savent en plus monter et se battre à cheval

• Les prêtres prient et sont les seuls à pouvoir soigner• Les magiciens sont les seuls à pouvoir lancer des

sortilèges et à avoir des points de magie• Les paysans sont les seules à cultiver la terre et à pouvoir

produire de la nourriture.• Tous les personnages consomment de la nourriture, ont

une durée de vie, un nombre de point de vie, une valeur représentant leur force, leur résistance à la magie, etc.



– Comment concevoir ces différents « personnages » et types de personnages selon une démarche « orientée objet » ?

• Une première solution est de faire correspondre directement une classe à un type de personnage

+Combattre()+Se nourrir()

-points de vie-force

Guerrier

+Cultiver()+Se nourrir()


Paysan

+Lancer un sort()+Se nourrir()

-points de vie-force-points de magie

Magicien

+Prier()+Se nourrir()+Soigner()


Prêtre

+Combattre()+Se nourrir()+Combatrre à cheval()


Cavalier



– Critique de la solution précédente• Avec cette première solution se qui est dommage, c’est

qu’un même comportement (seNourrir par exemple) devra être défini pour chacune des classes

• Il semble dommage de ne pas avoir un mécanisme qui nous permette de mieux organiser nos classes

– Après tout, du guerrier au prêtre, se sont tous des personnages qui se nourrissent, ont des points de vie, etc.

– Ils sont caractérisés par un ensemble de propriétés ou de comportements communs et se distinguent seulement par quelques différences.



– Critique de la solution précédente (suite)• Il serait pratique

– de définir un ensemble minimum de propriétés et de comportement communs

– de faire en sorte que chaque classe les hérite– d'ajouter dans chacune des classes ce qui les

distinguent des autres classes.• Ce mécanisme existe dans les langages de classe, c’est

le mécanisme d’héritage.• Ce qui nous mène vers une deuxième solution...



– Deuxième solution

+se nourrir()

#points de vie#force

Personnage

+combattre()

Guerrier

+cultiver()

Paysan+lancer un sort()+se nourrir()

#points de magieMagicien

+prier()+soigner()

Prêtre

+combatrre à cheval()

Cavalier



– Deuxième solution : utilisation de l’héritage• Avec l’héritage il y a factorisation du code : on partage le

code commun– On écrit moins de code (normalement), gain de place

et de temps de développement, même s’il peut y avoir plus de classes

– On a moins de modifications à faire• Si je décide de modifier la méthode seNourrir(), avec

la première solution, il faudra que je le fasse pour chaque méthode dans chaque classe.

• Avec l’héritage, je ne ré-écris qu’une méthode• L'héritage est également un puissant moyen d'organiser

ces classes, et donc son code.


Conception Orienté Objet (29)• Mécanisme d'héritage

– L'héritage est un mécanisme permettant le partage et la réutilisation de propriétés entre les objets.

• Afin d'éviter de définir plusieurs fois les mêmes informations (attributs ou méthodes), on a imaginé un mécanisme de factorisation de l'information contenue dans le classes

– La relation d’héritage est une relation de généralisation / spécialisation.

• L'héritage permet de définir une classe, la sous-classe, en réutilisant les informations d'une autre classe la superclasse.

• L'héritage evite d'avoir à spécifier une seconde fois les données et méthodes héritées. La définition de la sous classe réutilise le code de la superclasse.

• La sous-classe spécialise la superclasse : elle possède tous les attributs et toutes les méthodes de celle-ci ainsi que des attributs et des méthodes supplémentaires qui lui sont propres.


Conception Orienté Objet (30)• Mécanisme d'héritage (fin)

– L'héritage est un principe fondamental de l'approche objet qui instaure des mécanismes de factorisation et de réutilisation du code

• Codage plus rapide• Meilleure qualité de code• Maintenance et évolution facilitée


Diagrammes de cas d'utilisation


Définition et utilisation (1)• Définition

– Les cas d'utilisations (use cases en anglais) sont une technique qui permet de capturer les exigences fonctionnelles d'un système

• Les cas d'utilisation décrivent les interactions types entre les utilisateurs d'un système (les acteurs) et le système lui-même.

• Les cas d'utilisation constituent en quelque sorte le « récit » de la façon dont le système est utilisé


Définition et utilisation (2)• Utilisation

– Pour travailler avec les cas d'utilisation il y a plusieurs manières de procéder

• Une manière de faire est de commencer par décrire les scénarios d'utilisation du système

– Un scénario est constitué d'une série d'étapes et décrit une interaction particulière entre un utilisateur et un système

– Un cas d'utilisation est un ensemble de scénarios reliés par un but commun

• C'est ce but commun qui définit le cas d'utilisation.• Certains recommandent ou préfèrent d'abord définir le

diagramme des cas d'utilisation du système puis de décrire pour chacun des cas d'utilisation les différents scénarios.


Acteur (1)• Définition

– Un acteur est un rôle qu'un utilisateur joue par rapport au système

• Les acteurs réalisent les cas d'utilisation– Un seul acteur peut réaliser plusieurs cas d'utilisation

ou un même cas d'utilisation peut-être réaliser par plusieurs acteurs

– Les acteurs ne sont pas forcément « humains » : si un système fournit un service à un autre système, cet autre système est également un acteur

• Exemples d'acteurs– Un client, un employé du service clients, un

opérateur, un responsable bancaire, un enseignant, un administrateur système, un chef de produit, etc.

• Une seule et même personne concrète peut assumer plusieurs rôles d'acteur

– Par exemple un administrateur système ou un responsable de formation qui sont également enseignant.


Acteur (2)• Identification des acteurs

– Avant d'identifier les différents cas d'utilisation, il faut identifier les différents acteurs qui interagissent avec le système

– On peut définir un diagramme de contexte statique• On représente les différents acteurs qui seront en

interactions avec le système • On peut préciser des cardinalités si nécessaires pour

indiquer combien d'acteur en même temps interagissent avec le système.

Acteur


Diagramme de cas d'utilisation• Définition et utilité

– Un diagramme de cas d'utilisation peut être considérer comme une table des matières graphique de l'ensemble des cas d'utilisation.

– Les diagrammes de cas d'utilisation mettent en évidence les limites du système et les interactions avec le monde extérieur.

– Ils représentent les acteurs, les cas d'utilisation et les relations qu'ils entretiennent

• Quels acteurs réalisent quels cas d'utilisation• Quels cas d'utilisation en incluent d'autres

– La description textuel des cas d'utilisation est plus importante que le diagramme de cas d'utilisation


Contenu d'un cas d'utilisation (1)• Pas de méthodes standards

– Il n'existe pas de façon standard de rédiger un cas d'utilisation

• Les différents formats de rédaction peuvent correspondre à des besoins différents

• Démarche classique pour rédiger un cas d'utilisation– On choisit un scénario dit nominal ou principal

• Ce scénario correspond au scénario le plus habituel et qui aboutit toujours.

– On crée le corps du cas d'utilisation en rédigeant ce scénario sous la forme d'une suite d'étapes numérotées.


Contenu d'un cas d'utilisation (2)• Démarche classique (suite)

– On peut alors intégrer les autres scénarios sous forme d'extensions, les décrivant en terme de variantes du scénario principale.

• On les rédige alors sous forme d'extensions.• Ces extensions représentent des réussites ou des

échecs, les situations exceptionnelles• Acteurs primaire et secondaires

– Chaque cas d'utilisation a un acteur primaire qui interagit avec le système pour la réalisation d'un service

• L'acteur primaire est celui dont le système essaie de satisfaire l'objectif

• C'est généralement (mais pas toujours) l'initiateur du cas d'utilisation.

– Il peut y avoir d'autres acteurs avec lesquels le système communique pendant la réalisation d'un cas d'utilisation : ce sont les acteurs secondaires


Contenu d'un cas d'utilisation (3)• Etape du cas d'utilisation

– Chaque étape d'un cas d'utilisation est un élément de l'interaction entre un acteur et le système.

• Elle doit être rédigée sous forme simple montrant clairement que l'étape a été effectuée

• Elle doit exprimer l'intention de l'acteur, non les mécanismes qu'il utilise.

– C'est pourquoi l'interface utilisateur n'est pas décrite dans les cas d'utilisation.

– Généralement, la rédaction des cas d'utilisation précède la conception des interfaces.


Contenu d'un cas d'utilisation (4)• Extension

– Dans un cas d'utilisation, une extension nomme une condition qui entraine des interactions différentes de celles décrites dans le scénario nominal

• Bien sûr elle décrit quelles sont ces différences.– On commence l'extension en nommant l'étape à

laquelle la condition est détectée et on fournit une brève description de la condition.

– On continue en numérotant les étapes, dans le même style que pour le scénario nominal.

– On termine en indiquant le point où l'on retourne dans le scénario nominal, si besoin est.

– Mieux vaut généralement réfléchir d'abord à toutes les conditions des extensions.


Contenu d'un cas d'utilisation (5)• Informations supplémentaires

– Les préconditions• Une précondition décrit ce dont le système doit vérifier la

véracité avant d'autoriser les cas d'utilisation à débuter.– Elle permet d'indiquer aux développeurs les

conditions qu'ils auront à vérifier dans le code.– Les garanties et les post-conditions

• Une garantie décrit ce dont le système doit s'assurer à la fin du cas d'utilisation. Les garanties de succès s'appliquent après un scénario principal, les garanties minimales après tout scénario.

• Une post-condition est une condition qui sera systématiquement vérifiée après le déroulement d'un scénario.

– Un déclencheur (trigger)• Il spécifie l'événement qui provoque le démarrage du cas

d'utilisation.


Contenu d'un cas d'utilisation (6)• Quelques recommandations

– Efforcez-vous de rester bref et de privilégier la lisibilité• Attention mieux vaut parfois pas assez d'informations que

trop• Les cas d'utilisations longs et trop détaillés ne sont

généralement pas lus...– Souvent seuls quelques cas d'utilisation nécessitent

d'être détaillés dès le début : vous pourrez développez les autres justes avant l'implémentation.


Relations entre les cas d'utilisation (1)• Présentation

– UML définit 3 grands types de relations entre cas d'utilisation

• Include, • Extends• généralisation/spécialisation

– Ce dernier est anecdotique et n'a peu d'intérêt : il n'est pas abordé dans cette introduction

– L'utilisation de ces relations n'est pas primordiale dans la rédaction des diagrammes et des cas d'utilisation.

• Ces relations peuvent avoir leur intérêt dans certains cas, mais une trop forte focalisation sur leur usage conduit souvent à une perte de temps ou à un usage faussé, pour une valeur ajoutée généralement faible.


Relations entre les cas d'utilisation (2)• Relation include

– La relation include a pour objectif de factoriser une partie de la description d'un cas d'utilisation qui serait commune à un autre cas d'utilisation et qui représenterait une étape complexe de ces cas d'utilisation

• Le cas d'utilisation inclus dans les autres cas d'utilisation est un cas d'utilisation un peu particulier car il n'a pas vraiment d'acteur primaire

– Au niveau de la description textuel du cas d'utilisation on représente généralement cette relation par un lien hypertexte

Client

Retirer argent

Consulter solde

Authentifier client

<< include>>

<< include>>


Relations entre les cas d'utilisation (3)• Relation extends

– Un cas d'utilisation X étend un cas d'utilisation Y lorsque le cas d'utilisation X peut être appelé au cours de l'exécution du cas d'utilisation Y

– Dans l'exemple si après le cas d'utilisation « enregistrer client » étend le cas d'utilisation « prendre commande »

• Lors de la prise de commande d'un nouveau client, il faut d'abord saisir les informations client afin que le client soit connu/reconnu puis reprendre le processus de prise de commande.

Responsable clientèle

Prendre commande

Enregistrer client

«extends»


Utilisation des cas d'utilisation (1)• Quand utiliser les cas d'utilisation ?

– Les cas d'utilisation constituent un outil précieux pour comprendre les exigences fonctionnelles d'un système

• Il est souhaitable de leur consacrer une première étude au début du projet puis d'élaborer des versions plus détaillées avant de développer chacun d'eux.

• Ils permettent à la MOE (Maitrise d'Oeuvre) de se poser les bonnes questions sur le besoin client et à la MOA (Maitrise d'Ouvrage) de voir si la MOE a compris ses exigences.

• Une vue externe du système– Un cas d'utilisation représente une vue externe du

système• Il ne faut pas s'attendre à une correlation entre les cas

d'utilisation et les classes internes du système.• Cas d'utilisation et diagramme de cas d'utilisation

– Plus que le diagramme de cas d'utilisation, ce sont les descriptions textuels des cas d'utilisation qui sont importantes.


Utilisation des cas d'utilisation (2)• Risque

– Rédiger un cas d'utilisation trop compliqué peut amener à rester bloqué

• En règle générale avec les cas d'utilisation, vous courez moins de risques à en faire trop peu qu'à en faire trop

– 2 pages suffisent pour la plupart des cas d'utilisation– Si vous en avez écrit trop peu, vous disposerez au

moins d'un document court et facile à lire. – Si vous en avez écrit trop, le risque est important que

personne n'arrive à lire, comprendre et donc exploiter votre cas d'utilisation.

• Relations entre cas d'utilisation– Il est important de noter que l'utilisation des relations

entre les cas d'utilisation n'est pas primordiale– Certains auteurs recommandent de n'utiliser le include

qu'avec parcimonie et d'éviter les autres


Descriptions dynamiques d'un cas d'utilisation• Pour les cas d'utilisations

– Pour décrire dynamiquement à l'aide d'un diagramme UML un cas d'utilisation on peut utiliser un diagramme d'activité ou un diagramme de machines d'états

• Pour des scénarios particuliers– On peut utiliser des diagrammes de séquence

• En général on représente l'acteur principal à gauche, puis un objet représentant le système en « boîte noire » et les éventuels acteurs secondaires sollicités durant le scénario à droite du système.

• On parle alors souvent, suivant Graig Larman, de diagramme de séquence système.


Descriptions dynamiques d'un cas d'utilisation

Description textuelle

Cas d’utilisation

scénario

Diagrammes d’activités ou

diagrammes de machines d’états

Diagrammes de séquence


Diagrammes de classes



– Un diagramme de classes • décrit les types d'objet qui composent un système et les

différents types de relations statiques qui existent entre eux.

• représente les propriétés et les opérations des classes, ainsi que les contraintes qui s'appliquent sur la façon dont les objets sont connectés.

– En UML on utilise le terme général de caractéristique• Cela couvre les attributs et les opérations d'une classe


Exemple

-quantite-prix

LigneDeCommande

+expedier()+fermer()

-date_de_reception-est_prepaye-prix

Commande

Produit

1

-lignes*

*

1

{ordered}

+solvabilite()

-nom-adresse

Client

+facture_mensuelle()+rappeler()

-nom_du_contact-solvabilite-credit_autorise

ClientProfessionnel

-numero_carte_creditClientParticulier

*1

{Si Commande.client.solvabilite est "douteuse", alors Commande.estPrepayee doit être vraie}

Employe

*

-Commercial0..1


Exemple détaillé

-quantite : Integer-prix : Double

LigneDeCommande


-date_de_reception : Date-est_prepaye : Boolean-prix : Double

Commande

Produit

1

-lignes*

*

1

{ordered}

+solvabilite()

-nom : String-adresse : String

Client



ClientProfessionnel


*1


Employe

*

-Commercial0..1

Nom de rôle

contrainte

Navigabilité

Attributs

Opérations Multiplicité

Association

Généralisation

Classe

{Solvabilite() == douteuse}


Propriétés (1)• Définition

– Les propriétés représentent les caractéristiques structurelles d'une classe

• En première approximation cela correspond au attributs d'une classe dans un LOO

– En fait c'est un peu plus complexe comme nous allons le voir

– Les propriétés sont un concept unique• Cependant elles apparaissent sous 2 formes

significativement distinctes– attributs et associations– bien que leurs représentations soient tout à fait

différentes dans les diagrammes, ils représentent en fait la même chose


Propriétés (2)• Attributs

– Un attribut décrit une propriété sous la forme d'une ligne de texte à l'intérieur de la boite de la classe elle-même

– La syntaxe complète pour un attribut est la suivante :• visibilité nom type multiplicité = valeurParDefaut {propriété}• Par exemple

– - nom: String [1] = "UneValeur" {readonly}– Le marqueur de visibilité indique si l'attribut est

• Public : +• Privé : -

– Le nom de l'attribut indique comment la classe se refère à l'attribut

• Cela correspond grosso modo au nom de champ dans un LOO


Propriétés (3)• Attributs (suite)

– La valeur par défaut est la valeur associée à l'attribut pour un objet nouvellement créé s'il n'y a pas de valeur spécifiée lors de la phase de création.

– La propriété permet d'indiquer des propriétés supplémentaires pour un attribut

• Par exemple dans l'exemple précédent on a utilisé {readonly} pour indiquer que l'attribut était en lecture seule.

– Nous parlerons de la multiplicité de manière détaillée un peu après.


Propriétés (4)• Associations

– On peut également décrire une propriété à l'aide d'une association


-date_de_reception : Date-est_prepaye : Boolean-prix : Double-lignes : LigneCommande

Commande

{ordered}[1]

[0..1]

[*]

[1]


Commande

LigneCommande

1

-lignes* {ordered}

Date -DateReception

0..1*

Boolean

1

-estPrepaye

1

Reel

-Prix1

1

Les mêmes propriétés représentées sous forme d'association et d'attribut


Propriétés (5)• Associations (suite)

– Une association est représentée par une ligne pleine entre 2 classes, de la classe source à la classe cible

– Le nom de la propriété est placé dans l'association du côté de la cible à proximité de la multiplicité

– Le coté « cible » de l'association qui relie les 2 classes indique le type de la propriété

– Par comparaison avec la notation sous forme d'attribut, les associations peuvent comprendre des multiplicités aux 2 extrémités de la ligne unissant les classes.


Propriétés (6)• Multiplicité

– La multiplicité d'une propriété est une indication du nombre d'objets qui peuvent participer à l'association.

– Les multiplicités les plus courantes• 1

– Par exemple une commande doit avoir exactement 1 client

• 0..1– Une commande peut avoir ou ne pas avoir de date

de réception– Un client professionnel peut avoir ou ne pas avoir de

commercial• * : signifie 0 ou n

– Un client peut ne pas passer de commande, ou au contraire peut passer autant de commandes qu'il veut


Propriétés (7)• Multiplicité (suite)

– Dans le cas général• Les multiplicités sont définies avec une borne inférieure et

une borne supérieure– La borne inférieure peut être tout nombre positif ou

nul– La borne supérieure est représentée par un nombre

strictement positif ou * (illimité)– Si les 2 bornes sont identiques, vous pouvez utiliser

un seul nombre• 1 est équivalent à 1..1

– * étant un cas courant, c'est un raccourci pour 0..*


Propriétés (8)• Multiplicité (suite)

– Cas des attributs• Pour les attributs, vous pouvez rencontrer différents

terme se rapportant à la multiplicité– Optionnel

• Implique une borne inférieure de 0– Obligatoire

• Implique une borne inférieure de 1 ou plus– Monovalué

• Implique une borne supérieure de 1– Multivalué

• Implique une borne supérieur au-delà de 1• Pour une propriétés multivaluée, il est généralement

préférable d'utiliser la forme plurielle pour son nom.


Propriétés (8)• Multiplicité (fin)

– Par défaut les éléments dans une multiplicité multivaluée forment un ensemble

• Si l'ordre est significatif vous devrez placer la propriété {ordered} à l'extrémité de l'association

• Si vous souhaitez autoriser les doublons, il faut ajouter la propriété {nonunique}

• Si vous souhaitez indiquer les valeurs par défaut explicitement vous pouvez utilisez {unordered} et {unique}

– La multiplicité par défaut est égale à [1]• Néanmoins, vous ne pouvez pas considérer que la

multiplicité d'un attribut qui n'en dispose pas dans un diagramme a une valeur de [1]

– En effet les multiplicités peuvent être absentes du diagramme

– Il est toujours préférable de placer une multiplicité de [1] si c'est important.


Propriétés (9)• Associations bidirectionnelles

– Une association bidirectionnelle représente une paire de propriétés liées

– Dans l'exemple ci-après• La classe Voiture a la propriété proprietaire:Personne[0..1]

• La classe Personne a la propriété voitures:Voiture[*]– Cette liaison dans les 2 sens implique que si vous

suivez les 2 propriétés, vous obtenez lors du retour un ensemble qui inclut votre point de départ.

• Si nous partons d'une Cléo 3 ( de Cinaugeolt) particulière, que nous recherchons son propriétaire et que nous regardons les véhicules de ce propriétaire, l'ensemble contient la Cléo 3 de laquelle nous sommes partis.


Propriétés (10)• Associations bidirectionnelles (suite)

– La nature bidirectionnelle de l'association est notée par la présence des flèches de navigations aux 2 extrémités de l'association.

– On peut utiliser une notation sans flèches • soit pour indiquer une association bidirectionnelle• Soit lorsque l'on n'indique pas la navigabilité

– On peut nommer une association• Par une propriété• Par un groupe verbal (comme dans le modèle E/A par

exemple).– Il ne faut nommer une association qu'avec le but d'en

améliorer la compréhension• Les associations intitulés « a », « est en relation

avec » ou « est associé à » ne servent pas à grand chose, surtout si elles sont multipliées dans le diagramme.


Propriétés (11)• Associations bidirectionnelles (fin)

– L'implémentation d'une association bidirectionnelle dans un LOO est souvent un peu délicate

• Il faut s'assurer que les 2 propriétés demeurent synchronisées.

– En général on laisse une extrémité de l'association (l'extrémité monovaluée si possible) contrôler la relation.

– L'extrémité « esclave » (dans l'exemple précédent cela serait Personne) doit alors abandonner l'encapsulation de ses données à l'extrémité maître.

• On utilise en C++ une visibilité de type « friend »• Sinon dans des langages comme Java ou C# on a

dans la classe « esclave » une méthode qui ne devrait pas en théorie s'y trouver (violation partielle du principe d'encapsulation)

• Nous verrons tout ceci plus en détail quand nous ferons du Java


Opérations (1)• Définition

– Les opérations sont les processus qu'une classe sait mener à bien.

• Elles correspondent aux méthodes d'une classe dans un LOO

• Habituellement les opérations qui ne font que manipuler des propriétés ne sont pas notés

– En effet on peut généralement les déduire facilement.


Opérations (2)• Syntaxe

– visibilité nom (liste_de_paramètres) : type_de_retour {propriété}• La visibilité est publique (+) ou privé (-)• Le nom est une chaine de caractères• liste_de_paramètres représente la liste des paramètres de

l'opération– Les paramètres de la liste ont une notation

semblable à celle des attributs– Forme : direction nom: type = valeur_par_défaut

• Le nom, le type et valeur_par_defaut ont la même signification que pour les attributs

• direction indique s'il s'agit d'un paramètre en entrée (in), en sortie (out) ou les 2 (inout). Par défaut si aucune direction n'est précisée, on suppose que la direction est in.

• type_de_retour est le type de la valeur retournée, s'il en existe une

• La propriété indique les valeurs de propriétés qui s'appliquent à l'opération


Opérations (3)• exemple

– Des opérations sur un compte bancaire• + crediter(somme : Monnaie)• + debiter(somme : Monnaie)• + soldeAu(date: Date) : Monnaie

• Modèle conceptuel et opérations– Dans le modèle conceptuel (par opposition avec les

modèles proches de l'implémentation) on n'utilise pas les opérations pour spécifier l'interface d'une classe

• Par contre, on les utilise pour indiquer les principales responsabilités de cette classe


Opérations (4)• Requête et modificateur

– Il peut être nécessaire de distinguer les opérations qui changent l'état du système de celle qui ne le change pas

• Requête : une opération qui permet d'extraire une valeur d'une classe sans modifier l'état du système (i.e. Sans « effets de bord »)

– On peut marquer ces opérations à l'aide de la propriété {query}

• Modificateur : opérations qui modifient l'état du système– Etat observable du système

• La différence entre requêtes et modificateurs tient à ce qu'ils changent ou non l'état observale du système

• Etat observable : etat qui peut être perçu depuis l'extérieur du système

– Exemple du cache


Opérations (5)• CQS (Command-Query Separation)

– Il est utile de mettre en évidence les requêtes• En effet on peut exécuter celles-ci dans n'importe quel

ordre et ne pas changer le comportement du système.– Principe de séparation commande-requête

• Une bonne convention consiste à essayer de faire en sorte que les modificateurs ne retournent pas de valeur

– On peut ainsi considérer que les opérations qui retournent une valeur sont des requêtes.

• Cette séparation est parfois difficile à réaliser mais il faut essayer de la mettre en oeuvre aussi souvent que possible.

• Ce principe a été proposé par Bertrand Meyer, le père du langage Eiffel (entre autre). Voir les URL suivantes :

– http://en.wikipedia.org/wiki/Command-Query_Separation– http://en.wikipedia.org/wiki/Eiffel_programming_language– http://fr.wikipedia.org/wiki/Eiffel_%28langage%29

http://en.wikipedia.org/wiki/Command-Query_Separation

http://en.wikipedia.org/wiki/Eiffel_programming_language

http://fr.wikipedia.org/wiki/Eiffel_%28langage%29


Opérations (6)• Accesseur et mutateur

– Méthode accesseur• Elle retourne la valeur d'un champ et ne fait rien d'autre

– Méthode mutateur• Elle affecte une valeur à un champ et ne fait rien d'autre.

– Depuis l'extérieur de la classe, un objet client ne doit pas être en mesure de dire si une requête est une méthode accesseur ou si un modificateur est une méthode mutateur

• La connaissance des méthodes accesseurs et mutateurs est entièrement interne à la classe.


Opérations (7)• Opération et méthode

– Il existe une distinction entre opération et méthode• Une opération est invoquée sur un objet (lors de l'appel

de la procédure)• Une méthode est le corps de la procédure (sa définition)

– La différence entre les 2 est pertinente en cas de polymorphisme

• En effet, si vous avez un supertype avec trois sous-types, chacun redéfinissant l 'opération getPrix du supertype, vous avez 1 opération et 4 méthodes.

• Dans les faits on emploie souvent les termes d'opérations et de méthode indifféremment

– Cependant il est dans certaines situations judicieux d'être plus précis.


Généralisation (1)

+deplacer()+selectionner()+pivoter()+afficher()

-couleur-position_centre-epaisseur_trait-type_trait

Figure

-nomDiagramme 1 *

ZeroDimensionnelle

+mettreAEchelle()-orientationUniDimensionnelle

+mettreAEchelle()+remplir()

-orientation-remplissage

BiDimensionnelle

+afficher()

Point

+afficher()-pointsExtremites

Ligne

+afficher()

-rayon-angle_depart-angle_arc

Arc

+afficher()-pts_de_controle

Spline

+afficher()

-nb_cotes-sommets

Polygone

+afficher()+pivoter()

-diametreCercle

• Exemple introductif


Généralisation (2)• introduction

– La classe figure par rapport aux classes zero-, uni- et bi-dimensionnelles sont un exemple type de généralisation.

• Ies 3 classes zero-, uni- et bi-dimensionnelles présentent des différences mais également de nombreuses similitudes

• On peut placer ces similitudes dans une classe générique (Figure) qui constitue le supertype, dont Ies 3 classes zero-, uni- et bi-dimensionnelles sont des sous-types.


Généralisation (3)• interprétation

– Du point de vue conceptuel• On a une relation type / sous-type

– Toutes les instances de Arc, Ligne, Spline sont des Unidimensionnelle et sont des Figure.

– Unidimensionnelle est une catégorie spécifique de Figure

– Tout les énoncés vrais pour une Figure, le sont pour une Unidimensionnelle

– Du point de vue de l'implémentation• On a de l'héritage

– On a des relations classes/sous-classes• La sous-classe hérite de l'ensemble des

caractéristiques et peut redéfinir les méthodes héritées.

• Avec le polymorphisme une sous-classe peut se substituer à une superclasse (principe de substitution de Liskov – voir http://www.design-up.com/design/principesoo/lsp.html)

Les méthodes qui utilisent des objets d'une classe doivent pouvoir utiliser des objets dérivés de cette classe sans même le savoir.

http://www.design-up.com/design/principesoo/lsp.html


Notes (1)• Présentation

– Les notes sont les commentaires dans les diagrammes• Elles peuvent exprimées un point de vue ou être reliées

par une ligne pointillée aux éléments qu'elles commentent• Elles ne sont pas propres au diagrammes de classe

– Elles peuvent être présentes dans tous les types de diagrammes

– Convention • Sachant qu'il est parfois difficile de détrerminer l'élément

auquel se réfèrela note, on place parfois un très petit cercle à la fin de la ligne.

– Commentaire sur une ligne• On peut placer un commentaire sur une ligne dans un

élément.– On fait précéder le commentaire de 2 tirets : --


Notes (2)• Exemple

Véhicule assuré

Inclut les voitures et les autocars mais pas les camions


Dépendance (1)• Définition

– Une dépendance existe entre 2 éléments si • des changements apportés à la définition de l'un d'entre

eux (le « fournisseur ») peuvent entrainer des modifications dans l'autre (le « client »).

– Au niveau des classes, des dépendances peuvent exister pour plusieurs raisons :

• Une classe envoie un message à une autre classe• Une classe en a une autre comme partie de ces données• Une classe en utilise une autre comme paramètre de

l'une de ses opérations– En conséquence

• si l'interface d'une classe est modifiée, les messages envoyés à cette classe peuvent ne plus être valides


Dépendance (2)• Représentation des dépendances en UML

– UML autorise la représentation de dépendances entre toutes sortes d'éléments.

• On utilise des dépendances à chaque fois que l'on veut montrer comment des changements apportés à un élément peuvent en entraîner dans d'autres éléments.


Dépendance (3)• Exemple

– Le schéma ci-dessous réprésente une application multicouche

• La classe Fenetre Affichage Compte Bancaire est dépendante de la classe Compte Bancaire

– Compte Bancaire représente des objest du domaine qui capture un comportement essentiel du système (des règles métier)

– Si la classe Compte Bancaire modifie son interface, classe Fenetre Affichage Compte Bancaire peut elle aussi devoir être modifiée

Compte BancaireFenetre Affichage Compte Bancaire

Une IHM

client fournisseur

Dépendance


Dépendance (4)• Exemple (suite)

– Il est important de noter que la dépendance est unidirectionnelle

• Elle va de la classe de présentation vers la classe du domaine

– Il est important qu'il y est ainsi une séparation stricte entre la couche de présentation et la logique du domaine, avec une dépendance de la présentation vers la logique du domaine mais non l'inverse.


Dépendance (5)• Types de dépendance

– UML dispose de nombreuses sortes de dépendances• Chacune avec sa sémantique et ses mots clés

particuliers– La dépendance de « base » que nous avons vu est la

plus courante et est utilisé sans mot clé• Pour apporter plus de détail on peut ajouter le mot clé

approprié à une dépendance.• Relations et dépendances

– De nombreuses relations UML impliquent une dépendance

• Une association unidirectionnel ou bidirectionnel– Dans l'exemple du début, l'association avec un sens

de navigation allant de Commande vers Client indique que Commande est dépendante de Client

• La généralisation : une sous classe est dépendante de sa superclasse (mais pas l'inverse).


Contraintes (1)• Présentation

– Les constructions fondamentales (association, attributs et généralisations) expriment bien les contraintes importantes, mais elles ne peuvent toutes les représenter.

• Il faut pourtant pouvoir les capturer et les diagrammes de classes en sont un des lieux privilégiés.

• Syntaxe– UML permet de choisir la façon dont vous souhaitez

décrire les contraintes– Une seule règle

• Placer les contraintes entre accolades { }– On place les contraintes dans des éléments similaires

à des notes.


Contraintes (2)• Exemple



Commande

+solvabilite()


Client



ClientProfessionnel


*1


contrainte

{solvabilite() == douteuse}

invariant


Contraintes (2)• Description

– Vous pouvez utiliser• Le langage naturel• Un langage de programmation• OCL

– Object Constraint Language– Langage formel d'UML fondé sur le calcul des

prédicats– L'avantage d'une notation formelle comme OCL est

qu'elle permet d'éviter les malentendus• Néanmoins, cela implique que le rédacteur et le

lecteur doivent tous les 2 connaître suffisamment OCL pour éviter tout risque d'incompréhension.

• De manière générale, à moins d'avoir des lecteurs qui soient à l'aise avec le calcul des prédicats, il est préférable d'utiliser le langage naturel.


Contraintes (3)• Conception par contrat

– Développée par Bertand Meyer• Une des caractéristiques du langage Eiffel

– Cependant la conception par contrat peut être employé avec tout langage de programamtion

– Basé sur l'utilisation d'assertion• Une assertion est une expression booléenne qui ne doit

jamais être fausse.– Elle ne peut donc être fausse qu'en présence d'un

bogue– En général elles ne sont vérifiées qu'au déboggage

et pas à l'exécution.– 3 sortes d'assertions

• Post-conditions• Pré-conditions• Invariants


Contraintes (4)• Conception par contrat (suite)

– Les post- et les pré-conditions s'appliquent aux opérations

– Post-conditions• Une post-condition est un énoncé de ce que doit être le

« monde » (ou plus simplement l'état de l'application ou de l'objet) après l'exécution d'une opération.

– Par exemple sur une opération « racine carrée » sur un nombre, une post-condition pourrait prendre la forme entrée = résultat * résultat où résultat est la sortie de l'opération et entrée la valeur d'entrée.

– La post-condition est une manière de dire ce que nous faisons sans dire comment nous le faisons

• C'est une manière de séparer l'interface de l'implémentation.



– Pré-conditions• Une pré-condition est un énoncé de ce que nous

supposons de l'état du monde avant l'exécution d'une opération.

– Pour l'opération racine carrée, nous pourrions avoir la pré-condition entrée >= 0.

• Une telle précondition indique que c'est une erreur d'invoquer l'opération racine carrée sur un nombre négatif et que les conséquences en sont indéfinies

• Une précondition permet de savoir qui est responsable de la tâche de vérification

– La pré-condition rend explicite que c'est l'appelant qui est responsable de la vérification

• Sinon on risque de ne pas vérifier ou de vérifier 2 fois.



– Exception• A partir des notions de pré- et post-conditions, on peut

donner une définition forte du terme exception– Une exception se produit lorsqu'une opération est

invoquée, sa pré-condition étant satisfaite mais qu'il n'y a pas de retour car sa post-condition ne l'est pas.

– Invariant• Un invariant est une assertion à propos d'une classe.

– L'invariant est toujours vrai pour toutes les instances de la classe

• « toujours » signifiant ici chaque fois qu'un objet est disponible pour qu'on puisse invoquer une opération sur celui-ci.

• L'invariant peut-être faux pendant l'exécution d'une méthode, mais il doit être restauré à son état vraie avant qu'un autre objet ne puisse faire quoi que ce soit au récepteur.



– Assertion et héritage• Les invariants d'une classe et les post-conditions d'une

classe doivent s'appliquer à toutes ses sous-classes– Les sous-classes peuvent choisir de les renforcer

mais pas de les affaiblir.• Les pré-conditions d'une classe doivent s'apliquer

également à toutes ses sous-classes– Les sous-classes peuvent choisir de les affaiblir mais

pas de les renforcer.• Vous devez toujours être en mesure de traiter un objet

d'une sous-classe comme s'il était une instance de la superclasse (principe de substitution).

• Si une sous-classe renforçait sa pré-condition, alors une opération de la superclasse pourrait échouer quand on appliquerait à une sous-classe.

– Pour en savoir plus• http://en.wikipedia.org/wiki/Design_by_contract

http://en.wikipedia.org/wiki/Design_by_contract


Composition et agrégation (1)• Agrégation

– L'agrégation est la relation « est partie de », comme le moteur et les roues sont des parties d'une voiture

• Cependant la distinction entre une association et une agrégation est relativement floue.

– En UML l'agrégation existe mais sa sémantique n'est pas définie !


Composition et agrégation (2)• Composition

– Pour exprimer l'idée de « est partie de », UML dispose en plus de l'agrégation de la relation de composition

• La relation de composition a elle une sémantique bien définie.

• La règle générale avec la composition est que, bien qu'une classe puisse être un composant de plusieurs autres classes, chaque instance ne doit être un composant que de l'une d'entre elles

– Un diagramme de classes peut montrer plusieurs classes de propriétaires potentiels, mais chaque instance n'a qu'un seul objet comme propriétaire.

PointPolygone Cercle1 3..*

1

-centre

1{ordered}


Composition et agrégation (3)• Exemple

– Une instance de Point peut faire partie d'un Polygone ou être le centre d'un cercle mais pas les 2 en même temps

PointPolygone Cercle1 3..*

1

-centre

1{ordered}


Composition et agrégation (4)• Composition (suite)

– On peut s'abstenir de marquer les multiplicités du côté de la composition

• C'est souvent 0..1.• La seule autre possibilité c'est 1.

– Règle de non partage• Cette règle est une des clés de la relation de composition

– Par exemple si on supprime une instance de Polygone, il faudra supprimer les instances de Point dont il est propriétaire

• Idéalement cette suppression doit être automatisée.


Composition et agrégation (5)• Recommandation

– Il est recommandé de ne pas utiliser l'agrégation• Si vous la rencontrez dans des diagrammes tracés par

d'autres, vous devez réfléchir sur la signification que vous devez lui accorder.

– Il n'y a pas de consensus sur son utilisation et des équipes différentes l'utilisent avec des significations différentes.


Attributs et opérations statiques• Définition

– UML désigne comme static une opération ou un attribut s'appliquant à une classe et non à ses instances

• C'est l'équivalent des membres « static » dans des langages comme C++ ou Java.

• On parle aussi de membres de classe– En UML les caractéristiques statiques sont soulignées

dans les diagrammes de classes• Avec Visio il faut rentrée dans les propriétés de la

caractéristique et choisir une portée de classifieur

+getNumero()+getProchainNumeroLibre()

Commande

Static : visibilité de classe

Visibilité d'instance


Propriétés dérivées (1)• Définition

– Les propriétés dérivées sont des propriétés calculées à partir d'autres valeurs

• Par exemple si on considère un intervalle de dates, on peut penser à 3 valeurs

– La date de début, la date de fin et la durée exprimée en nombre de jours

– Ces valeurs sont liées et on peut considérer que la durée est dérivable des 2 autres valeurs.

– On fera alors apparaître un « / » avant la propriété dérivée.

+debut : Date+fin : Date+/duree : Integer

IntervalleDates{duree = debut - fin}


Propriétés dérivées (2)• Interprétation

– Une propriété dérivée indique une contrainte entre valeurs

• Dans l'exemple précédent, il existe une contrainte entre les 3 valeurs, et d'une certaine manière peu importe quelle est la valeur calculée parmi les trois

– Le choix de l'attribut qui doit être noté comme dérivé est arbitraire mais il est utile pour aider à mémoriser la contrainte

• La dérivation peut être également appliquée aux propriétés définies sous forme d'association

– Il suffit alors de les faire précéder le nom de la propriété par un /

– Une autre manière d'interpréter la dérivation est de dire qu'elle indique la différence entre une valeur calculée et une valeur mémorisée

• Cependant cela peut dans certains cas relever trop d'informations sur ce qui est interne à la classe.


Classes-Associations (1)• Définition

– Les classes -associations permettent d'ajouter des attributs, des opérations et d'auttres fonctionnalités aux associations.

• Par exemple– On considère qu'une personne peut participer à

plusieurs réunions. Une réunion pour pouvoir avoir lieu doit se faire entre au moins 2 personnes

– Pour chaque personne participant à la réunion on peut vouloir indiquer son degré d'implication dans la participation à cette réunion.

Personne Réunion

-degre_implicationParticipation

2..* *


Classes-Associations (2)• Définition (suite)

– Autre manière de représenter (presque) la même chose

• Néanmoins la classe-association ajoute une contrainte– Il ne peut y avoir q'une seule instance pour un lien

entre 2 objets quelconques

Personne Réunion

-degre_implicationParticipation

2..* *

Presque équivalent

Personne Réunion-degre_implicationParticipation

1 * 2..* 1


Classes-Associations (3)• Exemple

– Dans les exemples ci-après• Une entreprise ne peut avoir plus d'un rôle dans un

même contrat• Une personne ne peut avoir plus d'un niveau de

compétence dans une même technique

Entreprise Contrat

-descriptionRole

* *

Personne Technique

-niveauCompétence

* *


Classes-Associations (4)• Implémentation

– On implémente le plus souvent une classe-association comme une classe à part entière, mais dans laquelle on prévoit des méthodes qui peuvent fournir de l'information aux classes liées par la classe-association

– De plus on s'assure que la contrainte « un seul objet représentant la classe association pour une paire d'objets liés par cette classe association » est respectée


Associations qualifiées (1)• Définition

– Une association qualifiée correspond en UML à l'idée de tableau associatif, de « map » ou encore de dictionnaire en programmation.

• On qualifie l'association, et cela signifie qu'il y connexion entre les 2 produits liés par l'association pour chaque instance de l'objet qualifiant l'association

• Exemple– Dans l'exemple ci-après, la relation entre les classes

Commande et Ligne de Commande est qualifié par Produit

• Cela signifie qu'il peut y avoir en connexion avec une Commande, une Ligne de Commande pour chaque instance de Produit

CommandeProduit

Ligne de Commande

1

-ligne

0..1


Associations qualifiées (2)• Association qualifiées et multiplicités

– La multiplicité des associations qualifiées peut prêter à confusion

• Dans l'exemple précédent, une Commande peut avoir plusieurs lignes, mais la multiplicité de l'association qualifiée est celle du contexte du qualificatif

– Ainsi sur le diagramme la multiplicité indique qu'une commande a 0..1 ligne pour chaque instance de produit.

CommandeProduit

Ligne de Commande

1

-ligne

0..1


Classe paramétrable• Définition

– En C++ et récemment en Java et C#, il existe la notion de classe paramétrable ou template

• On rappelle que c'est une classe qui est paramétrée par un autre type de donnée

– C'est très utilisé notamment pour les classes de types Liste ou Ensemble

– En UML, on représente une classe paramètrable comme ci-après

+insert()+remove()

SetUnType


Visibilité• Visibilité avec UML

– UML définit 4 abréviations• + : public• - : privé• ~ : package• # : protégé

– Ces 4 niveaux sont définis à l'intérieur du métamodèle, mais leurs définitions varient subtilement dans les langages de programmation, donc attention.


Quelques conseils• Exploration de la logique métier

– Les diagrammes de classes peuvent être très utiles pour explorer le langage métier

• Dans ce cadre, il ne faut pas se focaliser sur les aspects logiciels et il faut conserver une notation très simple

• Ne pas créer systématiquement des diagrammes– Il faut faire porter ses efforts sur les point essentiels

• Mieux vaut avoir peu de diagrammes faciles à utiliser et à mettre à jour que beaucoup de diagrammes obsolètes

• Diagramme de classe signifie étude de la structure– Avec les diagrammes de classes vous vous concentrez

exclusivement sur la structure• Il y a un risque d'ignorer le comportement• Lorsque l'on trace des diagrammes de classes pour

comprendre le logiciel, il faut le faire en conjonction avec une autre technique comportementale (diagrammes de séquence, d'activités ou de machines d'états)


Diagrammes de séquences



– Les diagrammes d'interaction décrivent la façon dont des groupes d'objets collaborent à la réalisation d'un comportement donné.

• UML définit plusieurs formes de diagrammes d'interaction – La forme la plus courante est le diagramme de

séquence– Les autres formes sont

• les diagrammes de communication : ils permettent de représenter les connexions entre entités

• Les diagrammes de timing : ils permettent de représenter les contraintes temporelles

– En général, un diagramme capture le comportement d'un seul scénario

• Il contient un certain nombre d'objets et les messages transmis entre ces objets dans le cadre d'un cas d'utilisation.


Définition et utilisation (2)• Exemple introductif (1)

-quantite : Integer-prix : Double

LigneDeCommande



Commande

Produit

1

-lignes*

*

1

+solvabilite()


Client



ClientProfessionnel


*1

Employe

*

-Commercial0..1



– Considérons le scénario simple suivant, dans le contexte du diagramme de classe précédent.

• Nous avons une commande et nous allons invoquer une méthode pour calculer son prix

– Pour se faire l'objet commande doit lire toutes les Lignes de Commande et déterminer leur prix, en fonction des règles de tarifications des produits.

• Après avoir traité chaque ligne, il doit ensuite calculer une remise globale, qui dépend des règles associées au client.



UneCommande

CalculerPrix

Message trouvé

UneLigneDeCommande UnProduit UnClient

getQuantite

getProduit

unProduit

getDetailsTarification

calculerPrixDeBase

calculerRemise

getInfoRemise

participant

retour

Self-call

activation

message

Ligne de vie



– Le diagramme de séquence précédent représente une implémentation possible du scénario présenté précédemment

• Les diagrammes de séquences mettent en évidence les interactions en représentant chaque participant avec une ligne de vie qui parcourt verticalement la page.

– L'ordre des messages se lit de haut en bas– Ce qui nous permet de comprendre le diagramme

• Une instance de Commande envoie les messages getQuantite et getProduit à l'objet Ligne de Commande.

• L'instance de Commande invoque une méthode sur lui-même, qui envoie un message getInfoRemise à une instance de Client.



– Ce que ne nous permet pas de comprendre le diagramme

• Ce diagramme ne nous permet pas de savoir que– La séquence des messages getQuantité, getProduit,

getDetailsTarification et calculerPrixDeBase doit être répétée pour chaque ligne de la commande

– Dans le même temps calculer remise ne sera invoquée qu'une seule fois


Définition et utilisation (7)• Participants

– La plupart du temps les participants à un diagramme d'interaction sont des objets

• En UML 2, le rôle des participants est en fait plus complexe mais dépasse le cadre de ce cours.

– La syntaxe complète pour réprésenter un participant est de la forme

• Nom : Classe– La classe est facultative, néanmoins si on la met, il

ne faut pas oublier les « : ».• Ligne de vie

– Chaque ligne de vie possède une barre d'activation qui montre la durée de l'activité du participant dans l'interaction.

• Les barres d'activation sont facultatives néanmoins elles clarifient le comportement.


Définition et utilisation (8)• Retour

– Le nommage associé à un retour est souvent utile pour corréler les participants dans un diagramme

• Dans notre exemple, l'appel de getProduit retourne unProduit

– Il porte le même nom que le unProduit auquel est envoyé l'appel de getDetailsTarification et qu'il s'agit donc du même participant.

– On peut utiliser des flèches de retour pour tous les appels qui renvoient quelque chose

• Néanmoins, afin de ne pas éviter d'encombrer inutilement le diagramme, on recommande en général de réserver les flèches de retour aux cas dans lesquels elles ajoutent de l'information.

• Message trouvé– Le premier message n'a été envoyé par aucun

participant et provient d'une source indéterminée• C'est ce qu'on appelle un message trouvé


Définition et utilisation (9)• Solution alternative au scénario initial

UneCommande

CalculerPrix

UneLigneDeCommande UnProduit UnClient

calculerPrix

getMontantRemise(uneCommande)

getValeurDeBase

paramètre

retour

getPrix(quantite : nombre)

montantRemise


Création et suppression de participants• Création

– Pour représenter la création un participant dans un diagramme de séquence, on trace une flèche allant directement vers la boite du participant

• Le nom du message est facultatif en cas d'emploi du constructeur mais on peut le marquer avec le mot « new »

• Si le participant fait quelque chose immédiatement après qu'il a été créé, on place une barre d'activation juste sous la boite du participant.

• Suppression– La suppression d'un participant est indiqué par un

grand X.• Une flèche de message entrant dans le X signifie qu'un

participant en supprime explicitement un autre• Un X à la fin d'une ligne de vie montre que le participant

se détruit lui-même.


Instructions itératives et conditionnelles (1)• Préambule

– Les diagrammes de séquence permettent de représenter de façons claires

• les appels entre participants• Quel participant effectue quel traitement

– Par contre, ils conviennent mal pour représenter les algorithmes

• Les diagramme de séquence sont des moyens de visualiser les interactions entre les objets et non une façon de modéliser la logique de contrôle (il vaut mieux utiliser pour se faire un diagramme d'activités.

• Néanmoins si l'on souhaite montrer des alternatives ou des boucles sur ces diagrammes, on va utiliser des cadres d'interaction


Instructions itératives et conditionnelles (2)• Cadres d'interaction

– Les cadres d'interaction servent à délimiter une zone du diagramme de séquence.

• On les utilise pour définir des structures itératives ou alternatives

• En règle général, les cadres consistes en une région d'un diagramme de séquence divisée en plusieurs fragments.

– Chaque cadre a un opérateur et chaque fragment peut avoir une garde.

• Par exemple, pour représenter une structure itérative on utilise l'opérateur loop et on place la condition de l'itération dans ce que l'on appelle une garde

• Pour représenter une alternative, on utilise le l'opérateur alt et on place une condition dans chaque fragment. Seul le fragment dont la garde est vrai s'exécutera. Quand il n'y a qu'une seule région, il existe un opérateur opt.

– Une garde est une expression conditionnelle placée entre crochets et indique que le message ne sera envoyé que si la garde est vraie


Instructions itératives et conditionnelles (3)• Cadres d'interaction : limites

– Il est impossible d'indiquer que des gardes sont mutuellement exclusives.

– La notation ne fonctionne qu'avec un seul envoi de message et fonctionnent mal quand plusieurs messages provenant d'une seule barre d'activation sont dans la même structure itérative ou alternative.


Appels synchrones et asynchrones• Message synchrone

– Représentation : Flèches pleines– Si un appelant émet un message synchrone, il doit

attendre que celui-ci ait terminé son travail pour continuer ces traitements

• Message asynchrone– Représentation : Flèches « bâtons »

• Ancienne représentation : demi-pointe de flèche– Si un appelant émet un message asynchrone, il peut

continuer sont traitement sans avoir besoin d'attendre la réponse.

• Les messages asynchrones permettent d'obtenir une meilleur réactivité et permettent de réduire le coupalge temporel, mais ils rendent le déboggage plus difficile.

• On en rencontre dans les applications multithreads et dans le middleware orienté messages


Diagrammes de séquence système• Définition

– Un diagramme de séquence peut servir à illustrer des scénarios particuliers.

• Dans ce cas, on montre l'acteur principal à gauche, puis un objet représentant le système en boîte noire et enfin les éventuels acteurs secondaires sollicités durant le scénario à droite du système.


synthèse• Quand utiliser les diagrammes de séquence ?

– On utilise les diagrammes de séquences lorsque l'on veut visualiser le comportement de plusieurs objets au sein d'un seul cas d'utilisation

• Les diagrammes de séquence mettent bien en évidence les collaborations entre les objets.

• Il conviennent nettement moins bien pour la définition précise d'un comportement.

– Pour décrire les comportements d'un même objet dans plusieurs cas d'utilisation, il faut utiliser un diagramme d'état et les diagrammes d'activités si l'on doit décrire des comportements parallèles.


Diagrammes d'états



– Les diagrammes de machines d'états permettent de décrire le comportement d'un système.

• Les diagrammes d'états existent sous différentes formes depuis 1960.

• Les approches objets les ont adoptés pour représenter les comportement

– Dans les approches objets, on utilise un diagramme d'états pour une seule classe, pour mettre en évidence le comportement d'un seul objet durant son cycle de vie.


Définition et utilisation (2)• Utilisation

– Les diagrammes d'états sont adaptés pour décrire le comportement d'un objet à travers plusieurs cas d'utilisation.

– Ils sont par contre mal adaptés à la description de comportement impliquant plusieurs objets qui collaborent

• Pour décrire le comportement de plusieurs objets dans un cas d'utilisation on utilise des diagrammes d'interaction (diagrammes de séquences)

• Pour décrire l'organisation séquentielle globale des activités de plusieurs objets et cas d'utilisation, les diagrammes d'activités sont bien adaptés.


Définition et utilisation (3)• Exemple (d'après M. Fowler) (1/3)

– Enoncé• On considère le système de contrôle d'un panneau secret

dans un donjon– Dans ce donjon, nous conservons dans un coffre

difficile à trouver un trésor.– Pour découvrir le coffre, on doit ôter une certaine

chandelle de son chandelier de la pièce dans laquelle se trouve le panneau secret. Cependant le panneau secret ne s'effacera que si la porte de la pièce est fermée.

– Une fois le coffre découvert, on peut insérer une clé dans la serrure de ce dernier pour l'ouvrir. Néanmoins pour plus de sécurité, il faut avant de tourner la clef, d'abord remettre la chandelle à sa place. Si on néglige cette précaution, un monstre est libéré.



– Modélisation

Attente Fermé

OuvertPseudo-état initial

Etat finalTransition

Chandelle ôtée [porte fermée]/découvrir panneau

Clé tournée [chandelle dedans]/ouvrir coffre

Clé tournée [chandelle dehors]/lâcher le monstre

Coffre fermé



– Interprétation du modèle• Le diagramme commence à l'état de l'objet « système de

contrôle » au moment de sa création, l'état « Attente ».– Le diagramme à un « pseudo-état initial » qui n'est

pas vraiment un état mais qui correspond à cet instant de création.

• Notre système de contrôle peut avoir 3 états– « Attente », « Fermé » et « Ouvert »– Le diagramme précise les règles selon lesquelles le

contrôleur passe d'un état à l'autre.• Ces règles sont exprimés sous la forme de transitions,

qui correspondent sur le diagramme aux lignes qui connectent les états.

• Une transition indique un mouvement entre 2 états.• Chaque transition comprend 3 parties (optionnelles) :

déclencheur [garde] / activité


Transition (1)• Etiquette d'une transition (1/3)

– Une transition porte une étiquette comprenant 3 parties optionnelles : déclencheur [garde] / activité

• déclencheur– Le déclencheur est généralement un unique

événement qui déclenche potentiellement un changement d'état

• garde– La garde, si elle est présente, est une condition

booléenne qui doit être vraie pour que la transition soit empruntée.

• activité– L'activité est un comportement quelconque qui est

exécuté pendant la transition.• Il peut s'agir de n'importe quelle expression

comportementale.



– Les 3 parties sont optionnelles • garde

– Une garde absente indique qu'on emprunte la transition dès que l'événement se produit

• activité– S'il n'y a pas d'activité c'est qu'il ne se passe rien

durant la transition• déclencheur

– Le déclencheur est rarement absent mais ce n'est pas impossible

• Cela indique qu'on emprunte la transition immédiatement

• Ce cas se présente essentiellement dans les états d'activités que l'on verra dans la suite du cours



– Evénement et transition• Lorsqu'un événement se produit dans un état, on ne peut

emprunter qu'une seule transistion sortante– Si on a plusieurs transitions avec le même

événement déclencheur, il faut s'assurer dans cette situation que les gardes s'excluent mutuellement (comme dans l'exemple).

• Si un événement survient et qu'aucune transition n'est valide, cet événement est ignoré.


Etat final• Signification

– L'état final indique que la machine d'états a terminé et la destruction de l'objet correspondant

• Dans notre exemple, si quelqu'un tombe dans le piège, c'est la fin du cycle de vie de l'objet « système de contrôle »

– Nous devons remettre le monstre dans sa cage, nettoyer le tapis et rédémarrer le système.


Objet et état• Faire attention

– Une machine d'état ne représente que ce que l'objet observe ou active directement.

– On utilise en POO très souvent le terme d'état pour signifier la combinaison de toutes les données dans les champs des objets.

• Dans le cadre d'une machine d'états, l'état est une notion plus abstraite

– Différents états impliquent différentes façons de réagir aux événements.


Activités internes (1)• Définition

– Les états peuvent réagir aux événements sans transition, grâce à des activités internes

• On place alors l'événement, la garde et l'activité dans la boîte d'état elle-même.

• Une activité interne est semblable à une auto-transition– Une transition qui « reboucle » et retourne à l'état

antérieur.– La syntaxe des activités internes observe la même

que celle des transitions avec événement déclencheur – garde – activité

– Activités spéciales• Il existent des activités spéciales

– L'entrée (entry) et la sortie (exit)• L'activité entry est exécutée à chaque fois que l'on

rentre dans un état• L'activité exit est exécuté à chaque fois que l'on sort

d'un état


Activités internes (2)• Exemple

Saisieentry / tout sélectionnerexit / maj champcaractère / lecture caractèreaide [détaillée] / ouvrir page d’aideaide [muette] / maj barre d’état


Etats d'activité (1)• Définition

– On peut décrire des états pour des objets inactifs, qui attendent l'événement suivant avant de faire quelque chose

– Cependant on peut également rencontrer des états dans lesquels l'objet exécute une activité continue

• On parle d'état d'activité • L'activité continue est marquée par do/ (d'où parfois le

terme d'activité do)• Quand l'activité do est finie, toute transition sans

événement déclencheur est empruntée


Etats d'activité (2)• Exemple


Etats d'activité (3)• Exemple (suite)

– Dans l'exemple précédent, l'état « recherche » est un état d'activité.

• L'activité continue est marquée par « do/ »• Une fois l'activité terminée, toute transition sans

déclencheur est empruntée– Ici vers l'affichage de nouveaux matériels

• Si l'événement « annuler » survient durant l'activité, le programme met fin à l'activité do et on retourne à l'état correspondant à la « Fenêtre mise à jour des matériels».


Etats d'activité (4)• Synthèse

– Les 2 types d'activités (activités ordinaires et activités do) correspondent à l'exécution d'un comportement.

– La différence entre les 2 est que• Les activités ordinaires ont lieu « instanénment » et ne

peuvent être interrompues par des événements ordinaires.

• Les activités do peuvent prendre un temps fini et être interrompues.

• Note– En UML 1, on utilisait le terme d'action pour les

activités ordinaires et on parlait d'activité pour les activités do.


Superétats (1)• Présentation

– On constate souvent que certains états partagent des activités internes et des transitions communes.

• Dans ces cas-là, on peut faire des sous-états et transférer le comportement dans un super-état


Superétats (2)• Exemple

– En absence de superétat ci-dessous, on devrait représenter l'état d'annulation pour les 3 sous-états.

Entrer numéro de téléphoneEntrer nomprécédentsuivantsuivantprécédentEntrer les détails de de la connexionVisualiser les ConnexionsnouveauannulersauvegarderChoix partagé ou solo


Etats concurrents (1)• Exemple

– On peut décomposer un état en plusieurs diagrammes d'états orthogonaux.

– On considère ci-après un radio réveil qui peut déclencher le lecteur de CD-ROM ou la radio et afficher l'heure courante ou l'heure réveil.

• Les choix CD/Radio et heure courante/heure de réveil sont des choix orthogonaux

– Séparer les 2 composantes du comportement dans des diagrammes distincts rend la présentation plus claire


Etats concurrents (2)• Exemple (suite)


Etats concurrents (3)• Exemple (suite)

– Le pseudo-état historique indique que lorsque le réveil est mis en marche, le choix radio/CD retourne à l'état dans lequel le réveil était avant d'être éteint.

• La flèche qui en part indique l'état dans lequel doit être le réveil doit être la première fois.


Implémentation des diagrammes d'états (2)• 3 manières d'implémenter un diagramme d'état

– Il existe 3 grandes manières d'implémenter les diagrammes d'états : le switch imbriqué, le modèle de conception (design pattern) « Etat » et les tables d'états

• Switch– L'utilisation du switch est probablement la plus directe

mais pas la meilleure solution• On définit une méthode/procédure de gestion des

événements avec un switch dépendant de la valeur de l'événement

– Cette solution est assez verbeuse mais dans les cas simple

– Elle risque de devenir facilement incontrôlable.• Cette solution est à éviter dans la mesure du possible.


Implémentation des diagrammes d'états (3)• Modèle de conception Etat (1/4)

– Modèles de conception (design patterns)• UML permet d'exprimer une conception orientée objet• Les patterns sont des exemples de conception

– Les design patterns décrivent des façons courantes de procéder pour résoudre des problèmes de conceptions récurrents

– Ces patterns sont collectés et documentés par des personnes expérimentées qui repèrent des thèmes récurrents dans les conceptions

– Les patterns sont ainsi décrits que d'autres puissent les lire et voir comment les appliquer).



– Modèles de conception (suite)• Un pattern est plus qu'un modèle

– Il indique également la raison pour laquelle il est conçu comme il l'est.

– Le pattern identifie le problème clairement et explique pourquoi il le résout ainsi que les circonstances dans lesquelles il fonctionne et celles dans lesquelles il ne fonctionne pas.

• Les patterns fournissent une série de solutions, montrent ce qui fait un bon modèle et comment procéder pour le construire.

• Référence– « Design Patterns – Catalogue de modèles de

conception réutilisables » de Gamma, Helm, Johnson et Vlissides chez Vuibert

– www.hillside.net/patterns

http://www.hillside.net/patterns



– Le pattern Etat crée une arborescence de classes d'états pour gérer le comportement des états.

• Chaque état du diagramme a une sous-classe d'état.– Dans l'exemple initial avec le contrôleur de panneau

secret• Le contrôleur a des méthodes pour chaque événement et

celles-ci délèguent le traitement aux classes état.• Le sommet de l'arborescence est une classe abstraite qui

implémente toutes les métodes gestionnaires d'événements, celles-ci ne réalisant aucune opération.

– Pour chaque état concret, on redéfinit simplement les méthodes événementielles spécifiques pour lesquelles cet état possède des transitions.


Implémentation des diagrammes d'états (7)• Table d'états (1/2)

– La technique de la table d'états capture les informations du diagramme sous forme de données.

– En reprenant l'exemple du début du cours on arrive à une présentation tabulaire comme celle du tableau ci-après.

• Il faudrait ensuite un petit interpréteur qui lit les états de la table au moment de l'exécution ou un générateur de code qui crée les classes en fonction de la table.

Etat source Etat Cible Evénement Garde ProcédureAttente Fermé Chandelle otée Porte ouverte Découvrir

coffreFermé Ouvert Clé tournée Chandelle

dedans Ouvrir coffre

Fermé Final Clé tournée Chandelledehors

Libérer lemonstre

Ouvert Attente Coffre fermé


Implémentation des diagrammes d'états (8)• Table d'états (2/2)

– La table d'états demande plus de travail mais ce travail n'est à réaliser qu'une seule fois.

• De plus c'est réutilisable pour d'autres conception et programmes utilisant des états.

• La table d'étas peut de plus être modifiée sans recompilation au moment de l'exécution, ce qui peut s'avérer fort pratique dans certaines situations.


Synthèse• Utilisation

– Les diagrammes d'états sont adaptés pour décrire le comportement d'un objet à travers plusieurs cas d'utilisation.

• Conseil– Ne pas chercher à tracer un diagramme d'états pour

chacune des classes du système.• Ne se limiter qu'aux classes qui montrent un

comportement intéressant et pour lesquelles le diagramme d'états aidera à mieux comprendre le déroulement des opérations.

– Les diagrammes d'états sont souvent utilisés pour les objets de l'interface utilisateur.


Diagrammes d'activités



– Les diagrammes d'activités permettent de décrire la logique procédurale, les processus métiers et les enchaînements d'activités (workflows)

– Les diagrammes d'activités prennent en charge les comportements parallèles.

– Les diagrammes d'activités ont connu beaucoup de modification entre UML 1 et UML 2

• En UML1, ils étaient un cas particulier de diagrammes d'états

• En UML2, ce n'est plus le cas et ils peuvent servir à modéliser les workflows.


Définition et utilisation (2)• Exemple introductif (1/4)



– Après le noeud initial et l'action recevoir commande, nous rencontrons un débranchement

• Un débranchement a un seul flot entrant et plusieurs flots sortants concurrents.

• Les actions Préparer commande et les autres actions de cette branche s'exécute en parallèle des actions Envoyer facture et des autres actions de cette branche

– Cela signifie notamment que l'ordre d'exécution de ces actions en parallèle n'a pas d'importance et que ces différentes activités peuvent être « fractionnées ».

– Les diagrammes d'activités permettent au responsable du processus de choisir l'ordre d'exécution.

• Le diagramme se borne à énoncer les règles minimales qui doivent être appliquées.

• C'est important pour la modélisation métier dans laquelle les processus s'exécutent souvent en parallèle ou dans les algorithmes concurrents.



– Dans des situations de parallélismes, la synchronisation est indispensable

• On ne clôture pas la commande tant qu'elle n'est pas livrée et payée.

• La synchronisation dans le diagramme s'effectue avec une jonction telle que celle qui précède l'activité Clôturer Commande.

– Avec une jonction, le flot sortant ne peut être exécuté que lorsque toutes les activités entrantes sont terminées.

• Vous ne pouvez clôturer la commande que lorsque vous avez reçu son règlement et que vous l'avez livré.



– On peut décrire des comportements conditionnels à l'aide de décision et de fusions

– Une décision• Nommée branchement en UML1• Elle a un seul flot entrant et plusieurs flots sortants

– Chaque flot sortant est muni d'une garde (une condition booléenne).

– Quand on atteint une décision, on ne peut emprunter que l'un des flots sortants

• Les gardes doivent être mutuellement exclusives• Employer la garde [else] indique que le flot [else] doit

être emprunté si toutes les autres gardes de la décision sont fausses.

– Une fusion• Elle a plusieurs flots entrants et un seul en sortie. Elle

marque la fin d'un comportement conditionnel initialisé par une décision.


Décomposition des actions (1)• Actions et sous-activités (1)

– Les actions peuvent être décomposées en sous-activités.

• Si on reprend dans l'exemple précédent la logique de livraison et que nous la définissons en tant qu'activité propre.



– On peut implémenter les actions sous formes de sous-activités ou sous forme de méthodes.

• On peut représenter une sous-activité par le symbole du râteau

• On peut représenter un appel de méthode avec la syntaxe nom-de-classe::nom-de-methode

• On peut également écrire un fragment de code dans le symbole d'action si nécessaire.

– Par exemple si le comportement invoqué ne correspond pas à un seul appel de méthode.


Partitions (1)• Qui fait quoi ?

– Les diagrammes d'activités indiquent ce qui se passe mais ne disent pas qui fait quoi.

• Du point de vue développement, cela signifie qu'ils ne précisent pas quelle classe est responsable de chaque action.

• Du point de vue modélisation des processus métiers, cela signifie qu'ils ne permettent pas de savoir quelle partie de l'organisation exécute chaque action.

– Ce n'est pas nécessairement gênant, car il est souvent plus significatif de se concentrer sur ce qui est fait que sur les responsables de telle ou telle partie d'un comportement.

– Pour représenter qui fait quoi, on peut diviser un diagramme d'activités en partitions, qui montrent quelles actions sont exécutées par une classe ou une unité organisationnelle


Partitions (2)• Exemple


Signaux (1)• Emission et réception de signaux

– Les actions d'un diagramme d'activité peuvent également répondre à des signaux ou en envoyer.

• Un signal indique que l'activité reçoit un événement d'un processus extérieur. L'activité est donc constamment à l'écoute de ses signaux, et le diagramme définit la façon dont elle réagit.

– On peut avoir des signaux temporels• Ils sont liés au passage du temps

– Ils peuvent indiquer par exemple des fins de mois dans une année fiscale ou des microsecondes dans un contrôleur temps réel.


Signaux (2)• Emission et réception de signaux : exemple 1

– Nous souhaitons modéliser par un diagramme d'activité, la préparation d'un voyage en avion.

• On commence les valises 2 heures avant que l'avion ne décolle

• Pour aller à l'aéroport, on prend un taxi– Si nous terminons nos bagages rapidement, on doit

attendre que le taxi soit arrivé– Si le taxi arrive alors que nos bagages ne sont pas

prêts, le taxi nous attendra avant de partir.


Signaux (3)• Emission et réception de signaux : exemple 2

– Considérons une station de travail qui est mise sous tension.

• Elle entame une séquence de démarrage, puis demande à l'utilisateur de se connecter.

• Après la saisie du nom d'utilisateur et du mot de passe, la station demande au réseau de valider l'utilisateur.

• Après la validation, la station termine le processus de démarrage


Jetons, arcs et flots• Jetons

– Dans un diagramme d'activités, il y production et consommation de jetons

• Le noeud initial crée un jeton, qui passe à l'action suivante, qui s'exécute et passe le jeton à la suivante, etc.

• Lors d'un débranchement, le jeton entrant est pris en compte et le débranchement produit un jeton sur chacun des flots sortants

• Lors d'une jonction, plusieurs jetons arrivent et rien ne se passe tant qu'ils n'ont pas tous atteint la jonction ; un jeton est alors produit sur le flot sortant.


Jetons, arcs et flots• Arcs et flots

– UML 2 emploie les termes de flot (flow) et arc (edge) de façon synoyme pour décrire les connexions entre 2 actions.

• La forme d'arc la plus élémentaire est une simple flèche entre 2 actions.

• On peut associer un nom à un arc si on le souhaite.– On peut utiliser des connecteurs pour éviter de tracer

toutes la ligne• Les connecteurs vont par paires : l'un avec un flot entrant,

l'autre avec un flot sortant, les 2 portants la même étiquette.

– On peut transmettre des objets le long des arcs• On peut les représenter en plaçant une boite de classe

sur l'arc ou en utilisant des connecteurs sur les actions


Régions d'expansion (1)• Définition (1/2)

– On peut rencontrer avec les diagrammes d'activités des situations dans lesquelles la sortie d'une action déclenche plusieurs invocations d'une autre action.

• Pour représenter cette situation on peut utiliser une région d'expansion

– Une région d'expansion marque une zone dans laquelle des actions se déroulent une fois pour chaque élément d'une collection.

– On peut avoir le même nombre d'éléments dans la collection en entrée que celle en sortie, mais nous pourrions également en avoir moins.

• Dans ce cas la région d'expansion joue le rôle de filtre.


Régions d'expansion (2)• Définition (2/2)

– On utilise le mot clé « concurrent » pour indiquer que les actions dans la région d'expansion s'effectue en parallèle.

• Si on ne précise rien, on a une région d'expansion itérative, chaque élément de l'entrée étant traité un par un.


Régions d'expansion (3)• Terminaison de flot

– Quand on a plusieurs jetons, comme dans le cas d'une région d'expansion, on peut avoir des flots qui s'arrêtent même si l'activité en tant que telle continue.

• Une terminaison de flot indique qu'un flot donné se termine sans que l'ensemble de l'activité elle-même ne prenne fin


Spécifications des jonctions• Définition

– Par défaut l'exécution passe au flot sortant lorsque tous les flots entrants ont atteints la jonction

• Dans certains cas, notamment si un flot a plusieurs jetons, il peut être utile d'avoir une règle plus complexe.

– Une spécification de jonction est une expression booleénne attachée à la jonction

• Chaque fois qu'un jeton arrive à la jonction, la spécification est évaluée

– Si elle est vraie un jeton sortant est émis


Conseils pratiques• Synthèse

– Un diagramme d'activités représente la suite d'étapes qui constituent un processus complexe, par exemple un algorithme ou un workflow

– Il exprime le flux de contrôle mais en se concentrant sur les opérations plutôt que sur les objets

– Les diagrammes d'activités sont particulièrement utiles durant les premiers stades de la conception des algorithmes et des workflows.

– Equilibrer les diagrammes d'activités • Le niveau de détails des diagrammes doit être cohérent

dans un même diagramme.– Attention à réaliser avec soins les branchements

conditionnels– Attention aux activités concurrentes

• La concurrence signifie que les activités peuvent se terminer dans un ordre quelqconque.


Les autres diagrammes UML :packages, déploiement, objet, etc.


Diagrammes de déploiement (1)• Définition

– Les diagrammes de déploiement représentent l'agencement physique d'un système

• Ils permettent notamment d'indiquer sur quels composants matériels les différents composants logiciels s'exécutent

• Les diagrammes de déploiement sont des diagrammes simples

– Ils peuvent être utilisés à profit dans le cadre de toute opération de déploiement non triviale.


Diagrammes de déploiement (2)• Eléments d'un diagramme de déploiement (1/4)

– Les principaux éléments sont des noeuds connectés par des voies de communication.

• Un noeud est une unité susceptible d'héberger un logiciel• Il en existe 2 formes

– Un équipement qui est un matériel, i.e. un ordinateur ou un composant physique plus simple connecté à un système

– Un environnement d'exécution est un logiciel qui héberge ou contient d'autres logiciels

• Par exemple un système d'exploitation ou un processus container.



– Les principaux éléments sont des noeuds connectés par des voies de communication.

• Les noeuds contiennent des artefacts – Ce sont des manifestations physiques du logiciel,

généralement des fichiers.– Ces fichiers peuvent êtres des exécutables

• Binaires, .exe, DLL, archives JAR, des scripts, etc.– Ces fichiers peuvent également être des fichiers de

données, des fichiers de configurations, des documents HTML, etc.

– Faire figurer un artefact dans un noeud signifie que l'artefact est déployé sur ce noeud



– Représentation des artefacts• En les représentant avec des boites de classes

– Dans ce cas là, on utilise le mot clé « artifact »• En mettant leur nom directement dans un noeud• On peut également étiqueter les noeuds ou les artefacts

avec des valeurs marquées pour indiquer différentes informations

– Par exemple le fournisseur, le système d'exploitation, l'emplacement, etc.

– Quand on a plusieurs noeuds physiques s'acquittant de la même tâche logique

• On peut soit le représenter par plusieurs boîtes différentes ou l'exprimer avec un nombre sous forme de valeur marquée.



– Les voies de communication entre les noeuds indiquent la façon dont les composants communiquent

• On peut les documenter en y plaçant des informations sur les protocoles de communications utilisés.


Diagrammes de packages (1)• Présentation

– Un package permet de prendre n'importe quelle construction d'UML et de grouper ses éléments dans des unités de plus haut niveau.

• La plupart du temps, un package sert à grouper des classes même s'il peut être utilisé pour regrouper tout autre élément d'UML.

– Un diagramme de packages représente les packages et leur dépendances

– Ces diagrammes sont utiles quand on modélise de gros systèmes pour obtenir une image des dépendances entre leurs principaux éléments

• Cela correspond bien en général aux structures de programmation courante.

• Représenter les packages et les dépendances permet de garder les dépendances sous contrôle

• Les diagrammes de package représentent un mécanisme de regroupement au moment de la compilation.


Diagrammes de packages (2)• Package et classes

– Dans un modèle UML, chaque classe ne peut être membre que d'un seul package.

• Un package peut être membre d'un autre package– On peut ainsi avoir une structure hiérarchisée dans

laquelle les packages de haut-niveau sont décomposés en sous-packages possédant leurs propres sous-packages, et ainsi de suite jusqu'à ce qu'on atteigne le plus bas niveau de la hiérarchie (les classes)

• Un package peut contenir à la fois des sous-packages et des classes.

– En terme de programmation, les packages UML correspondent à des groupements tels que les packages Java ou les espaces de noms C++ ou .NET


Diagrammes de packages (3)• Package et espace de noms

– Chaque package représente un espace de noms• Chaque classe doit porter un nom unique dans le

package dont elle fait partie– Pour lever les ambiguïtés de nom qui peuvent exister

entre des classes de même nom dans des packages séparés on peut utiliser un nom pleinement qualifié

• i.e. un nom qui montre la structure de package dont la classe fait partie

• En UML, les doubles deux-points indiquent un nom de package

– Systeme::Collection::Liste et ISAIP::Collection::Liste


Diagrammes de packages (4)• Représentation

– Les packages sont représentés par des dossiers à onglet

• On peut – indiquer le nom du package– montrer son contenu avec des icônes de classes ou

avec des noms– utiliser des noms pleinement qualifiés ou des noms

simples pour les noms de packages ou de classes


Diagrammes de packages (5)• Visibilité

– UML permet aux classes d'un package d'être publiques ou privées

• Une classe publique fait partie de l'interface du package et peut être utilisée par les classes d'autres packages

• Une classe privée est masquée• Attention : selon l'environnement dans lequel vous

effectuez votre développement vous aurez peut-être à gérer des règles de visibilité des packages et des espaces de noms différentes.


Diagrammes de packages (6)• Design Pattern « Façades »

– Idée : réduire l'interface du package en n'exportant qu'un petit sous-ensemble des opérations associées aux classes publiques du package.

• Toutes les classes du packages ont une visibilité privée et on ajoute des classes « publiques » pour les comportements publics.

• Ces classes supplémentaires nommés « façades » délèguent ensuite les opérations publiques aux classes privées du même package


Diagrammes de packages (7)• Dépendance (1/2)

– UML autorise la représentation de dépendances entre toutes sortes d'éléments.

• On utilise des dépendances à chaque fois que l'on veut montrer comment des changements apportés à un élément peuvent en entraîner dans d'autres éléments.

– Une dépendance existe entre 2 éléments si • des changements apportés à la définition de l'un d'entre

eux (le « fournisseur ») peuvent entrainer des modifications dans l'autre (le « client »).

– Au niveau des packages, des dépendances peuvent exister parce qu'une classe du package (au moins) est dépendante d'une ou plusieurs classes d'un autre package.


Diagrammes de packages (8)• Dépendance (2/2)

– Il est important de noter qu'une dépendance est unidirectionnelle

• Types de dépendance (rappel)– UML dispose de nombreuses sortes de dépendances

• Chacune avec sa sémantique et ses mots clés particuliers

– La dépendance de « base » est la plus courante et est utilisée sans mot clé


Diagrammes de communication• Présentation

– Les diagrammes de communication sont un type particulier de diagramme d'interaction

• Ils mettent l'accent sur les liaisons de données entre les différents participants à l'interaction

• Au lieux de représenter chaque participant par une ligne de vie et la suite de messages sur un axe vertical comme dans les diagrammes de séquence, les diagrammes de communication permettent de palcer librement les participants, de tracer des liens pour montrer comment ils sont connectés et de numéroter les messages pour suivre la séquence d'appels.

– En UML 1, ces diagrammes s'appelaient diagrammes de collaboration

– On peut les utiliser à la place des diagrammes de séquences

• Leur utilisation est préférable si vous souhaitez mettre l'accent sur les liens entre objets plutôt que sur les séquences d'appels.

•


Diagrammes de vue d'ensemble des interactions• Présentation

– Ces diagrammes sont une combinaison de diagrammes d'activités et de diagrammes de séquences.

– On peut les voir soit• Comme des diagrammes d'activités dans lesquels les

activités sont remplacés par de petits diagrammes de séquences

• Comme des diagrammes de séquences morcelés, la notation des diagrammes d'activités servant à mettre en évidence le flot de contrôle


Diagrammes de timing• Présentation

– Les diagrammes de timing sont une autre forme de diagramme d'interaction dans lesquels l'accent est mis sur les contraintes temporelles

• Soit pour un seul objet• Soit pour un groupe d'objets

– Ces diagrammes sont similaires aux chronogrammes utilisés par les électroniciens

– Ils sont utiles pour représenter les contraintes temporelles entre les changements d'état de différents objets.


Diagrammes d'objets• Présentation

– Un diagramme d'objets est un instantané des objets d'un système à un moment donné.

• On parle souvent de diagrammes d'instances puisqu'ils représentent des objets et non des classes.

– Les diagrammes d'objets sont utiles pour représenter des exemples d'objets connectés entre eux.

• Il est souvent possible de définir précisément une structure avec des diagrammes de classes mais cette structure demeure trop difficile à comprendre

• On peut alors utiliser un diagramme d'objets pour représenter un exemple de configuration d'objets.

– Intéressant lorsque les connexions possibles entre les objets sont complexes.

– Les diagrammes d'objets sont des spécifications d'instances et non des instances réelles

• Une spcéification d'instance est une instance partiellement définie.


Structures composites• Présentation

– Les structures composites permmettent de décomposer hiérarchiquement une classe en une structure interne

• Cela permet de diviser un objet complexe en ses différentes parties

– Une manière de voir les structures composites par rapport aux packages est de considérer que

• Les packages représentent des groupements lors de la compilation

• Les structures composites représentent des groupements lors de l'exécution.

– Ainsi les structures composites sont bien adaptées à la représentation des composants et à la façon de les décomposer en différentes parties.

• Note : il existe en UML une notation propre aux composants. Ces notations peuvent être réutilisés dans les structures composites.

– Ces diagrammes sont une des nouveautés d'UML2

cours d'introduction à uml

Technology

site web