UML - Introduction à la notation

UML — The Unified Modeling Language

Introduction à la notation

Gerson Sunyé Université de Nantes

[email protected]

mailto:[email protected]?subject=

Gerson Sunyé - Université de Nantes

Introduction

• UML - Langage de modélisation unifié

• Standard de l’OMG (Object Management Group)

• Une notation (syntaxe concrète)

• Un méta-modèle (syntaxe abstraite)

• Ce n’est pas une méthode (pas de processus de développement)

�2


Un peu d’histoire La jungle de méthodes des années 90

• OMT (Rumbaugh et al.), OOA/OOD (Booch), OOA (Coad), OOSE (Jacobson), OOA/OODLE (Schlaer & Mellor) , Fusion (HP), Classe-Relation (Desfray).

• et aussi: DFD (De Marco), Etat-transition (Harel), ER (Chen), CRC (Wirf & Brooks), JSD (Jackson)


Un peu d’histoire

• Les années 80-90:

• Différents langage de modélisation

• Différentes interprétations des constructeurs de modélisation

• Peu d’outils, pas adaptés

• Pas d’échange de modèles


Objectifs d’UML

• Proposer un langage visuel de modélisation, indépendant de l’implémentation et du processus de développement

• Proposer une base formel pour l’interprétation des modèles


Objectifs d’UML

• Intégrer des concepts de haut niveau: Composants, Patrons de conception (Patterns), Cadres d’applications (Framewoks)

• Encourager l’outillage


UML et le processus de développement

• Un processus est composé (au minimum) des étapes suivantes: • Expression des besoins • Analyse • Conception • Réalisation, validation, maintenance


Analyse et conception

• UML: une même notation, deux niveaux d’abstraction différents

• Une frontière floue, qui doit être précisée par une méthode de développement


Analyse avec UML

• Généralement:

• Le résultat de l’analyse est un modèle idéal de la solution

• Abstraction des particularités de la plate-forme d’implémentation (persistance, réseau, etc.)


Conception avec UML

• Le résultat de la conception est un modèle de la solution, adapté au monde réel

• Ce modèle reste indépendant du langage d’implémentation


Modélisation avec UML

• Diagrammes de cas d’utilisation

• Diagrammes structurels

• Diagrammes comportementaux

• Mécanismes d’extension

�11

Diagrammes de cas d’utilisation

�12


Modèle des cas d’utilisation

• Buts : • modéliser le point de vue des utilisateurs • définir les limites précises du système

• Notation très simple, compréhensible par tous, y compris le client

• Permet de structurer : • les besoins (cahier des charges) • le reste du développement

• Modéle (principalement) communicationnel

CasU1

CasU4

CasU5

CasU2

CasU3

A1

A2

S A3


Modèle des cas d’utilisation

• Moyens :

• Les acteurs UML

• Les use-cases UML

• Utilisation d’un dictionnaire du domaine


Use Case Diagram Example

DistributeurDeBillets

Client

RetirerDeLArgent AuDistributeur

ConsulterSonCompte

AssurerLaMaintenance TechnicienAjouter

DesBilletsTransporteurDeBillets

RetirerLesCartesAvalées


Modèle de cas d’utilisation

• Diagramme de cas d’utilisation !

• Modèle de cas d’utilisation • descriptions textuelles, • diagrammes de cas

d'utilisation • diagrammes de

séquences • dictionnaire de données • …

CasU1

CasU4

CasU5

CasU2

CasU3

A1

A2

S A3


Eléments de base

Acteurs Cas d'utilisation Système


Cas d’utilisation (CU)

• Cas d’utilisation • une manière d’utiliser le système • une suite d’interactions entre un acteur et le système

• Correspond à une fonction du système visible par l’acteur • Permet à un acteur d’atteindre un but • Doit être utile en soi • Regroupe un ensemble de scénarii correspondant à un même

but

RetirerDeLArgentAu Distributeur

TaperSonCodeEnregistrerEntrée EntrerPendantLesHeuresDOuverture

SIdentifier


Système

• Le système est • modélisé par un ensemble de cas d’utilisation • vu comme une boîte noire !

• Le système contient : • les cas d’utilisation, • mais pas les acteurs. !

• Un modèle de cas d’utilisation permet de définir : • les fonctions essentielles du système, • les limites du système, • le système par rapport à son environnement, • délimiter le cadre du projet !


Acteurs

• Un Acteur = • élément externe • qui interagit avec le système (prend des décisions, des

initiatives. Il est "actif".) • Rôle qu’un "utilisateur" joue par rapport au système

CapteurAIncendie

PorteurDeCarte AdministrateurGardien


Acteurs vs. utilisateurs

Ne pas confondre les notions d’acteur et de personne utilisant le système

!• Une même personne peut jouer plusieurs rôles

ex: Maurice est directeur mais peut jouer le rôle de guichetier !• Plusieurs personnes peuvent jouer un même rôle ex: Paul et Pierre sont deux clients !• Un rôle par rapport au système plutôt qu’une position dans

l'organisation ex: PorteurDeCarte plutôt qu'Enseignant !• Un acteur n’est pas forcément un être humain ex: un distributeur de billet peut être vu comme un acteur


Différents types d’acteurs

Ne pas oublier d'acteurs : !• Utilisateurs principaux

ex: client, guichetier !

• Utilisateurs secondaires ex: contrôleur, directeur, ingénieur système, administrateur... !

• Périphériques externes ex: un capteur, une horloge externe, ... !

• Systèmes externes ex: système bancaires


Notation

•Notations alternatives pour les acteurs PorteurDeCarte

PorteurDeCarte

<<actor>>PorteurDeCarte

PorteurDeCarte

