Cours Uml Année 1

1 Support de Formation UML - M. TRAZIE Yves Roger – Ingénieur en Informatique

SUPPORT DE COURS UML

(Unified Modeling Language)


SOMMAIRE CHAPITRE I : PRESENTATION D’UML

I – Origines II ‐ Qu’est ce que UML III – Différents types de diagrammes IV – Eléments de modélisation

CHAPITRE II : DIAGRAMME DE CAS D’UTILISATION

I ‐ But de ce diagramme. II ‐ Acteurs et cas d’utilisation. III ‐ Relations entre cas. IV ‐ Relation entre acteurs. V ‐ Exemple récapitulatif. VI ‐ Méthodologie

CHAPITRE III : DIAGRAMME DE CLASSES

I ‐ Représentation des classes. II ‐ Relations entre classes. III ‐ Méthodologie.

CHAPITRE IV : DIAGRAMME DE SEQUENCE

I ‐ Envois de messages. II ‐ Fragments d’interaction combinés.


CHAPITRE I: PRESENTATION D’UML I – ORIGINES

A quoi sert une méthode ? Une méthode définit une démarche reproductible pour obtenir des résultats fiables. Tous les domaines de la connaissance utilisent des méthodes plus ou moins sophistiquées et plus ou moins formalisées. Les cuisiniers parlent de recettes de cuisine, les pilotes déroulent des check‐listes avant le décollage, les architectes dessinent des plans… UML est l'accomplissement de la fusion de précédents langages de modélisation objet : Booch, OMT, OOSE. Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML est à présent un standard défini par l'Object Management Group (OMG). La dernière version diffusée par l'OMG est UML 2.4.1 depuis août 2011 Booch, Jacobson et Rumbaugh se fixent 4 objectifs:

– représenter des systèmes entiers (au‐delà du seul logiciel) par des concepts objets, – établir un couplage explicite entre les concepts et les artefacts exécutables, – prendre en compte les facteurs d’échelle inhérents aux systèmes complexes et critiques, – créer un langage de modélisation utilisable à la fois par les humains et les machines.

Les principales étapes de l’évolution de UML

RUP workshop, 07.07.2000Copyright © 2000 Rational Software, all rights reserved 1-16

Historique d’UML

Booch ‘91G. Booch

OOSEI.Jacobson

Booch ‘93 OMT-2

UML 0.8

UML 0.9

UML 1.0

Fragmentation

Unification

Standardisation

Industrialisation

OMT - 1J. Rumbaugh

UML 1.1Novembre 97

Janvier 97

Juillet 96

Octobre 95

Standardisation OMG

Rational,IBM, HP, Microsoft, Oracle,

ObjecTime...

... ...

UML 1.3


UML est utilisé pour spécifier, visualiser, modifier et construire les documents nécessaires au bon développement d'un logiciel orienté objet. UML offre un standard de modélisation, pour représenter l'architecture logicielle. Les différents éléments représentables sont :

‐ Activité d'un objet/logiciel ‐ Acteurs ‐ Processus ‐ Schéma de base de données ‐ Composants logiciels ‐ Réutilisation de composants

Grâce aux outils de modélisation UML, il est également possible de générer automatiquement une partie de code, par exemple en langage Java, à partir des divers documents réalisés.

II ‐ QU’EST CE QUE UML UML (Unified Modeling Langage) est un langage de modélisation graphique. Il est conçu pour représenter, construire et documenter des systèmes logiciels utilisant les techniques orientées objet. Il permet la création de plusieurs modèles d’un même système, chacun privilégiant un aspect différent : fonctionnel, dynamique, statique. Il offre plusieurs niveaux d’abstraction qui simplifient la conception des solutions. Sa notation graphique est très adaptée à la conception orientée objet, et sera beaucoup plus simple à manipuler que l’algorithmique classique. Avec le même avantage que cette dernière, c’est à dire son indépendance par rapport aux langages d’implémentation et aux systèmes d’exploitation. Son côté visuel facilite également la comparaison et l’évaluation de solutions. C’est le résultat d’un large consensus et du travail d’experts reconnus. UML est ainsi devenu un langage incontournable dans tout projet de taille conséquente. Une remarque : UML est un langage de représentation de modèles mais pas une méthodologie pour les élaborer.

III – DIFFERENTS TYPES DE DIAGRAMMES UML propose 13 types de diagramme que l’on peut classer en trois catégories : diagrammes fonctionnels, dynamiques et statiques.

