deriving performance models from uml models by graph … · 2000. 9. 25. · wosp’ 2000 ©dorina...

September 2000 WOSP’2000 1

Deriving Performance Models from UMLModels by Graph Transformations

Dr. Dorina PetriuCarleton University

Department of Systems and Computer EngineeringOttawa, Canada, K1S 5B6

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

WOSP’ 2000 ©Dorina Petriu 2

Outline■ Background

● Layered Queueing Network (LQN) performance models■ Methodology for performance model derivation■ Software execution model

● represented by UML activity diagrams● automatic generation of activity diagrams from sequence

diagrams by graph transformations■ Generation of LQN performance model by graph

transformations● LQN model structure● LQN model parameters

■ Conclusions


Motivation■ Software Performance Engineering (SPE) [Smith90]:

● integrate performance evaluation into the softwaredevelopment process from the early stages throughout thewhole life-cycle

● requires the construction and analysis of performancemodels

■ 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

■ Present research: automate the derivation of LQNperformance models from UML design models:

● LQN model structure generated from high-level softwarearchitecture

● LQN model parameters from software execution model(activity diagrams).


■ LQN is an extended Queueing Networkmodel:

● both software tasks and hardware devicesare represented (drawn as parallelogramsand circles)

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

● software components have entriescorresponding 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 bottleneckswhich limit the system performance

● for capacity planning and scalabilityanalysis.

Client_1 Client_2

Application

Database

Proc 1

Proc 3

Proc 2

Disk 1 Disk 2

Example: LQN model of athree-tiered client-server system

Layered Queueing Network (LQN)


Types of LQN messages and phases

phase1 (service)

Client

Server

synchronousmessage

busy

reply

included servicesphase2 phase3

(autonomous phases)

idle

Client

Server

a) LQN synchronous message

Client

Serverbusy

included services

phase1

phase2 phase3idle

b) LQN asynchronous message

Client

Server

asynchronousmessage

forwarding

Clientsynchronous

message

reply tooriginal client

Server1 busy phase1 phase2 idle

Client

Server1

c) LQN forwarding message

Server2busy idle phase1 phase2 idle

Server2


Methodology

■ Our transformation from UML to LQN follows the generalSoftware Performance Engineering approach [Smith90]

■ First select the main use cases to be modelled.● Probabilities of selected use cases will determine the workload mix

(similar to [Cortellessa+00]) .■ The software execution model is represented as UML

activity diagrams.● The activity diagrams are automatically derived by graph

transformations from a set of interaction (sequence) diagrams thatdescribe the system behaviour.

● The activity diagrams are partitioned in swimlanes correspondingto different software components responsible for various activities.

● The resource demands are represented as activity attributes.


Methodology (cont)

■ The structure of the LQN performance model is derivedfrom the high level architecture of the UML model.

● LQN nodes represent both software and hardware entities● Architectural patterns given as UML collaborations describe the

interaction between concurrent components.● Graph transformations from different UML collaborations are used

to generate the LQN structure● UML component and deployment diagrams are used to determine

the allocation of software components to hardware devices.

■ LQN parameters are obtained by aggregating the resourcedemands for different activity diagram partitions thatcorrespond to LQN entries and phases.

● The aggregation follows the rules from [Smith90] and is performedby graph transformations.







■ Conclusions


Top level sequence diagram for e-commerce applications: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()

connectrequest

m.callbacks.acceptnew(w)

w.write(menu)

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

menu

servicerequest

Customerregistration

Add/dropProduct

Browse Checkoutreply(endMsg)

endMsg

w.terminate

unspecifiedwait forrequest

unspecified

compositeactivity


More detailed SD and corresponding AD

addAccount

register

client workerthread database

Create account andadd to database

form[to fill]

form[filled]

Reply withregistration form

Display accountcreated

account

reply

account

unspecified

SD for the iteration box fromthe 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


SD to AD transformation principles fora single execution thread

r 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) Sequentialexecution

b) Branch andmerge

c) Iteration(looping)

m.a n.b

n.bn.c


r m n

b()

a

replym.action(a)

a

n.breply

a) Synchronous messagesend and reply

b) Asynchronouscreation of an active

object

c) Asynchronousmessage

n.b

s.anew(m)

s.c

a()

r

m

s

b()

c()new n

a()

r ms

d()

cb()

n

f() n.d

s.a

r.action(c)s.f

n.b

c

SD to AD transformation principles formultiple execution threads


Graph Transformations and PROGRES■ We are using a known graph rewriting tool named PROGRES

(PROgramming with Graph Rewriting Systems) [Schürr90, 94, 97]■ 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” areoften considered synonymous, however:

● a graph grammar is a set of production rules that generates alanguage of terminal graphs and produces nonterminal graphsas intermediate results.