CapteurAIncendie

<<actor>>

SystèmeBancaire

<<actor>>

■ Note de style : utiliser plutôt le stéréotype <<actor>> pour les acteurs non humains


Relations entre les éléments de base

• Relations acteurs ⟷ cas d'utilisation ? !

• Relations acteurs ⟷ acteurs ? !

• Relations cas d'utilisation ⟷ cas d'utilisation ??

? ?


Relation acteur ⟷ cas d'utilisation

• Point de vue besoin: représente la possibilité d'atteindre un but • Point de vue système: représente un canal de communication

• Echange de messages, potentiellement dans les deux sens • Protocole particulier concernant le cas d'utilisation considéré

ClientRetirerDeLArgent

AuDistributeur

ClientRetirerDeLArgent

AuDistributeur



• Description via des diagrammes de séquences "systèmes" !

• Plus tard dans le cours ...

Client

RetirerDeLArgentAuDistributeur



• Acteur "primaire » • utilise le système comme

outil pour réaliser son but • initie généralement la

communication • Acteur(s) "auxiliaire(s)"

• interviennent suite à l'intervention de l'acteur primaire

• offrent généralement leurs services au système

Guichetier

SystèmeBancaire

ConsulterUnCompte

Acteur primaire

Acteur auxiliaire


Relation cas d’utilisation ⟷ cas d’utilisation

• Communications internes non modélisées.

• UML se concentre sur la description du système et de ses interactions avec l'extérieur

• Formalisme bien trop pauvre pour décrire l'intérieur du système. Utiliser les autres modèles UML pour cela.

• Autres relations possibles entre CU (slides suivants) Système

Bancaire

Directeur

Client

RetierDeLArgent

ConsulterLesSoldes


Relation cas d’utilisation ⟷ cas d’utilisation

• Utilisation («include» / « uses ») • Utilisation d’autres use-cases pour en préciser la définition !

• Extension («extend» / « extends ») • Un use-case étendu est une spécialisation du use-case père


Relation acteur ⟷ acteur

• Communications externes non modélisée !

• UML se concentre sur la description du système et de ses interactions avec l'extérieur

Guichetier

Client

RetirerDeLArgentAuDistributeur

ConsulterSonCompte

RetirerDeLArgentParChèque


Relation acteur ⟷ acteur : généralisation

• La seule relation entre acteurs est la relation de généralisation

GuichetierEnChef

Guichetier

CréerUnCompte

RetirerDeLArgentDUnCompte

AnnulerUnCompte

FermerUnCompte

Notation — résumé

«subsystem»Commandes

Consulter

Commander

MàJ catalogue

Traiter Commande

Etablir crédit

Client

0..1

1

1

1

0..1

0..1

Notation — résumé

Retrait Lecture carte«includes»

Transaction sur

distributeur

Aide en ligne«extends»


Exemple de marquage

DistributeurDeBillets

Client RetirerDeLArgentAuDistributeur

ConsulterSonCompte

GérerLaSécuritéAdministrateur

AjouterDesBilletsTransporteur

DeBillets

S’identifier


Cas d'utilisation vs. Scénarii

• Un scénario est un exemple :

• une manière particulière d’utiliser le système …

• … par un acteur particulier … • … dans un contexte particulier. !

• cas d’utilisation = ensemble de scénarios

!

• scénario = une exécution particulière d’un CU


Diagramme de séquences système

• Pour décrire un scénario : un diagramme de séquences • Diagramme de séquences :

• L’une des notations UML, une notation générale • Peut être utilisée dans de nombreux contextes • Permet de décrire une séquence de messages échangés entre différents objets • Différents niveaux de détails !

• Pour décrire un scénario simple, deux objets : l’acteur et le système !!

⇒ « Diagramme de séquences système »


Exemple de diagramme de séquence système

paul : Client le systèmeInsérer carte

Entrer code ‘1234 ’

Demander code

Message d ’erreur

Demander code

Entrer code ‘6622 ’

Vérifier carte

Vérifier code

...

Appeler Sylvia


Cas d'utilisation vs. scénarii

Niveau modèle

Niveau instances


Un peu de méthodologie…

Stabilisation du modèle par consensus

grandissant

!

• Équivalent à définir une table des matières et des résumés pour chaque chapitre • Pas de règles strictes • Effectuer les meilleurs regroupement possibles • Rester simple ! • Structuration possible en termes de paquetages • Culture d'entreprise


Pour en savoir plus

• Pour un template "standard" de description de cas d'utilisation :http://alistair.cockburn.us/Basic+use+case+template !

• Quelques livres :

http://alistair.cockburn.us/Basic+use+case+template



http://www.amazon.com/exec/obidos/tg/stores/detail/-/books/0130925691/reader/2/002-3439525-6842407%2523reader-link

http://www.amazon.com/exec/obidos/tg/stores/detail/-/books/0201702258/reader/2/002-3439525-6842407%2523reader-link


Pour en savoir encore plus

Diagrammes structurels

�42

Gerson Sunyé - Université de NantesGerson Sunyé - Université de Nantes

Diagrammes Structurels

• Classes • Objets • Structures composite

�43


• Classificateurs, attributs et opérations • Associations • Généralisation • Dépendances • Paquetages

Diagramme de classes

�44


Classificateurs


Rappel: objet

• Encapsulation d’un état et d’un ensemble d’opérations (qui s’appliquent à cet état) • Abstraction d’une entité réelle • Identité unique • Existence temporelle (création, modification, destruction)

�46


• Description du comportement et des propriétés communs à un ensemble d’objets • Un objet est une instance d’une classe • Chaque classe a un nom

Rappel: classe

�47


Notation

• Sans détails • Analyse • Conception • Propriétés groupées

