4. Langage de modélisation UML
Il nous paraît difficile d'envisager le processus 2TUP
sans recourir à UML comme support. Certes, les concepts
présentés jusqu'à présent ne sont pas
spécifiquement liés à une notation particulière.
Nous avons cependant omis de préciser le rôle central et
fondamental de la modélisation objet tout au long du
développement d'une solution logicielle. Le recours à la
modélisation est depuis longtemps une pratique indispensable au
développement, car un modèle est prévu pour anticiper les
résultats du développement. Un modèle est en effet une
abstraction du résultat, dont le but est de documenter, de
prévoir, d'étudier, de collecter ou d'estimer les
informations.26
4.1. Définition et Historique de UML
UML qui est un langage textuel et graphique a fait l'objet de
grands travaux de recherche. Il y avait de cela une quinzaine d'années,
MERISE était la méthode de conception et de développement
de système d'information, de loin là plus utilisée dans le
monde informatique. Mais de nos jours les tendances ont changé. UML se
définit comme un langage de modélisation graphique et textuel
destiné à comprendre et décrire des besoins,
spécifier et documenter des systèmes, esquisser des architectures
logicielles, concevoir des solutions et communiquer des points de vue.
La modélisation objet consiste à créer
une représentation informatique des éléments du monde
réel auxquels on s'intéresse, sans se préoccuper de
l'implémentation, ce qui signifie indépendamment d'un langage de
programmation. Il s'agit donc de déterminer les objets présents
et d'isoler leurs données et les fonctions qui les utilisent. Pour cela
des méthodes ont été mises au point. Entre 1970 et 1990,
de nombreux analystes ont mis au point des approches orientées objets,
si bien qu'en 1994 il existait plus de 50 méthodes objet. Toutefois
seules 3 méthodes ont véritablement émergé :
La méthode OMT de Rumbaugh
La méthode BOOCH'93 de Booch
La méthode OOSE de Jacobson (Object Oriented Software
Engineering) UML 1.0 est soumise à l'OMG (Object Management Group) en
janvier 1997, mais elle ne sera acceptée qu'en novembre 1997 dans sa
version 1.1, date à partir de laquelle UML devient un standard
international. UML a évolué très
26 P. roques et F.VALLEE, UML en action ; de l'analyse des
besoins à la conception en JAVA, 2ème éd EYROLLES,
2003, p22
Page 20 sur 68
rapidement ainsi respectivement en 2003 et 2004, UML 1.5 Et
UML 2.0 ont vu le jour. Plusieurs enquêtes réalisées sur
les sites dédiés au génie logiciel ont montré
qu'UML constitue le langage par excellence pour la modélisation.
En l'espace d'une poignée d'années seulement,
UML est devenu un standard incontournable. Les experts tant en analyse et
conception qu'en programmation informatique diffusent d'innombrables articles
au sujet de ce dernier et à en croire certains, utiliser les
technologies objet sans UML relève de l'hérésie. Les
concepts de base de l'approche objet sont stables, largement
éprouvés et ne datent pas d'aujourd'hui. Programmer « objet
» c'est donc 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.
Pourquoi avions-nous préféré UML comme
langage de modélisation par opposition au traditionnel cheminement
merisier au moment où l'informatique de gestion apparaît de plus
en plus comme un des éléments majeurs de la stratégie des
entreprises ?
Notre choix se fonde sur plusieurs critères. D'abord
l'émergence soudaine de UML ces dernières années. Cette
émergence se justifie par plusieurs atouts que nous ne manquerons pas de
relater dans ce mémoire. Ensuite ce choix est lié à la
complexité du système que nous devons modéliser. La
problématique que pose la mise en oeuvre d'UML est simple :
Comment passer de l'expression des besoins au déploiement du
système informatique ?
Comme nous le savons, UML n'est qu'un langage de
modélisation, ce n'est pas une méthode. En effet, UML ne propose
pas une démarche de modélisation explicitant et encadrant toutes
les étapes d'un projet, de la compréhension des besoins à
la production du code de l'application et au déploiement du
système informatique. Une méthode se doit de définir une
séquence d'étapes, partiellement ordonnées, dont
l'objectif est de produire un logiciel de qualité qui répond aux
besoins des utilisateurs dans des temps et des coûts
prévisibles.
Bien qu'UML ne soit pas une méthode, ses auteurs
précisent néanmoins qu'une méthode basée sur
l'utilisation UML doit être :
Pilotée par les cas d'utilisation :
La principale qualité d'un logiciel étant son
utilité, c'est-à-dire son adéquation avec les
besoins des utilisateurs, toutes les étapes, de la
spécification des besoins à la maintenance, doivent être
guidées par les cas d'utilisation qui modélisent justement les
besoins des utilisateurs.
Centrée sur l'architecture :
Page 21 sur 68
L'architecture est conçue pour satisfaire les
besoins exprimés dans les cas d'utilisation, mais aussi pour
prendre en compte les évolutions futures et les contraintes de
réalisation. La mise en place d'une architecture adaptée
conditionne le succès d'un développement. Il est important de la
stabiliser le plus tôt possible.
Itérative et incrémentale :
L'ensemble du problème est décomposé en
petites itérations, définies à partir des cas
d'utilisation et de l'étude des risques. Les risques majeurs et les cas
d'utilisation les plus importants sont traités en priorité. Le
développement procède par des itérations qui conduisent
à des livraisons incrémentales du système.
| 
