~1~

1. INTRODUCTION

Pour faire face à la complexité croissante des systèmes

d’information, de nouvelles méthodes et outils ont été créées. La principale
avancée des dernières années réside dans la programmation orientée objet
(P.O.O.).

Ce module va enseigner, la façon dont nous devons utiliser

efficacement les technologies orientées objet et la modélisation du logiciel
appliqué aux processus de développement de logiciels tout en utilisant le
langage de modélisation unifié UML (Unified Modeling Language).

UML est le langage standard pour l’analyse et la conception

orientée-objet. UML est utilisé tout au long du cycle de vie de développement
de logiciel pour prendre et communiquer les décisions relatives à l’analyse et
à la conception.

Dans ce travail, vous allez vous rendre compte des avantages de

l’utilisation d’un langage de modélisation graphique, pour communiquer des
concepts, des décisions, comprendre un problème, proposer la solution
adéquate et gérer la complexité des artefacts. Ce module permettra de
comprendre les patrons et les règles qui contribueront à la création de
composants logiciels réutilisables.

2. HISTORIQUE DU LANGAGE UML

Dans le milieu des années 1990, trois méthodes ont émergé du lot.
Ces trois méthodes ont commencé à converger, à fusionner. Chaque
méthode a ses propres atouts: Booch était excellent pour la conception et la
mise en œuvre. Grady Booch avait été un acteur majeur dans le
développement des techniques orientées objet. Object Modeling Technique
(OMT) était le mieux adapté pour l’analyse des systèmes d’information à
données intensives.

Object Oriented Software Engineering (OOSE) a présenté un

modèle connu sous le nom de cas d’utilisation. Les Cas d’utilisation sont un
puissant outil pour comprendre le comportement de tout un système (un
aspect où l’OO est traditionnellement défaillant).

Fin 1997, UML est devenu une norme OMG (Object Management
Group). L'OMG est un organisme à but non lucratif, créé en 1989 à
l'initiative de grandes sociétés (HP,Sun, Unisys, American Airlines, Philips...).
Aujourd'hui, l'OMG fédère plus de 850 acteurs du monde informatique. Son
rôle est de promouvoir des standards qui garantissent l'interopérabilité entre
applications orientées objet, développées sur des réseaux hétérogènes.
 ~2~

L'OMG propose notamment l'architecture CORBA (Common Object

Request Broker Architecture), un modèle standard pour la construction
d'applications à objets distribués (répartis sur un réseau). CORBA fait partie
d'une vision globale de la construction d'applications réparties, appelée OMA
(Object Management Architecture) et définie par l'OMG. Sans rentrer dans
les détails, on peut résumer cette vision par la volonté de favoriser l'essor
industriel des technologies objet, en offrant un ensemble de solutions
technologiques non propriétaires, qui suppriment les clivages techniques.

UML a été adopté (normalisé) par l'OMG et intégré à l'OMA, car il

participe à cette vision et parce qu'il répond à la "philosophie" OMG.

3. PARTICULARITES D’UML

Il y a donc déjà longtemps que l'approche objet est devenue une

réalité. Les concepts de base de l’approche objet est stable et largement
éprouvés. De nos jours, programmer "objet", c'est Bénéficier d'une panoplie
d'outils et de langages performants. L'approche objet est une solution
technologique incontournable. Ce n'est plus une mode, mais un réflexe quasi
automatique dès lors qu'on cherche à concevoir des logiciels complexes qui
doivent "résister" à des évolutions incessantes.

Toutefois, l’approche objet n’est pas une panacée :

 Elle est moins intuitive que l'approche fonctionnelle. Malgré les

apparences, il est plus naturel pour l'esprit humain de décomposer un
problème Informatique sous forme d'une hiérarchie de fonctions
atomiques et de données, qu'en termes d’objets et d'interaction entre
ces objets. Or, rien dans les concepts de base de l'approche objet ne
dicte comment modéliser la structure objet d’un système de manière
pertinente. Quels moyens doit-on alors utiliser pour mener une
analyse qui respecte les concepts objet ? Sans un cadre
méthodologique approprié, la dérive fonctionnelle de la Conception est
inévitable...
 L'application des concepts objet nécessite une très grande rigueur. Le
vocabulaire précis est un facteur d'échec important dans la mise en
œuvre d'une approche objet (Risques d'ambiguïtés et
d'incompréhensions). Beaucoup de développeurs (même expérimentés)
ne pensent souvent objet qu'à travers un langage de programmation.
Or, les langages orientés objet ne sont que des outils qui proposent
une manière particulière d’implémenter certains concepts objet. Ils ne
valident en rien l'utilisation de ces moyens techniques Pour concevoir
un système conforme à la philosophie objet.
 ~3~

