Vers la gestion de la cohérence dans les processus multi-modèles métier

Vers la gestion de la cohérence dans les processus multi-modèles “métier”

Wolfgang Theurer, doctorant – Wolfgang.Theurer@ensieta.fr François Mekerke, doctorant – mekerkfr@ensieta.fr

Emmanuel Rochefort, doctorant – Emmanuel.Rochefort@ensieta.fr Joël Champeau, enseignant-chercheur – Joel.Champeau@ensieta.fr Philippe Dhaussy, enseignant-chercheur – Philippe.Dhaussy@ensieta.fr

Mots clés : Modélisation, UML, Systèmes embarqués, Cohérence, Métiers

RESUME

Nous présentons ici une méthodologie de développement distribué par modèles-métier. Les différents modèles, liés chacun à leur domaine, sont maintenus en cohérence au travers de la vérification d’invariants, qui sont les garants des bonnes propriétés du système. Nous introduisons les concepts nécessaires à l’aide d’exemples tiré de notre expérience dans les systèmes embarqués.

Introduction

Face à une évolution technologique de plus en plus rapide, la capitalisation des connaissances passe par la modélisation, qui permet d'obtenir une vision globale des systèmes en développement. Cependant, la pratique industrielle étant basée sur le recours à la sous- traitance interne ou externe, il ne saurait y avoir un modèle unique du système. Chaque intervenant a sa propre vision, qu'il décrit dans son propre modèle.

Le défi majeur pour un maître d'oeuvre est d'obtenir la maîtrise de la gestion de ces modèles, et donc du modèle distribué du système. Nos observations des processus industriels existants nous portent à définir la partition de ce modèle comme étant un découpage orienté

« métier ». Chaque intervenant est un spécialiste dans son domaine, et le maître d'oeuvre doit pouvoir soit coordonner les actions des différents spécialistes, soit les mettre en contact et s'assurer de la cohérence de leur dialogue.

Nos travaux portent sur la validation continue de la cohérence au cours d'un projet. Nous présentons ici un processus de développement qui mène à une gestion intégrée des modèles, et garantit la cohérence entre les éléments de solutions élaborés dans les sous-systèmes, entre eux et au regard des spécifications.

Notre démarche répond à la double exigence de la separation of concerns et du découpage « métier ». Elle implique l'identification de « facettes-métier » et de leurs meta- modèles associés. Les interfaces de ces facettes, une fois définies, communiqueront au travers d'un modèle transverse que nous dénommons « pivot ». Cette entité traite les données échangées et effectue des vérifications de propriétés. Ces propriétés peuvent découler des spécifications ou de l'introduction dans le système de préoccupations non-fonctionnelles, qui sont au coeur du problème de maintien en cohérence.

Ce processus peut être utilisé de la phase de spécifications jusqu'à la mise en service, les modèles qu'il met en oeuvre pouvant même être utilisé durant l'intégralité du cycle de vie du système.

1. La modélisation dans l’ingénierie système

Pour des besoins d’abstraction et de maîtrise de la complexité, l’ingénierie logicielle se tourne vers l’utilisation de modèles. En effet, les systèmes intégrant du logiciel se sont énormément complexifiés et le logiciel a pris une part de plus en plus importante dans ces systèmes.

L’industrie automobile et avionique en sont des exemples significatifs puisque maintenant des réseaux embarqués parcourent les véhicules et interconnectent de nombreux calculateurs dont le nombre peut atteindre plusieurs dizaines dans une voiture.

Pour maintenir une qualité en terme de performance, de sûreté ou de validité, de nombreux formalismes de modélisation se sont développés pour permettre une analyse a priori ou faciliter les tâches de mise au point a posteriori.

Au sein d’une même application logicielle, nous devons intégrer de nombreuses caractéristiques logicielles qui se répartissent entre les entités liées aux besoins de l’utilisateur, celles liées aux choix architecturaux et celles venant de la plateforme finale. Pour ces différentes catégories de caractéristiques et d’entités, nous pouvons avoir différents modèles ou plusieurs composantes dans un même modèle. On obtient alors une répartition par domaine ou par aspect qui est une tendance forte des modèles de logiciels.