● a graph rewriting system is a set of rules that transforms oneinstance of a given class of graphs into another instance of thesame class of graphs without distinguishing terminal andnonterminal results.


PROGRES Schema

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

■ The graph schema shows the types of nodes and edgescomposing a valid graph

■ A set of production rules are applied in a controlled way inorder to performs the graph transformations.

● a production rule has a left-hand side defining a graphpattern that will be matched in the overall graph thenreplaced 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, whichdefine the relationships between node instances.

■ Node attributes are shown as small circles attached to the classor type boxes.


PROGRES Schema for SD to AD transformation

Namestring

CallAction

SendSignal

LocalOperation

CreateAction

DestroyAction

TerminateAction

ReturnAction

ACTION

ll_nextowns

senderMESSAGE

Asynch

SendTime

real SIGNAL

ReplySynchCall

RcvTime

real

INSTANCE

Active Passive

integerSize

MODELELEMENTDIAGRAM

Component

SequenceDiagram

ActivityDiagram Partition

receiver

arg

STATE

GuardCondition

contains

contains owns

maps_to

effect

SubActivitystate

SIMPLESTATE

COMPOSITESTATE

CTRLBLOCK

Initialstate

Finalstate

Activitystate

ObjFlowstate

Fork Join Merge Branch

PARALLEL ALTERNATIVE

ConditionalArc

guarded

has

c_flowd_in

d_out

flow

c_flow_in

cross_ref

dispatch

perform

InitAction

seq

map

s_to

Sequence Diagram

ActivityDiagram


a

f

r

Example of a sequencediagram with concurrency

Corresponding activity diagramwith swimlanes and objectflow

x

v

uy

z

r

b()a

newnew

d()

[c = c2] h()

[c = c1] g()

delete(v)fh()

1st thread 2nd thread 3nd thread

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)


Example of PROGRES input graph

x

v

uy

z

r

b()a

newnew

d()

[c = c2] h()

[c = c1] g()

delete(v)fh()

1st threadcomp1

2nd threadcomp2

3nd threadcomp3

SD

comp1 comp2 comp3

x y ua

z:Send

:Receive

1 :Receiveb

:Call :Local2

3

4

:Createnew v

new

:Init

:Create:Call :Local5

d:Local

6:Call:Local

6:Call:Local

g

h

Guard

Guard

7:Destroy:Localdelete

8f

:Send:Receive

:Call :Local9h

10 :Sendr

:Terminate

Not all edges sender, receiverand 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)fh()

1st threadcomp1

2nd threadcomp2

3nd threadcomp3

SD

comp1 comp2 comp3

x y u

a z:Send

:Receive

1 :Receiveb

:Call :Local2

3

4

:Createnew v

new

:Init

:Create:Call :Local5

d:Local

6:Call:Local

6:Call:Local

g

h

Guard

Guard

7:Destroy:Localdelete

8f

:Send:Receive

:Call :Local9h

10 :Sendr

:Terminate

Not all edges sender, receiverand perform are shown.

sender performreceiv

erperform

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:InitialSt y:InitialSt

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


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

partition1

a

z


3:Createnew

:Init

perform

SD

comp1 comp2 comp3

x y urec

eiversender

dispatch effect

perform

AD



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


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

partition1

a

z


3:Createnew

:Init

seq

SD

comp1 comp2 comp3

x y u

rece

iversender

dispatch effect

perform

AD



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


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

partition1

a

z

:Send 1:Receive b:Call

:Local2

3:Createnew

:Init

owns

SD

comp1 comp2 comp3

x y u

receiv

er

sender

dispatch effect

perform

AD



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







■ Conclusions


Architectural patterns

■ The literature identifies a relatively small number ofarchitectural patterns which describe the collaborationbetween high-level concurrent components:

● pipe and filters● client server● broker● layers● critical section● master-slave

■ The high-level architecture of a software system asdescribed by architectural patterns will determine thestructure of an LQN performance model.

● LQN nodes represent concurrent components or high-levelobjects 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 cooperativebehaviour that is bigger than the sum of all of its parts”

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

■ Deployment diagram with component instances● identifies runtime component instances● shows their allocation to physical devices (LQN nodes

represent both software and hardware entities)


UML collaboration: Forwarding Broker pattern

client fwd-broker server

req_service_k()

service_k()

reply()

reply()

serve otherrequests

. . .service_k( ). . .

<<process>>server

<<process>>

fwd-broker

<<process>>

client

1..n

Client

Broker

Server

FWD_BROKER

ClientServerBroker

Structure Behaviour


UML collaboration: Handle-Driven Broker pattern

. . .service_k( ). . .

<<process>>server

<<process>>

