Chap I : Introduction à UML

I-Introduction :
L’objectif de ce cours est de vous présenter les concepts de la modélisation de systèmes informatiques, c’est-
à-dire des systèmes dans lesquels la partie logicielle est prépondérante.
Ce cours introduit donc à la modélisation de systèmes informatiques orientée objet en utilisant le langage
(graphique) UML.
L’approche orientée objet est une façon d’aborder un problème et de le découper en petits sous-problèmes.
On commence par rechercher les objets du système puis leurs interactions.

II- Concepts de base :

1- Définitions générales
 Domaine : champ d’application
 élément de modélisation: représentation d’une abstraction issue du domaine du problème
 objet:
Entité ayant une frontière et une identité bien définies qui encapsule un état et un comportement
 système: ensemble d’objets connectés et organisés pour atteindre un but spécifique
 Un modèle est une abstraction de la réalité permettant de mieux comprendre le système. C’est donc
une simplification du monde réel.
 Cycle de vie: étapes du développement d’un système informatique
 Analyse: compréhension des besoins du système
 Conception : décrit la solution (comment le problème est résolu), conception = LE-COMMENT
 Modélisation: synonyme d’analyse, et par extension, élaboration des modèles (y compris en
conception)
 Spécification: description exhaustive d’un élément de modélisation
 Diagramme: représentation graphique d’éléments de modélisation
 Notation: ensemble des signes et symboles qui composent le langage UML

2- Définition d’UML (Unified Modeling Language)

UML est un langage de modélisation objet, il permet de formaliser sous forme des diagrammes un ensemble
des concepts pouvant être utilisés durant toutes les phases d'analyse du cycle de vie du logiciel (définition des
besoins, spécification, conception générale et conception détaillée).
A la différence de MERISE qui est une méthode de modélisation avec laquelle une étude globale peut être
menée pour le cycle de vie d’un projet, UML lui n’est qu’un langage et non une méthode, il doit être
accompagné d’un processus de développement objet pour mener une étude globale.

3- Historique d’UML :
Les méthodes utilisées dans les années 1980 pour organiser la programmation impérative (Merise) étaient
fondées sur la modélisation séparée des données et des traitements.
Lorsque la programmation par objets prend de l’importance au début des années 1990, la nécessité d’une
méthode qui lui soit adaptée devient évidente. Plus de cinquante méthodes apparaissent entre 1990 et 1995
(Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE,…) mais aucune ne parvient
à s’imposer. En 1994, le consensus se fait autour de trois méthodes :
– OMT de James Rumbaugh (General Electric) fournit une représentation graphique des aspects
statique, dynamique et fonctionnel d’un système ;
– OOD de Grady Booch, définie pour le département de la défence, introduit le concept de paquetage
– OOSE d’Ivar Jacobson (Ericsson) fonde l’analyse sur la description des besoins des utilisateurs (cas
d’utilisation).
Les trois gourous qui régnaient chacun sur l’une des trois méthodes se mirent d’accord pour définir une
méthode commune qui fédérerait leurs apports respectifs (on les surnomme depuis « the Amigos »). UML est
né de cet effort de convergence. L’adjectif unified est là pour marquer qu’UML unifie, et donc remplace.

1
Le Schéma ci-dessous présente l’évolution d’UML :

4- Diagramme UML :
Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect précis du modèle.
Chaque type de diagramme UML possède une structure et véhicule une sémantique précise.
Combinés, les différents types de diagrammes UML offrent une vue complète des aspects statiques et
dynamiques d'un système. Les diagrammes permettent donc d'inspecter un modèle selon différentes
perspectives et guident l'utilisation des éléments de modélisation (les concepts objet), car ils possèdent une
structure.

III- Les différents diagrammes UML :

UML 2.3 propose 14 types de diagrammes (9 en UML 1.3) représentant autant de vues distinctes pour
Représenter des concepts particuliers du système d’information. Ils se répartissent en deux groupes :
Diagrammes structurels ou diagrammes statiques (UML Structure)
 diagramme de classes (Class diagram)
 diagramme d’objets (Object diagram)
 diagramme de composants (Component diagram)
 diagramme de déploiement (Deployment diagram)
 diagramme de paquetages (Package diagram)
 diagramme de structures composites (Composite structure diagram)

Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior)

 diagramme de cas d’utilisation (Use case diagram)
 diagramme d’activités (Activity diagram)
 diagramme d’états-transitions (State machine diagram)
 Diagrammes d’interaction (Interaction diagram)
 diagramme de séquence (Sequence diagram)
 diagramme de communication (Communication diagram)

2
  diagramme global d’interaction (Interaction overview diagram)
 diagramme de temps (Timing diagram)

Il existe des ouvrages UML qui découpe la modélisation UML en trois axes ci-dessous, à la différence du
schéma ci-dessous, l’axe dynamique est découpée en deux axes à savoir, l’axe fonctionnel et l’axe
dynamique, ci-dessous la représentation.

3
IV- Les phases de la modélisation :
Ci-dessous le schéma du cycle en V

Le schéma présente le cycle en V du développement d’un système informatique. Le cycle en V vous est déjà
familier car vous l’avez rencontré pour la programmation procédurale. Il est également utilisé en orienté
objet. L’informatisation débute par l’établissement du cahier des charges avec le client suivi de l’analyse qui
a pour but de modéliser le problème. Puis, la conception modélise la solution technique ; elle est suivie par la
réalisation du logiciel conforme à la solution.
La partie droite consiste en la vérification du logiciel construit par une série de tests et la recette par le client
du produit fini.

III- La phase d'analyse

La phase d’analyse UML se fait comme suit :
1- La description des cas d'utilisation.
2- Pour chaque cas d'utilisation, réaliser de un à n diagrammes d’interactions (les diagrammes de
séquence en premier pour statuer sur les fonctionnalités avec le client ; puis, passer aux diagrammes
de collaboration pour continuer l’analyse avec l’équipe projet).
3- À chaque diagramme de collaboration correspond une ébauche de diagramme de classes. Préciser
lors de la création d’une classe à quel package elle appartient.
4- Faire la synthèse des diagrammes de classes pour un package donné.
5- Pour chaque classe du diagramme de classes, faire un diagramme d'états-transitions (optionnel).

IV- Les apports de la modélisation visuelle :

La modélisation visuelle:
- Permet une meilleure appréhension des besoins
- Facilite la compréhension du problème
- Facilite la communication entre les personnes (client, experts du domaine, analystes, concepteurs,
...)
- Améliore la lisibilité des schémas de conception
- Prépare la documentation et les programmes
- Facilite la maintenance