Deriving Performance Models from UML Specifications by Graph Transformations

June 2001 IEEE Ottawa Computer Chapter talk 1

Deriving Performance Models from UML Specifications by Graph

Transformations

Dr. Dorina Petriu

Carleton UniversityDepartment of Systems and Computer

EngineeringOttawa, Canada, K1S 5B6

http://www.sce.carleton.ca/faculty/petriu.html

IEEE Ottawa Computer Chapter talk ©Dorina C. Petriu 2

Outline

Motivation Background

Layered Queueing Network (LQN) performance models OMG Performance Profile

Methodology for performance model derivation Generation of LQN performance models by graph transformations based on

the graph-grammar formalism 2-phase transformation

Example: analysis of a telecommunication system from UML to LQN performance analysis

Conclusions


Motivation

Software Performance Engineering (SPE) [Smith90]: integrate performance evaluation into the software development

process from the early stages throughout the whole life-cycle requires the construction and analysis of performance models

Why SPE is not frequently applied in practice: cognitive gap between the software development domain and the

performance analysis domain pressure for “shorter time to market” leaves no time for SPE

Importance of SPE recognized by OMG: definition of a performance profile

Present research: automate the derivation of LQN performance models from UML design models: LQN model structure generated from high-level software

architecture LQN model parameters from software execution model (activity

diagrams).


LQN is an extended Queueing Network model: both software tasks and hardware devices

are represented (drawn as parallelograms and circles)

nested services are allowed (a server is also a client to other servers)

software components have entries corresponding to different services

arcs represent service requests synchronous and asynchronous requests multi-servers used to model components

with internal concurrency Typical LQN results: throughputs,

response times, utilization. LQN use:

for identigying and eliminating bottlenecks which limit the system performance

for capacity planning and scalability analysis.

Client_1 Client_2

Application

Database

Proc 1

Proc 3

Proc 2

Disk 1 Disk 2

Example: LQN model of a three-tiered client-server system

Layered Queueing Network (LQN)


Types of LQN messages and phases

phase1 (service)

Client

Server

synchronous message

busy

reply

included servicesphase2 phase3

(autonomous phases)

idle

Client

Server

a) LQN synchronous message

Client

Serverbusy

included services

phase1

phase2 phase3 idle

b) LQN asynchronous message

Client

Server

asynchronous message

forwarding

Client

synchronous message

reply to original client

Server1 busy phase1 phase2 idle

Client

Server1

c) LQN forwarding message

Server2busy idle phase1 phase2 idle

Server2


LQN extensions: activities, fork/join in an entry

T2

a1

&

a8a7

a3[e1]

&

T1

Sleep_T

P1

a10

a4

+

a5

a2

+

+

a9+

a6

T3

Sleep_P

P3

T4 T5 T6

P4 P5 P6

P2

0.50.50.50.5


Approach to converting UML to LQN models

UML Model

LQN ModelGraph Transformations

Performance Annotations


OMG’s Performance Profile

OMG is in the process of defining a performance profile intended to enable quantitative performance analysis of UML models.

The profile extends the UML metamodel for attaching performance information to a UML model with stereotypes tagged values constraints

In order to conduct quantitative performance analysis of a UML model: one must first translate the UML model into a performance model use an existing performance analysis tool import back in the UML model the analysis results


Performance Profile: the domain model

PerformanceContext

WorkloadresponseTimepriority

PScenariohostExecDemandresponseTime

PresourceutilizationschedulingPolicythroughput

PProcessingResourceprocessingRatecontextSwitchTimepriorityRangeisPreeemptible

PPassiveResourcewaitingTimeresponseTimecapacityaccessTime

PStepprobabilityrepetitiondelayoperationsintervalexecutionTime

ClosedWorkloadpopulationexternalDelay

OpenWorkloadoccurencePattern

0..n

1..n

1..n 1

11

1..n 1..n

0..n

0..n

0..n

0..1

1..n

1

