Utilisation de SysML pour la modlisation des rseaux de capteurs

Nicolas Belloir , Jean-Michel Bruel , Natacha Hoang , Congduc Pham Universit de Pau et des pays de lAdour L IUPPA, BP 1155, F-64013 Pau Cedex {belloir,bruel,nhoang,cpham}@univ-pau.fr http://liuppa.univ-pau.fr Rsum. SysML est le nouveau langage de modlisation dni par lOMG. Il peut tre vu comme une extension dUML destine la modlisation dun large spectre de systmes complexes. Son champ dapplication est en ce sens plus large que celui dUML mais sa liation le rend tout particulirement intressant pour la modlisation de systmes embarqus majoritairement composs de logiciel. Les logiciels dploys sur les rseaux de capteurs sans l (WSN) sont un bon exemple de ce type dapplication puisque la prise en compte de linteraction forte entre le matriel et le logiciel inhrente ce type de systme est une condition importante pour une modlisation efcace. Dans cet article nous dcrivons notre retour sur exprience concernant la modlisation dun systme utilisant des capteurs mobiles sans l an de mesurer les ux de personnes dans une ville. Dans cette tude, nous avons utilis la fois SysML pour la modlisation du systme et UML pour la modlisation des parties logicielles. Nous prsentons les points de recouvrements des deux langages dune part, et nous en comparons les diagrammes statiques dautre part.

Introduction

De nos jours, mme la plus simple des applications informatiques est relativement complexe, principalement de par son caractre distribu, mobile et communiquant. La gnralisation des architectures client/serveur, limportance des notions de services, la coopration entre entits et les besoins de ractivit temps rel participent imposer un environnement de dveloppement rigoureux. Dans cet article, nous nous intressons aux systmes informatiques fortement contraints que constituent les rseaux de capteurs sans l (Wireless Sensors Networks WSN), technologie dont on peut consulter notamment ltat de lart de Khemapech et al. (2005). Ces systmes sont caractriss par une forte interaction entre le matriel et le logiciel. Les composants internes des capteurs sont souvent propritaires et constituent des composants sur tagre (Commercial Off The Shelf COTS) dont la prise en compte ncessite une approche particulire. Les logiciels dploys sur les WSN doivent pouvoir prendre en charge linteraction forte entre le matriel et le logiciel inhrente ce type de systme. Spcialise dans le dveloppement dapplication base composants (Component-Based Software Engineering CBSE), technologie prsente dans louvrage de Szyperski et al.

Utilisation de SysML pour la modlisation des rseaux de capteurs

(2002), et dans les rseaux, notre quipe cherche dterminer une approche rigoureuse de dveloppement pour les WSN. Pour cela, nous nous basons sur notre exprience de lcriture de prols et de mtamodles, que nous appliquons aux dernires avances en terme de langages de modlisation de systmes. En effet, mme si le rapprochement des langages de modlisation (comme UML) et des langages de description darchitecture (ADL) ont vu lintgration dans la version 2.0 dUML, spcie dans OMG (2005), de concepts cls comme ceux de ports ou de composites, force est de constater les manques de tels langages gnralistes pour modliser les systmes complexes du type WSN, pour lesquels jusqu maintenant, et notre connaissance, ont t utilises des approches plutt formelles telles que dans Sachdeva et al. (2005). SysML est le nouveau langage de modlisation dni par lOMG (2007b). Il peut tre vu comme une extension dUML destin la modlisation dun large spectre de systmes complexes. Aprs en avoir tudi les apports, nous avons t confronts un certain nombre dinterrogations. Dans cet article nous dcrivons notre retour sur exprience concernant la modlisation dun cas rel (un systme utilisant des capteurs mobiles sans l an de mesurer les ots de personnes dans une ville, nanc par la communaut dagglomration de la ville de Pau). Dans cette tude, nous avons utilis la fois SysML pour la modlisation du systme et UML pour la modlisation des parties logicielles. Nous discutons des points de recouvrement des deux langages dune part, et nous en comparons les aspects statiques dautre part.

Modlisation des systmes embarqus communiquants

Nous nous intressons ici un type de systme embarqu communiquant particulier : les rseaux de capteurs sans l. Nous les prsentons dans un premier temps puis nous expliquons pourquoi UML ne suft pas pour modliser ce type de systme.

2.1

Les rseaux de capteurs sans ls : un systme trs complexe

Un capteur est un petit appareil autonome capable deffectuer des mesures simples sur son environnement immdiat. Lutilisation de ces capteurs na rien dune nouveaut, ceuxci sont utiliss depuis longtemps dans des domaines comme laronautique ou lautomobile. Ce qui est novateur, cest la possibilit pour ces capteurs de communiquer de manire radio (rseaux sans ls de type WiFi) avec dautres capteurs proches (quelques mtres) et pour certains dembarquer de la capacit de traitement (processeur) et de la mmoire. On peut ainsi constituer un rseau de capteurs qui collaborent sur une tendue assez vaste. Ces rseaux de capteurs soulvent un intrt grandissant de la part des industriels ou dorganisations civiles o la surveillance et la reconnaissance de phnomne physique sont une priorit. Par exemple, ces capteurs mis en rseau peuvent surveiller une zone dlimite pour dtecter soit lapparition dun phnomne donn (apparition de vibrations, dplacement linaire...) soit mesurer un tat physique comme la temprature (dtection des incendies en forts) ou la pression. Dans beaucoup de scnarios de gestion de crise (sismes, inondations,...) ces rseaux de capteurs peuvent permettre une meilleure connaissance du terrain an doptimiser lorganisation des secours, ou bien mme renseigner prcisment les scientiques sur les causes dun phnomne physique particulier. Il est aussi envisageable dintgrer les aspects multimdia et nomadisme dans certaines applications mobiles mlangeant donnes et images. On le voit, les applications

