IBM Rational White Paper

Janvier 2011

Modlisation SysML par la Pratique

Philippe Leblanc, IT Specialist, IBM Rational 1.0

Modlisation SysML par la Pratique

Table des Matires

2 Introduction 2 Processus de modlisation 4 Introduction ltude de cas 4 Analyse des exigences 6 Analyse fonctionnelle
6 6

Processus de modlisation
Le processus appliqu ici est bas sur la recommandation mthodologique de Rational appele Harmony/SE (SE pour System Engineering). Ce processus se focalise sur les activits dingnierie systme avec le formalisme SysML. Il est complt par le processus de dveloppement Harmony/ESW pour le logiciel embarqu. Dans cette tude, nous nous limiterons la partie SE. Le processus est dcrit en gure 1. Il se compose de trois grandes phases excutes suentiellement : 1. Analyse des exigences (Requirements Analysis) : spcication et analyse des exigences sous la forme de requirements SysML. 2. Analyse fonctionnelle (Functional Analysis) : construction des diagrammes de cas dutilisation, description dtaille des cas dutilisation en diagrammes dactivit et/ou diagrammes de squence en mode bote noire. 3. Architecture du systme (Design Synthesis) : dcomposition du systme en composants, spcication des interfaces du systme et de ses composants, rafnement des diagrammes dactivit et/ou diagrammes de squence du mode bote noire au mode bote blanche. Cette phase inclut aussi la spcication du comportement : spcication du comportement au niveau des composants changements de mode, algorithmiques, fonctions... au moyen de diagrammes dtat et de diagrammes dactivit (ou owcharts) et vrication du comportement.

Cas dutilisation UC1 Traiter les donnes Cas dutilisation UC2 Grer lalimentation

7 Architecture du systme et des interfaces 10 Description du comportement 13 Traabilit 15 Conclusion 16 Rfrences

Introduction
Cet article montre le formalisme SysML2 appliqu un exemple. SysML est la variante du formalisme de modlisation UML 2.04 dnie conjointement par lOMG et lINCOSE pour lingnirie systme. Lexemple que nous avons choisi est assez simple pour tre compris par tous rapidement mais il se veut reprsentatif des problmatiques traditionnelles en ingnierie des systmes techniques. Nous assumons que le lecteur connat SysML. Nous nous focalisons sur lanalyse du problme choisi plus que sur les dtails de ce formalisme. En particulier, nous ne prtendons pas lexhaustivit, mme si nous avons cherch montrer la varit des possibilits de modlisation en SysML. Nous avons aussi suivi un processus de modlisation bas sur la mthodologie Harmony/SE1 dnie par IBM Rational. Le processus appliqu est dcrit en premire section. La suite du document prsente le modle, de la spcication des exigences la dnition de larchitecture et du comportement. Le modle SysML prsent ici a t conu avec loutil IBM Rational Rhapsody Designer for Systems Engineers3.

Requirements Analysis Requirements

Functional Analysis

Identify usecases Detail usecase scenarios

Usecases

ActivityDiagrams

Design Synthesis

SequenceDiagrams

Decompose system BlockDiagrams Identify Interfaces

Refine usecase scenarios

Specify behavior for component and verify

Statecharts

Figure 1 : Processus de modlisation SysML appliqu

Modlisation SysML par la Pratique

Introduction ltude de cas

Nous cherchons concevoir un quipement embarqu mobile constitu dune batterie et dune carte de traitement qui transforme des entres en sorties un dbit xe. La carte est alimente par une batterie. Celle-ci se recharge quand le systme est connect un rseau lectrique. Cet quipement est rsidant sur une plateforme mobile. Nous nous intressons essentiellement modliser la gestion de lalimentation et le passage entre le mode de fonctionnement normal (batterie bien charge) et le mode conomique (batterie faible). Le dbit de traitement est dpendant du mode : rapide en mode normal, lent en mode conomique. Ce systme sera appel quipement mobile (Mobile Device) dans la suite de larticle. Les exigences de lquipement mobile sont dtailles dans la section suivante.

Analyse des exigences

