Chapitre III MODELISATION DU SYSTEME D'INFORMATION
EN UML
III.1. INTRODUCTION14
La description de la programmation par objets a fait ressortir
l'étendue du travail conceptuel nécessaire : définition
des classes, de leurs relations, des attributs et méthodes, des
interfaces, etc.
Pour programmer une application, il ne convient pas de se
lancer tête baissée dans l'écriture du code : il faut
d'abord organiser ses idées, les documenter, puis organiser la
réalisation en définissant les modules et étapes de la
réalisation. C'est cette démarche antérieure à
l'écriture que l'on appelle modélisation ; son produit est un
modèle.
Les spécifications fournies par la maîtrise
d'ouvrage en programmation impérative étaient souvent floues :
les articulations conceptuelles (structures de données, algorithmes de
traitement) s'exprimant dans le vocabulaire de l'informatique, le modèle
devait souvent être élaboré par celle-ci. L'approche objet
permet en principe à la maîtrise d'ouvrage de s'exprimer de
façon précise selon un vocabulaire qui, tout en transcrivant les
besoins du métier, pourra être immédiatement compris par
les informaticiens.
En principe seulement, car la modélisation demande aux
maîtrises d'ouvrage une compétence, un professionnalisme qui ne
sont pas aujourd'hui répandus.
UML n'est pas une méthode (càd. 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
14 BIRINDWA RWAMIHIGO Rodrigue, « Conception,
réalisation et administration d'un système d'information pour la
gestion de paie du personnel base en architecture client/serveur dans une
société de gardiennage, cas de HDW/Nord-Kivu»
Mémoire, Inédit, 2012-2013, ISC-Goma
36
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.
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 (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)
- diagramme global d'interaction (Interaction overview
diagram)
- diagramme de temps (Timing diagram)
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.
37
| 
