Ingénierie des systèmes logiciels

Ingénierie des Modèles Logiciels

Cours #1
Rappels sur UML
Jean Bézivin
Jean.Bezivin@irin.univ-nantes.fr
Equipe ATLAS (INRIA & IRIN), Nantes

. -1- © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Note liminaire

• Ce cours porte principalement sur l'approche MDA™ (Model Driven

Architecture) qui constitue une nouvelle alternative en génie logiciel.
• La vision MDA, les formalismes normes et outils associés sont
actuellement en évolution très rapide.
• Au mois de juin 2003 de nombreuses décisions portant sur les normes et
les évolutions seront prises (UML 2.0, MOF 2.0, etc.) et de nouvelles
orientations engagées (QVT, etc.) pour 2003/2004.
• Le présent support de cours ne constitue donc qu'une présentation
transitoire et partielle de ce domaine en évolution rapide. Il a pour
intention d'illustrer des tendances plutôt que de présenter des solutions
définitives.
• Il est fait pour être utilisé uniquement dans le contexte spécifique de
l'école d'été EDF/CEA/INRIA du 16 au 27 juin 2003.
• De nouvelles version de ce support seront élaborées au cours des
prochains mois.

Jean Bézivin, Mai 2003

. -2- © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Plan général du cours

• Cours #1 Rappels sur UML

• Cours #2 Sur l'intégration, l'interopérabilité et les modèles
• Cours #3 De l'OMA vers le MDA, des objets vers les modèles

• Cours #4 La pile de modélisation de l'OMG et le MOF

• Cours #5 Visite guidée des standards ADTF de l'OMG
• Cours #6 La transformation de modèles
• Cours #7 Les modèles de processus
• Cours #8 La liaison à la plateforme
• Cours #9 Bases conceptuelles du MDA
• Cours #10 Études de cas, outillage et retours d'expérience

. -3- © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Les travaux pratiques

•TD #1
•Modélisation d'un site Web : les rudiments de UML

•TD #2
•Génération de code avec XSLT

•TD #3
•Transformation de modèles dans le MDA

. -4- © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Les conférences

•Une conférence double

•Le MDA chez Thales

•par Serge Salicki

•Le MDA chez France Télécom

•par Mariano Belaunde

. -5- © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Plan du cours #1
• Introduction
• Historique de l'introduction du formalisme UML
• Les neuf types de diagrammes
• Classes, Objets, Etats, Activités, Séquences,
Collaboration,Composants, Déployement, Cas
d'utilisation
• Les mécanismes de base
• Paquetages
• Les mécanismes d'extension
• Contraintes, stéréotypes, valeurs marquées
• Le formalisme OCL
• Présentation du TP #1

. -6- © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Historique : Évolution de UML

0.8 ->0.9
0.9->0.91->1.0
1.0->1.1->1.2->1.3->1.4
UML d'après les «amigos»
Jim Rumbaugh Grady Booch Ivar Jacobson

OMT Booch Objectory 1.5

2.0
UML

Comprendre la logique d’évolution d’UML. x.y

. -7- © 2003 ATLAS Nantes
 Ingénierie des systèmes logiciels

De Rational à l'OMG

1.1 -> 1.2. -> 1.3 -> 1.4 -> 1.5 -> 2.0

?
Soumission de UML 1.0 à OMG Industrialisation
pour adoption (janvier 1997).
Standardisation
public feedback

UML 1.0

(juin 96 - oct. 96) UML 0.9 & 0.91 Unification

UML
partners expertise
OOPSLA’95 Unified Method O.8 Fragmentation

Booch 93 OMT-2

Autres méthodes Booch 91 OMT-1 OOSE

( 50)

. -8- © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Devant et derrière, Avant et après ...

Méthode = Langage(s) + Démarche + Outils

OMT
procédés
industriels
UML SA/RT
SADT
de production ERD Merise
de logiciels et
de systèmes. DFD
DFD
etc.
JSD

. -9- © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

L'image globale (roadmap)

1985-1995
Procedural ADM Method = notation + process + tools

Unified Method: impossible

OOADM
11/1997
e.g. OMT 07/2001

+ profiles
UML + other MMs Model UPM + specific processes
(RUP, IBM SI, etc.)
weaving SPEM
>2001

Network of models

1. Comment séparer les aspects ?

2. Comment tisser les aspects ?

. - 10 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Et un langage unique, un!

La définition du formalisme UML ne résulte pas

d'un processus innovant de recherche mais
d'un processus consensuel de stabilisation des pratiques
Industrielles éprouvées.

