From UML descriptions of high-level software architecture to ...

From UML descriptions of high-level software architecture to ...

Deriving Performance Models from UML Specifications by Graph Transformations Dr. Dorina Petriu Carleton University Department of Systems and Computer Engineering Ottawa, Canada, K1S 5B6 http://www.sce.carleton.ca/faculty/petriu.html June 2001 IEEE Ottawa Computer Chapter talk 1 Outline Motivation Background 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 Layered Queueing Network (LQN) performance models OMG Performance Profile from UML to LQN performance analysis Conclusions IEEE Ottawa Computer Chapter talk Dorina C. Petriu 2 Motivation Software Performance Engineering (SPE) [Smith90]:

Why SPE is not frequently applied in practice: 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 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). IEEE Ottawa Computer Chapter talk Dorina C. Petriu 3 Layered Queueing Network (LQN) 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: Client_1 Proc 1 Client_2 Application Proc 2 Database Proc 3 Disk 1 Disk 2 for identigying and eliminating bottlenecks Example: LQN model of a which limit the system performance three-tiered client-server system for capacity planning and scalability analysis. IEEE Ottawa Computer Chapter talk Dorina C. Petriu 4 Types of LQN messages and phases Client Client synchronous message phase1 (service) reply Server busy included services phase2 phase3 (autonomous phases) idle Server a) LQN synchronous message Client Client

asynchronous message phase1 Server busy phase2 phase3 idle Server included services b) LQN asynchronous message Client Client synchronous message Server1 busy phase1 phase2 reply to original client forwarding Server2 busy idle IEEE Ottawa Computer Chapter talk idle idle phase1 Server1 Server2 phase2 c) LQN forwarding message Dorina C. Petriu 5

LQN extensions: activities, fork/join in an entry T1 P1 0.5 a2 0.5 + a5 a1 & 0.5 a7 a8 + a6 a4 0.5 + & a3[e1] a10 + a9 P2 T2 T4 T3 P3 T6 T5 P4 P5 P6 Sleep_T Sleep_P IEEE Ottawa Computer Chapter talk Dorina C. Petriu 6 Approach to converting UML to LQN models UML

Model Graph Transformations LQN Model Performance Annotations IEEE Ottawa Computer Chapter talk Dorina C. Petriu 7 OMGs 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 IEEE Ottawa Computer Chapter talk Dorina C. Petriu 8 Performance Profile: the domain model PerformanceContext 1 0..n 1 1..n 1..n Workload

1..n 1 1..n 0..n PScenario hostExecDemand responseTime responseTime priority 0..n 0..n 1 +root ClosedWorkload population externalDelay OpenWorkload occurencePattern +successor utilization schedulingPolicy throughput {ordered} 1..n 1 PStep probability repetition delay operations interval executionTime +predecessor +host 0..1 PProcessingResource processingRate contextSwitchTime priorityRange isPreeemptible IEEE Ottawa Computer Chapter talk Presource Dorina C. Petriu PPassiveResource waitingTime responseTime

capacity accessTime 9 Implementation: 2-phase transformation Architectural Information Deployment Diagram Sequence Diagrams Activity Diagram Performance Annotations Collaboration Diagram LQN Models Performance Annotations IEEE Ottawa Computer Chapter talk Dorina C. Petriu 10 Top level sequence diagram for e-commerce application s:serverSocket m:mainServerThread :client listen() connectionRequest() iteration box callback() accept() new w:workerThread * [forever] write(menu) iteration box get(serviceRequest) reqType := checkRequest()

iteration expression [reqType = registration] Customer Registration composite subdiagram [reqType = browse] Browse [reqType = add | reqType = drop ] Add/drop product [reqType = buy] Checkout * [reqType != done] iteration expression [reqType= done] reply(endMsg) IEEE Ottawa Computer Chapter talk Dorina C. Petriu 11 Activity diagram corresponding to the previous SD server client connect request s.listen() m.callback s.accept new(w) w.write(menu) menu unspecified wait for request service request w. get(serviceRequest) w.reqType:=checkRequest() [reqType = done] [reqType reply(endMsg) =registration]

Customer registration [reqType= browse] Browse [reqType=add | reqType=drop ] Add/drop Product composite activity [reqType = buy] Checkout endMsg unspecified w.terminate IEEE Ottawa Computer Chapter talk Dorina C. Petriu 12 More detailed SD and corresponding AD Corresponding activity diagram SD for the iteration box from the top-level diagram specialized for registration client workerthread database register w:workerThread database :client Reply with registration form get(serviceRequest) reqType :=checkRequest() form [to fill] [reqType = registration] reply (registrationForm) send(form) unspecified form [filled]

