Early performance assessment in component-based software systems

www.ietdl.org Published in IET Software Received on 12th August 2011 Revised on 9th September 2012 Accepted on 22nd October 2012 doi: 10.1049/iet-sen.2011.0143

ISSN 1751-8806

Early performance assessment in component-based software systems Jaber Karimpour, Ayaz Isazadeh, Habib Izadkhah Department of Computer Science, Faculty of Mathematical Sciences, University of Tabriz, Tabriz, Iran E-mail: [email protected]

Abstract: Most techniques used to assess the qualitative characteristics of software are done in testing phase of software development. Assessment of performance in the early software development process is particularly important to risk management. Software architecture, as the first product, plays an important role in the development of the complex software systems. Using software architecture, quality attributes (such as performance, reliability and security) can be evaluated at the early stages of the software development. In this study, the authors present a framework for taking the advantages of architectural description to evaluate software performance. To do so, the authors describe static structure and architectural behaviour of a software system as the sequence diagram and the component diagram of the Unified Modelling Language (UML), respectively; then, the described model is automatically converted into the ‘interface automata’, which provides the formal foundation for the evaluation. Finally, the evaluation of architectural performance is performed using ‘queuing theory’. The proposed framework can help the software architect to choose an appropriate architecture in terms of quality or remind him/her of making necessary changes in the selected architecture. The main difference among the proposed method and other methods is that the proposed method benefits the informal description methods, such as UML, to describe the architecture of software systems; it also enjoys a formal and lightweight language, called ‘interface automata’ to provide the infrastructure for verification and evaluation.

1

Introduction

Software architecture is a main branch of software engineering, which includes techniques and methods to manage the complexity of software structure. Software architecture offers a view of a software system, which consists of components and connections. Each component includes a set of functional elements in the system. The connections give realisation to runtime interaction among the components. Architecture is the result of preliminary design decisions of components and communicative structure between them; and designing this level of work is necessary at the first phase of software development process. One of the architecture realities which create its assessment motive is that the architecture can cause or prevent the achievement of software quality attributes. For example, if the performance factor is a matter for the system, the connection between components and each component’s internal connection will be important. The cause of addressing the architecture evaluation is clear: the sooner problems in software projects are discovered; it will result less cost and the architecture will be of a low-cost option in this regard. Architecture assessment process will yield some results that can help to answer the following questions [1–3]: 1. Whether the designed system’s architecture is suitable or not? IET Softw., pp. 1–11 doi: 10.1049/iet-sen.2011.0143

2. By considering quality factors such as performance, whether the architecture is appropriate or not? 3. Which of two or more existing architectures are more suitable for the system under consideration? 4. What changes should be given to the existing architecture so that it will be suitable for system requirements? The significant impact of software architecture on the software quality encouraged us to provide a method which helps to establish a clear description of the software architecture to extract and evaluate the quality characteristics of software. 1.1

Terminology

Terms that are frequently used in this paper are defined as follows: 1.1.1 Software architecture: Architecture is the organisational structure of a system. Architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems (IEEE STD 610, 12). Software architectural patterns show the way the main components of software are arranged. Some examples of software architectural patterns are layered architecture pattern, pipe and filter architecture pattern, blackboard architecture and server–client architecture pattern. 1

& The Institution of Engineering and Technology 2013

www.ietdl.org A solution to this problem is to pick (and if necessary modify) an existing formalism or introduce a new one, with the following specific characteristics [5]:

Fig. 1 Different diagrams to describe architecture in 4 + 1 architectural view [4]

However, software architecture views should be used to show the software architecture and also are different aspects to look at the software. Such architecture should explain the static and dynamic aspects of the software. 4 + 1 architectural view model of architecture uses the diagrams of Fig. 1 [Unified Modelling Language (UML) model diagram] to describe software architecture. This paper uses component diagram and sequence diagram for the pertinent purposes (architectural description). 1.1.2 Component diagram: This diagram shows components within a system and relationships between them. Each component communicates with other components through the provider and request interfaces. In fact, provider and request interfaces of each component show the inputs and outputs of each component. 1.1.3 System sequence diagram: We use this diagram to model the sequence of interactions between system’s components. 1.1.4 Component sequence diagram: We will model the sequence of interactions (operations) of a single component by using this diagram. Participants in the sequence diagram of a component are software objects of a class. 1.2

Problem

Software architecture, as the first product, plays an important role in the development of complex software systems. Using software architecture, the assessable behaviour of the system, that is, quality attributes such as performance, reliability and security can be evaluated. Architectural evaluation can ensure whether the architecture satisfies these quality objectives or not. Today, different frameworks are used to describe software architecture. Some of them are based on the formal models while others, such as architecture description languages (ADLs), use special grammars to describe the components and communications between them. Some of them, such as UML, suggest visual attributes and diagrams. However, the fundamental weakness of informal methods is that using verification mechanisms for these models face many constraints. In contrast, formal methods have semantic and mathematical infrastructure and supported by verification tools. The overall problem addressed in this paper is providing a framework to take advantage of the formal and informal methods to describe software architecture and evaluate its performance at the early stages of software systems development. 2