4. DEFINITION
Par définition, la modélisation est fait d’établir un modèle, en
général mathématique qui décrit un objet naturel. 1

En informatique, la modélisation objet consiste à créer un modèle

du système informatique à réaliser.2 Ce modèle représente aussi bien des
objets du mode réel que des concepts abstraits propres au métier ou au
domaine dans lequel le système sera utilisé.

Un modèle est une représentation abstraite et simplifiée (qui exclut

certains détails), d'une entité (phénomène, processus, système, etc.) du
monde réel en vue de le décrire, de l'expliquer ou de le prévoir. Modèle est
synonyme de théorie, mais avec une connotation pratique : un modèle, c'est
une théorie orientée vers l'action qu'elle doit servir.

Concrètement, un modèle permet de réduire la complexité d'un

phénomène en éliminant les détails qui n'influencent pas son comportement
de manière significative. Il reflète ce que le concepteur croit important pour
la compréhension et la prédiction du phénomène modélisé. Les limites du
phénomène modélisé dépendant des objectifs du modèle.

Voici quelques exemples de modèles :

 Modèle météorologique :

 A partir de données d'observation (satellite…), il permet de prévoir

les conditions climatiques pour les jours à venir.

 Modèle économique :

 Peut par exemple permettre de simuler l'évolution de cours

boursiers en fonction d'hypothèses macro-économiques (évolution
du chômage, taux de croissance…).

5. LE ROLE DE LA MODELISATION

Modéliser un système avant sa réalisation permet de mieux

comprendre le fonctionnement du système. C'est également un bon moyen
de maîtriser sa complexité et d'assurer sa cohérence. Un modèle est un
langage commun, précis, qui est connu par tous les membres de l'équipe et
il est donc, à ce titre, un vecteur privilégié pour communiquer.

Le modèle est enfin indispensable pour assurer un bon niveau de

qualité et une maintenance efficace. En effet, une fois mise en production,
1
Méga dictionnaire info
2
Wikipédia
 ~4~

l'application va devoir être maintenue, probablement par une autre équipe

et, qui plus est, pas nécessairement de la même société que celle ayant créé
l'application.

6. CONCEPTS DE BASE
6.1. Objet

Un objet est une instance de classe ; autrement dit une variable

dont le type est une classe.

Par exemple :

Jean est un étudiant c’est-à-dire dans la classe étudiant, Jean est une
variable ayant étudiant comme type d’où Jean est un objet.

Comme nous venons de le dire, un objet est caractérisé par

plusieurs notions :

 L'identité : l'objet possède une identité, qui permet de le distinguer

des autres objets, indépendamment de son état. On construit
généralement cette identité grâce à un identifiant découlant
naturellement du problème (par exemple un produit pourra être repéré
par un code, une voiture par un numéro de série, etc.) ;
 Les attributs : il s'agit des données caractérisant l'objet. Ce sont des
variables stockant des informations sur l'état de l'objet ;
 Les méthodes : les méthodes d'un objet caractérisent son
comportement, c'est-à-dire l'ensemble des actions (appelées
opérations) que l'objet est à même de réaliser. Ces opérations
permettent de faire réagir l'objet aux sollicitations extérieures (ou
d'agir sur les autres objets). De plus, les opérations sont étroitement
liées aux attributs, car leurs actions peuvent dépendre des valeurs des
attributs, ou bien les modifier.

Dans cette section, nous tenons à signaler que l'approche objet

rapproche les données et leurs traitements. Mais cette approche ne fait pas
que ça, d'autres concepts importants sont spécifiques à cette approche et
participent à la qualité du logiciel.

6.2. Notion de classe

Tout d'abord, introduisons la notion de classe. Une classe est un

type de données abstrait qui précise des caractéristiques (attributs et
méthodes) communes à toute une famille d'objets et qui permet de créer
(instancier) des objets possédant ces caractéristiques. Les autres concepts
 ~5~

importants qu'il nous faut maintenant introduire sont l'encapsulation,

l'héritage et l'agrégation.

Par exemple :

Etudiant est une classe

Etudiant
Nom
Post nom
Prénom
Sexe
Age
promotion

6.2.1. Encapsulation

L'encapsulation consiste à masquer les détails d'implémentation

d'un objet, en définissant une interface. L'interface est la vue externe d'un
objet, elle définit les services accessibles (offerts) aux utilisateurs de l'objet.

L'encapsulation facilite l'évolution d'une application, car elle