hd-broker

<<process>>

client

1..n

Broker

Server

Client

HD_BROKER

ClientServerBroker

client hd-broker server

get_handle()

service_k()

return

Structure Behaviour


Deployment diagram for e-commerce system

DatabaseServer

Client Client Client

<<Internet>>

<<disk>>

<<Modem>>m1 bits/s

<<Modem>>m2 bits/s

<<Modem>>m3 bits/s

<<LAN>>r bit/sec

<<LAN>>r bit/sec


Transformation of Pipeline and Filters pattern to LQN

filter1 filter2

semaphoreand buffer

write read

proc

All filters running on thesame processor node

proc1 proc2write read

Filters running on differentprocessor nodes

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

PIPELINEWITH MESSAGE

<<process>>

filter1

UpStreamFilt

<<process>>

filter2

DownStreamFilter

UpStreamFilterDownStreamFilte

Structure

DownStreamFilter

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

buffer<<process>>

filter1

1..n<<process>>

filter2

1..n

write() read()

PIPELINE WITH BUFFER

UpStreamFilter Buffer

UpStreamFilterDownStreamFilterBuffer

StructureNote 1: only the structural view is used to transform aUML collaboration to LQN.

filter1 filter2

filter1 filter2

semaphore


Transformation of the basic Client-Server patternto 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 Client-Server pattern withForwarding Broker


server

<<process>>

client2

1..n<<process>>

client1

1..n

Client Client

Server

FWD_BROKER


client1 client2

forwardingbroker

server

service1 service2

ClientServerBroker

Note 1: the broker (a midware component) isnot explicitly represented in the architectureof the software under development (it ishidden inside the collaboration, as it isprovided by the underlying middleware).

Note 2:the LQN model represents allthe system layers used by the software.In this case, the broker is explicitlyrepresented as a multi-server that hasan entry for every server entry called.


Transformation of the Client-Server pattern withHandle-Driven Broker

client1 client2

server

service1 service2handle-drivenbroker


server

<<process>>

client2

1..n<<process>>

client1

1..n

Client Client

Server

HD_BROKER


ClientServerBroker


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 andcritical 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 participantsfrom the detailed behaviour described in the activitydiagrams

● For example, client-server interactions are easy to recognizewhen the client sends a synchronous message to the serverand waits for the reply

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

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

❷ The designer of the UML model indicates the architecturalpatterns used.

● Check if the detailed behaviour conforms to the patternindicated by the designer.


Graph rewriting approach with PROGRES■ The graph schema (see next slide) describes the valid node

types/classes, node attributes and edge types.■ Each architectural component (instance) is converted to an

LQN task, but the mapping is not bijective because:● an instance may generate more than one task (ex. critical section)● instances may be hidden by some collaborations (ex. brokers)

■ Instance operations are converted to entries.■ Processors and devices obtained from the deployment

diagrams become full-fledged nodes in LQN.■ Collaboration nodes have no LQN correspondent, but help

deciding what kind of transaction to perform.■ A PROGRES transaction was defined for the translation of

each architectural pattern into LQN (a transaction is atomic)■ Each transaction is composed of one or more production

rules, which formally define the basic steps of graph trans-formations (left-hand-side is replaced by right-hand-side).


real

integer Forward

COMP_TASK PORT_ENTRY

INSTANCE

PASSIVE

OPERATION

NonShared

Device

Multiplicity

Processor

integer

stringstring[0::n]

MODELELEMENT

Namestring

Entry

Device Sync Async

has

uses

realServiceTimeMultiplicity

integer

SeviceTime

Multiplicity

in

outout

inout

in

Task

link

has

Shared Active

COLLABORATION

PIPELINE &FILTERS

contains

CLIENT_SERVERclientserver

upStrmFilter

downStrmFilter

DoubleFilterCriticalSection

broker

container filtershared accessor

Pipelinewith Message

Pipelinewith Buffer Direct

Client-Server

Handle-drivenBroker

Half-forwardingBroker

ForwardingBroker

Constraint string

ExecTime real

ARC_PARAM

real

NbV

isits

string

From

Nam

e

string

ToN

ame

CALL_EDGENbVisits real

from to

buffer

Schema for transformation from UML collaborations to LQN

LQN

Collaborations


Example: Production Rule for the Critical Section

‘1: Active ‘2: CriticalSect ‘3: INSTANCE

‘5: CALL_EDGE ‘4: Operation

accessor shared

tofrom has

2’: ‘2 3’ = ‘3

10’: Device 4’ = ‘4uses uses

has

1’ = ‘1

6’: Entry

has

8’: Entry 9’ = Syncout

in

7’: Sync

out

in

‘1: Active

:=