& The Institution of Engineering and Technology 2013

1. Applicability at the requirement phase: The model must work and produce result at the requirement phase of the software development life cycle to provide early performance assessment. 2. To be usable and understandable: The proposed method should easily be used by the software designers. In fact, description of the software systems should be performed through the informal and/or semi-formal methods with which most software designer are familiar. 3. Flexibility with respect to requirement changes: When the software requirements are changed, the performance model should recalculate with minimum cost. 4. Formality: The model should be based on a formal software specification method. If the performance model has formal foundation for representation and analysis of software behaviour, then the measured performance value is realistic. 1.3

Motivation

Today, one of the software engineer’s concerns is to design the appropriate and low cost products, which satisfies the functional and non-functional requirements of the system. Meeting the non-functional requirements in software engineering is still at the beginning of its own way; whereas the non-functional requirements, especially performance, have a significant impact on the success of software systems. Meanwhile, if software systems are fully prepared and the analyst assesses some non-functional requirements in it, the systems may require some essential changes; it may even lead to the abandonment of the system or its redevelopment, which increases the cost of software system. Therefore to solve this problem, the non-functional requirements concerning performance and reliability should be evaluated and analysed through the development process, particularly at the preliminary phases of the development. Doing so, some changes can be applied at the beginning of the development process if some requirements are not met. Usually software architects and designers are not familiar with the evaluation and analysis of the non-functional requirements. This is because of the differences of knowledge between the designers and analysts of quality requirements. The motivation of this research is providing approaches to fill the knowledge gap between the software architect and the quality attributes, such as performance. In other words, our motivation is to integrate evaluation of performance requirement at the software architecture-design level. We believe, if evaluation of the quality attributes used at the preliminary phases of development, especially architecture-design level, it will reduce additional costs.

1.4

Claim

We claim that it is possible to provide a solution to the mentioned problem by doing the following tasks: 1. Specify software architecture: † Using UML component diagram [6] to specify the structural model of component-based software system. IET Softw., pp. 1–11 doi: 10.1049/iet-sen.2011.0143

www.ietdl.org † Using component sequence diagram (CSD) to specify behavioural model of each component. † Using system sequence diagram (SSD) to specify components interactions in order to determine the system scenarios. 2. Translate ‘CSD to interface automaton’ (described in Section 3.1). 3. Combine obtained ‘interface automata (IA)’ by considering SSD in order to model the system behaviour in scenarios (described in Section 3.2). 4. Compute performance of system using ‘queuing theory’ (described in Section 4).

2

We have used two types of the sequence diagram. The first one is the CSD, and the second type is the SSD, which shows the relationship and interaction among system’s components. In fact, the number of SSDs will be equal to the number of scenarios in the system. Sequence diagram of each component will automatically convert into the ‘interface automaton’. With respect to the SSD, the ‘IA’, which plays their roles in a scenario, will be combined to evaluate performance. Therefore a formal foundation will be created that is based on the mathematics for evaluation and verification of the software system. The proposed framework can help the software architect to choose an appropriate architecture in terms of performance or lets the architect to know the necessity of changes in the existing architecture.

Software engineers use various models to describe static and dynamic aspects of software systems architecture. Static structure of a system describes components and the relationship between them; and its dynamic part represents the behaviour of the system. Some description models and methods are UML, process algebra, message sequence chart, Petri net, ADLs and chemical abstract machine (CHAM). The mentioned models are compared according to the extent of model application in the development process, its intelligibility by the designer, supporting static structure and behaviour, abstraction-level model, the commonness of model application and its support tools. The incentive of this comparison is to select the best model to describe the software architecture. According to Table 1, it is observed that the formal languages, like automata, are not used much by software designers. On the other hand, UML, process algebra and message sequence chart (MSC) offers a semi-formal and informal description for software architecture. The use case map, process algebra and MSC describe only the dynamic behaviour of architecture and do not pay attention to the static structure. Owing to lack of acquaintance the software designers’, Petri net does not have much use. Also ADL describe only static structure of architecture [7, 8]. On the other hand, UML is used for the entire software development process. This language provides several diagrams by which static structure and dynamic behaviour of each component can be described. Therefore we choose UML as a top candidate among the reviewed models to describe software architecture.

1.5

Paper outline

The remaining sections of this paper are organised as follows: after introduction, in Section 2, we will review various software architecture description models, performance evaluation models and automata models in describing the architecture. In Section 3, creating IA model from UML descriptions is explained. In Section 4, queuing theory to predict software system performance is explained and in Section 5, transformation algorithm and performance model are applied on the architecture of web-service software as a case study. Finally, in Section 6, we will have conclusion and future work.

Background and evaluation

In this section, we will review various software architecture description models, performance evaluation models and automata models. Through comparing and evaluating these models, we will express our reason for choosing UML to describe software architecture in high abstract level, IA to describe the software architecture in low abstract level and queuing theory to evaluate the architecture performance. 2.1

Models describing the software architecture

Table 1 Comparison of various models to describe software architecture Name of the notation description the architecture