stabilise l'utilisation des objets : on peut modifier l'implémentation des
attributs d'un objet sans modifier son interface, et donc la façon dont l'objet
est utilisé.

L'encapsulation garantit l'intégrité des données, car elle permet

d'interdire, ou de restreindre, l'accès direct aux attributs des objets logiciel.

Par exemple

CLIENT
Nom Ici « Client »est une classe qui a comme
Post nom données : nom, post nom, prénom, sexe et tel ; du
Prénom fait qu’on ajoute les méthodes tels que acheter et
Sexe dette nous amène à l’encapsulation.
Tel
Acheter ()
Dette ()
 ~6~

6.2.2. Héritage

L'héritage est un mécanisme de transmission des caractéristiques

d'une classe (ses attributs et méthodes) vers une sous-classe. Une classe
peut être spécialisée en d'autres classes, afin d'y ajouter des caractéristiques
spécifiques ou d'en adapter certaines. Plusieurs classes peuvent être
généralisées en une classe qui les factorise, afin de regrouper les
caractéristiques communes d'un ensemble de classes.

L'héritage peut être simple ou multiple. L'héritage évite la

duplication et encourage la réutilisation.

Généralement on parle de l’héritage lorsqu’une sous classe ou

classe fille hérite de propriétés de la super classe ou classe mère.

Par exemple

a. Héritage complet

Un héritage est complet si ses classes filles n'ont aucunes

caractéristiques (attributs, méthodes, associations) propres.
 ~7~

Un héritage est presque complet si les classes filles ont des

méthodes propres, quelques attributs propres, et aucune association propre.

b. Héritage exclusif

Un héritage est exclusif si les objets d'une classe fille ne peuvent

appartenir aussi à une autre classe fille. On peut le noter avec la contrainte
sur le diagramme UML (si la classe mère est abstraite).

c. Héritage non exclusif

L'héritage non exclusif est une forme d'héritage qui exprime qu'un
objet peut appartenir à deux classes filles en même temps.

Normalement la notation UML par défaut désigne un héritage non

exclusif. Mais l'héritage exclusif étant plus commun, on conviendra plutôt
qu'un schéma UML qui ne comporte que des héritages non contraints
expriment par défaut des héritages exclusifs. Une note peut être ajoutée
précisant que tous les héritages sont exclusifs pour lever toute ambiguïté.
 ~8~

d. Héritage multiple

L'héritage multiple est une forme d'héritage qui exprime qu'une

classe fille hérite de plusieurs classes mères.

On conseillera d'ajouter une note lors de l'utilisation d'un héritage

multiple, expliquant le choix de modélisation et actant qu'il ne s'agit pas
d'une erreur. On évitera d'utiliser l’héritage multiple en modélisation de
bases de données, sauf en cas d'apport vraiment important d'expressivité. Il
est toujours possible de remplacer un héritage multiple par plusieurs
héritages simples.

6.2.3. Le polymorphisme

Le polymorphisme représente la faculté d'une méthode à pouvoir

s'appliquer à des objets de classes différentes. Le polymorphisme augmente
la généricité, et donc la qualité, du code.

Le polymorphisme est un mécanisme important dans la

programmation objet. Il permet de modifier le comportement d’une classe
fille par rapport à sa classe mère et il permet d’utiliser l’héritage comme un
mécanisme d’extension en adaptant les comportements des objets.

Type des polymorphismes :

 Le polymorphisme ad hoc (surcharge)

Une interface unique est implémentée par plusieurs routines ayant

le même identifiant, potentiellement hétérogènes c’est à dire chaque routine
ayant une combinaison différente de types pour ce paramètre, qu’elle soit
membre d’une classe ou non (routine globale).

 Le polymorphisme paramétré (générique)

Une interface unique est implémenté par une seule routine

utilisant un type générique ou au moins un de ses paramètres, que la
routine soit membre d’une classe ou non (routine globale)

 Le polymorphisme d’héritage (sous typage)

Une interface unique est implémentée pour une routine membre

ayant le même identifiant dans chaque classe faisant partie de la même
hiérarchie d’héritage.
 ~9~

6.2.4. L’agrégation

Il s'agit d'une relation entre deux classes, spécifiant que les objets
d'une classe sont des composants de l'autre classe. Une relation d'agrégation
permet donc de définir des objets composés d'autres objets. L'agrégation
permet donc d'assembler des objets de base, afin de construire des objets
plus complexes.

7. ETAPES DE LA MODELISATION

On peut identifier 3 étapes de la modélisation qui sont :

 Le modèle interprétatif
 Le modèle fonctionnel
 Le modèle physique

