Intitulé du Master : Génie Logiciel

Semestre : S1

Intitulé de l’UE : UEF 1.1

Intitulé de la matière : Modélisation orientée objet

Crédits : 6

Coefficients : 3

Objectifs de l’enseignement

Utiliser les diagrammes UML 2.0 à des fins de modélisation conceptuelle et

technique. Faire le lien entre le diagramme conceptuel et le code applicatif. Utiliser
les notions avancées de modélisation OO. Améliorer l’architecture générale des
développements OO au sein de l’entreprise.

Connaissances préalables recommandées

Il est attendu que les étudiant disposent d’une expérience en développement

informatique et en conception de systèmes. Les participants doivent également
connaître un langage de développement orienté objet (exemple Java, C++, …).

Contenu de la matière

Chapitre 1 : Diagrammes UML 2.0

o Rappels
o Concepts de bases
o Exemples

Chapitre 2 : Le langage de contraintes OCL

o Généralités
o Formes de contraintes
o Exemples

Cours MOO Pr A. AMIRAT Page 1

Chapitre 3 : Formes de présentation des modèles UML

o Graphique
o Based trée représentation
o Annotation
o Création de modèles sous Eclipse modeling tool

Chapitre 4 : Comparaison & Merge de Modèles

o Généralités
o EMF Compare
o Merge de Modèle EMF
o Exemples

Chapitre 5 : Les profils UML

o Généralités
o Eléments de spécialisation
o Exemples

Chapitre 6 : Conduite de projets UML

o Etude de cas

Mode d’évaluation : Contrôle continu (30%), examen (70%)

Références
1. Traité de modélisation objet, Auteur(s) : Arnold Rochfeld, Philippe Rigaux,
Editeur(s) : Eyrolles, 2002.
2. La programmation orientée objet, Cours et exercices UML 2 avec Java, C#, C++,
Python, PHP et LINQ. Auteur(s) : Hugues Bersini
3. Editeur(s) : Eyrolles, 2013.
4. UML 2 pour les développeurs, Cours et exercices corrigés, de Xavier Blanc et
Isabelle Mounier, 2006

Cours MOO Pr A. AMIRAT Page 2

Introduction à UML

Diagrammes structurels ou statiques (6 diagrammes)

Les diagrammes structurels ou statiques (Structure Diagram) rassemblent :

1. Diagramme de classes (Class diagram) : il représente les classes intervenant

dans le système.

2. Diagramme d'objets (Object diagram) : il sert à représenter les instances de

classes (objets) utilisées dans le système.

3. Diagramme de composants (Component diagram) : il permet de montrer les

composants du système d'un point de vue physique, tels qu'ils sont mis en
œuvre (fichiers, bibliothèques, bases de données...)

Cours MOO Pr A. AMIRAT Page 3

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

5. Diagramme des paquetages (Package diagram) : un paquetage étant un

conteneur logique permettant de regrouper et d'organiser les éléments dans
le modèle UML, le Diagramme de paquetage sert à représenter les
dépendances entre paquetages, c’est-à-dire les dépendances entre ensembles
de définitions.

6. Diagramme de structure composite (depuis UML 2.x, cf. Composite

Structure Diagram) : permet de décrire sous forme de boîte blanche les
relations entre composants d'une classe.

Cours MOO Pr A. AMIRAT Page 4

Diagrammes comportementaux (3 diagrammes)
Les diagrammes comportementaux (Behavior Diagram) rassemblent :

1. Diagramme des cas d'utilisation (use-cases) (cf. Use Case Diagram) : il

permet d'identifier les possibilités d'interaction entre le système et les acteurs
(intervenants extérieurs au système), c'est-à-dire toutes les fonctionnalités
que doit fournir le système.

2. Diagramme états-transitions (State Machine Diagram) : permet de décrire

sous forme de machine à états finis le comportement du système ou de ses
composants.
3. Diagramme d'activité (Activity Diagram) : permet de décrire sous forme de
flux ou d'enchaînement d'activités le comportement du système ou de ses
composants.

Diagrammes d'interaction ou dynamiques (4 diagrammes)

Les diagrammes d'interaction ou dynamiques (Interaction Diagram)

rassemblent :

1. Diagramme de séquence (cf. Sequence Diagram) : représentation

séquentielle du déroulement des traitements et des interactions entre les
éléments du système et/ou de ses acteurs.