transfer 6’.Name := ‘1.Name & “Entry”; 7’.NbVisits := ‘5.NbVisits;8’.Name := ‘4.Name & “CritSect”; 9’.ToName := 4’.Name;7’.FromName := 6’.Name; 9’.FromName := 8’.Name;7’.ToName := ‘5.Name; 9’.NbVisits := 1;

10’.Name := ‘1.Processor;


Deployment diagram for a telecom system

<<LAN>>s bit/sec

<<LAN>>r bit/sec

requests

ServiceProvider

Database

<<multiprocessor>>

ServiceProvider componentinstance contains severalconcurrent 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

ServiceProvidercomponent

Databasecomponent


LQN model structure for the telecom system

DummyProc

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 softwarecomponents to physical devices.







■ Conclusions


Deployment diagram for e-commerce system

DatabaseServer

Client Client Client

<<Internet>>

<<disk>>

<<Modem>>m1 bits/s

<<Modem>>m2 bits/s

<<Modem>>m3 bits/s

<<LAN>>r bit/sec

<<LAN>>r bit/sec


LQN model for e-commerce system

ProcDB

Database

disk

Client

ProcS

ProcC

ModemInternet

1 2 3 4 5 6 Server

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


AD partitioning: determine server entries and phases

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

[reqType = done]

client server

s.listen()

connectrequest

m.callbacks.acceptnew(w)

w.write(menu)

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

menu

servicerequest

Customerregistration

Add/dropProduct

Browse Checkoutreply(endMsg)

endMsg

w.terminate

unspecified

unspecified

request

request

reply

reply

entry1, phase 1

entry 2 - 5, phase 1

entry6,phase 1

entry6,phase 2

wait forrequest

The resourcedemands areaggregated

separately foreach area


Tool interoperability (1)

PerformanceModel

UMLModel

UML Tool

AnalysisResults

UML-XML toPROGRESTranslator

PROGRESGraphs

PROGRESTool

LQN Tool

Merge perfresults withPROGRES

models


Tool interoperability (2)

PerformanceModel

UMLModel

UML Tool

AnalysisResults

Ad-hoc graphtransformationson 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 deploymentdiagrams)

● partitioning the activity diagrams in areas corresponding todifferent LQN tasks, entries and phases

● aggregating the resource demands for different activitydiagram 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):

▼ obtain PROGRES input graphs from XML descriptions ofUML diagrams produced by a UML tool, and vice-versa.


References[Allen+97] R.Allen, D. Garlan, “A Formal Basis for Architectural Connection”, ACM Transactionson 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-Orientedsoftware architecture: A System of Patterns, Wiley Computer Publishing, 1996.

[Cortellessa+00] V. Cortellessa, R. Mirandola, “Deriving a Queueing Network based PerformanceModel from UML Diagrams”, Proceedings of the Second International Workshop on Software andPerformance,Ottawa, Sept. 2000.

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

{MSC99] International Telecommunication Union: Formal description techniques (FDT) –Message Sequence Chart, ITU-T Z.120 (1999)

[Petriu+98] D.C. Petriu, X. Wang "Deriving Software Performance Models from ArchitecturalPatterns 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 ComputerScience 1764, pp.475-488, Springer Verlag, 2000.


[Petriu+99] D.C. Petriu, X. Wang "From UML description of high-level software architecture toLQN performance models", in "Applications of Graph Transformations with Industrial RelevanceAGTIVE'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 SequenceDiagrams”, to appear in Proc. of UML’2000, York, GB, October 2000.

[Petriu+00b] D.C.Petriu, C.Shousha, A. Jalnapurkar, "Architecture-Based Performance AnalysisApplied to a Telecommunication System", to apper in I.E.E.E. Transactions on SoftwareEng.(special issue Workshop on Software and Performance), 2000.

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

[Ramesh+98] S.Ramesh, H.G.Perros, “A Multi-Layer Client-Server Queueing Network Modelwith Synchronous and Asynchronous Messages”, Proceedings of the First InternationalWorkshop 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 SoftwareEngineering, Vol. 21, Nb. 8, pp 689-700, August 1995.

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

[Shaw96] M. Shaw, “Some Patterns for Software Architecture” in Pattern Languages of ProgramDesign 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-basedspecification 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 withGraph 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 Systemswith SPE.ED”, in R. Marie et al.(eds), Computer Performance Evaluation - Modelling Techniquesand 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 RendezvousNetworks”, 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 StochasticRendezvous Network Model for Performance of Synchronous Client-Server-like DistributedSoftware”, IEEE Transactions on Computers, Vol.44, Nb.1, pp 20-34, January 1995.

deriving performance models from uml models by graph … · 2000. 9. 25. · wosp’ 2000 ©dorina...

Documents