Résumé

Il existe plusieurs catégories de projet, et par conséquent plusieurs approches du développement:

1. Les projets qui possèdent un cahier des charges, exprimant les exigences contractuelles (techniques, coûts, délais, qualité) entre le client et le fournisseur. Ce type de projet peut être traité selon deux approches:
   • une approche hiérarchique structurée où les grandes étapes du projet analyse, spécification, conception,...correspondent aux objectifs à réaliser.
   • une approche incrémentale et itérative avec pour objectif de réaliser des "builds". Un build est une entité autonome: un article de configuration qui s'enrichit de manière incrémentale.
2. Les projets qui ne possèdent pas de cahier des charges au début du projet, mais seulement une idée plus ou moins vague du système à réaliser, idée qui deviendra de plus en plus précise au fur et à mesure du développement du système. Avec ce type de projet, le développement s'effectue selon une approche évolutive et itérative avec en général une phase de recueil des besoins incrémentale par maquettages successifs.
3. Les projets qui sollicitent une combinaison "hybride" des deux approches précédentes.

Toutes ces particularités et bien d'autres, nous amènent à penser qu'il ne doit pas y avoir une méthodologie de développement avec de nombreuses exceptions pour tenir compte des différents cas de figure, mais une méthodologie à géométrie variable, où, le cycle de vie du projet et celui du système pourront être configurables. La méthodologie Sys_P_O propose une telle démarche à travers cinq principes fondamentaux :

1. Approche incrémentale configurable, illustrée par un cycle en spirale,
2. Développement du système par étude de cas et par points de vue,
3. Développement en réutilisant et pour réutiliser,
4. Pas de "cassure" entre l'analyse et la conception,
5. Application des nouvelles normes de développement: MIL STD-SDD

Mise en oeuvre de la spirale productiviste Sys_P_O

Certes il n'existe pas, comme l'affirment certains auteurs, de recette miracle pour développer en objet. Toutefois, avant d'acquérir l'expérience nous avons imaginé un cycle de développement incrémental en spirale comprenant 6 activités exécutées pendant n tours pour parcourir n niveaux d'abstraction ou couches. Avec Sys_P_O, le système est donc construit par couches successives.

Naturellement, l'ordre des activités de la spirale n'a pas été défini au hasard. Il résulte de nombreuses expériences menées dans des environnements différents. Vous observerez par exemple, que la réutilisation est omniprésente dans la démarche de conception en Sys_P_O, et que les relations statiques (héritage, référence, agrégation) sont réalisées après avoir identifié les attributs des entités, mais avant de s'intéresser à leurs services, afin de concevoir une architecture qui repose sur ce qui nous semble être le plus important: les attributs.

Remarques:

• Lorsque l'on applique une démarche de développement on se livre à un exercice réducteur puisque l'on place l'utilisateur de la démarche sur des "rails" l'obligeant ainsi à appliquer la procédure.
• Il ne s'agit pas d'exécuter séquentiellement, une seule fois les activités de chaque tour, mais bien de les parcourir jusqu'à ce que vous puissiez exécuter et valider la 6e activité de chaque tour.

Premier tour de spirale

Le principal objectif de ce premier tour de spirale est de situer le système à modéliser dans son environnement. Les différents agents extérieurs que composent l'environnement précisent en Sys_P_O les différents points de vue du système à représenter. Par exemple, si un distributeur de boissons a pour agents extérieurs les clients et les exploitants, le système devra être représenté selon ces deux points de vue "au minimum", puisque chacun de ces agents considère une partie du système, sous un angle qui lui est propre. La démarche consiste donc à créer, pendant les deux premiers tours autant de représentations statiques et dynamiques qu'il y a de points de vue, et de les superposer au début du 4e tour de spirale juste avant l'implémentation, afin de constituer les vues globales de ces représentations.

Identifier les entités du système: les domaines et les agents

Cette activité a pour objectif de représenter les différents points de vue du système à l'aide d'entités appelées domaines, et son environnement à l'aide d'agents ou acteurs.