7.1. Le modèle interpératif

Il s’agit décrit avec ce propre mots en langage nature l’objet.

7.2. le modele fonctionnel( rechercher)

Il s’agit de la description atomique, de l’identification des éléments

unitaires et des rapports précis. Le but est de rendre le modèle interprétatif
calculable. On passe alors à la calculabilité.

7.3. Le modèle physique

On implémente le modèle fonctionnel dans une machine pour

calculer. Dans un ordinateur par exemple, qui est une machine de Turing
réel (modèle abstrait du fonctionnement des appareils mécanique de
calcules, tel qu’un ordinateur et sa mémoire).

8. NOTIONS DE BASE RELATIVES A LA MODELISATION ORIENTEE

OBJET

Un modèle orienté objet (MOO) vous aide à analyser un système

d'information par l'intermédiaire de cas d'utilisations, d'analyses
structurelles et comportementales, ainsi qu'en termes de déploiement, ce en
utilisant le langage UML (Unified Modeling Language (UML). Vous pouvez
modéliser, procéder au reverse engineering et générer pour Java .NET et
d'autres langages.
 ~ 10 ~

Quelques diagrammes UML :

 Diagramme de cas d'utilisation

 Diagrammes structurels
 Diagramme de classes ;
 Diagramme de structures composites ;
 Diagramme d'objets ;
 Diagramme de packages.
 Diagramme dynamiques
 Diagramme de communication ;
 Diagramme de séquence ;
 Diagramme d'activités ;
 Diagramme d'états-transitions ;
 Diagramme d'interactions.
 Diagrammes de mise en œuvre
 Diagramme de composants ;
 Diagramme de déploiement.
 ~ 11 ~

Dans l'illustration ci-dessous, vous pouvez voir de quelle façon les

différents diagrammes UML peuvent interagir dans votre modèle :

8.1. Diagramme de cas d'utilisation

Un diagramme de cas d'utilisation est un diagramme UML qui

fournit une représentation graphique des exigences de votre système, et vous
aide à identifier la façon dont les utilisateurs interagissent avec ce dernier.

Ce diagramme est particulièrement approprié pour décrire toutes

les tâches pouvant être réalisées à l'aide d'un système de base de données
par toutes les personnes susceptibles de l'utiliser.

Par exemple
 ~ 12 ~

Le cas d'utilisation d'un appareil photo, l'acteur "Photographe" effectue deux

actions avec son appareil : prendre des clichés et changer de pellicule. L'action
de prendre une photo implique ainsi de régler le diaphragme et la mise au
point et d'ouvrir et de refermer l'obturateur. Ces activités ne sont toutefois pas
d'un niveau suffisant pour être représentées dans un cas d'utilisation.

8.2. Diagrammes structurels

8.2.1. Diagramme de classes

Un diagramme de classes est un diagramme UML qui fournit une

représentation graphique des classes, interfaces, et packages qui composent
un système, ainsi que des relations entre eux.

Les diagrammes de classes expriment la structure statique d'un

système en termes de classes et de relations entre ces classes.

Une classe décrit un ensemble d'objets et une association décrit un

ensemble de liens. Les objets sont les instances d'une classe, et les liens
sont les instances d'une association. Un diagramme de classes n'exprime
rien de spécifique concernant les liens d'un objet particulier, mais il décrit,
de façon abstraite, le lien potentiel entre un objet et d'autres objets.

8.2.2. Diagramme de structures composites

Un diagramme de structures composites est un diagramme UML

qui fournit une représentation graphique des classes, interfaces et packages
qui composent un système, en incluant les ports et parties qui décrivent
leurs structures internes. Remarque Pour créer un diagramme de structures
composites dans un MOO existant, pointez sur le modèle dans l'Explorateur
d'objets, cliquez le bouton droit de la souris, puis sélectionnez Nouveau
Diagramme de structures composites. Pour créer un nouveau modèle,
sélectionnez Fichier Nouveau modèle, choisissez Modèle Orienté Objet
comme type de modèle et Diagramme de structures composites comme
premier diagramme.
 ~ 13 ~

Un diagramme de structure composite joue le même rôle qu'un

diagramme de classes, mais permet d'approfondir la description de la
structure interne de plusieurs classes et la représentation des interactions
entre ces classes. Vous pouvez représenter de façon graphique les classes
internes et les parties et montrer les associations à la fois entre et au sein
des classes.

8.2.3. Diagramme d'objets

Un diagramme d'objets est un diagramme UML qui fournit une

représentation graphique de la structure d'un système via des instances
concrètes de classes (objets), d'associations (liens entre objets), et de
dépendances.

Le diagramme d'objets peut être utilisé à des fins d'analyse : les

contraintes entre classes qui ne sont pas classiquement représentées dans
un diagramme de classes peuvent par contre être représentées dans un
diagramme d'objets. Si vous ne disposez pas encore de connaissances
approfondies dans le domaine de la modélisation objet, l'utilisation
d'instances est probablement plus "parlante" pour vous que celles de
classificateurs, dans la mesure où les classificateurs représentent un certain
degré d'abstraction.

Par exemple

Le diagramme de classes spécifie qu'une classe Auteur est liée à une classe
Document. Dans le diagramme d'objets déduit de ce diagramme de classes,
l'accent est mis sur les détails suivants : l'objet nommé Jean, instance de la
classe Auteur est liée à deux objets différents (Brouillon et Final) qui sont deux
instances de la classe Document.
 ~ 14 ~

8.2.4. Diagramme de packages

Un diagramme de packages est un diagramme UML qui fournit une

représentation graphique de haut niveau de l'organisation de votre
application, et vous aide à identifier les liens de généralisation et de
dépendance entre les packages.

Vous pouvez contrôler le niveau de détail fourni pour chaque

package, en alternant les vues standard et composite grâce aux commandes
du menu Edition ou des menus contextuels.

Dans l'exemple suivant, le package WebShop importe le package

Cart qui, à son tour, importe le package Types et a accès au package
Auxiliary. Le package Types est montré en vue composite (sous-diagramme) :
 ~ 15 ~

8.3. Diagramme dynamiques

Les diagrammes décrits dans ce chapitre permettent de modéliser

le comportement dynamique de votre système, et d'indiquer comment ses
objets interagissent au moment de l'exécution. PowerDesigner propose
quatre types de diagrammes pour la modélisation de cet aspect de votre
système.

8.3.1. Diagramme de communication

Un diagramme de communication qui représente un cas

d'utilisation particulier ou une fonctionnalité du système en termes
d'interactions entre des objets, tout en se focalisant sur la structure de
l'objet. Pour plus d'informations.

Un diagramme de communication est un diagramme UML qui

fournit une représentation graphique des interactions entre les objets d'un
scénario de cas d'utilisation, l'exécution d'une opération, ou une interaction
entre des classes, en mettant l'accent sur la structure du système.

Vous pouvez utiliser un ou plusieurs diagrammes de

communication pour mettre en scène un cas d'utilisation ou pour identifier
toutes les possibilités d'un comportement complexe.

Ce diagramme véhicule le même genre d'information qu'un

diagramme de séquence, à ceci près qu'il se concentre sur la structure des
objets au lieu de la chronologie des messages qu'ils échangent. Un
diagramme de communication montre des acteurs, des objets (instances de
classes) et leurs liens de communication (appelés liens entre objets), ainsi
que les messages qu'ils échangent. Les messages sont définis sur des liens
entre objets qui correspondent à un lien de communication entre deux objets
 ~ 16 ~

qui interagissent. L'ordre dans lequel les messages sont échangés est
représenté par les numéros d'ordre.

a. Analyse d'un cas d'utilisation

Un diagramme de communication peut être utilisé pour affiner le

comportement ou la description d'un cas d'utilisation. Cette approche est
utile lors de l'analyse des besoins car elle peut aider à identifier des classes
et associations qui ne s'étaient pas imposées immédiatement. Vous pouvez
formaliser l'association entre le cas d'utilisation et le diagramme de
communication en ajoutant le diagramme dans l'onglet Diagrammes
associés de la feuille de propriétés du cas d'utilisation.

Il est souvent nécessaire de créer plusieurs diagrammes afin de

décrire tous les scénarios possibles d'un cas d'utilisation. Dans ce cas de
figure, il peut être utile d'utiliser les diagrammes de communication pour
découvrir tous les objets pertinents avant de tenter d'identifier les classes
qui vont les instancier. Une fois ces classes identifiées, vous pouvez ensuite
déduire les associations entre elles grâce aux liens entre objets.

La principale difficulté de cette approche consiste à identifier les

objets appropriés afin de transcrire les pas d'action du cas d'utilisation. Une
extension d'UML, "Robustness Analysis" peut simplifier ce processus. Cette
méthode préconise de séparer les objets en 3 types :

 Les objets Boundary sont utilisés par les acteurs lorsqu'ils

communiquent avec le système, il peut s'agir de fenêtres, d'écrans, de
boîtes de dialogue ou de menus ;
 ~ 17 ~

 Les objets Entity représentent des données stockées telles qu'une base
de données, des tables de base de données ou tout type d'objet
temporaire tel qu'un résultat de recherche ;
 Les objets Control sont utilisés pour contrôler les objets Boundary et
Entity, et qui représentent un transfert d'informations.

Exemple
Création d'extensions de diagramme de robustesse.
8.3.2. Diagramme de séquence

Un diagramme de séquence qui représente un cas d'utilisation

particulier ou une fonctionnalité du système en termes d'interactions entre
des objets, tout en se focalisant sur l'ordre chronologique des messages
échangés. Pour plus d'informations.

Un diagramme de séquence est un diagramme UML qui fournit une

représentation graphique de la technologie d'échange de messages entre des
objets et des acteurs pour un cas d'utilisation, l'exécution d'une opération,
ou une interaction des classes, en mettant l'accent sur leur chronologie.

Vous pouvez utiliser un ou plusieurs diagrammes de séquence

pour mettre en scène un cas d'utilisation ou pour identifier toutes les
possibilités d'un comportement complexe. Un diagramme de séquence
montre des acteurs, des objets (instances de classes) et les messages qu'ils
échangent. Il véhicule le même genre d'informations qu'un diagramme de
communication, à ceci près qu'il se concentre sur la chronologie des
messages échangés entre les objets plutôt que sur la structure des objets.

Un fragment d'interaction gère diverses possibilités de vérifier la

commande. L'objet Compte et l'auteur Responsable peuvent interagir avec la
commande en fonction de sa taille. Une fois le message Confirmer
commande envoyé, l'interaction Traiter commande est initiée.

a. Analyse d'un cas d'utilisation

Un diagramme de séquence peut être utilisé pour affiner le

comportement ou la description d'un cas d'utilisation. Cette approche est
utile lors de l'analyse des besoins car elle peut aider à identifier des classes
et associations qui ne s'étaient pas imposées immédiatement.

Il est souvent nécessaire de créer plusieurs diagrammes afin de

décrire tous les scénarios possibles d'un cas d'utilisation. Dans ce cas de
figure, il peut être utile d'utiliser les diagrammes de séquence pour découvrir
tous les objets pertinents avant de tenter d'identifier les classes qui vont les
 ~ 18 ~

instancier. Une fois ces classes identifiées, vous pouvez ensuite déduire les
associations entre elles grâce aux liens entre objets.

b. Analyse d'un diagramme de classe

La construction d'un diagramme de séquence peut également être

l'opportunité de tester un modèle statique pendant la conception ; il peut
représenter un scénario dans lequel les classes du diagramme de classes
sont instanciées pour créer les objets nécessaires à l'exécution du scénario.

Il complète le diagramme de classes qui représente la structure

statique d'un système en spécifiant le comportement des classes et
interfaces ainsi que l'utilisation possible de leurs opérations.

Un diagramme de séquence permet d'analyser des opérations de

classe avec plus de précision qu'un diagramme de communication. Vous
pouvez créer une opération dans la classe d'un objet qui reçoit un message
par le biais de la feuille de propriétés du message. Vous pouvez également
effectuer une telle tâche dans un diagramme de communication, mais il y a
plus d'espace dans un diagramme de séquence pour afficher des
informations détaillées (arguments, valeur de résultat, etc.) relatives à
l'opération.

8.3.3. Diagramme d'activités

Un diagramme d'activités qui représente un cas d'utilisation

particulier ou une fonctionnalité du système en termes d'actions ou
d'activités effectuées et de transitions déclenchées par l'accomplissement de
ces actions. Il permet également de représenter des branches
conditionnelles. Pour plus d'informations.

Un diagramme d'activités est un diagramme UML qui fournit une

représentation graphique du comportement d'un système, et vous aide à le
décomposer de façon fonctionnelle afin d'analyser sa mise en œuvre.

a. Modélisation orientée objet Construction de MOO

Alors qu'un diagramme d'états-transitions se focalise sur la mise

en œuvre des opérations dans lesquelles la plupart des événements
correspondent précisément à la fin de l'activité précédente, le diagramme
d'activités ne fait pas la distinction entre les états, les activités et les
événements.

Le diagramme d'activités donne une représentation simplifiée d'un

processus, en montrant les flux de contrôle (appelés transitions) entre les
actions effectuées dans le système (appelées activités). Ces flux représentent
 ~ 19 ~

le comportement interne d'un élément de modèle (cas d'utilisation, package,

classificateur ou opération) depuis un point de début jusqu'à plusieurs
points de fin potentiels.

