design of xmi-based tools for building eqn models of software systems

DESIGN OF XMI-BASED TOOLS FOR BUILDING EQN MODELS OF SOFTWARE SYSTEMS Andrea D’Ambrogio and Giuseppe Iazeolla∗ Dept. Computer Science, Systems and Production University of Roma TorVergata Roma, Italy E-Mail: {dambro,iazeolla}@info.uniroma2.it This paper focuses on performance models of queueing network type [3]. According to [5, 6] queueing network model building is roughly performed according to the following main steps:

ABSTRACT Research in software development is proving that model building during product development is essential to product validation. Indeed the model can be used in the early stages of the product lifecycle to predict the product compliance with the user performance requirements. This paper deals with software performance model building. Only a few methods and tools have been introduced for performance model automatic building, which would be of great interest to software developers, since existing performance methods and tools require a deep knowledge of performance theory. This paper illustrates the design of a tool for automatically building software performance models. The produced model is a queueing network. The design is based on recently published standards like MOF and XMI, that facilitate the easy interchange of models between different tools (e.g., software development tools, evaluation tools, etc.).

a) production of the software execution model by use of the execution graph formalism; b) derivation of the queueing network graph, consisting of service centers and connections between centers, basing on the platform configuration; c) parametrization of the model in b) by use of the model in a), in other words identification of centers’ service rates and routing probabilities among centers. The obtained queueing network (QN) is then evaluated and yields performance predictions, such as response time, throughput, utilization, etc. Nevertheless there are still some points that need further investigation in order to qualify QN model building approaches as a viable and effective means for software performance engineering. In particular:

KEY WORDS software performance, model building, queueing network, UML, XMI, MOF.

1

Introduction

1. the QN methods proposed in literature [4, 8] are empirical in nature and more rigorous algorithms to perform steps b) and c) should be introduced;

The main objective of software performance engineering is to enable software designers to assess product performance during development cycle [1, 2]. The basic idea is to use a software model to derive a performance model, which can be used to predict the product capability to meet the performance requirements [4, 5, 6]. Several methods for performance model building have been proposed, that roughly differ for:

2. the methods have not been implemented into a tool to enable software designers to easily introduce performance engineering as an integral part of their work. This paper introduces a tool1 to build QN models from execution graphs and platform descriptions. The tool also considers extended queueing networks (EQN), or queueing networks that can model resource simultaneous possession, fork-join software primitives, split primitives, etc. The tool design and implementation is based on the use of metadata-driven standards, like MOF (Meta Object Facility) and XMI (XML Metadata Interchange). Such standards, published by the OMG (Object Management Group), provide all the necessary ingredients to facilitate the easy interchange of models between different tools

• the type of performance model that is built (e.g., queueing network, petri net, markov chain, process algebra, etc.); • the automation degree, or the extent to which a method implementation is available to automatically build the model. ∗ Work partially supported by funds from the FIRB project on ”Performance Evaluation of Complex Systems” and from the University of Roma TorVergata CERTIA Research Center.

455-025

1 The tool has been developed at the Software Engineering Laboratory of the University of Roma ”Tor Vergata” [10].

366

(e.g., software development tools, model evaluation tools, etc.). This paper is organized as follows. Section 2 outlines the EQN model building process. Section 3 gives details about the tool architecture by describing how to exploit standards like MOF and XMI, while Section 4 illustrates the tool implementation with an example use.

2

! "# "

Overview of the EQN Building Process

The EQN building process is here illustrated, by use of a simple application case that deals with a distributed software product for remote surveillance. The product activates a set of cameras installed on remote sites for monitoring purposes. A log server is used to record each system operation. There are two categories of users: managers (10% of total users), whose typical session consists of checking the log content before activating a single camera, and operators (90% of total users), allowed to activate a mean number of 3 cameras for session. The tool for building the EQN model takes in input the software execution graph and the system deployment diagram. The deployment diagram (DD) describes the platform configuration and devices with the allocation of the software components onto platform devices. The execution graph (EG) is a standard flow graph enriched with resource usage data, specified by associating a so-called resource demand vector to each software block (or node) of the EG [1]. The resource demand vector is composed of elements that specify the number of times the software block makes use of each device (e.g. CPU, DISK, LAN, WAN, etc.) of the platform2 . Figure 1 illustrates the DD for the remote surveillance system3 . The platform configuration consists of a User Workstation, which executes the System component, and two servers, a Site Server, executing the Site Mgr component that manages the activation of monitoring cameras on the remote site, and a Log Server, executing the Log Mgr component that records all system activities. The User Workstation is connected to the Log Server by the LAN and to the Site Server by the WAN. The User Workstation includes a CPU (UWScpu), a disk (UWSdisk) and a terminal (UWSterm) operated by users of the system (both managers and operators), while the Site Server and the Log Server include only a CPU and a disk (SScpu, SSdisk, LScpu and LSdisk, respectively). Figure 2 illustrates the EG for the remote surveillance system. After user authentication (auth user node), the EG enters a CASE node with two alternative