Dans ce cas, chaque domaine nécessite une définition non ambiguë qui s’appuie sur une approche semi-formelle ou formelle. Bien sur, si de nombreux domaines existent avec des définitions différentes, nous avons besoin d’unifier les différentes démarches et proposer des approches permettant le passage entre domaines.

Dans ce cadre, nous pouvons citer l’approche MDA (Model Driven Architecture, voir [1]), promue par l’OMG, pour faciliter l’exploitation des modèles en s’attachant de définir un cadre pour l’expression des définitions, via des meta-modèles, puis de formaliser des transformations entre domaines en s’appuyant sur ces meta-modèles. Cette initiative a permis d’encourager l’utilisation des modèles et ouvrir un champ d’investigation important vers l’ingénierie des modèles.

Au niveau de l’ingénierie système, des besoins identiques se sont manifestés pour la maîtrise de la complexité, l’analyse a priori et la qualification. Des démarches de modélisation se sont également développées selon les différents points de vue du système. De part la nature même de l’ingénierie système, différents modèles ont été créés pour certains domaines métiers précis comme la sûreté de fonctionnement, l’analyse de performances ou le dimensionnement, assurant ainsi des possibilités d’analyse.

Le nombre de domaines modélisés doit augmenter au niveau système pour augmenter la maîtrise et surtout assurer une cohérence entre domaines. En effet, le contrôle de cohérence entre domaines n’est possible que si tous les domaines possèdent des modèles plus ou moins abstraits mais garantissant des possibilités d’analyse. Un besoin d’unification des définitions apparaît donc, comme en logiciel, pour faciliter le contrôle de cohérence. Pour cela, une ingénierie des modèles doit se développer pour la gestion des modèles et également pour les intégrer dans un processus de réalisation. Ce processus basé sur les modèles doit également garantir une continuité dans les modèles tout au long du processus pour obtenir une cohérence entre différents niveaux d’abstraction conduisant à la réalisation du système.

Ce besoin de développer l’ingénierie des modèles au niveau système est perceptible par la réalisation d’une extension du langage de modélisation UML pour l’ingénierie système. Cette extension, SysML (voir [2]), doit être normalisée par l’OMG (voir [3]) au cours de l’année 2005.

2. Contexte et problématique

2.1. Historique

Afin de bien faire comprendre nos travaux, nous exposons ici le cheminement qui nous y a conduit. Ils se trouvent à la confluence de deux thématiques: modélisation des systèmes embarqués d'une part et adaptation des méthodes formelles à l'ingénierie système d'autre part.

Dans le premier cas, il est vite apparu impossible de gérer un modèle complet des systèmes, dans le second, il était nécessaire de s'appuyer sur une modélisation. Or, le caractère distribué des modèles du système implique vérification (éventuellement formelle), et vérifier des propriétés dans les modèles d'un système implique des connaissances en modélisation. D'où une synergie, qui nous a amené à tenter d'associer les deux thématiques au mieux (voir [5], [6], [7], [8],[9],[10]).

Dans les deux cas, des problèmes de complexité rendant impossibles certaines vérifications existent, nous avons cherché à les contourner en séparant au maximum les préoccupations, afin de ne valider les propriétés que sur les éléments qui y ont trait. Pour ce faire, nous avons donc développé une structure de modèles communicants, dont nous avons ensuite cherché à comprendre l'impact sur le processus de développement.

Il se trouve que le processus induit par l'utilisation d'une telle structure est viable, et peut permettre de résoudre certains problèmes de complexité. De plus, il nous semble être une formalisation correcte de la pratique industrielle. Une description technique de nos travaux se trouve dans [4]

2.2. Problématique industrielle

La pratique industrielle, dans le cadre des grands projets et quelle que soit la souplesse du cahier des charges initial, nous semble pouvoir se décrire de la manière suivante.

Dans un premier temps, la mise en oeuvre du projet, son démarrage effectif une fois le choix des intervenants effectué, se présente sous la forme d'un dialogue entre toutes les parties, directement ou par maître d'oeuvre interposé. Dans tous les cas, l'issue est la même: les réunions s'enchaînent à un rythme élevé, afin de décider de la distribution des responsabilités, en terme de spécifications, à chacune des parties prenantes. Ce processus consiste à évaluer la cohérence entre les différents éléments de solution (généralement relativement abstraits) proposés par les parties en présence.

