(QN) models has been often proposed to support software designers during the ..... quest (QN customer) between the service centers and the time it spends in ...
Compositional Generation of Software Architecture Performance QN Models Antinisca Di Marco, Paola Inverardi Dipartimento di Informatica University of L’Aquila Via Vetoio 1, 67010 Coppito, L’Aquila, Italy {adimarco,inverard}@di.univaq.it Abstract Early performance analysis based on Queueing Network Models (QNM) has been often proposed to support software designers during the software development process. These approaches aim at addressing performance issues as early as possible in order to reduce design failures. All of them try to adapt to software systems the well-known system performance analysis methodology. This implies that they assume at design time the availability of information about the hardware platform the software will run on. In recent years we have proposed a methodology that allows quantitative reasoning on software aspects without considering hardware aspects. In this work we extend our methodology to encompass a compositional approach to performance analysis of software architecture described by means of UML2.0 diagrams. The main improvements include the characterization of architectural patterns and of their corresponding QNM pattern; the use of multi-chain queueing network as system target model and the identification of the information needed to parameterize the system model.
Message Sequence Charts describing the behavior of a software system. By applying this original methodology to complex case study we have discovered that the approach is not able to consider all their aspects. In particular we find problems in considering software systems that provide several services by means of software component interactions having different meaning, but involving the same software components. In this work we extend our methodology to encompass a compositional approach to QN model generation for the software architecture described by means of UML2.0 diagrams. The used UML diagrams are the use case diagrams, the sequence diagrams and the component diagram. The new version of the methodology improves the original one in several directions: • it introduces the multi-chain QN model [6] to deal with software systems that export multiple services. For each software system service the methodology defines a chain in the QN model that represents a QN customer type. A QN customer type specifies the behavior inside the QN model for all the requests of that type. • It deals with the QN parameterization.
1. Introduction Early performance analysis based on Queueing Network (QN) models has been often proposed to support software designers during the software development process [2]. These approaches aim at addressing performance issues as early as possible in order to reduce design failures. All of them try to adapt to software systems the well-known system performance analysis methodology. This implies that they assume at design time the availability of information about the hardware platform the software will run on. In recent years we have proposed a methodology that allows quantitative reasoning on software aspects without considering hardware aspects [1, 4]. This methodology allows automatic generation of a QN model [6] from a set of
• The new QN generation approach is compositional and driven by architectural patterns making easier the architectural feedbacks generation. We decided to migrate towards UML notation with the specification of UML 2.0 [9]. We postpone the discussion about this choice later in the Section 3. As done in [4], we show the new approach by applying it to a simple case study, that is a simplified version of the electronic commerce system in [5]. Our goal is to present a methodological approach to the QN definition from the specification of a software architecture. It is out of the scope of this paper to derive and discuss the results obtained by evaluating the derived performance models.
Trace Analysis Traces Generation
SA Description Traces/Regular Exp Message Sequence Charts
MSC2QN Methodology
Feedback
Queuing Network Model
Performance Evaluation
Interaction Sets definition
Interaction Sets QN generation Interaction sets analysis
Intermediate QN and set of real concurrent components
Results
Results Interpretations
QN model restructuring
Figure 1. Software Performance Analysis Process and MSC2QN methodology.
The paper is organized as following: the next Section summarizes the main features of the original approach, Section 3 motivates the migration towards UML notation, Section 4 presents the new methodology and it shows the principal features of the approach by applying them on the chosen case study. Section 5 presents some considerations on our approach to performance analysis of software architectures. Section 6 concludes the paper.
2. Our original approach to Software Architecture Performance analysis In [1, 4] we have defined a methodology that, starting from a Software Architecture (SA) description given by means of Message Sequence Charts (MSC) [7], automatically derives a performance evaluation model, based on a Queueing Network (QN) model [6]. From the QN evaluation the designers might have insight on the goodness of their decisions with respect to performance aspects. The left-hand side of Figure 1 sketches the software performance analysis process we use to validate SA. In the Figure, ovals represent activities of the process whereas rectangles indicate the output of each process step. The software performance analysis process takes as input the MSCbased description of a SA, goes through our methodology (MSC2QN methodology), and through the model evaluation and finally provides feedbacks at the architectural level from the results interpretation. The MSC2QN step allows the generation of the QN
topology. Very briefly we recall that the topology of a QN model is represented by a set of service centers, which are independent entities, suitably connected. The translation algorithm applied in our approach aims at deriving a QN model as close as possible to the SA model: where the software components that are strongly synchronized are represented by means of a single service center, and independent components are instead associated to individual service centers. Service centers are then connected in the QN model depending on how the SA components interact with each other (see [4] for more details). At the right-hand side of Figure 1 we outline the macro steps of the MSC2QN methodology which are: 1. the Trace Analysis phase that starts encoding the MSC by means of regular expressions. These regular expressions are analyzed in pair to find out their common prefix and to identify interaction pairs that can give information on the real concurrency between SA components. These interactions pairs form the Interaction sets. 2. the QN Generation step that, by analyzing the Interaction sets, identifies the components or sets of components that can be modelled as service centers of the final QN and identifies the interconnections among the service centers, i.e. the topology of the QN. To apply our methodology, the set of MSC must be representative of major system behaviors and for each SA component there must exist at least an MSC describing its interactions with other components. In the original version of the methodology we make a crucial assumption: all the MSC of the SA description start from the same initial state of the software system. In other words there is no hierarchy among MSC, and every one can only be triggered, in practice, from an external event. This constraint may be overcome by making use of HMSC [7]. Moreover, to simplify the approach, we assume that the primitive basic communication between components is one to one. This assumption is not restrictive since both multiple-senders and multiple-receivers interactions can be modelled by a set of one to one communications. This approach has many limits. First of all, it is not able to properly manage complex systems having more than one functionality. The approach loses information about the type of exchanged messages maintaining information only on the components involved in the communication. Two errors arise when more software system services are considered: we cannot distinguish different types of communications having the same sender and receiver and, as a consequence, we do not know the subsequent evolution of the execution trace and the service rate to be applied when the communications are very different from each other. This
Comp1
Comp2
Comp3 op1
op2()
(a) split/fork communication Comp1
Comp2
We require that, if a component is designed as a multithread component, state information for that component is a tuple of setting conditions, one for each thread. Figure 3 shows an example of MSC containing such information, where lk represents the setting condition for a component. The setting condition of comp3 is a pair since it is composed by two threads.
Comp3
Comp1
op1
Comp2
Comp3
l2
l 3,l 4
l6
l 7,l 8
op2
l1 Input in_gate
(b) join communication
l5 l9
Figure 2. Some patterns the previous approach does not deal with.
can result in an inconsistency problem in the obtained QN model with respect to the original software architecture. Moreover, the actual approach does not deal with some particular architectural patterns, such as, for example, the ones in Figure 2 and it does not cover the QN parameterization phase. Finally, due to its monolithic nature, the approach makes the architectural feedbacks generation difficult. We focused on the (automatic) generation of the topology of a QN model starting from architectural specification. We did not deal with the QN parameterization that requires the knowledge of domain specific information such as system operational profile and resource workload. To this aim many efforts have been done to extend scenario notations to allow performance data specifications. Recently a UML profile [8] has been defined to allow the embedding of performance related data in the UML diagrams.
2.1. MSC features used in MSC2QN step The MSC2QN methodology uses several features of the MSC notation, that we summarize in Figure 3. First of all we use different arrow heads to model synchronous and asynchronous interactions. For this purpose we use the standard MSC notation: full arrow heads for synchronous communications, and half arrow heads for asynchronous ones. The MSC setting condition facility, instead, is used to model conditions on the state of each component, before interactions occur. A setting condition sets or describes the current system global state or the components state in order to restrict the traces that an MSC can take. Its graphical representation is an hexagon placed on one or more instance lifelines.
op1
l 10
op2
l 11, l 12 Output
op1 = Synchronous Interaction op2 = Asynchronous Interaction
out_gate
Figure 3. State Information and Interaction Types in MSC Notation.
Finally, we use MSC gates to model inputs and outputs of the software system. The software system may receive service requests from external software components and it may give back information. These external software components are called environment. In a QN, the interactions of the system with its environment are modelled by input and output flows respectively, and the QN is called open. Instead, when interactions between the software system and its environment do not exist, the corresponding QN is called closed. Our methodology can build both QN model typologies. However, to generate an open QN, the approach needs information on the interactions with the environment. Gates in the MSC notation represent the interface with the environment. Any message attached to the MSC frame constitutes a gate. If the arrow starts from the MSC frame and ends in the lifetime line of an object it will correspond to an input flow. Analogously, if the arrow starts from the lifetime line of an object and ends to the MSC frame it will correspond to an output flow. Figure 3 shows two gates, in gate and out gate, referring respectively to an input stream and to an output stream. MSCs permit to represent many aspects of the SA dynamics useful to produce QN models from SA descriptions. However some extensions to the notation must be defined. First of all, interactions definition must be extended. In general the interactions involve objects. In our approach the interactions occur between architectural components. Although the difference is mostly conceptual, in practice
C1
C2
repeat: n times
Order DB CustomerProcess
Cart DB
interactions block endrepeat: n times
Customer DB
Figure 4. MSC with a repeat block. our extension allows the designers to abstract from (possibly unknown) behavioral details. Obviously, on the other hand, we loose notation expressiveness, for example, dynamic creation of objects can not be modelled with MSC. Secondly, we require to extend the MSC notation by introducing blocks of interactions that can occur many times in order to represent iteration cycles, as shown in figure 4.
3. Migration towards UML 2.0 UML has become a standard de fact in software modelling due to its capabilities to represent different aspects of a software system and different views. Its wide diffusion is also due to the proliferation of open source tools that can be freely used and work on UML representation. We decided to migrate from MSC notation to UML because the new release of UML specification, that is UML 2.0 [9], improves the expressiveness of the UML notation providing the definition of all facilities we need for our QN model generation. In particular, it strengthens the definition of Sequence Diagrams, by introducing all the facilities summarized in subsection 2.1. Moreover, UML 2.0 defines new operators on Sequence Diagrams that can facilitate and improve our approach. For example, operators such as alternatives, parallel and loop make more concise the software behavioral description allowing the representation of several execution traces in a single Sequence Diagram. The new operator ignore, instead, allows the slicing of the software system behavior. In our context, this is useful when it is necessary to simplify the target QN model in order to allow a reasonable performance evaluation. Quite often, in fact, the software system model describes useless details that make the target analysis model too complex to be evaluated in an acceptable time. This operator is very useful since it allows the simplification of the target model at the software designers level. Another feature of UML 2.0 is the definition of the new diagram, namely the Component diagram, that we use to specify the service rates and the scheduling policies of the software components. Finally, the specification of UML profiles, such as, for example, the UML profile for Schedulability, Performance,
Catalog DB
DeliveryOrderProcess
Invoice DB
SupplierProcess
InvoiceProcess Bank DB
Figure 5. SA components of the Electronic Commerce System.
and Time [8], provides common facilities for the diagrams performance annotations. In our approach we use three types of UML diagrams: use case diagrams, sequence diagrams and component diagrams, suitably annotated by means of the UML Profile for Schedulability, Performance and Time. We remark here that, since the considered UML profile has been defined on UML 1.x, no annotations on component diagram are specified in the profile. However, we annotate the component diagram by using some stereotypes defined in the UML profile.
4. Software Architecture Performance analysis: the new approach In this section we present the new approach for Software Architecture Performance (SAP) analysis and we discuss the improvements we make. Compared to the previous version, the most relevant changes are the migration towards Unified Modelling Language (UML), the usage of the multi-chain queueing network, the QN parameterization and, finally, a re-engineering of the QN generation step to make it more compositional. In the following we present the case study we use to show the new approach (Section 4.1), the motivations of using multi-chain QN (Section 4.2), the parameterization step of the approach (Section 4.3) and the QN chains generation (Section 4.4)
4.1. The Electronic Commerce System In the electronic commerce system, there is a supplier that publishes his catalogue on the web [5]. The supplier ac-
{PApopulation=$NUSER * F_cust * P_bc, PAextDelay=('assm','mean',(5,'ms')) }
Browse Cart Scenario
BrowseCart
SD BrowseCart
«uses»
CartServer
CustomerProcess {Logged} Customer
Insert Item Scenario
InsertItem
BrowseCart {Logged} ReadStatus
In_gate
{Reading}
{Waiting} CartInfo
PlaceOrder
Place Order Scenario
Cart DB Involved
{Ready}
{Logged} CartOutput
Customer
Out_gate
Figure 6. Annotated UML Use Case Diagram.
{PAdelay= ('assm','mean',(0.5,'s'))}
Figure 8. MSC4: Browse Cart Scenario. {PAdemand= ('assm','mean',(1,'s'))}
{PAschdPolicy='FIFO'}
{ PApopulation= $NUSER * F_cust * P_ii PAextDelay='mean','asgn',20,'ms'}
NewOrder
: OrderServer
SD InsertItem
ReadStatus : DeliveryOrderProcess
: CartServer ReadStatus
{PAdemand= ('assm','mean',(1.5,'s'))}
ReadStatus
CreateNewOrder
: CustomerProcess
Customer
{PAdemand= ('assm','mean',(1,'s'))}
UpdateStatus
{PAdemand= ('assm','mean',(2,'s'))}
CustomerProcess
CartServer
{Logged} InsertItem
In_gate
BrowseCart PlaceOrder InsertItem
{Logged} UpdateStatus Cart DB
{Waiting}
{PAdelay= ('assm','mean',(0.5,'s'))}
Ack
{Logged}
{Writing} Involved {Ready}
ref
InfoRequest {PAschdPolicy='FIFO'}
: CustomerServer
CartOutput
UpdateStatus
{PAdemand= ('assm','mean',(3,'s'))}
BrowseCart
Out_gate
Figure 9. MSC6: Insert Item Scenario. Figure 7. Component diagram of the considered portion of the e-commerce system.
cepts customer orders and delivers the ordered items maintaining all the relevant data. He needs to maintain information on data, on the catalogue and on the orders purchased by his customers. Each registered customer has a cart where he can insert or delete items. The customer can order only if the cart is not empty. The system also allows the customer to monitor the order status and to confirm the delivery in order to permit the payment. In Figure 5 we show the Software Architecture of the system, where we identify some databases (Customer DB, Cart DB, Order DB,etc.) and four components (CustomerProcess, SupplierProcess, etc.). Each customer has associated a (individual) CustomerProcess and there is a server for each involved database that permits to communicate with it. The interactions with these servers are asynchronous.
For the sake of space, we consider a simplified version of this system. We focus on the customer view by considering only the software system services reported in Figure 6. In the use case diagrams the association between the use case and the sequence diagram describing the corresponding system behavior is expressed by means of notes. In Figure 7 we present the UML 2.0 Component Diagram for the portion of the e-commerce system we consider. This diagram highlights the software components and their required and provided interfaces. The provided interfaces are represented by a circle whereas the required ones are represented by a semicircle. In general, an interface is composed by a set of operations provided or required by a software component. Here, to simplify the presentation of the parameterizazion phase, we assume that an interface is composed of a single operation from with the interface derives the name. The Component diagram is annotated according to the UML profile in order to consider performance aspects of the software components and their interfaces.
From Figure 8 to Figure 10 we report the scenarios we consider to derive the QN model of the identified subsystem. The scenarios are expressed by means of the Sequence Diagrams of UML 2.0, annotated by the stereotypes defined in UML profile for Schedulabilty, Performance and Time [8].
{ PApopulation= $NUSER * F_cust * P_po PAextDelay=(assm,'mean',(10,'ms'))} SD PlaceOrder CustomerProcess
CartServer
DeliveryOrderProcess OrderServer
CustomerServer
{Logged} Customer PlaceOrderReq In_gate
{Logged} ReadStatus {Waiting}
4.2. Motivations of using multi-chains Queuing Network
Cart DB {Reading} Involved
alt {PAprob=1- $Perror}
[cart not empty] CartInfo {Ready}
{Logged}
A QN model is defined by a set of service centers, a topology representing how the service centers are connected, and a workload intensity modelling the behavior of the sources generating the requests (QN customers). The definition of the service centers, in term of their service rates and the scheduling policies of their waiting queues, and the workload intensity, that is the definition of the incoming traffic, is generally called parameterization of the QN model. In our new approach, a QN model represents the software architecture we want to analysis and a service center in the QN model corresponds to an architectural software component. Since in general, the software system provides several services to its users, as in our case the use case diagram in Figure 6 shows, the requests entering the software system are of several types. Also the customers entering to the QN model are of different types. Moreover, the software system has different behaviors according to the different types of requests, as showed by the Sequence diagrams in Figures 8, 9 and 10. This implies that also the QN customer types representing the users requests should have different behavior in the QN model. The behavior of a customer is defined by the chain of services it requires to the service centers in the QN. Informally, a chain in a queueing network model describes how a request type is served by passing through the QN service centers. Hence, it defines the routing of the request (QN customer) between the service centers and the time it spends in them. Since different user requests (QN customers) might require different works to a software component (QN service center), the software component should provide several services having different complexity. For what concerns customer types definition, the use case diagram gives information on the types of QN customer entering the system. The sequence diagrams are used to generate the QN topology and the chains definition. The Sequence Diagram describes the behavior of the associated type of QN customers in the software system. Since there is a mapping between the sequence diagram and type of QN customers, the Sequence diagram gives information on the workload intensity of the class of customer it describes. The use case diagram in Figure 6 reports the association between a use case and the set of scenarios describing
{Waiting} {Logged}
ReadInfo {Reading}
CustomeInfo
Customer DB Involved createNewOrder NewOrder
{Waiting}
{PAdelay= ('assm','mean',(0.5,'s'))}
OrderInfo
{Writing} Order DB Involved
OrderInfo
OrderInfo Out_gate
par
UpdateStatus(Empty) {Waiting}
Cart DB {Writing} Involved
{PAdemand= ('assm','mean',(0.2,'s'))}
[cart empty] {PAprob= $Perror}
{Logged}
{empty}
EmptyCart EmptyCart
{Logged}
Out_gate
{PAdelay= ('assm','mean',(0.5,'s'))}
Figure 10. Place order scenario. it. The use case diagram gives us information on the types of services (chains in the QN terminology) provided by the software system. Finally the annotated component diagram provides information on the parameterization of the service centers of the QN, such as the type of the service center (e.g. servers with waiting queue or a delay), the service rates of the services they provide and the scheduling policies they use to extract jobs from their waiting queues.
4.3. QN parameterization The QN parameterization is a fundamental and very complex task in performance analysis. In our methodology we assume that the software designer has suitably labelled the component and sequence diagrams with the information useful to carry on the parameterization. Our QN parameterization step, in fact, does not deal with how collect data to parameterize, whereas, it allows the QN parameterization from opportunely annotations in the UML component and sequence diagrams. The parameterization consists of: the definition of the workload intensity for each QN customer class, the identification of the service demand of each service provided by
a service center and the specification of the scheduling policies. According to the UML profile, the workload intensity provided by a given customer class, is extracted from the or stereotypes that are at the beginning of the corresponding sequence diagram. The former is used when the customer type provides an open load, whereas the latter is used in case of closed load. For example, in Figure 8 the stereotype defines the workload intensity for the customer class (or system use case) browseCart. In this case, the workload is defined by the number of users indicated by the PApopulation tag value and the time needed to generate a request expressed by the tag value PAextDelay (technically this workload is called terminal workload). It is worthwhile to observe that the number of users (PApopulation tag value) is equal to the product of the number of registered e-commerce users ($NUSER), the frequency of the e-commerce customers entering the system (F cust value), the probability the customer requires the browseCart service (P bc value). This technique follows the one introduced by Cortellessa et al. in [3]. The approach defines a QN service center for each component in the component diagram. Since the software component should provide more interfaces (or services), the corresponding service center may have more classes of service, one for each interface in the diagram. The service rate of the identified service class (or job class) is extracted from the tag value of the stereotype associated to the component interface in the component diagram. We here recall that, for the sake of presentation, we assume that an interface contains just an operation from which it inherits the name. From the component diagram, also information about the scheduling policy of the waiting queue of the components can be extracted: the components are stereotyped. The stereotype models active resources. The only annotation we consider for the components is PAschdPolicy tag value that indicates the scheduling policy. See Figure 7 for an example. Some times also internal actions of components are significant for performance analysis. We use the stereotype to give information on the time spent doing internal actions. The stereotype is associated to the component lifeline of the sequence diagram at the point in which the internal work is done. For example, if we consider the sequence diagram in Figure 8, the stereotype indicates the time needed to prepare the web page containing the information about the cart status.
4.4. Chains generation: a compositional approach In this section we present the technique to generate a multi-chain QN topology. As we already said, the approach introduces a chain for each use case of the system. The use cases are considered separately, one by one. All the sequence diagrams describing the software system behavior of an use case are considered. The output of a chain generation is a sub-QN model that describes the behavior of the QN customer type. It is defined by the services required to the service centers and the stochastic routing of the customers among the service centers. The approach is compositional. Statically, we define a library of architectural patterns (sequence diagram fragment) and we relate them to QN patterns. Thanks to the new operators for the sequence diagrams introduced by UML 2.0, it is easy to identify and to model the architectural patterns of interest. In fact, it is possible to relate a QN pattern to each sequence diagram operator. Then, according to the sequence diagrams describing the chain definition, the approach suitably combines the involved QN patterns by instantiating them to the particular situation. The compositional feature of the approach helps in the architectural feedbacks derivation. The separation of system behaviors and the identification of patterns facilitate the identification of the software system behavior parts that result in performance problems. Moreover, the use of the component diagram annotated according to the UML profile for Schedulability, Performance and Time allows the identification of overloaded components. The approach models every software components interaction (arrow in the sequence diagram) according to the previous approach. It associates a connection in the QN topology from the service center corresponding the component sender to the one corresponding the receiver. The service center of the receiver has an infinite (or finite with a given capacity) waiting queue if the interaction is asynchronous, or a waiting queue with zero capacity whenever the interaction is synchronous. As the previous approach does, the new version uses the gate facilities to identify the environment and the incoming and outgoing system traffic. A gate in a sequence diagram is identified a the point crossed by an arrow located on the most external frame containing the scenario description. The gate is an output gate if the interaction is an outgoing arrow from the frame. Whereas it is an input gate if the interaction is entering into the frame. Finally, also the information on the components state is used in the same way the old approach does. In a sequence diagram, such information is annotated by means of invariants placed on the component lifeline and identified by curly brackets. In the following we introduce the QN pattern for three
Multi-chain QN topology for the case study In Figures 11 and 12 we show the chains of the browseCart and placeOrder customer classes respectively. A chain does not necessarily involve all service centers. If we consider the chain
ReadInfo
UpdateStatus
1-P error
8
CustomerProcess
8
8
UpdateStatus
...
ReadStatus
BrowseCart
CustomerServer
Perror
CartServer
...
8
0 ReadStatus
ReadStatus
0
8
InsertItem
createNewOrder
NewOrder
response
OrderServer
0 PlaceOrder
DeliveryOrderProcess
8
Customers
...
Internal Actions
sink
8
Figure 11. Chain in the QN model corresponding to PlaceOrder Scenario.
8
UpdateStatus
CustomerProcess
ReadInfo
UpdateStatus
CustomerServer
...
ReadStatus
BrowseCart ...
CartServer
InsertItem ...
8
0
ReadStatus
ReadStatus
0
8
Customers
8
QN patterns for Sequence operators The Reference operator allows the definition of a reference to a behavior already defined by another sequence diagram. In Figure 9 a reference operator, identified by the ref keyword, is used to indicate that the behavior of the insertItem includes the behavior described in browseCart sequence diagram. The Reference operator models a change of chain in a multi-chain QN. This means that the chain of the insertItem use case, has a sub-chain corresponding to the one modelling the behavior of the browseCart customer type. ”The Alternative operator designates that the interaction fragment it represents models a choice of the behavior. At most one of the operands will executes. The operand that executes must have an implicit or explicit guard expression that evaluates to true at this point of interaction” (quoted from [9]). In Figure 10 an alternative operator, identified by the alt keyword, has two alternative behaviors, one with not empty cart guard expression and the other with empty cart guard expression. The Alternative operator models a branching in a QN. The alternative behaviors in the operator are the possible routings of the customers among the services of the service centers. The routing probabilities among the alternatives are annotated in the sequence diagram. As an example, let us consider again Figure 10. The alt operator has two alternatives one with 1-$Perror probability and the other with $Perror probability. We remark here that the sum of all option probabilities must be 1. By considering the Figure 11, the alternative operator defines the branching point highlighted by the shaded area at the top of the Figure. ”The Parallel operator designates that the interaction fragment it represents models a parallel merge between the behaviors of the operands. The event occurrences of the different operands can be interleaved in any way as long as the ordering imposed by each operand as such is preserved” (quoted from [9]). In Figure 10 a parallel operator, identified by par, defines two parallel behaviors to be merged. The parallel operator models a fork in a QN. As an example, let us consider Figure 11, the parallel operator defines the QN fork highlighted by the shaded area at the bottom of the Figure.
8
sink
8
sequence operator, namely the Alternative operators, the Parallel operator and the Reference operator. Obviously, there exists other sequence operators, but, for the sake of presentation, we deal with the operators we consider more significant. We also show how instantiate the presented patterns to model the chains of the case study.
createNewOrder
NewOrder
response
OrderServer
0 PlaceOrder
DeliveryOrderProcess
Internal Actions
Figure 12. Chain in the QN model corresponding to BrowseCart Scenario.
for the browseCart (see Figure 12), it involves the CartServer and the CustomerProcess service centers only. In Figure 13, instead, we present the QN model topology derived by merging all the defined chain topologies. Let us observe that all the service centers provide a service type for each interface of the corresponding component in the component diagram. Moreover, some of them have a service type to model the additional internal work the components do to accomplish a request. An e-commerce customer is modelled by a set of traffic sources, one for each QN customer type. The CustomerProcess component, instead, is modelled by a set of delays,
8
sink
ReadInfo
UpdateStatus
CustomerServer
8
CustomerProcess
8
8
UpdateStatus
...
ReadStatus
BrowseCart ...
CartServer
...
ReadStatus
ReadStatus
0
8
InsertItem
8
0
createNewOrder
NewOrder
response
OrderServer
0 PlaceOrder
DeliveryOrderProcess
8
Customers
Internal Actions
Figure 13. Multi-chain queueing network.
one for each request type and one modelling the internal actions. This choice is conform to the annotations in the component diagram where it is specified that the provided interfaces of the CustomerProcess are delays. We remark here that this modelling respects the architectural constraint concerning the presence of a customerProcess instance for each e-commerce customer. Finally, in the Figure 13, the shaded area indicates the change of chain defined by the reference operator in the insertItem scenario discussed before.
5. Further considerations In this paper we presented the QN model definition phase of our performance analysis process applied to SA descriptions. Differently to the previous version, the step of the QN topology generation presents characteristics of compositionality. The algorithm that generates the QN model, accesses to a library that associates QN patterns to architectural patterns. The target QN model is obtained by composing the identified QN patters suitably instantiated. The new approach, due to the use of the UML profile, requires some knowledge on performance analysis, and on how to determine the additional information needed to carry on the evaluation of the generated QN model. This is not trivial. At the moment, do not exist automatic approaches that assist in the whole process of performance analysis. To this respect a relevant effort is still required to software designers attending in the process itself. However, it is not common to find specific performance skills in software designers and, due to the high level of abstraction of the software architecture description, the additional information to parameterize the QN model is not easy to determine.
The assumption of using an ideal hardware architecture should help to overcome these drawbacks. As we already discussed in [1], in our framework we consider QN performance models of SA to evaluate and to compare SA specifications. The goal is to derive performance results that can be interpreted in terms of SA design artifacts. Therefore, unlike other approaches that build QN models as a combination of the hardware platform with software requirements, we consider QN models as performance models at the level of the SA. The definition of a QN model at the SA level cannot be completely specified because of the high level of abstraction. If some parameters or characteristics of the QN are not specified, it is then up to the designer their definition. The model parameter instantiations correspond to potential implementation scenarios, and the performance evaluation results can provide useful insights on how to carry on the development process. Due to the high level of abstraction, we do not model software resources other than the software components presented in the component diagram. This means that buffers are considered if they are explicitly modelled as software components. For what concerns other software artifacts, such as semaphores or locks, in general they are not explicitly modelled in an SA. They contribute in the specification of the communication protocol used by the software component to interact each other, hence, in a SA specification, they are embedded in the connectors. Of course, the methodology deals with all kind of software systems that: • can be modelled by means of UML facilities we use to model the software architecture; • have characteristics that can be modelled by means of a QN model.
6. Conclusions In this paper we have presented the new version of our approach to software system performance analysis. The approach allows the automatic generation of a performance model based on QN models. This new version addresses the problems, discovered in the previous version, with respect to the multiple services software systems, by generating a multi-chain QN model. Differently to the previous version, the new approach uses UML 2.0 as notation to describe the software system architecture. The migration has been driven by two factors: the more expressiveness of UML 2.0 diagrams that allows us the definition of a compositional approach, and the presence of an UML profile that defines suitable capabilities to annotate the diagrams with information on performance aspects. The new version also deals with the parameterization phase of performance models by assuming that the software
designers suitably label the used UML diagrams with useful information. As final remarks, we want to observe that, even if the new approach allows the generation of a QN model closer to the software architecture, the obtained performance model is more complex. This complexity implies that we have to use more complex techniques to evaluate the new QN model. These techniques, quite often, are not analytic as instead they were in the previous approach. In particular, whenever we have a parallel operator in a sequence diagram, we have a fork in the QN model. A QN with forks (namely Extended QN) can be evaluated only through simulation techniques.
References [1] F. Andolfi, F. Aquilani, S. Balsamo, and P. Inverardi. Deriving performance models of software architectures from message sequence charts. In Proceedings of the Second International Workshop on Software and Performance (WOSP00), September 2000. [2] S. Balsamo, A. DiMarco, P. Inverardi, and M. Simeoni. Model-based performance prediction in software development: A survey. Transactions of Software Enginnering, To Appear. [3] V. Cortellessa and R. Mirandola. PRIMA-UML: a performance validation incremental methodology on early uml diagrams. Science of Computer Programming. [4] A. DiMarco and P. Inverardi. Starting from message sequence chart for software architecture early performance analysis. In 2nd International Workshop on Scenarios and State Machines: Models, Algorithms, and Tools, Portland, Oregon, USA. http://www.di.univaq.it/di/pub.php?username=adimarco, May 2003. [5] H. Gomaa. Designing Concurrent, Distributed, and Real-Time Applications with UML. Addison-Wesley, 2000. [6] E. Lazowska, J. Kahorjan, G. S. Graham, and K. C. Sevcik. Quantitative System Performance: Computer System Analysis Using Queueing Network Models. Prentice-Hall, Inc., Englewood Cliffs, 1994. [7] ITU - Telecommunication Standardization Sector. Message Sequence Charts, ITU-T Recommentation Z.120(11/99). 1999. [8] Object Management Group. UML Profile, for Schedulability, Performance, and Time. OMG document ptc/200203-02, http://www.omg.org/cgi-bin/doc?ptc/2002-03-02. [9] Object Management Group. Unified Modeling Language 2.0. http://www.omg.org/uml/, 2003.