Un domaine qui illustre le système ou une fraction du système selon le point de vue considéré, a pour objectif de satisfaire une ou plusieurs fonctions issues du tableau d'analyse fonctionnelle. Il s'agit bien ici de se demander qui fait la(les) fonction(s) du tableau d'analyse fonctionnelle.

Deux techniques différentes peuvent être sollicitées pour identifier les entités de base du système: les domaines.

• La première technique propose d'identifier toutes les entités que composent le système, puis de regrouper celles-ci. On regroupe les entités intervenant dans la même mission (fonction du tableau d'analyse) et ayant le maximum de communications entre-elles.
• La seconde technique consiste à identifier directement les domaines à partir de l'expertise métier.

Identifier les entités à réutiliser

Avec Sys_P_O, il existe principalement deux niveaux de réutilisation:

• Le premier niveau de réutilisation s'effectue lors des deux premiers tours de la spirale sous la forme de domaines, charpentes et/ou grappes remplissant une (ou plusieurs) étude de cas, par exemple: les interfaces graphiques pour utilisateur (MVC), des systèmes de gestion de base de données, des systèmes de gestion de communication (ORB),...
• Le deuxième niveau de réutilisation commence au troisième tour de spirale et se poursuit jusqu'à l'implémentation. Il s'agit principalement de récupérer des classes ou des modules ainsi que leur comportement, par exemple: NIH Class, Booch Class, Borland Class, MCF de Microsoft, MEIJIN++,...

Avec Sys_P_O la réutilisation est au coeur du développement. Elle est organisée à partir de deux magasins d'entités réutilisables:

• le magasin central, qui stocke des entités réutilisables exprimant des études de cas, achetées, développées ou reconfigurées par l'entreprise. Ce magasin d'études de cas plurisdisciplinaires est transversal dans l'organisation de l'entreprise.
• le magasin du projet, qui stocke des entités réutilisables, développées pendant le projet par les différentes équipes (internes ou externes).

L'objectif de cette deuxième activité du cycle en spirale est double:

• Identifier les charpentes ou les grappes réutilisables en évaluant le niveau d'adéquation entre le besoin et les entités stockées dans le magasin central. Si une entité récupérée dans le magasin central satisfait une fonction du tableau d'analyse fonctionnelle elle est notée dans le champ fonction du domaine.
• Décider si une charpente ou une grappe non trouvée dans le magasin est "intéressante" à développer pour être réutilisée dans l'avenir.

Identifier les attributs des entités du système

Il s'agit lors de cette activité d'identifier un maximum de 10 attributs par domaine, et 1 à 5 attributs par agent. Les attributs des domaines correspondent généralement aux entités de base du domaine. Les attributs des agents précisent leurs caractéristiques (attributs d'état, attributs démons).

Identifier les relations entre les entités du système

Après avoir identifié les attributs des domaines et des agents, nous devons maintenant établir les relations statiques existantes entre les domaines, et entre les domaines et les agents extérieurs. C'est ainsi que nous identifierons les liens de clientisme (référence statique) et d'héritage entre domaines via les entités de base du domaine. Par exemple, marquer qu'un domaine hérite d'un autre domaine signifie qu'une entité d'un domaine (classe, grappe) hérite d'une entité d'un autre domaine (classe, grappe).

Identifier les services offerts par entités

C'est lors de cette activité que seront notées, dans le champ fonction des domaines, les exigences stipulées dans les tableaux d'analyse fonctionnelle. Les fonctions des domaines seront ensuite réparties lors des prochains tours de spirale dans les différentes entités que composeront le domaine.

Définir la communication entre les entités

Il s'agit d'une certaine manière de "valider" le travail réalisé par les activités précédentes en "simulant" le premier délivrable: le système et son environnement. Par exemple, l'impossibilité de faire communiquer les différents domaines et agents entre-eux est symptomatique d'une erreur de découpage du système.

Deuxième tour de spirale

L'objectif de ce deuxième tour de spirale, éventuellement parcouru plusieurs fois, est de représenter le système à l'aide d'une ou plusieurs images statiques et dynamiques de base appelées également études de cas statiques et dynamiques de base.

Identifier les entités statiques de base de chaque domaine du système: les domaines, les charpentes, les grappes, les classes, les modules

Il existe plusieurs techniques pour identifier les "objets":

• Une première technique consiste à faire une analyse grammaticale des documents textuels en entrée du projet (cahier des charges, spécification technique des besoins,...): les noms peuvent signifier un objet, un état de l'objet ou encore une valeur d'état de l'objet, les verbes (autres que les auxiliaires) représentent en général les services offerts par les objets, les adjectifs (autres que les participes passés) peuvent indiquer des contraintes ou des valeurs d'état.
• Une deuxième technique fait appel aux diagrammes état-transition de l'objet: les états du diagramme correspondent aux états de l'objet ou aux valeurs des états, la transition entraîne un message, le message déclenche un service, le service modifie (ou non) l'état de l'objet.
• Une troisième technique est basée sur les principes de la psychologie contemporaine.
• Une quatrième technique consiste à décrire le système en commençant par les entités qui sont en contact avec les agents extérieurs, puis de décrire ensuite le coeur du système en le considérant comme un "macro-objet" dont les états et les services offerts se déduisent des objets en contact avec le monde extérieur: l'objet de commande et de contrôle du domaine. Avec une telle technique nous devrions déboucher, aux prochains tours de spirale, sur une architecture en couches: couche des objets en contact avec les agents extérieurs (objets d'interface), couche du "macro-objet" de commande ou de contrôle, couche des "objets de données" manipulées, créés,...
• Une cinquième technique propose de construire des diagrammes par services élémentaires et par condition à remplir, en partant de l'objectif final qui représente une étude de cas. Cette technique est particulièrement efficace pour construire les études de cas du système.

