automatic inclusion of middleware performance attributes into architectural uml software models by...

Automatic Inclusion of Middleware Performance

Attributes into Architectural UML Software Models

by Tom Verdickt, Bart Dhoedt, and Piet Demeester

Senior Member,IEEE

Presented byAYŞEGÜL TÜYSÜZ

CmpE 550 – Advanced Topics in Software Engineering

Ayşegül Tüysüz / 23 November 2005

Outline

Introduction UML for Schedulability, Performance and Time Model Driven Architecture (MDA) CORBA Input to the Transformation The Model Transformation Conclusion


Motivation of the article

Development of a framework for the automatic modeling of the impact of the middleware on the architecture and the performance of distributed systems

Software Modeling Language UML System Design MDA Middleware CORBA


UML : a cocktail of well-known ingredients

A stereotype <<PAstep>>Tagged value PAdemand


MDA’s Y cycle

PIMs(PlatformIndependentModels)

PSMs(PlatformSpecificModels)

Merging/binding phase(TRANSFORMATION ALGORITHM)

PDMs(PlatformDescriptionModels)

M

Model Driven Architecture (MDA)


The middleware war is over

COM+

DCOM

CORBA

IIOPMicrosoft

C# & DotNet

XMLSOAP

JavaRMI HTTP

HTML

There is no clear winner nor loser

The next battlefield will be model transformation

The MDA initiative is aimed at using modelling to drive the design and implementation of distributed systems. Sun's reaction

to C# & DotNet?

Sun's JavaEJB

IIOPORB

Client Machine

Client Object

ORB

Server Machine

Stub

Remote

Object

Skeleton

Additional CORBA services:- Naming Service (NS)- Security Service- Event Service


Approach: MDA’s cycle

Transformationalgorithm

UML ActivityDiagram

UML DeploymentDiagram

Middleware-independent model

UML CollaborationDiagram

Middleware usage

description

UML ActivityDiagram

UML DeploymentDiagram

Middleware-aware model UML Collaboration

Diagram

CORBA

Java RMI

Web Services

Middleware modellibrary

High-level PIM

Lower-level PSM


Input to the Transformation

UML Deployment Diagram

Client PC

client

Server PC

server

UML Collaboration Diagramclient-server

client server



UML Activity Diagramserver client

make call

continue

waiting

undefined

process

asynchronous

client server

make call

continue

waiting

undefined

process

synchronous deferred synchronous

client server

make call

continue

waiting

undefined

processdo

something

wait



Middleware usage descriptionThe specifics of the middleware (its type, some

performance information, etc.) are given in a seperate XML input file to the transformation

<middleware> <mw_instance id=“orb1” type=“CORBA”

inittime=“36.549” destroytime=“3.3646” /> <link id=“link1” mwref=“orb1”> <call cref=“G.11” stubtime=“1.8413” skeletontime=“0.1021” /> </link></middleware>

Describes middlewa

re instances

Type of middlewa

re

Initialization time

Time needed to clean up

and destroy

describes groups of calls

between a client and a

server

specifies server and client side

overhead of using the

middleware

<middleware> <mw_instance id=“orb1” type=“CORBA”

inittime=“36.549” destroytime=“3.3646” /> <link id=“link1” mwref=“orb1”> <endpoints client=“S1” server=“S2” stubtime=“1.8413” skeletontime=“0.1021” /> </link></middleware>

All communication between the components

should use the middleware


The Model Transformation

Locating the involved componentsThe deployment diagramThe collaboration diagramThe activity diagram & Performance

attributesAdditional middleware (CORBA)

services


Locating the involved components

function find involved components {for each <link> element in Middleware Usage Description XML {

if <link> has <endpoints> child { find partitions by looking “client” and “server”

attributes of <endpoints>; } else { take first <call> element; find transition referenced by “cref”; get names of source and target partitions; } //end else } //end for} // end function


Transformation of the Deployment Diagram

function transform deployment diagram {for each <link> element {

find nodes that contain source and target; add corba_client and stub to source node; find orb referenced in “mwref” attribute; if orb not yet added to source node { add orb to source node; } //end if add skeleton to target node; } //end for} // end function

Server PC

server

Client PC

client

stuborb

corba_client

skeleton


Transformation of the Collaboration Diagramfunction transform collaboration diagram {

for each <link> element { find source and target roles; find collaboration between source and target roles; create roles corba_client, stub and skeleton; find orb referenced in “mwref” attribute; if orb not yet added { create role orb; } //end if create client—server collaboration between corba-client and orb, corba-client and client, client and stub, stub and skeleton, skeleton and server; } //end for delete collaborations between orijinal source and target roles; } // end function

client stub skeleton server

client-server

client-server

client-server

client-server

orb

corba_client

client-server


Transformation of the Activity Diagram (synchronous)

process

make callcall_client

initialize

client servercorba_client orb stub skeletoncall_init

waiting

skeleton_replystub_reply

stub_request

destroy

continuereturn_client

dummycall_destroy

skeleton_request

waiting<<PAstep>>

{PAdemand = (‘assm’, ‘mean’, (36.549, ‘ms’))}

<<PAstep>>{PAdemand = (‘assm’, ‘mean’,

(3.3646, ‘ms’))}

<<PAstep>>{PAdemand = (‘assm’, ‘mean’,

(1.8413, ‘ms’))}<<PAstep>>

{PAdemand = (‘assm’, ‘mean’, (0.1021, ‘ms’))}

Middleware Usage Description<middleware> <mw_instance type=“CORBA” inittime=“36.549” destroytime=“3.3646” /> <link id=“link1” mwref=“orb1”> <call cref=“G.11” stubtime=“1.8413” skeletontime=“0.1021” /> <use_service sref =“NS1”> </link> <service id=“NS1” type=“NS” host=“spc”> <overhead>

<initialization client=“0.3” host=“0.1” /><invocation client=“0.46” host=“0.53” />

</overhead> <service/></middleware>


Transformation Limitations

Naming convention: Model elements that occur in different diagrams need to have the same name which should be unique in the model

No handling of interactions (e.g forwarding servers)

client Server A Server B21

3


Conclusion

MDA Transformation includes: structural impact of the middleware overhead generated by the middleware

The resulting UML model contains information for: modeling and analyzing the performance of the system how the performance is affected by the middleware

Combination of MDA and SPE allows: obtaining performance estimates as early as possible redesigning the system without excessive costs


Questions ???

automatic inclusion of middleware performance attributes into architectural uml software models by...

Documents