Formality rate

Ease of use

Domain application

Tool support

Focus

Description type

Abstraction level

Automata [9]

formal

poor

general

✓

requirement

dynamic behaviour

UML [4]

semi-formal

high

general

✓

Message sequence chart [10] Use case map [11] Process algebra [12]

informal

medium

general

✓

architecture and requirement requirement

static structure and dynamic behaviour dynamic behaviour

different levels different levels high-level

informal semi-formal

medium poor

general general

✓ ✓

requirement requirement

dynamic behaviour dynamic behaviour

Petri net [13]

semi-formal

high

general

✓

requirement

ADL [14]

informal

good

✓

architecture

Chemical abstract machine [15] Reliability block diagram [16] Fault tree [16]

informal

good

✓

architecture

static structure

semi-formal

good

✓

requirement

dynamic behaviour

semi-formal

good

architecture description architecture description reliability assessment reliability assessment

static structure and dynamic behaviour static structure

high-level different levels different levels different levels different levels high-level

✓

requirement

dynamic behaviour

high-level

IET Softw., pp. 1–11 doi: 10.1049/iet-sen.2011.0143

3

& The Institution of Engineering and Technology 2013

www.ietdl.org Table 2 Compare performance evaluation models [22, 23] Notation

Easiness

SPA Generalised stochastic Petri nets QN

Domain application

Adequacy

To model

To resize

medium medium

high low

general general

medium medium

medium

high

general

high

2.3 Comparing the ability of automata in describing software architecture

Table 3 Comparison of performance models [24] Notation

Easiness to model

Easiness to resize

Domain application

Adequacy

CSPN QN Bayesian Markov model

high medium – medium

high high high high

general general general general

high high medium medium

2.2

Ebadi [24] has continued the work [22, 23] in her PhD thesis and presented a comprehensive assessment of ‘coloured stochastic Petri net’, ‘Bayesian networks’ and ‘Markov models’. The evaluation results are shown in Table 3. Several methodologies have been introduced to translate software notation into ‘QN’ automatically. In contrast, a complete methodology for automatic conversion of software descriptions into Petri nets and stochastic process algebra has not introduced yet. Considering the benefits of QNs, in this paper, we use it to assess performance.

Performance evaluation models

In this section, we briefly compare the models used in performance evaluation such as, queue networks (QNs) [17, 18], stochastic Petri nets [19], stochastic process algebra (SPA) [20] and Markov models [21]. From the viewpoint of the software designers, choosing a suitable model is a controversial task. Each of these models has its own benefits and disadvantages. For this purpose, in [22, 23], an applied example called XML translator has been described, analysed and evaluated using QN models, generalised stochastic Petri nets and the SPA. In Table 2, summary of the study is illustrated. In this table, ‘easiness’ and ‘adequacy’ criteria are discussed. Ease means to simplify modelling the system and simplicity of the system configuration change. Adequacy also means the model ability to integrate and manage performance aspects in architectural descriptions. QNs are selected as a suitable notation for performance evaluation.

In this section, we compare the various types of automata models such as ‘I/O automata’ [25], ‘interaction automata’ [26] and ‘interface automata (IA)’ [27–29] briefly. Abilities of each mentioned models with evaluation criteria are compared in Table 4. This comparison shows the significant superiority of IA to other models. IA provide a formal framework to design component-based software system. The framework is based on a well-known method for modelling collaboration between components by composing them. Therefore it is a powerful model for modelling the interaction between components in software architecture. Two advantages of IA in architecture description are † A light-weight formal method to describe componentbased systems. † There are various tools to assessment and support it. By considering Table 4, we select IA as formalism for describing software architecture. This automaton presents a light-weight formalism that captures the temporal aspects of software component interfaces [27, 28]. The formalism supports automatic compatibility checks between interface models, and thus constitutes a type system for component interaction. Unlike traditional uses of automata, ‘IA’ formalism is based on an optimistic approach to composition, and on an alternating approach to design refinement. According to the optimistic approach, two components are compatible if there is

Table 4 Comparison of the automata models ability in describing the architectural behaviour Model evaluation criteria in describing the behaviour of software architectural

IA

Interaction automata

I/O automata

Preventing from accepting unsolicited input actions: this feature causes more flexibility in modelling the interactions, in this way that the components can respond to the requested services with a delay, if needed Possibility of existence of common elements in the set of input, output and internal actions of the components: possibility of service request transfer between the same samples of a component will be provided. This feature facilitates delegate modelling in architecture Possibility of participation of a composite component as an element in other combinations: owing to this feature, aggregation type of hierarchical modelling software components will be possible Absence of limit in simultaneous combination of more than two components: this feature allows modelling of the wide range of architectural styles Input enabled: the input active means that it never blocks the inputs. In this case, decision cannot be made directly on the characteristics of the interaction between a component such as A which is ready to send the output action of a to B output, which is not ready to receive it (for instance, when component B should finish some calculations) Possibility of refinement: the refinement relation aims at formalising the relation between abstract and concrete versions of the same component, for example, between an interface specification and its implementation. Obviously, this characteristic has a considerable impact on designing the architecture of the software systems Existence of strong support tools: it should have tools for modelling, simulation and verification of the systems