1{ordered}

+successor

+predecessor

+root

+host


Implementation: 2-phase transformation

LQN Models


Sequence Diagrams

Architectural Information

Activity Diagram

Collaboration Diagram

Deployment Diagram



Top level sequence diagram for e-commerce application

s:serverSocket m:mainServerThread

listen()connectionRequest()

accept()

w:workerThread

get(serviceRequest)reqType :=checkRequest()

* [reqType != done]

callback()

write(menu)

[reqType = registration]

Customer Registration

[reqType = browse]

Browse

[reqType = add | reqType = drop ]

Add/drop product

[reqType = buy]

Checkout

new

[reqType= done]reply(endMsg)

:client

* [forever]

iterationbox

iterationbox

compositesubdiagram

iterationexpression

iterationexpression


Activity diagram corresponding to the previous SD

[reqType =registration]

[reqType = buy][reqType=add | reqType=drop ]

[reqType= browse]

[reqType = done]

client server

s.listen()

connect request

m.callbacks.acceptnew(w)

w.write(menu)

w. get(serviceRequest)w.reqType:=checkRequest()

menu

service request

Customer registration

Add/drop Product

Browse Checkoutreply(endMsg)

endMsg

w.terminate

unspecifiedwait for request

unspecified

compositeactivity


More detailed SD and corresponding AD

addAccount

register

client workerthread database

Create account and add to database

form [to fill]

form [filled]

Reply with registration form

Display account created

account

reply

account

unspecified

SD for the iteration box from the top-level diagram

specialized for “registration”

Corresponding activity diagram

w:workerThread

reply (registrationForm)

:client

send(form):customerAcct

addAccountt()

new

reply(account)

database

fillIn()

get(serviceRequest)reqType :=checkRequest()

[reqType = registration]

* [reqType != done]

iterationbox

compositesubdiagramiteration

expression


From architectural patterns and deployment info to LQN

Database Server

Client Client

<<Internet>>

<<disk>>

<<Modem>>m1 bits/s

<<Modem>>m2 bits/s

<<LAN>>r bit/sec

<<LAN>>r bit/sec

ProcDB

Database

disk

Client

ProcS

ProcC

ModemInternet

1 2 3 4 5 6

Server

1. Connect2. Registration3. Browse4. Add/Drop5. Checkout6. Disconnect


Determine server entries and phases from AD

[reqType =registration]

[reqType = buy][reqType=add | reqType=drop ]

[reqType= browse]

[reqType = done]

client server

s.listen()

connect request

m.callbacks.acceptnew(w)

w.write(menu)

w. get(serviceRequest)w.reqType:=checkRequest()

menu

service request

Customer registration

Add/drop Product

Browse Checkoutreply(endMsg)

endMsg

w.terminate

unspecified

unspecified

entry1, phase 1

entry 2 - 5, phase 1

entry6, phase 1

entry6, phase 2

wait for request

The resource demands are aggregated

separately for each area


Producing Activity Diagram (Phase1 transformation)

Transformation Rules

Activity Diagram

Output Graph

Representing

Objective: Identifying flows of control

Represented by Input Graph

Sequence Diagrams

Architectural Information



SD to AD transformation principles for a single execution

threadr m n

a()b()

m.a n.b

r m n

c:= b()a()

[c=c1] d()

g()

[c=c2] f()

[c=c2][c=c1]

n.d n.f

n.g

r m n

a()

b()

c()

*[loop condition]

m.a

*[loop condition]

a) Sequential execution

b) Branch and merge

c) Iteration (looping)

m.a n.b

n.bn.c


r m n

b()

a

replym.action(a)

a

n.breply

a) Synchronous message send and reply

b) Asynchronous creation of an active

object

c) Asynchronous message

n.b

s.a new(m)

s.c

a()

r

m

s

b()

c()new n

a()

r ms

d()

c

b()

n

f() n.d

s.a

r.action(c) s.f

n.b

c