Vous pouvez créer plusieurs diagrammes d'activités dans un

package ou dans un modèle. Chacun de ces diagrammes est indépendant et
définit un contexte isolé dans lequel l'intégrité des éléments peut être
vérifiée.

b. Analyse d'un cas d'utilisation

Un diagramme d'activités est fréquemment utilisé pour décrire de

façon graphique un cas d'utilisation. Chaque activité correspond à une étape
d'action et les points d'extension peuvent être représentés comme des
branches conditionnelles.

Au-delà de la modélisation orientée objets, les diagrammes

d'activité sont de plus en plus souvent utilisés pour modéliser les aspects
 ~ 20 ~

métiers de l'entreprise. Ce type de modélisation se produit avant la

modélisation UML classique d'une application, et permet l'identification des
processus importants de l'entreprise et les domaines de responsabilité pour
chaque unité organisationnelle au sein de l'entreprise.

8.3.4. Diagramme d'états-transitions

Un diagramme d'états-transitions est un diagramme UML qui

fournit une représentation graphique d'une State Machine, le comportement
public d'un classificateur (composant ou classe), sous la forme des
changements de l'état du classificateur et des événements qui permettent la
transition d'un état à l'autre.

Le classificateur est censé avoir déjà été identifié dans un autre

diagramme et tous ses états doivent pouvoir être répertoriés. A la différence
des autres diagrammes d'interaction, le diagramme d'états-transitions peut
représenter une spécification complète des scénarios possibles appartenant
au classificateur. A un moment donné, l'objet doit être dans l'un des états
définis.

