En analysant les schémas de représentation proposés par les méthodes de développement couramment utilisées, on observe deux types de représentation du réel.
- La première est basée sur le postulat qu'une application informatique doit satisfaire certaines fonctionnalités : vérifier la présence d'un objet en stock, guider la construction d'une maison. Cette approche est celle de la décomposition fonctionnelle.
- La seconde s'intéresse essentiellement à l'application en tant système de relations entre entités. On décrit un individu comme un ensemble composé d'un nom, d'un ou plusieurs prénoms, d'un numéro de sécurité sociale et ayant ou non des enfants. De même, une maison est un assemblage de fondations, murs, portes, fenêtres.. le modèle de la réalité ainsi élaboré est qualifié de systémique.
Pour reprendre la terminologie de M COMBES, nous appellerons ces schèmes de représentation "modèles" dans le sens ou ils se veulent à la fois mathématiques dans leur expression et les plus proches possible de la réalité.
Mais examinons plus avant ces deux paradigmes :
La décomposition fonctionnelle se propose d'aborder le système d'information comme un prestataire de services qui répond à des questions. Par exemple "Combien de clients a t-on visité depuis le début du mois" ? La réponse à cette question passe alors par l'accomplissement d'une série d'actions : calculer la date du premier jour ouvrable du mois, trouver les clients client vus depuis ce jour, afficher le résultat. La fonction " trouver les clients client vus depuis.." se décomposant elle-même en : accéder au fichier client, sélectionner le nombre de clients vus depuis la date, éliminer les clients présents deux fois, compter le nombre de clients restants etc..
Cette démarche parait naturelle dans la mesure ou elle reproduit ce que ferait un employé auquel on poserait la question. On peut y distinguer un double mouvement :
• Découpage temporel : les tâches doivent être accomplies les unes après les autres. De plus certaines d'entre elles produisent des informations utilisées par d'autres : elles doivent donc les précéder. Dans notre exemple, on ne peut sélectionner les clients avant d'avoir calculé la date du premier jour ouvrable du mois. Cette dimension temporelle met en relief la séquentialité des tâches et leur synchronisation.
• Découpage des procédures en sous procédures : la tâche globale est découpée en sous-tâches qui peuvent elles-mêmes être décomposées. Le processus est répété jusqu'à ce que les tâches élémentaires soient suffisamment simples. Dans notre exemple, la fonction " trouver les clients client vus depuis.." se décompose en quatre sous-fonctions qui peuvent éventuellement être décomposées à nouveau.
Dans l'analyse, ces deux dimension sont souvent liées dans la mesure ou les sous-procédures sont aussi des sous-séquences.
Il existe de nombreuses méthodes de développement. Toutes préconisent d'utiliser des schémas pour représenter la décomposition fonctionnelle d'une application. La méthode Merise est sans doute la plus utilisée en France. Voici l'un des modèles de décomposition fonctionnelle qu'elle préconise :
Construction d'une maison : fondations
Il existe de nombreux autres types de diagrammes fonctionnels. Certains mettent en avant d'autres concepts comme celui de flux ou de stock de données, mais ils procèdent tous de la même double approche. Le propre de ces démarches est de représenter une application au travers des transformations que l'on fait subir aux données ; il s'agit d'une analyse par structuration des traitements.
L'analyse par décomposition fonctionnelle permet également de trouver les sous-procédures communes à différentes procédures d'une application. On peut alors en vertu d'un principe d'économie concevoir une seule sous-procédure qui sera utilisée à plusieurs reprises. Une sous-procédure utilisée à plusieurs endroits différents d'une application ne sera donc présente qu'en un seul exemplaire. De la sorte, on n'a a écrire le code qu'une seule fois et les améliorations qui sont réalisées sur ce code s'appliquent automatiquement à toutes les fonctions qui l'utilisent.
La plupart des schémas de structuration des traitements ont été conçus durant les années 70. Les années 80 ont été marquées par le développement d'un paradigme de représentation radicalement différent : Un problème est représenté comme un système de relations entre les éléments qui le composent La démarche de l'analyste s'articule alors autour de la définition des éléments du modèle et de l'élucidation du réseau des relations qui les lient.
L'expression de ce système de relations se fait grâce à un schéma : le diagramme "entité-relation". Les entités représentent des individus, des choses ou des événements qui font partie du domaine - Ces entités peuvent être munies de propriétés -. Les relations représentent les interactions entre ces entités.
Une relation élémentaire peut être exprimée par une phrase dont le sujet et le complément d'objet sont des entités et le verbe la relation qui les lie.
Voici un exemple de diagramme entité-relation utilisé par la méthode Merise :
Diagramme entité-relation
Ce diagramme introduit également la notion de cardinalité (un coffrage est toujours construit sur une fondation, une fondation supporte quatre coffrages au maximum).
Contrairement à celle du paradigme de structuration des traitements, cette représentation est statique : On spécifie l'existence de données sans préciser si elles sont 'en mouvement ' ou 'au repos'.
Par contre, à un même modèle correspond un nombre illimité de réalisations possibles. Le diagramme entité-relation exprime en effet un ensemble de relations potentielles sans en imposer le sens de lecture. La méthode de recherche de toutes les bulldozers ayant participé au creusement d'un trou est de même nature que celle de toutes les coffrages qui font partie d'une fondation. Le changement du chef d'équipe ou la création d'une nouvelle entité 'pelleteuse' pour creuser les fondations ne demande pas de revoir le modèle entier. De fait, la description du problème qui est produite est réputée plus durable, dans la mesure ou ce qui est représenté est la "la réalité fondamentale du domaine d'activité" (R. PLANCHE), mais elle est également plus adaptable.
Par contre, contrairement au diagramme qui le précède, un diagramme entité-relation ne permet pas de traduire la mission de l'application. Notre diagramme entité-relation exprime ce que sont des fondations et ce qui est nécessaire pour les construire, mais pas la façon de procéder.
