Le diagramme, expression des fonctions du programme informatique

Un Modèle exprimé doit décrire complètement le contenu fonctionnel d’un programme informatique. Le langage UML, bien adapté à la technologie objet, définit sur ce modèle des vues graphiques, ou diagrammes, qui doivent être complétées par une documentation en langage naturel.

La réalisation du modèle doit progresser par étapes caractérisées chacune par la confection d’un diagramme, la démarche procédant par enrichissement progressif selon un ordre « top down ».

Il ne convient pas de bousculer l’ordre des étapes : il ne faut pas se lancer dans la Modélisation proprement dite sans disposer de l’expression de besoin, ni documenter les cas d’utilisation avant d’avoir produit le diagramme d’activité etc. Chaque étape de la démarche doit avoir été réalisée entièrement avant que l’on ne passe à la suivante : l’une des erreurs les plus courantes en modélisation est de s’engouffrer de façon précoce dans des travaux détaillés qu’il faudra détricoter par la suite.

Il est nécessaire d’associer plusieurs techniques informelles et formelles pour saisir les diverses facettes d’un problème sans le dénaturer, puis pour le détailler dans un modèle central que l’on pourra préciser et modifier jusqu’à l’implémentation. L'utilisation conjointe de ces diverses techniques permet de s'adresser à des interlocuteurs qui diffèrent tant par la forme de leur intuition que par le niveau de visibilité et de lecture des modèles.

Il se peut que les contraintes que l’on découvre lors de la réalisation de l’étape n de la démarche obligent à réviser les résultats des étapes antérieures. Ainsi, alors que la démarche doit progresser sans que l'on n'anticipe le travail à faire dans les étapes ultérieures, elle ne peut pas exclure les retours en arrière.

Il faut d'abord réviser l’étape la plus en amont parmi celles qui sont à revoir, puis revenir vers l’aval jusqu’à l’étape en cours. Un modèle bien fait facilite ces révisions : si la documentation est correcte, si les outils facilitent la cohérence entre les diverses étapes, si le modèle est convenablement modulaire, le travail nécessaire aux révisions reste raisonnable.

Chaque étape aboutit à un « livrable » spécifique qui doit être dûment validé, ce qui évite l’effet de tunnel dans la modélisation.

Une fois l’expression des besoins précisée et validée, il convient d’établir en premier le dictionnaire du domaine considéré ; ensuite, une Approche Systémique en fournit une vue globale. La définition des modèles conceptuels peut accompagner la modélisation des Processus métier, enrichie par la prise en compte des règles de gestion. Enfin, les cas d’utilisation détaillent ce que le modèle doit effectuer au sein du système global.

   Les différentes étapes d'un projet de modélisation

Expression du besoin

Toute modélisation informatique doit partir d’une expression de besoin écrite, claire, validée par les responsables. Elle servira de référence tout au long de la réalisation du projet.

La première formulation de l’expression de besoin est trop souvent inadéquate : le client dit qu’il a besoin de telle et telle fonctionnalité, alors qu’il faudrait qu’il expliquât ce qu’il a l’intention de faire, qu’il décrivît l’action qu’il s’agit de réaliser.

Lorsque l’expression de besoin part comme il se doit d’une action, elle comporte naturellement la description d’un processus : toute action se ramène en effet à un processus (plus ou moins complexe et ramifié) selon lequel, partant d’une situation initiale ou input, et par l’application de certaines ressources, on aboutit à un résultat ou output.

L’expression de besoin doit essentiellement décrire l’input et l’output, la définition des ressources relevant le plus souvent d’une étape ultérieure.

Il faut dire aussi ce qu’il conviendrait de faire en cas de défaillance : la modélisation du processus doit comporter la description des cas de panne et des solutions à adopter en régime dégradé.

Dictionnaire

Le dictionnaire rassemble les définitions des termes relatifs au système considéré. On doit être tolérant lors du recueil de la terminologie du métier et accepter de noter les homonymes et synonymes qui coexistent dans l’organisation. Cependant la construction du modèle apportera une réduction terminologique, en n’associant plus qu’un nom et un seul à une même chose ou à un même concept : l'amélioration du vocabulaire est l’un des apports de la modélisation.

Approche systémique

Il est utile de produire un schéma général, validé par les acteurs, mettant en évidence les structures de l’entreprise impliquées, leurs responsabilités et leur mode de coopération. La notion de « flot d’information » introduite dans UML 2.0 est ici utile.

Règles métier

La notion de « contrainte » dans UML permet de modéliser des règles de gestion qui autorisent, provoquent ou empêchent le déroulement d’un processus (exemples : « une direction départementale ne doit pas comporter plus de dix agences », « un client ne peut commander via le Web que s’il a été enregistré au préalable », « un employé marié ne doit être muté qu’en dernier recours » etc.)

Modélisation du processus

Décrire un processus, c’est décrire l’événement qui le déclenche, les étapes (ou activités) par lesquelles il doit passer, les ressources qu’il doit consommer et l’événement final auquel il doit aboutir. Ces informations sont rassemblées et documentées dans le diagramme d’activité : il décrit la succession des activités, les messages qu’elles échangent, les éventuels sous-processus et les livrables intermédiaires que ceux-ci fournissent.

Cas d’utilisation

L’étape suivante consiste à décrire les cas d’utilisation, chaque activité en comportant un ou plusieurs. Un cas d’utilisation regroupe des opérations que l’acteur exécute et qui forment un ensemble cohérent : recevoir des messages, consulter des données ou du texte, saisir des données ou du texte, lancer des traitements, envoyer des messages. On a défini le cas d’utilisation lorsque on l’a nommé et désigné par sa finalité au sein de l’activité, on a décrit son contenu en définissant les données consultées, saisies ou traitées, la nature des traitements, les messages échangés, on a identifié les composants applicatifs qu'il met en oeuvre au sein du système informatique.

Il arrive que des cas d’utilisation divers comportent des éléments semblables, ou qu’ils soient des cas particuliers de cas d’utilisation plus généraux : on peut alors définir une hiérarchie de cas d’utilisation qui, par abstraction, simplifie le modèle : c’est le diagramme des cas d’utilisation.

Pour valider un cas d’utilisation, on présente aux utilisateurs futurs une succession d’écrans simulant l’exécution du processus.

Suite de l'article

---

Vous souhaitez partager cet article :