✓

✓

×

✓

×

×

✓

✓

✓

×

✓

✓

×

×

✓

✓

×

×

✓

×

✓

4

& The Institution of Engineering and Technology 2013

IET Softw., pp. 1–11 doi: 10.1049/iet-sen.2011.0143

www.ietdl.org some environment that can make them work together. In the optimistic approach, the interface captures not only the legal component behaviours but also an assumption about the environment, in the form of permissible environment behaviours. The optimistic view implies a notion of interface composition that leads to smaller compound automata than the pessimistic view. If two IA are composed, the result may contain error states, where one automaton generates an output that is an illegal input for the other automaton. However, the standard pessimistic view would consider the two interfaces to be incompatible.
Definition 1: An interface automaton P = VP , VPinit , AIP , AO P, AH , t ) consists of the following elements: P P † VP is a set of states. † VPinit # VP is a set of initial states. H † AIP , AO P , AP are mutually disjoint sets of input, output, and H internal actions. We denote by AP = AIP < AO P < AP the set of all actions. † τp ⊆ VP × AP × VP is a set of steps. Definition 2: Two ‘IA’ P and Q are composable if AH P > AQ = 0,

AIP > AIQ = 0

AH Q > AP = 0,

O AO P > AQ = 0

Definition 3: If P and Q are composable IA, their product P ⊗ Q is an interface automaton defined by VP⊗Q = VP × VQ ,

init VP⊗Q = VPinit × VQinit ,     O I shared(P, Q) = AIP < AO Q > AP < AQ   AIP⊗Q = AIP < AIQ \shared(P, Q),   O O = A < A AO P⊗Q P Q \shared(P, Q)   H H = A < A AH P⊗Q P Q < shared(P, Q)