Le résultat de ces dialogues est un modèle de « blocs » en interaction, dont les interfaces doivent être définies. Une fois cela fait, chaque intervenant réalise sa partie du contrat souvent sans plus d'interaction avec les autres parties, en dehors du maître d'oeuvre.

Surviennent ensuite les phases d'intégration et de test, qui peuvent révéler des problèmes non prévus lors de la conception, dont certains peuvent amener à remettre en cause toute l'architecture du système.

Les points faibles de cette démarche industrielle sont liés à sa nature empirique: la bonne marche du projet repose principalement non seulement sur l'expérience technique de ceux qui le mène, mais aussi sur la capacité qu'ils ont à dialoguer. Si la démarche première de mise en avant des compétences n'est sûrement pas à remettre en cause, chacun étant certainement un spécialiste dans son domaine, la capacité supposée des intervenants à se communiquer des informations pertinentes sur leurs éléments de solution respectifs est encore à démontrer (voir [11]).

La cohérence du système final dépend, de manière parfois critique, de la cohérence des décisions prises dans cette phase préliminaire de conception, qui reste pourtant relativement informelle. La vérification de la compatibilité entre éléments de solution se fait souvent grosso modo, ce qui apparaît assez normal à ce stade où la solution est encore très abstraite.

Cependant, le manque de politique de conservation des relations vérifiées à cet instant entraînera nécessairement qu'il ne sera pas possible de les vérifier ultérieurement, du moins pas de manière automatique. Or c'est bien le moins si l'on souhaite garantir la cohérence.

Aucune traçabilité n'est donc possible dans ce cadre, en dehors du recours à la mémoire collective. Il est toujours possible de revenir à une version antérieure si cela a été prévu, mais pas de connaître les choix qui y ont mené. Afin de pouvoir vérifier à chaque instant, et donc garantir la cohérence du système tout au long de son cycle de vie, il est nécessaire d'intégrer la distribution par équipes-métier dans le processus de développement et de formaliser le stockage et l'échange d'informations entre ces équipes, aussi bien sur le fond que sur la forme.

En effet, que ce soit dans un cadre de sous-traitance interne ou externe, la réalisation d'un (sous-)système passera par le travail commun de collaborateurs regroupés en équipes selon leur spécialité. Les interactions décrites plus haut se référaient donc à un dialogue entre différentes équipes de spécialistes, auxquelles nous nous réfèrerons dorénavant comme à des équipes-métier.

L'idée directrice de nos travaux est de rechercher, valider, puis garantir un invariant de processus, à un niveau d'abstraction aussi haut que possible, mais aussi bas que nécessaire pour permettre une bonne communication entre intervenants.

2.3. Approches académiques

Les « méthodes formelles », telles que le model-checking (voir [14]), le test formel, les algèbres de processus (voir [13]), les automates temporisés (voir [12])..., sont des outils très puissants qui permettent d'assurer ou de vérifier la validité des systèmes. Cependant, elles nécessitent une mise en oeuvre particulière et donc un formatage des données particulier. De plus, leur application sur des grands systèmes pose le problème de l'explosion d'états: le modèle formel complet du système nécessaire à l'application de ces méthodes comporte un nombre d'états exponentiel du nombre d'états des sous-systèmes, rendant rapidement leur évaluation impossible, ou du moins trop longue avec les moyens actuels.

Le problème est donc double: (1) comme nous venons de le montrer, la vérification globale d'un système complet est inapplicable actuellement; (2) il est insuffisant de vérifier chaque sous- système indépendamment, puisque certaines propriétés importantes n'apparaissent que lors du fonctionnement simultané des dits sous-systèmes (par exemple les inter-blocages ou deadlocks).

Afin de résoudre ce problème, il nous faut pouvoir collecter dans les sous-systèmes les éléments pertinents correspondant à des propriétés influant sur le comportement global, pour ensuite appliquer les techniques susnommées permettant de vérifier la validité des dites propriétés.

Ces propriétés globales du système (liées à des cross-cutting concerns) sont vérifiées à un niveau d'abstraction donné, à charge pour les facettes de maintenir leur développement (raffinement) en accord avec leur modèle solution abstrait (qui fait office de contrat), ou inversement.

3. Une approche orientée Maître d’œuvre