new :customerAcct Create account and add to database fillIn() reply(account) addAccountt() account addAccoun t * [reqType != done] iteration expression iteration box composite subdiagram Display account created reply account IEEE Ottawa Computer Chapter talk Dorina C. Petriu 13 From architectural patterns and deployment info to LQN Client Client <> m1 bits/s Client ProcC <> m2 bits/s Modem Internet <> <> r bit/sec Database

<> r bit/sec 1 2 3 4 5 6 Server ProcS 1. Connect 2. Registration 3. Browse 4. Add/Drop 5. Checkout 6. Disconnect Server Database ProcDB <> IEEE Ottawa Computer Chapter talk Dorina C. Petriu disk 14 Determine server entries and phases from AD server client connect request s.listen() The resource demands are aggregated separately for each area m.callback s.accept new(w) w.write(menu)

entry1, phase 1 menu unspecified wait for request service request entry6, phase 1 w. get(serviceRequest) w.reqType:=checkRequest() entry 2 - 5, phase 1 [reqType = done] [reqType reply(endMsg) =registration] Customer registration [reqType= browse] Browse [reqType=add | reqType=drop ] Add/drop Product [reqType = buy] Checkout endMsg unspecified w.terminate entry6, phase 2 IEEE Ottawa Computer Chapter talk Dorina C. Petriu 15 Producing Activity Diagram (Phase1 transformation) Architectural Information Sequence Diagrams Represented by Transformation

Rules Performance Annotations Activity Diagram Input Graph Representing Output Graph Objective: Identifying flows of control IEEE Ottawa Computer Chapter talk Dorina C. Petriu 16 SD to AD transformation principles for a single execution thread r a) Sequential execution m a() r n m.a n.b b() m a() c:= b() b) Branch and merge m.a n.b n [c=c1] d() [c=c1] [c=c2] n.d n.f

[c=c2] f() g() n.g r m n a() c) Iteration (looping) m.a b() *[loop condition] c() *[loop condition] IEEE Ottawa Computer Chapter talk Dorina C. Petriu n.b n.c 17 SD to AD transformation principles for multiple execution threads r m n a a a) Synchronous message send and reply reply m.action(a) b() reply b) Asynchronous creation of an active object s n.b r s.a new(m)

a() new m c() n b() n.b s.c s r m n s.a n.b a() c) Asynchronous message b() c f() c d() n.d r.action(c) s.f IEEE Ottawa Computer Chapter talk Dorina C. Petriu 18 Graph Transformations and PROGRES We are using a known graph rewriting tool named PROGRES (PROgramming with Graph Rewriting Systems) [Schrr90, Schrr94, Schrr97] 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. IEEE Ottawa Computer Chapter talk Dorina C. Petriu 19 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 IEEE Ottawa Computer Chapter talk Dorina C. Petriu 20 Schema notation PROGRES uses inheritance (possible multiple) to define hierarchies of node classes Square boxes represent node classes (can have attributes)

Rounded-corner boxes represent node types inheritance relationships are represented with dotted edges node classes correspond to abstract classes in UML 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. IEEE Ottawa Computer Chapter talk Dorina C. Petriu 21 PROGRES Schema for SD to AD transformation Sequence Diagram Active integer Size Sequence Diagram Passive INSTANCE real Asynch real Call Action Reply Send Signal SIGNAL RcvTime SendTime

arg sender receiver seq Local Operation ACTION Create Action dispatch MESSAGE effect perform owns contains maps_to Synch Call ll_next guarded Component DIAGRAM string Name MODEL ELEMENT Return Action Activity Diagram contains Partition owns SubActivity state Initial state Final

state c_flow_in STATE SIMPLE STATE COMPOSITE STATE has cross_ref flow Activity state CTRL BLOCK d_in ObjFlow state Dorina C. Petriu Init Action Conditional Arc d_out PARALLEL Fork IEEE Ottawa Computer Chapter talk Terminate Action Guard Condition maps_to Activity Diagram Destroy Action Join c_flow ALTERNATIVE

