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
WOSP’ 2000 ©Dorina Petriu 3
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).
WOSP’ 2000 ©Dorina Petriu 4
■ 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)
WOSP’ 2000 ©Dorina Petriu 5
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
WOSP’ 2000 ©Dorina Petriu 6
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.
WOSP’ 2000 ©Dorina Petriu 7
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.
WOSP’ 2000 ©Dorina Petriu 8
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
WOSP’ 2000 ©Dorina Petriu 9
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
WOSP’ 2000 ©Dorina Petriu 10
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
WOSP’ 2000 ©Dorina Petriu 11
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
WOSP’ 2000 ©Dorina Petriu 12
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
WOSP’ 2000 ©Dorina Petriu 13
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
WOSP’ 2000 ©Dorina Petriu 14
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.
WOSP’ 2000 ©Dorina Petriu 15
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
WOSP’ 2000 ©Dorina Petriu 16
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.
WOSP’ 2000 ©Dorina Petriu 17
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
WOSP’ 2000 ©Dorina Petriu 18
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)
WOSP’ 2000 ©Dorina Petriu 19
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.
WOSP’ 2000 ©Dorina Petriu 20
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
WOSP’ 2000 ©Dorina Petriu 21
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
WOSP’ 2000 ©Dorina Petriu 22
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
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
x:send :Joinflow flow
a:ObjFlow
d_in d_out
y.receive(a)flow
ownsowns
WOSP’ 2000 ©Dorina Petriu 23
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
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
x:send :Joinflow flow
a:ObjFlow
d_in d_out
y.receive(a)flow
u.b()flow
ownsowns
WOSP’ 2000 ©Dorina Petriu 24
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
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
x:send :Joinflow flow
a:ObjFlow
d_in d_out
y.receive(a)flow
new(z)
flow
ownsowns
:Forkflow
u.b()flow
owns
flow
WOSP’ 2000 ©Dorina Petriu 25
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
WOSP’ 2000 ©Dorina Petriu 26
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.
WOSP’ 2000 ©Dorina Petriu 27
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)
WOSP’ 2000 ©Dorina Petriu 28
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
WOSP’ 2000 ©Dorina Petriu 29
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
WOSP’ 2000 ©Dorina Petriu 30
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
WOSP’ 2000 ©Dorina Petriu 31
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
WOSP’ 2000 ©Dorina Petriu 32
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.
WOSP’ 2000 ©Dorina Petriu 33
Transformation of the Client-Server pattern withForwarding Broker
service1()service2()
server
<<process>>
client2
1..n<<process>>
client1
1..n
Client Client
Server
FWD_BROKER
service1() service2 ()service2 ()
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.
WOSP’ 2000 ©Dorina Petriu 34
Transformation of the Client-Server pattern withHandle-Driven Broker
client1 client2
server
service1 service2handle-drivenbroker
service1()service2()
server
<<process>>
client2
1..n<<process>>
client1
1..n
Client Client
Server
HD_BROKER
service1() service2 ()service2 ()
ClientServerBroker
WOSP’ 2000 ©Dorina Petriu 35
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
WOSP’ 2000 ©Dorina Petriu 36
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.
WOSP’ 2000 ©Dorina Petriu 37
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).
WOSP’ 2000 ©Dorina Petriu 38
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
WOSP’ 2000 ©Dorina Petriu 39
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;
WOSP’ 2000 ©Dorina Petriu 40
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
WOSP’ 2000 ©Dorina Petriu 41
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
WOSP’ 2000 ©Dorina Petriu 42
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.
WOSP’ 2000 ©Dorina Petriu 43
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
WOSP’ 2000 ©Dorina Petriu 44
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
WOSP’ 2000 ©Dorina Petriu 45
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
WOSP’ 2000 ©Dorina Petriu 46
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
WOSP’ 2000 ©Dorina Petriu 47
Tool interoperability (1)
PerformanceModel
UMLModel
UML Tool
AnalysisResults
UML-XML toPROGRESTranslator
PROGRESGraphs
PROGRESTool
LQN Tool
Merge perfresults withPROGRES
models
WOSP’ 2000 ©Dorina Petriu 48
Tool interoperability (2)
PerformanceModel
UMLModel
UML Tool
AnalysisResults
Ad-hoc graphtransformationson UML models
LQN Tool
WOSP’ 2000 ©Dorina Petriu 49
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.
WOSP’ 2000 ©Dorina Petriu 50
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.
WOSP’ 2000 ©Dorina Petriu 51
[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.
WOSP’ 2000 ©Dorina Petriu 52
[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.