Vous pouvez créer plusieurs diagrammes d'états-transitions pour

le même classificateur, mais alors les états et les transitions représentés
doivent être liés à différents aspects de son évolution. Par exemple, une
personne peut être considérée d'un côté comme se déplaçant entre les états
étudiant, travailleur, sans emploi et en retraite, et de l'autre étant
successivement célibataire, fiancé, marié et divorcé.

Les diagrammes d'états-transitions montrent le comportement du

classificateur via des règles d'exécution qui expliquent précisément de quelle
façon les actions sont exécutées lors des transitions entre les différents états
; ces états correspondent aux différentes situations se produisant lors de la
vie du classificateur.
 ~ 21 ~

L'exemple ci-dessus montre les états d'un jeu d'échecs.

Un diagramme d'états-transitions requiert l'identification préalable

d'un classificateur. Il peut être utilisé pour décrire le comportement du
classificateur, et vous aide également à découvrir ses opérations via la
spécification des actions associées aux événements d'états-transitions.

8.3.5. Diagramme d'interactions

Un diagramme d'interactions est un diagramme UML qui fournit

une représentation graphique de haut niveau du flux de contrôle de votre
système alors que ce dernier est décomposé en diagrammes de séquence et
autres diagrammes d'interactions.

Par exemple :

Un flux de contrôle lie deux diagrammes de séquence