selon leur visibilité

�48

HTML Page

HTML Page

title : Stringsize : Integerrender()save()

HTML Page

+ title : String+ /size : Integer~ version : Integer# contents : String- visibility : Boolean = true- tags : String [1..*]+ render()+ save()- optimize()

HTML Page

public title : String /size : Integerpackage version : Integerprotected contents : Stringprivate visibility : Boolean = true tags : String [1..*]public render() save()private optimize()


• Caractéristique structurelle typée d’un classificateur, qui spécifie la structure des instances de ce classificateur

• Peuvent être dérivés d’autres attributs

Attributs

�49


• Propriétés: • {readOnly}, {union}, {subsets <p>}, {redefines

<p>}, {ordered}, {unique}, {id}, {non-unique}, <prop-constraint>.

• Visibilité: [+,~,#,-] • Peuvent être soulignés (attributs de classe)

Attributs

Syntaxe: [visibility][/]name[:type][multiplicity] [=default][{prop-modifier}]

�50


• Caractéristique comportementale d’un classificateur qui spécifie le nom, les types, les paramètres et les contraintes pour invoquer un comportement associé

Opération

�51


• Peut être soulignée (opération de classe) • Propriétés: redefines<operation-name>, query, ordered, unique • direction: in, out, inout

Opération

parameter: [direction]name : type-expression [multiplicity] = default-value [param-properties]

Syntaxe: [visibility]name (parameter-list):return-type {oper-properties}-

�52


• Classes abstraites • Datatypes • Interfaces • Classes paramétrées

Autres classificateurs

�53


Classes abstraites

• Encapsulent un comportement commun

• Ne possèdent pas d’instances

• Possèdent des opérations abstraites

Etudiant

Etudiant{abstract}

�54


• deferred en Eiffel • abstract en Java • pure virtual en C++ • méthodes ^self shouldNotImplement en Smalltalk

Classes abstraites

�55


• Type, dont: • les valeurs n’ont pas

d’identité • les opérations sont de

fonctions “pures”

Datatypes

«dataType»Date

day : Integermonth : Integeryear : Integer

�56


• Enumeration • Types primitifs:

• Boolean, Integer, UnlimitedNatural, String

Datatypes

«enumeration»Temperature

Cold

Hot

�57


• Une déclaration d’un ensemble cohérent d’opérations

• Une interface peut être implémentée ou demandée

Interfaces

HTML Page


«Interface»

Serializable

+ read()+ write

Exporter

write()

HTML Page


Exporter

write()

Serializable

�58


• Indispensable pour les classes conteneurs (e.g. Listes)

• Existe en Ada, Eiffel, C++ (templates) et Java (>1.5)

• N’est pas nécessaire en Smalltalk et Python

Classes paramétrées

Vecteuritem : Ttaille : intajouter()supprimer()

T

Polygone

<<bind>> <Point>

�59


Associations


• Une association entre deux classes représente un lien stable entre deux objets (instances de ces classes)

Rappel: association

�61


• Un lien d’utilisation, temporaire, n’est pas une association

Rappel: association

feature {VISITOR} accept(v: VISITOR) is do v.visitExemple(Current) end -- accept

�62


• Nom • Rôles • Cardinalités • Direction de lecture • Navigabilité

Notation

HTMLFolder

HTMLPage

1 contents

Possède

container*

�63


• Exacte : 1 • Plusieurs (0 à n): * • Optionnelle: 0,1 • Spécifiée: 1, 2, 4 • Intervalle: 1-10

Cardinalités - Notation

�64


• {set} : chaque élément est présent au plus une fois (par défaut) • {bag} : un élément peut être présent plus d’une fois • {ordered}: set ordonné • {sequence} or {seq}: bag ordonné

Propriétés des rôles

�65


• {redefines <end-name>} : redéfinition d’un autre rôle • {subsets <property-name} : le rôle représente un sous-ensemble • {union} : union dérivée de tous ses sous-ensembles

Propriétés des rôles

�66


• Association réflexive • Association n-aire • Association qualifiée • Association-classe • Agrégation partagée • Agrégation composite

Cas particuliers (1/2)

�67


Association réflexive

• Liaison entre objets de la même classePersonne

enfant

parent

0..2

*

�68


Association n-aire

• Association entre plus de deux classes

• Interprétation confuse des cardinalités

Enseignant Matière

Classe

*enseignement

1..*

1..*

�69


Association qualifiée

• Qualificatif: attribut spécial, qui permet de réduite la cardinalité (de n à 1)

• Une clef permettant de distinguer un objet de façon unique

Banque compte Personne* 0..1

�70


Association-classe

• Aussi appelée classe de liaison

Etudiant Matière

Notevaleur : intop()op()

�71


Agrégation

• Notion de “tout” et “partie”

• Partagée et compositeVoiture Roue

Chassis

4,6

1

�72


Généralisation


• Héritage, caractéristique des langages à objets • Partage de structure et comportement entre classes

Généralisation

�74


• Mécanisme d’extension de module • ajout de fonctionnalités dans la sous-classe • réutilisation de code

Utilisation (1/2)

�75


• Mécanisme de classification : sous-typage • relation X est-une-sorte-de Y (est substituable à) • organisation des systèmes complexes (cf. Linnaeus) • réutilisation d’interface

Utilisation (2/2)

�76


• Relation “est une sorte de”, “est remplaçable par”

Notation

Etudiant{abstract}

Etudiant de Maîtrise

Etudiant de DESS

Etudiant


Etudiant de DESS

�77


• complete/incomplete: couverture. Une personne est soit un homme, soit une femme.

• disjoint/overlapping: si les classificateurs partagent des instances. Une personne peut être aussi un étudiant.

Generalization Set

Personne

Etudiant Homme Femme

{complete, disjoint}{incomplete, disjoint}

�78


• Attributs • Opérations • Associations • Contrats, états, etc. (mais cela, nous verrons plus tard)

Généralisation

�79


• Un attribut qui a le même nom qu’un attribut hérité est une redéfinition

Attributs

Personnenom : Stringsecu : Integernaissance : Date

Personneid {redefines nom}naissance : Integer

�80


• Une opération peu être redéfinie si: • elle a le même nombre

de paramètres • Le type de chaque

paramètre est conforme au paramètre correspondant

Opérations

Départementvirer (e : Etudiant)

Département d'infovirer (e : EtudiantInfo)

�81


• Les associations sont héritées par les sous-classes

Associations

Etudiant


Etudiant de DESS

Départementappartient

�82


• Il est possible de spécialiser une association • Double emploi avec <redefined> ?

Associations

Etudiant Département

Etudiant en informatique

Département d'info

appartient

appartient{redefined appartient}

�83


• Relation entre deux éléments (client et fournisseur) • Abstraction • Permission • Réalisation • Substitution

Dépendances

�84


• Entre éléments de différents niveaux sémantiques • «derive» : éléments dérivés, pas forcément du même type • «refine» : raffinement entre modèles • «trace» : (aussi) - utilisé pour marquer les changements entre

modèles.

Abstraction (1/2)

�85


• Relation entre un «type» du modèle d’analyse avec une classe du modèle de conception

Abstraction (2/2)

«type»Personne

Personne Impl

«refine»

�86


• Outillage de méthodes de développement (RUP, Catalysis, etc.)

Intérêt de l’abstraction

�87


• Droits d’accès aux propriétés privées

Permission

Etudiant+ nom- cartable

Professeur«permit»

�88


• Relation entre deux ensembles d’éléments, de spécification et d’implémentation

• Utilisé pour représenter: raffinement, optimisation, transformations, synthèses, etc.

• «realize»

Réalisation

�89


• Relation entre classificateurs. Les instances du fournisseur peuvent remplacer celles du client

Substitution

Etudiant+ nom- cartable

Espion«substitute»

�90


• «call» : dépendance entre opérations (où classes) • «create» : le client créé des instances du fournisseur

(classificateurs) • «instantiate» : les opérateurs du client créent des instances du

fournisseur

Usage

�91


• «send» : entre une opération et un signal

Usage (2/2)

�92


• Représentation des associations non permanentes • Très utiles pour estimer la testabilité d’un modèle ou l’impact

d’un changement

Intérêt de l’usage

�93


• Principal mécanisme d’extension d’UML • Permet l’extension (ou plutôt la restriction) de la plupart des

éléments de modélisation: classe, objet, opération, acteur, cas d’utilisation, diagrammes, etc.

Stéréotypes

�94


• Peuvent introduire: • une nouvelle notation • des contraintes

d’utilisation • Très utiles pour

l’interprétation d’un modèle

Notation

«persistent»Personne

nom : Stringsecu : Integernaissance : Date

Personne


«persistent»Personne


Personne

�95


• Pair de la forme “étiquette=valeur”, attachée aux éléments de modélisation

Etiquettes (tagged values)

Personne{author = G. Sunyé,status = incomplete}


�96


• Compléments de modélisation sous forme textuelle, attachées à un élément ou un diagramme

• Peuvent être stéréotypées

Notes

Départementvirer (e : Etudiant)

Département d'infovirer (e : EtudiantInfo)

Le département d'informatique ne peut virer que les étudiants

d'informatique

�97


• Mécanisme d’extension, permettant d’adapter UML à l’aide d’un ensemble de stéréotypes

• Le profil “Standard” contient les stéréotypes utilisés dans UML • Autres profils: J2EE/EJB, COM, .NET, CCM, etc.

Profils

�98


• Groupement d’éléments, qui leur fournit un espace de nommage commun

Paquetage (1/3)

�99


• Utilisé pour structurer une application • Il se compose de classes et d’autres paquetages • Il référence des classes ou d’autres paquetages

Paquetage (2/3)

�100


• Utilisé pour réglementer la visibilité des classes et paquetages qui le composent

Paquetage (3/3)

�101


• Vues externe et interne

Notation

Types

«datatype»Date

Types

�102


• Importation («import»): les éléments de l’espace de nommage sont importés

• Accès («access»): les éléments sont simplement utilisés

Dépendances entre paquetages

Types

Persistence Gestion

«import»

«access»

�103


• Une fusion définie la manière dont un paquetage étend un autre • Composé de liens de généralisation et de redéfinition

Fusion de paquetages

�104


• Vue externe

Notation

Types

Enumerations My Types

«merge»

«merge»

�105


• Vue interne

Notation

«datatype»Types::Date

My Types

«datatype»Date

�106




�107


• Représentation d’objets, de liens et de valeurs. • Très utiles pour expliquer les associations entre classes ou le

résultat d’une opération

Diagramme d’instances

�108


• Similaire à celle d’une classe • Le nom de l’instance et celui de la classe sont soulignés

et séparés par “:” • Les deux noms sont facultatifs

Notation

Arnaud : Etudiant

adresse = "13 r du pont"age : Integer = 38

: Département

nom = "Informatique"

appartient

�109

UML — Composants

Gerson Sunyé[email protected]

�110

mailto:[email protected]


• Composant

• Connecteur

• Artefact

• Port

Élements du diagramme de composants

�111


• Composants:

• Partie remplaçable d’un système.

• Son comportement est spécifié en terme d’interfaces requises et fournies.

Définition

�112


• Interfaces requises et fournies.

Notation

«component»Dictionnaire

Synonymes

AntonymesTexte structuré


«provided interfaces» Synonymes Antonymes«required interfaces» Texte structuré

�113


• Point d’interaction entre un composant et son environnement.

• La nature de ces interactions est spécifiée par des interfaces.

Port

«component»DictionnaireSynonymes

Antonymes

�114


• Liaison entre un contrat externe (port) et la réalisation.

• Assemblage, délégation.

Connecteur

:Index

:Langue

Dictionnaire

Texte structuréAntonymes

«component»:Texte

Texte structuré «component»:Dictionnaire

Texte structuré �115



• Classes • Objets • Composants • Déploiement • Structures composite

�116

UML — Composants


• Composant

• Connecteur

• Artefact

• Port

Élements du diagramme de composants

�118


• Composants:

• Partie remplaçable d’un système.

• Son comportement est spécifié en terme d’interfaces requises et fournies.

Définition

�119


• Interfaces requises et fournies.

Notation


Synonymes

AntonymesTexte structuré


«provided interfaces» Synonymes Antonymes«required interfaces» Texte structuré

�120


• Point d’interaction entre un composant et son environnement.

• La nature de ces interactions est spécifiée par des interfaces.

Port

«component»DictionnaireSynonymes

Antonymes

�121


• Liaison entre un contrat externe (port) et la réalisation.

• Assemblage, délégation.

Connecteur

:Index

:Langue

Dictionnaire

Texte structuréAntonymes

«component»:Texte

Texte structuré «component»:Dictionnaire

Texte structuré �122



• Classes • Objets • Composants • Déploiement • Structures composite

�123

UML — Déploiement


• Éléments de modélisation:

• Artefact

• Chemin de communication

• Déploiement

• Dispositif

• Noeud

Diagramme de déploiement

�125


• Spécification d’une pièce physique d’information utilisée dans le processus de développement

• Fichiers source, modèles, scripts, binaires, document, etc.

Artefact

�126


• Un artefact est un classificateur: il possèdes des propriétés et des opérations

• Il peut s’associer avec d’autres artefacts

Artefact

�127


• Stéréotypes standards: «source», «executable»

Notation

«artifact»

Order.jar

«artifact»

Order.jar

�128


• Ressource logique sur laquelle les artefacts sont déployés.

Noeud

�129


• Connexion, instances

Notation

Zope ZODB1 1..4

CMF

«deploy»

:Zope

:Zope

CMF«artifact»«artifact»

Plone

�130


• Association entre deux noeuds, permettant l’échange de signaux et de messages.

Chemin de communication

�131


• Ressource (artefact) déterminant les paramètres d’exécution d’un artefact.

Spécification de déploiement

«artifact»

Order.jar

«deployment spec»

description.xml

�132



Diagrammes structurels

�133


• Structures internes • Collaborations

Structures composite

�134


• Spécification d’éléments créés à l’intérieur d’un classificateur

Structures internes

�135


• Propriétés • Instances • Références

Notation

:Point [3] :Color

Triangle

:Triangle

a:Point

c:Pointb:Point

blue:Color

Trianglemake(c : Color)

«create»

�136


• Spécification de la structure d’un ensemble d’éléments (rôles) qui réalisent une tache commune

• Représentation de la structure d’un patron de conception

Collaborations

�137


• Rôle: rôle d’une classe participant à une collaboration

• Connecteur: lien permettant la communication entre deux classes

Notation (1/3)

/Observer:Dependent /Subject:Model

Observer

�138


• Les propriétés définies par les classificateurs doivent être possédées par les classes jouant leurs rôles

Notation (2/3)

Modelnotify()

addDependent()

Dependentupdate()

Observer

Observer Subject

�139


• Occurrence d’une collaboration

Notation (3/3)

Fenêtre Donnée

:Observer

Observer Subject

�140

Diagrammes comportementaux

�141


Diagrammes de comportement

• Etat-transition • Interaction • Activités

�142

Gerson Sunyé - Université de NantesGerson Sunyé - Université de NantesGerson Sunyé — Université de Nantes

Diagrammes état-transition

• Modélisation d’un comportement par un système fini d’états et de transitions

• Il existe deux sortes de digrammes d’état: • De comportement • De protocole

�143

Diagramme de d’état de comportement

�144


• Décrivent un comportement à l’aide d’un graphe d’États, interconnectés par des Transitions, qui sont déclenchées par des Événements

• En d’autres termes, décrivent les réactions d’un objet aux changements de son environnement.

• Essentiellement, un diagramme de Harel • Attachés à un classificateur (sauf interfaces) ou à une opération

• Sont hérités, et peuvent être spécialisés

Machines à états

�145


• Relation unidirectionnelle entre deux états (ou entre deux machine d’état)

• Interne à un état • Externe: implique un changement d’état • Locale: s’applique à tous les états d’un état composite

Transition

�146


Transition — notation

Evt1 [cond] / m() ^Evt2E1 E2

état transition

événement reçuévénement émisactioncondition de garde

�147


Transition — exemple

Syntaxe : trigger [guard]/ trigger

Open Closequit(user) [user has rights] / parent := user.parent(); parent.update()

�148


• Evénement qui peut causer l’exécution d’un comportement qui lui est associé. Exemples: • Message: Événement ou Opération • Temporel • Changement

Déclencheur (Trigger)

�149


Événement/Signal

• Un événement est un type de message pouvant être échangé entre deux objets.

• Asynchrone (contrairement aux opérations, qui sont synchrones) • Peut transporter des données. • Correspond à un message asynchrone dans les diagrammes de

séquence.

�150


Événement

• Stimuli auxquels réagissent les objets • Occurrence déclenchant une transition d’état

• Abstraction d’une information instantanée échangée entre des objets et des acteurs • Un événement est instantané • Un événement correspond à une communication

unidirectionnelle • Un objet peut réagir à certains événements lorsqu'il est dans

certains états. • Un événement appartient à une classe d'événements (classe

stéréotypée «signal»).

