I.6. Présentation du language UML
1 UML et les vues
Diverses perspectives ou vues peuvent être prises en
compte dans la modélisation d'un système d'informations. Le
langage UML en a défini cinq (05) qui sont complémentaires et qui
guident l'utilisation des concepts objets : il s'agit de l'architecture 4+1
centrée sur la vue utilisateur.
1.1 La vue logique
Cette vue appelée vue de haut niveau se concentre sur
l'abstraction et l'encapsulation. C'est à ce niveau que s'effectue la
modélisation des éléments et mécanismes principaux
du système. La vue logique permet d'identifier les
éléments du domaine, ainsi que les relations et interactions
entre ces éléments : les éléments du domaine
étant le(s) métier(s) de l'entreprise. Ils sont d'une importance
capitale dans la mission future du système, ils gagnent à
être réutilisés (ils représentent un savoir-faire).
Cette vue permet aussi d'organiser, (selon des critères purement
logiques), les éléments du domaine en "catégories"
: pour répartir les tâches dans les équipes, regrouper
ce qui peut être générique, isoler ce qui est propre
à une version donnée, etc.18
1.2 La vue des composants
Cette vue de bas niveau (aussi appelée "vue de
réalisation"), montre : L'allocation des éléments de
modélisation dans des modules (fichiers sources, bibliothèques
dynamiques, bases de données, exécutables, etc.). En d'autres
termes, cette vue identifie les modules qui réalisent (physiquement) les
classes de la vue logique. Elle définit aussi l'organisation des
composants, c'est-à dire la distribution du code en gestion de
configuration, les dépendances entre les composants... Les contraintes
de développement (bibliothèques externes...). La vue des
composants montre aussi l'organisation des modules en
"sous-systèmes", les interfaces des sous-systèmes et
leurs dépendances (avec d'autres sous-systèmes ou modules).
1.3 La vue processus
Cette vue est d'une très grande importante dans les
environnements multitâches ; elle montre :
? La décomposition du système en termes de
processus (tâches);
? les interactions entre les processus (leur
communication);
18 P. Rocques & F. Vallée, UML 2 en action, de
l'analyse des besoins à la conception, éd. EYROLLES, 2007,
p45
13
> la synchronisation et la communication des activités
parallèles (threads).
1.4 La vue de déploiement
Cette vue très importante dans les environnements
distribués, décrit les ressources matérielles et la
répartition du logiciel dans ces ressources :
> la disposition et nature physique des matériels,
ainsi que leurs performances,
> l'implantation des modules principaux sur les noeuds du
réseau,
> les exigences en termes de performances (temps de
réponse, tolérance aux fautes et pannes...). 1.5 La
vue utilisateur
Cette vue (dont le nom exact est "vue des cas d'utilisation"),
guide toutes les autres. Dessiner le plan (l'architecture) d'un système
informatique n'est pas suffisant, il faut le justifier ! Cette vue
définit les besoins des clients du système et centre la
définition de l'architecture du système sur la satisfaction (la
réalisation) de ces besoins. A l'aide de scénarios et de cas
d'utilisation, cette vue conduit à la définition d'un
modèle d'architecture pertinent et cohérent. Cette vue est la
"colle" qui unifie les quatre autres vues de l'architecture. Elle motive les
choix, permet d'identifier les interfaces critiques et force à se
concentrer sur les problèmes importants.
Les diagrammes UML
UML n'est pas une méthode (une description normative
des étapes de la modélisation) : ses auteurs ont en effet
estimé qu'il n'était pas opportun de définir une
méthode en raison de la diversité des cas particuliers. Ils ont
préféré se borner à définir un langage
graphique qui permet de représenter, de communiquer les divers aspects
d'un système d'information (aux graphiques sont, bien sûr,
associés des textes qui expliquent leur contenu). UML est donc un
métalangage car il fournit les éléments permettant de
construire le modèle qui, lui, sera le langage du projet.
Il est impossible de donner une représentation
graphique complète d'un logiciel, ou de tout autre système
complexe, de même qu'il est impossible de représenter
entièrement une statue (à trois dimensions) par des photographies
(à deux dimensions). Mais il est possible de donner sur un tel
système des vues partielles, analogues chacune à une
photographie d'une statue, et dont la juxtaposition donnera une idée
utilisable en pratique sans risque d'erreur grave.
Les versions d'UML 1.x proposaient neuf (09) diagrammes.
UML 2.0 en a rajouté quatre. Ces treize types de
diagrammes représentent autant de vues distinctes pour
représenter des concepts particuliers du système d'information.
Ils se répartissent en deux grands 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)
14
> diagramme de paquetages (Package diagram)
rajouté par UML 2.0
> diagramme de structures composites (Composite
structure diagram) rajouté par UML 2.0
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)
> diagramme global d'interaction (Interaction overview
diagram) rajouté par UML 2.0
> diagramme de temps (Timing diagram)
rajouté par UML 2.0
Ces diagrammes, d'une utilité variable selon les cas,
ne sont pas nécessairement tous produits à
l'occasion d'une modélisation. Les plus utiles pour la
maîtrise d'ouvrage sont les diagrammes d'activités,
de cas d'utilisation, de classes, d'objets, de séquence
et d'états transitions. Les diagrammes de
composants, de déploiement et de communication sont
surtout utiles pour la maîtrise d'oeuvre à qui ils
permettent de formaliser les contraintes de la
réalisation et la solution technique. Dans la suite nous
allons présenter les diagrammes utilisés dans
notre modélisation.
| 