a. Références d'interaction et activités d'interaction (MOO)

Les références d'interaction et permettent représenter un

diagramme de séquence dans le corps d'un autre et de modulariser et de
réutiliser des interactions couramment utilisées sur une plage de
diagrammes de séquence. Les activités d'interaction permettent de
représenter un diagramme de séquence, un diagramme de communication
ou un diagramme d'interactions dans un diagramme d'interactions.

b. Propriétés d'une référence d'interaction ou d'une activité

d'interaction

Vous pouvez modifier les propriétés d'un objet à partir de sa feuille

de propriétés. Pour afficher la feuille de propriétés d'une référence ou activité
d'interaction, double-cliquez sur son symbole dans le diagramme, en
prenant soin de pointer sur l'étiquette d'opérateur, dans l'angle supérieur
gauche. L'onglet Général contient les propriétés suivantes :
 ~ 22 ~

8.4. Diagrammes de mise en œuvre

8.4.1. Diagramme de composants

Un diagramme de composants est un diagramme UML qui fournit

une représentation graphique des dépendances et des généralisations entre
composants logiciels, en incluant les composants de code source, les
composants de code binaire et les composants exécutables.

L'exemple suivant représente les relations entre les composants dans un

système de réservation de salle de conférence :

Les diagrammes de composants sont utilisés pour définir les

dépendances et relations entre objets à un niveau supérieur à celui du
diagramme de classes.

Les composants doivent être conçus de façon à pouvoir être

réutilisés pour plusieurs applications distinctes, ils doivent être étendus
sans mettre en péril la pérennité des applications existantes.

Vous pouvez utiliser les diagrammes de composants pour