Nous avons captur les exigences du systme dans le diagramme des exigences (Requirement Diagram) vu en gure 2. Les exigences de lquipement sont rparties en trois catgories : CAT-GEN : Quatre exigences sont exprimes sur son fonctionnement gnral et son architecture ; CAT-PROC : Trois exigences sont exprimes sur les dbits de traitement autoriss lorsque lquipement est connect au rseau lectrique ou non ; CAT-POW : Trois exigences sont exprimes sur la gestion de lalimentation passage de normal conomique et passage dconomique teint. Pour plus de dtails sur ces exigences, se rfrer au diagramme de la gure 2. Ce diagramme des exigences va nous permettre dtablir ultrieurement lintrieur du modle des liens de traabilit entre les exigences et les lments de modlisation fonctionnelle et darchitecture.

Requirement

Cat001

ID = CAT-GEN General requirements

Req001 ID = REQ-GEN-1 The Portable Dev is a piece of ice equipment embedded on a mobile platform.

Req002 ID = REQ-GEN-2 The Portable Dev process es input ice data and produc es output data.

Requi rement

Req010

Requi rement

Req011

ID = REQ-GEN-3 The Portable Dev is made of a ice main proc essor in charge of the data proc essing and a battery delivering electrical power to the main p

ID = REQ-GEN-4 The battery charges when connected to the elec trical network.

Requirement

Cat002

ID = CAT-PROC Requirements linked to data proc essing

Requi rement

Req004

Requirement

Req007

Requirement

Req008

ID = REQ-PROC-1 When c onnected to the electric al network, the Portable Device processes its input data at a rate of 1 element eac h 500 ms.

ID = REQ-PROC-2 When disconnected in normal mode, the Portable Device proces ses its input data at a rate of 1 element per eac h 500 ms.

ID = REQ-PROC-3 When dis connected in ec onomic mode, the Portable Device proces ses its input data at a rate of 1 element per eac h 1 s ec.

Requirement

Cat003 ID = CAT-POW Requirements linked to electricity power

Requirement

Req005

Requirement

Req006

Req003 ID = REQ-POW-3 When c onnected to the electric al network, the battery is charging and stops charging when the maximum capacity is reached.

ID = REQ-POW-1 When disc onnected from the elec trical network, the battery s witches from normal mode to economic mode when its capacity becomes below 25% of its maximum capacity .

ID = REQ-POW-2 When dis connected from the electrical network, the battery shuts down when its capacity becomes below 5% of its maximum capacity.

Figure 2 : Diagramme des exigences de lquipement mobile

Modlisation SysML par la Pratique

Analyse fonctionnelle
Lanalyse fonctionnelle est pratique par la mthode des cas dutilisation (use case). Nous avons identi deux cas dutilisation : UC1 Traiter les donnes UC2 Grer lalimentation Ces deux cas dutilisation sont en relation chacun avec un acteur, respectivement la plate-forme mobile qui accueille lquipement et le rseau lectrique. Le diagramme de cas dutilisation (Usecase Diagram) est prsent en gure 3.
evInputData() ev OutputData()
MobileDevice

:MobilePlatform

:MobileDevice

alt

[Normal Mode] evInputData() ev OutputData()

<200 ms

[Eco Mode]

<1 sec

UC1 process data

MobilePlatform UC2 manage electrical power

Figure 4 : Diagramme de squence

ElectricalNetwork

Le diagramme de squence est bien adapt pour dcrire ce cas dutilisation car cet UC est de type squence dchanges entre lacteur et le systme.
Figure 3 : Diagramme de cas d'utilisation

Cas dutilisation UC1 Traiter les donnes

Cet UC est en charge du traitement des donnes en entre. Nous lavons dtaill au moyen dun diagramme de squence (Sequence Diagram) vu en gure 4.

Nous avons introduit un fragment combin de type alternative (alt) de manire spcier les comportements attendus en mode normal traitement dans les 200 ms et en mode conomique traitement dans la seconde.

Cas dutilisation UC2 Grer lalimentation

Cet UC est en charge de la gestion de lalimentation de lquipement : la batterie alimente la carte de traitement, la batterie est en charge quand elle est connecte au rseau lectrique. Nous lavons dtaill au moyen dun diagramme dactivit (Activity Diagram) vu en gure 5.

block MobileDev ice

Actor ElectricalNetwork