Etude de cas: Déplacer une personne en ascenseur

Pour que la personne soit déposée à un étage, il faut que la porte s'ouvre

Objet: Porte Etat: Ouverte

Pour que la porte s'ouvre, il faut que l'ascenseur soit arrivé à l'étage de destination

Objet: Ascenseur Etat: Arrivé_à_l'étage_destination

Pour que l'ascenseur arrive à l'étage, il faut que la destination ait été choisie et les portes fermées

Objet: Porte Etat: Fermée

Objet_Créé: Destination Etat: Choisie

Pour que la destination soit choisie, il faut que l'on ait appuyé sur le bouton de la cabine

Objet: Bouton_Cabine Etat: Enfoncé

Pour que l'on ait appuyé sur le bouton, il faut que l'on soit entré dans l'ascenseur

Objet: Ascenseur Etat: Chargé

Comme vous pouvez en juger, cette dernière technique permet d'identifier les principaux objets de l'étude de cas "déplacer une personne", selon le point de vue du fonctionnement normal. De la même manière, nous aurions pu traiter l'étude de cas "déplacer une personne" selon le point de vue de la sûreté de fonctionnement (objets: bouton arrêt d'urgence, sonnerie,...).

Identifier les études de cas à réutiliser

Comme lors du précédent tour de spirale, l'architecte doit d'abord faire "un petit tour" au magasin pour récupérer toutes les études de cas qui présentent un intérêt pour le système à modéliser.

Identifier les attributs des entités statiques de base de chaque domaine

Suivant la technique utilisée pour identifier les entités de base, cette activité sera plus ou moins importante puisqu'en partie déjà réalisée.

Au cours de cette activité, l'architecte Sys_P_O s'efforce d'affecter 1 à 5 attributs aux entités de base préalablement identifiées. Il s'agit principalement d'attribut indiquant un lien de référence statique, dynamique ou un lien d'agrégation. Si un attribut appartient à plusieurs classes, il existe sans doute un lien d'héritage entre ces classes. Par contre, une classe de base qui ne possède pas d'attribut correspond fort probablement à un attribut d'une autre classe.

Identifier les relations entre les entités statiques de base de chaque domaine