UML n'est que le reflet fidèle des pratiques majoritaires

utilisées vers la fin des années 2000 par la profession.

UML ne vise pas l'innovation, mais la consensualité.

Il y a deux façons de réaliser un consensus:

à minima (par intersection) ou à maxima (par union).

Ces deux tendances se retrouvent dans les groupes d'influence

qui gèrent l'évolution du langage (vendeurs d'AGL, etc.)

La tendance maximaliste a souvent été majoritaire (!)

. - 11 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

UML n'est pas un projet de recherche

"In short: the time for experimentation

is past;
the time for stability and use
is now."

Grady Booch
Chief Scientist
Rational Software Corporation

. - 12 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Evolution de la terminologie

Booch Classe Utilise Hérite Contient

Connexion
Coad Classe/Objet
d'instance
Gen/Spec Tout/Partie

Accointance
Jacobson Objet Association Hérite ConsisteEn

Odell Objet/Type Relation Sous-type Composition

Rumbaugh Classe Association Généralisation Aggrégation

Shlaer/Mellor Objet Relation Sous-type N/D

UML Classe Association Généralisation Aggrégation

. - 13 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Quelques notations de cardinalité

1 + ? *
Booch.1 A B A B A B A B

1 1,m 0,1 0,m

Coad A B A B A B A B

1+
Rumbaugh A B A B A B A B

1 1..* 0..1 *
UML A B A B A B A B

un A toujours un A toujours un A associé un A associé

associé avec associé avec avec zéro ou avec zéro, un
un B. un ou plusieurs B. un B. ou plusieurs B.
. - 14 - © 2003 ATLAS Nantes
 Ingénierie des systèmes logiciels