Architecture du systme et des interfaces

Lors des tapes prcdentes nous avons captur dans le modle SysML les exigences, identi les cas dutilisation et nous les avons dtaills au niveau systme. Maintenant il nous faut concevoir larchitecture du systme rpondant ces besoins. Pour cela nous allons identier les sous-systmes ou composants du systme et spcier leurs interfaces. Cette conception sappuie sur une analyse des exigences, en particulier la prise en compte de lexigence REQ-GEN-3. Pour dcrire cette solution, nous avons cr un diagramme de dnition de bloc ou BDD (Block Denition Diagram), voir gure 6 : son objectif est de dnir chaque entit de larchitecture le systme et ses composants et pour chacune delles ses entres / sorties par des ports et des interfaces.

continuous provide Power to Processor charge Battery

generate Current

continuous

continuous

Battery

Figure 5 : Diagramme d'activit

Le diagramme dactivit est appropri pour dcrire ce cas dutilisation car il nous permet de le dtailler sous la forme de ots dactivit ce qui correspond bien au fonctionnement squentiel de cet UC. Dans ce diagramme dactivit, nous avons utilis les possibilits suivantes : Utilisation de fork et join pour montrer des activits sexcutant en parallle ; Utilisation de ot <<continuous>> pour montrer quun ot entre deux activits est continu : llectricit est fournie en continu de lactivit amont lactivit aval (spcicit SysML) ; Utilisation dobject node pour montrer quune activit vient alimenter / consommer un rservoir de donnes, ici llectricit.

Modlisation SysML par la Pratique

pIn In_Device

MobileDevice

block

pOut Out_Device

altCurrent:RhpInteger

1 pIn In_Device MainProcessor timeIntervalInNormalMode:RhpInteger=500 timeIntervalInEcoMode:RhpInteger=1000 curTiming:RhpPositive=0 directCurrent:RhpInteger

block

1 PowerSupply altCurrent:RhpInteger=0 charge:RhpInteger=0 maxCapacity:RhpInteger=100 maxAltCurrent:RhpInteger=10 chargeTimeInterval:RhpInteger=1000 directCurrent:RhpInteger=0 inUse:RhpBoolean=false altCurrentReal:float=0.0

block

pOut Out_Device

opProcessData():void

altCurrent:RhpInteger

pElec I_ConsumerToPower

directCurrent:RhpInteger

opCharge():void opControlBattery():void opDischarge():void directCurrent:RhpInteger pElec I_ConsumerToPower

Figure 6 : Diagramme de dnition de bloc

Ce diagramme montre des dnitions de blocs, il ne peut pas montrer comment les diffrents composants du systme sont connects entre eux. Pour spcier cette communication, nous devons construire un diagramme interne de bloc ou IBD (Internal Block Diagram). La gure 7 prsente lIBD pour le bloc systme MobileDevice. Ce diagramme montre clairement que lquipement est constitu de deux composants, une carte de traitement appele MainProcessor et une alimentation

appele PowerSupply. La carte de traitement reoit les entres venant de lextrieur et produit des sorties vers lextrieur. Lalimentation est connecte au rseau lectrique via un port de ot (owport) reprsentant un ot continu de courant lectrique (do la che dans le carr reprsentant le port). Les deux composants sont connects ensemble pour schanger des informations lies la consommation lectrique de la carte de traitement (information de la carte vers lalimentation) et ltat de la batterie (information de lalimentation vers la carte).

MobileDevice 1 In_Device pIn pIn In_Device pElec directCurrent:RhpInteger I_ConsumerToPower proc:MainProcessor pOut Out_Device pOut Out_Device

block

directCurrent:RhpInteger 1 power:PowerSupply

I_ConsumerToPower pElec altCurrent:RhpInteger

altCurrent:RhpInteger
Figure 7 : Diagramme interne de bloc

On peut noter que les ports des deux composants sont des ports dits behavioral signiant quils alimentent directement une machine dtat, alors que les ports au niveau systme

sont des ports relay servant simplement de relai entre lextrieur et les composants sans effectuer de traitements spciques.

10 Modlisation SysML par la Pratique

Pour tre complet, il faut aussi dnir les interfaces. Leurs dnitions sont montres dans le diagramme en gure 8.
In_Device
Interface