modéliser la structure du logiciel, et pour montrer les dépendances entre le
 ~ 23 ~

code source, le code binaire et les composants exécutables, de sorte que

l'impact d'une modification puisse être évalué.

Un diagramme de composants est très utile lors de l'analyse et de

la conception. Il permet aux analystes et aux chefs de projet de spécifier les
composants dont ils ont besoin avant de les faire développer et mettre en
œuvre. Le diagramme de composants met à votre disposition une
représentation des composants et simplifie leur conception, leur
développement et leur maintenance, mais facilite également le déploiement,
l'identification et la recherche des composants du côté serveur.

8.4.2. Diagramme de déploiement

Le diagramme de déploiement fournit une vue des nœuds reliés par

des liens de communication. Ce diagramme permet de modéliser des nœuds,
des objets fichier associés aux nœuds qui sont utilisés pour le déploiement,
et les relations entre les nœuds. Les nœuds contiennent des instances de
composant qui peuvent être déployées dans et exécuté sur des serveurs de
base de données, des serveurs d'applications ou des serveurs Web.

Les diagrammes de déploiement sont utilisés pour le déploiement

effectif des composants sur des serveurs. Un déploiement représente la
possibilité d'utiliser des instances.

Vous pouvez utiliser le diagramme de déploiement pour établir le

lien avec l'architecture physique. Il est particulièrement approprié pour
modéliser les topologies en réseau,

Par exemple, vous pouvez construire un diagramme de déploiement

pour représenter les types de vues suivants, depuis une architecture de haut
 ~ 24 ~

niveau qui décrit les ressources matérielles ainsi que la distribution du

logiciel dans ces ressources jusqu'au déploiement complet sur un serveur :

 Identification de l'architecture système : utiliser les nœuds et

associations de noeuds uniquement.
 Identification du lien entre le logiciel et le matériel : utiliser les
instances de composant, gérer leur acheminement, identifier et
sélectionner les serveurs.
 Déploiement des composants sur des serveurs : inclure certains
détails et ajouter des paramètres physiques.
 ~ 25 ~

TABLE DES MATIERES

1. INTRODUCTION.....................................................................................................................1
2. HISTORIQUE DU LANGAGE UML.................................................................................1
3. PARTICULARITES D’UML..................................................................................................2
4. DEFINITION..............................................................................................................................3
5. LE ROLE DE LA MODELISATION..................................................................................3
6. CONCEPTS DE BASE..........................................................................................................4
6.1. Objet.................................................................................................4
6.2. Notion de classe................................................................................4
6.2.1. Encapsulation................................................................................5
6.2.2. Héritage.........................................................................................6
a. Héritage complet..................................................................................6
b. Héritage exclusif..................................................................................7
c. Héritage non exclusif............................................................................7
d. Héritage multiple.................................................................................8
6.2.3. Le polymorphisme..........................................................................8
6.2.4. L’agrégation....................................................................................9
7. ETAPES DE LA MODELISATION....................................................................................9
7.1. Le modèle interpératif......................................................................................................9
7.2. Le modèle fonctionnel......................................................................................................9
7.3. Le modèle physique..........................................................................................................9
8. NOTIONS DE BASE RELATIVES A LA MODELISATION ORIENTEE
OBJET.........................................................................................................................................9
8.1. Diagramme de cas d'utilisation.................................................................................11
8.2. Diagrammes structurels...............................................................................................12
8.2.1. Diagramme de classes..................................................................12
8.2.2. Diagramme de structures composites...........................................12
8.2.3. Diagramme d'objets......................................................................13
8.2.4. Diagramme de packages...............................................................14
8.3. Diagramme dynamiques...............................................................................................15
8.3.1. Diagramme de communication.....................................................15
a. Analyse d'un cas d'utilisation.............................................................16
 ~ 26 ~

8.3.2. Diagramme de séquence...............................................................17

a. Analyse d'un cas d'utilisation.............................................................17
b. Analyse d'un diagramme de classe.....................................................18
8.3.3. Diagramme d'activités..................................................................18
a. Modélisation orientée objet Construction de MOO..............................18
b. Analyse d'un cas d'utilisation.............................................................19
8.3.4. Diagramme d'états-transitions.....................................................20
8.3.5. Diagramme d'interactions............................................................21
a. Références d'interaction et activités d'interaction (MOO)....................21
b. Propriétés d'une référence d'interaction ou d'une activité d'interaction
21
8.4. Diagrammes de mise en œuvre.................................................................................22
8.4.1. Diagramme de composants..........................................................22
8.4.2. Diagramme de déploiement..........................................................23