Les phases

Pour couvrir la totalité du cycle de vie, différents formalismes sont nécessaires pour exprimer les différents éléments des différents niveaux d’abstraction [Herlea et al., 1999]. C’est pour cette raison que nous avons adopté un cycle axé sur quatre phases exploitant différents notations provenant de paradigmes semi-formels et de langages (agents, composants, machines à états finis, Hardware Description Langage).

104 La démarche de la méthode DIAMOND

Dans la phase de recueil des besoins, nous avons introduit une étude des modes de marche et d’arrêt qui n’existe qu’à cause de la criticité de nos applications physiques. En effet, dans les systèmes phy-siques, il est intéressant et important de pointer des modes précis de fonctionnement du système, que les méthodes tendent à négliger. Il y a bel et bien une problématique à traiter mais le système à concevoir est plus que cela : l’utilisation des méthodes multi-agents est généralement axée sur ce problème principal et a tendance à mettre de coté d’autres aspects tels que les transitions fonctionnement normal vers arrêt, les arrêts d’urgence, les arrêts pour maintenance, les marches dégradées (que les entreprises exploitent pour produire malgré des dysfonctionnements et amoindrir l’impact financier des problèmes) et surtout la sécurité des biens et personnes (primordial pour une catégorie de systèmes physiques). Un déploie-ment industriel de système multi-agents doit prendre en compte ces paramètres.

Les phases de déploiement sont aussi des phases assez marginales dans les méthodes multi-agents. Dans MASE cette phase permet de spécifier la place des agents sur les plates-formes existantes. Dans PASSI [Burrafato and Cossentino, 2002] cette phase a pour objectif de définir la topologie du réseau et l’attribution des ressources aux agents mobiles. Dans notre approche, cette phase transparaît à deux niveaux :

– Au niveau de l’agent via la phase du partitionnement qui donne une importance particulière à la partition matérielle/logicielle de l’agent dans le sens ou chacune des fonctionnalités de l’agent peut être déployée sur du matériel et/ou du logiciel.

– Au niveau système ou chaque agent est déployé dans l’environnement comme précisé dans la phase de recueil des besoins (voir §5.2).

Les principaux critères intervenant pour le déploiement de l’agent ont été étudiés (voir tableau 5.4).

Notre phase de conception est originale de part son côté générique. Dans les méthodes de génie logi-ciel, la conception générique [Roques and Vallée, 2003] fait référence au développement d’une solution qui répond aux spécifications techniques mais restant entièrement indépendante des aspects fonctionnels. Dans notre cas, elle fait en plus référence à l’abstraction de l’aspect matériel : un composant traduit le fait de traiter une fonctionnalité mais n’est en aucun cas son implémentation réelle. Ce composant pourra être décliné de plusieurs manières matérielles à logicielles.

Cette troisième phase de notre méthode a pour objectif la construction des entités élémentaires de notre système, que sont les agents, en respect de l’analyse effectuée précédemment. Cette construction des agents démarre par la coquille externe et se poursuit en direction de son coeur (l’aspect décision-nel). Cette phase est effectuée sans discriminer ce qui deviendra logiciel ou matériel. Pour cela on uti-lise des composants comme unité opératoire (cf §5.4). L’utilisation de composants pour implémenter des agents préoccupent de nombreux chercheurs [Kendall and Malkoun., 1997, Guillemet et al., 1999, Meurisse and Briot., 2001, Occello et al., 2002, Vercouter, 2004] mais les travaux sur des cycles de dé-veloppement complets de systèmes multi-agents intégrant une dimension componentielle sont rares [Lind, 2001, Brazier et al., 2002]. Nous rappelons que nos intérêts pour l’utilisation des composants comme unité opératoire sont:

– La simplicité de compréhension et de mise en oeuvre par "l’utilisateur" du composant (program-mation graphique et abstraction de la nature matérielle/logicielle),

Conclusion : discussion sur la méthode 105

– L’incitation à la généricité (quand un composant est bien fait, il est facile de le ré-utiliser), – Le découpage fonctionnel clair inhérent à leur utilisation qui facilite le partitionnement ,

– L’analogie composant logiciel/composant électronique qui permet aux outils du logiciel et de la description du matériel de partager une vision unifiée (voir le découpage entre description ex-terne/interne dans les spécifications VHDL).

Il est intéressant de faire une analogie avec d’autres méthodes utilisant des composants. Dans MaSE l’ensemble des composants sont représentés sous forme de classes ou d’ensembles de classes. Les com-posants permettent de détailler les différents types d’agents, de définir l’architecture de l’agent. Dans MASSIVE, les composants interviennent après la sélection d’une vue⁶ du système dans le raffinement de celle-ci et est en relation avec une base d’expérience qui regroupe tout les composants prédéfinis.

Les méthodes multi-agents sont beaucoup trop récentes pour intégrer des démarches qualité. Cepen-dant, dans MASSIVE des mesures qualités sont utilisées pour évaluer la vue travaillée. Elle permet ainsi de savoir s’il faut réitérer le processus ou non.

L’utilisation de qualité dans notre approche n’est pas encore effective. Les documents créés asso-ciés à une gestion documentaire permettront une traçabilité complète des différentes étapes de la vie de l’application. Un de nos objectifs est d’intégrer une démarche complète de qualité dans notre méthode. Pour cela, nous devrons intégrer une réelle politique de qualité, c’est-à-dire permettre l’identification des exigences clients et la mise en place de mesures sur chaque activité afin de mesurer la corrélation en ce qui est produit et ce qui était initialement attendu par le demandeur. Une phase ne pourra être quittée que lorsque la qualité sera satisfaisante (comme dans MASSIVE). Un cycle de vie en spirale s’y prête d’ailleurs très bien via son évaluation des risques avant de quitter toute phase (voir §3.4.7 et §5.1.2.1).

De plus il faudra intégrer le processus qualité à la co-simulation (afin de vérifier la qualité

dyna-mique⁷du système) et la co-validation.

Le tableau 5.5 présente une synthèse des cycles de vies des méthodes systèmes multi-agents. Il met aussi en évidence les points forts et faibles des activités de ces cycles [Picard, 2004].

Les critères sont:

– Besoins : l’étape de recueil des besoins est-elle prise en compte? – Analyse : l’étape d’analyse est-elle prise en compte?

– Conception : l’étape de conception est-elle prise en compte?

– Implémentation : l’étape d’implémentation est-elle prise en compte? – Test : le processus de test est-il pris en compte?

– Déploiement : le déploiement est-il pris en compte? – Maintenance : la maintenance est-elle prise en compte?

– Délivrables : les délivrables sont-ils bien identifiés et associés à des étapes précises? – Gestion de la qualité : la gestion de la qualité est-elle prise en compte?

– Gestion de projet: les directives de conduite de projet sont-elles claires?

6. La méthode propose une vue environnement, une vue tâche, une vue rôle, une vue interaction, une vue société, une vue architecture qui permettent d’arriver à la vue système

106 La démarche de la méthode DIAMOND

TAB. 5.5 – Comparaison des cycles de vie

(++) : les propriétés sont pleinement et explicitement prises en charge. (+) : les propriétés sont prises en charge de manière indirecte. (+) : les propriétés sont potentiellement prises en charge. ( ) : les propriétés ne sont pas prises en charge. ( ) : les propriétés ne sont explicitement pas prises en charges.