�151


Événement

• Déclaration au sein d’un diagramme de classe au moyen d’une Classe stéréotypée « signal » !

!

!

!

• Utilisation au sein • d’un diagramme de séquence pour représenter les interactions

dynamiques entre objets, • des diagrammes d'états pour représenter les déclencheurs de

transitions.

�152


Notion d’événements

• Les événements sont considérés comme des objets

time : Integer

«signal»IO Event

device : Integer

«signal»User Input

position : Point

«signal»Mouse Click

key : Integer

«signal»Key Pressed

port : Integer

«signal»Network

�153


Types d’événements

• Réalisation d’une condition arbitraire • transcrit par une condition de garde sur la transition

• Réception d’un signal issu d’un autre objet • transcrit en un événement déclenchant sur la transition

• Réception d’un appel d’opération par un objet • transcrit comme un événement déclenchant sur la transition

• Période de temps écoulée • transcrit comme une expression du temps sur la transition

�154


• Contrainte évaluée avant le déclenchement d’une transition

Garde

�155


• Déclenchée par une transition ou interne à un état • Définit un comportement, spécifié dans n’importe quel langage

(!)

Activité

�156


Notion d’action

• Action : opération instantanée (conceptuellement) et atomique (ne peut être interrompue)

• Déclenchée par un événement • Traitement associé à la transition • Ou à l’entrée dans un état ou à la sortie de cet étatUser_input / mise_sous_tension