Description du comportement
A ce stade notre modle contient les exigences, lanalyse par cas dutilisation et larchitecture. Nous allons maintenant le complter avec la description de la dynamique et des traitements. SysML nous offre essentiellement trois moyens : Dclarer des oprations sur les blocs ; Spcier le traitement de ces oprations au moyen de diagrammes dactivit ; Spcier les automates associs aux blocs au moyen de diagramme dtat ; ces diagrammes vont prciser les changements de mode : tat de dpart, tat darrive, traitement (opration) excut sur le changement de mode. Les oprations dnies sur les blocs sont visibles dans le compartiment du bas des blocs visibles dans le BDD en gure 6 : Block PowerSupply : opration opCharge active lorsque la batterie est connecte au rseau, opration opDischarge active lorsque lon consomme du courant de la batterie, opration opControlCharge en charge du contrle de ltat de chargement de la batterie. Block MainProcessor : opration opProcessData en charge du traitement des donnes dentre pour produire les donnes de sortie. Ce diagramme de la gure 6 montre aussi les donnes possdes par chacun des blocs. Ces donnes sont utiles pour les traitements et les changes : Block PowerSupply : donne current reprsente le courant dlivr par le rseau lectrique lorsque la batterie est connecte elle est directement associe au owport current , donne charge reprsente ltat de charge de la batterie en pourcentage de la charge totale, donne maxCharge reprsente la charge maximale de la batterie en milliWattxHeure.

Out_Devic e evOutputData()

Interface

evInputData() evOn() evOff()

I_ConsumerToPower Direc tCurrentValues

DataType

Interface

evInUse() evNotInUse()

Figure 8 : Dnition des interfaces des composants

La carte de traitement reoit des signaux asynchrones en entre de type evInputData avec comme donne une chane de caractres (permet ainsi de modliser aisment nimporte quel type dinformation) et met des signaux asynchrones en sortie du type evOutputData avec comme donne une chane de caractres. Lalimentation reoit un courant continu de lextrieur. La carte envoie lalimentation un niveau de consommation et en retour lalimentation fournit le niveau de la batterie, ce qui va faire basculer la carte en mode normal, conomique ou teint. La nouvelle tape dans notre processus serait de reprendre le diagramme de squence de la gure 4 et le diagramme dactivit de la gure 5 en introduisant les composants sous forme de lignes de vie dans le premier diagramme et sous forme de partitions (swimlanes) dans le second diagramme. Etant donn les cas dutilisation identis, il suft simplement de remplacer la ligne de vie MobileDevice par une ligne de vie MainProcessor dans le diagramme de squence, et de remplacer la partition MobileDevice par une partition PowerSupply dans le diagramme dactivit. Pour un systme plus complexe, nous aurions t amens dans le diagramme de squence ventiler les changes entre lignes de vie et en faire apparatre de nouvelles, et dans le diagramme dactivit rpartir les activits et les object nodes.

11

Block MainProcessor : donne timeIntervalInNormalMode reprsente le temps en millisecondes entre deux donnes dentre en mode normal, donne timeIntervalInEcoMode reprsente le temps en millisecondes entre deux donnes dentre en mode conomique (batterie faible), donne curTiming reprsente la valeur courante du temps choisi elle vaut soit timeIntervalInNormalMode, soit timeIntervalInEcoMode , donne neededPower reprsente la puissance lectrique dlivre par la batterie et qui est consomme par le traitement dune rception de donne. Lautomate de la batterie (block PowerSupply) est dcrit en gure 9 :

[charge > 25]

evPowerHigh to pElec

[charge < 5]

evNoPower to pElec

[else]

evPowerLow to pElec

Figure 10 : Traitement de l'opration opControlCharge du composant

chCurrent/opCharge();

PowerSupply

ready evConsume/ opDischarge(params->elec); opControlCharge();

Figure 9 : Diagramme d'tat du composant PowerSupply

Lalgorithme est graphique rendant son interprtation aise : si la batterie a une charge suprieure 25%, alors elle envoie linformation evPowerHigh la carte indiquant quelle peut travailler en mode normal ; si la batterie est en-dessous de 5%, linformation evNo-Power est envoye la carte lui indiquant quelle doit arrter ses traitements ; si la batterie est entre 25% et 5%, elle envoie evPowerLow la carte indiquant quelle doit passer en mode conomique.

