UML based Modeling and Performance Evaluation of Mobile Systems Vincenzo Grassi 1,Raffaela Mirandola...

UML based Modeling and Performance Evaluation

of Mobile SystemsVincenzo Grassi1,Raffaela Mirandola2,Antonino Sabetta1

(1) Università di Roma “Tor Vergata”, Italy {vgrassi|sabetta}@info.uniroma2.it

(2) Politecnico di Milano, [email protected]

VIII Workshop PISATEL

6 dicembre 2005, Pisa

V. Grassi, R. Mirandola, A. Sabetta – UML based Modeling and Performance Evaluation of Mobile Systems

Outline

• Introduction: motivation, previous work, approach• Modeling mobility

– Physical mobility: locations and moving locations– Logical mobility: mobile software components– Dynamics of mobility: <<MobilityManager>>

• Modeling performance– Annotated UML models: SPT + Mobility profile

• Representing mobile code paradigms in UML• Code On Demand (COD)• Remote Evaluation (REV)• Mobile Agent (MA)

• Performance Analysis based on UML models: an example• Conclusion


Modeling mobility: related work

– previous work• UML-based modeling

– Class and Activity Diagram extension [Baumeister, Koch, Kosiuczenko, Wirsing – 2002]; Sequence Diagram extension [Kosiuczenko – 2003]; Activity Diagrams based [Balsamo, Marzolla – 2003]; …

• formal languages– -calculus [Milner – 1999]; ambient calculus [Cardelli,

Gordon – 1998]; Klaim [De Nicola, Ferrari, Pugliese, Venneri – 1998]; mobile Unity [Picco, Roman, McCann – 2001];…


Motivation and approach• Why modeling mobility and performance in UML?

– Wide user- and tool-base– Extensibility– “Model Driven” approach

• On the other hand….– The UML standard specification does not natively support modeling

mobility• Guidelines for our approach

– "separation of concerns”• models of mobility (both physical and logical) separated from

models of the application logic and of the system structure• ease “plug-and-play” of different mobility policies at the

application modeling level, to support “what if” experiments– usability

• lightweight UML extension• compliant with the UML 2.0 specification• only requires UML 2.0 compliant tools


Outline







B

Representing locations– locations

• basic model : a nesting relationship between an entity and some container

– B “is located at” AA

B

AC

– location change• a modification of a nesting ("located at") relationship

– C “is located at” A C “is located at” B

– What are locations?• Physical places (rooms, buldings, vehicles, persons,….)• Execution environments (PCs, PDAs,…..)

– What do they contain?• Physical places contain other physical places or execution env.• Execution environments contain software entities (agents, mobile components, code fragments...)


Room_B:…Room_A:…

Representing Locations with theUML Profile for Mobility

Mary:…

MyPda:…

Room_C:…

<<Mobile>><<ExecEnv>>MyPda : PDA

<<Mobile>><<Place>>

Mary : Person

<<Place>>Room_C : Room

<<Place>>Room_A : Room

<<Place>>Room_B : Room

<<NodeLocation>>

<<NodeLocation>>

<<NodeLocation>>

<<NodeLocation>>


Adding Dynamics to the Model

<<place>>MyPda : PDA

<<mobile>><<place>>

Mary : Person

<<place>>Home :

<<place>>Office :

<<NodeLocation>>

<<NodeLocation>>

<<NodeLocation>>

State atHome

sleep(uniform(4h))

State atOffice

sleep(uniform(3h))

<<MobilityManager>> Mary_MobMan

/<<moveActivity>>go(Mary, Office)

/ <<moveActivity>>go(Mary, Home)

MobilityManagers encapsulate all the “mobility logic”, keeping it strictly separate from the application logic

different mobility managers can be modularly plugged into the same system model, to describe different mobility scenarios and strategies

•mainly a modeling abstraction, not necessarily a “real” entity


Representing Code Mobility (I)

<<ExecEnv>>MyPda : PDA

<<mobile>><<place>>

Mary : Person

<<place>>Home : Room

<<place>>Office : Room

<<ExecEnv>>srv : Server

<<NodeLocation>>

<<NodeLocation>>

<<NodeLocation>>

<<MobileCode>>C3 : Comp

C1 : Comp

C2 : CompC4 : Comp

<<CurrentDeployment>>

<<AllowedDeployment>>

<<deploy>>

<<deploy>>

<<deploy>>


Representing Code Mobility (II)

<<MobileCode>>C2 : Comp

<<ExecEnv>>MyPda : PDA

<<CurrentDeployment>>

<<ExecEnv>>srv : Server

<<AllowedDeployment>>

C1 : Comp

Structural model

State B

[MyPda.locatedAt (Home)] event_E1

/ <<Move>> REV(C1, somewhere)

State D

State C

State A

[SomeCondition] Event 2 /

[SomeCondition] Event 3 /

[MyPda.locatedAt (Office)] Event 4

/ <<Move>> SomeMigrationAct( )

[C1.CurrentDeployment.BatteryLevel < 25%] event_E2

/ <<Move>> MA(C1, somewhere_else)

Behavioral model


Outline







Annotating UML modelswith performance characteristics

• Adding performance annotations from the UML Profile for Schedulability, Performance and Time (SPT)

Node PAhost, PAresource-PArate

PhysicalMove PAstep- PAdelay- PAprob

LogicalMove PAstep-PAdemand

Move

<<ExecEnv>>MyPda : PDA <<PAhost>>

PArate =……..

<<PhysicalMove>>Move

<<Place>>Destination

<<MobileElement>>EntityToMove

<<PAstep>>PAdelay =……..PAprob = ……

<<LogicalMove>>REV

