Michel Tollenaere ENSGI 2A MSI - UML version 1.a du 1er Octobre 2002 1 UML : Unified Modelling Language Historique : Références : Object Management Group

ENSGI 2A MSI - UML version 1.a du 1er Octobre 2002

1Michel Tollenaere

UML : Unified Modelling Language

Historique :

Références : Object Management Group http://www.omg.orgen France Pierre Alain Muller (U-Mulhouse) et Valtech

Outils : Objecteering http://www.objecteering.com/us/produits_pe.php

Rational ROSEplus de 30 outils de modélisation et de CASE(Computer Aided Software Engineering)


2Michel Tollenaere

UML : • modelling information systems• at conceptual level• at logical level


3Michel Tollenaere

Creating the UML

Booch method OMT

Unified Method 0.8OOPSLA ´95

OOSEOther methods

UML 0.9Web - June ´96

publicfeedback

Final submission to OMG, Sep ‘97

First submission to OMG, Jan ´97

UML 1.1OMG Acceptance, Nov 1997

UML 1.3

UML 1.0UML partners


4Michel Tollenaere

Meyer

Before and after conditions

Harel

StatechartsGamma, et al

Frameworks and patterns,

HP Fusion

Operation descriptions and message numbering

Embley

Singleton classes andhigh-level view

Wirfs-Brock

Responsibilities

Odell

Classification

Shlaer - Mellor

Object lifecycles

Rumbaugh

OMT

Booch

Booch method

Jacobson

OOSE

Contributions to the UML


5Michel Tollenaere

Diagrammes UML

• diagramme de classes

• diagramme de cas d’utilisation

• diagramme de séquence

• diagramme de collaboration

• diagramme d’objets

• diagramme d’états-transitions

• diagramme d’activités

• diagramme de composants

• diagramme de déploiement


6Michel Tollenaere

Légende

Cas d’utilisation

une fonctionnalité attendue du système (VEGA2) par les différents acteurs.

cas d'utilisation : acteur (intéragissant

avec VEGA2)

Système (VEGA2)

message

messagemessage

message

Diagramme de séquence

Chaque cas d'utilisation apparaît comme un scénario, décrit par un ou plusieurs diagrammes de séquence.

Un diagramme de séquences montre les interactions entre les acteurs et le système selon un point de vue

temporel pour accomplir une fonctionnalité attendue du système (un cas d ’utilisation). C’est une ensemble de

messages échangés entre les acteurs et le système, ordonnés chronologiquement.

Diagramme de Classes

objet 1

objet 3

objet 2 objet 4

lien exprimant que "objet 2 est

composé de objet 3"

lien exprimant que "objet 2 a une relation avec objet 4"

lien exprimant que "objet 2 est une sorte de objet 1"


7Michel Tollenaere

Diagramme de cas d’utilisation

Représente les fonctions du système de point de vue de l ’utilisateur.

Eléments du diagramme :

• acteur : un rôle joué par une personne, un service, etc. qui interagit avec le système étudié

• cas d’utilisation : manière spécifique d ’utiliser un système. Image d’une fonctionnalité attendue, déclenchée en réponse à la stimulation d’un acteur

• relations entre cas d’utilisations et acteurs

Cas d ’utilisationActeur

relation

Cas d ’utilisation


8Michel Tollenaere

Diagramme de cas d’utilisation

Relations entre cas d ’utilisations

Trois types de relations :

• relation de communication : entre un acteur et un cas d’utilisation. Exprime l’échange d’informations entre l’acteur et le système.

virementclient

déclenche

• relation d’utilisation : entre deux cas d ’utilisation. Exprime que le cas d’utilisation source comprend également le comportement décrit par le cas d’utilisation destinataire (utile pour la factorisation de cas).

virement identification

« use »

• relation d’extension : entre deux cas d’utilisation. Exprime que le cas d’utilisation source étend le comportement du cas d’utilisation cible (utile pour la spécialisation de cas).

Virement par Internet

virement

« extend »


9Michel Tollenaere

Diagramme de Séquences

Un cas d’utilisation apparaît comme un scénario, décrit par un diagramme de séquences.

Diagramme de séquence : exprime la séquence des interactions entre objets du système selon un point de vue temporel, pour réaliser le cas d’utilisation.

Objet 1 Objet 2

1 : [condition A] message

