Consultant en système d'information et délégué général du club des maîtres d'ouvrage des systèmes d'information, Michel Volle est l'auteur, chez Economica, d'Analyse des données, Le métier de statisticien, e-conomie. |
|
|
|
Le diagramme, expression des fonctions du programme informatique
Un modèle exprimé doit décrire complètement le contenu fonctionnel dun 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 dun diagramme, la démarche procédant par enrichissement progressif selon un ordre top down.
Il ne convient pas de bousculer lordre des étapes : il ne faut pas se lancer dans la modélisation proprement dite sans disposer de lexpression de besoin, ni documenter les cas dutilisation avant davoir produit le diagramme dactivité etc. Chaque étape de la démarche doit avoir été réalisée entièrement avant que lon ne passe à la suivante : lune des erreurs les plus courantes en modélisation est de sengouffrer de façon précoce dans des travaux détaillés quil faudra détricoter par la suite.
Il est nécessaire dassocier plusieurs techniques informelles et formelles pour saisir les diverses facettes dun problème sans le dénaturer, puis pour le détailler dans un modèle central que lon pourra préciser et modifier jusquà limplé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 lon 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 laval 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 leffet de tunnel dans la modélisation.
Une fois lexpression 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 dutilisation 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 dune 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 lexpression de besoin est trop souvent inadéquate : le client dit quil a besoin de telle et telle fonctionnalité, alors quil faudrait quil expliquât ce quil a lintention de faire, quil décrivît laction quil sagit de réaliser.
Lorsque lexpression de besoin part comme il se doit dune action, elle comporte naturellement la description dun processus : toute action se ramène en effet à un processus (plus ou moins complexe et ramifié) selon lequel, partant dune situation initiale ou input, et par lapplication de certaines ressources, on aboutit à un résultat ou output.
Lexpression de besoin doit essentiellement décrire linput et loutput, la définition des ressources relevant le plus souvent dune étape ultérieure.
Il faut dire aussi ce quil 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 lorganisation. Cependant la construction du modèle apportera une réduction terminologique, en nassociant plus quun nom et un seul à une même chose ou à un même concept : l'amélioration du vocabulaire est lun 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 lentreprise impliquées, leurs responsabilités et leur mode de coopération. La notion de "flot dinformation" 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 dun processus (exemples : "une direction départementale ne doit pas comporter plus de dix agences", "un client ne peut commander via le Web que sil a été enregistré au préalable", "un employé marié ne doit être muté quen dernier recours", etc.).
Modélisation du processus
Décrire un processus, cest décrire lévénement qui le déclenche, les étapes (ou activités) par lesquelles il doit passer, les ressources quil doit consommer et lévénement final auquel il doit aboutir. Ces informations sont rassemblées et documentées dans le diagramme dactivité : il décrit la succession des activités, les messages quelles échangent, les éventuels sous-processus et les livrables intermédiaires que ceux-ci fournissent.
Cas dutilisation
Létape suivante consiste à décrire les cas dutilisation, chaque activité en comportant un ou plusieurs. Un cas dutilisation regroupe des opérations que lacteur 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 dutilisation lorsque on la nommé et désigné par sa finalité au sein de lactivité, 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 dutilisation divers comportent des éléments semblables, ou quils soient des cas particuliers de cas dutilisation plus généraux : on peut alors définir une hiérarchie de cas dutilisation qui, par abstraction, simplifie le modèle : cest le diagramme des cas dutilisation.
Pour valider un cas dutilisation, on présente aux utilisateurs futurs une succession décrans simulant lexécution du processus. |
Michel Volle |