Merge Branch 22 Example of a sequence diagram with concurrency Corresponding activity diagram with swimlanes and object flow x y x.send(a) z waiting receive synch msg y.receive(a) u.b() new(z) fork new thread a x y a u b() object flow z new new z.init() new(v) v d() [c = c1] [c = c1] g() [c = c2] h() h()

1 component st 2nd component send asynch msg receive asynch msg r 3 component rd send reply v.h() v.g() u.d() delete(v) f [c = c2] z.delete(v) z.send(f) f y.receive(f) u.h() y.send(r) z.terminate() r x.receive(r) IEEE Ottawa Computer Chapter talk Dorina C. Petriu undefined 23 Example of PROGRES input graph SD comp1 x x y a a 1 u

b() :Send :Call z new new v :Create comp2 comp3 y u :Receive b 2 new 3 :Local :Call d 5 [c = c2] h() f delete(v) :Call r 1st thread comp1 2nd thread comp2 3nd thread comp3 :Call :Receive r 10 IEEE Ottawa Computer Chapter talk :Create :Local :Call h()

Dorina C. Petriu :Receive f 8 h 9 :Send v :Init d() [c = c1] g() z :Destroy new 4 :Local Guard g :Local 6 Guard h :Local 6 delete :Local 7 :Send :Local :Terminate Not all edges sender, receiver and perform are shown. 24 Detailed mapping from SD to PROGRES graph SD comp1 se er nd iv e e c perform r re x y a u disp

b() :Send new z new v ll_next x 1 a effect :Call :Create comp2 y comp3 u perform :Receive seq b 2 new 3 :Local :Call d 5 [c = c2] h() f delete(v) :Call r 1st thread comp1 2nd thread comp2 3nd thread comp3 :Call :Receive r 10

IEEE Ottawa Computer Chapter talk :Create :Local :Call h() Dorina C. Petriu :Receive f 8 h 9 :Send v :Init d() [c = c1] g() z :Destroy new 4 :Local Guard g :Local 6 Guard h :Local 6 delete :Local 7 :Send :Local :Terminate Not all edges sender, receiver and perform are shown. 25 Generating an AD: apply top rule (1) comp2 comp1 comp3 owns x y

u comp1 :Send u b 2 :Call :Local new 3 :Create maps-to a 1 :Receive comp3 maps-to z new owns y maps-to b() s comp2 owns x conta in maps-to a SD s contain z :Init

AD waiting x.send(a) partition1 owns a owns x:InitialSt partition2 partition3 waiting: ActivityState y.receive(a) u.b() new(z) z.init() IEEE Ottawa Computer Chapter talk Dorina C. Petriu 26 Generating an AD: apply synchr. message rule (2) SD comp2 comp1 x y a comp3 u comp1 x perform b() z new :Send se n

de r ei v rec er comp2 y comp3 u perform a 1 effect dispatch :Receive b 2 :Call :Local new 3 :Create z :Init AD waiting x.send(a) partition1 owns a flow x:send d_in d_out a:ObjFlow u.b() partition3 owns x:InitialSt y.receive(a) partition2

waiting flow :Join flow y.receive(a) new(z) z.init() IEEE Ottawa Computer Chapter talk Dorina C. Petriu 27 Generating an AD: apply operation call rule (3) SD y a u comp1 comp2 y x z :Send er new a 1 :Receive seq d sen b() :Call comp3 u eiv er x comp3 rec

comp2 comp1 perform b 2 dispatch effect :Create :Local new 3 z :Init AD waiting x.send(a) partition1 owns a flow x:send partition3 owns x:InitialSt y.receive(a) partition2 d_in d_out a:ObjFlow u.b() waiting flow :Join flow y.receive(a) flow new(z)

u.b() z.init() IEEE Ottawa Computer Chapter talk Dorina C. Petriu 28 Generating an AD: apply create thread rule (4) SD comp2 comp1 x y a comp3 u comp1 y x :Send u owns r de z new a 1 :Receive comp3 n se b() comp2 b 2 :Call :Create :Local new

3 dispatch er eiv c re effect z perform :Init AD waiting x.send(a) partition1 owns a flow x:send partition3 owns x:InitialSt y.receive(a) partition2 d_in d_out a:ObjFlow u.b() waiting flow :Join flow y.receive(a) owns flow new(z) u.b() flow

