Chapitre 2 : Conception de système interactif d’aide à la décision
2.3. Méthodes d’analyse et de conception des systèmes
Pour pouvoir modéliser et formaliser les différentes étapes d’un processus de développement
d’un système, une méthode d'analyse et de conception doit être utilisée. C’est un procédé qui
consiste à créer une représentation virtuelle d'une réalité de façon à faire ressortir les points
auxquels on s'intéresse. C’est dans ce cadre que s’inscrit cette section.
2.3.1 Les méthodes systémiques
Elles permettant des modélisations centrées sur les données et les traitements.
2.3.1.1 La méthode Merise
La méthode Merise [Tardieu et al. 83] [Tardieu et al. 91] était la méthode systémique la plus
points forts de Merise est de proposer trois niveaux d’abstractions avec des préoccupations
complémentaires :
- Le niveau conceptuel comprend le modèle conceptuel de données et le modèle
conceptuel des traitements,
- Le niveau logique (ou organisationnel) est représenté par le modèle logique des
données et le modèle organisationnel des traitements,
- Le niveau physique (ou opérationnel) comprend le modèle physique des données et
le modèle opérationnel des traitements.
Suivant cette méthode tout projet informatique suit trois cycles : abstraction, décision et vie.
Le cycle de vie permet de décrire la vie du système. Il distingue les périodes qui vont de la
conception à la maintenance. Le cycle de décision concerne les différentes décisions et les
choix qui sont effectués tout au long du cycle de vie. Le cycle d’abstraction offre les concepts
pour pouvoir décrire les différents éléments du monde réel qui seront représentés dans le
système d’information. Merise a évolué au fur et à mesure des nouvelles technologies, par
exemple en intégrant les notions objets dans une de ses versions récentes [Gabay 01].
Pour ce qui est de l’étude de l’existant et de l’analyse des besoins, la méthode Merise propose
d’intéressants modèles centrés d’une part sur les données et d’autre part sur les traitements
[Nanci et al. 01].
2.3.1.2 La méthode Axial
La méthode Axial [Pelleaumail 86] C’est une méthode d'analyse, de conception et de gestion
de projet. C’est une méthode systémique qui a été concurrente de la méthode Merise. Les
différents modèles de cette méthode mettent l'accent sur le rapprochement des données et des
traitements.
2.3.2 Les méthodes cartésiennes
Elles permettent de procéder à un découpage fonctionnel et hiérarchique du système ; elles
sont très pratiques pour représenter des systèmes complexes, et pour faciliter la
communication dans les équipes projet.
2.3.2.1 La méthode SADT (Structured Analysis and Design Technique)
C’est une méthode d'analyse bien adaptée à la phase de spécification fonctionnelle d'un
système. Conçue au début des années 70 par Doug Ross aux Etats-Unis [Ross 77] [Dickover
et al. 77], elle a été mise au point par la société Softech, en collaboration avec ITT [Marca
88]. Elle est diffusée en France par IGL Technologie [IGL 89].
Cette méthode permet de décrire un système complexe existant sur les deux plans : le plan
fonctionnel (la mission du système, les différentes fonctions, leurs niveaux et leurs
interactions) et le plan structurel (les frontières du système, les entrées-sorties, les principaux
sous-systèmes et leurs liaisons). L'analyse d'un système par la méthode SADT suit une
démarche descendante, modulaire, hiérarchique et structurée.
En effet, la technique consiste à découper hiérarchiquement l’objectif global en n niveaux
(décrivant complètement les fonctionnalités du système) dépendant de la complexité du
système, sous forme d’actigrammes. Chaque niveau est composé d’un ensemble de tâches
composées ou terminales ; la tâche composée présente un niveau opérationnel qui fait appel à
un enchaînement structuré de sous-tâches. Les tâches terminales, non décomposables,
correspondent à la description des séquences composées d’actions élémentaires de l’opérateur
ou de la machine pour atteindre le but fixé. Son niveau opérationnel est défini par une
structure décrivant le corps de la tâche.
2.3.2.2 La méthode SA (Structured Analysis)
Elle a été développée par Demarco [DeMarco 79] ; elle a pour base le modèle diagramme de
flot de données (DFD). Son objectif est d’identifier et représenter les fonctions d’un système
par niveaux de détails successifs et par niveaux d'abstraction successifs. A tout niveau, chaque
fonction peut être décomposée en sous-fonctions de niveau inférieur représentant le détail des
traitements de la fonction mère. Les fonctions de SA sont appelées processus et ont pour but
de transformer des données portées par des flots de données.
L’apport de la méthode SA est qu’elle représente les fonctions d’un système par niveaux de
détails successifs et par niveaux d’abstraction successives. Sa limite est qu’elle n’exprime ni
le contrôle ni le séquencement temporel des actions.
2.3.2.3 La méthode SA-RT
Elle a été proposée par Ward et Mellor en 85 [Ward et Mellor 85], puis étendue en 87 aux
aspects architecture système par Hatley et Pirbhai [Hatley et al. 87]. Elle se présente comme
une extension sous l’angle du temps réel de la méthode fonctionnelle SA avec une bonne
couverture de l'axe dynamique par la prise en compte des informations de contrôle
(événements, exceptions, activations, synchronisation, etc.). La modélisation du
comportement du système se fait dans un modèle dynamique séparé mais couplé au modèle
fonctionnel. Un troisième modèle est proposé par Hatley et Pirbhai [Hatley et al. 91], c’est le
modèle d’architecture. Il est proposé dans le but de couvrir le troisième axe d'analyse à savoir
l’axe de l'aspect structurel. Sous l’angle du diagramme de flots de données, il est comme SA
très proche du modèle SADT de décomposition en actigrammes ; néanmoins, il reste moins
convaincant et moins approfondi.
2.3.3 Les méthodes orientées objets
Ces méthodes sont toutes basées sur UML
5actuellement suite à l’unification des trop
nombreuses méthodes existantes, durant les années 90 [Jacobson et al. 99]. UML est définie
comme un langage d’unification des différentes méthodes objet. Ce n’est pas véritablement
une méthode puisqu’elle doit être associée à un processus méthodologique. UML provient
d’une fusion des principales modélisations objets. En cela, elle reprend et améliore leurs
formalismes.
Parmi les diagrammes que propose UML, on retrouve le diagramme de classes, le diagramme
d’objets, le diagramme des cas d’utilisation, le diagramme de séquences, le diagramme de
collaboration, le diagramme d’activité, le diagramme de temps, le diagramme d’états /
transitions, le diagramme de composants, le diagramme de déploiement, etc. [Larman 05].
L’emploi des cas d’utilisation de Jacobson [Jacobson et al. 93] incite à intégrer ou tout au
moins à prendre en compte l’utilisateur au moins à un niveau d’abstraction élevé, ce qui
constitue un progrès important par rapport à la plupart des méthodes objets qui ont procédé
5