SD to AD transformation principles for multiple execution threads


Graph Transformations and PROGRES

We are using a known graph rewriting tool named PROGRES (PROgramming with Graph Rewriting Systems) [Schürr90, Schürr94, Schürr97]

The essential idea of all implemented graph grammars or graph rewriting systems is that they are generalization of string grammars (used in compilers) or term rewriting systems.

The terms “graph grammars” and “graph rewriting systems” are often considered synonymous, however: a graph grammar is a set of production rules that generates a

language of terminal graphs and produces nonterminal graphs as intermediate results.

a graph rewriting system is a set of rules that transforms one instance of a given class of graphs into another instance of the same class of graphs without distinguishing terminal and nonterminal results.


PROGRES Schema

PROGRES transforms an attributed input graph into an attributed output graph.

The graph schema shows the types of nodes and edges composing a valid graph we have built it to resemble closely the UML metamodel

A set of production rules are applied in a controlled way in order to performs the graph transformations. a production rule has a left-hand side defining a graph pattern

that will be matched in the overall graph then replaced by the right-hand side

nodes and edges can be deleted, added or modified a rule also shows how to compute the attributes of the new nodes

from the attributes of the nodes that were replaced


Schema notation

PROGRES uses inheritance (possible multiple) to define hierarchies of node classes

Square boxes represent node classes (can have attributes) inheritance relationships are represented with dotted edges node classes correspond to abstract classes in UML

Rounded-corner boxes represent node types connected with their uniquely defined classes by the means of dashed

edges. node types are leaves of the node class hierarchy, and are used to create

node instances in a PROGRES graph. a node type specializes only one class

Solid edges between edge classes represent edge types, which define the relationships between node instances.

Node attributes are shown as small circles attached to the class or type boxes.


PROGRES Schema for SD to AD transformation

Namestring

Call Action

Send Signal

Local Operation

Create Action

Destroy Action

Terminate Action

Return Action

ACTION

ll_nextowns

senderMESSAGE

Asynch

SendTime

real SIGNAL

ReplySynchCall

RcvTime

real

INSTANCE

Active Passive

integer

Size

MODEL ELEMENT

DIAGRAM

Component

Sequence Diagram

Activity Diagram Partition

receiver

arg

STATE

Guard Condition

contains

contains owns

maps_to

effect

SubActivity state

SIMPLE STATE

COMPOSITE STATE

CTRL BLOCK

Initial state

Final state

Activity state

ObjFlow state

Fork Join Merge Branch

PARALLEL ALTERNATIVE

Conditional Arc

guarded

has

c_flowd_in

d_out

flow

c_flow_in

cross_ref

dispatch

perform

Init Action

seq

map

s_to

Sequence Diagram

Activity Diagram


a

f

r

Example of a sequence diagram with concurrency

Corresponding activity diagram with swimlanes and object flow

x

v

uy

z

r

b()a

new

new

d()

[c = c2] h()

[c = c1] g()

delete(v)f

h()

1st component 2nd component 3rd component

y.receive(a) u.b() new(z)

v.g()

z.terminate()

v.h()

[c = c2][c = c1]

u.d()

y.receive(f)u.h()

y.send(r)

x y

z.init() new(v)

z.delete(v) z.send(f)

object flow

fork newthread

send asynch msg

receive asynch msg

send reply

receive synch msg

x.send(a)

x.receive(r)

waiting

undefined

z


Example of PROGRES input graph

x

v

uy

z

r

b()a

new

new

d()

[c = c2] h()

[c = c1] g()

delete(v)f

h()

1st thread comp1

2nd thread comp2

3nd thread comp3

SD

comp1 comp2 comp3

x y ua

z:Send

:Receive

1 :Receiveb

:Call :Local2

3

4

:Create

new v

new

:Init

:Create:Call :Local5

d:Local

6:Call:Local

6:Call:Local

g

h

Guard

Guard

7:Destroy:Localdelete