N. Belloir et al.

possibles sont extrmement nombreuses avec un impact fort sur un grand nombre dapplications civiles et des nouveaux effets socitaux certains. Ces rseaux de capteurs posent un certain nombre de ds scientiques intressants pour la communaut de recherche. Par exemple, lorganisation de ces capteurs en rseaux soulve des problmes bien connus, mais qui restent extrmement ardus, de routage (dtermination du chemin optimal entre 2 points du rseau), de communication et darchitecture logicielle. Les scnarios usuels dutilisation envisagent plusieurs milliers de capteurs que lon pourra disperser pour surveiller des zones sensibles. Le facteur de rsistance lchelle sera donc crucial. Sajoute ces difcults le fait que les capteurs possdent des ressources trs limites en terme de puissance de calcul, mais aussi en terme dautonomie de fonctionnement puisque dans la plupart des scnarios de dploiement, les capteurs fonctionneront avec de petites batteries. Cette limitation des ressources rend ncessaire une certaine forme de coopration grande chelle o les interactions entre capteurs peuvent tre extrmement complexes. En effet, outre les problmes de dissmination ou de rcupration des donnes, la ralisation dun service complexe dans un rseau de capteurs doit pouvoir tre effectue grce une composition de services plus simples et donc une forme de collaboration "intelligente" des capteurs. La reconguration et ladministration distance, cest--dire la gestion de ces capteurs, seront galement des proprits souhaitables qui seront indispensables dans un proche avenir pour optimiser les ressources et permettre la rutilisation de linfrastructure dploye. Toutefois les architectures logicielles actuelles ne savent pas, ou mal, intgrer des lments autonomes et mobiles comme le sont les capteurs.

2.2

Modlisation de nouvelles fonctionnalits et limitation dUML

Les travaux dans le domaine du gnie logiciel ont prouv le besoin de dvelopper les applications informatiques de manire modulable et faiblement couple. Lingnierie logicielle base composant a ainsi apport dimportantes contributions, offrant des mthodes, des concepts et des supports technologiques qui permettent ce type de dveloppement. Dans ce contexte, de nombreuses nouvelles fonctionnalits peuvent alors tre envisages. Par exemple, la reconguration dynamique qui est une composante primordiale de la modularit est alors envisageable. En effet, cette opration permet de remplacer un composant par un autre dans une application en cours dexcution. Cette action peut-tre cause par la ncessit de substituer un composant mal implment cest--dire ne ralisant pas les fonctionnalits prvues ou les ralisant de manire incorrecte, ou encore dajouter ce composant de nouvelles fonctionnalits. Dans le contexte des rseaux de capteurs, il peut savrer pertinent, par exemple, de changer les donnes quun capteur devait initialement collecter sur son environnement ou tout simplement de recongurer le rseau lorsquun capteur na plus assez de batterie pour fonctionner. La reconguration dynamique devient alors une caractristique importante des applications dployes sur ce type de rseau. Normalis par lOMG, UML est le langage graphique le plus utilis pour modliser les divers aspects dun systme dinformation. Par contre, dans le contexte de lingnierie systme, son pouvoir dexpression est plus limit. En effet, certains concepts spciques ce domaine ne peuvent tre spcis simplement avec UML. Par exemple, le fait quil existe des paramtres dont un changement de valeur entranerait un fonctionnement diffrent du systme ne peut tre modlis avec UML. De plus, le lien fort entre le logiciel et le matriel ne trouve pas en UML de moyen satisfaisant dexpression. Dans les systmes qui nous intressent, il faut tre capable

Utilisation de SysML pour la modlisation des rseaux de capteurs

dexprimer les contraintes portant sur la batterie, ou bien encore la faible quantit de ressources disponibles. Par exemple, si le niveau de la batterie devient limite, il faut pouvoir spcier une action comme envoyer un signal aux autres capteurs leur demandant de se recongurer pour palier cette dfection. Ces limitations ont fait lobjet de nombreux travaux de recherche. Notons actuellement les travaux portant sur le prol UML Marte (OMG (2007a)) qui est ddi aux systmes temps rel et embarqus ainsi que les travaux portant sur le langage de description darchitecture AADL (Feiler et al. (2006)). Pour remdier aux limitations dUML identies prcdemment, lINCOSE1 , aid par lOMG, a donc rchi sur des amliorations dUML 2 an de proposer un langage de modlisation plus appropri lingnierie systme. Nous prsentons SysML plus en dtail dans la section suivante.

Prsentation de SysML