Vues multiples (aspects d'un système logiciel)

Vue du Vue de Vue du

plombier l'électricien locataire

Vue du
Vue du propriétaire
maçon

Vue de
l'architecte

Vue du
notaire Vue du Vue du service
cadastre des impots locaux

. - 15 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Vues multiples (aspects d'un système logiciel)

Fonctions du système
du point de vue
de l’utilisateur. Les objets et les relations de base
entre ces objets.

Composants Représentation
physiques du comportement Représentation des objets,
d’une en termes d’états. des liens mutuels et des
application. interactions potentielles.

Représentation des objets

Schémas de l’installation
et de leurs interactions temporelles.
des composants sur les
dispositifs matériels.
Représentation
du comportement
Structure statique des classes et des relations entre ces classes. des opérations
en termes d’actions.

. - 16 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Un peu de retard
2001
(p la n n e d m a jo r r e v is io n ) < < d o c u m e n t> >
U M L 2 .0

< < r e f in e > >

Version stabilisée 1.5 non prévue initialement  O th e r r e le v a n t
s ta n d a rd s T B A

Q 3 2000 < < d o c u m e n t> >

(p la n n e d m in o r r e v is io n ) < < in f o r m a lL ia is o n > >
U M L 1 .4

IS O P u b lic ly
< < r e fin e > >
A v a ila b le
S p e c ific a tio n s
(P A S )
< < d o c u m e n t> >
Q 3 1999 < < fo r m a lL ia is o n > >
U M L 1 .3

< < r e fin e > >

E d it o r ia l r e v is io n
< < d o c u m e n t> >
w it h n o s ig n ific a n t
Q 2 1998 U M L 1 .2
t e c h n ic a l c h a n g e s .

< < r e fin e > >

Q 3 1997 U n if ic a tio n o f m a jo r
(O M G A d o p te d < < d o c u m e n t> > m o d e lin g la n g u a g e s ,
T e c h n o lo g y ) U M L 1 .1 in c lu d in g B o o c h , O M T
From Cris Kobryn a n d O b je c to r y

. - 17 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

UML 1.5 : la dernière version disponible (mai 2003)

UML 1.5
http://www.omg.org/technology/documents/formal/uml.htm

Unified Modeling Language (UML), 

version 1.5

OMG is pleased to announce that the Unified Modeling Language (UML)

specification is available electronically.
OMG has released a new version (1.5) of the UML specification,
which includes the syntax and semantics
of executable actions and procedures,
including their run-time semantics. 

. - 18 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

De UML 1.5 à UML 2.0

• UML 2.0 Infrastructure RFP -- A

UML 2.0 RFP issued September 15,
2000 that is primarily concerned with
architectural alignment, restructuring
and extension mechanisms.
• UML 2.0 Superstructure RFP -- A
UML 2.0 RFP issued September 15,
2000 that is primarily concerned with
the refinement and extension of UML
1.x semantics and notation.
• UML 2.0 OCL RFP -- A UML 2.0 RFP
issued September 15, 2000 that is
primarily concerned with with defining
an OCL metamodel.
• UML 2.0 Diagram Interchange RFP
-- A UML 2.0 RFP issued March 2,
2001 that is primarily concerned with
with defining metamodel for diagram
interchange using the XMI facility.

"Will UML 2.0 Be Agile or

Awkward?" par Cris Kobryn
. - 19 - © 2003 ATLAS Nantes
 Ingénierie des systèmes logiciels

UML 2.0

UML 2.0
Breaking news: Three of Four Parts of UML 2.0 Approved
Task force delays acceptance of Superstructure portion of spec pending ‘cleanup’
                             
April 15, 2003 —
As expected, the Analysis and Design Task Force of Object Management Group Inc. in late March
voted to accept the Unified Modeling Language 2.0 Infrastructure, Object Constraint Language (OCL)
and Diagram Interchange Protocol submissions and recommend to the full organization their adoption.
The task force, though, tabled a vote on changes to the Superstructure recommendation
until a June meeting in Paris.

. - 20 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Visite guidée rapide du langage

• Les mécanismes généraux

• Les paquetages
• Les stéréotypes
• Les étiquettes
• Les notes
• Les contraintes
avec la contribution
• Les diagrammes de base de Pierre-Alain Muller
• Les diagrammes de classes
• Les diagrammes d’objets
• Les diagrammes de cas d'utilisation
• Les diagrammes de séquence
• Les diagrammes de collaboration
• Les diagrammes d'états/transitions
• Les diagrammes d'activités
• Les diagrammes de composants
• Les diagrammes de déploiement

. - 21 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Les paquetages

• Structuration des modèles

. - 22 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Variantes de paquetage

• Sous-système (unité de comportement)

• Modèle

. - 23 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Stéréotypes

• Un stéréotype élargit le vocabulaire d'UML, en permettant de créer

de nouvelles sortes de briques de base qui dérivent des sortes
existantes mais qui sont adaptées à un problème donné. Par exemple,
lors d'un travail dans un langage de programmation, tel que Java ou C+
+, il est souvent souhaitable de modéliser des exceptions. Dans ces
langages, les exceptions ne sont que des classes, même si elles sont
traitées de manière très particulière. En règle générale, il est
préférable de leur permettre simplement d'être lancées et attrapées
et rien de plus. Il est possible de faire de ces exceptions des
éléments plus importants des modèles — ce qui signifie qu'elles sont
traitées comme des briques de base — en les marquant avec un
stéréotype approprié.
• Définition :
stéréotype. Un nouveau type d'élément de modélisation qui étend la sémantique du
méta-modèle. Les stéréotypes doivent être basés sur des types ou classes
existant dans le méta-modèle.

. - 24 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Les stéréotypes

• Extension contrôlée des classes du méta-modèle

• <<Nom du stéréotype>>
• Possibilité de modifier l’icône

«datatype»
Integer «exception»
«subsystem»
User Interface Overflow

«utility» «traces» «refines»

Maths

. - 25 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemples de stéréotypes

. - 26 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Les étiquettes

• Extension des attributs des classes du métamodèle

• Paire (nom, valeur)
• Tagged values

. - 28 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Les notes

• Commentaire attaché à un ou plusieurs éléments de

modélisation
• Appartient à la vue, pas au modèle
• Peut être stéréotypée en contrainte

A
Ceci est un
commentaire

B
Blah blah

. - 29 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Les contraintes

• Relation sémantique quelconque entre éléments de

modélisation
• Exprimée en OCL (Object Constraint Language) ou en
langage naturel
• {contrainte}, inv, pre-, post-condition

A
«postcondition»
{Count > 10}

. - 30 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemples de contraintes
Copie Livre
{xor}

Journal

{self.roues->size <= 4}

Transaction
quantité:Euro {quantité est un multiple de €5}

. - 31 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Quelques exemples de contraintes standard

• Généralisation
• Complete
• Incomplete
• Disjoint
• Overlapping
• Instance ou lien
• New
• Destroyed
• Transient
. - 32 - © 2003 ATLAS Nantes
 Ingénierie des systèmes logiciels

Extensibilité du formalisme UML

stéréotype
de classe

Étiquette ou
valeur marquée
(tagged value)

contrainte

stéréotype
d'opération

. - 33 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de cas d'utilisation

Use Cases

. - 34 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de cas d'utilisation

• Les diagrammes de cas d'utilisation représentent un ensemble de cas

d'utilisation et d'acteurs (sorte de classe particulière) et leurs
relations. Ils permettent de délimiter les frontières du système.

. - 35 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Relations des cas d’utilisation

• Association, Extension, Utilisation, Généralisation

. - 36 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Relations des acteurs

• Association, généralisation

. - 37 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Un cas d'utilisation réalisé par une collaboration d'objets

. - 38 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Les diagrammes de classes

Classes

. - 39 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de classes

• Les diagrammes de classes représentent un ensemble

de classes, d'interfaces et de collaborations, ainsi
que leurs relations. Ce sont les diagrammes les plus
fréquents dans la modélisation des systèmes à
objets. Ils présentent la vue de conception statique
d'un système. Les diagrammes de classes, (qui
comprennent aussi les classes actives), présentent la
vue de processus statique d'un système.

Zèbre

<<interface>>
Zébu

. - 40 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Les classes

• La classe est une description • Caractéristiques des classes

abstraite d’un ensemble
d’objets • Attributs

• La classe peut être vue comme • Opérations

la factorisation des éléments • Réceptions
communs à un ensemble d’objets • Relations
• La classe décrit le domaine de • Multiplicité
définition d’un ensemble
d’objets • Persistance
• Composant
• Description conceptuellement
séparée en deux parties
• La spécification d’une classe qui
décrit le domaine de définition et
les propriétés des instances de
cette classe (type de donnée)
• La réalisation qui décrit comment
la spécification est réalisée

. - 41 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de classe.

nom de la classe
nom de la classe
- variable privée
+ variable publique attributs
# variable protégée nom_attr : type = valeur initiale

- opération privée opérations

+ opération publique nom_op (arg_list):type
# opération protégée

parametre

classe parametrable
nom de l’association

une classe une autre classe

nom de la / association dérivée

classe association
attributs rôle 1 rôle 2
nom de l’association
operations
une classe une autre classe

. - 42 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Visibilité des propriétés

Truc
+attributpublic
• Public +
#attributprotégé
Visible à l’extérieur de
-attributprivé
la classe
+Opérationpublic()
• Protégé #
#Opérationprotégée()
Visible seulement par
-Opérationprivée()
les descendants
• Private -
Visible à l’intérieur des
méthodes
• Souligné
Variable/opération de
classe

. - 43 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Variantes de classes

• Classe emboîtée
• Déclarée dans la portée
lexicale d’une autre classe.

• Type
• un domaine de définition
d’objets
• opérations + attributs +
associations
• Classe d’implémentation
• Pour la réalisation des types
• Méthodes + structure de
données physiques

. - 44 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Variantes de classes

• Classe paramétrée
• Modèle de classe
• Paramètres Formels
génériques (types,
opérations…)

• Classe utilitaire
• Espace de nommage,
groupement de
variables + opérations

. - 45 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Variantes de classes

• Interfaces

• Spécification des
opérations visibles
• Classes, paquetage,
composants
• Contrat sans
implémentation
• Pas d’attributs, de
méthodes, de relations
• Peut être cible d’une
association
monodirectionnelle
• Deux représentations
graphique
• Stéréotype, lollipop

. - 46 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Variantes de classes

• Metaclasse
La classe d’une classe.

• Enumération
Ensemble de littéraux d’énumération, ordonné.

• Powertype
Les instances du powertype sont des classes du modèle, s’utilise
pour la méta-modélisation.

. - 47 - © 2003 ATLAS Nantes


Les relations entre classes
• L’association
• L’agrégation
• La composition
• La généralisation
• La dépendance
. - 48 -
Ingénierie des systèmes logiciels
• L’association exprime une
connexion sémantique
bidirectionnelle entre
classes
• Une association est une
abstraction des liens qui
existent entre les objets
instances des classes
associées
© 2003 ATLAS Nantes
 Ingénierie des systèmes logiciels

Exemple

. - 49 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Nommage des associations

• Indication du sens de lecture

Université Héberge Etudiant

Université  Etudie dans Etudiant

. - 50 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Nommage des rôles

• Le rôle décrit une extrémité d’une association

+Etudiant
Université Personne

+Employeur +Enseignant

. - 51 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Multiplicité des rôles

1 Un et un seul
0..1 Zéro ou un
M .. N De M à N (entiers naturels)
* Plusieurs
0 .. * De zéro à plusieurs
1 .. * D'un à plusieurs

. - 52 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Visibilité des rôles

• Public
• Protégé
• Private -Role privé
B

+Rolepublic
A
* #Role protégé C
*
*

. - 53 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemple : graphe non orienté

. - 54 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemple : graphe orienté

. - 55 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Navigabilité

• étant donnée une association

non décorée entre deux classes,
on peut naviguer d'un type
d'objet vers un autre type
d'objet.
• par défaut une association est
• étant donné un utilisateur, on
navigable dans les deux sens. désire pouvoir accéder à ses mots
• une indication de navigabilité de passe
suggère en général qu'à partir
d'un objet à une extrémité on
peut directement et facilement • étant donné un mot de passe, on ne
atteindre l'un des objets à souhaite pas pouvoir accéder à
l'autre extrémité. l'utilisateur correspondant
• lors d'une mise en œuvre
programmée, ceci peut suggérer
par exemple qu'un objet source
mémorise une référence
directe aux objets cible.

. - 56 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemple

. - 57 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Les classes-associations

• Ajout d’attributs ou d’opérations dans la relation

A * * B

C
D
-a1
-a2
+op1() * *
+op2()

. - 58 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Associations ternaires (et plus)

• Pas d’agrégation, pas de qualifier

• Multiplicité plus difficile à lire

. - 59 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

L'agrégation

• Connexions sémantiques bidirectionnelles

antisymétriques
• Forme d’association qui exprime un couplage plus
fort entre classes
• Représentation des relations
• maître et esclaves
• tout et parties
• composé et composant.

. - 60 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

La composition

• Modélisation de la
composition physique
• Multiplicité au max de 1
du coté de l’agrégat
• Propagation automatique
de la destruction

Agrégat Partie

1 *

. - 61 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Hiérarchies de classes

• Gérer la
complexité
• Arborescences de
classes
d’abstraction
croissante

Super-classe

Classe plus
générale

Sous-classe

Classe plus
spécialisée

. - 62 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Association qualifiée

• Une association qualifiée met en relation deux classes sur la

base d'une clef.
• La technique associée de mise en œuvre est souvent un tableau
associatif ou un dictionnaire.
LigneDeCommande

Commande Produit Quté: Entier

Une personne peut être associée à plusieurs banques.

Etant donnés une banque et un numéro de compte,
Il y a au plus une personne ayant ce numéro de compte à cette banque.

. - 63 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Relation de dépendance

• Relations d’obsolescence dans un modèle

. - 64 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes d'objets

Objets

. - 65 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Représentation graphique des objets

• Le nom d’un objet est souligné

• Nom : Classe
• Nom
• :Classe

. - 66 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Représentation des liens

• Un lien est instance d’une association

• C’est un tuple de références vers des objets

. - 67 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

3 types de diagrammes avec des objets

• Diagrammes d’objets (point de vue statique)

• Diagrammes d’interaction (point de vue dynamique)

• Diagramme de séquence
• Diagramme de collaboration

• Deux niveaux de représentation des collaborations

• Niveau Spécification (des rôles et des messages)
• Niveau Instance (des instances et des stimuli)

. - 68 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes d'objets

• Les diagrammes d’objets représentent un ensemble

d’objets et leurs liens. Ce sont des vues statiques des
instances des éléments qui apparaissent dans les
diagrammes de classes. Ils présentent la vue de
conception d'un système, exactement comme les
diagrammes de classes, mais à partir de cas réels ou
de prototypes.

• Un diagramme d’objet est une instance d’une

diagramme de classes. Les diagrammes de classes
peuvent aussi contenir des objets (objets de classes,
au sens variables de classes)

. - 69 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes d'interaction

• Les diagrammes de séquence et les diagrammes de collaboration

d’instances sont deux types de diagrammes d'interaction. Les
diagrammes d'interaction représentent une interaction, c'est‑à‑dire
un ensemble d’objets et leurs relations, y compris les messages qu'ils
peuvent échanger. Ils présentent une vue dynamique d’un système.

• Les diagrammes de séquence sont des diagrammes d'interaction qui

mettent l'accent sur le classement chronologique des messages alors
que les diagrammes de collaboration d’instances sont des diagrammes
d'interaction qui mettent l'accent sur l'organisation structurelle des
éléments qui envoient et reçoivent des messages.

• Les diagrammes de séquence et les diagrammes de collaboration

d’instances sont isomorphes, c'est-à-dire que l'un peut être
transformé en l'autre.

. - 70 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de séquence

Séquences

. - 71 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de séquence

• Représentation des interactions entre acteurs et objets

• Vision temporelle d’une interaction
• Chaque objet est symbolisé par une barre verticale
• Le temps s'écoule de haut en bas, de sorte que la numérotation des
messages est optionnelle.
• Diagramme dual du diagramme de collaboration
• Souvent utilisé pour représenter une instance de cas
d’utilisation
• De manière plus générale, représentation temporelle d’une
interaction
• Bien adapté pour de longues séquences
• Ne visualise pas les liens
• Complémentaire du diagramme de collaboration

. - 72 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Messages et Stimuli

• Un Stimulus est une communication entre deux

instances, dans le but de déclencher une action.

• Un Message est une spécification de Stimulus, qui

définit les rôles de l’émetteur et du récepteur.

. - 73 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de séquence

• Avec des objets actifs

. - 74 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagramme de séquence.

• Acteur/objets
• Barres
d’activité
• Expressions
conditionnelles
• Récursion
• Créations
d’objets
• Destructions
d’objets

. © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagramme de séquence

• Représentation d’une sous-séquence

. - 76 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de collaboration

Collaborations

. - 77 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de collaboration

• Représentation d’une collaboration entre rôles

• Booch : Société d’objets collaborant (UML 1.5 : de rôles
communicants)
• Représentation spatiale d’une interaction
• Mise en avant de la structure
• Représentation des structures complexes (récursives par exemple)
• Pas d’axe temporel
• Diagramme dual du diagramme de séquence

• Des rôles ou des objets dans une situation donnée

• Des liens relient les objets qui se connaissent
• Les messages échangés par les objets sont représentés le long
de ces liens
• L’ordre d’envoi des messages est matérialisé par un numéro de
séquence

. - 78 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagramme de collaboration

• Représentation de collaborations de rôles

Description de la réalisation d’un Classifier ou d’une opération
Ensemble de rôles (ClassifierRoles + AssociationRoles)
/ ClassifierRoleName : ClassifierName

• Représentation de collaborations d’instances

• Ensemble d’objets (Objets + Liens)
• Conforme à un diagramme de collaboration de rôles

• Représentation d’interactions
• Ensembles d’objets + Stimuli (Instances de Messages)
. - 79 - © 2003 ATLAS Nantes
 Ingénierie des systèmes logiciels

Diagramme de collaboration

3 : Operation 1 (parametres)

1 : evenement 2 : operation

Objet 1 : nom de la classe Objet 2

4 : operation
nom acteur : 5 : operation (parametre)
nom de la classe

flux de donnees

Objet 3
: nom de la classe

. - 80 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemples : Traitement de texte

2 : Ecrire

• Object Actif 1 : Lire

: Imprimante
: Scanner

1: Venir me chercher au RDC

: Personne : Ascenseur

• Avec Acteur
: Cabine 2: Ajouter destination RDC

• Multi-objets
. - 81 - © 2003 ATLAS Nantes
 Ingénierie des systèmes logiciels

Diagramme de collaboration (niveau instances)

. - 82 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Le concept de messages

• L’unité de communication entre rôles

• Concept très général pouvant être mis en œuvre

suivant de nombreuses variantes (les stimuli)

• Regroupe les flots de contrôle et les flots de

données

. - 83 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemple

• Un objet A envoie un stimulus X à un objet B, puis

l’objet B envoie un stimulus Y à un objet C, et enfin C
s’envoie un stimulus Z.

A
3: Z
X
1:

2: Y
B C

. - 84 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagramme de collaboration avec condition

. - 86 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Représentation des patterns par des collaborations

• Vue interne

• Vue externe

. - 91 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes d'états-transitions

Etats/Transitions

. - 93 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes d'états

• Les diagrammes d'état sont des automates à états, composés

d'états, de transitions, d'événements et d'activités. Ils
présentent la vue dynamique d’un système, sont
particulièrement importants dans la modélisation du
comportement d'une interface, d'une classe ou d'une
collaboration et mettent l'accent sur le comportement d'un
objet ordonnancé par les événements, ce qui est
particulièrement utile dans la modélisation des systèmes
réactifs.
• Etat
• Condition dans laquelle se trouve un objet
• Transition
• Chemin entre deux états
• Evénement
• Occurrence qui survient dans le domaine

. - 94 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Symboles
Event2

Event1
State1 State2

Pseudo Etat Initial

CompositeState

Pseudo Etat Final

Event [C1] / Action

L’action est exécutée instantanément

. - 95 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Les actions et les activités

A
/ Op1

A
entry: Op2
do: Op3 Evt[ Garde ] / Action ^Cible.Evt
on Evt: Op4
exit: Op5

/ Op6 B

. - 96 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Les gardes

Trop Chaud[ Ete ] Trop Chaud[ Hiver ]

Climatisation Aération

. - 97 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Automates hiérarchiques
Plus de 60 ans
Actif

• Généralisation d’états Perte emploi Embauche

Retraité

Chomeur

Plus de 60 ans

Actif

Plus de 60 ans Retraité

Perte emploi Embauche

Chomeur

. - 98 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Automate à mémoire

Actif

Plus de 60 ans Retraité

Perte emploi Embauche

Chomeur
H

Zut Ok
H Mémoire (superficielle)

Mémoire (profonde)
Congé sabbatique H*

. - 99 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemple plus complexe

. - 100 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Graphes état-transition

. - 101 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes d’états.

Notation de Harel,
autorisant :

- gardes sur transitions,

- propagation de transition,
- actions sur transitions,
- actions sur entrée d’état,
- activités apparaissant tant
que l’état est actif,
- actions sur sortie d’état,
- imbrication d’états,
- concurrence.

. © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Sous-états séquentiels et concurrents.

. © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes d'activités

Activités

. - 104 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes d'activités

• Les diagrammes d'activités sont un type particulier de diagrammes

d'état, qui décrit la succession des activités au sein d'un système. Ils
présentent la vue dynamique d’un système, sont particulièrement
importants dans la modélisation de la fonction d'un système et
mettent l'accent sur le flot de contrôle entre objets.
• Le statut relatif des diagrammes d'activités et d'état est un
changement de UML 1.5 en UML 2.0
• Contexte d'utilisation :Description du comportement interne
• D’une classe
• D’une méthode
• D’un cas d’utilisation

. - 105 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemple

ActionState1

ActionState2

Fork

[C1]
[C2] Condition
ActionState5 ActionState7

ActionState3 ActionState4

Join
Barre de synchronisation

ActionState6

. - 106 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemple

Mesurer la température

[Trop froid] [Trop Chaud]

Chauffer Refroidir

Arrêter le chauffage Ouvrir les fenêtre

. - 107 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemple

Client Vendeur Livreur

Se renseigner

Etablir un devis

Commander

Facturer

Payer Livrer

. - 108 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemple

Activités Qui fait quoi, quand, ou

Statechart Cas d’utilisation Partition des exigences

Séquences Objects Classes Statechart

Composants Déploiement Statechart

. - 109 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de composants

Composants

. - 110 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de composants

• Les diagrammes de composants représentent

l'organisation et les dépendances au sein d'un
ensemble de composants. Ils présentent la vue
d’implémentation statique d’un système et sont liés
aux diagrammes de classe dans le sens où un
composant correspond généralement à une ou
plusieurs classes, interfaces ou collaborations.

. - 111 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de composants

• Représentation de la Component1 Interface1

structure du code
• Fichiers source, binaires,
exécutables, DLL
• Document d’organisation Dependency1
• Partitionnement de l’espace Node1
de réalisation
• Composant = unité de
réalisation distribuable
• Représentation de la
structure statique
• Des composants génériques
reliés par des relations de
dépendances
• Les composants ayant une
identité à l’exécution se Package1
représentent dans des
diagrammes de déploiement

. - 112 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Relation de dépendance

• Une relation d’obsolescence entre deux composants

• Flèche avec trait pointillé
• Concerne les éléments du modèles, pas forcément d’instance au
runtime
• Quatre stéréotypes prédéfinis
• Trace, refinement, usage, binding

Sous-programme Main Main A

Composant

Module Module générique

Tâche B
C

. - 113 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagramme de composant

composant 1

composant 2

. - 114 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de déploiement

Déploiement

. - 115 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de déploiement

• Les diagrammes de déploiement

représentent la configuration des nœuds Component ComponentInstance

de processus en phase d'exécution ainsi

que les composants qui y résident. Ils
présentent la vue de déploiement statique
d'une architecture et sont liés aux Node NodeInstance
diagrammes de composants, dans le sens
où un nœud renferme généralement un ou
plusieurs composants.
• Représentation de la structure d’un
système lors de son exécution
• Relation entre composants logiciels et Object1
matériels Interface

• Distributions des composants sur les

processeurs
• Les composants qui n’ont pas d’existence
propre à l’exécution se représentent
dans les diagrammes de composants

. - 116 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de déploiement

NodeInstance1

Object2
ComponentInstance1

nom du lien
Noeud 1 Noeud 2

. - 117 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Autres diagrammes

• Cette liste n’est pas exhaustive. Des outils peuvent

utiliser UML pour produire d'autres sortes de
diagrammes, même si les neufs types précédemment
cités sont les plus fréquemment utilisées dans la
pratique.

. - 118 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Modèles évolutifs et imparfaits

• Les modèles construits au cours du développement d'un système à

forte composante logicielle ont tendance à évoluer et peuvent être
utilisés par de nombreux intervenants selon des approches et à des
moments différents. c’est la raison pour laquelle il est courant que
l'équipe de développement construise non seulement des modèles
correctement mis en forme, mais parfois également des modèles :
• Partiels
• Afin de simplifier la représentation graphique, certains éléments sont cachés
• Incomplets
• Il manque certains éléments
• Incohérents
• L'intégrité du modèle n'est pas garantie
• Ces modèles imparfaits sont inévitables car les détails d'un système
se précisent et se combinent tout au long du cycle de développement
logiciel. Les règles d'UML encouragent — mais n'obligent pas — à
répondre aux principales questions d'analyse, de conception et
d'implémentation qui permettent à ces modèles d'acquérir peu à peu
une forme correcte.

. - 119 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de déploiement

unModem unDisque unPC

unNoeud

Console
<<TCP/IP>> unPC
unTX

unServeur
uneImprimante

. - 125 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Diagrammes de déploiement

. - 126 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Présentation du TD #1

TD #1

. - 127 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Un exemple : Championnat de football

. - 128 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Un exemple : Championnat de football

. - 129 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Object Constraint Language

OCL

. - 130 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Proposition IBM/Objectime

Modeling Schemes
Object (for specific languages)
Constraint Extension
Language Mechanism
(OCL)
is a refinement of

Core Meta-Model
67 Formally defined Meta-Types

OA&D Standard

. © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Introduction

• OCL (Object Constraint Language) est un langage d'expression

permettant de décrire des contraintes sur des modèles objet.
• Une contrainte est une restriction sur une ou plusieurs valeurs
d'un modèle.
• OCL fait partie de UML. OCL a été ajoutée par l'OMG à la version
UML 1.1.
• L'origine des contraintes se situe dans la logique des assertions de
Floyd-Hoare
• Assertion
• Pre-condition
• Post-condition
• Invariant
• On devrait parler de langage d'assertions et de navigation plutôt
que de langage de contraintes.

. - 132 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Stéréotypes standards UML

• <<precondition>>
• Pour toute opération, les droits de l'objet offrant le contrat
sont définis par une pré-condition
• <<postcondition>>
• Les obligations sont précisées par une post-condition. Une
post-condition doit être vérifiée au moment où l'opération se
termine.
• <<invariant>>
• Un invariant est une contrainte qui doit toujours être vérifiée
pour toutes les instances d'un type, d'une classe ou d'un
interface.

. - 133 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Expressions booléennes simples

Client
nom: String
titre: String
age: Integer
estMale: Boolean

context Client
titre = if estMale then ‘Mr.’ else ‘Mme.’ endif
age >= 18 and age < 66
nom.size < 100

. - 134 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemple

Client
sexe: enum {male, female}
nom: String
titre: String
naissance: Date

sexe = #male implies titre = ‘Mr. ‘

. - 135 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemple

self.transaction -> forAll (t:Transaction | t.value > 100)

1 0..*
CompteBancaire Transaction

CompteEpargne

self.solde > 0

. - 136 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemple

Spécifier qu'une classe est abstraite

Context Animal
Animal.allInstances -> select(oclType = Hint) -> isEmpty

. - 137 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemples

• Une interface ne contient que des opérations

self.allFeatures->forall (f | f.oclIsKindOf(Operation))

• Tous les éléments définis dans une interface

sont publics

self.allFeatures->forall (f | f.visibility = #public)

. - 138 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Exemple d'inclusion d'ensembles

pilote

équipage
Vol 1..*
Personne

0..* stewards

context Vol
self.équipage -> includes( self.pilote )
context Vol
self.équipage -> includesAll(self.stewarts)

. - 141 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Complexité de UML

"Inside every large meta-model is a small meta-model

struggling to get out."

inspiré de Tony Hoare

Six years after UML 1.1 was adopted, no vendor has

fully implemented any of the UML 1.x specifications or
even bothered to document their compliance. What
sort of a *standard* is this?

Trouvé sur le Web

. - 145 - © 2003 ATLAS Nantes

 Ingénierie des systèmes logiciels

Fin du cours

Merci
Questions ?
Commentaires ?

Jean Bézivin
Jean.Bezivin@irin.univ-nantes.fr
Equipe ATLAS, INRIA & IRIN, Nantes

. - 146 - © 2003 ATLAS Nantes