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.
UML 2.0 propose 13 diagrammes répartis en 2 groupes :
? Diagrammes comportementaux ou diagrammes dynamiques
(UML Behavior)
Exemple : Le diagramme de cas
d'utilisation
Bien souvent, la maîtrise d'ouvrage et les utilisateurs
ne sont pas des informaticiens. Il leur faut donc un moyen simple d'exprimer
leurs besoins. C'est précisément le rôle des diagrammes de
cas d'utilisation qui permettent de recueillir, d'analyser et d'organiser les
besoins, et de recenser les grandes fonctionnalités d'un système.
Il s'agit donc de la première étape UML d'analyse d'un
système.
Un diagramme de cas d'utilisation capture le comportement
d'un système, d'un sous-système, d'une classe ou d'un composant
tel qu'un utilisateur extérieur le voit. Il scinde la
fonctionnalité du système en unités cohérentes, les
cas d'utilisation, ayant un sens pour les acteurs. Les cas d'utilisation
permettent d'exprimer le besoin des utilisateurs d'un système, ils ont
donc une vision orientée utilisateur de ce besoin au contraire d'une
vision informatique. Il ne faut pas négliger cette première
étape pour produire un logiciel conforme aux attentes des utilisateurs.
Pour élaborer les cas d'utilisation, il faut se fonder sur des
entretiens avec les utilisateurs.
Système de notification par SMS des incidents support
de NEDGE PS.
Babacar NGOM Mémoire de fin de cycle DST Page 19
? Diagrammes structurels ou diagrammes statiques
(UML Structure) ; Exemple : Le diagramme de
classe
Le diagramme de classe est considéré comme le
plus important de la modélisation orientée objet, il est le seul
obligatoire lors d'une telle modélisation.
Alors que le diagramme de cas d'utilisation montre un
système du point de vue des acteurs, le diagramme de classes en montre
la structure interne. Il permet de fournir une représentation abstraite
des objets du système qui vont interagir ensemble pour réaliser
les cas d'utilisation.
Il est important de noter qu'un même objet peut
très bien intervenir dans la réalisation de plusieurs cas
d'utilisation. Les cas d'utilisation ne réalisent donc pas une partition
des classes du diagramme de classes. Un diagramme de classes n'est donc pas
adapté (sauf cas particulier) pour détailler, décomposer,
ou illustrer la réalisation d'un cas d'utilisation particulier. Les
principaux éléments de cette vue statique sont les classes et
leurs relations association, généralisation et plusieurs types de
dépendances, telles que la réalisation et l'utilisation.
Tout au long du chapitre 2 intitulé Analyse des
besoins, nous n'utiliserons pas tous les 13 diagrammes d'UML mais uniquement
ces deux diagrammes décrits ci-haut.