délai_mise_en_veille / passage_en_mode_veille

Veille Allumé

action

action�157


Notion d’activité interne à un état

• Activité : opération se déroulant continuellement tant que l’on est dans l’état associé • do/ action

• Une activité peut être interrompue par un événement.

TéléphoneN° invalide Téléphone raccroché Invalide

do / passer message

activité�158


• Situation stable d’un objet: • en attente d’un événement, ou • en train de réaliser une tâche

• Conditionne la réponse de l’objet à des événements • programmation réactive / « temps réel »

• Peut avoir des variables internes • Attributs de la classe attachée à ce diagramme d’états

• Trois sortes: simple, composite et sous-machine

Etat

�159


• Compartiments: • Nom • Activités internes • Transitions internes

Notation

ICQ-Connectedentry/say_hello()exit/bye_bye()do/poll()keyboard/read_msg()

�160


• Etat englobant différents sous-états • Possède une entrée et une sortie • Transition arrivant -> entrée • Transition sortant -> sort de tous les états

Etat composite

�161


Notation

Offline Available N/A Freedeconnect()

Online

set_available()

not_available() free_for_chat()

�162


Notation

• Etat composite avec indicateur de décomposition

Online

do/poll()

�163


• Régions concurrentes, représentant 2 (ou n) aspects indépendants d’un objet.