8

f:Send:Receive

:Call :Local9h

10 :Sendr

:Terminate

Not all edges sender, receiver and perform are shown.


Detailed mapping from SD to PROGRES graph

x

v

uy

z

r

b()a

new

new

d()

[c = c2] h()

[c = c1] g()

delete(v)f

h()

1st thread comp1

2nd thread comp2

3nd thread comp3

SD

comp1 comp2 comp3

x y u

a z:Send

:Receive

1 :Receiveb

:Call :Local2

3

4

:Create

new v

new

:Init

:Create:Call :Local5

d:Local

6:Call:Local

6:Call:Local

g

h

Guard

Guard

7:Destroy:Localdelete

8

f:Send:Receive

:Call :Local9h

10 :Sendr

:Terminate

Not all edges sender, receiver and perform are shown.

sender performreceiv

er

perform

disp effect

ll_ne

xt

seq


owns

partition1

Generating an AD: apply “top” rule (1)

a

z

:Send 1:Receive b

:Call :Local2

3:Createnew

:Init

contains SD

comp1 comp2 comp3

x y u

contains

AD

partition2 partition3

x:InitialStwaiting: ActivityState

x uy

z

b()a

new

a

y.receive(a)

z.init()

x.send(a)

new(z)

u.b()

comp2comp1 comp3

maps-to

maps-to

maps-to

maps-to

owns owns

owns owns

waiting


Generating an AD: apply “synchr. message” rule (2)

partition1

a

z

:Send 1:Receive b

:Call :Local2

3:Createnew

:Init

perform

SD

comp1 comp2 comp3

x y urec

eiversender

dispatch effect

perform

AD


x:InitialSt waiting

x uy

z

b()a

new

a

y.receive(a)

z.init()

x.send(a)

new(z)

u.b()

comp2comp1 comp3

x:send :Joinflow flow

a:ObjFlow

d_in d_out

y.receive(a)flow

ownsowns

waiting


Generating an AD: apply “operation call” rule (3)

partition1

a

z

:Send 1:Receive b

:Call :Local2

3:Createnew

:Init

seq

SD

comp1 comp2 comp3

x y u

rece

iversender

dispatch effect

perform

AD


x:InitialSt waiting

x uy

z

b()a

new

a

y.receive(a)

z.init()

x.send(a)

new(z)

u.b()

comp2comp1 comp3


a:ObjFlow

d_in d_out

y.receive(a)flow

u.b()flow

ownsowns

waiting


Generating an AD: apply “create thread” rule (4)

partition1

a

z

:Send 1:Receive b

:Call

:Local

2

3:Createnew

:Init

owns

SD

comp1 comp2 comp3

x y u

receiv

er

sender

dispatch effect

perform

AD


x:InitialSt waiting

x uy

z

b()a

new

a

y.receive(a)

z.init()

x.send(a)

new(z)

u.b()

comp2comp1 comp3


a:ObjFlow

d_in d_out

y.receive(a)flow

new(z)

flow

ownsowns

:Forkflow

u.b()flow

owns

flow

waiting


Building LQN Models (Phase2)

Transformation Rules

Output Graph

RepresentingLQN Models

Represented byInput Graph

Activity Diagram


Deployment Diagram

Collaboration Diagram


Architectural patterns

The literature identifies a relatively small number of architectural patterns which describe the collaboration between high-level components (mostly concurrent): pipe and filters client server broker layers critical section master-slave

The high-level architecture of a software system as described by architectural patterns will determine the structure of the LQN performance model. LQN nodes represent concurrent components or high-level objects

and hardware devices.


UML diagrams for generating the LQN structure

Collaboration an abstraction mechanism used to represent architectural patterns represents “a society of classes, interfaces, and other elements that

work together to provide some cooperative behaviour that is bigger than the sum of all of its parts”

a collaboration has two aspects: structural and behavioural (only the structure is directly used to generate the LQN nodes)