On y voit que la batterie a un seul tat ready. Lorsquelle reoit du courant via son owport current, elle augmente sa charge en excutant lopration opCharge. Lopration opCharge consiste simplement augmenter la charge de la batterie jusqu atteindre sa capacit maximale. Lorsquelle reoit une consommation (evConsume), elle dcharge la capacit de la puissance correspondante (opration opDischarge) et elle fait un contrle de son tat de charge en appelant lopration opControlCharge. Cette opration est dcrite dans le diagramme dactivit vu en gure 10.

12 Modlisation SysML par la Pratique

Lautomate de la carte de traitement (block MainProcessor) est dcrit en gure 11 :

evPowerHigh

evInputData/ opProcessData(params->val); evPowerLow tm(curTiming)

evNoPower

Figure 11 : Diagramme d'tat du composant MainProcessor

13

Cet automate est un peu plus complexe que celui de la batterie. La carte a un macrotat modeHdler rafn en trois sous-tats normalMode, ecoMode et standby. Le macro-tat permet de factoriser des comportements communs : quel que soit ltat rel de la carte, si elle reoit evPowerHigh elle bascule en mode normal, si elle reoit evPowerLow elle bascule en mode conomique, si elle reoit evNoPower elle sarrte de travailler. Les tats normalMode et ecoMode sont en fait redcoups en deux sous-tats : en tat running la carte attend la donne dentre, ds quelle arrive, elle est traite et on suspend la carte dune dure dpendant de ltat de batterie (tat paused) soit 200 ms en normal, soit 1 s en conomique puis aprs cette pause elle se remet en tat dattente de la donne dentre (retour ltat running). Le traitement associ la rception de la donne dentre est excut par lopration opProcessData qui est dcrite dans le diagramme dactivit vu en gure 12.

Nous avons modlis ce traitement trs simplement par lenvoi de deux signaux : evOutputData vers lenvironnement linformation transmise est exactement celle reue, si nous avions voulu appliquer un traitement plus complexe, cest l o nous laurions insr et evConsume vers la batterie pour lui rclamer une certaine quantit de puissance lectrique.

Traabilit
Notre modle est maintenant complet contenant lanalyse fonctionnelle et larchitecture du systme avec son comportement dtaill. Ltape nale de construction du modle systme consiste tracer les exigences identies dans la premire tape sur les lments du modle. Cette traabilit se fait en crant des liens de satisfaction entre exigences et lments de modlisation : lments fonctionnels (cas dutilisation, activits, changes), lments darchitecture (blocs, ports, vnements) et lments comportementaux (tats, transitions, oprations). SysML offre aussi dautres types de dpendance comme la vrication et lallocation. Nous nous limiterons ici aux seuls liens de satisfaction. La gure 13 montre le diagramme de traabilit associ aux exigences gnrales. Le tableau 14 reprsente la matrice de traabilit complte qui peut tre produite partir des liens de traabilit (gnre automatiquement avec loutil Rational Rhapsody).

evOutputData(v) to pOut

evCons ume(neededPower) to pElec

Figure 12 : Traitement de l'opration opProcessData du composant MainProcessor

14 Modlisation SysML par la Pratique

Requi rement

Req001

ID = REQ-GEN-1 satisfy satisfy satisfy MobileDevice

bl ock

Cat001.Req002 ID = REQ-GEN-2
Requi rement

Requi rement

Cat001.Req010 ID = REQ-GEN-3

Cat001.Req011 ID = REQ-GEN-4 satisfy

Requi rement

PowerSupply

bl ock

Figure 13 : Traabilit sur les exigences gnrales

15

Exigences REQ-GEN-1 REQ-GEN-2 REQ-GEN-3 REQ-GEN-4 REQ-PROC-1 REQ-PROC-2 REQ-PROC-3 REQ-POW-1 REQ-POW-2 REQ-POW-3