• Activités parallèles • Evitent l’expression d’un

produit cartésien

Composite Orthogonal

Online

InvisibleVisible

Available

�164


Diagrammes d'états concurrents : exemple

Préparation d'un avion

Remplissage PleinMaintenance

Réservoir pleinpréparation Avion

prêt

Chargement nourriture Nourriture

chargée

Approvisionnement

Compartiment plein

Equipage absent Vérification

avion

Equipage

Montée

vérification OK

�165


Sous-machine

• Référence à une machine d’états

�166


• Référence à une machine d’états • Points de connexion:

• Entrée • Sortie

Notation

Connexion:ConnexionMachine

timeout

�167


• Initial, Final • Entrée, sortie • Fourchette, jonction

(régions orthogonales) • Choix

Pseudo-états

id

[>10]

[<=10]

�168


• Envoi et réception d’événements

• Séquence d’actions • Pour une vue “orientée

transition”

Transitions particulières

Abort

Timeout

Connected

reason = timeout

Offline

�169


• Ajout de nouvelles transitions ou de nouveaux états

• Spécialisation d’états (transformation d’un état simple en composite)

• Un état peut être {final}

Spécialisation

Online Offline

Connection {extended}

new transition

�170

Diagramme d’état de protocole

�171


Machines d’état de protocole

• Spécialisation des machines d’états • Toujours attachées à un classificateur • Représentent un cycle de vie d’un objet et spécifient quels

messages sont acceptés à chaque état

�172


• Similaire aux machines d’états

• Notée {protocol}

Notation

Porte {protocol}

Ouverte Fermée[couloir->libre] Fermer/

�173


• Spécifient une pré et une post condition

Transitions

[pré-condition] événement / [post-condition]

�174


• Spécifient un invariant

Etats

[invariant]Etat

�175

Résumé

�176


Exemple de diagramme d'états

Actif

En composition

connecté

décroche combiné

Repos

Appelé raccroche

Dialogue Sonnerie do/ sonneRéponse de l’appelé/

autorise parole

Compose numéro (n)

Appelant raccroche/ déconnexion

Tonalité do/ joue tonalité

Occupé do/ tonalité occupée

occupé

15 sec

Invalide do/ dit message

Compose numéro (n) [n.isInvalid]

Timeout do/ timeout tone 15 sec

Compose numéro (n)

Etablissement

OccupéLibre

Dernier numéro

�177


Émission d’événements

• Automate d’états d’une télécommande double (TV + MAGNETOSCOPE) :

Contrôle distantMAGNETOSCOPE

TVcontrôle

TVcontrôle

MAGNETO