Nous identifierons en premier, les liens qui relient les différentes représentations d'un même domaine, si différents points de vue ont été sollicité. Par souci de cohérence également, nous noterons les liens entre domaines, à travers les entités de base. Nous devrions également marquer les liens qui relient les grappes entre elles, et, les grappes et les classes de base. Si l'une des classes du domaine créée, manipule, un objet nous noterons le lien de référence dynamique. Concernant l'héritage, nous ne devrions pas dépasser deux niveaux d'héritage ce qui prouverait que la spécialisation du système n'a pas encore débuté.

Identifier les services offerts par les entités statiques de base de chaque domaine

Nous allons pouvoir appliquer l'un des principes énoncés en introduction: "Ne demande pas ce que fait le système, mais qui le fait". Plus précisément, il s'agit d'identifier quelle entité est capable de traiter la(les) fonction du domaine. Naturellement une fonction d'un domaine peut être répartie sur les entités du domaine. Une matrice permet de s'assurer que toutes les fonctions du domaine (fonctions issues du tableau d'analyse fonctionnelle) auront bien été implémentées.

Ces cinq activités du deuxième tour de spirale ont permis de réaliser les images statiques de base de chaque domaine du système vue des différents agents extérieurs.

Définir la communication entre les entités de base de chaque domaine et entre domaines

Il s'agit ici de simuler le fonctionnement des différentes fonctions des domaines, implémentées dans les entités de base. Une fonction d'un domaine correspond à une (rarement à plusieurs) étude de cas de base, formalisée sur une page d'écran informatique ou sur une feuille de papier au format A4. Cependant, il n'est pas rare qu'une étude de cas implique, comme le montre l'exemple "déplacer une personne", plusieurs services répartis dans plusieurs entités différentes du domaine et qu'il faille plusieurs feuilles de papier.

Les études de cas de base ou images dynamiques de base montrent, comme l'expose l'exemple ci-dessous, l'enchaînement des différentes fonctions du domaine préalablement réparties dans ses entités.

Remarque:
A la fin du deuxième tour de spirale seules les entités d'analyse auront été identifiées. Cependant, vous noterez que consciemment ou inconsciemment, vous avez également réalisé "un peu de conception" pour tenir compte par exemple de certaines contraintes d'implémentation (choix d'un exécutif temps réel, d'une base de données, d'un langage de programmation,...). Ce principe est à la base du développement incrémental proposé par la norme de développement MIL STD-SDD.

En pratique on peut très bien imaginer que les deux premiers tours de spirale soient exécutées par le chef de projet, et les autres tours par les différentes équipes de réalisation.

Troisième tour de spirale

L'objectif de ce troisième tour de spirale est double, il s'agit pour l'architecte Sys_P_O de:

• Réaliser les images statiques détaillées de chaque domaine du système d'abord en ajoutant aux entités de base de chaque domaine les "objets" de conception, ensuite en spécialisant certaines classes à l'aide de sous-classes et/ou de liens de renommage, et/ou de redéfinition de service, enfin en identifiant les liens complémentaires.
• Réaliser les images dynamiques détaillées ou études de cas détaillées de chaque domaine du système en identifiant les pré-conditions à satisfaire pour que l'objet puisse traiter le service invoqué par un message et en créant les "struturogrammes" de chaque étude de cas détaillée

La réalisation des ces objectifs aura naturellement pour conséquence d'aborder (si ce n'est déjà fait) le choix du langage d'implémentation (C++, Eiffel, Smalltalk, Ada95,...).

Identifier les entités complémentaires à chaque domaine: les classes, les modules

Après cette action, l'architectee(chef de projet ou développeur) doit d'une part, enrichir, spécialiser le domaine à l'aide de sous-classes et, d'autre part, indiquer les entités spécifiques (objets) de conception (structure de données, moniteur temps réel,...). Lors d'évolutions du système, seules ces entités spécifiques seront sujettes à modification, surtout si vous avez pris soin de concevoir une architecture en couches telle qu'elle a été présentée au deuxième tour de spirale.

Identifier les entités à/pour réutiliser

Comme nous l'avons souligné précédemment, il s'agit du 2e niveau de réutilisation qui consiste à récupérer du magasin central des classes et leur comportement qu'il faudra éventuellement spécialiser.

Identifier les attributs des entités complémentaires à chaque domaine

