Langage de mod´ elisation

Au regard des caract´eristiques du framework de mod´elisation attendu, nous avons choisi comme support `a la mod´elisation du cas d’´etude les frameworks SysML, OCL et UPDM. Suite `a l’analyse de ces frameworks pr´esent´ee au chapitre 3 et plus particuli`erement la synth`ese que nous en avons fait en section 3.4, nous avons s´electionn´e les vues pertinentes pour notre travail. Identifier les concepts associ´es `a chacune de ces vues nous a conduit `a ´

elaborer des m´eta-mod`eles, que les figures 5.1 et 5.2 pr´esentent de mani`ere simplifi´ee. La figure 5.1 d´ecrit un m´eta-mod`ele simplifi´e du point de vue op´erationnel :

— Les vues OV-1a permettent avec une description picturale de montrer les princi-paux composants du SdS. Ces composants sont les principales ressources d´eploy´ees dans le contexte de la mission principale du SdS.

— Les vues de type OV-1b permettent de mod´eliser avec les diagrammes de cas d’util-satition quels sont les objectifs des interactions entre les CSs (syst`emes consti-tuants). Ces diagrammes sont associ´es `a des acteurs qui mod´elisent des ressources impliqu´ees dans les interactions. Nous utiliserons le diagramme de cas d’utilisation de SysML car cette partie du mod`ele architectural est comportementale et statique. — Les vues OV-5 permettent d’exprimer l’intention des interactions par la d´ ecompo-sition des actions et leur responsable. Nous constatons de plus qu’elles permettent de faire apparaˆıtre des ressources qui n’´etaient pas identifi´ees d`es le d´ebut. Le diagramme le plus adapt´e est le diagramme d’activit´e qui mod´elise des aspects comportementaux et des analyses de la dynamique des interactions.

— Pour finir la vue OV-4 fait la synth`ese des CSs impliqu´es ainsi que des ressources qu’ils d´eploient. Elle permet de faire apparaˆıtre clairement les CSs en montrant `a quelles organisations les acteurs appartiennent. Nous utiliserons un diagramme de package pour mod´eliser des aspects structurels et permettre des analyses statiques. Les diagrammes de package mettent en avant l’ind´ependance des ressources d’un CS vis-`a-vis des autres CS.

Le point de vue syst`eme de UPDM fournit un ensemble de vues qui donnent un niveau de d´etail suppl´ementaire `a la vue op´erationnelle. La figure 5.2 montre un m´eta-mod`ele simplifi´e `a partir duquel nous d´eveloppons une partie du mod`ele. Nous avons choisi la vue SV-1 qui raffine les ressources en termes de composant humain, mat´eriel et logiciel. Elle pr´ecise le type des ressources, le nombre d’instance et les connexions. Les connexions sont d´ecrites via la notion de port et d’interface fournie et requise. Le BDD (Diagramme de D´efinition de Bloc) et le BDI (Diagramme Interne de Bloc) sont des diagrammes struc-turels qui permettent d’exprimer les instances minimales et maximales pour le BDD et les interconnexions pour le BDI. Ces diagrammes permettent d’exprimer en termes de contrainte le nombre de composants de l’architecture et la d´ependance entre ces compo-sants. Cela permet de capturer le style architectural mais aussi le comportement des CSs.

5.1. Choix de mod´elisation

5.1. Choix de mod´elisation

Ces diagrammes limitent les propri´et´es que l’on souhaiterait mod´eliser. Un exemple de propri´et´e que nous serons amen´e `a mod´eliser est la d´efinition de la stratification entre des groupes de composants. Le but est de v´erifier que des composants ne puissent pas communiquer directement avec des composants d’autres stratifications.

Pour ´etendre la pr´ecision de SysML et UPDM nous int´egrons OCL qui ajoute plus de pr´ecision aux propri´et´es exprim´ees et permet leur v´erification automatique. Nous utilise-rons OCL pour d´efinir des primitives architecturales comme expliqu´ees par Zdun and Av-geriou (2008). Ensuite, nous verrons que l’approche met en œuvre des outils de simulation se focalisant sur des sc´enarios d’ex´ecution. Les vues OV-5 nous permettent d’identifier un ensemble de sc´enarios d’ex´ecution possibles, mais la description n’est pas assez formelle. La vue SV-10c nous permet de d´ecrire les sc´enarios d’ex´ecution en termes de messages ´

echang´es. UPDM n’´etant pas assez pr´ecis, nous avons int´egr´e des primitives comporte-mentales qui capturent les concepts d’envoi et de r´eception de messages comme celle de SosADL (System of Systems Architectural Description Language) Oquendo (2017). Un diagramme de s´equence est utilis´e et montre les interactions en termes d’envoi de mes-sages et de r´eception de messages. Il permet de mod´eliser des aspects d’interaction, alors que le diagramme d’activit´e permet de mod´eliser des envois de messages.

Notre framework de mod´elisation se limite aux vues op´erationnelles et syst`emes. Notre int´erˆet se porte sur les reconfigurations `a court terme dans les SdSs. Les points de vue toutes vues et strat´egique s’int´eressent `a des ´el´ements qui portent sur des ´evolutions `a long terme plutˆot que des ´evolutions `a court terme qui impliquent des solutions de re-configuration non anticip´ees. Le point de vue service est couvert par la description des interfaces de SV-1. Le point de vue technique est ´egalement couvert par la vue SV-1 en capturant le style architectural suivi.