bouton marche ^signal ON/OFF

Télévision

Arrêt Marche

signal ON/OFF

�178


Etat-transition (résumé)

• Format : • événement (arguments) [conditions] / action ^événements provoqués

• Déclenchement : • par un événement (peut être nul).

• Peut avoir des arguments. • Conditionné par des expressions booléennes sur l'objet courant,

l'événement, ou d'autre objets.

• Tir de la transition : • Exécute certaines actions instantanément. • Provoque d'autres événements ; globaux ou vers des objets cibles.

�179



• Interaction • Activités

�180


• Définissent le comportement d’un Classificateur • Le comportement est défini par deux ensembles de traces:

• Valides • Invalides

Interactions

�181


Interactions

• Décrivent l’échange de messages entre objets. Diagrammes: • Séquence • Communication • Aperçu d’interaction

�182


Interaction

• Diagramme de Séquences

�183


• Exemples de coopération entre objets • Illustrent la dynamique d’enchaînement d’un traitement à travers

les messages échangés entre objets • Représentation du temps comme une dimension explicite

(verticale)

Diagramme de séquences (scénario)

�184


• Constitution: • Un message initiateur • Un ensemble d’objets et de messages • Des cadres (frames) • Des contraintes de temps

Diagramme de séquences

�185


Notation

sd Exemple

obj : C1 obj2 : C2

obj3 : C1

Message Asynchrone

Message synchrone

creation()

new = obj3

message(obj, obj2)

debut

�186


Messages

• Communication (synchrone ou asynchrone) entre deux lignes de vie. Sortes de message: • Complet (événements d’envoi et de réception connus) • Trouvé (événement d’envoi inconnu) • Perdu (événement de réception inconnu) • Inconnu

�187


• Asynchrone • Synchrone • Création • Perdu • Trouvé

Messages - Notation

Message Asynchrone

Message synchrone

obj3 : C1creation()

retour

�188


Messages - Syntaxe

message ::= [attribut =] signal-ou-operation [(arguments)][: valeur-retour] | ‘*’arguments ::= argument [, arguments]

argument ::= [paramètre=]valeur-argument | attribut = paramètre-sortie [valeur-argument] |

message(14, -, 3.14, “hello”)v=message(16, variable):96message(id=16)

Exemples:

�189


• Ligne de vie: • Représente l’existence d’un objet à un

moment particulier • Entre la création et la destruction

• Activation: • Période d’exécution d’une activité (lui-

même, délégation)

Ligne de vie, Activation

obj : C1

�190


• Observation de durée, contraintes

• Observation de temps (instants), contraintes

Contraintes temporelles

:User :ACSystem

Code d = duration

CardOut {0..13}

{d..3*d}

{t..t+3}

t = now

�191


• Région définissant une sémantique précise à l’intérieur d’une interaction

• Raccourcis pour l’écriture de traces

• Composé de [1..*] “Opérandes”

Fragments

sd Region Critique

obj : C1 obj2 : C2

msg()

msg()

critical

�192


• Alternatives (alt): choix de comportement, entre deux opérandes

Fragments

sd Exemple

obj : C1 obj2 : C2

msg()

msg()

alt [x == 42]

[else]

�193


• Option (opt): l’opérande est optionnelle. Elle peut ne pas exister • Break (break): l’opérande est exécutée, à la place du reste de

l’interaction (raccourci pour alternative)

Fragments

�194


• Parallèle (par): le comportement spécifié par les deux opérandes peut s’exécuter en parallèle (fusion entre les messages)

• Négatif: le fragment représente des traces invalides

Fragments

�195


• Région critique (critical): les traces spécifiées ne peuvent pas être intercalées

Fragments

�196


• Assertion (assert): spécification de la seule continuation valable

• Ignorer et Considérer (ignore | consider): spécification des messages significatifs

Fragments

sd Exemple ignore {t,r}

:X :Y

consider {q,v,w} v()

assert

q()

�197


• Boucle (loop): l’opérande sera répétée autant de fois que défini par une garde

• Autres: strict, ordonnancement strict, ordonnancement faible

Fragments

�198


• Diagramme de Communication

Interaction

�199


• Comme le diagramme de séquences, sert à représenter des exemples de coopération d’objets

• Cependant: la dimension temporelle est représentée par une séquence et les liens entre objets sont visibles

Diagramme de Communication

�200


• Equivalent à un diagramme de séquences

• Le chemin utilisé par les messages est visible

Notation

Gildas:Caissier

Aurélie:Client

1: demande argent()

2 : reçoit argent()

�201


Notation

:Carre :Segment

origine:Point

destination:Point

Sylvain

afficher() 1 *(i=1..4):affiche()4

1.1 position()

1.2 position()

Séquences consécutives et imbriquées

�202



!

• Interaction • Activités

�203


• Spécifie la séquence et les conditions pour coordonner différents comportements (plutôt que les classificateurs contenant ces comportements)

• Attachés à un Classificateur

Diagramme Activités

�204


• Composés d’un ensemble d’actions et de flots (de contrôle et de données)

• Spécifient une opération (conception) • Peuvent spécifier un workflow • Sémantique basée sur les réseaux de Petri

Diagramme Activités

�205


• Paramètres d’entrée et de sortie

• Pré et post-conditions • Exceptions

Notation

{activity}Activité

Attribut : type

Attribut : type

Operation(param)

Operation(param)

Action Action

Action

Nom de l'activité «precondition» contrainte«postcondition» contrainte

�206


Notation

�207


Actions

• Représentent un comportement d’exécution (une étape dans l’exécution d’un algorithme)

• Peuvent avoir une pré et une post conditions