2. Diagramme de communication (depuis UML 2.x, Communication

Diagram) : représentation simplifiée d'un diagramme de séquence se
concentrant sur les échanges de messages entre les objets.
3. Diagramme global d'interaction (depuis UML 2.x, Interaction Overview
Diagram) : permet de décrire les enchaînements possibles entre les scénarios
préalablement identifiés sous forme de diagrammes de séquences (variante
du diagramme d'activité).

4. Diagramme de temps (depuis UML 2.x, Timing Diagram) : permet de

décrire les variations d'une donnée au cours du temps.

Cours MOO Pr A. AMIRAT Page 5

Les éléments de modélisation
Classe, Relation,

Objet, Lien

Association, Agrégation, Composition

Classe d’association,

L’Héritage = (Généralisation / Spécialisation)

L’Instanciation (Classe) = Objet

Abstraction

Modélisation

Package (Paquetage)

Message, message synchrone, message asynchrone,

Ligne de vie

Activité

Etat, Etat composite

Synchronisation

Débranchement

Espace de nommage

Modèle

Méta-Modèle

Cours MOO Pr A. AMIRAT Page 6

 Historique d’UML

1- Diagramme de Use Case

2- Diagramme de Classe
3- Diagramme d’Objets
4- Diagramme de Séquence
5- Diagramme d’Etat transition
6- Diagramme d’Activité
7- Diagramme de Communication (collaboration dans UML1.x)
8- Diagramme de Paquetage
============================
Diagramme de temps (depuis UML 2.x, Timing Diagram)
Diagramme global d'interaction (depuis UML 2.x, Interaction Overview)

Diagramme de déploiement (Deployment diagram)

Diagramme de structure composite (UML 2.x, Composite Structure Diagram)

Diagramme de composants (Component diagram)

Diagramme de profil (UML 2.x)

Cours MOO Pr A. AMIRAT Page 7

Contraintes OCL

Comment exprimer le faite que le solde d’un compte bancaire doit être toujours
positif ?

Compte
+NoCompte : int
- Solde : Real ; {solde > 0}

+ crediter(Real);
+ debiter(Real);
+ getSolde():Real;

1- Pourquoi OCL ?
 OCL (Object Constraint Language) est un langage formel pour
l’expression de contraintes, standardisées par l’OMG.

 Object Management Group, association américaine à but non lucratif créée

en 1989 dont l’objectif est de standardiser et promouvoir le modèle objet
sous toutes ses formes.

 OCL et UML s’utilisent conjointement.

 Les contraintes d’un système sont des informations supplémentaires

importantes qui n’ont pas pu être spécifiées à l’aide d’éléments de
modélisation UML.

 Une contrainte peut être attachée à n’importe quel élément de modèle ou

liste d’éléments de modèle,

 Une contrainte désigne une restriction qui doit être appliquée par une
implémentation correcte du système.

 Elles sont souvent exprimées en langage naturel ; cependant, l’utilisation

d’un langage non formel peut introduire des ambiguïtés.

Cours MOO Pr A. AMIRAT Page 8

  L’avantage d’OCL est de pouvoir supprimer ces ambiguïtés en se basant
sur une grammaire précise.

 Les contraintes OCL s’expriment dans le modèle, mais s’appliquent à

chacune des instances du modèle.

Remarque
OCL est langage déclaratif typé.

Il permet uniquement de comparer des instances de même type.

Cours MOO Pr A. AMIRAT Page 9

Représentation des contraintes et contraintes prédéfinies

Différentes façons sont possible pour associer une contrainte à un ou +sieurs éléments
du modèle :

 En plaçant directement la contrainte à côté d’une propriété ou d’une opération

dans un classeur ;
 En ajoutant une note associée à l’élément à contraindre ;
 En plaçant la contrainte à proximité de l’élément à contraindre, comme une
extrémité d’association par exemple ;
 En plaçant la contrainte sur une flèche en pointillés joignant les deux éléments
de modèle à contraindre ensemble, la direction de la flèche constituant une
information pertinente au sein de la contrainte ;
 En plaçant la contrainte sur un trait en pointillés joignant les deux éléments de
modèle à contraindre ensemble dans le cas où la contrainte est bijective ;
 En utilisant une note reliée, par des traits en pointillés, à chacun des éléments de
modèle, subissant la contrainte commune.

Nous venons de voir, au travers ces exemples, quelques contraintes prédéfinies

{frozen}, {subset} , {xor} , {ordered} et {addOnly}.

2- OCL permet l’expression des contraintes suivantes :

1. Les invariants au sein d’une classe ou un type : contraintes qui doivent être
toujours vérifiées pour assurer du bon fonctionnement des instances de la
classe ou du type concerné ;

2. Les contraintes au sein d’une opération : contraintes qui doivent être

toujours vérifiées pour assurer de la bonne exécution de l’opération
concernée ;

3. Le pré et post-conditions d’opération : des contraintes qui doivent être

respectivement vérifiées avant et après l’exécution d’une opération ;

4. Les gardes : contraintes sur la modification de l’état d’un objet ;

5. Les expressions de navigation : contraintes pour représenter les chemins au

sein de la structure de classe.

Cours MOO Pr A. AMIRAT Page 10

3- Le contexte
 Le contexte d'un événement inclut les circonstances et conditions qui
l'entourent ;

 le contexte d'un mot, d'une phrase ou d'un texte inclut les mots qui
l'entourent.

Chaque contrainte OCL est liée à un contexte définissant le type auquel la

contrainte se rapporte. Chaque instance d’un type doit ensuite respecter les
contraintes définies pour ce type.

Le contexte est exprimé comme suit :

<Contexte> <Stéréotype> " : " <ExpressionDeLaContrainte>

<Contexte> ::= "Context" <NomDel’ElementConcerné>

<Stéréotype> ::= inv | pre | post

Exemple :
Context Pile inv :
nb_elements >= 0

Cours MOO Pr A. AMIRAT Page 11