UML est un langage qui permet de représenter des
modèles, mais il ne définit pas le processus d'élaboration
des modèles !
Cependant, dans le cadre de la modélisation d'une
application informatique, les auteurs d'UML préconisent d'utiliser une
démarche :
· Itérative et incrémentale,
· guidée par les besoins des utilisateurs du
système,
· centrée sur l'architecture logicielle.
D'après les auteurs d'UML, un processus de
développement qui possède ces qualités devrait favoriser
la réussite d'un projet.
- Une démarche itérative et
incrémentale ?
· L'idée est simple : pour modéliser
(comprendre et représenter) un système complexe, il vaut mieux
s'y prendre en plusieurs fois, en affinant son analyse par étapes.
·Cette démarche devrait aussi s'appliquer au
cycle de développement dans Le but est de mieux maîtriser la part
d'inconnu et d'incertitudes qui caractérisent les systèmes
complexes.
- Une démarche pilotée par les besoins des
utilisateurs ?
· Avec UML, ce sont les utilisateurs qui guident la
définition des modèles :
· Le périmètre du système à
modéliser est défini par les besoins des utilisateurs (les
utilisateurs définissent ce que doit être le système).
· Le but du système à modéliser est de
répondre aux besoins de ses utilisateurs (les utilisateurs sont les
clients du système).
Les besoins des utilisateurs servent aussi de fil rouge, tout au
long du cycle de développement (itératif et incrémental)
:
· A chaque itération de la phase d'analyse, on
clarifie, affine et valide les besoins des utilisateurs.
· A chaque itération de la phase de conception et de
réalisation, on veille à la prise en compte des besoins des
utilisateurs.
25
· A chaque itération de la phase de test, on
vérifie que les besoins des utilisateurs sont satisfaits.
- Une démarche centrée sur l'architecture
?
· Une architecture adaptée est la clé de
voûte du succès d'un développement.
Elle décrit des choix stratégiques qui
déterminent en grande partie les qualités du logiciel
(adaptabilité, performances, fiabilité...).
· Ph. Kruchten propose différentes perspectives,
indépendantes et complémentaires, qui permettent de
définir un modèle d'architecture (publication IEEE, 1995).
Cette vue ("4+1") a fortement inspiré UML :
1.3.1- La vue logique.
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.
· 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.2- La vue des composants.
. Cette vue de haut niveau se concentre sur l'abstraction et
l'encapsulation, elle modélise les éléments et
mécanismes principaux du système.
· Elle identifie les éléments du domaine,
ainsi que les relations et interactions entre ces éléments : les
éléments du domaine sont liés au(x) métier(s) de
l'entreprise, *ils sont indispensables à la mission du
système,
26
1.3.3- La vue des processus.
Cette vue organise aussi (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.
1.3.4- La vue de déploiement.
Cette vue est très importante dans les environnements
multitâches ; elle montre :
· La décomposition du système en terme de
processus (tâches).
· Les interactions entre les processus (leur
communication).
· La synchronisation et la communication des
activités parallèles (threads).
1.3.5- La vue des besoins des
utilisateurs.
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.
1.4- Comment "rédiger" un modèle avec
UML ?
· UML permet de définir et de visualiser un
modèle, à l'aide de diagrammes.
· Un diagramme UML est une représentation
graphique, qui s'intéresse à un aspect précis du
modèle ; c'est une perspective du modèle, pas "le
modèle".
· Chaque type de diagramme UML possède une structure
(les types des éléments de modélisation qui le composent
sont prédéfinis).
27
· Un type de diagramme UML véhicule une
sémantique précise (un type de diagramme offre toujours la
même vue d'un système).
· 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 UML supportent l'abstraction. Leur niveau de
détail caractérise le niveau d'abstraction du modèle.
L'abstraction est un des piliers de l'approche objet.
· Il s'agit d'un processus qui consiste à identifier
les caractéristiques intéressantes d'une entité, en vue
d'une utilisation précise.
· L'abstraction désigne aussi le résultat de
ce processus, c'est-à-dire l'ensemble des caractéristiques
essentielles d'une entité, retenues par un observateur.
Avant de passer à la représentation des
diagrammes UML nous jugions nécessaire la présentation des
concepts objets puisque ces diagrammes se fondent essentiellement sur
l'approche objet.