• Types: fonctions primitives, appel de comportement, envoi d’événements, manipulation d’objets (lecture/écriture d’attributs)

Verser Café

boisson choisie = Café«localPrecondition»

le café est versé«localPostcondition»

�208


• De contrôle: déclenche une action une fois que l’action précédente est finie

• D’objet: chemin par lequel peuvent passer des objets et des données

Flots

�209


• Instance d’un classificateur, potentiellement dans un état particulier

• Événements

Objet

Café

[chaud]

{ordering = LIFO}

Annulation

�210


• Région d’une activité qui peut avoir une sortie alternative au flot normal

Région interruptive

déterminer boisson

mettre café dans le filtre

ajouter de l'eau dans le réservoir obtenir gobelet

mettre filtre dans la machine

infuser

Annulation

préparation annulée

�211


• Région qui s’exécute plusieurs fois, selon les éléments de la collection passée en entrée

• Types d’exécution: parallèle, itérative ou stream

Région d’expansion

parallel

�212


• Fin d’activité, fin de flot • Fourchette

Autres noeuds

Préparer café

Livrer café

[encore du café]

[plus de café]

�213


• Décision: branchement sur plusieurs transitions

• Fusion: accepte un flot parmi plusieurs

Autres noeuds

[cout>10]

[cout<=10]

�214


• Jointure • Fourchette

Autres Noeuds

�215


• Groupement d’actions ayant des caractéristiques communes

• Utilisées pour affecter des actions à des ressources différentes (Classificateurs, Noeuds)

Partition

déterminer boisson

mettre café dans le filtre

ajouter de l'eau dans le réservoir

mettre filtre dans la machine

infuser

:Dis

tribu

teur

de

Bois

sons

:Caf

etiè

re

�216

Mécanismes d’extension

�217


Motivation

• Malgré sa richesse, UML n’est pas adapté à tous les domaines.

• Formes d’extension:

• Ajout de nouveaux éléments.

• Création de nouvelles propriétés.

• Spécification d’une nouvelle sémantique.

• Mécanismes disponibles:

• Stéréotypes, étiquettes et contraintes.�218


Stéréotypes

• Utilisés pour créer des éléments de modélisation spécifiques à un domaine.

• Par exemple, pour modéliser une base de données:

• «Entity», «Relationship»

• «Table», «Index»

�219


Stéréotypes - notation

• Textuelle: entre guillemets (« »)

• Icône

«Database»

Séminaires

list_all_lectures()

Séminaires

list_all_lectures()

Séminaires

�220


Étiquettes

• Définition de propriétés pour n’importe quel élément de modélisation.

• Attachées à des éléments existants ou à des stéréotypes. • Présentées sous la forme d’une paire étiquette=valeur

�221


Étiquettes

• Utiles pour ajouter des informations concernant: • La documentation • Le contrôle de version • La génération de code • etc.

�222


Étiquettes - notation

• Présentées entre crochés.{version = 1.1}

Cours

Nom : StringDurée : Integer

�223

Méta-modèle

�224


Méta-modélisation

• Spécification d’un langage de modélisation grâce à un autre langage de modélisation, appelé «métalangage» ou «métalangue».

�225


Métalangage

• Une métalangue est une langue qui prend pour objet une autre langue et qui la formalise.

• Un métalangage n’est rien d’autre qu’un langage. • Même s’il s’agit d’un méta-méta-méta-méta-méta-méta-méta-

méta-méta-méta-méta-méta-métalangage.

�226


Langage

• Un langage est composé d’une syntaxe et d’une sémantique. • La syntaxe spécifie les sujets (concepts, entités) et les verbes

(liens entre ces concepts) d’un langage. • La sémantique donne une interprétations aux sujets et aux

verbes

�227


Syntaxe abstraite

• Définition des liens possibles • Exemple: une association lie deux classes, une classe contient des

attributs, etc.

�228


Syntaxe concrète

• Syntaxe concrète: définition de la représentation des sujets et des verbes.

• Par exemple: graphique (diagrammes), textuelle (HUTN).

Cours

Nom : StringDurée : Integer

Class “Cours” { attribute: “nom” { type = “String” } attribute: “durée” { type = “String” } }

�229


Méta-modèle

• Modèle représentant la syntaxe abstraite d’un langage. • Celui de UML est représenté en MOF et organisé en différents

paquetages. • Il est complété par des règles de bonne formation (well

formedness rules) sous la forme de contraintes OCL.

�230

Profils

�231


Profil

• Mécanisme d’extension d’UML permettant la création de modèles dans des domaines spécifiques:

• Systèmes de temps-réel, EJB, Corba, Test, etc.

�232


Spécification

• Un profil est un paquetage qui contient un ensemble de mécanismes d’extension: stéréotypes, étiquettes, contraintes, etc.

• Ces mécanismes s’appliquent à des éléments UML existants:

• les profils ne modifient pas le méta-modèle de UML.

�233


Rôle

• Identifier un sous-ensemble d’UML

• Spécifier des stéréotypes et/ou des étiquettes.

• Spécifier d’autres règles de bonne formation.

• Spécifier une sémantique (toujours en langage naturel).

�234


Exemple

• Profil UML pour la modélisation de données.

• Éléments:

• Entités

• Associations

• Contraintes: les entités sont des classes qui n’ont pas de comportement

�235

Le profil de modélisation

context Stereotypeinv: self.name = “Entity” implies self.baseClass.ownedOperation->isEmpy()

Data modeling profile

Classfrom Core

Associationfrom Core

«Stereotype»Entity

«Stereotype»Relationship

�236

Exemple

«Entity»Lecture

«Entity»Professor«Relationship»

�237

UML - Introduction à la notation

Technology

Transcript of UML - Introduction à la notation