2 : message synchrone

4 : message

6 : [condition B] message

9 : message asynchrone

7 : message réflexif

Evénement / Communication

entre objets

Objet 33 : message de création

5 : message

8 : message de destruction

Période d’activité de l’objet


10Michel Tollenaere

• message synchrone: l’émetteur est bloqué et attend que l’appelé ait fini de traiter le message (message 1)

message asynchrone: l’émetteur n’est pas bloqué et peut continuer son exécution (message 6)

• Un message réflexif indique souvent un point d ’entrée dans une activité de plus bas niveau qui s ’exerce entre objets contenus par l ’objet composite (message 7)

• Un message dont les délais de transmission sont non négligeables est matérialisé par une flèche oblique (message 4)

• Messages conditionnés : flèches prenant leur origine au même instant avec des conditions mutuellement exclusives (messages 1 et 6)

• Possibilité de compléments d ’informations sous forme de texte libre ou de pseudo-code à côté du diagramme

• Période d ’activité : temps pendant lequel un objet effectue une action, directement ou par l ’intermédiaire d ’un autre objet sous-traitant

• Des contraintes temporelles peuvent être exprimées en graduant la ligne de vie (pour dire par exemple: « 10 secondes plus tard »)


Cas particuliers


11Michel Tollenaere


Exemple

AppelantLigne

téléphonique Appelé

décroche

tonalité

numérotation

sonnerieindication de sonnerie

décroche

allô


12Michel Tollenaere

Diagramme de Collaboration

Comme les diagrammes de séquence : interactions entre objets du système avec un accent particulier sur la structure spatiale statique des objets (contexte des objets). Les messages sont numérotés pour indiquer l ’ordre des envois.

Message: Simple, Asynchrone, Synchrone,, Minuté

: ascenseur

: cabine

: porte

: lumière

1 : monter

3 : fermer

2 : allumer

Objet 1

Objet 2

Objet 3

1 : message

3 : message

2 : message

4 : message 5 : message


13Michel Tollenaere

Diagramme de classes

Structure statique d’un système, en termes de classes et de relations (3 types) entre ces classes.

Nom de classe

Attributs

Opérations ()

Motocyclette

Couleur

Cylindrée

Vitesse max

Démarrer ()

Accélérer ()

Freiner ()

Visibilité : trois niveaux de visibilité pour les attributs les opérations:

• public (+) : élément visible à tous les clients de la classe

