UML Design and Software Performance Modeling

UML Design and Software Performance Modeling? Salvatore Distefano, Daniele Paci, Antonio Puliafito, and Marco Scarpa Dipartimento di Matematica, Universit` a di Messina, 98166 Messina, Italy {salvatdi,dpaci,apulia,mscarpa}@ingegneria.unime.it

Abstract. The importance of integrating performance evaluation into the software development process from the very early stages has been widely recognized during last years. The goal is to individuate performance behavior before the system is actually implemented reducing costs and time, and permitting to compare different design choices. The main drawback of this approach is the time and the background knowledge required to transform the specifications of a software system into a performance model. In this paper, we present a model for setting performance requirements collected from a UML [9] project. This represents the first step towards an automatic process for computing performance measures starting from an UML specified model. The approach proposed is based on open and well-known standards: UML for the software modeling, the Profile for Schedulability, Performance, and Time Specification for the performance annotations and XMI for the interchange of metadata.

1

Introduction

Performance is an important but often overlooked aspect of the software design. Indeed, the consideration on performance issues is in many cases left until late in the Software Development Process (SDP), when problems have already manifested themselves at system test or actually within the deployed system. Nevertheless, the importance of integrating performance evaluation into the whole SDP from the early stages has been recognized during last years in the Software Engineering community. This kind of approach realizes the so called Software Performance Engineering (SPE) [14] which allows to build performances into systems rather than add them later. The birth of UML (Unified Modeling Language) [9] and its sudden spread on wide scale from 1996, favored the developing of SPE. An increasing number of researchers, encouraged by the standardization of this modeling language, began to be interested in such topic: King and Pooley in [11] evidenced as UML, considering both static and dynamic aspects of a system, lends particularly to the analysis of the performances, when annotations for timing and branching probabilities are added. ?

This work is supported by Italian national project “FIRB - Performance Evaluation of Complex System: Techniques, Methodologies and Tools”.

C. Aykanat et al. (Eds.): ISCIS 2004, LNCS 3280, pp. 564–573, 2004. c Springer-Verlag Berlin Heidelberg 2004

UML Design and Software Performance Modeling

565

Since UML has been conceived as a general purpose modeling language, it has equipped with an open ended semantic, that can be extended and merged with various application domains. These extensions can be obtained through the UML profiles, a specialized subset of the UML that permits to extend the model using the lightweight extension mechanisms (stereotypes, tagged values and constraints). In particular the UML Profile for Schedulability, Performance and Time Specification (UML-RT) [8], is an OMG standard for the representation of performances and real-time properties, adopted here for the annotations of performance requirements in the UML model. Insertion of performance requirements into UML models convinced many researchers to develop algorithms for automatic generation of Performance Models starting from UML diagrams, like in [2,7], where the authors formalize a structured methodology which sets a relation between an UML model defined through a Use Case Diagram (UC), a set of Sequence Diagrams (SDs) and State Chart Diagrams (SCs), with Labeled General Stochastic PNs (LGSPNs). These are subsequently linked together obtaining the PN describing the whole system. Similarly, the synthesis of PN from UML diagrams is treated in [12]. Even in this case, SCs are used for the specification of the dynamic behaviors of an object, using Collaboration Diagrams (CoDs) to express the interaction between them. Other approaches use target performance models different from PNs like Generalized Semi-Markov Process (GSMP) [6], Stochastic Reward Nets (SRN) [5], Queuing Network Models (QNM) [16], Layered Queueing Networks (LQN) [10]. In these cases, generation of performance model is obtained from an UML model based on SCs, ADs, or Deployment Diagram (DD). A different approach has been presented in [1], where a simulation model is developed from a hierarchic UML model represented by UCs, DDs and ADs. This approach is highly integrated with the OMG’s performance profile, indeed the performance model is based on the one defined in [8] (see Figure 1). The work presented in [3] is particularly interesting: it defines an Intermediate Model (IM) as an hypergraph. Two steps permit to realize the mapping: in the first step, remarkable data on dependability are extracted projecting the UML entities into IM nodes and structural UML relations into IM arcs; then the IM is mapped to a PN model examining the hypergraph and generating a set of subnets for each IM element. In order to realize the integration between SDP and performance analysis, we also introduce an intermediate model, called Performance Context Model (PCM). The idea of an intermediate model offers the advantage of being independent both from the particular UML representation and from the adopted analysis formalism. The rest of this paper is organized as follows. Section 2 introduces the PCM. Section 3 presents the rules for mapping the UML model towards the PCM. Section 4 reports a simple case study. Conclusions and ideas concerning future work close the paper.

566

2

Salvatore Distefano et al.

The Performance Context Model

Most of the proposals available in literature provide a limited integration of the performance aspects into UML models. In this paper, we intend to pursue such goal focusing on the Performance Analysis Domain Model (PAD), as defined in the UML-RT [8] and depicted in Figure 1. 0..*

PerformanceContext

1..*

1..*

1..*

Workload +responseTime

0..*

PScenario

1..*

0..*

+hostExcecutionDemand

+priority

+resource

+respondeTime

PResource +utilization +schedulingPolicy +throughput

0..* +root

ClosedWorkload +population

OpenWorkload

1..*

PStep

+occurencePattern

+externalDelay

+successor

0..1

+host

PProcessingResource

PPassiveResource

+probability

+processingRate

+waitingTime

+repetition

+cintextSwitchTime

+responseTime

+delay

+priorityRange

+capacity

+operations

+isPreemptible

+accessTime

+interval +executionTime

0..* 0..* +predecessor

Fig. 1. UML-RT performances model The PAD is constituted of many entities: a PerformanceContext specifies one or more Scenarios that are used to explore various dynamic situations involving a specific set of resources. The class PScenarios is used for modeling a response path whose end points are externally visible. Each Scenario is executed by a job or user class with an applied load intensity, represented by a (Open or Closed) Workload. The Steps are the elements of the Scenario, joined in a sequence of predecessor-successor relationship which may include forks, joins and loops. Resources are modeled as servers. Active Resources are the usual servers in performance models and have service time. Passive Resources are acquired and released and have holding time. Like suggested from OMG in [8], we refined the PAD into a Performance Context Model (PCM), to take into account the properties of a generic performance model. The PCM we defined is depicted in Figure 2, and we propose to use it as an intermediate model between an UML project and the final performance model, whatever formalism is used to analyze the latter. The structure of PCM (see Figure 2) is similar to that depicted in Figure 1, where the abstract classes have been specialized to contain performance informations. - The PCM implements the generic concept of step, formally described from the abstract class VertexStep, by introducing the classes DeciderStep, ForkStep, MergerStep, JoinStep, and TimedStep.

UML Design and Software Performance Modeling PerformanceContext

+workloads

+scenarios

1..*

Workload +frequenceOfUsage

1..*

+probability +loadLinks

1..*

+population

OpenWorkload +occurencePattern

+externalDelay

1..* 1..*

+resources +resources

Resource

-executionProbability

+utilization

+targetScenario -responseTime

+root

ClosedWorkload

0..* 0..*

Scenario

LoadLink

567

+vertexSteps 1..*

+successors

VertexStep

2..*

+successor 0..1

ProcessingResource

+waitingTime +responseTime

+targetStep

MultiSuccessorsStep

PassiveResource

+processingRate +schedulingPolicy 0..1 +host

+capacity +accessTime

SingleSuccessorStep

0..* +steps

ForkStep

DeciderStep

JoinStep

TimedStep

MergerStep

+repetition +delay 2..* +successors

+hostExecutionDemand ConditionalLink +probability

+interval -responseTime

Fig. 2. The Performance Context Model - The UML-RT associates the stereotype PAcontext to AD, restricting to use only one Scenario into a PerformanceContext. The PCM overrides this limit associating the PAcontext to the overall UML model. - The UML-RT allies one Workload to each Scenario. Instead the PCM admits the definition of Workloads in the UCs, and it is able to compose them in different way and to link more Scenarios to the same Workload. In the following, we give a more detailed description of the classes included in the PCM with their roles. 2.1

Performance Context

The role played from this class is to group all the elements necessary to describe the software from the performance analysis point of view. 2.2

Scenario

The role of this class is the same as in the PDA; the only difference is the attribute executionProbability used to model how much a Scenario is run. It depends on frequencyOfUsage of Workloads and probability of LoadLink. Each Scenario represents some kind of computation, so that it is constituted of a sequence of elementary steps (the class VertexStep), where the first is located by the association root. We defined two kind of elementary steps to be able to model every kind of computation: MultiSuccessorsStep for modeling branching in computation (eventually parallel) and SingleSuccessorStep for modeling sequential computation. The ForkStep is used to generate parallel threads. The DeciderStep is useful for representing a choice among different threads like the if-then construct. The

568


choice is probabilistically done by ConditionalLink that pairs a DeciderStep with a VertexStep. The JoinStep is used as synchronization point of concurrent threads, and it has a single successor; the MergerStep has a single successor too, but it is executed when just one of the concurrent threads completes. The ForkStep, DeciderStep, JoinStep, and MergerStep all express logical conditions on the software evolution so that no time delay is associated with them. The time is taken into account by the TimedStep associated to a resource (see section 2.3). 2.3

Resource

The abstract class Resource represents some resource used to produce computation. It can be either a real Processing Resources or a Passive Resources. The former models a computation units offering a service according to a fixed policy (e.g, a CPU, a communication network); the latter models the resources protected by an access mechanism. It may represent either a physical device or a logical protected-access entity. The common attribute utilization returns a measure of the time during which the resource is active, and it must be computed by the performance model. 2.4

Workload

The abstract class Workload models how the requests of computation are submitted. When a finite population of user is supposed, the class ClosedWorkload has to be used by specifying the number of users (population) and their interarrival time (externalDelay); otherwise OpenWorkload is appropriate by specifying the interarrival time distribution only. The class LoadLink is used to create a correspondence between Workloads and Scenarios. Since a Workload could be associated to more Scenarios each one is probabilistic selected by means of the attribute probability. 2.5

How to Use the PCM

Following the specifications of UML-RT, the software analyst will be able to use DDs for specifying the resources and UC for describing the workloads; the scenarios described in the UCs will be detailed by using SDs, ADs, and CoDs with the only restriction that each scenario can be specified by means of a single kind of diagram. According to this kind of project specification two levels of description are located (see Figure 3): the Specification Level including all the DDs and UCs, and the Base Level containing the SDs, ADs, and CoDs. Since all the scenarios are specified from the diagrams contained into the Base Level, these are used to translate performance specifications into a PCM, then employed for defining the final performance model. This approach differs from those presented up to now, where a particular mapping for each kind of UML diagram is required towards the performance model.


569

The overall process, is synthesized into two steps: 1) UML Source Model → PCM , 2) PCM → Performance Model During step 1) all the information about the software project will be specified in a UML model in a formal way, including the performance annotations; a solvable performance model will be produced by step 2). Specification Level

Use Case Diagram (UC)

Scenario 1

Scenario 2

...

Deployment Diagram (DD) Scenario p

Base Level SD 1

SD 2

...

SD n

AD 1.1

AD 1

AD 2

AD 1.2

...

AD m

CoD 1

CoD 2

...

CoD k

AD m.1

AD 1.2.1

...

Fig. 3. Schematic view of UMLBLM (UML Bi-Level Methodology)

3

Mapping from UML to PCM

The previous section describes the classes that constitute the PCM and the relations existing among them. What we want now to establish is the correspondence between the UML domain and these classes, specifying indirectly the semantics of the subset of UML elements through which it is possible to model a PVM Software Analysis. Consider the whole UML model represented by the Performance Context: Model PCM Performance Context Stp

PAContext

Action State, Message, Stimulus, SubactivityState of AD, SD or CoD are associated to a PCM TimedStep, implemented by a PAstep stereotype (Stp), as described in the following table: Action State, Message, Stimulus, SubactivityState PCM TimedStep Stp

PAstep

Tag

Tag Name PAdemand PArep PAinterval PAdelay PArespTime PAexecHost

↔ ↔ ↔ ↔ ↔ ↔

PCM Attribute TimedStep::hostExecutionDemand TimedStep::repetition TimedStep::interval TimedStep::delay TimedStep::responseTime TimedStep::host

Type PAperfValue Integer PAperfValue PAperfValue PAperfValue String

Mult [0..*] [0..1] [0..1] [0..*] [0..1] [0..1]

570


The lower part of this table shows the set of tags related to the stereotype, which permits to specify the associated PCM attributes, the type of tag and its multiplicity (see [8] for details). PCM MergerStep and DeciderStep represent a Branch Pseudostate UML, according to the constraints specified in tables: Branch Pseudostate PCM element MergerStep, DeciderStep Constraints

MergerStep: Input Transition has to be greater than one and the output Transition has to be unique. DeciderStep: Input Transition has to be unique and the output Transition has to be greater than one. The outgoing Transition is a Conditional Links.

Strictly related to the previous tables is the following one regarding the Conditional Link: Transition PCM element ConditionalLink Tag Name PCM Attribute PAprob ↔ ConditionalLink::probability

Tag Constraints

Type Real

Mult. [0..1]

The Transition has to be an outgoing one from a Branch pseudostate representing a DeciderStep. The sum of all PAprob outgoing from the same DeciderStep has to be equal to one.

In the same manner the following tables describe the rules which allow to execute the mapping from the UML domain toward the remaining PCM elements: Join Pseudostate PCM element JoinStep

Fork Pseudostate PCM element ForkStep

Node PCM Processing Resource Stp

PAhost

Tag

Tag Name PCM Attribute PAutilization ↔ Resource::utilization PArate ↔ ProcessingResource::processingRate PAschdPolicy ↔ ProcessingResource::schedulingPolicy

Type Real Real Enumeration

Mult. [0..1] [0..1] [0..1]


571

Actor PCM Closed and Open Workload Stp

PAclosedLoad, PAopenLoad Tag Name PCM Attribute PAfreqOfUsage ↔ Workload::frequencyOfUsage

Tag

PApopulation ↔ ClosedWorkload::population PAextDelay ↔ ClosedWorkload::externalDelay

Type Real

Mult. [0..1]

Integer PAperfValue

[0..1] [0..1]

PAoccurrence ↔ OpenWorkload::occurencePattern RTarrivalPattern [0..1] Association PCM element LoadLink Tag Constraints

4

Tag Name PCM Attribute PAprob ↔ LoadLink::probability

Type Real

Mult. [0..1]

The Association has to be an outgoing one from an Actor representing a Workload. The sum of all PAprobs outgoing from the same Workload have to be equal to one.

A Case Study: Web Video Application

To better clarify the proposed approach, in this section we present a case study delivered from the example reported in the OMG specifics: the video Web application described in [1]. It regards a video streaming application on the Web, where a user selects a movie by connecting to the Web server. The DD of Figure 4 (b) represents the resources dislocation. The performance parameters are included into the diagrams by UML-RT annotations. The UC (see Figure 4 (a)) shows the workload applied to the system, characterized by a fixed number of users and an exponentially distributed interarrival time. The scenario contained in the UC is detailed in the AD of Figure 4 (c), where a client requests a video to a remote Web server; the Web server selects the opportune video server that initializes the client’s video player and starts the video streaming. At the same time, the Web server sends the client a confirmation message. Once the streaming is over the video server closes the application. From this UML model, by applying the rules described in section 3, it is possible to obtain the PCM of Figure 5.

5

Conclusions and Future Work

In this paper, we proposed a methodology that splits translation from UML to performances domains into two phases, interposing an intermediate step through a Performance Context Model (PCM). Such translation represents the strength of the proposed methodology. The proposed approach represents the starting point of an intense research work based on SPE and UML design. We have already started the implementation of a submapping from PCM toward a Petri Net model. This also includes

572

Salvatore Distefano et al. PAexecHost = ' ClientWorkstation'

Select Service

PAdemand = (' assm' ,' dist' ,(' exponential' ,10))

Handle Selection

PAexecHost = ' WebServerNode' PAdemand = (' est' ,' dist' ,2.0)

Request Video

User fixed Confirm

Initiate Playout

PAexecHost = ' VideoServerNode' PAdemand = (' assm' ,' dist' ,(' exponential' ,5))

PApopulation = 10 PAexecHost = ' ClientWorkstation'

PAextDelay = ('assm','dist','exponential',50)

PAdemand = (' msr' ,' dist' ,(' exponential' ,0.5))

Initialize Player

(a)

PAexecHost = ' ClientWorkstation' PAdemand = (' msr' ,' dist' ,(0.5))

Send Video

PArate = 1.0

PArate = 2.0

PArate = 2.0

PAschdPolicy = ' FIFO'



PAutilization = $util1



PAexecHost = ' Internet' PAdemand = (' assm' ,' dist' ,(' exponential' ,0.5)) PArep = 100

SendTerminate

PAexecHost = ' VideoServerNode' PAdemand = (' msr' ,' dist' ,(0.5))

ClientWorkstation

WebServerNode

VideoServerNode

TerminatePlayer

PAexecHost = ' ClientWorkstation' PAdemand = (' assm' ,' dist' ,1.0)

Internet

PArate = 1.0 PAschdPolicy = ' PS'

(c)

(b)

Fig. 4. (a) Use Case Diagram, (b) Deployment Diagram, and (c) Activity Diagram describing the Web-based video application

TIMED STEP Initialize Playout CLOSED W ORKLOAD

TIMED STEP Select Service

TIMED STEP Handle Selection

TIMED STEP Initialize Player

TIMED STEP Send Video

TIMED STEP Send Terminate

TIMED STEP Terminate Player

JOIN STEP

FORK STEP TIMED STEP Confirm

PROCESSING RESOURCE Client W orkstation

PROCESSING RESOURCE W ebServer Node

PROCESSING RESOURCE VideoServer Node

PROCESSING RESOURCE Internet

Fig. 5. PCM rappresenting the Web-based video application

the construction of a software performance design toolkit based on the WebSPN Petri Nets tool [4,13] and the UML CASE tool ArgoUML [15], through a specific plug-in. Another development concerns the formalization of a mapping among the behavioral diagrams used in UML-RT: SDs, ADs and CoD.


573

References 1. Balsamo, S., Marzolla, M.: A Simulation-Based Approach to Software Performance Modeling. In: European Software Engineering Conference and ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE 2003), Helsinki, Finland. ACM SIGSOFT Software Engineering Notes 28 (2003) 363–366 2. Bernardi, S.: Building Stochastic Petri Net Models for the Verification of Complex Software Systems. Ph.D. thesis, Universit´ a di Torino, Italy. (2003) 3. Bondavalli, A., Majzik, I., Mura, I.: Automatic Dependability Analysis for Supporting Design Decisions in UML. In: Proceedings of the 4th IEEE International Symposium on High-Assurance Systems Engineering, Washington, D.C. IEEE (1999) 64–71 4. Horv´ ath, A., Puliafito, A., Scarpa, M., Telek, M., Tomarchio, O.: Design and Evaluation of a Web-Based Non-Markovian Stochastic Petri Net Tool. In: Proceedings of the 13th International Symposium on Computer and Information Sciences (ISCIS’98), Antalya, Turkey. IOS/Ohmsha (1998) 101–109 5. Huszerl, G., Mjzik, I., Pataricza, A., Kosmidis, K., Chin, M.D.: Quantitative Analysis of UML Statechart Models of Dependable Systems. The Computer Journal 45 (2002) 260–277 6. Lindemann, C., Th¨ ummler, A., Klemm, A., Lohmann, M., Waldhorst, O.P.: Performance Analysis of Time-Enhanced UML Diagrams Based on Stochastic Processes. In: Proceedings of the 3rd International Workshop on Software and Performance (WOSP 2002), Rome, Italy. ACM (2002) 25–34 7. Merseguer, J.: Software Performance Engineering Based on UML and Petri Nets. PhD thesis, University of Zaragoza, Spain. (2003) 8. Object Management Group. UML Profile for Schedulability, Performance, and Time Specification. OMG, Final Adopted Specification edn. (2002) 9. Object Management Group. UML Specification v. 1.5. OMG, 1.5 edn. (2003) 10. Petriu, D.C., Shen, H.: Applying the UML Performance Profile: Graph GrammarBased Derivation of LQN Models from UML Specifications. In: Proceedings of the 12th International Conference on Computer Performance Evaluation, Modelling Techniques and Tools (TOOLS 2002), London, UK. Lecture Notes in Computer Science, Vol. 2324. Springer (2002) 159–177 11. Pooley, R., King, P.J.B.: The Unified Modeling Language and Performance Engineering. In: Proceedings of IEE - Software, Vol. 146. (1999) 2–10 12. Saldhana, J.A., Shatz, S.M., Hu, Z.: Formalization of Object Behavior and Interactions from UML Models. International Journal of Software Engineering and Knowledge Engineering 11 (2001) 643–673 13. Scarpa, M., Distefano, S., Puliafito, A.: A Parallel Approach for the Solution of Non-Markovian Petri Nets. In: Dongarra, J., Laforenza, D., Orlando, S. (eds.): Proceedings of the 10th European PVM/MPI Users’ Group Meeting (Euro PVM/MPI 2003), Venice, Italy. Lecture Notes in Computer Science, Vol. 2840. Springer (2003) 196–203 14. Smith, C.U.: Performance Engineering of Software Systems. Addison-Wesley Longman, Boston (1990) 15. Tigris. ArgoUML. http://argouml.tigris.org/ 16. Xu, Z., Lehmann, A.: Automated Generation of Queuing Network Model from UML-Based Software Models with Performance Annotations. Technical report 2002-06, Universit¨ at der Bundeswehr M¨ unchen. (2002)