SysML est le nouveau langage de modlisation spci par lOMG. Il sagit en fait dun prol UML et il hrite donc des caractristiques dUML, ce qui est la fois un atout et une faiblesse comme nous le verrons dans la section 5. Il sagit dun langage de modlisation graphique dont la smantique semi-formelle est dnie dans OMG (2007b) - il est entendu que par smantique, nous nous rfrons Harel et Rumpe (2004) qui notent que malgr le manque de smantique formelle et les critiques bien connues sur le sujet, les langages diagrammatiques ont prouv leur importance dans le dveloppement systme et logiciel. SysML est dni comme un langage de modlisation pour lingnierie systme capable doffrir un support pour la modlisation de multiples processus et mthodes. Nanmoins, comme explicit dans le document de spcication, chaque mthodologie peut imposer des contraintes additionnelles sur la manire dont un lment de construction ou un type de diagramme donn peut tre utilis. Cela sous-entend qu cause du nombre lev de champs couverts par lingnierie systme, une approche interdisciplinaire est difcile obtenir. De plus, les processus dingnierie, tant pour lingnierie logicielle que systme, ont volu indpendamment chacun de leur cot comme lexplique Boehm (2006). Dans ce contexte, SysML semble tre en mesure de devenir un support permettant de rapprocher ces deux familles dingnierie. Dans cet esprit, nous avons travers notre tude de cas, essay dvaluer ce rapprochement. Les concepteurs de SysML ont travaill dune part, limiter ou adapter les concepts trop proches de lingnierie logicielle, et dautre part simplier la notation UML originale en rduisant notamment le nombre de types de diagramme disponible, an den simplier lutilisation. Ainsi, la gure 1 tire de Friedenthal et al. (2007) montre les diagrammes fournis par SysML. On note lapparition de deux nouveaux diagrammes. Le Requirement Diagram (diagramme des exigences) a pour rle de spcier les besoins de lapplication. Un des points intressants de ce type de diagramme est quil permet de relier les exigences avec les diagrammes rpondant ces exigences comme nous le verrons sur lexemple de la gure 2 prsent la section 4.2. Le Parametric Diagram (diagramme paramtrique) est le second type de diagramme entirement nouveau. Il permet de spcier des expressions mathmatiques entre les lments des modles. Parmi les diagrammes conservs dUML, lActivity Diagram (diagramme dactivit) a t lgrement modi. Par contre, les Class Diagram (diagramme de
1 INCOSE

: International Council on Systems Engineering : http://www.incose.org/

N. Belloir et al.

F IG . 1 Taxonomie des diagrammes SysML

classe) et Composite Diagram (diagramme composite) dUML ont t renomms et modis plus en profondeur travers le concept de Block, permettant dexprimer tout lment structurel dun systme. Nous nous intresserons dailleurs plus en dtail aux diagrammes structurels dUML et de SysML dans la section 5. Enn, SysML se veut, la manire dUML, une norme volutive. La version 1.0 a t adopte le 19 septembre 2007 et dj le comit travaillant sur SysML lOMG propose des pistes damlioration pour passer la version 1.1. Cette approche incrmentale, mme si elle implique une ractivit forte la fois des diteurs denvironnement de modlisation et des utilisateurs, a montr son succs avec la famille des langages UML et lavnement de UML 2.

Etude de cas

Dans cette section, nous prsentons dune part le projet Sicop dans le cadre duquel nous avons men notre tude de cas, et dautre part un ensemble dlments de modlisation mettant en uvre le langage SysML.

4.1

Le projet Sicop