• protégé ( #) : élément visible aux sous-classes de la classe

• privé (-) : élément visible à la classe seule

Syntaxe:

• nom_attribut : type_attribut = valeur initiale

• nom_opération (nom_argument : type_argument = valeur_par_défaut, …) : type_retourné

exemple :


14Michel Tollenaere


Relations entre classes

Agrégation : quand une classe fait partie d’une autre classe (agrégat - composant)

Généralisation : factorisation des éléments communs d’un ensemble de classes dits sous-classes dans une classe plus générale dite super-classe. Elle signifie que la sous-classe est un ou est une sorte de la super-classe. Le lien inverse est appelé spécialisation

Association : toute relation structurelle entre classes, autre que l ’agrégation et la généralisation

classe 4

classe 3

classe 2

classe 1

agrégation

associa

tion

généralisation sp

écia

lisa

tion

véhicule

voiture camion avion

moteurconstructeur1 1..* 1..*1


15Michel Tollenaere


RelationsAgrégation:

• Relation transitive : si voiture est composée de moteur et si moteur est composé de courroie alors voiture est composée de courroie

• Relation non systémique: si voiture est composée de moteur, moteur ne peut pas être composé de voiture

• Relation réflexive : une fonction peut être composée d ’autres fonctions

Généralisation :

• Relation non réflexive : une classe ne peut dériver d’elle-même

• Relation non symétrique : si une une voiture est une sorte de véhicule, alors le véhicule ne peut pas être une sorte de voiture

• Relation transitive : si voiture est une sorte de véhicule terrestre qui elle même est une sorte de véhicule alors voiture est une sorte de véhicule

Association :

• Une classe a un rôle dans une association.

• Les rôles portent une information de multiplicité précisant le nombre d ’instances qui participent dans la relation. Les multiplicités les plus courantes sont : 1 / 0..1 / m..n / * /0..* / 1..*

véhiculeconstructeur1 1..*

construit parconstruire


16Michel Tollenaere

Diagramme d’Objets

Structure statique d’un système, en termes d’objets et de liens entre ces objets.

Un objet est une instance de classe et un lien est une instance de relation.

Nom de l ’objet : Classe

Attributs = valeurs

Etienne : personne

âge = 35

Jan-Luc : personne

âge = 25

patronPersonne

âge : entier

patron

collaborateur

1

*

Diagramme de classes Diagramme d ’objets


17Michel Tollenaere

Diagramme d ’états-TransitionDescription des séquences possibles d’états et d ’actions par lesquelles un objet peut passer tout au long de sa vie. Ces séquences résultent de sa réaction à des événements discrets.

Eléments du diagramme :

• état : situation d’un objet à un moment donné

• transition : connexion entre deux états, permettant le passage d’un état à l’autre

• événement : occurrence d ’une situation donné dans le domaine du système qui déclenche la transition

• garde : condition booléenne qui valide ou non le déclenchement d’une transition lors de l’occurrence d’un événement (cas de plusieurs transitions exclusives déclenchées par le même événement)

• action : opération exécutée pendant que l’objet est dans un état donné ou lorsque une transition est déclenchée (correspondant à des opérations déclarées dans la classe de l’objet destinataire). Une action d’un état est dite activité quand l’opération associée a un temps d’exécution non négligeable (do : nom_opération)

Etat A

action

do:opération

Etat BEvénement [garde] / Action

…. ….

état initial état final


18Michel Tollenaere

Personne

âge Société0..11..*

Les personnes ne possèdent pas toutes un emploi et se trouvent, à un moment donné, dans un des états suivants : en activité, au chômage, à la retraite

L’état d ’une personne donnée est déterminé selon son âge et la présence ou non d’un lien vers une société.

Diagramme d ’états-Transition

Exemple

Diagramme de classes Diagramme d ’états-transitions

En activité

do: travailler

Au chômage

A la retraite

Perte d ’emploi

Embauche

Plus de 60 ans

Plus de 60 ans


19Michel Tollenaere

Diagramme d ’Activitéson peut aussi utiliser IDEF0 ou IDEF3

Variante des diagrammes d’états-transition, organisé par rapport aux actions et destiné à représenter le comportement interne d’une opération ou d’un cas d ’utilisation.

Mesurer température

Chauffer Refroidir

AérerArrêter chauffage

[trop froid] [trop chaud]

« synchronisation »


20Michel Tollenaere

Diagrammes de composants et de déploiement

Diagramme de composants :

• représente l’architecture logicielle

• décrit les spécifications des modules qui vont contenir le code des classes ainsi que le programme principal. L’identification des modules est réalisée pour chaque sous-système du système global.

Diagramme de déploiement : • représente l’architecture matérielle• décrit la disposition physique des différents nœuds (processeurs) dans la composition d’un système et la répartition des programmes principales du diagramme des composants, sur ces processeurs.


21Michel Tollenaere

Mécanismes UML : Paquetage

• Regroupement d’éléments de modélisation. Une façon d’organiser les modèles de la même manière que les répertoires organisent les fichiers. Un paquetage contient divers diagrammes.

• Un paquetage peut contenir d’autres paquetages, sans limite d ’emboîtement.

• Un élément contenu par un paquetage peut apparaître dans un autre paquetage sous forme d ’élément importé.

• Un seul type de relations entre paquetages : les dépendances (au moins un élément du paquetage client utilise les services offerts par les éléments du paquetage fournisseur.

Fournisseur

Client

dépendance


22Michel Tollenaere

Mécanismes UML : Stéréotype

• Un mécanisme d’extensibilité d ’UML. • Il spécialise les éléments de modélisation d’UML, pour un métier donné : cas

d’utilisation, lien, classe, …. • Il permet la classification des éléments de modélisation (méta-modélisation).• Chaque élément de modélisation d’UML a au plus un stéréotype, lorsque la

sémantique de base est insuffisante.

Exemple : dans le domaine de la gestion des données techniques, les liens de composition entre articles sont stéréotypés selon leur nature : « nomenclature BE » / « nomenclature BM » / etc.

Documents

Michel Tollenaere ENSGI 2A MSI - UML version 1.a du 1er Octobre 2002 1 UML : Unified Modelling Language Historique : Références : Object Management Group