<<ExecEnv>>DestinationNode

<<MobileCode>>Component

<<PAstep>>PAdemand =……..


Outline







Modeling mobile code paradigms

– “standard” paradigms to architect mobile code based applications[Fuggetta, Picco, Vigna - IEEE Trans. on Sw. Eng., 1998]

– ‘stateless’ code mobility• code on demand (COD)• remote evaluation (REV)

– code+state mobility• mobile agent (MA)

both can be seen as “location aware” extensions

of the client-server (CS) paradigm


From “Client Server” to “Code On Demand”

Invoke

Use Results

<<MobileCode>>CodeToMigrate

Do Service

<<AfterMove>>PrepareToExec

<<LogicalMove>>Migrate Code

<<BeforeMove>>Prepare To Migrate

<<MobileCode>>SomeComponent


Local Execution Environment

Remote Execution Environment

<<PAstep>>PAdemand = ….f($M)

<<PAstep>>PAdemand = ….f($M) <<PAstep>>

PAdemand = ….f($M)

<<LogicalMove>> COD(CodeToMigrate)

Do Service


Modeling the “Remote Evaluation” paradigm

Invoke

Use Results






<<LogicalMove>> REV(CodeToMigrate,Destination)

Do Service Do Service





<<MobileCode>>CodeToMigrate




Mobile Agents

Invoke

Use Results



Do Service










Here the semantics of the <<MoveActivity>> is different from that

in the COD and REV examples!In this case the state moves,

not only the code!

<<LogicalMove>> MA(Destination)


Outline







Case study: picture retrieval system (I)

Send requestfor pictures

Retrievepictures

<<PAstep>>{PAdemand =(ass, mean, f($r))}

<<PAstep>>{PArep =$N}

User PictureAgent

Send picturerequest


Selectpictures

Send pictureindex

Show pictureindex

Send viewlist

Selectpictures




User PictureAgent Filter Database

[doFilter=false]

[doFilter]

<<PAcontext>> Retrieve Pictures


Case study: picture retrieval system (II)

Send view list

Sendselected list

Sendpictures

Sendfiltered list

Show picturesSend select

and discard list

Receive andStore pictures

<<PAstep>>{PAdemand =(ass, mean,f($r))}

User PictureAgent Filter Database

<<PAcontext>> Select Pictures [doFilter == true]

Send view list

Sendpictures

Send selectedPictures to PA





System model with physicaland logical mobile entities

LocBLocA

WLanAccessPoint

InternetWWanAccessPoint

<<ExecEnv>>PDA

<<ExecEnv>>Server1

<<ExecEnv>>Server2

PictureAgent

DB(2)

DB(1)

Filter

<<deploy>>

<<deploy>>

<<Allowed>>

<<Allowed>>

<<NodeLocation>><<NodeLocation>>

<<NodeLocation>>

<<Allowed>>

<<Allowed>>

<<Allowed>>

<<Allowed>>

{PArate =…….}{PArate =…….}

{PArate =…….}

<<deploy>>

<<deploy>>

<<Mobile>>

<<Place>> <<Place>>

<<PAhost>><<PAhost>><<PAhost>>

<<MobileCode>>

<<MobileCode>>

Static System model


Mobility managers

Idle Interactingwith DB($i)

sendPictureReq(DB($i)) / <<moveActivity>>REV(Filter,DB($i).CurrentDeployment)

sendSelect&DiscardList() /[no more archives] /

Idle Interactingwith DB($i)

sendPictureReq(DB($i)) /<<moveActivity>>MA(PictureAgent,

DB($i).CurrentDepl); <<moveActivity>> REV(Filter, DB($i).CurrentDepl)

sendSelect&DiscardList() /

[no more archives] /<<moveActivity>> MA(PictureAgent,UserInterface.CurrentDeployment)

atLocAatLocB

<<PhysicalMove>>

Move(Pda, LocB)

<<PhysicalMove>>

Move(Pda, LocA)

<<PAstep>>{PAdelay =(‘ass’, ‘dist’, exp($λ2)}

<<PAstep>>{PAdelay =(‘ass’, ‘dist’, exp($λ1)}


Outline







Conclusion (I)

– Our contribution Representation of mobility in computer systems from a

high level perspective… ….by means of an extension of a mainstream de facto

standard language Mobility is described in a uniform way for both physical

and logical entities Modularity and separation of concerns allow to easily

experiment with different scenarios and adaptation strategies based on code mobility

Integration of our profile with other pre-existing, well established profile for performance modeling (SPT)

It is primarily a descriptive technique for performance analysis of mobile systems– models built according to the proposed framework are

meant as the input to third party performance analysis tools• Recent extension: automatic code generation

(Jade,muCode)


Conclusion (II)– Open Issues

• Model transformation rules need to be defined in order to derive new models in suitable forms from descriptions made with our framework

– In our paper we have shown a trivial rule (which is basically an inspection of the diagrams) that allows to make some comparisons between different mobile code strategies (provided some strong conditions hold, such as no competition)

• Other transformation rules are documented in the literature (to produce QN, LQN, Petri Nets, Markovian models from UML annotated models). The research on this topic is still going on.

– Future work• Definition of formalized transformation rules (maybe

using relational or graph-transformation techniques)• Assess consistency between models resulting from

different transformations (difficult task!)• Maybe some UML-specific rework is to be done on the

definition of the profile when the final UML 2 specification is out

UML based Modeling and Performance Evaluation of Mobile Systems Vincenzo Grassi 1,Raffaela Mirandola...

Documents

Transcript of UML based Modeling and Performance Evaluation of Mobile Systems Vincenzo Grassi 1,Raffaela Mirandola...