Lobjectif du projet Sicop2 , nanc par la communaut dagglomration de Pau Pyrnes, est de dterminer si la technologie des WSN est adquate pour ltude des mouvements urbains sur une priode donne. Dans ce contexte, les WSN permettent dautomatiser les tudes statistiques mais galement datteindre un haut degr de pertinence. Dans ce scnario, des capteurs individuels sont distribus une population cible et volontaire, qui les portera lors de ses dplacements urbains. Ainsi les dplacements sont observs et enregistrs par le systme. Nous appelons ces capteurs des capteurs mobiles. Les dplacements seront enregistrs grce
2 Sicop : Sensor in the City of Pau (http://liuppa.univ-pau.fr/ALCOOL/article.php3?id_ article=13)

Utilisation de SysML pour la modlisation des rseaux de capteurs

au dploiement au pralable de capteurs en des endroits (extrieurs ou intrieurs) prdnis de la ville. Ce sont les capteurs dits xes. Un capteur mobile port par une personne pourra communiquer avec un capteur xe lorsque cette personne passera proximit de celui-ci. Les informations collectes par les capteurs xes pourront alors tre agrges sur un rseau de type Internet (tel que linfrastructure Pau Broadband Country3 ) par le biais de ponts WiFi pour tre enregistres dans une base de donnes. Comme il est difcile de mettre un point dagrgation (les ponts WiFi par exemple) pour chaque capteur xe dploy, les informations dun capteur mobile concernant les diffrents capteurs xes rencontrs pourront tre galement sauvegardes puis envoyes en diffr lorsque ce capteur mobile passera proximit dun capteur xe proche dun point dagrgation. Les diffrents dplacements dun capteur mobile, reprsents par la suite des capteurs xes quil a rencontrs dans le temps, seront ainsi enregistrs, permettant aux scientiques concerns dtudier les diffrents dplacements urbains dune population test. Il est aussi envisageable que les capteurs mobiles puissent communiquer entre eux an de remplir, si besoin est, le rle de station relais pour lchange dinformations ou bien pour augmenter ltude avec des donnes concernant les interactions/corrlations entre les dplacements. Les possibilits de reconguration des capteurs mobiles et xes permettront de pouvoir rutiliser linfrastructure dploye pour dautres types dapplication.

4.2

Elments de modlisation

Dans un projet systme classique des ingnieurs spcialistes de divers domaines technologiques (lectronique, hydraulique, logiciel . . .) et de divers domaines mtiers (aronautique, automobile . . .) sont amens interagir. Cest l la cible de SysML. Cependant, SysML nous semble particulirement intressant galement dans le cas o un ingnieur logiciel est amen travailler dans des systmes principalement composs de logiciel comme par exemple en informatique pervasive, dont le domaine est prsent par Satyanarayanan (2001). Cest cette approche que nous avons choisie pour mener notre investigation. Ce cas dtude est trs orient logiciel et peut paratre peu complexe pour un ingnieur systme. Nanmoins, il nous semble particulirement adapt pour explorer la frontire entre UML et SysML dune part, et dautre part il est rvlateur des problmes venir avec lavnement de linformatique pervasive dans laquelle les systmes dinformations vont devoir de plus en plus fonctionner sur, et/ou utiliser, des environnements contraints. Dans notre tude, il est ncessaire de prendre en compte la svrit des contraintes inhrentes au support matriel que sont les capteurs. Par exemple, de par leur faible autonomie (par rapport dautres systmes mobiles), il est impratif de limiter au maximum les traitements impliquant une forte dpense dnergie telles que les communications. Le traitement de ces contraintes peut senvisager plusieurs niveaux : bien videmment elles doivent tre considres et spcies au niveau de la modlisation du systme dans son ensemble. Mais elles doivent galement tre traites au niveau de la conception logicielle puisquelles ont un impact sur la manire dont le logiciel doit fonctionner. Ce type dentrelacement entre le logiciel et son support matriel est naturel pour un ingnieur systme alors quil lest habituellement moins pour un ingnieur logiciel. Ce dernier devra donc avec SysML savoir prcisment jusqu quel niveau de rafnement il doit modliser son systme. Par exemple,
3 Le Pau Broadband Country http://paubc.info est un projet visant tester la viabilit dun rseau trs haut dbit dans une agglomration.

N. Belloir et al.

SysML permet de modliser une architecture matrielle, mais on peut se demander sil est pertinent de le faire dans le cas o le projet modliser rutilise du matriel existant.

F IG . 2 Exemple de diagramme SysML dexpression des besoins

Grce aux bases UML de SysML les ingnieurs logiciels peuvent se familiariser facilement avec la plupart des diagrammes SysML. Seuls les diagrammes paramtriques ou les diagrammes des besoins sont rellement nouveaux (OMG, 2007b, p.11). En fait, si lon regarde la pratique, en ingnierie logicielle les besoins sont exprims la plupart du temps dans dautres langages quUML. Lutilisation des diagrammes de cas dutilisation, de classe, ou encore de squence tt dans la phase danalyse permet de vrier la bonne comprhension des besoins plutt que de les spcier. De plus, en UML les besoins ne sont pas relis aux diagrammes correspondants. Cela implique donc pour lingnieur logiciel un effort dattention lev pour sassurer que tous les besoins se retrouvent bien dans la spcication nale UML puisquil na aucune traabilit sa disposition. Cependant, les diagrammes des besoins en SysML ne sont pas non plus exempts de reproche. Sils permettent effectivement dintroduire une traabilit entre un besoin et le (ou les) diagramme(s) ralisant ce besoin, ils consistent en fait simplement en un lment structurel contenant une description textuelle du besoin. On peut galement faire des drivations de besoins ou bien crer une hirarchie de besoins, mais cela semble lger pour rpondre la demande forte dexpression bien formalise - et automatise - des besoins dans les langages de modlisation. La gure 2 montre un diagramme dexpression des besoins. Celui-ci spcie des proprits lies au besoin dconomie dnergie. Le bloc Longevity est un besoin de haut niveau. Le bloc ConrmReception est beaucoup plus prcis. La relation <<derive>> montre que le second besoin dcoule directement du premier. Dans

Utilisation de SysML pour la modlisation des rseaux de capteurs

la partie basse de la gure, on trouve le diagramme dtat NominalBehavior qui satisfait le besoin ConrmReception (lien de type <<satisfy>>) ainsi que le cas de test EvaluateConrmReception qui vriera la bonne implmentation de ce besoin.

F IG . 3 Exemple de diagramme paramtrique

Les diagrammes paramtriques reprsentent la seconde nouveaut de SysML. Ils offrent la possibilit dexprimer des proprits mathmatiques entre diffrents lments dun modle. En cela ils offrent un apport considrable par rapport UML o ce type de notation ntait possible qu travers des contraintes textuelles ou exprimes dans le langage formel OCL. Par exemple, dans le cadre de notre tude, ces diagrammes nous ont permis de spcier des contraintes portant sur la porte dune mission WiFi. En effet, nous spcions le fait quun capteur mobile ne rentre en communication avec un capteur xe que si celui-ci est une porte dau moins 20% de sa puissance dmission. Pour cela, il nous faut calculer laffaiblissement en espace libre, chose que nous spcions sur la gure 3 : lquation, tire de Stallings (2005), est spcie laide du bloc de contrainte FreeSpaceLoss. Les paramtres Pt et Pr sont transmis par le bloc radio. Pour lexpression des contraintes, la possibilit dutiliser OCL est prserve bien que non explicitement exprime dans la spcication ( part dans lutilisation dun bloc particulier appel constraint block et utilisable uniquement sur les diagrammes de dnition de bloc ou les diagrammes de package, ce qui est limitatif).

N. Belloir et al.

De la mme manire quUML, SysML nest quun langage de modlisation. Cela signie quil ny a pas de mthode associe spciquement au langage. On peut toutefois rutiliser des rgles de bonne utilisation naturelles. Ainsi, une fois les besoins tablis, il semble opportun de se consacrer ltablissement des cas dutilisation. En SysML, dans ce type de diagramme, mme si la smantique est identique celle dUML, on note dans la pratique que les acteurs du systme seront la plupart du temps des systmes externes plutt que des acteurs humains. Dans notre tude de cas, les acteurs ne sont pas seulement les personnes portant les capteurs mobiles ou encore loprateur rcoltant les donnes ; les diffrents types de capteurs (mobiles, xes relis au rseau ou xes non relis au rseau) sont galement des acteurs. Une fois les cas dutilisation raliss, il est possible de spcier les diagrammes de bloc et dinteraction an davoir une premire vue du systme. Le diagramme de dnition de bloc et le diagramme de bloc interne qui correspondent, respectivement au diagramme de classe et au diagramme composite en UML, peuvent trangement se rvler difcile crer pour un ingnieur logiciel. En effet, le point difcile notre avis concerne le niveau de profondeur de la modlisation matrielle qui doit tre mise en uvre. Par exemple, un mme bloc peut tre considr comme un composant lectronique ou comme un composant logiciel. Une interaction entre deux blocs peut tre vue comme une liaison lectrique, comme un lien logiciel portant des messages binaires ou comme un change de messages entre deux composants logiciels. Pour preuve, dans notre tude, la modlisation des changes entre deux capteurs peut tre traite bas niveau (trame rseaux) ou encore dun point de vue haut niveau (change de messages). On peut encore vouloir exprimer des contraintes concernant la puissance ou le rythme des missions radio pour conomiser la batterie. Ainsi, il convient de bien cibler ce que lon veut prcisment modliser.

F IG . 4 Diagramme de dnition de bloc

La gure 4 prsente le diagramme de dnition de bloc spciant une vue haut niveau dun capteur mobile. On peut remarquer facilement une imprcision du langage. En effet, le bloc mote, qui reprsente la carte mre de la partie calculatoire du capteur mobile est li au bloc platform via une composition de mme type que celle qui lie le bloc battery platform. Or, la composition entre platform et battery vient du lien physique entre les deux, comme pour mote,

Utilisation de SysML pour la modlisation des rseaux de capteurs

mais alors quon peut imaginer changer la batterie, il est impossible de changer la carte mre. Il y a donc un manque au niveau de la spcication. Faut-il alors supprimer mote et linclure dans platform ? Cela aurait pour consquence de rendre cet lment moins visible. Se pose galement le problme de la reprsentation interne de platform (voir la gure 5) car dans ce cas le mote devient central, ce quil ntait pas dans le diagramme de dnition de bloc. Une heuristique pourrait alors en dcouler : si un bloc est central, alors il faut linclure dans le bloc principal. Lautre solution serait dajouter des proprits sur les relations de composition, telles que la non sparabilit, comme nous lavons propos dans Belloir (2004).

F IG . 5 diagramme de reprsentation interne de bloc

Discussion

Dans cette section, nous allons tenter dvoquer les avantages et les inconvnients de lutilisation de SysML pour le dveloppement des systmes du type WSN. Dans le cadre de cet article, nous limiterons essentiellement nos rexions aux diagrammes structuraux.

5.1

De la question de la smantique

Si lon regarde lvolution des diffrentes versions dUML, on constate quun effort rcurrent a t port sur lamlioration du pouvoir dexpression du langage paralllement une meilleure dnition de la smantique associe aux lments du langage. Cependant ces deux axes sont parfois antinomiques. Pour sen convaincre, prenons le cas de la reprsentation dun lment contenant un autre lment. En UML 1.x, le concepteur devait exprimer cette contenance laide des relations dagrgation et de composition, relations dont Barbier et al. (2003) ont montr limprcision smantique. UML 2 a rvolutionn les moyens de reprsenter cette

N. Belloir et al.

contenance grce au concept de classe structure, bien plus visuel. Cependant, leur smantique, au lieu damliorer et de simplier les choses, ne fait quaccentuer le doute puisque, non seulement les relations de composition et dagrgation sont toujours disponibles, mais en plus leur smantique reste imprcise comme montr par Belloir (2004). Aprs exprimentation de SysML, il savre que le nouveau langage napporte pas dclaircissement sur ce point. En effet, si lon considre par exemple un bloc, ce qui est lintrieur peut tre envisag suivant de nombreux points de vue. Par exemple, lintrieur dun capteur mobile peut tre modlis suivant sa structure lectronique, lectrique ou encore informatique suivant que le concepteur sintresse lun ou lautre. La difcult vient lors des phases transitoires au cours desquelles le type - ou la technologie - concern peut varier. Cela ne fait quajouter un point de variation smantique cause notamment du large champ smantique couvert par le concept de bloc. On trouve l la limite de la gnralisation de ce concept et il semble invitable lors dun projet de rapidement devoir typer les diffrents blocs selon le domaine modliser. En SysML, les diagrammes de bloc (BDD) et les diagrammes internes de bloc (IBD) sont directement hrits dUML (Diagramme de Classe et Diagramme de Structure Composite) en y apportant des restrictions et des extensions (OMG, 2007b, p.44). Les liens entres les deux notations sont donc parfois assez vidents, mme si du coup lutilisation doutils SysML, pour la plupart assez rcents, provoque des situations paradoxales (cf. gure 6 o loutil permet dinsrer une classe au lieu dun bloc dans un IBD). Notons que cela nest pas possible avec Enterprise Architect.

F IG . 6 Hritage de menus contextuels avec Embedded Plus

5.2

Utilisation de SysML : jusquo ?

Lors de notre exprimentation de SysML nous avons t amen nous poser la question du passage lchelle. en effet, au travers dun cas concret relativement peu complexe en terme de taille ou de nombre de composants en jeu, nous avons dj t confronts un certain nombre dinterrogations. Parmi ces dernires, la question de la profondeur de modlisation nous a sembl particulirement importante dterminer. En effet, mme si ce jour aucune mthode dingnierie systme ne sappuie sur SysML, il est clair que ce langage, linstar dUML, est plutt orient

Utilisation de SysML pour la modlisation des rseaux de capteurs

vers une approche de rafnements successifs. Cela tant pos, un certain stade de la modlisation, on se trouve confront des diagrammes sur lesquels on a identi les lments matriels et logiciels. Ltape suivante consiste donc modliser ces mmes lments dun point de vue technique. Par exemple, lorsquun bloc est identi comme logiciel, il est alors ncessaire de le modliser dun point de vue logiciel et non plus systme, avec des lments spciques au logiciel (classe, objet . . .). De mme lorsquon a identi un bloc lectronique, il va falloir produire des schmas sur lesquels on spciera des lments spciques ce domaine (diodes, transistors, micro-processeurs . . .). On peut parler de conception avance. Le problme qui se pose alors est que SysML ne permet pas de spcier cela. Il convient alors de se tourner vers des langages de modlisation adapts ces domaines. Ainsi, SysML peut tre vu comme un langage de haut niveau permettant lanalyse et la conception de systmes complexes jusqu une certaine granularit, mais qui nest pas sufsant pour le dveloppement complet dun systme. A un certain stade, il est ncessaire de passer un langage plus spcique au sous-systme modlis, comme UML pour le cas de sous-systmes logiciels. Le passage un langage de modlisation plus spcique lors de la conception avanc pose plusieurs problme. Dune part, comment passe-t-on dun lment SysML un lment reprsentant la mme entit mais dans un langage diffrent. Si lon considre le cas dUML, le bloc reprsentant un lment logiciel va se retrouver sous la forme dune classe ou dun composant. Le cas dUML est dailleurs particulier puisque SysML est un prol UML. Dautre part, on est amen se demander comment prserver (et/ou transfrer) les proprits ou les contraintes spcies avec SysML en phase amont. Si lon prend une des caractristiques nouvelles de SysML, comment lier par exemple un <<requirement>> et les lments de traabilit affrents avec des lments de modlisation de diagrammes UML (comme par exemple une classe) ? La spcication SysML ne dit rien ce sujet. Notons ici un paradoxe de lapproche. SysML est dni comme un nouveau langage mais a t cr sous la forme dun prol UML. Cela permet donc en thorie de mlanger la fois des concepts UML et des concepts SysML. Si cette approche permet dtendre le pouvoir dexpression dUML, en revanche on est en droit de se poser la question de la smantique qui en rsulterait. Que dire par exemple dun diagramme dexpression des besoins indiquant quun besoin est satisfait par une classe alors que le concept de classe nest pas dni dans SysML ? Et mme si cette reprsentation tait satisfaisante, ce que nous ne croyons pas, quen est-il du passage de SysML un langage autre que UML ? Enn, si lon pose comme rgle de passer UML ds quun lment du modle est identi comme logiciel, on est confront au problme de la cohrence du modle UML dans sa globalit. En effet, si le passage un diagramme de classe partir dun bloc semble ais, il nen est pas forcment de mme pour les autres diagrammes. Par exemple, est-il ncessaire de rpter en UML un diagramme de squence SysML mettant en scne linteraction entre deux blocs logiciels ? Dans lafrmative, on se retrouve avec un risque de duplication de linformation et donc un risque de dsynchronisation entre le diagramme SysML et le diagramme UML. Dans la ngative, le modle UML ne sera pas complet. Et dans le cas dun bloc logiciel auquel serait attach un diagramme paramtrique, comment traduire ce dernier en UML ? On le voit la rponse ces questions ncessite un effort de clarication de la part de la communaut. Lautre grand absent dans la mouvance SysML est laspect mthodologique. En effet, si UML vient du besoin dunier les mthodologies objets, ce quoi il a par ailleurs chou, SysML rpond lui une tentative de cration dun nouveau standard pour la conception des systmes. Ses bases mthodologiques lies au domaine de lingnierie systme sont donc en-

N. Belloir et al.

core moins fournies. sachant que SysML, comme UML, est une notation et non une mthode, on peut se demander quelle approche particulire est la plus adapte, et en particulier sil faut se tourner vers les mthodes issues de lingnierie des systmes ou bien adapter les mthodes logicielles. Lautre challenge auquel SysML devra rpondre est celui de la normalisation. En effet les divers domaines de lingnierie systme sont souvent fortement contraint par des normes svres (aronautique, automobile . . .). La normalisation du langage ainsi que linsertion du langage au sein de processus normalis prendra sans doute du temps.

5.3

Retour sur exprience

Cette tude de cas nous a permis de mettre en uvre une modlisation en langage SysML. Nous donnons ici notre retour sur exprience concernant dune part SysML et dautre part lapport de SysML la modlisation des rseaux de capteurs. Cette tude a lev quelques interrogations qui ne semblent pouvoir tre rsolues quaprs un certain nombre dexpriences pratiques, notamment industrielles. Pour ce qui est de notre exprience, nous pouvons simplement avancer quelques pistes de rexion et quelques commentaires sur lutilisation conjointe des deux notations : La documentation SysML permet de mettre en uvre sans trop de problme les nouveaux diagrammes. Pour des dveloppeurs habitus manipuler les concepts UML 2 de port ou de connecteur, le passage au concept de bloc ne pose aucun problme, si ce nest la perptuelle interrogation sur le niveau de dtail entre logiciel et matriel. Les outils SysML commencent tre utilisables. Pour notre part nous avons essay IBM Rational Software Modeler avec le plug-in SysML dEmbeddedPlus Engineering4 et Topcased5 . Tous deux possdent linconvnient dtre principalement issus doutils UML 2 existants. Lavantage est lintgration dans un mme outil des deux langages utiliser. Linconvnient est lamalgame fait parfois entre les deux notations, comme nous lavons illustr en gure 6. Une des avances qui nous semble signicative dans lutilisation de SysML concerne le concept de requirement. En effet, non seulement il permet dexprimer directement les besoins l o UML permettait uniquement de les reprsenter avec des cas dutilisation et des notes par exemple, cest--dire un stade de conception un peu plus avanc. Les relations de traabilit de SysML sont plus prcises que par exemple les relations de type <<trace>> ou <<dpendance>> dUML. Mme si les outils actuels ne permettent pas de rendre toute lutilit dun tel concept (trace arrire quand on dtecte la violation dune contrainte par exemple), il nous semble fort intressant, surtout dans un contexte o le matriel et le logiciel sont trs lis. Peut-tre que le dveloppement de SysML verra les ingnieurs systme se rapprocher des notations des ingnieurs logiciels. SysML a par exemple rduit le nombre de diagrammes UML pour simplier le nombre de concepts utiliss. Mais si on extrapole lexprience de larrive dUML 2 pour la communaut des ADLs, comme dcrit par Bruel (2007), il semble que les changements de rexes soient trop difciles mettre en place dans des communauts trs ancres dans leurs habitudes (comme dans laronautique par exemple).
4 Cf. 5 Cf.

lURL : http://www.embeddedplus.com lURL : http://www.topcased.org

Utilisation de SysML pour la modlisation des rseaux de capteurs

Dautre part, lutilisation de SysML pour la modlisation des rseaux de capteurs a globalement t concluante. En effet, la prise en compte des aspects systmes permet de bien identier ce qui est du ressort de lingnierie systme et ce qui du ressort de lingnierie logicielle. Lautre aspect intressant concerne lajout des diagrammes paramtrique qui vont permettre de spcier notamment sur un mme modle des quations mathmatiques importantes dans le cadre de systmes mobiles (localisation dun capteur, puissance dmission . . .). Nous navons pas trait en profondeur les aspects lis au capteurs physiques, considrant que nous rutilisions ceux fournis avec les capteurs mobiles. Il est certain que SysML reprsenterait un grand intrt dans le cadre dun systme dans lequel le dveloppement de matriel serait une des actions raliser.

Conclusion

Dans le domaine de lingnierie logicielle, UML a apport une indniable rvolution, devenant une norme de fait. Lingnierie systme tente de franchir ce mme cap en proposant aux ingnieurs systme le nouveau langage SysML. Lapparition de nouvelles technologies comme les rseaux de capteurs sans l dans lesquelles le logiciel et le matriel sur lequel celui-ci est dploy sont fortement entrelacs, ncessitent de nouveaux supports de modlisation. En effet, lentrelacement de ces deux mondes prcdemment souvent disjoints, impose de tirer le meilleur parti possible des avances des deux domaines. Dans ce cadre, nous avons men une tude de cas utilisant conjointement UML et SysML an de modliser une application base sur un rseau de capteurs sans l pour faire du recensement urbain. Cette tude a mis en relief des points trs positifs. Lutilisation de SysML apporte un rel bnce par rapport UML pour la modlisation de contraintes lies au matriel, la dnition et la traabilit des besoins ou encore lexpression de contraintes mathmatiques. Ce langage savre galement un bon moyen de communication avec des ingnieurs mtiers grce notamment au concept gnrique de bloc. Il y a fort parier que certaines de ces avances vont rapidement se rpercuter dans UML. Cependant, nous avons eu nous confronter plusieurs aspects contraignants. Parmi ceuxci, le manque de prcision pour trouver la charnire entre lutilisation de SysML et dUML (ou dautres langages et/ou mthodes de conceptions lis des domaines spciques tels que la mcanique, llectronique ou lhydraulique) nous a souvent gn. Dautre part, le fait que les outils mettant en uvre SysML sont issus doutils UML rend cette frontire encore plus tnue et nous parat tre source de malentendus. De plus, la gnricit du concept de bloc est source galement dincomprhensions et ncessite dtre rapidement prcise lors de la modlisation. Enn, malgr la liation avec UML, il y a un manque dans la littrature dtudes de cas mettant en uvre SysML an davoir une vision plus exhaustive des possibilits du langage. Gageons que cela aidera adapter les normes et les mthodes de dveloppement systme souvent fort contraignantes et supportant mal ce type de langage graphique. Cette tape est indispensable pour permettre SysML de passer du coup dessai au coup de matre. Pour nous, cette tude a mis en vidence lintrt et les manques dun tel langage et la ncessit dun effort de recherche soutenu pour le dvelopper. Ainsi, nous avons pour objectif dinvestir ce champ de recherche. Pour ce faire, nous comptons travailler rpondre aux questions identies dans le paragraphe prcdent. Plus particulirement, nous nous intressons amliorer linteraction entre UML et SysML. Cela revient dune part dterminer prcisment

N. Belloir et al.

le niveau partir duquel le langage orient systme quest SysML devient trop spcique au domaine du systme pour permettre une modlisation de qualit du logiciel devant fonctionner sur ce systme. Dautre part, nous comptons nous appuyer sur les techniques dingnierie des modles et de transformations de modle an la fois dautomatiser au maximum le passage dun modle un autre et de garantir galement le respect des contraintes et les liens de traabilit exprims avec SysML.

Remerciements
Ce travail est nanc la fois par la Communaut dAgglomration de Pau Pyrnes6 travers le nancement dune bourse de thse et par la rgion Aquitaine7 via le nancement dune plate-forme de test de rseaux de capteurs. Nous les remercions pour leur soutien.

Rfrences
Barbier, F., B. Henderson-Sellers, A. L. Parc-Lacayrelle, et J.-M. Bruel (2003). Formalization of the Whole-Part Relationship in the Unied Modeling Language. IEEE Transactions on Software Engineering 29(5), 459470. Belloir, N. (2004). Composition logicielle base sur la relation Tout-Partie. Ph. D. thesis, Universit de Pau et des Pays de lAdour. Boehm, B. (2006). Some Future Trends and Implications for Systems and Software Engineering Processes. Systems Enginnering 9(1), 119. Bruel, J.-M. (2007). Composition logicielle laide de machine tats. Gnie Logiciel (80), 26. ISSN : 0295-6322. Feiler, P. H., D. P. Gluch, et J. J. Hudak (2006). The Architecture Analysis and Design Language (AADL) : An Introduction. Technical Note CMU/SEI-2006-TN-011, Software Engineering Institute. Friedenthal, S., A. Moore, et R. Steiner (2007). OMG Systems Modeling Language Tutorial. http://www.omgsysml.org/INCOSE-2007-OMG-SysML-Tutorial.pdf. Harel, D. et B. Rumpe (2004). Meaningful Modeling : Whats the Semantics of "Semantics" ? IEEE Computer 37 (10), 6472. Khemapech, I., I. Duncan, et A. Miller (2005). A survey of wireless sensor networks technology. In PGNET, Proceedings of the 6th Annual PostGraduate Symposium on the Convergence of Telecommunications, Networking & Broadcasting. OMG (2005). UML 2.0 Superstructure Final Adopted specication formal-05-07-04. OMG document, Object Management Group. OMG (2007a). A UML Prole for MARTE. OMG document ptc/07-08-04, Object Management Group. OMG (2007b). OMG Systems Modeling Language Specication. Technical Report formal/0709-01, Object Management Group.
6 http://www.agglo-pau.fr 7 http://aquitaine.fr/,

numro de projet : 20061104047

Utilisation de SysML pour la modlisation des rseaux de capteurs

Sachdeva, G., R. Dmer, et P. Chou (2005). System Modeling : A Case Study on a Wireless Sensor Network. Technical Report TR-05-12, Center for Embedded Computer Systems, Irvine, California. Satyanarayanan, M. (2001). Pervasive computing : vision and challenges. IEEE Personnal Communications 8(4), 1017. Stallings, W. (2005). Rseaux et communication sans l. Pearson education. Szyperski, C., D. Gruntz, et S. Murer (2002). Component Software Beyond Object-Oriented Programming Second Edition. ACM Press. New York, NY : Addison-Wesley.

Summary
SysML is the new system modeling language promoted by the OMG. It can be seen as an extension of UML that targets the modeling of a broad range of complex systems. Its application eld is then wider and its UML roots are useful to design embedded systems mostly composed by software. Applications deployed on wireless sensor networks (WSN) are a good example of such applications as the interactions between hardware and software components are of prime importance in the design of efcient sensor networks. In this paper we describe our feed-back, based on a case study that models a WSN system. In this case study, we have used both SysML (to design the complete system) and UML (to model the software parts). We present the overlapping of the two languages and we compare the both structural diagrams of theses languages.