Il s'agit d'identifier les attributs ajoutés aux classes de base du domaine, mais également les attributs des sous-classes spécialisées et des classes de conception. Il s'agira principalement d'attribut de type simple (entier, booléen,...). Nous pouvons également nous rendre compte que certains attributs sont inutiles, que d'autres doivent être déplacés d'une sous-classe à l'autre. Nous identifierons aussi les attributs "dynamiques" qui référencent un objet (persistant) créé, utilisé, détruit pendant l'exécution de certaines fonctions du système.

Identifier les relations entre les entités de chaque domaine

La reconnaissance de classes de base complémentaires, de sous-classes spécialisées et de classes de conception ne devrait pas entraîner de modifications importantes dans l'architecture du domaine. Nous porterons une attention toute particulière aux nouvelles relations inter-domaine, en minimisant toujours celles-ci. Nous nous attarderons sur les classes qui ne possèdent pas de sous-classes et à celles qui se spécialisent excessivement. Enfin, les références dynamiques seront identifiées.

Identifier les services des entités de chaque domaine

Il s'agit d'identifier d'une part les services offerts par les sous-classes identifiées et ceux qui résolvent des problèmes d'implémentation et, d'autre part, l'éventuelle pré-condition à l'exécution d'un service suite à l'invocation de celui-ci par un message séquentiel ou un signal "masquable". Nous préciserons aussi la signature complète des services (paramètres, type). C'est naturellement lors de cette activité que seront traités certains problèmes spécifiques à l'objet (problèmes de nom lors d'héritage multiple,...) en sollicitant le renommage et la redéfinition de service. Toutefois, nous devrons limiter leur utilisation toujours pour des raisons de complexité de tests.

C'est également pendant cette activité que le comportement de chaque classe est formalisé à l'aide de diagramme état-transition qui s'avère intéressant pour environ 5% des classes, de pseudo-code proche du langage d'implémentation sélectionné,...

Remarque:
Ces cinq premières activités du troisième tour de spirale ont permis de réaliser les images statiques détaillées de chaque domaine du système.

Définir la communication entre les entités de chaque domaine et entre les domaines

Deux possibilités sont offertes pour faire "tourner" les domaines:

• Réaliser des images dynamiques de base en tenant compte des résultats obtenus par les activités précédentes du tour: classes complémentaires, classes de conception,...
• Réaliser des images dynamiques détaillées. Pour ce faire chaque classe sera instanciée. Les objets instance seront ensuite reliés dynamiquement à l'aide de messages séquentiels et/ou de signaux asynchrones en tenant compte des éventuelles préconditions. Seront aussi noté les liens de création/destruction d'objets pendant l'exécution de l'étude de cas détaillée. Le résultat de l'interaction des objets sera formalisé par un (ou plusieurs) structurogramme afin de se rapprocher de la réalisation, objectif du prochain tour de spirale.

Remarque:
Vous vous êtes certainement rendu compte, tout au long de cette démarche de développement, que notre méthode raisonnement n'est plus guidée par les activités d'analyse séparée de la conception mais, par une analyse et une conception associée: la séparation entre l'analyse et la conception n'a plus de raison d'être. Il est clair qu'au début du développement nous passons plus de temps à analyser pour comprendre qu'à concevoir pour réaliser. Mais il est également vrai qu'il est impossible de concevoir si l'on ne sait pas ou l'on va (résultat de l'analyse).

Quatrième tour de spirale

La première action, avant de commencer l'implémentation des classes et modules dans le langage de programmation préalablement sélectionné au plus tard au troisième tour de spirale, il est indispensable de superposer des différents points de vue d'un même domaine pour obtenir les classes globales.

Retours d'expérience

La méthodologie Sys_P_O a été utilisée dans plusieurs projets (GIAT, EDF, Aérospatiale, CEA, Métrologic Instruments,...) avec succès après formation des opérateurs. La véritable difficulté rencontrée fût sans aucun doute le syndrome de la "page blanche" d'où la mise en place d'un guide pour construire des applications objet.

© 1985-2011 Eiffel Software. All rights reserved. -- Privacy Policy