Deployment diagram with component instances identifies runtime component instances shows their allocation to physical devices

What do LQN tasks represent software component instances (according to the architectural

patterns in which they are involved) hardware devices


Transformation of Pipeline and Filters pattern to LQN

filter1 filter2

semaphoreand buffer

write read

proc

All filters running on the same processor node

proc1 proc2write read

Filters running on different processor nodes

Note 2: a pattern may produce different LQN models depending on factors such as processor allocation. (obtained from the deployment diagram)

PIPELINEWITH MESSAGE

<<process>>

filter1

UpStreamFilt

<<process>>

filter2

DownStreamFilter

UpStreamFilterDownStreamFilte

DownStreamFilter

write() {sequential}read() {sequential}

buffer<<process>>

filter1

1..n <<process>>

filter2

1..n

write() read()

PIPELINE WITH BUFFER

UpStreamFilter Buffer

UpStreamFilterDownStreamFilterBuffer

Note 1: only the structural view is used to transform a UML collaboration to LQN.

filter1 filter2

filter1 filter2

semaphore


Transformation of the basic Client-Server pattern to LQN

service1()service2()

server

<<process>>

client2

1..n<<process>>

client1

1..n

Client Client

Server

CLIENT SERVER

ClientServer

service1() service2 ()

service2 ()

client1 client2

server

service1 service2

Each software process (client or server) is modelled as an LQN task Each server operation is modelled as an entry A client may request more than one server operation; each request is modelled

as an LQN synchronous message arc. Auxiliary performance information: average execution time for each client and

server entry; average number of requests associated with each LQN message arc.


Transformation of the Critical Section collaboration

f1 () {sequential}f2 () {sequential}. . .fN () {sequential}

shared

<<process>>

userN

<<process>>

user1

Accessor Accessor

Shared

CRITICAL SECTION

AccessorShared

f1 () fN ()

. . .

user1 userN

proc

. . .

semaphore and critical sectionsf1 f2 . . . fN

Users on the same processor node

user1 userN

semaphore

proc1 procNf1 fN

. . .

1 2 ... N

. . .

Users on different processor nodes


How to identify architectural patterns

Recognize the pattern of interaction between participants from the detailed behaviour described in the activity diagrams For example, client-server interactions are easy to recognize when

the client sends a synchronous message to the server and waits for the reply

Client-server interactions can also be realized through asynchronous messages - a little more difficult to identify.

Some interaction patterns are more difficult to recognize, as for example pipeline with buffer, critical section, etc.

The designer of the UML model indicates explicitly the architectural patterns used. Check if the detailed behaviour conforms to the pattern indicated

by the designer.


Example: telecom system deployment diagram

<<LAN>>

s bit/sec

<<LAN>>r bit/sec

requests

Service Provider

Database

<<multiprocessor>>

ServiceProvider component instance contains several concurrent high-level object


Example: telecommunication system architecture

PIPELINEWITH BUFFER

UpStrmFilterDownStrmFilterBufferPIPELINE

WITH MESSAGE

UpStrmFilterDownStrmFilter

<<process>>

RequestHandler

1..n

<<process>>

IO

IOin

IOout

<<process>>

Stack

StackIn

StackOut

doubleBuffer

inBuffer

outBuffer

PIPELINEWITH BUFFER

UpStrmFilterDownStrmFilterBufferPIPELINE

WITH MESSAGE

UpStrmFilterDownStrmFilter

CRITICAL SECTION

AccessorShared

CRITICAL SECTION

AccessorShared

CLIENT SERVER

ClientServer

alloc() {sequential}free() {sequential}

ShMem1

update() {sequential}

ShMem2 <<process>>

DataBase

ServiceProvider component

Database component

COALLOCATION

ContainerContained

COALLOCATION

ContainerContained


Main scenario represented as sequence diagrams

enqueue (req)

StackIn:client

IOin inBuffer

input (req)

reserve()

write (req)

signal (awake)