① Diagrammes fonctionnels (ou comportementaux). 1. Diagramme de cas d’utilisation : permet d'identifier les possibilités d'interaction entre le

système et les acteurs (intervenants extérieurs au système), c'est‐à‐dire toutes les fonctionnalités que doit fournir le système.

2. Diagramme d’activités : permet de décrire sous forme de flux ou d'enchaînement d'activités le comportement du système ou de ses composants.

3. Diagramme d’états‐transitions : permet de décrire sous forme de machine à états finis le comportement du système ou de ses composants.

② Diagrammes dynamiques.

1. Diagramme de séquence : c’est une représentation séquentielle du déroulement des traitements et des interactions entre les éléments du système et/ou de ses acteurs.

2. Diagramme de communication : depuis UML 2.x, représentation simplifiée d'un diagramme de séquence se concentrant sur les échanges de messages entre les objets.


3. Diagramme global d’interaction : depuis UML 2.x, permet de décrire les enchaînements possibles entre les scénarios préalablement identifiés sous forme de diagrammes de séquences (variante du diagramme d'activité).

4. Diagramme de temps : depuis UML 2.3, permet de décrire les variations d'une donnée au cours du temps.

③ Diagrammes statiques.

1. Diagramme de classes : il représente les classes intervenant dans le système. 2. Diagramme d’objets : il sert à représenter les instances de classes (objets) utilisées dans le

système. 3. Diagramme de paquets : un paquetage étant un conteneur logique permettant de regrouper

et d'organiser les éléments dans le modèle UML, le diagramme de paquetage sert à représenter les dépendances entre paquetages, c’est‐à‐dire les dépendances entre ensembles de définitions.

4. Diagramme de composants : il permet de montrer les composants du système d'un point de vue physique, tels qu'ils sont mis en œuvre (fichiers, bibliothèques, bases de données…)

5. Diagramme de déploiement : il sert à représenter les éléments matériels (ordinateurs, périphériques, réseaux, systèmes de stockage…) et la manière dont les composants du système sont répartis sur ces éléments matériels et interagissent entre eux.

6. Diagramme de structure composite : depuis UML 2.x, permet de décrire sous forme de boîte blanche les relations entre composants d'une classe.

Diagramme des diagrammes UML


IV – ELEMENTS DE MODELISATION On va présenter maintenant quelques symboles et notions que l’on retrouvera dans la plupart des diagrammes UML.

• Classe :

• Instance d’une classe (objet) :

• Acteur :

• Commentaire :

• Relation d’héritage :

• Relation de dépendance :

• Relation d’association :

• Relation d’agrégation :

• Relation de composition :

• Cas d’utilisation :

• Paquetage :

Multiplicité : quelque soit la relation entre éléments d’un système, on peut préciser le nombre d’intervenants à l’aide d’un indicateur de multiplicité :

– n : exactement n éléments. – n…* : au moins n éléments. – n...m : entre n et m éléments. – * : un nombre quelconque d’éléments.


CHAPITRE II : DIAGRAMME DE CAS D’UTILISATION

I ‐ BUT DE CE DIAGRAMME. C’est souvent le premier diagramme construit lors du développement d’un projet. Son but est de recenser les grandes fonctionnalités d’un système. Il va clarifier, filtrer et structurer les besoins des utilisateurs, et donc les objectifs à atteindre par le système. Ce diagramme insiste uniquement sur ce que fait le système et non sur comment il va le faire. Les solutions d’implémentation font l’objet d’autres diagrammes, comme par exemple les diagrammes de classes. Cette démarche simplificatrice permet une meilleure compréhension du système à développer, et permet de vérifier tout au long de la conception que les besoins des utilisateurs sont satisfaits.

II ‐ ACTEURS ET CAS D’UTILISATION. Acteur : entité externe au système qui interagit directement avec lui. L’acteur peut être humain, matériel, conceptuel... Représentation :

Cas d’utilisation : service rendu par le système en réponse à une sollicitation d’un acteur (l’accomplissement de ce service est réalisé par une suite d’actions non modélisée à ce niveau). Représentation :

Lien d’association : marque la participation d’un acteur à un cas d’utilisation. Représentation :

Délimitation du système :

Tous les acteurs n’utilisent pas forcément le système.


• Acteur principal : celui pour qui le cas d’utilisation produit un résultat observable et qui a le pouvoir de le déclencher.

• Acteur secondaire : autre participant du cas d’utilisation sollicité dans le cadre de sa réalisation. • Représentation des acteurs principaux et secondaires

Exemple

III ‐ RELATIONS ENTRE CAS. Afin de clarifier les diagrammes, de limiter le nombre de liens et de gagner en lisibilité, UML permet d’établir des relations de trois types entre les cas d’utilisation :

• Relation d’inclusion. • Relation d’extension. • Relation de généralisation / spécialisation.

Relation d’inclusion : un cas A est inclus dans un cas B si la sollicitation de A entraine nécessairement celle de B comme une partie de A. Représentation :

Exemple


Relation d’extension : un cas B étend un cas A si la sollicitation de A peut éventuellement provoquer celle de B en complément de A. Représentation :

La relation d’extension est souvent soumise à condition. Cette condition est représentée graphiquement sous forme de note :

Exemple

Relation de généralisation / spécialisation (ou héritage) : indique qu’un cas B est un cas particulier d’un cas A, ou autrement dit qu’un cas A est une généralisation d’un cas B. Un acteur en relation avec A le sera aussi avec B. Représentation :

Exemple


Relation de généralisation / spécialisation (ou héritage) : indique qu’un acteur B est un cas particulier d’un acteur A. Tous les cas d’utilisation accessibles à A le seront aussi à B. Représentation :

Exemple

Exemple récapitulatif.


UN PEU DE METHODOLOGIE I ‐ Déterminer les acteurs.

• Pour bien recenser les acteurs, il faut se demander parmi tout ce qui est extérieur au système, quels

sont les éléments qui interagissent avec lui. • Pour les désigner, il faut penser à leurs rôles vis à vis du système et ne pas réfléchir en termes

d’individus. Un seul acteur représente par exemple les clients du guichet automatique étudié dans la partie précédente.

Acteurs possibles

• Principaux acteurs : utilisateurs du système. En général faciles à identifier. • Autres acteurs humains éventuels : personnes responsables de l’exploitation et de la maintenance du

système (administrateur, technicien...). • Acteurs « matériels » : périphériques, logiciels, autre système.

II ‐ Déterminer les cas d’utilisation.

• Pour déterminer les cas d’utilisation, il faut se demander comment chaque acteur se sert du

système, dans quels cas il l’utilise et à quelles fonctionnalités il a accès. • Une difficulté est de se placer au bon niveau d’abstraction, en ne réduisant pas par exemple un cas à

une seule action. Il faut essayer de rester au niveau des grandes fonctions du système.

III ‐ Description textuelle.

• Le diagramme de cas d’utilisation décrit les fonctionnalités du système à implanter en se plaçant du point de vue des utilisateurs.

• La simplicité de ce diagramme ne permet pas toujours de mentionner des détails intéressants concernant le rôle précis des acteurs, les messages échangés ou les conditions particulières de fonctionnement.

De telles informations peuvent être décrites dans d’autres diagrammes mais il peut être intéressant (plus souple) d’associer une description textuelle au cas d’utilisation. Une description textuelle comporte en général trois parties :

1. Identification du cas – Le nom du cas. – Un résumé de son objectif. – Les acteurs principaux et secondaires. – Les dates de création, de mise à jour et un numéro de version.

2. Description du fonctionnement du cas • Scénario nominal (celui qui se déroule « si tout va bien ») :

– Pré‐conditions (état du système avant le cas). – Enchaînement des actions. – Post‐conditions (état du système à l’issue du cas).

• Scénarii alternatifs (embranchement dans un scénario nominal). • Scénarii d’erreurs (interruption du scénario nominal).

3. Spécifications non fonctionnelles (partie optionnelle)

– Contraintes techniques. – Informations diverses : intégrité, volumétrie, fiabilité, disponibilité, fréquence...


Exemple : on reprend le cas du guichet automatique de banque. 1. Identification du cas

– Nom du cas : retirer de l’argent. – Résumé : procédure de retrait d’argent à un guichet automatique. – Acteurs : porteur de CB (principal), système d’autorisation (secondaire).

Mis à jour le 31/07/2012.

2. Description du fonctionnement du cas Scénario nominal :

• Pré‐conditions : – la caisse du guichet est alimentée. – L’appareil est en état de marche.

• Enchainement des actions : – Le porteur introduit sa carte. – Le porteur tape son code. – Le guichet automatique vérifie le code. – Le guichet demande au porteur le montant qu’il veut retirer. – Le système d’autorisation vérifie que le compte est assez approvisionné. – Le guichet rend la carte au porteur et délivre les billets. – Le porteur prend ses billets. – Scénarii alternatifs : – Le porteur s’est trompé dans son code pour la première ou deuxième fois, le guichet lui

redemande. – Le compte n’est pas assez approvisionné, le guichet demande au porteur un autre montant.

• scénarii d’erreurs : – Le porteur s’est trompé trois fois de code, le guichet conserve sa carte. Le cas se termine. – Le découvert du compte est trop important, le guichet refuse tout retrait. Le cas se termine.


CHAPITRE III : DIAGRAMME DE CLASSE

I ‐ REPRESENTATION DES CLASSES.

I‐1‐ But du diagramme de classes.

• Le diagramme de cas d’utilisation montre un système du point de vue des acteurs. • Le diagramme de classes va lui présenter la structure interne du système. • Il donne une vue statique du système, en montrant les classes et leurs relations entre elles. • L’aspect dynamique sera lui apporté par exemple par un diagramme de séquence (voir prochain

module).

I‐2‐ Objets et classes d’objets. Objet : entité identifiable du monde réel pouvant avoir ou pas une existence physique. Exemples : chat, table, courant de pensée… Un objet possède trois composantes :

1. Une identité. 2. Des variables définissant sont état (attributs). 3. Des sous programmes gérant son comportement (méthodes).

Classe : abstraction regroupant des objets ayant les mêmes attributs et les mêmes méthodes. Un objet est alors une instance de la classe correspondante, et se distingue des autres instances par son identité et la valeur de ses attributs. Représentation d’une classe :

Exemple d’une classe et d’une de ses instances

I‐3‐ Visibilité des membres. Visibilité des attributs et méthodes :

• Un attribut ou une méthode sont dits privés si leur utilisation est interdite en dehors de la classe. • Un attribut ou une méthode sont dits publics si leur utilisation est autorisée en dehors de la classe. • Un attribut ou une méthode sont dits protégés si leur utilisation est limitée à la classe et ses

descendantes. Représentation de la visibilité :

– Public : + – Privé : ‐ – Protégé : #


Exemple :

I‐4‐ Attributs. Possibilité d’initialisation des attributs Lors de la déclaration d’un attribut on peut lui attribuer une valeur par défaut. Exemple :

Attributs de classes : ce sont des attributs particuliers qui ont la même valeur pour toutes les instances de la classe. L’exemple fondamental est un attribut qui compte le nombre d’objets instanciés de la classe. Représentation : ils sont soulignés. Exemple :

Attributs dérivés : attributs dont la valeur peut être calculée à partir d’autres attributs et de formules de calcul. Représentation : avec un « / » devant le nom. Exemple :

Multiplicité : il est possible d’indiquer la multiplicité d’un attribut, c’est à dire le nombre de valeurs que la variable peut stocker. Représentation : entre [ ]. Exemple :

I‐5‐ Méthodes.


Dans la signature des méthodes on peut de façon optionnelle :

• Donner des valeurs par défaut aux paramètres. • Spécifier la nature des paramètres (entrée, sortie, entrée/sortie).

Exemple

Méthodes de classes : ce sont des méthodes qui ne dépendent pas des attributs propres de chaque objet mais qui portent sur les attributs de classes. Représentation : elles sont soulignées. Exemple :

I‐6‐ Classes abstraites. Classe abstraite : classe qui ne peut être instanciée, car elle contient des méthodes abstraites, c’est à dire des méthodes non implémentées. Une classe abstraite sert essentiellement à factoriser des méthodes et attributs communs à plusieurs classes, et ce dans une relation d’héritage. Représentation : le nom de la classe est en italique, et on fait précéder les méthodes abstraites par le stéréotype « abstract ». Exemple :

Interface : il s’agit d’une classe totalement abstraite, c’est à dire d’une classe sans attributs qui ne contient que des méthodes abstraites. Son rôle est de regrouper un ensemble cohérent d’opérations. On utilise des interfaces pour classer les opérations en catégories sans se soucier de leurs implémentations. Représentations d’une interface

II ‐ RELATIONS ENTRE CLASSES.


Après avoir établi quelles classes participaient au système, il convient d’étudier leurs relations. Ces relations expriment des liens structurels ou sémantiques. Dans cette partie nous utiliserons souvent une représentation non documentée des classes (c’est à dire sans préciser les attributs et les méthodes) afin d’alléger les diagrammes.

II‐1‐ Association. Association : relation sémantique durable entre deux classes. Exemple : une personne peut travailler pour une entreprise. La relation « travaille pour » est une association entre les classes « personne » et « entreprise ». Représentation :

• « nom » est souvent un verbe complété par un sens de lecture. • « rôle » indique les fonctions de chaque classe dans l’association. • Les multiplicités précisent les nombres d’objets de chaque classe qui interviennent dans

l’association. Exemple :

Une association entre deux classes peut être multiple :

Une association peut être réflexive :


Association à navigabilité restreinte : par défaut une association est navigable dans les deux sens. Mais on peut aussi indiquer que les instances d’une classe ne connaissent pas les instances d’une autre.

Association avec contraintes : permet de mieux préciser le sens et la portée de l’association.

Contrainte entre associations : permet par exemple de faire un choix entre deux associations possibles.

Association dérivée : association redondante que l’on peut déduire d’autres associations. Elle permet de faciliter la compréhension de la navigabilité entre classes.

Classe d’association

• Certaines associations nécessitent de stocker des informations complémentaires qui, d’un point de vue conceptuel, ne peuvent faire partie d’aucune des classes de la relation.

• On crée alors une nouvelle classe dite classe d’association, destinée à contenir ces informations. Exemple :


Qualification d’une association : renseigne sur l’implication effective des classes dans la relation. Deux types de précisions apportés par une qualification :

• Sur la multiplicité d’une des extrémités de l’association. • Sur la portée de l’association par rapport aux classes en relation.

Exemple 1 : changement de la multiplicité

Exemple 2 : restriction de la portée d’une association

Association n‐aire : association qui relie plus de deux classes. Représentation :

Attention : gestion délicate, notamment de la multiplicité. Exemple

II‐2‐ Agrégation. Agrégation : forme particulière d’association, non symétrique, qui exprime une relation d’inclusion structurelle ou comportementale d’un élément dans un ensemble. Représentation :


Propriétés de l’agrégation : • Les cycles de vie de l’agrégat et de ses éléments agrégés sont indépendants : ils peuvent exister l’un

sans l’autre. Un élément peut appartenir à plusieurs agrégats. Exemples d’agrégation :

II‐3‐ Composition. Composition : forme particulière d’agrégation qui exprime l’appartenance exclusive d’une instance à une autre. Représentation :

Propriétés de la composition :

• Les cycles de vie du composite et de ses composants sont liés : la création ou la destruction d’un composite implique celle de ses composants.

• Un élément ne peut appartenir qu’à un seul composite. Exemples de composition :

II‐4‐ Dépendance. Dépendance : relation unidirectionnelle indiquant qu’une classe est modifiée si l’élément dont elle dépend est lui même modifié. Représentation :

Exemple :


II‐5‐ Héritage. Héritage : relation de spécialisation/généralisation entre deux classes. Elle indique qu’une classe dite classe fille spécialise une autre classe dite classe mère, i.e. qu’elle possède les attributs et les méthodes de la classe mère plus d’autres qui lui sont propres. Représentation :

Les deux visions de l’héritage :

• Spécialisation : on étend les propriétés d’une classe à des sous‐classes plus spécifiques. Cela permet donc la réutilisation de modèles déjà existants.

• Généralisation : on factorise les propriétés communes d’un ensemble de classes dans une super‐classe plus abstraite. Cela permet de gagner en généricité.

Propriétés de l’héritage :

• Une classe fille possède les attributs et méthodes de sa classe mère mais n’a accès à ceux‐ci que s’ils sont déclarés « public » ou « protégé ».

• Une classe fille peut redéfinir (avec la même signature) des méthodes de la classe mère. C’est le mécanisme de polymorphisme.

• Les associations de la classe mère s’appliquent par défaut aux classes filles.

II‐6‐ Interfaces. Une interface est donc une classe sans attributs et ne contenant que des méthodes abstraites. Ses méthodes seront alors implémentées par au moins une autre classe. On dit alors que cette dernière réalise l’interface. Représentation :

D’autres classes utiliseront l’interface pour réaliser leurs opérations. On les dit classes clientes de l’interface. C’est un lien de dépendance qui unit une classe cliente à une interface, complété par le stéréotype « uses ». Représentation :


But d’une interface L’interface est utilisée pour diminuer le couplage entre les classes car une classe « cliente » qui utilise les services spécifiés dans une interface n’a pas besoin de connaître quelle classe « serveur » implante réellement ce service ni de quelle manière ces services sont implantés. Exemple :

III ‐ METHODOLOGIE.

III‐1‐Plan d’élaboration. • Identifier les classes. Cela peut se faire à partir d’une liste de classes « candidates » fournies par un

expert du domaine. On éliminera les classes redondantes et les classes superflues (celles qui ne sont pas en rapport direct avec le problème).

• établir les associations entre les classes. • Identifier les attributs des classes. • Organiser et simplifier le modèle, en particulier en utilisant la relation d’héritage. • Recommencer toute cette procédure du début à la fin autant de fois que nécessaire. Au fil des

itérations, le modèle s’affinera. • Utiliser un diagramme d’objets pour donner un exemple, ou pour préciser un aspect délicat du

diagramme de classes.

III‐2‐Diagramme d’objets Un diagramme d’objets représente des instances de classes et leurs relations. Il sert entre autres à illustrer le diagramme de classes en montrant un exemple explicatif du modèle. Il va permettre également de clarifier certaines relations entre classes, en particulier les associations réflexives et multiples. Exemple : reconsidérons cette relation réflexive.


Exemple (suite) : le diagramme d’objets correspondant.

Exemple (suite et fin) : liens entre la classe et ses instances.


CHAPITRE IV : DIAGRAMME DE SEQUENCE

• Présenter le diagramme de séquence qui va donner une vue dynamique d’un système. • Voir comment des objets peuvent communiquer en s’envoyant des messages. • Modéliser des scénarii complexes à l’aide de boucles, d’alternatives, et d’opérateurs de contrôles du

séquencement.

I ‐ ENVOIS DE MESSAGES.

I‐1‐ But du diagramme de séquence.

• Il donne une description dynamique du système. • Il va permettre d’établir un lien entre le diagramme de cas d’utilisation (vue fonctionnelle et externe

d’un système) et le diagramme de classes (vue statique et interne). • Il va montrer de façon séquentielle (c’est à dire temporelle) comment communiquent les objets du

système afin de réaliser une certaine fonctionnalité. • Le cœur d’un diagramme de séquence est la description des échanges de messages entre éléments

du système ou acteurs extérieurs. • Les messages les plus courants sont :

• L’envoi d’un signal. • L’appel d’une méthode d’un objet. • La création ou la destruction d’un objet.

I‐2‐ Représentation globale.

Représentation globale

En général on ne pourra pas représenter toute la dynamique d’un système sur un seul diagramme. On créera donc un ensemble de diagrammes, chacun représentant un cas d’utilisation ou une fonction interne du système. Modularité : on pourra réutiliser un diagramme déjà existant en y faisant référence.


I‐3‐ Lignes de vie et périodes d’activité. Ligne de vie : représente un participant à une interaction. C’est par exemple un des objets du système ou un acteur extérieur. Remarque : dans le cas d’un objet, selon le niveau de précision souhaité, on pourra le désigner par son nom, la classe à laquelle il appartient ou alors les deux. Représentation :

Une ligne de vie signifie qu’un élément existe mais il n’est pas nécessairement actif. Période d’activité : marque le fait qu’un élément soit actif. Cette période commence généralement à la réception d’un message et peut se clôturer par l’envoi d’une réponse. On la représente par un rectangle blanc sur la ligne de vie de l’élément en question. Représentation :

I‐4‐ Messages asynchrones et synchrones. Message asynchrone : message ne bloquant pas l’activité de son expéditeur. Il pourra être traité à tout moment par son destinataire ou même ignoré. Cela correspond par exemple à l’envoi d’un signal. Représentation :

Exemple :


Message synchrone : message bloquant l’activité de son expéditeur. Et ce jusqu’à prise en compte du message par le destinataire. Il s’accompagne souvent d’une réponse du destinataire. Cela correspond par exemple à l’appel d’une méthode d’un objet. Représentation :

Réponse :

Exemple :

Durée de transmission Dans les exemples précédents, on a considéré que les temps de transmission des messages étaient négligeables, d’où des flèches horizontales. Il peut arriver que l’on doive prendre en compte cette durée de transmission, on représentera alors le message avec une flèche oblique. Exemple : communication sur un réseau d’ordinateur via un protocole UDP.

I‐5‐Création et destruction d’instances. Un message peut également commander la création ou la destruction d’un objet. Représentation :


Exemple :

I‐6‐ Messages perdus et trouvés. Message perdu : message dont on connaît l’expéditeur mais pas le destinataire. Modélise par exemple une perte de message sur un réseau. Représentation :

Exemple :

Message trouvé : message dont on connaît le destinataire mais pas l’expéditeur. Modélise par exemple le comportement d’un élément suite à la réception d’un message d’exception. Représentation :

Exemple :

I‐7‐ Syntaxe des messages Selon le niveau de détail souhaité, la syntaxe des messages sera plus ou moins précise. Si le diagramme de séquence sert à documenter un cas d’utilisation, on utilisera une syntaxe proche du langage courant. C’est d’ailleurs ce que l’on a fait dans les exemples précédents. Si le diagramme de séquence est destiné à un usage plus « programmation », on adoptera une syntaxe plus rigoureuse, correspondant aux méthodes des objets se communiquant. Dans ce dernier cas, on pourra transmettre des paramètres et recevoir un résultat (comme lors de l’appel classique d’une fonction).


Ce résultat sera renvoyé par l’objet appelé via un message de réponse. Exemple :

II ‐ FRAGMENTS D’INTERACTION COMBINES.

II‐1‐ Principe. Dans des situations complexes, on décomposera une interaction en fragments, qui vont permettre de modéliser par exemple une alternative, une itération ou encore une exécution de tâches en parallèle. Ces fragments d’interaction pourront faire intervenir tous ou une partie des éléments du système. Les combiner et les imbriquer permettra alors de rendre compte de la complexité d’un système. Représentation :

II‐2‐ Opérateurs d’alternative et d’itération. Opérateur alt : permet de modéliser une alternative entre plusieurs scénarii. Représentation :

Exemple :


Opérateur opt : permet de modéliser un scénario optionnel. Selon la validité d’une condition, une interaction aura lieu ou pas. Représentation :

Exemple :

Opérateur break : permet de modéliser un scénario de rupture. Selon la validité d’une condition, le scénario de l’interaction est abandonné au profit du scénario contenu dans le fragment break. Représentation :

Exemple :


Opérateur loop : permet de modéliser une itération. Le nombre de boucle est compris entre une valeur minimum et une valeur maximum, et peut de plus être soumis à une condition. Représentation :

Exemple :

II‐3‐ Opérateurs d’ordre des messages. Opérateur par : permet de modéliser des interactions ayant lieu en parallèle. Dans chaque opérande les évènements se déroulent dans l’ordre, mais pris globalement ils peuvent s’entrelacer. Représentation :

Exemple :

Opérateur seq : permet de modéliser des interactions ayant lieu en parallèle. Dans chaque opérande les évènements se déroulent dans l’ordre. Des messages destinés à des lignes de vie différentes peuvent être entrelacées. Des messages destinés à une même ligne de vie doivent se produire dans l’ordre des fragments.


Représentation :

Exemple :

Opérateur strict : impose l’ordre de réalisation de ses opérandes, du haut vers le bas. Par contre le séquencement à l’intérieur de chaque opérande est quelconque. Représentation :

Exemple :

Opérateur critical : désigne un fragment qui devra être exécuté de façon atomique. Cela signifie que les messages de ce fragment ne doivent pas être entrelacés avec d’autres. Et ce même si ce fragment est inclus dans un fragment « par ».


Représentation :

Exemple

II‐4‐ Opérateurs d’interprétation des messages. Opérateur ignore : indique une liste de messages non représentés sur le fragment car ils sont insignifiants dans la description que l’on effectue. Ces messages peuvent quand même être envoyés pendant ce fragment, mais ils seront ignorés. Représentation :

Exemple :

Opérateur consider : indique une liste de messages décrits par le fragment. D’autres messages peuvent quand même être envoyés pendant ce fragment, mais ils ne seront pas pris en compte.


Représentation :

Exemple :

Opérateur neg : indique qu’une certaine séquence ne doit pas avoir lieu, car elle est considérée comme invalide. Représentation :

Exemple :

Opérateur assert : indique l’unique séquence valide, et qui doit donc être nécessairement réalisée. Représentation :


Exemple :

Cours Uml Année 1

Documents

Transcript of Cours Uml Année 1