3.1 Creating IA model from UML sequence diagrams We describe static structure of architecture by UML ‘component diagram’ and describe interactions between components with SSD. One component of UML is defined as component = [name, RI (or PI)]; where ‘name’ is the component name, PI represents a finite set of provide interfaces and RI is a finite set of request interfaces related to the component. The operational profile captures the set of inputs and outputs to a software component [30]. Therefore we define an operational profile for a component as OPcomponent = (PI, RI). Initially each component in the component diagram (CD) is considered as an automaton component. In other words, the correspondence g:CD.component → IA maps each component to its automaton. In addition to being able to convert each component into automata, the proposed algorithm specifies input and output of each automaton according to the component diagram. We create an equivalent IA for a given UML sequence diagram. Symbol c is used to denote an individual diagram. The set of instance lines for a diagram is given by inst(c). An instance line has locations to track the state of the associated agent. For an instance line i and diagram c, dom(c, i) = {l0, l1,…,lmax(i)} is the set of locations for i in c with the first location (top most location for a process line) given by l0 and the last location given by lmax(i) when moving from the top to the bottom of the instance line. As locations are not uniquely labelled in the diagram across instance lines, the set of pairs dom(c) = {〈i, l〉|i ∈ inst (c)∧l ∈ dom(c, i)} represents all instance and location pairs in a diagram c. The complete state of a diagram is the state of the individual instances as denoted by their current location. The initial state has every instance in its first location. The state of the diagram evolves as instances move from one location to another down the diagram. The preset (†) of a location 〈i, l〉 is the set of locations of diagram m that is smaller than 〈i, l〉   †ki, ll = ki′ , l ′ l [ dom(m)|ki′ , l ′ l ≤m ki, ll

A ‘point’ through a diagram, c, is a set of locations c, one for each instance in the diagram, such that for every location in the diagram, the preset †〈i, l〉 does not contain a location 〈i′, l′〉 such that 〈j, lj〉 ≺ 〈i′, l′〉 for some location 〈j, lj〉 in c   c = ki1 , l1 l, ki2 , l2 l, . . . , kin , ln l

tP⊗Q = {((v, u), a, (v′ , u))|(v, a, v′ ) [ tP ^ a  shared(P, Q) ^ u [ VQ } ′

′

< {((v, u), a, (v, u ))|(u, a, u ) [ tP ^ a  shared(P, Q) ^ v [ VP } < {((v, u), a, (v′ , u′ ))|(v, a, v′ ) [ tP ^ (u, a, u′ )

(1)

(2)

The set points(m) for a diagram m is the set of all possible points. A point c′ = (〈i0, li〉,…,〈in, ln〉) is said to succeed a point c = (〈i0, l′i〉,…,〈in, l′n〉), if ∃j,

0 ≤ j ≤ n,

lj′ = lj + 1 ^ ∀i = j,

lj′ = li

(3)

[ tQ ^ a [ shared(P, Q)}

3 New algorithm for creating IA model from UML descriptions In this section, we explain the conversion algorithm of each sequence diagram to a corresponding ‘interface automaton’ and we compose the interface automaton with respect to the SSD. IET Softw., pp. 1–11 doi: 10.1049/iet-sen.2011.0143

A point c′ succeeds a point c, if the location of one instance progresses to its immediately successive location and the remaining instances in the diagram maintain their location. A run of a diagram, c, is a sequence of points c0, c1, …, ck such that: † c0 is an initial point † ∀0 ≤ i < k, ci+1 succeeds ci † in the final point, all locations are maximal. 5

& The Institution of Engineering and Technology 2013

The interface automaton of the sequence diagram is obtained by exploring every possible ‘point’ through the diagram (using a ‘depth first search’). We used the depth first search, because of the limitation of the search space and less complexity of time and place comparing the other methods. A ‘point’ through a sequence diagram represents the current state of the automata as specified by the location of each object in the diagram and the state of the variables of the automata. Also, algorithm creates the automaton by relating each point to a state in the automaton. For each point, the successor points are generated using the ‘getPoints’ method. We also define the ‘getLabel(m)’ function that maps two points to the alphabet AP, given two points, returns the corresponding event that caused progress in the diagram (automaton). It should be noted that in the case of a simultaneous message, the getLabel(m) function only returns a letter for the send instance and not for the receive instance. Fig. 2 shows the proposed algorithm. In the first step, the algorithm will produce the initial point for a given sequence diagram and the corresponding state. The initial point is inserting to the queue and added to the state set Φ. Next, process every point in the queue. For each point, getPoints method generated the successor points. Each point is inserted in the queue and the corresponding state is added to the state set. In addition, the transition from the parent state s to the child state s′ is added in the automaton. The ‘addTransition’ method adds the transition from state s to s′ with the getLabel (c, c′) transition label. After all points have been processed, the initial state of the automaton is returned as the pointer to the entire automaton of the diagram. The final states of the automaton are marked as accept states to signify the end of the diagram. In the second step, input and output of each IA is specified with respect to the component diagram and add them to the input/output set of each automaton. 3.2

Computing the composition of IA

To compute the composition of IA we use algorithm that is designed by Luca de and Thomas [27]. Given two IA P and Q, a pair (v, u) ∈ VP × VQ is compatible if there is some environment under which Illegal(P, Q) is not reachable in P ⊗ Q from (v, u). As remarked above, the best environment corresponds to accepting all outputs of P ⊗ Q and generating no inputs for P ⊗ Q. On the basis of this observation, the set composition (P, Q) can be computed by performing a backward reachability analysis from Illegal (P, Q), which traverses only internal and output steps, and removes all states thus reachable. To present the algorithm, they introduced an operator ‘OHpre’. Intuitively, for a set U of states of an interface automaton R, the set OHpreR(U ) contains the states of R that can enter a state in U by taking an internal or output step. Formally, the operator OHpreR : 2VR  2VR is defined for all sets U ⊆ VR

Fig. 2 Proposed algorithm for creating IA from UML component and sequence diagrams

complexity of deciding compatibility, and computing the composition, of IA. Theorem 1: Given two IA P and Q, we can decide whether they are compatible, and we can compute P ⊗ Q in time linear in (|P|*|Q|). Since the composition of IA is associative, we can check whether n > 0 IA P1,…,Pn are compatible by computing their composition P1||…||Pn in a gradual fashion, constructing (P1||…||Pi–1)||Pi for i = 1, 2,…,n, and checking for each i that the resulting composition is non-empty. The efficiency of this check lies in the fact that, in the computation of (P1||…||Pi–1)||Pi, the incompatible states are pruned as early as possible. This idea is closely related to the use of games for the early detection of errors in verification. We can further improve the algorithm by composing the automata P1,…,Pn in a tree-like fashion, rather than in a linear order.

4 Using queuing theory to predict software system performance

(4)

As mentioned in Section 2.2, queuing theory is an efficient and accurate method to determine the performance of computer systems; it could be used to prediction software system’s performance. The considered factors in the proposed performance models to use queuing theory are as follows:

The set composition(P, Q) can be computed by iterating the operator OHpreP⊗Q, starting from Illegal(P, Q) until no new states are found. Algorithm 2 shows the composition two IA. Using Algorithm 2 in Fig. 3, the composition of two IA can be computed by first pruning the incompatible states from the product, and then, for optimisation, removing any unreachable states. The following theorem summarises the

(a) Performance of communication between the components depends on various factors, including the deployment of components in the system, distribution of components and network line performance (if distributed). Such information is not clearly stated in the preliminary description of the software. To obtain it, we should use the data collected from the similar systems. Definitions of connections in our model

  H OHpreR (U ) = v [ VR |∃(v, a, u) [ tO R < tR u [ U

6

& The Institution of Engineering and Technology 2013

IET Softw., pp. 1–11 doi: 10.1049/iet-sen.2011.0143

enable us to allocate a time delay for each connection from the beginning. For each automata component, synchronisation delay function of P′:τP → R + is defined as below:  P′ = (l, d )|l [ tp ,

where tp is a set of transitions  and d is a delay corresponding to l

(5)

(b) Performance of each component can be considered as dependent or independent of its behaviour. For instance, performance can be determined with respect to the total processing time of a component and/or the processing time of the request for each service’s of the component. In the method that will be presented later, we have considered the performance as high as the services level to increase accuracy. Since the prepared operation in the interfaces of each component was modelled as the input actions to that automaton component, we consider one processing time for each input action. This processing time can be extracted from the similar systems. Therefore we model each component of the architecture as an automaton, which contains performance information. Regarding this introduction, the proposed mechanism to define the performance specifications in the created automata model is as follows. For each automata component, we define the processing time function corresponding to action a, P:AIP  R+ as follows  P = (a, r)|a [ AIP , where r is a processing  time corresponding to action a

(6)

Therefore developed model for an automaton with performance factor is defined as

H ′ PFP = VP , VPinit , AIP , AO (7) P , AP , tP , PP , PP According to queuing theory, whereas we consider components interaction simultaneous and consecutive, in this case the entire composition of components for taking a sequence diagram can be considered a composed service

that its average service time is equal to the total of each component’s service time plus total performed delays synchronisations at the whole composition. If A = {a1, a2, …, am} is the set of communication actions that synchronisation is done on them and P(ai) is the average corresponding time service to action ai we will have m




1 = P′ li + P ai mk i=1

(8)

That (1/μk) is the average service time of scenario k that with composing IA in a sequence diagram are modelling. Now, if the software system has k-independent scenario, which the probability of request for each of the scenarios is fk and the input rate to the whole system is λ the response time corresponding to modelling architecture will be equal to R = (1/(λ − μ), so that μ is the entire architecture service rate which calculates through the following equation k 1

fi = m i=1 mi

(9)

From this information, results in ‘queuing theory’ make it possible to calculate for a single queue [17, 18]: † Utilisation (how often the service centre is occupied. (ρ = (λ/μ) = utilisation). † Average time a job spends waiting in the queue ( = (λ/(μ(μ − λ)))). † Average queue length. † The probability that the queue length is μ. † Whether the system is stable or overloaded. In an overloaded system, the queue grows faster than jobs can be processed; the server cannot keep up. † For a queue implemented as a buffer of length B, the rate at which incoming jobs are discarded because of buffer overflow (drop rate). In addition to the above results it is possible to calculate expected values for

Fig. 3 Algorithm for computing the composition of two IA (P ⊗ Q) IET Softw., pp. 1–11 doi: 10.1049/iet-sen.2011.0143

7

& The Institution of Engineering and Technology 2013

† Latency, the time for a job to be completely processed (=(1/μ)). † Throughput, the rate at which jobs are processed (throughput = utilisation/service time). † Number of outstanding jobs in the system (= (λ/(μ − λ))).

5

Case study

Consider the mini-architecture illustrated in Fig. 4, which contains three components: ‘a web server’, ‘a web client’ and a database (DB). Suppose that the client send requests to server component and receives answers. The server may send requests to DB component or to be able to provide answers to the client. To judge the suitability of the performance of this architecture, there are several questions that must be answered; a few of them include [1, 2]: † To what extent this website can handle the unforeseen requests? † What is the average response time? † Assuming that the response time is not more than a specified amount, what is the highest request congestion that this site can answer? In Fig. 4b the operational profiles for server component and DB component is defined as follows: For Server component: OPcomponent (inquire, respond). For DataBase component: OPcomponent (select, respond). Components interaction in this example is as follows: Suppose that two types of requests can be sent by a client to the server, one type is fetch which response is given in server and has no reference to DB and another type is query that is sent after the server to DB then returns to server again and eventually to the client. Also, assume that 40% of requests are fetch type and the rest are query type. Fig. 5 shows the

sequence diagram of the system that is correspondent to query scenario and fetch scenario. The server component processes the request received from the user. If it asks the DB for the reference, that is, ‘selected’, it will refer the request to the DB. If it is of the ‘fetch’ type, the server prepares the user’s request and returns. If the DB component receives a request from the server, it prepares and sends it to the server. In the first phase, the interface automaton for the server component (Fig. 6) and ‘DB’ component (Fig. 7) are extracted using Algorithm 1. In the second phase, the obtained automata of the ‘server’ and ‘DB’ components participate in the ‘query’ sequence diagram (Figs. 6 and 7), are combined using Definition 3. In other words, to combine the server and DB components, multiplication of server ⊗ database should be calculated using Definition 3. In Figs. 8 and 9, the composition of automata interface related to components of fetch and query sequence diagrams are shown.

Fig. 6 Interface automaton corresponding to server component

Fig. 4 Mini-architecture contains three components a Internal web site b Component diagram for a

Fig. 5 System sequence diagrams corresponding to query and fetch scenarios [4] 8

& The Institution of Engineering and Technology 2013

IET Softw., pp. 1–11 doi: 10.1049/iet-sen.2011.0143

Fig. 9 Interface automaton corresponding to fetch sequence diagram Fig. 7 Interface automaton corresponding to DB component

We declare the ‘unexpected’ states ( p, p) and (i, p) of the product automaton server ⊗ database to be illegal, because if the environment assumption of the component server is satisfied by its environment, then this state does not occur. There are two ways of dealing with illegal states. The standard pessimistic approach considers two IA incompatible if the product can reach illegal states. In contrast, according to optimistic approach server and DataBase are compatible. In fact, we consider two components compatible if there is some environment in which they work correctly. The composition server|| database of the two IA is obtained by restricting the product server ⊗ database to its compatible states (using Algorithm 2), as depicted in Fig. 10. To analyse the performance of this architecture, assume that the data are as follows: † Inputs rate to the system is equal to 20, where 0.6 are query and the rest are fetch. † Processing time by server and DB components, respectively, are 30 and 100 ms. † The delay connection between client and server is 2 s (DCS = 2 s) and delay connection between the server and DB is 80 ms (DSD = 80 ms). In this case, in accordance with the performance model presented relation 7, developed model of automata for the server is as follows PFserver =





init Vserver , Vserver , ′ Pserver , Pserver

AIserver ,

AO server ,

AH sever ,

tserver , (10)

Fig. 10 server||database (restricting the product of the two automata server and DB of Fig. 8 to its compatible states)

Function P according to the performance data model is   P = (a, 0.03)|∀a [ AIserver

(11)

Relation 11 shows the time required for processing by the server. In the automata model for DB (PFdatabase) we have P=




 ‘query’, 0.100

(12)

Relation 12 shows the time required for processing by the DB. Owing to the service time related to fetch scenario we have 1




1 = P′ li + P ai = 0.03 s m1 i=1

(13)

In fetch scenario, only one operation is processed by the server. DSD delay must be added to the final response time.

Fig. 8 server ⊗ database (Product of the two automata Server and Database in the query sequence diagram) IET Softw., pp. 1–11 doi: 10.1049/iet-sen.2011.0143

9

& The Institution of Engineering and Technology 2013

4. IA is a formal method and provides the formality we need, satisfying the four characteristic.

Service time related to query scenario is 2




1 = P′ li + P ai m2 i=1

= 0.08 + 0.08 + 0.03 + 0.1 + 0.03 = 0.32 s

6.2 (14)

In relation 14, 0.08 shows the contact time between the server and the DB that occurs twice. Also 0.1 shows the service processing time in the DB. A 0.03 is the processing time in the server, which occurs twice. So the average service time of software architecture is 1 = (0.4 × 0.03) + (0.6 × 0.32) = 0.204 s m

(15)

The average response time architecture is R=

1 1 = 0.066 s = l − m 20 − 4.901

(16)

The delay of connection between client and server (DCS = 2) should be added to the average response time. As of this delay is done twice it should be calculated twice. Thus, the average response time for requests in the system would be 0.066 + 4 = 4.066 s. Therefore software architect can evaluate system performance with increase simultaneous request of the system and can bring into action required decisions.

6

Conclusion and future work

Most methods which are used to evaluate performance are based on some complex methods. Most designers are not aware of these methods, and they have many problems to use them for evaluating software systems. Therefore in this paper, we proposed a framework for evaluating performance quality attributes at the early stages of the software development. In this framework, an algorithm is proposed that transforms the architectural models described in UML2.0 (component and sequence diagrams) to formal IA. Then, the obtained IA was developed, so that the performance data related to the components interactions had considered in it. Consequently, we could evaluate the performance of software system using the queuing theory. 6.1

Demonstration of the claim

We now return to Section 1.2, where we defined the overall problem addressed by this paper. Recall that our proposed solution is characterised as a new method, satisfying a list of specific characteristics: 1. Regarding the first characteristic of the solution, our approach is design to work and produce result at the design phase of the software development. 2. As the UML visual diagrams (most of designers are familiar with) were applied in the proposed method, using the proposed method made software performance evaluation as easy. 3. IA uses divide and conquer approach to specify component-based system requirement. Requirement changes and modification, therefore do not affect all of the system and so the third characteristic is satisfied. 10

& The Institution of Engineering and Technology 2013

Future work

In future work, it will be interest to extend and improve this work as follows: 1. Apply the alternating simulation approach proposed by Luca de and Thomas [27] to define the conformance of components with IA. 2. To extend the IA for other non-functional attributes (e.g. reliability and security).

7

References

1 Koziolek, H.: ‘Performance evaluation of component-based software systems: a survey’, Perform. Eval., 2010, 67, (2), pp. 634–658 2 Becker, S., Grunske, L., Mirandola, R., Overhage, S.: ‘Performance prediction of component-based systems: a survey from an engineering perspective’, in Reussner, R., Stafford, J., Szyperski, C. (Eds.): ‘Architecting Systems with Trustworthy Components’, (LNCS, 3938) (Springer, 2006), pp. 169–192 3 Bass, L., Clements, P., Kazman, R.: ‘Software architecture in practice’ (Addison-Wesley, 2002) 4 Object Management Group: ‘Unified Modeling Language 2.0’, http:// www.omg.org/uml/, 2003 5 Alipour, H., Isazadeh, A.: ‘Software reliability prediction based on a formal requirements specification’, Adv. Comput. Sci. Eng. Commun. Comput. Inf. Sci., 2009, 6, (2), pp. 816–820 6 Ivers, P., Clements, D., Garlan, R., Nord, B., Schmerl, J.R., Silva, V.: ‘Documenting component and connector views with UML2.0’. Technical Report, CMU/SEI, TR-008 ESC-TR-2004-008, 2004 7 Kacem, M.H., Jmaiel, M., Kacem, A.H., Drira, K.: ‘Using UML2.0 and GG for describing the dynamic of software architectures’. Proc. Third Int. Conf. Information Technology and Applications (ICITA’05), 2005 8 Kogut, P., Clements, P.C.: ‘Feature analysis of architecture description languages’. Proc. Software Technology Conf. (STC’95), Salt Lake City, April 1995 9 Hopcroft, J., Uliman, J.: ‘Introduction to automata theory, languages and computations’ (Addison-Wesley, 1979) 10 Sector I.T.S.: ‘Message sequence charts’, ITU-T Recommendation Z.120(11/99), 1999 11 Abuhr, R., Casselman, R.: ‘Use case maps for object-oriented systems’ (Prentice-Hall, 1996) 12 Milner, R.: ‘Communication and concurrency’ (Prentice-Hall International, International Series on Computer Science, 1989) 13 Reisig, W.: ‘Petri nets: an introduction’, EATCS Monogr. Theor. Comput. Sci., 1985, 4, pp. 325–392 14 Medvidovic, N., Taylor, R.N.: ‘A classification and comparison framework for software architecture description languages’, IEEE Trans. Softw. Eng., 2000, 26, (1), pp. 70–93 15 Corradini, F., Inverardi, P.: ‘Model checking of CHAM descriptions of software architectures’ (WICSA, 1999) 16 Johnson, A.M., Malek, J.M.: ‘Survey of software tools for evaluating reliability, availability, and serviceability’, ACM Comput. Surv., 1988, 20, (4), pp. 227–269 17 Kounev, S.: ‘Performance modeling and evaluation of distributed component-based systems using queueing Petri nets’, IEEE Trans. Softw. Eng., 2006, 32, (7), pp. 486–502 18 Cortellessa, V., Mirandola, R.: ‘Deriving a queueing network based performance model from UML diagrams’. Proc. Second Int Workshop Software and Performance (WOSP’00), 2000, pp. 36–55 19 Baccelli, F., Balbo, G., Boucherie, R., Campos, J., Chiola, G.: ‘Annotated bibliography on stochastic Petri nets’, in Tract, C. (Ed.): ‘Performance evaluation of parallel and distributed systems-solution methods’ (Amsterdam, 1994), (105), pp. 1–24 20 Thomas, N., Bradley, J.: ‘Towards reliable software performance modelling using stochastic process algebra’. Technical Report 2001/1, Department of Computer Science, University of Durham, 2001 21 Balsamo, S., Bernardo, M., Grassi, V.: ‘Quantitative analysis of software architectures’. Research Report, CS-2002-13, Department of information, University Ca’ Foscari di Venezia, 2002 22 Cortellessa, V., Marco, A.D., Inverardi, P.: ‘Three performance models at work: a software designer perspective’, Electr. Notes Theor. Comput. Sci., 2004, 97, pp. 219–239 IET Softw., pp. 1–11 doi: 10.1049/iet-sen.2011.0143

23 Cortellessa, V., Marco, A.D., Inverardi, P.: ‘Comparing performance models from a software designer perspective’. Technical Report TR SAH/042, 2003 24 Emadi, S.: ‘Introducing a new software architecture executable model’. PhD thesis, Department of Computer Engineering, Science and Research University, Tehran, Iran, 2008 25 Blundo, C., Cimato, S., De Prisco, R., Ferrara, A.L.: ‘Modeling a certified email protocol using I/O automata’. Electronic Notes in Theoretical Computer Science 99, Elsevier, 2004, pp. 339–359 26 Jin, Y.: ‘Compositional verification of component-based heterogeneous systems’. PhD thesis, Department of Computer Science, University of Adelaida, 2004

IET Softw., pp. 1–11 doi: 10.1049/iet-sen.2011.0143

27 Luca de, A., Thomas, A.H.: ‘Interface automata’. Proc. Joint Eighth European Software Engeneering Conf. and Ninth ACM SIGSOFT Symp. Foundation of Software Engeneering (ESEC/FSE-01), 5 of Software Engineering Notes, 2001, vol. 26, pp. 109–120 28 de Alfaro, L., Henzinger, T.A.: ‘Interface-based design’. Proc. 2004 Marktoberdorf, Summer School, Kluwer, 2004 29 Esmaeilsabzali, Sh., Mavaddat, F., Day, N.A.: ‘Interface automata with complex actions’. Electronic Notes in Theoretical Computer Science, Elsevier, 2005, pp. 79–97 30 Koziolek, H., Becker, S.: ‘Transforming operational profiles of software components for quality of service predictions’. Proc. Tenth Workshop on Component Oriented Programming (WCOP’05), July 2005, pp. 1–8

11

& The Institution of Engineering and Technology 2013