Satisfaites par Block PortableComputer Block PortableComputer Block PortableComputer Block PowerSuppply State normalMode in block MainProcessor State normalMode in block MainProcessor State ecoMode in block MainProcessor Operation opControlCharge in block PowerSupply Operation opControlCharge in block PowerSupply Operation opControlCharge in block PowerSupply

Il est aussi fortement conseill dutiliser conjointement un outil de modlisation qui supporte rellement le formalisme SysML avec les rgles de bonne construction associes (et pas seulement un outil de dessin). Rational Rhapsody est un outil mature qui offre toutes les capacits ncessaires la modlisation SysML et il supporte aussi le processus Harmony/SE dont sont tirs les bonnes pratiques et le processus simpli propos ici. Enn au-del de la simple production de diagrammes, SysML permet de construire des modles excutables et donc testables et vriables. Pour cette activit loutil est essentiel car cest lui qui excute le modle. Le produit Rational Rhapsody inclut un simulateur fonctionnant de la manire suivante : Les automates des composants sexcutent en parallle en schangeant des donnes et des contrles. Ils appellent les services spcis sur les transitions. La communication se fait par transmission des vnements dun automate (ou de lextrieur) vers un autre (ou vers lextrieur), selon les deux modes : asynchrone sporadique par vnement ou continu pour les ports de ot. On peut suivre lvolution du modle automates, donnes, changes, etc. sur des diagrammes de squence et des panneaux graphiques. Lexcution de ce modle nous permettrait de vrier le bon fonctionnement de lquipement en mode connect, le temps de fonctionnement en mode dconnect avec batterie pleine, et le temps de recharge. Cet exemple pourrait tre aisment enrichi, par exemple, avec une loi de chargement de la batterie plus sophistique et pas simplement linaire ou avec une prise en compte de lusure de la batterie dpendant du nombre de cycles chargement / dchargement.

Tableau 14 : Matrice de traabilit

Conclusion
SysML permet de construire graphiquement un modle dingnierie systme contenant : La spcication des exigences, Lanalyse fonctionnelle, La dcomposition du systme en composants, La spcication des changes entre le systme et son environnement et entre les composants du systme, La description du comportement autonome de chaque composant avec leurs services offerts, La traabilit entre tous ces lments. Il est recommand dappliquer SysML selon un processus clair, complet et bien organis, de manire faciliter la prise en main par les quipes dingnierie, ainsi que la communication entre quipes et la capitalisation du savoir, avec comme consquence une rutilisation et une maintenance volutive elles aussi facilites.

Rfrences
1

Harmony-SE/SysML Deskbook, Hans-Peter Hoffmann, Rev 3.1.1, July 2010, available upon request SysML, www.sysml.org IBM Rational Rhapsody, http://www.ibm.com/developerworks/rational/products/rhapsody UML, www.uml.org
Copyright IBM Corporation 2011 Compagnie IBM France 17 Avenue de l'Europe 92 275 bois-Colombes Cedex Imprim en France Janvier 2011 Tous droits rservs. IBM, le logo IBM et ibm.com sont des marques d'International Business Machines Corporation aux Etats-Unis et/ou dans certains autres pays. Si ces marques et d'autres marques d'IBM sont accompagnes d'un symbole de marque ( ou ), ces symboles signalent des marques d'IBM aux tats-Unis la date de publication de ce document. Ces marques peuvent galement exister et ventuellement avoir t enregistres dans d'autres pays. La liste actualise de toutes les marques d'IBM est disponible sur la page Web ibm.com/legal/copytrade.shtml. Les autres noms de socits, de produits et de services peuvent appartenir des tiers. Les rfrences aux produits et services d'IBM n'impliquent pas qu'ils soient distribus dans tous les pays dans lesquels IBM exerce son activit.
1

Pour de plus amples informations

Pour en savoir plus sur le Cloud Computing par IBM, consultez le site Web suivant : ibm.com/cloud IBM Global Financing peut proposer des solutions de nancement personnalises, parfaitement adaptes vos besoins informatiques spciques. Pour plus d'informations sur nos tarifs et sur nos plans de nancement extrmement souples et sur le rachat et la rcupration des quipements, consultez ibm.com/nancing/fr

IDC eXchange, IDCs New IT Cloud Services Forecast: 2009-2013, p=543, 5 octobre 2009.

Recyclable, merci de recycler