read (req)

ReqHandler outBuffer IOout StackOut

process (req)

write (result)

signal (awake)

read (result)pass (result)

sendBack (result)

Details of process (req)

ReqHandler ShMem1 DataBase ShMem2

interpret (script)

alloc ()

get (script)

update ()free ()


Main scenario represented as sequence diagrams

enqueue (req)

StackIn:client

IOin inBuffer

input (req)

reserve()

write (req)

signal (awake)

read (req)

ReqHandler outBuffer IOout StackOut

process (req)

write (result)

signal (awake)

read (result)pass (result)

sendBack (result)

Details of process (req)

ReqHandler ShMem1 DataBase ShMem2

interpret (script)

alloc ()

get (script)

update ()free ()

<<PAclosedLoad>>{PAPopulation = $Nusers,PAextDelay = (‘mean’, asgn’, 20, ‘ms’)}

<<PAstep>>{Pademand = (‘meas’, ‘mean’, 0.120, ‘ms’)}












Main scenario represented as activity diagram

input (req)

ReqHandler outBuffer IOout StackOutinBufferIOinStackIn

wait

reserve

wait

write(result)

wait

wait

wait enqueue (req)

write (req)

awake

req

read (req)

process (req)

read (result)

awake

pass(result

result

send(result


LQN model for the telecom system

Dummy Proc

pull push alloc free

IOin

RequestHandler

IOout

StackExec

ShMem2

Proc

IOexec

StackIn

StackOut

Buffer ShMem1

update DataBase

ProcDB

Obtained by graph transformation from the following UML diagrams high-level system architecture (described by UML collaborations) deployment diagram showing the allocation of software components to physical devices.


Average execution times per request

Execution time demands per system request

0 1 2 3 4 5

StackIn

StackOut

IOin

IOout

RequestHandler

DataBase

TOTAL

Execution time (msec)

Non-critical section

Critical sect:Buffer

Critical sect:ShMem1

Critical sect:ShMem2

Total


Max throughput for 1, 4 and 6-processor configurations

Maximum Throughput Vs. replication factor of the RequestHandler (RH)

0

200

400

600

800

1000

1200

n=1 processor n=4 processors n=6 processors

Configurations

Th

rou

gh

pu

t [r

eq

ue

sts

/se

co

nd

]

(n-1) RHs

n RHs

(n+1) RHs

(n+2) RHs


Base Case, 1-processor: hardware bottleneck

1-Processor Configuration: Base Case

0

0.2

0.4

0.6

0.8

1

1 2 3 4

Number of RequestHandlers

Uti

liza

tio

n

RequestHandler

Processor

IOExec

StackExec

Database


Base Case, 4-proc: software bottleneck


0

0.2

0.4

0.6

0.8

1

2 4 6 8 10 12 14 16 18 20

Number of RequestHandler replications

Uti

liza

tio

n

IOout Processor

IOExec

StackExec

Database

RequestHandler


Base Case, 6-proc: stronger software bottleneck


0

0.2

0.4

0.6

0.8

1

5 6 7 8 9 10 11 12 13 14 15 16 17 18

Number of RequestHandler Replications

Uti

liza

tio

n

IOout

IOexec Processor

StackExec

DataBase

RequestHandler


0

0.2

0.4

0.6

0.8

1

1.2

3 4 5 6 7 8 9 10 11 12

Number of RequestHandler Reprlications

Uti

liza

tio

n

Useful work by each RequestHandler

Useful work by others on behalf of RequestHandler

RequestHandler is busy while waiting for nested services

0

0.2

0.4

0.6

0.8

1

1.2

3 4 5 6 7 8 9 10 11 12


Uti

liza

tio

n IOout waiting for IOexec

IOexec waiting for semaphore / processor

Useful work: read from buffer

What is the bottleneck task IOout doing ?

IOout is doing only 0.12 ms of useful work on behalf of a system request. Nonetheless, it is the system bottleneck.

RequestHandler is doing 2.75 ms of useful work on behalf of a system request. However, it is not the system bottleneck.

useful work

waitingwaiting

useful work

waitingwaiting


LQN model of the modified system

RequestHandler

IOin

IOout

ShMem2

DataBase

Proc

StackIn

StackOut

write read alloc free

BufferIn ShMem1

read write

BufferOut

update

The original software architecture suffers from serializations constraints at the level of IO process, Stack process and doubleBuffer

Eliminate the serialization constraints in two steps: Each pipeline filter will run on its own process (thread of control) Split the pipeline buffer into two separate buffers, each controlled

by its own semaphore.


Modified system 4-proc configuration: software bottleneck eliminated

4-processor configuration: fully modified system

0

0.2

0.4

0.6

0.8

1

1.2

2 4 6 8 10 12 14 16 18 20

Number of RH replications

Uti

liza

tio

n

Processor

DataBase

RequestHandler

IOout IOin

StackIn

StackOut


Modified system, 6-proc configuration: a new software bottleneck is emerging (DataBase)

6-Processor Configuration: fully modified system

0

0.2

0.4

0.6

0.8

1

5 6 7 8 9 10 11 12 13 14 15 16 17 18


Uti

liza

tio

n

RequestHandler

Processor

DataBase

IOout

StackOut

IOin

StackIn


Tool interoperability (1)

PerformanceModel

UMLModel

UML Tool

AnalysisResults

UML-XML to PROGRES Translator

PROGRESGraphs

PROGRES Tool

LQN Tool

Merge perf results with PROGRES

models


Tool interoperability (2)

PerformanceModel

UMLModel

UML Tool

AnalysisResults

Ad-hoc graph transformations on UML models

LQN Tool


Conclusions We have defined and implemented separate PROGRES graph

transformation for: generating activity diagrams from sequence diagrams generating the LQN model structure from the high-level

architecture (defined by collaborations and deployment diagrams) partitioning the activity diagrams in areas corresponding to

different LQN tasks, entries and phases aggregating the resource demands for different activity diagram

areas (as in the SPE methodology). Currently working on:

Integrating the previous separate PROGRES transformations Extending the graph transformations for newer LQN features Tool interoperability (UML tool, PROGRES, LQN solver):

Take PROGRES out of the loop: define ad-hoc transformations on XML files with UML models produced by a UML tool

Use XSLT for transformation.


References[Amer01] Hoda Amer, “Automatic Transformation of UML Software Specifications into LQN Performance Models Using Graph Grammar Techniques”, Master Thesis, Carleton University, Department of Systems and Computer Eng., May 2001.

[Allen+97] R.Allen, D. Garlan, “A Formal Basis for Architectural Connection”, ACM Transactions on Software Engineering Methodology, Vol.6, No.3, pp 213-249, July 1997.

[Booch+99] G.Booch, J.Rumbaugh, I.Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999.

[Buchmann+96] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, Pattern-Oriented software architecture: A System of Patterns, Wiley Computer Publishing, 1996.

[Franks+95] G. Franks, A. Hubbard, S. .Majumdar, D. Petriu, J. Rolia, C.M. Woodside, “A toolset for Performance Engineering and Software Design of Client-Server Systems”, Performance Evaluation, Vol. 24, Nb. 1-2, pp 117-135, November 1995.

[Franks99] G. Franks. Performance Analysis of Distributed Server Systems, PhD thesis, Department of Systems and Computer Engineering, Carleton University, 1999.

[OMG01] “Response to the OMG RFC for Schedulability, Performance and Time”, version 1.7, June 2002 (to be posted on OMG’s web site)

[Petriu+98] D.C. Petriu, X. Wang "Deriving Software Performance Models from Architectural Patterns by Graph Transformations", in Theory and Applications of Graph Transformations, TAGT'98 (H.Ehrig, G.Engels, H.J. Kreowski, G. Rozenberg, Eds.) Lecture Notes in Computer Science 1764, pp.475-488, Springer Verlag, 2000.


[Petriu+99] D.C. Petriu, X. Wang "From UML description of high-level software architecture to LQN performance models", in "Applications of Graph Transformations with Industrial Relevance AGTIVE'99" (eds. M.Nagl, A. Schuerr, M. Muench), Lecture Notes in Computer Science 1779, pp. 47-62, Springer Verlag, 2000.

[Petriu+00b] D.C.Petriu, Y. Sun, “Consistent Behaviour Representation in Activity and Sequence Diagrams”, to appear in Proc. of UML’2000, York, GB, October 2000.

[Petriu+00b] D.C.Petriu, C.Shousha, A. Jalnapurkar, "Architecture-Based Performance Analysis Applied to a Telecommunication System", to apper in I.E.E.E. Transactions on Software Eng, Vol.26, No.11, pp.1049-1065, Nov. 2000.

[Pooley+99] Pooley, R., Stevens, P.: Using UML: Software Engineering with Objects and Components, Addison Wesley Longman, 1999.

[Ramesh+98] S.Ramesh, H.G.Perros, “A Multi-Layer Client-Server Queueing Network Model with Synchronous and Asynchronous Messages”, Proceedings of the First International Workshop on Software and Performance, Santa Fe, USA, pp.107-119, Oct. 1998.

[Rolia+95] J.A. Rolia, K.C. Sevcik, “The Method of Layers”, IEEE Trans. On Software Engineering, Vol. 21, Nb. 8, pp 689-700, August 1995.

[Rumbaugh +99] Rumbaugh, J., Booch, G., Jacobson, I.: The Unified Modeling Language Rreference Manual, Addison Wesley Longman, (1999)

[Shaw96] M. Shaw, “Some Patterns for Software Architecture” in Pattern Languages of Program Design 2 (J.Vlissides, J. Coplien, and N. Kerth eds.), pp.255-269, Addison Wesley, 1996.


[Schürr90] Schürr, A., “Introduction to PROGRES, an attributed graph grammar-based specification language”, In: M. Nagl (ed): Graph-Theoretic Concepts in Computer Science, Lecture Notes in Computer Science, Vol. 411, pp. 151-165, 1990.

[Schürr94] Schürr, A., “PROGRES: A Visual Language and Environment for PROgramming with Graph Rewrite Systems, Technical Report AIB 94-11, RWTH Aachen, Germany, 1994.

[Schürr97] Schürr, A.,: “Programmed Graph Replacement Systems”, In: G. Rozenberg (ed): Handbook of Graph Grammars and Computing by Graph Transformation, pp. 479-546, 1997.

[Smith90] C.U. Smith, Performance Engineering of Software Systems, Addison Wesley, 1990.

[Smith+97] C.U.Smith and L.G.Williams, “Performance Engineering Evaluation of OO Systems with SPE.ED”, in R. Marie et al.(eds), Computer Performance Evaluation - Modelling Techniques and Tools, Springer LNCS, pp.12-45, 1997.

[UML1.3] OMG: Unified Modeling Language Specification, Version 1.3,1999.

[Williams+98] L.G Williams, C.U.Smith, “Performance Evaluation of Software Architectures”, Proceedings of the First International Workshop on Software and Performance, Santa Fe, USA, pp.164-177, Oct. 1998.

[Woodside89] C.M. Woodside, “Throughput Calculation for Basic Stochastic Rendezvous Networks”, Performance Evaluation, Vol. 9, Number 2, pp.143-160, April 1989.

[Woodside+95] C.M. Woodside, J.E. Neilson, D.C. Petriu, S. Majumdar, “The Stochastic Rendezvous Network Model for Performance of Synchronous Client-Server-like Distributed Software”, IEEE Transactions on Computers, Vol.44, Nb.1, pp 20-34, January 1995.

Documents

Deriving Performance Models from UML Specifications by Graph Transformations