UML (Unified Modeling Language, « langage de
modélisation objet unifié » en français) est un
langage de description standard intégrant les avantages des
différentes méthodes composantes (ainsi que celles d'autres
analystes). Il a été normalisé par l'OMG en 1997.
Rapidement devenu un standard incontournable, il donne une définition
plus formelle à l'approche objet et lui apporte la dimension
méthodologique qui lui faisait défaut.
Les créateurs d'UML ont tenu à ce qu'il tire le
meilleur profit de ses principales méthodes composantes dont les
caractéristiques suivantes sont confirmées :
· OOSE : expressive pour l'analyse des besoins grâce
aux « cas d'utilisation » ;
· OMT : expressive pour l'analyse et la conception de
systèmes à base de données ;
· Booch : expressive durant les phases de design et
d'implantation des projets.
UML opte pour l'élaboration des modèles
plutôt que pour une approche qui impose une barrière stricte entre
analyse et conception : les modèles des deux activités ne
diffèrent que par leur niveau de détail, il n'y a pas de
différence dans les concepts utilisés.
Il n'introduit pas d'éléments de
modélisation propres à une activité : le langage reste le
même à tous les niveaux d'abstraction. L'élaboration
encourage une approche non linéaire facilitant les retours en
arrière entre niveaux d'abstraction différents.
Cependant, notons que UML a été construite afin
de standardiser les artéfacts de développement (modèles,
notation, diagrammes) sans pour autant standardiser la démarche, le
processus de développement. De ce fait, UML est une notation, un langage
qui permet de
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 38
représenter des modèles mais il ne définit
pas leur processus d'élaboration. En résumé, c'est
un formalisme et pas une méthode.
? Démarche préconisée
Les concepteurs d'UML préconisent l'utilisation d'une
démarche qui soit :
- itérative et incrémentale,
- guidée par les besoins des utilisateurs du
système,
- centrée sur l'architecture logicielle.
* Itérative et incrémentale
Il est évident que, pour modéliser (comprendre et
représenter) un système
complexe, il vaut mieux procéder à une
étude par étapes. Cette démarche devrait aussi
s'appliquer au cycle de développement dans son ensemble,
en favorisant le prototypage.
Le but est de mieux maîtriser la part d'inconnu et
d'incertitudes des systèmes. Si
l'itératif s'est imposé, c'est parce qu'il
réduit la complexité de réalisation des phases, en
travaillant par approches successives et incrémentales. Il
est alors possible de présenter
rapidement aux utilisateurs des éléments de
validation. Chaque incrément ajoute de nouvelles
fonctionnalités. La difficulté réside dans
le fait de combiner au final les sous projets ou
incréments et de respecter leurs interdépendances
et la cohérence générale du produit
envisagé.
* Guidée par les besoins des utilisateurs
L'utilisateur est l'acteur principal lors de la
définition des modèles. L'objectif étant de
répondre aux besoins des utilisateurs du système
à concevoir, leurs besoins tracent les limites
et contours du futur système. Somme toute, ils
déterminent sa nature.
Lors du cycle de développement, tout reste basé
sur les exigences des utilisateurs :
- à la phase d'analyse, les besoins sont
clarifiés, affinés et validés ;
- lors de conception et de réalisation, on veille
à la prise en compte des besoins ;
- à la phase de test, on vérifie que les besoins
sont satisfaits.
* Centrée sur l'architecture logicielle
Une architecture adaptée garantit le succès d'un
développement. Elle décrit des choix
stratégiques qui déterminent en grande partie la
qualité du logiciel (adaptabilité,
performances, fiabilité, etc.). Kruchten1
propose différentes perspectives indépendantes et
1 Model de Kruchten d'après Philippe Kruchten
: model adopté dans le processus unifié
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 39
complémentaires qui définissent un
modèle d'architecture. Cette vue (« 4+1 ») a fortement
inspiré UML :
Vue comportement Vue déploiement
Vue logique
Vue utilisateur
Vue implémentation
Figure 3.1 : Vue 4+1 définie par
Kruchten
La vue logique se concentre sur
l'abstraction et l'encapsulation. Elle modélise les mécanismes
principaux du système, identifie les éléments du domaine
et les liens qui les unissent. C'est la définition du système vue
de l'intérieur. Elle explique comment peuvent être satisfait les
besoins des acteurs. Il s'agit du « comment ».
La vue des composants montre l'allocation
des éléments de modélisation dans des modules (fichiers
sources, bibliothèques dynamiques, bases de données,
exécutables, etc.). Elle identifie les modules qui réalisent
physiquement les classes de la vue logique. Elle renseigne sur l'organisation
des composants et leurs dépendances. Elle montre aussi l'organisation
des modules en sous systèmes.
La vue des processus est la vue temporelle
et technique. Elle montre la décomposition du système en termes
de processus, les interactions entre les processus (communication), la
synchronisation des activités parallèles.
La vue de déploiement décrit
les ressources matérielles et la répartition du logiciel dans ces
ressources. Elle précise la disposition, la nature physique et les
performances des ressources ainsi que l'implantation des modules principaux sur
les noeuds du réseau et les exigences en termes de performance.
La vue des besoins des utilisateurs guide
toutes les autres vues et les unifient. Elle définit les besoins des
clients et centre la définition de l'architecture du système sur
la satisfaction 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. Elle motive les choix et force à
se concentrer sur les problèmes importants. Il s'agit du « qui
» et du « quoi ».
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 40
? Les diagrammes UML
UML 2.0 comporte ainsi treize types de diagrammes
représentant 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
(diagramme de classes, d'objets, de composants, de déploiement,
de paquetages, de structures composites)
- Diagrammes comportementaux ou diagrammes dynamiques
(diagramme de cas d'utilisation, d'activités,
d'états-transitions, d'interaction, de séquence,
de communication, global d'interaction et de temps)
Ces diagrammes, d'une utilité variable selon les cas,
ne sont pas nécessairement tous produits à l'occasion d'une
modélisation.
? Diagramme de cas d'utilisation
Le diagramme de cas d'utilisation représente la
structure des grandes fonctionnalités nécessaires aux
utilisateurs du système. C'est le premier diagramme du modèle
UML, celui où s'assure la relation entre l'utilisateur et les objets que
le système met en oeuvre.
? Diagramme de classes
Le diagramme de classes est généralement
considéré comme le plus important dans un développement
orienté objet. Il représente l'architecture conceptuelle du
système : il décrit les classes que le système utilise,
ainsi que leurs liens, que ceux-ci représentent un emboîtage
conceptuel (héritage) ou une relation organique (agrégation).
? Diagramme de séquences
Les diagrammes de séquences permettent de
représenter des collaborations entre objets selon un point de vue
temporel, on y met l'accent sur la chronologie des envois de messages. Les
diagrammes de séquences peuvent servir à illustrer un cas
d'utilisation.
? Diagrammes d'activités
UML permet de représenter graphiquement le
comportement d'une méthode ou le déroulement d'un cas
d'utilisation, à l'aide de diagrammes d'activités (une variante
des diagrammes d'états transitions). Une activité
représente une exécution d'un mécanisme, un
déroulement d'étapes séquentielles. Le passage d'une
activité vers une autre est matérialisé par une
transition.
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 41
Nous allons, dans le chapitre analyse et conception du
système, utiliser certains de ces diagrammes pour analyser puis
concevoir une solution qui réponde effectivement aux exigences de notre
système.
UML n'étant pas une méthode, sa norme a
été décrite en même temps qu'une méthode
générique d'analyse et de conception des systèmes
logiciels : le Processus Unifié. Synthèse de nombreuses
méthodes et notations, le couple UML et Processus Unifié propose
une approche pour conduire la réalisation de systèmes
orientés objet depuis les spécifications jusqu'au
déploiement. Aujourd'hui, il est à la base de nombreuses
méthodes de travail utilisées dans les entreprises
réalisant des logiciels. Nous allons nous appesantir sur cette
méthode dite générique qui sera la nôtre.