new(z) flow z.init() IEEE Ottawa Computer Chapter talk :Fork Dorina C. Petriu flow 29 Building LQN Models (Phase2) Deployment Diagram Activity Diagram Represented by Collaboration Diagram Transformation Rules Performance Annotations LQN Models IEEE Ottawa Computer Chapter talk Input Graph Representing Dorina C. Petriu Output Graph 30 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. IEEE Ottawa Computer Chapter talk Dorina C. Petriu 31 UML diagrams for generating the LQN structure Collaboration Deployment diagram with component instances 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) 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 IEEE Ottawa Computer Chapter talk Dorina C. Petriu 32 Transformation of Pipeline and Filters pattern to LQN

UpStreamFilter DownStreamFilte PIPELINE WITH MESSAGE filter1 UpStreamFilt filter2 DownStreamFilter <> <> filter1 filter2 All filters running on the same processor node filter1 UpStreamFilter DownStreamFilter Buffer filter2 write read PIPELINE WITH BUFFER semaphore and buffer proc UpStreamFilter 1..n <> filter1 DownStreamFilter Buffer 1..n <> buffer write() write() {sequential} read() {sequential} read() Filters running on different processor nodes

filter2 filter2 filter1 Note 1: only the structural view is used to transform a UML collaboration to LQN. Note 2: a pattern may produce different LQN models depending on factors such as processor allocation. (obtained from the deployment diagram) IEEE Ottawa Computer Chapter talk Dorina C. Petriu semaphore proc1 write read proc2 33 Transformation of the basic Client-Server pattern to LQN Client Server CLIENT SERVER Client Client 1..n <> <> client1 client2 1..n client2 client1 service2 () service1() Server service1 service2 service2 () server

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. IEEE Ottawa Computer Chapter talk Dorina C. Petriu 34 Transformation of the Critical Section collaboration Users on the same processor node ... user1 userN Accessor Shared semaphore and CRITICAL SECTION f1 f2 . . . fN critical sections Accessor Accessor <> user1 f1 () ... Shared proc <> userN fN () Users on different processor nodes

... user1 shared f1 () {sequential} f2 () {sequential} ... fN () {sequential} semaphore 1 proc1 IEEE Ottawa Computer Chapter talk userN Dorina C. Petriu f1 2 ... N ... fN procN 35 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. IEEE Ottawa Computer Chapter talk

Dorina C. Petriu 36 Example: telecom system deployment diagram requests <> r bit/sec <> Service Provider <> s bit/sec Database ServiceProvider component instance contains several concurrent high-level object IEEE Ottawa Computer Chapter talk Dorina C. Petriu 37 Example: telecommunication system architecture Container Contained Container Contained COALLOCATION COALLOCATION UpStrmFilter DownStrmFilter PIPELINE Buffer UpStrmFilter DownStrmFilter PIPELINE WITH MESSAGE WITH BUFFER <> <> Stack IO StackIn

IOin inBuffer StackOut IOout outBuffer doubleBuffer ServiceProvider component IEEE Ottawa Computer Chapter talk RequestHandle r UpStrmFilter DownStrmFilter Buffer UpStrmFilter DownStrmFilter PIPELINE WITH MESSAGE <> 1..n Client Server PIPELINE WITH BUFFER CLIENT SERVER ShMem1 ShMem2 alloc() {sequential} free() {sequential} update() {sequential} <> DataBase Accessor Shared Accessor Shared CRITICAL SECTION CRITICAL SECTION Dorina C. Petriu

Database component 38 Main scenario represented as sequence diagrams :client StackIn IOin inBuffer ReqHandler outBuffer IOout StackOut input (req) enqueue (req) reserve() write (req) signal (awake) read (req) process (req) write (result) signal (awake) read (result) pass (result) sendBack (result) Details of process (req) ReqHandler ShMem1 DataBase ShMem2 alloc () get (script) interpret (script) update () free () IEEE Ottawa Computer Chapter talk Dorina C. Petriu 39 Main scenario represented as sequence diagrams :client

StackIn IOin inBuffer input (req) reserve() IOout signal (awake) read (req) process (req) <> {Pademand = (meas, mean, 1.998, ms)} <> {Pademand = (meas, mean, 0.105, ms)} write (result) signal (awake) read (result) <> {Pademand = (meas, mean, 0.4028, ms)} pass (result) <> {Pademand = (meas, mean, 0.120, ms)} <> {PAPopulation = $Nusers, PAextDelay = (mean, asgn, 20, ms)} StackOut <> {Pademand = (meas, mean, 0.105, ms)} write (req) <> {Pademand = (meas, mean, 0.120, ms)} outBuffer <> {Pademand = (meas, mean, 0.120, ms)} enqueue (req)