Dans le cadre de développements industriels, la séparation des préoccupations (concerns) à partir des spécifications, se fait prioritairement selon les domaines métier impliqués dans la réalisation du système. Le but recherché étant d'exploiter au mieux les compétences des sous- traitants (internes ou externes) impliqués dans la réalisation du système. Chaque équipe spécialisée (facette) se voit affecté un cahier des charges, sous-ensemble des spécifications fonctionnelles du système. Les préoccupations de chacun sont donc clairement identifiées. En revanche, une partie des spécifications (fonctionnelles ou non) sont communes à plusieurs facettes et ne peuvent être divisées, car elle portent directement sur l'interaction entre les dites facettes (Cross Cutting Concerns).

L'approche que nous présentons, répond à cette problématique, tout en intégrant le fonctionnement orienté métier couramment pratiqué lors de développements industriels.

Afin de pouvoir répondre au mieux à la double exigence issue du couple « separation of concerns » /découpage métier, nous avons choisi d'adopter la structure du découpage ``métier'' et de fournir les mécanismes permettant d'implanter les aspects et surtout de garantir leurs invariants dans le temps.

(Ceci plutôt que d'autres solutions, telle par exemple celle qui consiste à tisser les aspects sur un modèle complet du système reconstitué par fusion des modèles des sous- systèmes, qui ne seraient en fait que des vues ``métier'' du système.)

En résumé, le résultat obtenu, en terme de structure, est le suivant: chaque ``facette- métier'' présente des informations à un ``pivot'', qui les traite afin de fournir des données à d'autres ``facettes'' ou de vérifier des propriétés issues de l'introduction des aspects.

Pour illustrer le fonctionnement de cette structure, prenons l'exemple suivant: un client désire disposer d'un engin susceptible d'effectuer des missions de relevés de propriétés chimiques et biochimiques en mer de longue durée et jusqu'à des profondeurs élevés, ceci pour un coût par mission minimal, et un coût de développement donné. Parmi les technologies existantes, une seule répond à ces exigences: celle des glisseurs sous-marins (« gliders »).

Un cahier des charges est établi, puis confié à un maître d'oeuvre. Celui-ci fait appel à divers sous-traitants (logiciel embarqué, électronique, hydrodynamique, automatique, mécanique...), et leur demande de lui fournir leurs éléments de solutions chiffrés.

Même si ces éléments sont techniquement compatibles, il est possible et même probable que le coût de développement annoncé sera dépassé, car il est difficile pour le MO de spécifier a priori une exigence de coût à chaque sous-traitant. De plus, ne pas en spécifier lui permet de connaître l'état de l'art lui permettant une plus grande souplesse de gestion et une gamme de choix plus large. En cas de violation d'une exigence globale (tel que le coût) c'est au MO et à lui seul d'arbitrer entre les sous-traitants en spécifiant plus finement le cahier des charges de certains d'entre eux (s'il estime que le devis logiciel est trop élevé le MO introduira une exigence de coût dans le cahier des charges du logiciel, qu'il aura déterminé en rapport avec les autres devis).

3.1. Concepts et définitions

3.1.1. Facette métier

Le principal axe de séparation des préoccupations est la séparation par domaines métier, nous dénommerons par le terme générique de facette à la fois les exigences liées à un métier, l'équipe physique spécialisée dans ce métier et l'ensemble de modèles du sous-système qu'elle conçoit. Par exemple, dans le cas du développement d'un avion on peut citer les facettes électronique, logiciel embarqué, hydraulique, automatique, aérodynamique, etc.

Une phase de concertation permet de déterminer, pour chaque facette un cahier des charges sous forme d'un modèle solution abstrait nommé Public Model (où PM). Celui-ci permet non seulement d'exprimer les spécifications précises de la facette, mais il définit aussi les éléments d'interaction entre toutes les facettes. Une fois la phase de négociations terminée et les cahiers des charges des différentes facettes déterminés, le processus de développement entre dans une phase dite ``à modèles stables''. Au cours de cette phase la structure des Public Models et celle du pivot ne change plus. Les seuls changements pouvant intervenir sur ces modèles sont des gains de précision de leurs attributs. Nous allons décrire les différents concepts que nous développons dans le cadre de la phase à modèles stables. Le processus d'initialisation menant à ces modèles sera décrit plus avant dans cet article.

Chaque facette est libre de ses choix de conception en ce qui concerne la réalisation sa partie du système. Sa seule contrainte est que celle-ci soit conforme à son Public Model. Le processus de développement et les solutions techniques choisis par la facette ne sont pas imposés.

La gestion de la cohérence entre les Public Models ainsi que les Cross Cutting Concerns ne peuvent être de la responsabilité des facettes. Nous introduisons donc un modèle transverse appelé Pivot. Ce pivot rassemble les informations des Public Models de toutes les facettes, ainsi que des informations liées aux Cross Cutting Concerns exprimées au moyen :

• De nouveaux attributs;

• De règles permettant de les calculer à partir d'informations fournies par les Public Model des facettes;

• De contraintes sur ces attributs provenant des exigences, permettant de déterminer un ensemble de contraintes sur les facettes, de façon à ce que celles-ci ne violent pas les Cross Cutting Concerns.

3.1.2. Pivot

Etant données la taille et la complexité des grands systèmes actuels (avioniques, navals ...) le maître d'oeuvre ne peut ni ne doit connaître en détails l'intégralité des modèles du système dont il a la charge. De même, les équipes métier impliquées dans le développement (ou le maintient en condition opérationnelle), si elles doivent maîtriser à 100% leur domaine, n'ont besoin que d'une quantité réduite d'informations abstraites sur le reste du système. Pour répondre à cette double problématique, nous définissons un ensemble de modèles abstraits appelé pivot qui regroupe des informations de haut niveau permettant d'une part au maître d'oeuvre d'avoir une vision synthétique du système et d'autre part de servir d'interface entre les différentes facettes.

Le pivot est l'entité qui a en charge la gestion de la cohérence entre facettes. D'une part, il reformate les sorties de certaines facettes pour les donner en entrées à d'autres, afin de leur permettre de se coordonner. D'autre part, il vérifie que les invariants introduits par les aspects sont bien respectés.

Il contient donc deux types d'informations: (1) celles relatives au traitement de données (sources, traitements, destinations) et (2) celles relatives à la vérification de propriétés. Le traitement des premières implique l'introduction de techniques de transformations de modèles, tandis que celui des secondes demande, selon les cas, la maîtrise des inéquations ou celle des méthodes formelles.

La gestion des invariants est problématique car il est possible d'envisager l'utilisation de nombreux formalismes différents, en fonction de ce que l'on souhaite vérifier. Afin de pallier ce problème, il nous a semblé judicieux de prévoir un système de ``layers'' , dont chacun contient les informations relatives à un aspect, aussi bien en terme de flot de données que d'invariants.

Le pivot est ainsi composé de ces calques, qui sont empilés lors de l'ajout d'un aspect, et dépilés lorsqu'ils sont jugés inutiles lors de la suite du développement.

Le méta-modèle du pivot doit se trouver à l'intersection de ceux des facettes, afin que le

``mapping`` entre les éléments du pivot et ceux des facettes soit facilité.

Dans le cadre de notre projet de glider, si l'on ne considère, pour simplifier, qu'une facette logiciel et une facette matériel (électronique) le pivot aura la structure suivante:

Il sera constitué de blocs fonctionnels composés d'un processus logiciel (situé dans la facette logiciel) et de la ressource de calcul chargée de l'exécuter. Une ressource de calcul peut-être affectée à plusieurs processus logiciels (multi-tâches). Ces blocs fonctionnels se verront affectés (entre autres) une information de coût calculée en ajoutant au coût du processus sa part du coût de la ressource de calcul au pro rata de la puissance qu'il utilise. Le pivot comportera aussi des liens de communication dont les caractéristiques seront calculées en fonction des liens physiques de la facette matériel qui correspondent et des données qu'ils acheminent (information provenant de la facette logiciel).

Il permettra de vérifier, par exemple, que la puissance des micro-processeurs choisis par la facette matériel permettent aux processus logiciels qu'ils exécutent de respecter les délais qui leurs sont imposés par les spécifications de type « performances temps réel ».

3.2. Processus de développement

Le processus induit par l'utilisation d'une telle structure de gestion des modèles et de leurs relations nous semble pouvoir se découper en deux phases principales: une phase de négociation et une phase « à modèles stables ».

Ce comportement se rapproche assez de ce qui peut être observé dans l'industrie, où le choix des partenaires, puis les choix technologiques et la distribution des taches donnent lieu à négociation.

La première phase comprend l'établissement d'un consensus sur le choix des meta-modèles employés par les différents intervenants, puis sur le meta-modèle du pivot. Suit une phase de définition de la structure du pivot en lui-même, en analysant les éléments de solution préliminaires apportés par les facettes.

La seconde phase correspond à un enrichissement de cette structure, qui consiste en la précision des attributs du pivot, et en la convergence vers le modèle-solution.

Nous allons maintenant détailler les différentes étapes de ce processus.

Fig1 : Schéma du processus de développement

3.2.1. Phase d'initialisation

Cette phase a pour but de définir des modèles-solution pour chacune des facettes ainsi que le modèle pivot destiné au Maître d'Oeuvre. La première étape consiste pour le Maître d'Oeuvre en l'analyse et la compréhension des exigences systèmes émises par le Maître d'Ouvrage. Cette

étape est fondamentale d'une part car elle conditionne la bonne réalisation du système, et d'autre part car beaucoup de projets échouent du fait d'une mauvaise interprétation des exigences (cf. [11]). L'interprétation des exigences par le Maître d'Oeuvre conduit à l'élaboration d'un ensemble de spécifications techniques plus formelles (sous forme de modèles).

Les activités d’analyse des exigences consistent en :

• Comprendre les missions du système,

• Construire une base de données des exigences (besoin et système),

• Définir une architecture fonctionnelle préliminaire explicitant les capacités du système (et du système de soutien)

Dans cette phase d’analyse les outils de gestion des exigences et modélisation d’architecture se complètent, l’un apporte la maîtrise de la base des exigences et l’autre la représentation des missions et scénarios opérationnels et de soutien qui permettront de préciser le besoin et les exigences. En particulier, les diagrammes de séquence représentant les scénarios opérationnels du système constituent un outil essentiel pour comprendre le besoin.

La modélisation de missions et services du système s’appuie sur les "uses cases" UML pour la partie statique. Les scénarios opérationnels, qui décrivent dynamiquement des utilisations du système, sont modélisés en utilisant les diagrammes de séquence UML. Le comportement général du système décrit par des changements d’états est modélisé à l’aide des diagrammes d’état-transition de UML.

Une fois les exigences interprétées, le Maître d'Oeuvre dispose de spécifications du système très abstraites qui sont considérées comme le premier pivot. Elles se présentent sous la forme de modèles UML précisant les valeurs des attributs des objets du système sous forme d'intervalles de valeurs admissibles en regard des exigences initiales. Ce modèle, bien qu'abstrait permet une première vérification de la cohérence des spécifications établies à la suite de l'analyse des exigences. En vérifiant la compatibilité numérique des encadrements de valeurs des attributs du système entre eux et avec les relations qui les lient, il est possible de détecter (numériquement) des erreurs dans la compréhension des exigences ou dans les exigences elle-même. Malheureusement, du fait de la souplesse des exigences initiales, cette analyse ne garantie pas la validité des spécifications; plus les exigences sont strictes, meilleure est la qualité du diagnostique effectué à cette étape.

A ce stade le modèle du pivot ne reflète que les spécifications et ne fournit pas d'éléments de solution, il est donc insuffisant pour entamer la conception. En revanche il permet d'identifier les différentes facettes métier nécessaires et de déterminer les spécifications de chacune d'elles à partir de celles du pivot. Ces spécifications seront soumises à appel d'offre pour déterminer les sous-traitants qui seront choisis pour être en charge des différentes facettes.

L'étape suivante consiste pour les facettes à proposer un modèle solution abstrait de leur partie du système. Pour clarifier notre propos nous considèrerons qu'à une facette est affecté un et un seul sous-traitant des le début mais il nous faut préciser la marche à suivre en cas d'appel à concurrence; Cette concurrence ne joue que lors de la phase d'initialisation: lors de la conception effective il est naturel de considérer les sous-traitants définitivement choisis. La concurrence entre sous-traitants pour une facette donnée revient à considérer que cette facette propose plusieurs modèles solution (un par candidat) qu'il faudra traiter un à un.

Il faut ensuite fusionner les modèles proposés par les facettes pour obtenir le pivot correspondant (boîte « Merge »). Ce pivot doit être validé: les solutions des différentes facettes doivent être compatibles entre elles (en plus de respecter leur cahier des charges). Le pivot comporte des calques correspondant aux préoccupations transverses (c'est à dire portant sur au moins deux facettes) fournissant les relations entre objets de différentes facettes, ainsi qu'un ensemble d'invariants à respecter par les dits objets.

Si le pivot n'est pas cohérent, au moins une facette doit changer son modèle solution. La question de savoir laquelle, n'a en général, pas de réponse unique et évidente. En effet il n'est pas question ici d'erreur d'un sous-traitant, mais d'une incompatibilité entre les choix techniques de plusieurs intervenants qui respectent individuellement leur cahier des charges (celui-ci laissant une assez grande latitude pour ne pas figer les technologies a priori). Le Maître d'Oeuvre doit alors donner son arbitrage et designer les facettes qui doivent corriger leur modèle solution et préciser leurs spécifications afin d'introduire les contraintes induites par les modèles solution retenus.

Par exemple, dans le cadre de notre développement de « glider », si l’une des exigences est que le coût de développement doit être inférieur à 100 000 euros, il est difficile de spécifier a priori le coût maximum respectif de chacune des facettes. A l’issue des premières propositions si la facette logiciel propose 20 000 euros, la facette électronique 30 000, la mécanique 50 000 et l’automatique 15 000, on abouti à un total de 115 000 euros. Le maître d’œuvre doit discuter avec chacune des facettes pour rediscuter de leur cahier des charges. Il peut dans le cas qui nous préoccupe décider de diminuer les contraintes temps réel du logiciel afin de diminuer la puissance de l’électronique, et ainsi faire diminuer le coût de celle-ci. Ceci est possible car le pivot comporte les formules liant les contraintes temps réel du logiciel à la puissance des processeurs.

Ce processus est réitéré jusqu'à l'obtention d'un pivot cohérent suffisamment détaillé pour permettre d'entrer en phase de réalisation proprement dite.

3.2.2. Phase de réalisation (phase à modèles stables)

Lors de la phase de conception, appelée phase à modèles stables, chaque facette réalise sa partie du système en employant le processus de son choix. In fine leur partie doit être conforme au Public Model défini lors de la phase d'initialisation.

Au cours du développement la structure des Public Model ne doit pas changer, en revanche les valeurs des attributs laissées sous forme d'intervalles acceptables à l'issue de la phase d'initialisation sont précisées par les facettes dés qu'elles effectuent un choix de conception. Le pivot est alors notifié et met à jour toutes les valeurs des attributs qui dépendent de ceux qui ont été précisé. Les autres facettes sont ainsi informées.

Ce processus permet au MO d'avoir une connaissance en temps réel de l'avancement du développement de son système. De plus il est le garant de la cohérence sémantique et syntaxique des informations échangées par les sous-traitants dans la mesure où ils ne peuvent communiquer directement et que le pivot traduit les informations provenant d'une facette dans les langages compréhensibles par les autres. Les risques d’erreurs dû à l'incompréhension entre sous-traitants sont donc réduits. Ce processus permet en outre, grâce à une séparation claire des exigences par domaine de diminuer la taille des modèles à vérifier et le niveau d'abstraction auquel ces vérifications ont lieu (celui du pivot). Il rend donc possible l'application des méthodes formelles augmentant ainsi la confiance que l'on peut accorder au système a priori (c'est à dire au plus tôt dans le cours du processus de développement).

Une fois le système réalisé, les Public Models des facettes et le pivot final permettent de faciliter la maintenance et le maintien en condition opérationnelle du système. En effet cet ensemble de modèles donne une vision claire des dépendances entre les parties du système ainsi que les responsabilités de chacun.

3.3. Traçabilité

L’approche présentée permet de « s’affranchir » du problème de la traçabilité, du moins pour ce qui est des mécanismes permettant de retracer les choix ayant mené à une erreur. En effet, puisque l’on teste régulièrement les invariants issus des différentes préoccupations, les éventuelles erreurs sont détectées au plus tôt, et leurs relations avec les autres données étant connues, il est facile de localiser l’erreur. Bien sûr, il est pour cela nécessaire de vérifier autant de propriétés que possible, afin de ne rien laisser passer. Mais ce problème semble inéluctable quelque soit les méthodes utilisées ; il est en effet difficile de découvrir une erreur si l’on n’a pas prévu le dispositif de surveillance adapté.

Conclusion

Nous avons exposé un processus de développement de systèmes multi-intervenants issu de nos recherches en modélisation/validation des systèmes embarqués ainsi qu’un ensemble de

modèles permettant d’aider le Maître d’œuvre dans sa gestion des sous-traitants (qu’ils soient internes ou externes). Nous avons tenté de montrer l’impact éventuel de nos travaux sur le management de projet dans le cadre du développement de grands systèmes industriels.

Nos travaux peuvent etre considérés aussi comme une tentative de modélisation semi-formelle de la pratique industrielle. Le volet management de projet, bien que n’étant pas central, nous semble être un corollaire intéressant de notre approche.

Bien qu'ayant déjà appliqué notre approche sur une étude de cas simple, elle a besoin, pour atteindre sa pleine maturité, d'être confrontée à une application plus complète. C'est pourquoi nous travaillons actuellement à la modélisation d'un sous-marin autonome de type glider développé à l'ENSIETA. Nous définissons trois facettes :

logiciel, matériel et automatique (modèle hydrodynamique, lois de commande. . .) et divers layers dont : validation, énergétique, masse/volume.

Au travers de cette expérience, notre objectif est de proposer, à court terme, un outil de support logiciel appliqué à un problème spécifique et, à moyen terme, un ensemble d'outils génériques dont les combinaisons permettront de répondre à des problématiques plus générales.

Bibliographie

[1] http://www.omg.org/mda/

[2] http://www.sysml.org [3] http://www.omg.org

[4] Mekerke F., Theurer W.& Champeau J. « Non-functional aspects management for craft- oriented design », UML’2004, WS: Models for Non-functional Aspects of Component-Base Software, 12/10/2004

[5] AKSIT M., TEKINERDOGAN B., « Solving the modeling problems of objectoriented languages by composing multiple aspects using composition _lters », 1998.

[6] H^ÜRSCH W. L., L^OPES C. V., « Separation of Concerns », rapport n^o NU-CCS-95-03, February 1995, College of Computer Science, Northeastern University, Boston, MA.

[7] H^ILLIARD R., « Using the UML for Architectural Description », F^RANCE R., R^UMPE B., Eds., UML'99 - The Unified Modeling Language. Beyond the Standard. Second International Conference, Fort Collins, CO, USA, October 28-30. 1999, Proceedings, vol. 1723 de LNCS, Springer, 1999, p.

32.48.

[8] K^ICZALES G., L^AMPING J., M^ENHDHEKAR A., M^AEDA C., L^OPES C., L^OINGTIER J.-M., I^RWIN J., « Aspect- Oriented Programming », A^{K ¸SIT} M., M^ATSUOKA S., Eds., Proceedings European Conference on Object-Oriented Programming, vol. 1241, p. 220.242, Springer-Verlag, Berlin, Heidelberg, and New York, 1997.

[9] M^EKERKE F., G^EORG G., F^RANCE R., A^LEXANDER R., « Tool Support for Aspect-Oriented Design », BRUEL J.-M., BELLAHSÉNE Z., Eds., Advances in Object-Oriented Information Systems OOIS 2002 Workshops, LNCS 2426, septembre 2002, p. 280-289.

[10] S^UZUKI J., Y^AMAMOTO Y., « Extending UML with aspects : Aspect support in the design phase », Proceedings of the third ECOOP Aspect-Oriented Programming Workshop, 1999.

[11] Standish Group International. (1999). Chaos: A recipe for success. Available on the World Wide Web: http://www.standishgroup.com/sample_research/chaos_1994_1.php [12] A^LUR R., D^ILL D. L., « A theory of timed automata », Theoretical Compute Science, vol. 126, n^o 2, 1994, p. 183.235.

[13] E^RMONT J., « Une algèbre de processus pour la modélisation et la vérification des systèmes temps-réel avec préemption. », PhD thesis, ENSAE, 2002.

[14] L^AROUSSINI F., « Automates temporisés et hybrides », École d'Été Temps Réel (ETR2003), Toulouse, Septembre 2003, p. 155-166.