!

Figure 2. Execution Graph (EG) for the remote surveillance system

nodes, the managers node (with probability 0.1) and the operators node (with probability 0.9). In the former case the system calls the log checking operation (call check log node), which is executed by the Log Mgr on the log server (exec check log node), and then calls the camera activation operation (call activ cam node), which is executed by the Site Mgr on the site server. In the latter case, the system enters a loop that performs three calls for the camera activation operation (call activ cam node), which is executed by the Site Mgr on the site server. Finally the system enters the SPLIT node that returns control to the user and asynchronously calls the log updating operation (call update log node), which is executed by the Log Mgr on the log server (exec update log node). EG nodes with side diamonds denote software servers, and the number inside the left diamond specifies the number of possible simultaneous activations. The model building process proceeds by breadth-first visiting the EG and incrementally producing the EQN basing on information given by the DD. The detailed description of the building algorithm, reported in [10] is not the focus of this work. Nevertheless, to give the reader a flavor of the algorithm, the portion of EQN resulting from the application of the model building algorithm to the Site Mgr:exec activ cam software server node in Figure 2 is obtained by: • introducing the TOKEN POOL with 2 tokens to represent the 2 possible simultaneous accesses to the software server, and the associated LOCK and FREE for tokens acquiring and releasing;

2 An EG can be either developed from scratch or obtained from design documents produced during product development. As an example the EG could be automatically derived from a set of appropriately annotated UML documents (namely, the use case diagram and the set of sequence diagrams that realize the use cases), as described in details in [5] and [9]. 3 For the sake of clarity, notes associated to DD elements are expressed by use of natural language instead of using stereotypes and tag values according to the UML Performance Profile [13].

• introducing the SScpu and SSdisk centers corresponding to demand vector elements, if not already intro-

367

( ) ! $ *

!

"#$

( ) ! $ *

%

&'

(' &

( ) ! $ *

&

&

&

Figure 1. Deployment Diagram (DD) for the remote surveillance system

• enable easy interchange of models between heterogeneous tools and repositories

duced in the existing EQN; • connecting service centers according to information given by the DD;

• facilitate the linking between tools.

• parameterizing the EQN by the routing probabilities and the center service rates, basing on the values of SScpu and SSdisk demand vector elements;

The availability of standard metamodels, or models of metadata, that define a language for describing specific kinds of models (performance models in the paper case), is essential to reach a high degree of model interoperability. To this scope, appropriate metamodels are introduced for the uniform representation of both EG and EQN models, according to currently available standards for metadatabased model interoperability (MOF, XMI). Note that the MOF metamodel for representing a DD is already available, being part of the UML metamodel illustrated in [14]. The MOF (Meta Object Facility) is an OMG standard that defines an abstract language and a framework for specifying, constructing, and managing technology neutral metamodels [12]. Figure 3 illustrates the EG metamodel, expressed in terms of MOF metamodeling constructs (classes, attributes, associations, etc.). An EG object4 consists of one or more Node objects. The value of the attribute kind of the Node object is chosen among the ones enumerated by the NodeType datatype, that identifies all different kinds of execution graph nodes (basic, case, loop, fork, join, split, software server). The multiplicity attribute is used to specify the degree of multiplicity of software servers, while the obj ref attribute provides a reference to the corresponding object of the sequence diagram that is responsible of the node execution. Each Node object is linked to subsequent node by use of the is connected to association and may include other EG objects to represent the

The so-obtained portion of EQN increments the EQN built from already visited nodes. The complete multi-class EQN is obtained when the final node of the EG is visited.

3

Tool architecture

The tool this paper illustrates has been designed to ease its integration into software environments that enable software designers to smoothly introduce performance engineering activities into their best development practices, without spending effort and time to exploit tools that require a deep knowledge of performance theory. Indeed, the EQN building tool imports and exports models of different types: the UML model of DD type and the EG model are imported models, while the produced EQN model is an exported one. Such models are produced and used by a set of side tools (e.g., UML-based development tools, execution graph editors, EQN evaluation tools, etc.) that are part of the same environment. In order to reach a high degree of interoperability between the EQN building tool and the set of side tools it is necessary to implement the concept of metadata-based model interoperability, which allows to: • use metadata to drive tool execution (in analogy to introspection and reflection mechanisms, currently offered by several programming languages)

4 The term object is here used to denote a meta-object, i.e., an instance of a meta-class in the MOF metamodel.

368

&

" !

&

'

'

) ) * + ) *,