<> {Pademand = (meas, mean, 0.4028, ms)} ReqHandler sendBack (result) Details of process (req) ReqHandler ShMem1 DataBase ShMem2 alloc () get (script) interpret (script) <> {Pademand = (meas, mean, 0.6749, ms)} update () free () IEEE Ottawa Computer Chapter talk Dorina <> {Pademand = (meas, C.mean, Petriu0.1328, ms)} <> {Pademand = (meas, mean, 0.1576, ms)} 40 Main scenario represented as activity diagram StackIn IOin input (req) wait inBuffer ReqHandler outBuffer IOout StackOut

req wait enqueue (req) reserve wait write (req) awake read (req) wait process (req) write(result) wait awake read (result) pass(result send(result result IEEE Ottawa Computer Chapter talk Dorina C. Petriu 41 LQN model for the telecom system StackIn IOin Request Handler Dummy Proc StackOut StackExec IOout IOexec update DataBase ShMem2 pull push alloc Buffer

free ProcDB ShMem1 Proc 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. IEEE Ottawa Computer Chapter talk Dorina C. Petriu 42 Average execution times per request Execution time demands per system request TOTAL DataBase RequestHandler Non-critical section Critical sect:Buffer Critical sect:ShMem1 Critical sect:ShMem2 Total IOout IOin StackOut StackIn 0 1 2 3 4 5 Execution time (msec) IEEE Ottawa Computer Chapter talk Dorina C. Petriu 43 Max throughput for 1, 4 and 6-processor configurations

Maximum Throughput Vs. replication factor of the RequestHandler (RH) 1200 Throughput [requests/second] 1000 800 (n-1) RHs n RHs (n+1) RHs (n+2) RHs 600 400 200 0 n=1 processor n=4 processors n=6 processors Configurations IEEE Ottawa Computer Chapter talk Dorina C. Petriu 44 Base Case, 1-processor: hardware bottleneck 1-Processor Configuration: Base Case Processor 1 RequestHandler Utilization 0.8 IOExec 0.6 0.4 StackExec 0.2 Database 0 1 2

3 4 Number of RequestHandlers IEEE Ottawa Computer Chapter talk Dorina C. Petriu 45 Base Case, 4-proc: software bottleneck 4-Processor Configuration: Base Case IOout Processor IOExec 1 Utilization 0.8 StackExec Database 0.6 RequestHandler 0.4 0.2 0 2 4 6 8 10 12 14 16 18 20 Number of RequestHandler replications IEEE Ottawa Computer Chapter talk Dorina C. Petriu 46

Base Case, 6-proc: stronger software bottleneck 6-Processor Configuration: Base Case 1 IOout StackExec IOexec Processor Utilization 0.8 DataBase RequestHandler 0.6 0.4 0.2 0 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Number of RequestHandler Replications IEEE Ottawa Computer Chapter talk Dorina C. Petriu 47 What is the bottleneck task IOout doing ? 1.2

1 0.8 Utiliz ation IOout is doing only 0.12 ms of useful work on behalf of a system request. Nonetheless, it is the system bottleneck. IOout waiting for IOexec 0.6 waiting 0.4 IOexec waiting for semaphore / processor 0.2 useful work Useful work: read from buffer 0 3 4 5 6 7 8 9 10 11 12 Number of RequestHandler replications 1.2 1 RequestHandler is busy while waiting for nested services 0.8 U tiliz ation RequestHandler

is doing 2.75 ms of useful work on behalf of a system request. However, it is not the system bottleneck. 0.6 Useful work by others on behalf of RequestHandler 0.4 waiting 0.2 Useful work by each RequestHandler useful work 0 3 IEEE Ottawa Computer Chapter talk 4 5 6 7 8 9 Number of RequestHandler Dorina C. Petriu Reprlications 10 11 12 48 LQN model of the modified system StackIn IOin Request Handler

StackOut IOout read write BufferOut write read BufferIn alloc free ShMem1 update DataBase ShMem2 Proc 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. IEEE Ottawa Computer Chapter talk Dorina C. Petriu 49 Modified system 4-proc configuration: software bottleneck eliminated 4-processor configuration: fully modified system 1.2 Processor 1 IOout Utilization 0.8 IOin DataBase

RequestHandler 0.6 StackIn 0.4 StackOut 0.2 0 2 4 6 8 10 12 14 16 18 20 Number of RH replications IEEE Ottawa Computer Chapter talk Dorina C. Petriu 50 Modified system, 6-proc configuration: a new software bottleneck is emerging (DataBase) 6-Processor Configuration: fully modified system RequestHandler 1 Processor DataBase Utilization 0.8 IOout IOin StackOut StackIn 0.6 0.4

0.2 0 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Number of RequestHandler replications IEEE Ottawa Computer Chapter talk Dorina C. Petriu 51 Tool interoperability (1) UML Tool UML Model UML-XML to PROGRES Translator Merge perf results with PROGRES models Analysis Results PROGRES Graphs LQN Tool PROGRES Tool

IEEE Ottawa Computer Chapter talk Performance Model Dorina C. Petriu 52 Tool interoperability (2) UML Tool UML Model Ad-hoc graph transformations on UML models Analysis Results LQN Tool Performance Model IEEE Ottawa Computer Chapter talk Dorina C. Petriu 53 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. IEEE Ottawa Computer Chapter talk Dorina C. Petriu 54 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 OMGs 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. IEEE Ottawa Computer Chapter talk Dorina C. Petriu 55 [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 UML2000, 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. IEEE Ottawa Computer Chapter talk Dorina C. Petriu 56

[Schrr90] Schrr, 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. [Schrr94] Schrr, A., PROGRES: A Visual Language and Environment for PROgramming with Graph Rewrite Systems, Technical Report AIB 94-11, RWTH Aachen, Germany, 1994. [Schrr97] Schrr, 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. IEEE Ottawa Computer Chapter talk Dorina C. Petriu 57

Recently Viewed Presentations

  • USC Brain Project Specific Aims

    USC Brain Project Specific Aims

    Computational Architectures in Biological Vision, USC, Spring 2001 Lecture 5. More Introduction to Vision Reading Assignments: Chapters 5 and 6.
  • Native American

    Native American

    Functions Of Music in Native American Culture Religious ceremonies Healing ceremonies Work songs Game songs Honoring songs Courting songs Social songs Songs to bring success in hunting/farming Vocables- syllables sung in Native American music The song is a gift from...
  • MODULE C - nj.gov

    MODULE C - nj.gov

    For ELLs, the Language Objective, is also similar: "include illustrations, diagrams, captions with writing to support comprehension". As explained in Module B, based on the descriptors from the WIDA rubric, VU (Vocabulary Usage) would allow the ELL to use illustrations;...
  • Using data to fill an ARC Cora Gleeson

    Using data to fill an ARC Cora Gleeson

    * Due to historical reasons the Glucksman Library has been fortunate to have a significant bookfund. To put this in context we place 20,000+ orders on an annual basis. All orders have until recently been copy-catalogued and had class numbers...
  • IGCSE FM Trigonometry II Dr J Frost (jfrost@tiffin.kingston.sch.uk)

    IGCSE FM Trigonometry II Dr J Frost ([email protected])

    Sine/Cosine Rule Recap. 65° 45° 5 ? We have two angle-side pairs involved, so use sine rule. ??????=???????=??????×??????=?.?? ? 40° 10 8 Sine rule angle, but this time angle unknown, so put as numerator.
  • DIABETES 10 POINT TRAINING Ruth Miller RGN BSc

    DIABETES 10 POINT TRAINING Ruth Miller RGN BSc

    A set of didactic instructions directed at clinicians giving care to patients with diabetes. Objective: to improve quality of care and safety for all patients with diabetes. Key principle: recognition that conflicting pressure on clinicians leave them with little time....
  • ASEAN Integration: Cross Border Mobility of Library

    ASEAN Integration: Cross Border Mobility of Library

    ASEAN Integration: Cross Border Mobility of Librarians MALAYSIA 9 June 2015 Viva Garden Serviced Residence Bangkok, Thailand Persatuan Pustakawan Malaysia Librarians Assosiation of Malaysia MALAYAN LIBRARY GROUP (MLG): Inauguration 25 March 1955 Registered 6 June 1955 Library Association of Malaya...
  • Chemistry Without bonding the universe would be a

    Chemistry Without bonding the universe would be a

    Sharing still takes place but is an uneven sharing. a) calculate the difference in electronegativities: 4.0 - 0.9 = 3.1 ionic (electrons are transferred) b) Draw the electron dot/Lewis structure: Na + F = Na F + - Describes a...