!

&

'

%

"

%

& %

"

#

"##$

"##$

"

"##$

"

#

!

$ "

"

% " %

"

"

"##$

"

(##"

! !

Figure 3. MOF metamodel for EGs

Figure 4. MOF metamodel for EQN models

extended node concept or references to sub-graphs pointed by special nodes like case, fork-join, split or loop nodes [1]. Each Node object of an EG contains a Demand Vector object, which in turn is composed of one or more DVElement objects. The demand value attribute of the DVElement object specifies the hardware resource requirements for the PlatformDevice object it refers to. The unit of measure for the demand value is given by the service unit attributes of the corresponding PlatformDevice object, whose service time attribute specifies the time required to process a single service unit. Figure 4 illustrates the EQN metamodel expressed in terms of MOF constructs. Without going into the details, it is easy to see that the metamodel consists of a set of classes and associations that represent the essential elements of a generic EQN model (see [3] for a detailed description of EQN models). MOF metamodels are then mapped to the corresponding XML Schemas, which are used for the production and validation of XML documents representing EG and EQN models. The production of both XML Schemas (representing metamodels) and XML documents (representing models, i.e, instances of a metamodel) is defined as a set of rules by use of the XML Metadata Interchange (XMI) Specification [15]. As an example, the XML schema representing the EQN metamodel is illustrated in Figure 5.

4

- - + + - - - + - - - + - +

Tool implementation and example use

The implemented tool takes in input two XMI documents (an EG and a DD) and yields in output another XMI document (the corresponding EQN model). The use of an XMI format for the input and output documents provides an ef-

Figure 5. XML Schema produced from the EQN metamodel (compact view)

369

Appendice B Documento XML completo ricavato dall’ execution graph mostrato di seguito. I valori del vettore domanda sono stati inizializzati ai valori di default.

Figure 7. GUI of the EQN building tool Figure 6. The EG graphical editor with XMI import/export capabilities

the resulting EQN, which is automatically validated by use of the XML Schema produced from the EQN metamodel. In the example case, the tool identifies from the EG five classes, namely Users, Managers, Operators, Async and Back. Jobs change class according to probabilities given by the EG. For the sake of brevity the complete XMI document is not reported here. Nevertheless, Figure 8 illustrates a portion of the resulting XMI document showing the parameters of the SScpu EQN center for the Managers job class. Parameters specify the number of times each service center is visited, the center service rate and the routing probabilities between centers5 . Similar parameters are computed by the tool for the remaining EQN centers and job classes that have been identified. The parametrized EQN can then be evaluated by translating the XMI document into the input format of the specific tool used for the evaluation (e.g., QNAP, RESQ, etc.), as detailed in [10].

- 62 fective solution to the problem of dealing with heterogeneous data formats. Indeed, each side tool must only be endowed with a XMI import/export facility to be able to communicate with the XMI-compliant EQN building tool. Moreover such facility is already included in most of the current UML-based CASE tools, that can be used to produce the DD taken in input by the tool. Unfortunately no editors are available to build the EG in XMI format. To overcome such difficulty, an XMIenabled graphical editor for building EGs has been developed from scratch [11]. The EG editor, whose GUI is illustrated in Figure 6, allows to easily build an EG and finally save it as an XMI document. Existing EGs can be imported by use of the XMI import facility and then modified by use of the graphical features offered by the editor. The EQN building tool has been implemented in Java. It makes use of an XML parser to extract XML elements from the input documents (i.e., the EG and the DD) and a DOM-based (Document Object Model [16]) internal data structure to apply the process outlined in Section 2 and build the output document, i.e., the resulting EQN. An alternative approach that is currently under development is based on the implementation of XSLT (eXtensible Stylesheet Language Transformation) rules that, once applied to the input documents, allow to obtain the output document [19]. In such a case a standard XSLT processor (freely or commercially available) is used to apply XSLT rules, without the necessity of coding the component in a general purpose language like Java or C++. Figure 7 illustrates the simple user interface of the EQN building tool. The user is only required to provide the path to the XMI files of the EG and the DD and then click on the Build EQN button. By giving as input to the tool the XMI documents of the EG in Figure 2 and the DD in Figure 1, the obtained output is the XMI document of

5

Conclusions

Performance model building during product development is essential to predict, since the early stages of the product lifecycle, the product compliance with the user performance requirements. A key factor is the automation of model building, that enables software developers to build the performance model without the need for a deep knowledge of performance theory. This paper has illustrated the design of a tool for automatically building performance models of EQN type from execution graphs and deployment diagrams. The tool is based on recently published standards like MOF and XMI, that facilitate the easy interchange of models between different tools (e.g., software development tools, model build5 It is assumed a mean transfer of 10 KBytes for each visit to LAN and WAN service centers and a mean number of 10 accesses for each visit to UWSdisk, LSdisk and SSdisk service centers.

370

- closed - processor FCFS - - xmi.idref="J001" xmi.idref="S005" xmi.idref="S006" - xmi.idref="J001" xmi.idref="S005" xmi.idref="S005" - xmi.idref="J001" xmi.idref="S005" xmi.idref="S008"

plications, Computer Networks Journal, vol. 41, pp. 29–39, January 2003. [7] E. Dimitrov, A. Schmietendorf, R. Dumk,UMLbased Performance Engineering Possibilities and Techniques, IEEE Software, January/February 2002. [8] R. Pooley, P. King, The Unified Modeling Language and Performance Engineering, Proceedings of IEE Software, 1999. [9] A. D’Ambrogio, S OON: a Tool for Software Performance Validation, Report RI.01.03, Software Engineering Laboratory, Dept. Informatics S&P, University of Roma TorVergata, Roma (Italy), January 2003. [10] A. D’Ambrogio, G. Iazeolla, A. Dell’Ira, A Method to Derive EQN Models From Design Documents, Report RI.01.04, Software Engineering Laboratory, Dept. Informatics S&P, University of Roma TorVergata, Roma (Italy), January 2004.

Figure 8. Portion of the resulting EQN in XMI format

[11] A. D’Ambrogio, C. Ossino, Design and Implementation of an XMI-enabled Graphical Editor for Execution Graphs, Report RI.02.04, Software Engineering Laboratory, Dept. Informatics S&P, University of Roma TorVergata, Roma (Italy), February 2004.

ing tools, evaluation tools, etc.). To this purpose, appropriate MOF metamodels have been introduced to describe both execution graphs and EQN models. The metamodels have then been translated into XMI schemas, used to produce and validate the corresponding XMI documents. The tool takes in input an execution graph and a deployment diagram in XMI format and yields in output the resulting EQN in XMI format. A simple case study has been used to illustrate the tool capabilities and design features.

[12] Object Management Group, Meta Object Facility (MOF) Specification, version 1.4, April 2002. [13] Object Management Group, UML Profile for Scheduling, Performance and Time, March 2002. [14] Object Management Group, Unified Modeling Language (UML) Specification, version 1.4, September 2001. [15] Object Management Group, XML Metadata Interchange (XMI) Specification, version 1.2, January 2002.

References [1] C.U. Smith, Performance Engineering of Software Systems, Addison Wesley, 1992.

[16] WWW Consortium, Document Object Model (DOM) Level 1 Specification Version 1, W3C Recommendation, http://www.w3.org/TR/REC-DOM-Level-1, October 1998.

[2] C.U. Smith, L.G. Williams, Performance Solutions: a Practical Guide to Creating Responsive, Scalable Software, Addison Wesley 2002. [3] S.S. Lavenberg, Computer Performance Modeling Handbook, Academic Press, New York, 1983.

[17] WWW Consortium, eXtensible Markup Language (XML) 1.0, W3C Recommendation, http://www.w3.org/TR/2000/REC-xml-20001006, October 2000.

[4] V. Cortellessa, R. Mirandola, PRIMA-UML: a performance validation incremental methodology on early UML diagrams, Science of Computer Programming, vol. 44, pp. 101–129, 2002.

[18] WWW Consortium, XML Schema, W3C Recommendation, http://www.w3.org/XML/Schema, May 2001. [19] WWW Consortium, eXtensible Stylesheet Language: Transformations (XSLT), W3C Recommendation, http://www.w3.org/TR/1999/REC-xslt-19991116, November 1999.

[5] V. Cortellessa, A. D’Ambrogio, G. Iazeolla, Automatic Derivation of Software Performance Models from CASE documents, Performance Evaluation, 45(2-3):81–106, July 2001. [6] A. D’Ambrogio, G. Iazeolla, Steps towards the Automatic Production of Performance Models of Web Ap-

371