Bi-Dimensional Composition with Domain Specific Languages

Home , Executable UML, UML state machine

Editors

Zbigniew Huzar ([email protected]) Lech Madeyski ([email protected], http://madeyski.e-informatyka.pl/ )

Wrocław University of Technology Institute of Applied Informatics Wrocław University of Technology, 50-370 Wrocław, Poland e-Informatica Software Engineering Journal http://www.e-informatyka.pl/wiki/e-Informatica/

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, transmitted in any form, or by any means, electronic, mechanical, photocopying, recording, or othervise, without the prior written permission of the publishers.

Printed in the camera ready form

c Copyright by Oﬁcyna Wydawnicza Politechniki Wrocławskiej, Wrocław 2009

OFICYNA WYDAWNICZA POLITECHNIKI WROCŁAWSKIEJ Wybrzeże Wyspiańskiego 27, 50-370 Wrocław

ISSN 1897-7979

Drukarnia Oﬁcyny Wydawniczej Politechniki Wrocławskiej. Order No. 757/2009 . Editorial Board

Editor-in-Chief Zbigniew Huzar (Wrocław University of Technology, Poland)

Associate Editor-in-Chief Lech Madeyski (Wrocław University of Technology, Poland)

Editorial Board Members Pekka Abrahamsson (VTT Technical Research Centre, Finland) Sami Beydeda (ZIVIT, Germany) Miklós Biró (Corvinus University of Budapest, Hungary) Joaquim Filipe (Polytechnic Institute of Setúbal/INSTICC, Portugal) Thomas Flohr (University of Hannover, Germany) Félix García (University of Castilla-La Mancha, Spain) Janusz Górski (Gdańsk University of Technology, Poland) Andreas Jedlitschka (Fraunhofer IESE, Germany) Pericles Loucopoulos (The University of Manchester, UK) Kalle Lyytinen (Case Western Reserve University, USA) Leszek A. Maciaszek (Macqarie University Sydney, Australia) Jan Magott (Wrocław University of Technology, Poland) Zygmunt Mazur (Wrocław University of Technology, Poland) Bertrand Meyer (ETH Zurich, Switzerland) Matthias Müller (IDOS Software AG, Germany) Jürgen Münch (Fraunhofer IESE, Germany) Jerzy Nawrocki (Poznań Technical University, Poland) Krzysztof Sacha (Warsaw University of Technology, Poland) Rini van Solingen (Drenthe University, The Netherlands) Miroslaw Staron (IT University of Göteborg, Sweden) Tomasz Szmuc (AGH University of Science and Technology Kraków, Poland) Iwan Tabakow (Wrocław University of Technology, Poland) Rainer Unland (University of Duisburg-Essen, Germany) Sira Vegas (Polytechnic University of Madrit, Spain) Corrado Aaron Visaggio (University of Sannio, Italy) Bartosz Walter (Poznań Technical University, Poland) Jaroslav Zendulka (Brno University of Technology, The Czech Republic) Krzysztof Zieliński (AGH University of Science and Technology Kraków, Poland)

Contents

Editorial Zbigniew Huzar, Lech Madeyski ...... 7

Regular Paper A Component Model with Support of Mobile Architectures and Formal Description Marek Rychlý ...... 9 Special Issue Papers Bi-dimensional Composition with Domain Speciﬁc Languages Anca Daniela Ionita, Jacky Estublier, Thomas Leveque, Tam Nguyen ...... 27 Aspect-Oriented Change Realizations and Their Interaction Valentino Vranić, Radoslav Menkyna, Michal Bebjak, Peter Dolog ...... 43 Two Hemisphere Model Driven Approach for Generation of UML Class Diagram in the Context of MDA Oksana Nikiforova ...... 59 Automated Code Generation from System Requirements in Natural Language Jan Franců, Petr Hnětynka ...... 73 Tool Based Support of the Pattern Instance Creation Ľubomír Majtás ...... 89 Transformational Design of Business Processes in BPEL Language Andrzej Ratkowski, Andrzej Zalewski, Bartłomiej Piech ...... 103 Satisfying Stakeholders’ Needs – Balancing Agile and Formal Usability Test Results Jeﬀ Winter, Kari Rönkkö ...... 119 Web–Server Systems HTCPNs-Based Development Tool Application in Load Balance Modelling Slawomir Samolej, Tomasz Szmuc ...... 139

Editorial

It is a pleasure to present to our readers mented. The second paper by Vrani et al. de- the third issue of the e-Informatica Software scribes the approach to aspect-oriented change Engineering Journal (ISEJ). realization based on a two-level change type The mission of the e-Informatica Software model in the web application domain. The third Engineering Journal is to be a prime interna- paper by Nikiforova proposes two hemisphere tional journal to publish research findings and model driven approach for generation of UML IT industry experiences related to theory, prac- class diagram. The fourth paper by Franců and tice and experimentation in software engineer- Hnětynka presents an approach that allows au- ing. The scope of the journal includes method- tomated generation of executable code directly ologies, practices, architectures, technologies from the use cases written in a natural lan- and tools used in processes along the software guage. The fifth paper by Majtás presents tool development lifecycle, but particular interest is based support of the pattern instance creation in empirical evaluation. on the model level in a semi automatic way. The The third issue of the journal includes nine sixth paper by Ratkowski et al. demonstrates papers. Eight of the papers are extended a transformational approach to the design of versions of the best papers presented at the executable processes in Business Process Execu- CEE-SET’2008 conference (IFIP Central and tion Language (BPEL). The seventh paper by Eastern European Conference on Software En- Winter and Rönkkö is about balancing agile and gineering Techniques) carefully selected by the formal usability test results. The eight paper by editors, while the ninth is a regular paper. Samolej and Szmuc focuses on a new software The first of the papers by Ionita et al. tool for web-server systems development. The presents how domain modelling may leverage tool consist of a set of predefined Hierarchical the hierarchical composition, supporting two or- Timed Coloured Petri Net (HTCPN) structures thogonal mechanisms for composing completely – patterns. The last paper by Rychlý is a regular autonomous parts. The vertical mechanism is one and presents the component model that ad- in charge of coordinating heterogeneous compo- dresses component mobility including dynamic nents, tools or services at a high level of abstrac- reconfiguration, allows to combine control and tion, by hiding the technical details. The result functional interfaces, and separates a compo- of such a composition is called “domain” and is nent’s specification from its implementation. characterised by a Domain Specific Language We look forward to receiving quality contri- (DSL). The horizontal mechanism composes do- butions from researchers and practitioners in mains at the level of their DSLs, even if they software engineering for the next issue of the have been independently designed and imple- journal.

Editors Zbigniew Huzar Lech Madeyski e-Informatica Software Engineering Journal, Volume 3, Issue 1, 2009

A Component Model with Support of Mobile Architectures and Formal Description

Marek Rychl´y∗

∗Department of Information Systems, Faculty of Information Technology, Brno University of Technology, Boˇzetˇechova2, 612 66 Brno, Czech Republic [email protected]

Abstract Common features of current information systems have significant impact on software architectures of these systems. The systems can not be realised as monoliths, formal specification of behaviour and interfaces of the systems’ parts are necessary, as well as specification of their interaction. Moreover, the systems have to deal with many problems including the ability to clone components and to move the copies across a network (component mobility), creation, destruction and updating of components and connections during the systems’ run-time (dynamic reconfiguration), maintaining components’ compatibility, etc. In this paper, we present the component model that addresses component mobility including dynamic reconfiguration, allows to combine control and functional interfaces, and separates a component’s specification from its implementation. We focus on the formal basis of the component model in detail. We also review the related research on the current theory and practice of formal component-based development of software systems.

1. Introduction nately, design and implementation of those systems have to deal with many problems including Increasing globalisation of information society the ability to clone components and to move the and its progression create needs for extensive copies across a network (i.e. component mobil- and reliable information technology solutions. ity), creation, destruction and updating of com- Common requirements for current information ponents and connections during the systems’ systems include adaptability to variable struc- run-time (i.e. dynamic reconfiguration), main- ture of organisations, support of distributed taining components’ compatibility, etc. [6] activities, integration of well-established (third Moreover, distributed information systems party) software products, connection to a vari- are getting involved. Their architectures are able set of external systems, etc. Those fea- evolving during a run-time and formal spec- tures have significant impact on software archi- ifications are necessary, particularly in criti- tectures of the systems. The systems can not cal applications. Design of the systems with be realised as monoliths, exact specification of dynamic architectures (i.e. architectures with functions and interfaces of the systems’ parts dynamic reconfigurations) and mobile archi- are necessary, as well as specification of their tectures (i.e. dynamic architectures with com- communication and deployment. Therefore, the ponent mobility) can not be done by means information systems of organisations are realised of conventional software design methods. In as networks of quite autonomous, but cooper- most cases, these methods are able to describe ative, units communicating asynchronously via semi-formally only sequential processing or sim- messages of appropriate format [7]. Unfortu- ple concurrent processing bounded to one com- 10 Marek Rychlý ponent without advanced features such as dy- tion 6, we discuss advantages and disadvantages namic reconfiguration. of our component model and its formal descrip- The component-based development (CBD, tion compared with the reviewed approaches see [17]) is a software development methodol- and outline the future work. To conclude, in Sec- ogy, which is strongly oriented to composability tion 7, we summarise our approach and current and re-usability in a software system’s architec- results. ture. In the CBD, from a structural point of view, a software system is composed of components, which are self contained entities ac- 2. Component Model cessible through well-defined interfaces. A connection of compatible interfaces of cooperating In this section, we describe our approach to the components is realised via their bindings (con- component model. The component model is pre- nectors). Actual organisation of interconnected sented in two views: structural and behavioural. components is called configuration. Component At first, in Section 2.1, we introduce the compo- models are specific meta-models of software ar- nent model’s meta-model, which describes basic chitectures supporting the CBD, which define entities of the component model and their rela- syntax, semantics and composition of compo- tions and properties. The second view, in Sec- nents. tion 2.2, is focused on behaviour of the compo- Although the CBD can be the right way to nent model’s entities, especially on the compo- cope with the problems of the distributed in- nent mobility. formation systems, it has some limitations in formal description, which restrict the full sup- 2.1. Meta-model port for the mobile architectures. Those restrictions can be delimited by usage of formal bases The Figure 1 describes an outline of the compo- that do not consider dynamic reconfigurations nent model’s meta-model1 in the UML notation and component mobility, strict isolation of con- [20]. Three basic entities represent the core enti- trol and business logic of components that does ties of a component based architecture: a compo- not allow full integration of dynamic reconfigu- nent, an interface and a binding (a connector). rations into the components, etc. The component is an active communicat- This paper proposes a high-level component ing entity in a component based software sys- model addressing the mentioned issues. The tem. In our approach, the component con- model allows dynamic reconfigurations and com- sists of component abstraction and compo- ponent mobility, defined combination of control nent implementation. The component abstrac- and business logic of components, and sepa- tion (CompAbstraction in the meta-model) rep- ration of a component’s specification from its resents the component’s specification and be- implementation. The paper also introduces a haviour given by the component’s formal de- formal basis for description of the component scription (semantics of services provided by model’s semantics, i.e. the structure and be- the component). The component implementa- haviour of the components. tion (CompImplementation) represents a specific The remainder of this paper is organised as implementation of the component’s behaviour follows. In Section 2, we introduce the compo- (an implementation of the services). The imple- nent model in more detail. In Section 3, we pro- mentation can be primitive or composite. The vide the formal basis for description of the com- primitive implementation (CompImplPrimitive) ponent model. In Section 5, we review main ap- is realised directly, beyond the scope of archi- proaches that are relevant to our subject. In Sec- tecture description (it is “a black-box”). The

1 The ﬁgured diagram can not describe additional constraints, e.g. a composite component “contains” bindings that interconnect only interfaces of the component’s subcomponents, not interfaces of its neighbouring components, etc. A Component Model with Support of Mobile Architectures and Formal Description 11

NamedEntity name : string * subcomponents * is of type TypeOfInterface TypeOfValue CompAbstraction component interfaces Interface 1 1 impl. by accessible via 1 type * 1 * ToIControl 1 implementation is of type : IntCtrlTypeEnum * CompImplementation IntCompProxy ICProxyOutward ICProxyInward ToIFuncParam <> 1 * proxies IntCtrlTypeEnum * 1..* outer outParams inner start : void ref. 1 1 outer 1 1 inner inParams CompImplPrimitive provides stop : void ProvInterface ReqInterface input output clone : void attach : void CompImplComposite component 1 output 1..* input detach : void ToIFunctional to from getFuncInterf : void bindings Binding type TypeOfBinding consists of bindFuncInterf : void contains * * is of 1 ToIReference

ToIRefComp interface ToIRefInt * ref. *

Figure 1. The meta-model of the component model (the UML notation [20]) composite implementation (CompImplComposite) face (the relations “outer” and “inner” and is decomposable on a system of subcompo- vice versa). nents at the lower level of architecture de- According to the functionality of inter- scription (it is “a grey-box”). Those subcom- faces, we can distinguish functional, con- ponents are represented by component ab- trol and reference interfaces (described by stractions (CompAbstraction and relation “con- TypeOfInterface). The functional interfaces sists of”). (ToIFunct-ional) represent business oriented Interfaces of a component are described in services with typed input and output parame- relation to the component’s abstraction (re- ters (ToIFuncParam and TypeOfValue). The con- lation “accessible via” from CompAbstraction). trol interfaces (ToIControl and its attribute’s We distinguish two types of interfaces: re- type) provide services for obtaining references quired and provided (ReqInterface and Prov- to a component’s provided functional interfaces Interface, respectively), according to the type (type getFuncInterfaces), for binding a compo- of services required or provided by the com- nent’s required functional interfaces (type bind- ponent from or to its neighbouring compo- FuncInterface), and for changes of behaviour nents, respectively, at the same level of hi- (types start and stop) and architecture. The erarchy of components (i.e. not from or to services for changes of architecture are clone, subcomponents of a neighbouring component, attach and detach for obtaining references to a for example). Moreover, the composite com- fresh copy of a component (type “cloning”), at- ponents’ implementations (CompImplComposite) taching of a new component as a subcomponent provide special internal interfaces, which are and detaching of an old subcomponent, respec- available only for the component’s subcom- tively. The reference interfaces (ToIReference) ponents and make accessible the component’s are able to transmit references to components external interfaces (i.e. the interfaces de- or interfaces, which is required to support com- scribed in relation to CompAbstraction). The en- ponent mobility. tity ICProxyInward connects a composite com- Finally, the binding describes connection of ponent’s external provided interface to the required and provided interfaces of the identi- component’s internal required interface, while cal types and of components at the same level the entity ICProxyOutward connects a com- of the hierarchy into a reliable communication posite component’s internal provided interface link (entity Binding). The type of a binding to the component’s external required inter- (TypeOfBinding) can specify a communication 12 Marek Rychlý style (buffered and unbuffered connection), a type ToIRefComp) where it can be placed as a type of synchronisation (blocking and output subcomponent of a parent component (by means non-blocking), etc. of attach interface), connected to local neighbouring components (by means of bindFunc- 2.2. Behaviour and Support of Interf and getFuncInterf interfaces) and acti- Mobile Architectures vated (by means of start interface). Destruction of an old component can be done automatically The previous section introduces the structure after deactivating of the component (by means of the component model. A system described of stop interface), releasing of all its provided in- by means of the component model is one com- terfaces and disconnecting from its parent component with provided and required interfaces, ponent (by means of detach interface). which represent the system’s input and output Creation of new connections between two actions, respectively. The component can be im- compatible functional interfaces can be done by plemented as a primitive component or as a com- means of passing of functional interfaces (via in- posite component. The primitive component is terfaces of type ToIRefInt). At first, a reference realised directly, beyond the scope of architec- to provided functional interface (a target inter- ture description, while the composite component face) is obtained from a component (via control is decomposable at the lower level of hierarchy interface getFuncInterf). This reference is sent into a system of subcomponents communicating via outgoing connections into different location via their interfaces and their bindings. (via interfaces of type ToIRefInt), but only in Behaviour of a primitive component has to the same parent component and at the same be defined by a developer, simultaneously with level of hierarchy of components (i.e. crossing definitions of the component’s interfaces. The the boundary of a composite component is not primitive component is defined as “a black-box”, allowed). The reference is received by a compo- i.e. its behaviour can be described as a de- nent with compatible required functional inter- pendence relation of input and output actions. face (a source interface) and a binding of this Behaviour of a composite component depends interface to referenced interface is created (by on behaviour of its subcomponents, but it in- means of control interface bindFuncInterf). De- cludes also a description of communication be- struction of a connection can be done by rebind- tween connected interfaces of those subcompo- ing of a required interface participating in this nents and processing of specific control actions connection. in the component (e.g. requests for starting or As it follows from the description of be- stopping of the component and their distribu- haviour, the connections can interconnect only tion to the component’s subcomponents, etc.). interfaces of the same types. Moreover, dynamic In the following description, we focus on the creation of new connections and destruction of behaviour of control parts of components par- existing connection are permitted only for func- ticularly related to the features of mobile ar- tional interfaces (type ToIFunctional). Those re- chitectures, i.e. on creation and destruction of strictions, together with the restriction of pass- components and connections and on passing of ing of interfaces’ references described in the pre- components. Evolution of a system’s architec- vious paragraph, prevent architectural erosion ture begins in the state where its initialisation and architectural drift [11], which are caused is finished. by uncontrollable evolution of dynamic and mo- A new component can be created as a copy of bile architecture resulting into degradation of an existing component by means of its control the components’ dependencies over time. In the interface clone. The resulting new component component model, the architecture of control in- is deactivated (i.e. stopped) and packed into a terfaces and their interconnections, which allow message, which can be sent via outgoing con- evolution and component mobility, is a static ar- nections into different location (via interfaces of chitecture. A Component Model with Support of Mobile Architectures and Formal Description 13

Despite those restrictions, combining of ac- process by mentioning them in interactions. The tions of functional interfaces with actions of names received by a process can be used and control interfaces is permitted inside primi- mentioned by it in further interactions (as com- tive components. This allows to build systems munication links). This “passing of names” per- where functional (business) requirements imply mits mobility of communication links. changes of a systems’ architectures. Processes evolve by performing actions. The capabilities for action are expressed via three kinds of prefixes (“output”, “input” and “unob- 3. Formal Description servable”, as it is described later). We can define the π-calculus processes, their subclass and the In this section, formal description of behaviour prefixes as follows. of the component model’s entities is presented. Definition 1 (π-calculus). The processes, The Section 3.1 provides an introduction to the the summations, and the prefixes of the process algebra π-calculus, which is used in de- π-calculus are given respectively by scription in Section 3.2. The description is based P ::= M P P 0 (z)P !P on our previous research on distributed informa- | | | | M ::= 0 π.P M + M 0 tion systems as systems of asynchronous concur- | | π ::= x y x(z) τ rent processes [13] and the mobile architecture’s h i | | features in such systems [15, 14]. We give a brief, informal account of semantics of π-calculus processes. At first, process 0 is 3.1. The π-Calculus a π-calculus process that can do nothing, it is the null process or inaction. If processes P and P 0 The process algebra π-calculus, known also as a are π-calculus processes, then following expres- calculus of mobile processes [10], is an extension sions are also π-calculus processes with formal of Robin Milner’s calculus of communicating syntax according to the Definition 1 and given systems (CCS). This section briefly summarises informal semantics: the fundamentals of the π-calculus, a theory of – x y .P is an output prefix that can send h i mobile processes, according to [16]. The follow- name y via name x (i.e. via the communi- ing theoretical background is required for the cation link x) and continue4 as process P , component model’s formal description in Sec- – x(z).P is an input prefix that can receive any tion 3.2. The π-calculus allows modelling of sys- name via name x and continue as process P tems with dynamic communication structures with the received name substituted for every (i.e. mobile processes) by means of two concepts: free occurrence5 of name z in the process, a process – an active communicating en- – τ.P is an unobservable prefix that can evolve tity in a system, primitive or expressed in invisibly to process P , it can do an internal π-calculus (denoted by uppercase letters in (silent) action and continue as process P , 2 expressions) , – P + P 0 is a sum of capabilities of P together a name – anything else, e.g. a communica- with capabilities of P 0 processes, it proceeds tion link (a port), variable, constant (data), as either process P or process P 0, i.e. when etc. (denoted by lowercase letters in expres- a sum exercises one of its capabilities, the sions)3. others are rendered void, Processes use names (as communication – P P is a composition of processes P and P , | 0 0 links) to interact, and pass names (as variables, which can proceed independently and can in- constants, and communication links) to another teract via shared names,

2 A parametric process is also called “an agent”. 3 The names can be called according to their meanings (e.g. a port/link, a message, etc.). 4 The prefix ensures that process P can not proceed until a capability of the prefix has been exercised. 5 See the Definition 2. 14 Marek Rychlý

–( z)P is a restriction of the scope6 of name z an abstraction located at name a. In (x).P as in in process P , a(x).P , the displayed occurrence of x is binding –! P is a replication that means an infinite with scope P . composition of processes P or, equivalently, a Definition 3 (Abstraction). An abstraction process satisfying the equation !P = P !P . of arity n 0 is an expression of the form | ≥ The π-calculus has two name-binding opera- (x1, . . . , xn).P , where the xi are distinct. For tors. The binding is defined as follows. n = 1, the abstraction is a monoadic abstrac- Definition 2 (Binding). In each of x(z).P tion, otherwise it is a polyadic abstraction. and (z)P , the displayed occurrence of z is bind- When an abstraction (x).P is applied to ing with scope P . An occurrence of a name in an argument y it yields process P y/x . Ap- { } a process is bound if it is, or it lies within the plication is the destructor of abstractions. scope of, a binding occurrence of the name, oth- We can define two types of application: erwise the occurrence is free. pseudo-application and constant application. In our notations, we will omit a transmit- The pseudo-application is defined as follows. ted name, the second parts of input and out- Definition 4 (Pseudo-application). If F def= put prefixes in a π-calculus expression, if it is (˜x).P is of arity n and y˜ is length n, then not used anywhere else in its scope (e.g. in- P y/˜ x˜ is an instance of F . We abbreviate { } stead of (x)((y)x y .0 x(z).0), we can write P y/˜ x˜ to F y˜ . We refer to this instance op- h i | { } h i (x)(x.0 x.0)). eration as pseudo-application of an abstraction. | Since the sum and composition operators are In contract to the pseudo-application that is associative and commutative (according to the only abbreviation of a substitution, the constant relation of structural congruence [10]) they can application is a real syntactic construct. It al- be used with multiple arguments, independently lows to describe a recursively defined process. of their order. Also an order of application of the Definition 5 (Constant application). A re- restriction operator is insignificant. We will use cursive definition of a process constant K is an the following notations: expression of the form K =∆ (˜x).P , where x˜ con- – for m 3, let m P = P P ... P be tains all names that have a free occurrence in ≥ i=1 i 1 | 2 | | m a multi-composition of processes P1,...,Pm, P .A constant application, sometimes referred Q which can proceed independently and can in- as an instance of the process constant K, is a teract via shared names, form of process K a˜ . b c – for n 2 andx ˜ = (x , . . . , x ), let Communication between processes (a com- ≥ 1 n (x1)(x2) ... (xn)P = (x1, x2, . . . , xn)P = putation step) is formally defined as a reduction (˜x)P be a multi-restriction of the scope of relation . It is the least relation closed under → names x1, . . . , xn to process P . a set of reduction rules. We will omit the null process if the meaning Definition 6 (Reduction). The reduction relation, , is defined by the following rules: of the expression is unambiguous according to → the above-mentioned equations (e.g. instead of R-Inter (x y .P1 + M1) (x(z).P2 + M2) P1 P2 y/z x y .0 x(z).0, we can write x y x(z)). More- h i | → | { } h i | h i | over, the following equations are true for the null R-Tau τ.P + M P → process: P P 0 1 → 1 R-Par P P P P M + 0 = MP 0 = P (x)0 = 0 1 | 2 → 10 | 2 | P P 0 R-Res → The π-calculus processes can be (z)P (z)P 0 → parametrised. A parametrised process, an ab- P =P P 0=P 0 1 2 → 2 1 R-Struct P P straction, is an expression of the form (x).P . 1 → 10 We may also regard abstractions as components ∆ R-Const K a˜ P a/˜ x˜ K = (˜x).P of input-prefixed processes, viewing a(x).P as b c → { }

6 The scope of a restriction may change as a result of interaction between processes. A Component Model with Support of Mobile Architectures and Formal Description 15

The communication is described by the main as names used by the processes. The following reduction rule R-Inter. It means that a compo- names can be used in external or internal view sition of a process proceeding as either process of a component, i.e. for the component’s neigh- M1 or the process, which sends name y via name bours or the composite component’s subcompo- x and continues as process P1, and a process nents, respectively. s s g g proceeding as either process M2 or the process, – external: s0, s1, c, r1, . . . , rn, p1, . . . , pm (of a which receives name z via name x and continues primitive or composite component), s s g g as process P2, can perform a reduction step. Af- – internal: a, r10 , . . . , rm0 , p10 , . . . , pn0 (of a com- ter this reduction, the process is P P y/z posite component only), 1 | 2 { } (all free occurrences of z in P2 are replaced by y). where n is a number of the component’s required functional interfaces, m is a number of 3.2. Description of the Component the component’s provided functional interfaces Model (both from the external view) and the names have the following semantics: A software system can be described by means via s0 – a running component accepts a re- of the component model as one component with quest for its stopping, which a composite provided and required interfaces, which repre- component distributes also to all its subcom- sent the system’s input and output actions, re- ponents, spectively. According to the component model’s via s1 – a stopped component accepts a definition, every component can be implemented request for its starting, which a composite as a primitive component or as a composite com- component distributes also to all its subcomponent. Since a primitive component is realised ponents, as “a black-box”, its behaviour has to be de- via c – a component accepts a request for its fined by its developer. This behaviour can be cloning and returns a new stopped instance formally described as a π-calculus process, which of the component as a reply, s uses names representing the component’s inter- via ri – a component accepts a request for faces, but also implements specific control ac- binding given provided functional interface tions provided by the component (e.g. requests (included in the request) to the required to start or stop the component). On the con- functional interface ri, g trary, a composite component is decomposable via pj – a component accepts a request for at the lower level of hierarchy into a system of referencing to the provided functional inter- subcomponents communicating via their interface pj that is returned as a reply, faces and their bindings (the component is “a via a – a composite component accepts a grey-box”). Formal description of the composite request for attaching its new subcomponent, component’s behaviour is a π-calculus process, i.e. for attaching the subcomponent’s s0 and which is composition of processes representing s1 names (stop and start interfaces), which behaviour of the component’s subcomponents, can be called when the composite component processes implementing communication between will be stopped or started, respectively, and interconnected interfaces of the subcomponents as a reply, it returns a name accepting the and internal interfaces of the component and request to detach the subcomponent. processes realising specific control actions (e.g. We should remark that there is a relation- the requests to start or stop the composite com- ship between the names representing functional ponent, but including their distribution to the interfaces in the external view and the names component’s subcomponents, etc.). representing corresponding functional interfaces Before we define π-calculus processes imple- in the internal view of the composite compo- menting the behaviour of a component’s indi- nent. The composite component connects its ex- vidual parts, we need to define the component’s ternal functional interfaces r1, . . . , rn (required) interfaces within the terms of the π-calculus, i.e. and p1, . . . , pm (provided) accessible via names 16 Marek Rychlý

s s g g r1, . . . , rn and p1, . . . , pm, respectively, to internal functional interfaces p10 , . . . , pn0 (provided) and g g s s r10 , . . . , rm0 (required) accessible via names p10 , . . . , pn0 and r10 , . . . , rm0 , respectively. Requests received via external functional provided interface pj are forwarded to the interface, which is bound to internal functional required interface rj0 (and analogously for interfaces pi0 and ri).

3.2.1. Interface’s References and Binding

At first, we define an auxiliary process W ire7, which can receive a message via name x (i.e. input) and send it to name y (i.e. output) repeatedly till the process receives a message via name d (i.e. disable processing). W ire =∆ (x, y, d).(x(m).y m .W ire x, y, d + d) h i b c Binding of a component’s functional interfaces is done via control interfaces. These control interfaces provide references to a component’s functional provided interfaces and allow to bind a component’s functional required interfaces to referenced fictional provided interfaces of another local components. Process CtrlIfs implementing the control interfaces can be defined as follows

SetIf =∆ (r, s, d).s(p).(d.W ire r, p, d SetIf r, s, d ) b c | b c def GetIf = (p, g).g(r).r p h i def P lug = (d).d

def s s g g CtrlIfs = (r1, . . . , rn, r1, . . . , rn, p1, . . . , pm, p1, . . . , pm) n m .( (rd)(P lug rd SetIf r , rs, rd ) !GetIf p , pg ) i h i i | b i i i c | h j j i Yi=1 jY=1 s s g g where names r1, . . . , rn, r1, . . . , rn, p1, . . . , pm, p1, . . . , pm have been deﬁned at the beginning of Section 3.2. Let us assume CtrlIfs shares its names r1, . . . , rn and p1, . . . , pm with a process implementing a component’s core functionality via its required and provided interfaces, respectively. Pseudo-application GetIf p , pg enables process Ctrl to receive a name x via pg and to send p h j j i Ifs j j via name x as a reply (it provides a reference to an interface represented by pj). Constant application SetIf r , rs, rd enables process Ctrl to receive a name x via rs, which will be connected to r b i i i c Ifs i i by means of a new instance of process W ire (it binds a required interface represented by ri to a d provided interface represented by x). To remove a former connection of ri, a request is sent via ri (in case it is the ﬁrst connection of ri, i.e. there is no former connection, the request is accepted by pseudo-application P lug rd ). h i i In a composite component, the names representing external functional interfaces r1, . . . , rn, p1, . . . , pm are connected to the names representing internal functional interfaces p10 , . . . , pn0 , r10 , . . . , rm0 . Requests received via external functional provided interface pj are forwarded to the interface, which is bound to internal functional required interface rj0 (and analogously for interfaces pi0 and ri). This is described in process CtrlEI .

def CtrlEI = (r1, . . . , rn, p1, . . . , pm, r10 , . . . , rm0 , p10 , . . . , pn0 ) n m . (d)W ire r , p0 , d (d)W ire r0 , p , d b i i c | b j j c Yi=1 jY=1

7 The process will be used also in the following parts of Section 3.2. A Component Model with Support of Mobile Architectures and Formal Description 17

3.2.2. Control of a Component’s Life-cycle

8 Control of a composite component’s life-cycle can be described as process CtrlSS.

Dist =∆ (p, m, r).(p m .Dist p, m, r + r) h i b c Life =∆ (s , s , p , p ).s (m).(r)(Dist p , m, r r.Life s , s , p , p ) x y x y x b x c | b y x y xc def Attach = (a, p0, p1).a(c0, c1, cd)(d) (c (m).d m .d m W ire p , c , d W ire p , c , d ) d h i h i | b 0 0 c | b 1 1 c def Ctrl = (s , s , a).(p , p )(Life s , s , p , p !Attach a, p , p ) SS 0 1 0 1 b 1 0 1 0c | h 0 1i where names s0 and s1 represent the component’s interfaces that accept stop and start requests, respectively, and name a that can be used to attach a new subcomponent’s stop and start interfaces (at one step). The requests for stopping and starting the component are distributed to its subcomponents via names p and p . Constant application Life s , s , p , p enables process Ctrl to receive 0 1 b 1 0 1 0c SS a message m via s0 or s1. Message m is distributed to the subcomponents by means of constant application Dist p , m, r via shared name p , which can be p in case the component is running or b x c x 0 p1 in case the component is stopped. When all subcomponents accepted message m, it is announced via name r and the component is running or stopped and ready to receive a new request to stop or start, respectively. Pseudo-application Attach a, p , p enables process Ctrl to receive a message via a, a re- h 0 1i SS quest to attach a new subcomponent’s stop and start interfaces represented by names c0 and c1, respectively. The names are connected to p0 and p1 via new instances of processes W ire. Third name received via a, cd, can be used later to detach the subcomponent’s previously attached stop and start interfaces.

3.2.3. Cloning of Components and Updating of Subcomponents

Cloning of a component allows to transport the component’s fresh copy into different location, i.e. its subsequent attaching as a subcomponent of other component. The processes of the cloning can be described as follows ∆ s s g g Ctrlclone = (x).x(k).(s0, s1, c, r1, . . . , rn, p1, . . . , pm, r, p) (k s , s , c, r, p r rs, . . . , rs p pg, . . . , pg h 0 1 i | h 1 ni | h 1 mi Component s , s , c, rs, . . . , rs , pg, . . . , pg Ctrl x ) | h 0 1 1 n 1 mi | cloneb c s s g g where pseudo-application Component s , s , c, r , . . . , r , p , . . . , pm with well-defined parameters h 0 1 1 n 1 i describes behaviour of the cloned component. When process Ctrlclone receives a request k via name x, it sends names s0, s1, c, r, p via name k as a reply. The first three names represent “stop”, “start” and “clone” interfaces of a fresh copy of the component. The process is also ready to send names representing functional requested and provided interfaces of the new component, i.e. names s s g g r1, . . . , rn via name r names p1, . . . , pm via name p, respectively, and to receive a new request. The fresh copy of a component can be used to replace a compatible subcomponent of a composite component. The process of update, which describes the replacing of an old subcomponent with a new one, is not mandatory part of the composite component’s behaviour and its implementation

8 A primitive component handles stop and start interfaces directly. 18 Marek Rychl´y depends on particular conﬁguration of the component (e.g. if the component allows updating of its subcomponents, a context of the replaced subcomponent, which parts of the component have to be stopped during the updating, etc.). As an illustrative case, we can describe process Update as follows

∆ s s g g Update = (u, a, s0, sd, r1, . . . , rm, p1, . . . , pn)(k, sd0 ) .(u k .k(s0 , s0 , c, r0, p0).s .a s0 , s0 , s0 .s h i 0 1 0 h 0 1 di d s s g s g s .r0(r0 , . . . , r0 ).(x)(p x .x(p).r p ... pn x .x(p).r p ) 1 n 1h i 10 h i h i n0 h i g g g s g s .p0(p10 , . . . , pm0 ).(x)(p10 x .x(p).r1 p ... pn0 x .x(p).rm p ) h si s h gi gh i h i .s .Update u, a, s0 , s0 , r , . . . , r , p , . . . , p ) 10 b 0 d 1 m 1 nc Process Update sends via name u a request for a fresh copy of a cloned component. As a return value, it receives a vector of names representing all functional interfaces in a process describing behaviour of the new component, which will replace an old subcomponent in its parent component implementing the update process. Name a provides the parent component’s internal control interface to attach the new subcomponent’s stop and start interfaces (the s0 and s10 names) and an interface later used to detach the subcomponent (name sd0 ). Name s0 is used to stop the replaced subcomponent and name sd is needed to detach the old subcomponent’s stop and start s s g g interfaces. Finally, names r1, . . . , rm, p1, . . . , pn represent a context of the updated subcomponent, i.e. connected interfaces of neighbouring subcomponents.

3.2.4. Primitive and Composite Components

In conclusion, we can describe the complete behaviour of primitive and composite components. Let’s assume that process abstraction Compimpl with parameters s0, s1, r1, . . . , rn, p1, . . . , pm describes behaviour of the core of a primitive component (i.e. excluding processing of control actions), as it is deﬁned by the component’s developer. Further, let’s assume that process abstraction Compsubcomps s s g g with parameters a, r10 , . . . , rm0 , p10 , . . . , pn0 describes behaviour of a system of subcomponents interconnected by means of their interfaces into a composite component (see Section 3.2.1). Names s s g g s0, s1, r1, . . . , rn, p1, . . . , pm and names a, r1, . . . , rm, p1, . . . , pn are deﬁned at the beginning of Section 3.2. Processes Compprim and Compcomp representing behaviour of the mentioned primitive and composite components can be described as follows

def s s g g Compprim = (s0, s1, c, r1, . . . , rn, p1, . . . , pm)(r1, . . . , rn, p1, . . . , pm) .(Ctrl r , . . . , r , rs, . . . , rs , p , . . . , p , pg, . . . , pg Ctrl c Ifsh 1 n 1 n 1 m 1 mi | cloneb c Comp s , s , r , . . . , r , p , . . . , p ) | implh 0 1 1 n 1 mi def s s g g Compcomp = (s0, s1, c, r1, . . . , rn, p1, . . . , pm)

.(a, r1, . . . , rn, p1, . . . , pm, r10 , . . . , rm0 , p10 , . . . , pn0 ) s s g g (CtrlIfs r1, . . . , rn, r1, . . . , rn, p1, . . . , pm, p1, . . . , pm h s s g i g Ctrl r0 , . . . , r0 , r0 , . . . , r0 , p0 , . . . , p0 , p0 , . . . , p0 | Ifsh 1 m 1 m 1 n 1 n i CtrlEI r1, . . . , rn, p1, . . . , pm, r10 , . . . , rm0 , p10 , . . . , pn0 Ctrlclone c | h s s g i | g b c Ctrl s , s , a Comp a, r0 , . . . , r0 , p0 , . . . , p0 ) | SSh 0 1 i | subcompsh 1 m 1 n i where processes CtrlIfs represent behaviour of control parts of components related to their interfaces (see Section 3.2.1), processes Ctrlclone describe behaviour of a control part of components related to cloning of these components (see Section 3.2.3), process CtrlSS represents behaviour of A Component Model with Support of Mobile Architectures and Formal Description 19 a component’s control part handling its stop and start requests (see Section 3.2.2), and process CtrlEI describes behaviour of communication between internal and external functional interfaces of a component (see Section 3.2.1).

4. An Example

As an example, we describe a component based system for user authentication and access control. At first the system receives an input from an user in form (username, password) and verifies the user’s password in order to check the user’s identity. If the user’s password passes the verification, the system creates a new session handle reserved for the user. The session handle is connected to the system’s core. It enables the user to access the system’s core functionality and performs the access control according to the user’s authorisation. Finally, the session handle is passed back to the user as a return value of the whole process. The system is composed of Login component verifying the user’s authentication and initiating the new session, • Core component providing the system’s core functionality, • and Session component enabling the user to access the Core component according to the • user’s authorisation. For simplicity, let’s assume that component Session has only one input interface for the user’s calls of the system’s core without any explicit authorisation checks and component Core implements simple shared memory – one storage for all users with two interfaces: for saving and loading a value to and from the memory, respectively.

4.1. Deﬁnition of the Components’ Implementations

At ﬁrst, we describe behaviour of cores of primitive components, i.e. the components’ implementations, which have to be deﬁned by developer of the system (see Section 3.2.4). Description of behaviour of the Core component’s implementation is:

def Core = (s , s , p , p )(val)Core0 undef, p , p impl 0 1 save load implb save loadc ∆ Core0 = (val, p , p )(p (val0).Core0 val0, p , p impl save load save implb save loadc + p (ret).(ret val Core0 val, p , p ) load h i | implb save loadc where process Coreimpl can save a message received via name psave and load the saved message and send it as a reply on a request received via name pload. Description of behaviour of the Session component’s implementation is the following:

def Session = (s , s , r , r , p )Session0 r , r , p impl 0 1 save load handle implh save load handlei def Sessionimpl0 = (rsave, rload, phandle)(save, load)(phandle(ret) .ret save, load .Session0 r , r , p , save, load ) h i implb save load handle c ∆ Sessionimpl00 = (rsave, rload, phandle, save, load) (save(call).r call .Session0 r , r , p saveh i implh save load handlei + load(call).r call .Session0 r , r , p ) loadh i implh save load handlei 20 Marek Rychlý where process Sessionimpl can receive via name phandle an user’s request, which is specified subsequently by inputs via names save or load, and pass it to process Coreimpl via names rsave or rload (the required interfaces), respectively. Finally, behaviour of the Login component’s implementation can be defined as follows:

∆ g g Loginimpl = (s0, s1, pinit, sysattach, sessionclone, coresave, coreload) pinit(username, password, ret)

.(Loginverify username, password, ok, fail h g i g Login0 sys , session , core , core , ret, ok, fail | implb attach clone save load c Login s , s , p , sys , session , coreg , coreg ) | implb 0 1 init attach clone save loadc

∆ g g Loginimpl0 = (sysattach, sessionclone, coresave, coreload, ret, ok, fail)(new, d0, t)

(fail.ret error + ok.sessionclone new .new(s0, s10 , clone0, r0, p0) h i s s h g i .sys s0 , s0 , d0 .r0(r0 , r0 ).p0(p0 ) attachh 0 1 i save load handle g s g s .coresave t .t(save).r save .core t .t(load).r load h i save0 h i loadh i load0 h i g .p0 (handle).(s ret handle ) handle 10 | h i where process Loginimpl can receive an user’s initial request via name pinit as a triple of names (username, password, ret) and after successful veriﬁcation of the user’s name and password, the process returns a new session’s handle via name ret. Name sysattach provides an interface to attach new subcomponents into the system (see Section 3.2.2), name sessionclone is connected to a provided g g interface for cloning of Session component (see Section 3.2.3), and names coresave or coreload are connected to provided control interfaces for getting references to interfaces save or load of component Core (see Section 3.2.1), respectively. The deﬁnition contains pseudo-application of process abstraction Login username, password, ok, fail , which represents description of behaviour verifyh i def of user’s authentication process (e.g. Loginverify = (... ).ok for authorising of all users).

4.2. Description of the Component Based System

Now, we can describe behaviour of individual components including their control parts, as well as behaviour and structure of a composite component, which represents the whole component based system. According to Section 3.2.4, behaviour of components Core and Session can be described as follows: def g g Core = (s0, s1, c, psave, pload).(psave, pload) (Ctrl p , p , pg , pg Ctrl c Ifsh save load save loadi | cloneb c Core s , s , p , p ) | implh 0 1 save loadi def s s g Session = (s0, s1, c, rsave, rload, phandle).(rsave, rload, phandle) (Ctrl r , r , rs , rs , p , pg Ctrl c Ifsh save load save load handle handlei | cloneb c Session s , s , r , r , p ) | implh 0 1 save load handlei Behaviour of component Login has to be described diﬀerently from the others, because it uses g g control interfaces sysattach, sessionclone, coresave, coreload, which can not be referenced (contrary to functional interfaces, see Section 2.2). This case can be compared with the description of Update A Component Model with Support of Mobile Architectures and Formal Description 21 process in Section 3.2.3. The behaviour of component Login can be described as follows:

def g g g Login = (s0, s1, c, pinit, sysattach, sessionclone, coresave, coreload).(pinit) (Ctrl p , pg Ctrl c Ifsh init initi | cloneb c Login s , s , p , sys , session , coreg , coreg ) | implb 0 1 init attach clone save loadc Finally, behaviour and structure of a composite component, which represents the whole component based system, can be described as follows:

def g s System = (s0, s1, c, pinit)(a, pinit, rinit0 , rinit0 ) g s .(CtrlIfs pinit, pinit CtrlIfs rinit0 , rinit0 CtrlEI pinit, rinit0 h i | h i | s h i Ctrl c Ctrl s , s , a System0 a, r0 ) | cloneb c | SSh 0 1 i | h initi def s System0 = (sysattach, rinit) g g g s s g (pinit, coresave, coreload, sesssave, sessload, sesshandle, loginclone, coreclone)

(Login slogin, slogin, login , pg , sys , sess , coreg , coreg h 0 1 clone init attach clone save loadi Core score, score, core , coreg , coreg | h 0 1 clone save loadi Session ssess, ssess, sess , sesss , sesss , sessg | h 0 1 clone save load handlei sys slogin, slogin, dlogin sys score, score, dcore | attachh 0 1 i | attachh 0 1 i sys ssess, ssess, dsess pg t .t(init).rs init ) | attachh 0 1 i | inith i inith i

5. Related Work

There have been proposed several component models [8]. In this section, we focus on two contemporary component models supporting some features of dynamic architectures and formal descriptions.

5.1. Fractal

The component model Fractal [3] is a general component composition framework with support for dynamic architectures. A Fractal component is formed out of two parts: a controller and a content. The content of a composite component is composed of a finite number of nested components. Those subcomponents are controlled by the controller (“a membrane”) of the enclosing component. A component can be shared as a subcomponent by several distinct components. A component with empty content is called a primitive component. Every component can interact with its environment via operations at external interfaces of the component’s controller, while internal interfaces are accessible only from the component’s subcomponents. The interfaces can be of two sorts: client (required) and server (provided). Besides, a functional interface requires or provides functionalities of a component, while a control interface is a server interface with operations for introspection of the component and to control its configuration. There are two types of directed connections between compatible interfaces of components: primitive bindings between a pair of components and composite bindings, which can interconnect several components via a connector. 22 Marek Rychlý

Behaviour of Fractal components can be for- interfaces of components. The connector archi- mally described by means of parametrised net- tecture can be simple (for primitive connectors), works of communicating automata language [2]. i.e. directly implemented by described software Behaviour of each primitive component is mod- system, or compound (for composite connectors), elled as a finite state parametrised labelled tran- which contains instances of other connectors and sition system (pLTS) – a labelled transition components. system with parametrised actions, a set of pa- The SOFA uses a component definition lan- rameters of the system and variables for each guage (CDL) [9] for specification of compo- state. Behaviour of a composed Fractal components and behaviour protocols (BPs) for formal nent is defined using a parametrised synchroni- description of their behaviours. The BPs [21] sation network (pNet). It is a pLTS computed are regular-like expressions on the alphabet of as a product of subcomponents’ pLTSs and a event tokens representing emitting and accepting transducer. The transducer is a pLTS, which method calls. Behaviour of a component (its in- synchronises actions of the corresponding LTSs terface, frame and architecture) can be described of the subcomponents. When synchronisation of by a BP (interface, frame and architecture proto- the actions occurs, the transducer changes its col, respectively) as the set of all traces of event to- state, which means reconfiguration of the com- kens generated by the BP. The architecture pro- ponent’s architecture. Also behaviour of a Frac- tocols can be generated automatically from ar- tal component’s controller can be formally de- chitecture description by a CDL compiler.A pro- scribed by means of pLTS/pNet. The result is tocol conformance relation ensures the architec- composition of pLTSs for binding and unbind- ture protocol generates only traces allowed by the ing of each of the component’s functional inter- frame protocol. From dynamic architectures, the faces (one pLTS per one interface) and pLTS for SOFA allows only a dynamic update of compo- starting and stopping the component. nents during a system’s runtime. The update consists in change of implementation (i.e. an archi- 5.2. SOFA and SOFA 2.0 tecture) of the component by a new one. Compat- ibility of the implementations is guaranteed by In the component model SOFA [12], a part of the conformance relation of a protocol of the new SOFA project (SOFtware Appliances), a software architecture and the component’s frame protocol. system is described as a hierarchical composition Recently, the SOFA team is working on of primitive and composite components. A com- a new version of the component model. The ponent is an instance of a template, which is de- component model SOFA 2.0 [5] aims at re- scribed by its frame and architecture. The frame moving several limitations of the original ver- is a “black-box” specification view of the com- sion of SOFA – mainly the lack of support ponent defining its provided and required inter- of dynamic reconfigurations of an architecture, faces. Primitive components are directly imple- well-structured and extensible control parts of mented by described software system – they have components, and multiple communication styles a primitive architecture. The architecture of a among components. composed component is a “grey-box” implementation view, which defines first level of nesting in the component. It describes direct subcompo- 6. Discussion and Future Work nents and their interconnections via interfaces. The connections of the interfaces can be realised The component model proposed in this paper is via connectors, implicitly for simple connections able to handle mobile architectures, unlike the or explicitly. Explicit connectors are described SOFA that supports only a subset of dynamic in a similar way as the components, by a frame architectures (implementing the update opera- and architecture. The connector frame is a set of tion) or the Fractal/Fractive, which does not roles, i.e. interfaces, which are compatible with support components mobility. As is described in A Component Model with Support of Mobile Architectures and Formal Description 23

Section 3.2, the π-calculus provides fitting for- nication between interfaces (i.e. in process W ire malism for description of software systems based from Section 3.2.1) or, alternatively, by using of upon the component model. an asynchronous π-calculus [16]. The proposed semantics of the component The next important extension of the model permits to combine control interfaces presented approach is application of typed and functional interfaces inside individual prim- π-calculus [10, 16], which allows to distinguish itive components where the control actions can types of names. This feature is necessary to for- be invoked by the functional actions, i.e. by mally describe constraints of the type system a system’s business logic represented by busi- of interfaces in behaviour of components. In the ness oriented services. This allows to build sys- component model’s metamodel, the type system tems where functional (business) requirements is defined by instances of entity TypOfInterface imply changes of the systems’ architectures. Re- and its descendants and related entities (see Sec- gardless, in some cases, this feature can lead tion 2.1). to architectural erosion and architectural drift However, the above mentioned modifications [11], i.e. unpredictable evolution of the system’s are out of scope of this paper and a final ver- architecture. For that reason, the component sion of the component model’s formal descrip- model forbids dynamic changes of connections tion including the proposed extensions is part between control interfaces, which reduces archi- of current work. Further ongoing work is re- tecture variability to patterns predetermined at lated to the realisation of a supporting envi- a design-time. Formal description of the com- ronment, which allows integration of the components integrating the control and functional ponent model into software development pro- actions can be compared with the transducer in cesses, including integration of verification tools the Fractal/Fractive approach (see Section 5.1). and implementation support. The idea is to use The next feature of the component model is results of the ArchWare project [1], especially partially independence of a component’s spec- for theorem-proving and model-checking9. We ification from its implementation (see the de- intend to use the Eclipse Modeling Framework scription of entities CompAbstraction and Comp- (EMF) [4, 19] for modeling and code generation Implementation in Section 2.1). This feature is of tools based on the component model and the similar to the SOFA’s component-template re- Eclipse Graphical Modeling Framework (GMF) lationship. It allows to control behaviour of a [18] for developing graphical editors according primary component’s implementation, define a to the rules described in the component model’s composite component’s border that isolates its metamodel (based on EMF). subcomponents, which is called “a membrane” in the Fractal, etc. (for comparison, see Section 7. Conclusion 5.1 and Section 5.2) The attentive reader will have noticed that In this paper, we have presented an approach, the process algebra π-calculus, as it is defined which contributes to specify component-based in Section 3.1 and applied to the formal de- software systems with features of dynamic and scription of behaviour of the component model’s mobile architectures. The proposed component entities in Section 3.2, allows to describe only model splits a software system into primitive synchronous communication. Although, in most and composite components according to decom- cases, we need to apply the component model to posability of its parts, and the components’ distributed software systems with asynchronous functional and control interfaces according to communication. This limitation is a consequence the types of required or provided services. The of the reduction relation’s definition (see Defini- components can be described at different levels tion 6 in Section 3.1). The problem can be solved of abstraction, as their specifications and imple- by proposing of a “buffered” version of commu- mentations.

9 See the tools presented in documents D3.5b and D3.6c at [1]. 24 Marek Rychl´y

Semantics of the component model’s entities [5] T. Bureˇs,P. Hnˇetynka, and F. Pláˇsil. SOFA is formally described by means of the process 2.0: Balancing advanced features in a hierarchi- algebra π-calculus (known as a calculus of mo- cal component model. In Proceedings of SERA bile processes). Formal description of behaviour 2006, Seattle, USA, 2006. IEEE Computer So- ciety. of a whole system can be derived from the vis- [6] J. Králand M. Zemliˇcka.ˇ Autonomous compo- ible behaviour of its primitive components and nents. In SOFSEM 2000: Theory and Practice their compositions and communication, both de- of Informatics, volume 1963 of Lecture Notes in fined at a design-time. The result is a π-calculus Computer Science. Springer, 2000. process, which describes the system’s architec- [7] J. Králand M. Zemliˇcka.ˇ Software confedera- ture, including its evolution and component mo- tions and alliances. In CAiSE Short Paper Pro- bility, and communication behaviour of the sys- ceedings, volume 74 of CEUR Workshop Pro- tem. Thereafter, critical properties of the system ceedings, pages 229–232. CEUR-WS.org, 2003. [8] K.-K. Lau and Z. Wang. A survey of software can be verified by means of π-calculus model component models (second edition). Pre-print checker. CSPP-38, School of Computer Science, Univer- We are currently working on extending our sity of Manchester, Manchester, UK, May 2006. approach to use asynchronous communication [9] V. Mencl. Component definition language. Mas- between components and a type system for their ter’s thesis, Charles University, Prague, 1998. interfaces. Future work is related to integration [10] R. Milner, J. Parrow, and D. Walker. A calculus of the component model into software develop- of mobile processes, parts I and II. Journal of Information and Computation, 100:41–77, Sept. ment processes, including application of veri- 1992. fication tools and implementation support. In [11] D. E. Perry and A. L. Wolf. Foundations for the broader context, the research is a part of the study of software architecture. SIGSOFT a project focused on formal specifications and Software Engineering Notes, 17(4):40–52, Oct. prototyping of distributed information systems. 1992. Acknowledgements This research has [12] F. Pláˇsil, D. B´ılek, and R. Janeˇcek. been supported by the Research Plan No. MSM SOFA/DCUP: Architecture for component 0021630528 “Security-Oriented Research in In- trading and dynamic updating. In 4th Interna- tional Conference on Configurable Distributed formation Technology”. Systems, pages 43–51, Los Alamitos, CA, USA, May 1998. IEEE Computer Society. References [13] M. Rychlý. Towards verification of systems of asynchronous concurrent processes. In Pro- [1] ArchWare project. http://www.arch-ware.org/, ceedings of 9th International Conference Infor- Nov. 2006. mation Systems Implementation and Modelling [2] T. Barros. Formal specification and verification (ISIM’ 06), pages 123–130. MARQ, Apr. 2006. of distributed component systems. PhD thesis, [14] M. Rychlý.Component model with support of Universitéde Nice – INRIA Sophia Antipolis, mobile architectures. In Information Systems Nov. 2005. and Formal Models, pages 55–62. Faculty of Phi- [3] E. Bruneton, T. Coupaye, and J.-B. Stefani. losophy and Science in Opava, Silesian Univer- The Fractal component model. Draft of spec- sity in Opava, Apr. 2007. ification, version 2.0-3, The ObjectWeb Consor- [15] M. Rychlýand J. Zendulka. Distributed in- tium, Feb. 2004. formation system as a system of asynchronous [4] F. Budinsky, D. Steinberg, E. Merks, R. Eller- concurrent processes. In MEMICS 2006 Second sick, and T. J. Grose. Eclipse Modeling Frame- Doctoral Workshop on Mathematical and Engi- work. The Eclipse Series. Addison Wesley Pro- neering Methods in Computer Science. Faculty fessional, Aug. 2003. of Information Technology BUT, 2006. A Component Model with Support of Mobile Architectures and Formal Description 25

[16] D. Sangiorgi and D. Walker. The π-Calculus: [19] The Eclipse Foundation. Eclipse Model- A Theory of Mobile Processes. Cambridge ing Framework Project (EMF). http://www. University Press, First paperback edition, eclipse.org/modeling/emf/, Sept. 2007. Oct. 2003. [20] Uniﬁed Modeling Language, version 1.5. Doc- [17] C. Szyperski. Component Software: Beyond ument formal/03-03-01, Object Management Object-Oriented Programming. Addison Wesley Group, 2003. Professional, second edition, Nov. 2002. [21] S. Viˇsˇnovsk´y. Modeling software components [18] The Eclipse Foundation. Eclipse Graphical using behavior protocols. PhD thesis, Dept. of Modeling Framework (GMF). http://www. Software Engineering, Faculty of Mathematics eclipse.org/gmf/, Sept. 2007. and Physics, Charles University, Prague, 2002. e-Informatica Software Engineering Journal, Volume 3, Issue 1, 2009

Bi-dimensional Composition with Domain Speciﬁc Languages

Anca Daniela Ionita∗, Jacky Estublier∗∗, Thomas Leveque∗∗, Tam Nguyen∗∗

∗University Politehnica of Bucharest, Automatic Control and Computers Faculty ∗∗LIG-IMAG, Grenoble, France [email protected], [email protected], [email protected], [email protected]

Abstract The paper presents how domain modeling may leverage the hierarchical composition, supporting two orthogonal mechanisms (vertical and horizontal) for composing completely autonomous parts. The vertical mechanism is in charge of coordinating heterogeneous components, tools or services at a high level of abstraction, by hiding the technical details. The result of such a composition is called “domain” and represents a high granularity unit of reuse, which may be easily developed in Mélusine framework. A domain is characterised by a Domain Specific Language (DSL) and applications in that domain are defined by models executed by the DSL interpreter. Most often, this is significantly simpler than writing a program using a general purpose language. Unfortunately, DSLs have a narrow scope, while real world applications usually span over many domains, raising the issue of domain (and DSL) composition. To overcome this problem, the horizontal mechanism composes domains at the level of their DSLs, even if they have been independently designed and implemented. The paper presents a model and metamodel perspective of the Mélusine bi-dimensional composition, assisted and automated with the Codèle tool, which allows specification at a high level of abstraction, followed by Java and AspectJ code generation.

1. Introduction they could have been designed and developed independently, i.e. they do not call each other; In the widely adopted Component Based Soft- – Composed parts should be of any nature (ad ware Engineering (CBSE) approach, compo- hoc, legacy, COTS, local or distant); nents know each other, must have compatible – Parts should be allowed to be heterogeneous interfaces and must comply with the constraints i.e. they do not need to follow a particular of the same component model, which reduces model (component model, service etc.); the likelihood of reusing components, and there- – Parts should be reused without having to per- fore the capability to obtain a large variety of form any change in their code. assemblies. Therefore, alternative composition The bi-dimensional composition mechanism mechanisms have to be explored, such as to pre- presented here is intended to be a solution for serve the CBSE advantages (coming from hiding such situations. The idea is to obtain compos- the internal structure and reusing components able elements that are not traditional compo- without any change) but to relax the rigidity of nents, but much larger units, called domains, the composition constraints: which do not expose simple interfaces, but do- – The components or, generally speaking, the main models, representing DSLs for specifying parts, should ignore each other, such that the application models. 28 Anca Daniela Ionita, Jacky Estublier, Thomas Leveque, Tam Nguyen

One of the important problems to be solved richer the semantics embedded in the DSL, the was related to the heterogeneity of components, simpler the models, but the narrower the lan- tools or services that have to be reused. A pos- guage scope. In this context, the main draw- sible solution was to imagine that the part to back of DSLs comes out from the fact that most be composed is wrapped into a “composable el- real life applications usually crosscut several do- ement” [22]. There was also a need to define mains, but they cannot be simply described by a composition mechanism that is not based on selecting a set of independent domain specific the traditional method call, for composing parts models, each one describing how the application that ignore each other, and therefore do not behaves inside each covered domain. call each other. The publish/subscribe mecha- Consequently there is also a need to compose nism [2] was an interesting candidate, since the domains; this is what we call horizontal compo- component that sends events ignores who (if sition and is not based on calling component any) is interested in that event, but the receiver interfaces, but on composing domain DSLs and knows and must declare what it is interested in. models. In contrast to method call, model com- If other events, in other topics, are sent, the re- position does not impose that models stick to ceiver code has to be changed. Moreover, the common interfaces, or know each other, because approach works fine only if the sender is an ac- one can either merge or relate independent con- tive component. A more appropriate solution for cepts. Moreover, model composition allows the our requirements could be given by Aspect Ori- definition of variability points [17], which makes ented Software Development (AOSD) [18], [13], the mechanism more flexible than component which eliminates some of the constraints above, composition. since the sender (the main program) ignores and For building applications spanning different does not call the receiver (the aspects). Unfor- domains, the challenge is to reuse the domain tunately, the aspect knows the internals of the tools, the existing models and the practitioner’s main program, which defeats the encapsulation expertise and know-how; this is far from trivial principle [8] and aspects are defined at a low and is not possible if one creates a new language level of abstraction (the code) [12], [24]. for the composite domain. As discussed above, In our approach, heterogeneity is dealt with for obtaining a non-invasive method, a possibil- by coordinating components, tools or services ity is to adopt an implementation based on AOP from a higher abstraction level; this is what (Aspect Oriented Programming); the composed we call vertical composition and is attained by domains and their models are totally unchanged defining a domain DSL, which can natively spec- and the new code is isolated with the help of ify entities specific to the domain and natively aspects. However, since the AOP technique is grasp the semantics (behaviour) of these entities at code level, performing domain composition within its interpreter; therefore, defining an ap- has proved to be very difficult in practice; the plication in the domain turns out to be the sim- conceptual complexity is increased, due to the ple definition of a model in the DSL language. As necessity to deal with many technical details. usual, each domain is well instrumented with ed- This problem has been treated in many research itors, interpreters, debuggers, analyzers, whose works. The elevation of crosscutting modeling development is rather expensive, even with the concerns to first-class constructs has been done help of the recent environments. Maybe more in having [15], by generating weavers from do- important, the practitioners acquire expertise in main specific descriptions, using ECL, an exten- using these languages and benefit from a large sion of OCL (Object Constraint Language). An- set of existing models, which constitute a part other weaver constructed with domain model- of the company assets. Therefore, a large scale ing concepts is presented in [16], while [25] dis- reuse of these domains is essential for the ap- cusses mappings from a design-level language, plicability of such an approach and is promoted Theme/UML, to an implementation-level lan- through rich DSL semantics. Unfortunately, the guage, AspectJ. Our solution is to clearly sep- Bi-dimensional Composition with Domain Specific Languages 29 arate the specification of the composition from 2.1. Developing Autonomous Domains: its implementation, by designing at a high con- Vertical Composition ceptual level and then generating the code based on aspects. Developing a domain can be performed follow- For managing the complexity in a user ing a top-down or a bottom-up approach. From friendly manner, the user defines the com- a top down perspective, the required function- position using wizards, for selecting among alities of the domain can be specified through a pre-defined properties. Designers and program- model, irrespective of its underlying technology. mers are assisted by the Mélusine engineering Then, one identifies the software artifacts (avail- environment for developing such autonomous able or not) that will be used to implement the domains, for composing them and for creat- expected functionality and make them interop- ing applications based on them [22]. For fa- erate. From a bottom up perspective, the de- cilitating an easier domain composition, by signer already knows the software artifacts that generating Java and AspectJ code, Mélusine may be used for the implementation and will was leveraged by Codèle, a tool that guides have to interoperate; therefore, the designer has the domain expert for performing the compo- to identify the abstract concepts shared by these sition at the conceptual level, as opposed to software artifacts and how they are supposed the programming level. to be consistently managed. Finally, one defines Chapter 2 describes the architecture and the how to coordinate the software artifacts, based principles that stand behind the creation of do- on the behavior of the shared concepts. mains driven by their DSLs and the composition at a high level of abstraction. Chapter 3 presents the metamodels that allow code generation for vertical and horizontal composition. Chapter 4 introduces some details related to the implementation choices, including some mappings for code generation. Chapter 5 compares the approach with other related works and evaluates its usefulness in respect with the domain compositions performed before the availability of the code generation facility offered by Codèle. Figure 1. Bi-dimensional composition mechanism

2. Bi-dimensional Composition In both cases, the composition is called verti- Based on DSLs cal, because the real software components, services or tools are driven based on a high level The alternative composition idea presented model of the application. The model elements above is to create units of reuse that are au- are instances of the shared concepts, which are tonomous (eliminating dependencies on the con- abstractions of the actual software artifacts. The text of use) and composable at an abstract synchronization between these software artifacts level (eliminating dependencies on the imple- and the model means that the evolution of the mentation techniques and details). The solu- model is transformed into actions performed by tion presented here combines two techniques the software artifacts. (see Fig. 1): building autonomous domains using The set of shared concepts and their con- vertical composition and abstract composition sistency constraints constitute a domain model, of domains using horizontal composition, per- to which the application model must conform formed between the abstract concepts of inde- to. In the Model Driven Engineering (MDE) vo- pendent domains, without modifying their code. cabulary, the domain model is the metamodel, 30 Anca Daniela Ionita, Jacky Estublier, Thomas Leveque, Tam Nguyen or a DSL for all the application models for that models are written; from a Domain Modeling domain [12]. point of view, it is a model of the application The application models are interpreted by a domain [12]. Thus, the DSL is the symbiosis virtual machine, built according to the domain of both views, since it is a language in which DSL, which orchestrates the lower level services models are written, but, being Domain Specific, or tools. The domain interpreter is realized by it contains the domain specific concepts, their Java classes that reify the shared concepts of the allowed relationships and their behaviors. The domain model and whose methods implement DSL captures both the abstract syntax and the the behavior of these concepts. In many cases, semantic aspects and it has different purposes: these methods are empty, because most, if not on one hand, it is used to develop models; on the all the behavior is actually delegated to other other hand it is used to develop the interpreter software artifacts, with the help of aspect tech- and the editor of the domain and to compose do- nology. Thus, the domain interpreter, also called mains for enlarging their scope. These activities the domain virtual machine, separates the ab- involve an awareness of the concepts related to stract and conceptual part from the implemen- the semantic domain, which is necessary, for in- tation, creating 3 layers architecture [12]. The stance, for developing the interpreters, but also domains may be autonomously executed, they for composing them, in order to be able to com- do not have dependencies and they may be eas- pose domains. ily used for developing applications.

2.1.1. Domain Speciﬁc Languages in Mélusine

The domain specific languages defined in Mélu- sine are rather small, covering a narrow domain and typically, they are object oriented. As usual, each language description contains two parts: syntax and semantics. The abstract syntax (AS) of the language contains the concepts and rules necessary to define a valid model, while its Se- mantic Domain (SD) is needed to provide the meaning of the abstract syntax concepts. By convention, the abstract syntax is defined by a class diagram, while the Semantic Domain is defined based on the methods pertaining to the Figure 2. DSL of Product domain AS classes, plus some additional classes. The concrete syntax (CS) is provided by a specific editor. 2.1.2. Domain Specific Models The Product domain, one of our intensely reused domains, is presented in the case study of For defining an application, one creates a model this paper. It was developed as a basic version- that is going to be interpreted at run-time. Sup- ing system for various products, characterised pose we use our Product domain to version the by a map of attributes, according to their type; software artefacts produced when developing an the versions are stored in a tree, consisting of application based on the J2EE architecture. A branches and revisions. The Product domain Servlet in this application model conforms to the DSL is shown in Fig. 2 and contains both AS ProductType concept from the Product DSL. elements (light colored) and SD elements (dark In practice, the models can be expressed in colored). several formalisms, and represented in a variety From a Language Engineering point of view, of ways; indeed, models may be defined in UML, this DSL is the definition of a language in which or in Ecore, through generated editors (like in Bi-dimensional Composition with Domain Specific Languages 31 most metamodeling environments), and stored keep the composed domains unchanged. A very in different formats, currently XML based. We strict definition of the horizontal relationship have developed a number of filters, allowing one properties is necessary, such as to be able to to define models and metamodels in these dif- generate most of the AOP code for implement- ferent formalisms, using different environments ing them. This code belongs to the Composition and editors. An example of editor for Product Virtual Machine and is separated from the vir- domain is given in Fig. 3. However, since our tual machines of the composed domains. DSLs are written in Java, models always consist This composition is called horizontal, be- in a set of Java objects at execution. Models, ex- cause it is performed between parts situated at pressed in various formalisms, will be transpar- the same level of abstraction. It can be seen as ently converted to Java objects at the beginning a grey box approach, taking into account that of interpretation phase. In most cases, when do- the only visible part of a domain is its DSL. It mains are narrow enough, the complete models is a non-invasive composition technique, because semantics lies in the DSL. In this case, mod- the components and adapters are hidden and are els are purely structural, and simple editors like reused as they are. The composition result is a those generated by EMF are sufficient. This is new domain model and therefore, a new domain, very important, because it allows non program- with its virtual machine, so that the process may mers to define executable models themselves. If be iterated. As the domains are executable and models require specific semantics, it has to be the composition is performed imperatively, its described in Java. result is immediately executable, even if situated at a high level of abstraction. Model composition is actually performed by creating links between model elements (instances of the DSL classes) so by instantiating the horizontal relationships defined at metamodel level. The choices of links ends may be made either automatically or manually (interactive) with the help of the application designer. Interactive selection is often used, since concepts Figure 3. Model editor for Product domain of existing models may not match to each other perfectly (they may have different names, but the same meaning or have the same name, but 2.2. Abstract Domain Composition: behaviors that partially overlap) and no rule Horizontal Composition can be defined for it. However, it may be a tedious process, especially for composing large It may happen that the development of a new models. In contrast, automatic selection can re- application requires the cooperation of two con- lieve model designer from this burden and is cepts, pertaining to two different domains, and particularly appreciated when models are very realized through two or more software compo- large. The default criterion for automatic selec- nents, services or tools. In this case, the interop- tion can be based on name matching. eration is performed through a horizontal composition between these abstract concepts, and 2.2.1. Horizontal Composition at Metamodel, also through the domain virtual machines, ig- Model and Execution Levels noring the low level components, services and tools used for the implementation. The mech- A real example of domain composition, realized anism consists in establishing relationships be- in our industrial applications, is illustrated in tween concepts of the two DSLs and implement- Fig. 4. On the left, the Activity domain supports ing them using aspect technology, such as to workflow execution, while on the right, the Prod- 32 Anca Daniela Ionita, Jacky Estublier, Thomas Leveque, Tam Nguyen uct domain is meant to store typed products and model, containing two instances of ProductType: their attributes. Each domain has a DSL (see the JMLSpecification and JavaFile. metamodel level). The upper part shows the vis- The Activity model in this example is made of ible concepts (the abstract syntax, in light grey) a simple activity, in which a developer john reused for defining the models with appropriate ceives a software specification spec, realizes the editors; the lower part (in dark grey) shows the activity Programming and produces the source hidden classes, introduced for implementing the code source. However, the developer john may interpreters (the virtual machines) and for hold- need to work on various revisions of his specifi- ing the state of the models during the execution cation or of his source, so the Activity domain process. needs to be composed with the Product domain, for adding the versioning facility. These two domains (Activity and Product) are related together by horizontal relationships at metamodel level, for example, a horizontal relationship is defined between DataType and ProductType and another one between Data and Revision. At model level, a link relates the type of spec – Specification (found in the Activity model) – to JMLSpecifi- cation, instantiated from ProductType (found in the Product model). Another link relates Pro- gram (the type of source) to the JavaFile product type. These two links conform to the relationships defined between the DataType and Product- Type concepts. At execution level, a data from the Activity model, for example DATA_0097 is related to a revision from Product model, for example VERSION-0050 (see Fig. 4). This link conforms to the relationship between Data and Re- vision, situated at metamodel level. Even if in the example above there was a clear correspondence between Specification Figure 4. Composition of Activity from Activity model and JMLSpecification from and Product domains Product Model, in practice, there may be several instances of a metamodel concept on both sides, For each domain, a model is made by instanti- as exemplified in Table 1. For creating the link ating the concepts found in the light colored part at model level, one has to choose among these of the domain DSL. At model level, on the left, instances, such as to select a single one-to-one Figure 4 shows an Activity model, conforming to correspondence. its DSL above. This model describes a very simple software development process, which only contains one activity – Programming; the box Pro- 3. Metamodels for the Bi-dimensional gramming is an instance of the ActivityDefinition Composition concept. Labels on the activity connectors, like spec or source are instances of the DataVariable 3.1. Metamodel for the Vertical concept. These data variables correspond to in- Composition stances of DataType: Specification and Program (not shown in this figure). Similarly, on the right The methods defined in a domain concept are inside of Figure 4, at model level, there is a Product troduced for providing some behavior (see Fig. 5 Bi-dimensional Composition with Domain Specific Languages 33

Table 1. Different mappings of metamodel concepts on their instances at model level (for application development in Java and PHP respectively) Domain Product Activity Metamodel ProductType DataType (Java) (PHP) Use Case Document Use Case Document Requirement Model JML Specification UML Specification Specification Java File PHP File Program URL Bugzilla Vision Project BugReport for the correspondent metamodel elements). In for a set of functionalities defined in a Java in- most cases, only a part (if any) of the behavior is terface, which are ultimately executed by com- implemented inside the method itself, because, ponents/tools representing the services (i.e. im- most often, its functionality involves the execu- plementing its methods). tion of some tools. The notion of Feature has More than one feature can be attached to been defined to provide the code that contains the same method and each feature can address one or more method interceptions and calls the a different concern. The word feature is used in services that actually implement the expected the product line approach to express a possible behavior of that methods. Additionally, a fea- variability that may be attached to a concept. ture can implement a concern attached to that Our approach is a combination of the product method, like security or persistency, which can line intention with the AOP implementation. be an optional behavior, as in product line ap- Moreover, the purpose is to aid software en- proaches. gineers as much as possible, in the design and development of such kind of applications. By using the Codèle tool, which “knows” the metamodel from Figure 5, the software engineer simply creates instances of its concepts (Behav- ior, Interception, Feature, Service etc.) and the tool generates the corresponding code in the Eclipse framework. As well as all Mélusine DSLs, Codèle metamodels are implemented with Java, whereas AspectJ, its aspect-oriented extension, is used for delegating the implementation to dif- Figure 5. Metamodel for the vertical composition ferent tools and/or components (instances of the For the vertical composition, the non-ho- Service concept). mogeneous units of reuse correspond to the generic notion of Service (see Fig. 5). At instan- 3.2. Metamodel for the Horizontal tiation, they may correspond to components, Composition tools, COTS etc. In our Product domain, the persistency service may be supplied either by In other similar approaches, as in model collabo- SQL storage, or by a repository of another ver- ration [26], AOP was mentioned as a possible so- sioning system, like Subversion or CVS; the lution for implementing collaboration templates choice can be done by the client. For the ex- in service oriented architectures (SOA), orches- ample from Figure 4, the method getProducts tration languages or coordination languages. As of the class ProductType is empty and it is its our approach is based on establishing relation- associated feature that delegates the call to a ships, it can also be compared to [1], where the database where actual products are stored. How- properties of AOP concepts are identified (e.g. ever, a feature is not related directly to services, behavioral and structural cross-cutting advices, but through abstract services – an abstraction static and dynamic weaving). Our intention is to 34 Anca Daniela Ionita, Jacky Estublier, Thomas Leveque, Tam Nguyen

Figure 6. Metamodel for the horizontal composition identify such properties at a more abstract level, ior (method) pertaining to the source concept, such as aspects only constitute an implementa- and then some computation, depending on its tion technique. The method we use for defining type: Synchronization, StaticInstantiation, Dy- and generating horizontal compositions between namicInstantiation. Since concepts are reified as domains is similar to transforming UML associ- classes and operations are defined as their meth- ations into Java [14], but using AOP, because ods, a connection may be expressed based on the we are not allowed to change the domain code. AOP mechanism: the method from one side is To provide an effective support for domain captured, allowing for the interaction with the composition, Mélusine requires a specific formal methods from the other side. As a concept may definition and semantics. The metamodel from have many methods, each one being able to par- Fig. 6 shows that domain composition relies on ticipate to one or many connection(s), a horizon- Horizontal Relationship, made of connections. tal relationship may manage many connections. A relationship not only represents a set of communication links between instances, but also ex- 3.2.1. Composition Specific Semantics presses the interaction between them. The execution of an operation from an instance pertaining From the experience gained while defining con- to one side of the relationship has consequences nections, some composition templates have been on the instances from the other side. In Codèle, identified, such that some types of connections such a piece of interaction is called connection may be generalized and generated automati- and is established between a source concept, per- cally. Connections are categorized according to taining to the source domain, and a destina- their purpose: tion concept in the target domain. First, a con- – Synchronization – the most popular kind of nection performs the interception of the behav- connections, modifying the state of the in- Bi-dimensional Composition with Domain Specific Languages 35

stance at the destination end, with respect – Creation (returning a new instance) and to the changes performed for the instance at – Selection (returning an existing instance). the source end; Either to create or to select a destination – Instantiation – in charge of creating an in- instance, one should define some criteria, often stance of the horizontal relationship (a link based on the properties of the source instance. between elements of the models to be com- For example, the mapping function may create a posed) and, eventually, also with the creation destination instance, providing the source name of the instance at the destination end. as parameter (creation mapping) or it may look For establishing a link between two instances for the destination instance with the same name participating in a horizontal relationship, two is- as the source instance (selection mapping). Be- sues must be considered: 1) the moment of cre- sides the two alternatives above, the mapping ating the link, and 2) the alternatives for set- function may adopt two kinds of processes: ting the destination instance. These semantics – Automatic: the destination element is found are taken into account when instantiating HRs automatically, if the searching criterion is at model level (see Fig. 4). provided; 1) The moment of creating the link. Most of- – Interactive: the destination element is found ten, a link is established when creating the in- with human intervention, if the searching cri- stance that must be the origin of the link. These terion is not provided. instances (representing elements of the models For the Automatic case, by default, Codèle to be composed) are created either before ex- supports a searching criterion based on a key ecution (if they conform to AS concepts and attribute, like name or identifier. The default are part of a domain specific model defined for criterion is used if no user-defined searching cri- a domain to be composed) or during the exe- terion is provided. cution (if they conform to concepts introduced The combination of the mapping kinds and for interpreting these models). Therefore, it is processes presented above gives diverse ways to possible to establish links either before or dur- set the destination instance and the dynamic ing the execution; the two situations actually interaction may follow several valid possibili- correspond to the two types of horizontal rela- ties, as also presented in the metamodel from tionships: static and dynamic respectively. For Fig. 6: doing so, the method for creating the source – Automatic.New: the mapping function auto- instance (e.g. the constructor) is captured by matically creates and returns a new instance; the AOP machine and extended with the cre- – Automatic.Selection: the mapping function ation or the reification of the link; for the links automatically returns an existing instance; defined before execution (between elements of – Automatic.Selection.New: the mapping func- domain specific models of the domains to be tion automatically searches for an existing composed) the link is reified when the model instance and, if not found, creates a new one; elements are reified, just before starting the ex- – Interactive.Selection: the destination in- ecution. In our example from Fig. 4, the links stance is selected by a human, and created between models (i.e. before the execu- – Interactive.Selection.New: first, a human tion) are called static, while the links created to tries to select an existent destination in- relate these models at execution are called dy- stance; if he or she does not find anything namic. For example, the link between Specifica- appropriate, it is possible to ask for the cre- tion and JML Specification is static, whereas the ation of a new one. link between DATA_0097 and VERSION-0050 The above options may be valid or not. is dynamic. If a link is created at execution time, all the 2) The alternatives for setting the destina- above options may be used for setting the link tion instance. For deciding the link destination destination. However, if a link is created be- end, there are two kinds of mapping functions: fore execution, the only valid option is Auto- 36 Anca Daniela Ionita, Jacky Estublier, Thomas Leveque, Tam Nguyen matic.Selection, because the link already exists interpretation. Models are represented, at exe- and it must be simply reified. cution, as instances of the AS classes, and are interpreted using the semantic domain. At run time, the model is simply reified as instances 4. Implementation Issues of the interpreter classes and then interpreted. However, during execution, the interpreter mod- 4.1. Implementation Choices ifies/creates/deletes instances of the abstract syntax concepts, and also creates instances of Our approach follows the language/interpreter the DSL concepts corresponding to the semantic technology. However, to be later composable domain. with other domain interpreters, the DSL interpreter must follow conventions in the way the 4.2. Code Generation concepts defined in the metamodel are mapped to the target programming language. The Eclipse mappings currently used in Mélu- First, the target implementation language sine environment for the vertical composition must be able to express the DSL opera- are presented in Table 2. Actually, users never tional semantics. Since the metamodels are see, and even ignore, that AspectJ code is gener- object-oriented, it is convenient to use an ated; for instance, they do not create an AspectJ object-oriented programming language, like project, but simply define and generate a fea- Java or C++, or an executable metamodel- ture associated with a concept. A similar idea is ing language, like Kermeta [25] or XMF (eXe- presented in [30], where Xtend and Xpand lan- cutable Metamodelling Facility) [6]. Executable guages are used for specifying mappings from metamodeling languages allow not only the problem to solution spaces and the code gener- description of the model structure (the ab- ation is considered to be less error-prone than stract syntax), but also of the behavior. Sec- the manual coding. ond, each concept in the metamodel must To implement horizontal relationships in As- be mapped to one class in the target im- pectJ, each horizontal relationship is also trans- plementation language. Third, the target im- formed into an AspectJ code. The mappings to- plementation language must provide support wards Eclipse artifacts used for Mélusine hori- for aspect programming, to allow inserting the zontal composition are indicated in Table 3. code responsible for the composition semantics into the original metamodel implementa- 4.3. Codèle Tool tion (the set of corresponding classes, responsible for model interpretation) without chang- This section introduces Codèle, as an implemen- ing the interpreter. In this context, one de- tation for the composition methodology previ- cided to use Java for implementing our inter- ously presented. For supporting domain compo- preters, together with its aspect-oriented exten- sition, we have developed the Codèle toolbox, in sion, AspectJ. which dedicated editors allow one to: (i) Define Models, defined using the DSL abstract syn- horizontal relationships, (ii) Use horizontal re- tax concepts, are technically reified as Java lationships to define static model composition, classes and then interpreted. This implies that (iii) Use horizontal relationships to define dy- the model is created before execution, while the namic model composition. instances of semantic domain concepts are only From this information, Codèle automatically created during the execution. More precisely, at generates AspectJ captures and the code that design time, the modeler only needs the abstract implements the composition strategy. Imple- syntax concepts for creating a model – referred menting horizontal relationships in AspectJ is to as domain specific model; he or she does not simple. Each connection is transformed into an need to be aware of the concepts related to the AspectJ code that calls a method in a class gen- Bi-dimensional Composition with Domain Specific Languages 37

Table 2. Mapping on Eclipse artifacts for the vertical composition metamodel Metamodel element Eclipse artifact Elements generated inside the artifacts Domain Project Interfaces for the domain management Concept Class Skelton for the methods Behavior Method Empty body by default Feature AspectJ Project The AspectJ aspect and a class for the behavior Abstract service Project Java interface deﬁning the service interface Service Project An interface and an implementation skeleton Interception AspectJ Capture The corresponding AspectJ code

Table 3. Mapping between horizontal composition concepts and Eclipse artifacts Metamodel element Eclipse artifact Elements generated inside the artifacts Domain Project Predefined interfaces and classes Concept Class None Behavior Method None – an AspectJ file containing the code for all the interceptions HorizontalRelationship AJ Class and Java classes – a Java file for each instantiation connections – a Java file for each synchronization connections Lines in the AspectJ file for the interception, and Interception AspectJ Capture a Java file for the connection code erated by Codèle; users never “see” it. In practice, the code for horizontal relationships semantics represents about 15% of the total code. Under a unified graphical interface, Codèle implements different subsystems: – Relationships Editor, which is responsible to create horizontal relationships, according to the properties presented above; see an example in Fig. 7, for defining a relationship between DataType from Activity domain, and ProductType from Product domain; – Captures Generator, which generates As- pectJ code, and creates a Java class in which the user can define the connection semantics; – Dynamic Model Composition Editor, for dynamic link creation and life cycle; – Static Model Composition Editor for the composition of two models, in their abstract form; see an example in Fig. 8. In our example, the DataType – Product- Type horizontal relationship has been selected, for which one displays the corresponding instances, like Specification in the Activity do- Figure 7. Defining horizontal relationships main, and JMLSpecification or JavaFile in the at metamodel level Product domain. As this horizontal relationship relationship. Otherwise, they would have been has been declared Static, the developer is asked selected automatically, at run time. The bottom to provide the pairs of model entities that must panel lists the pairs that have been defined. For be linked together, according to that horizontal example, the data type called Program in the 38 Anca Daniela Ionita, Jacky Estublier, Thomas Leveque, Tam Nguyen

Activity domain is now related to JavaFile in chronization relationships [11] or weaving two the Product domain. The system finds this in- models/metamodels, without changing their formation by introspecting the models and is in structures. The second mechanism is interesting charge of creating these relationships at model because it is possible to compose models and level. metamodels and still use their existent tools. According to the theme of research, model/metamodel composition is approached in three major areas: Model Management, Aspect Oriented Modeling and Metamodeling. Model Management is a topic born in the MDE (Model Driven Engineering) context. This community is interested in platforms manipulat- ing and managing models, focusing on generic operators to be applied on models, which can be divided in three groups: Figure 8. Defining static links at model level match [3, 4], relate [21], compare [20] – for dis- • Mélusine system, including the domain com- covering correspondences between models; position technology, was developed in 2000 and merge [21], [20], [7], compose [3], weaving [7] • was used in a number of applications, both aca- – for integrating models and demic and industrial. A little less than one mil- sewing [7] – for relating models without chang- • lion lines were developed for this system, and ing their structure. dozens of domain compositions were performed. Several platforms have been developed, like The work reported in this paper started with AMMA [28], Rondo [10], EOL [23] and MO- an analysis of these domain compositions, with MENT [19]. One can qualify these Model Man- the goal to find recurring concepts and patterns, agement approaches as heavyweight. and ended in the development of the Codèle tool. Aspect Oriented Modeling (AOM) applies the Since then, Codèle is integrated in different envi- separation of concern principle of AOP in the ronments. In some environments, like FOCA [27] modeling phase. Weaving consists in compos- where domains are manually composed, Codèle ing aspect models to a base model. The rela- is used only for model composition. In other sys- tionship between aspect model and base model tems, like Mélusine, Codèle is fully used, on a is relative. A model can be both an aspect and daily basis. the base; thus, two kinds of weaving have been identified: aspect/base weaving (called asymmet- ric), and base/base weaving (called symmetric). 5. Evaluation of the Composition The first one is borrowed from AOP and usu- Approach ally uses a lightweight composition mechanism, while the second one is inspired from SOP (Sub- 5.1. Related Works ject Oriented Programming) and uses a heavyweight mechanism. Theme/UML [7] is an ap- The works on model/metamodel composition proach merging both kinds of weaving; the com- can be classified according to several criteria: position between the base models (called sub- the composition mechanism and the theme of ject) is done with two kinds of composition re- research. According to the composition mecha- lationships: merge or override. Merge integrates nism, these works could be split in two major a subject with another one, while override re- categories: the heavyweight composition mech- places an existing subject with a new one. In anism, which consists in model and metamodel all cases, these strategies change the composed merging [29], [23], [20]; and the lightweight model structure. The aspects in Theme/UML are mechanism, which involves establishing syn- designed in terms of aspect templates. Bi-dimensional Composition with Domain Specific Languages 39

Metamodelling also treats model compo- above took into account the specificities of Mélu- sitions, supported by metamodeling environ- sine domains. Consequently, the composition we ments, like XMF (eXecutable Metamodelling realized is specific for this situation, as opposed Facility) [6] or GME (Generic Modeling Envi- to other approaches, which try to provide mech- ronment) [9]. XMF has a purpose that is simi- anisms for composing heterogeneous models in lar to ours – lightweight model composition con- general contexts, generally without specifying sisting of composing and executing models con- how to implement them precisely. forming to different metamodels. This is pos- The technique used at each composition level sible through synchronized mappings, written is different. At code level one uses AOP tech- in XSync – a specific language of XMF, based nique; at model and metamodel levels one es- on actions. Unfortunately, the metamodels also tablishes relationships. The main reason for this have to be written in a specific language – choice was to compose domains without chang- XCore, which is an extension of MOF. There- ing their models or the associated tools and en- fore, we would not be able to reuse our meta- vironments. models (implemented in Java) nor our models, The elaboration of metamodels that support nor use AOP technique – which is a central re- code generation in Codèle tool was possible af- quirement for model and metamodel reuse. ter years of performing Mélusine domain com- GME environment also supports the compo- positions. This experience also led to the defini- sition of models conforming to the same meta- tion of a methodology for developing horizon- model (using so-called references) and to differ- tal relationships, described in [11]. Moreover, ent metamodels (using union and inheritance). through trials and errors, one found recurring However, it allows the creation of a composite patterns of code for defining vertical and hori- metamodel, which may be used for defining new zontal relationships and it was possible to iden- models; there is no possibility to reuse the exist- tify some of their functional and non functional ing models “as-is” and to keep the metamodels characteristics. Codèle embodies and formalizes unchanged – an important requirement for our this knowledge through simple panels, such that domain composition approach. users “only” need to write code for the non stan- The canonical scheme for model composi- dard functionalities. Practice showed that, in av- tion proposed in [5] uses a weaving model, con- erage, more than half of the code is generated, sisting in correspondences between model ele- in an error prone manner, managing the low ments. Then, several transformations based on level technical code – including AOP captures, ATL (ATLAS Transformation Language) are aspect generation and so on. The user’s added used for obtaining the composite model. The code fully ignores the generated one and the ex- composition semantics resides in these transfor- istence of AOP; it describes the added function- mations. The weaving model may also be ex- ality at the logical level. Experience with Codèle tended for creating a specific composition, using has shown a dramatic simplification for writing AMW (Atlas Model Weaver). This facility could relationships, and the elimination of the most be used for defining our horizontal relationships; difficult bugs; there are also some cases where however, our purpose was to obtain a composi- the generated code was sufficient, allowing appli- tion tool based on wizards, which is easier to cation composition without any programming. learn and only contains the concepts specific for However, many other non-functional charac- our composition approach. teristics could be identified and generated in the same way, and Codèle can (should) be extended 5.2. Specificities for Mélusine to support them. We have also discovered that Composition some, if not most, non-functional characteristics cannot be defined as a domain (security, In order to make the domain composition task performance, transaction etc.), and therefore as simple as possible, the metamodels presented these non-functional properties cannot be added 40 Anca Daniela Ionita, Jacky Estublier, Thomas Leveque, Tam Nguyen through horizontal relationships. For these prop- compositions can be performed by domain ex- erties, we have developed another technique, perts, not necessarily by highly trained technical called model annotation, described in [27]. experts, as it would be the case if directly using AOP techniques.

6. Conclusion References

The division of applications in parts can be per- [1] E. Barra Zavaleta, G. Génova Fuster, and formed by reusing large functional areas, called J. Llorens Morillo. An approach to aspect mod- domains, which are primary elements for divid- elling with uml 2.0. In Proceedings of the UML ing the problem in parts, and atoms on which 2004 Workshop on Aspect-Oriented modeling, Lisbon, Portugal, 2004. our composition technique is applied. [2] L. Bass, P. Clements, and R. Kazman. Software A domain is usually implemented by reusing Architecture in Practice. Addison-Wesley, 2003. existing parts, found on the market or inside [3] P. Bernstein. Applying model management to the company, which are components or tools of classical meta data problems. In Proceedings various size and nature. We call vertical com- of the Conference on Innovative Database Re- position the technique which consists in relat- search (CIDR), Asilomar, CA, USA, 2003. ing the abstract elements found in the domain [4] G. Brunet, M. Chechik, S. Easterbrook, S. Ne- model, with the existing components found in jati, N. Niu, and M. Sabetzadeh. A manifesto for model merging. In Proceedings of the company. Reuse imposes that vertical re- the 2006 international workshop on Global inte- lationships are implemented, without changing grated model management, pages 5–12, Shang- the domain concepts, or the existing compo- hai, China, 2006. ACM. nents. In our approach, one develops indepen- [5] J. Bézivin, S. Bouzitouna, M. D. D. Fabro, M.-P. dent and autonomous domains, which become Gervais, F. Jouault, D. Kolovos, I. Kurtev, and the primary units for reuse, whose interfaces are R. F. Paige. A canonical scheme for model com- their domain models (DSLs). position. In Proceedings of the European Confer- ence in Model Driven Architecture (EC-MDA), Domain composition is performed by com- Bilbao, Spain, 2006. posing their DSLs, without any change in [6] T. Clark and al. Applied metamodelling – their abstract syntax or semantics. This is a foundation for language driven development called horizontal composition, defining relation- version 0.1. Xactium, Editor, 2004. ships between modeling elements pertaining [7] S. Clarke. Extending standard UML with model to the composed domains. In this way, the composition semantics. Science of Computer tools/environments in charge of editing, analyz- Programming, 44(1):71–100, 2002. ing and executing the models, as well as the [8] T. Dave. Reflective software engineering – from MOPS to AOSD. Journal of Object Technology, knowledge of practitioners, are kept unchanged. 1(4), 2002. Tools, environments and models can be reused [9] J. Davis. GME: the generic modeling environ- “as-is” and thus they can continue to be used ment. In Proceedings of the Conference on Ob- by the existing applications that rely on them, ject Oriented Programming Systems Languages which is a critical property in real operational and Applications (OOPSLA ’03), Anaheim, CA, contexts. USA, 2003. An important goal of our approach was to [10] M. Didonet Del Fabro and F. Jouault. Model transformation and weaving in the amma plat- raise the level of abstraction and the granularity form. In Proceedings of the Workshop on Gener- level at which large applications are designed, ative and Transformational Techniques in Soft- decomposed and recomposed. Moreover, these ware Engineering (GTTSE), Braga, Portugal, large elements are highly reusable, because the 2005. composition only needs to “see” their abstract [11] J. Estublier, A. D. Ionita, and G. Vega. Re- models, not their implementation. Finally, by lationships for domain reuse and composition. relating domain concepts using wizards, most Bi-dimensional Composition with Domain Specific Languages 41

Journal of Research and Practice in Informa- [22] T. Le-Anh, J. Estublier, and J. Villalobos. tion Technology, 38(4):135–162, 2006. Multi-level composition for software federa- [12] J. Estublier, G. Vega, and A. Ionita. Composing tions. In Proceedings of the SC’2003 Conference, domain-specific languages for wide-scope soft- Warsaw, Poland, April (2003). IEEE Computer ware engineering applications. In Proceedings Society Press. of the MoDELS/UML Conference, pages 69–83, [23] S. Melnik, E. Rahm, and P. A. Bernstein. Jamaica, 2005. Lecture Notes in Computer Sci- Rondo: A programming platform for generic ence. model management. In Proceedings of the Inter- [13] R. Filman, T. Elrad, S. Clarke, and M. Ak- national Conference on Special Interest Group sit. Aspect-Oriented Software Development. on Management of Data (SIGMOD), San Diego, Addison-Wesley, ISBN10: 0321219767, 2004. California, June, 2003. [14] G. Génova, C. Ruiz del Castillo, and J. Lloréns. [24] M. Monga. Aspect-oriented programming as Mapping UML associations into Java code. model driven evolution. In Proceedings of the Journal of Object Technology, 2(5):135–162, linking aspect technology and evolution (LATE) 2003. workshop, Chicago, 2005. [15] J. Gray, T. Bapty, S. Neema, D. Schmidt, [25] P.-A. Muller, F. Fleurey, and J.-M. Jézéquel. A. Gokhale, and N. B. An approach for support- Weaving executability into object-oriented ing aspect-oriented domain modeling. In Pro- meta-languages. In Proceedings of the MoD- ceedings of GPCE. LNCS 2830, Springer Verlag, ELS/UML Conference, Jamaica, 2005. Lecture 2003. Notes in Computer Science. [16] W. Ho, J.-M. Jezequel, F. Pennaneac’h, [26] A. Occello, O. Casile, A. Dery-Pinna, and and N. Plouzeau. A toolkit for weaving M. Riveill. Making domain-specific models col- aspect-oriented UML designs. In Proceed- laborate. In Proceedings of the 7th OOPSLA ings of the First International Conference on Workshop on Domain-Specific Modeling, Mon- Aspect-Oriented Software Development, pages tréal, Canada, 2007. 99–105, Enschede, The Netherlands, 2002. [27] G. Pedraza and J. Estublier. An extensible ser- [17] A. D. Ionita, J. Estublier, and G. Vega. Vari- vice orchestration framework through concern ations in model-based composition of domains. composition. intl workshop on non-functionnal In Proceedings of the Software and Service Vari- properties in domain specific languages. In Pro- ability Management Workshop, Helsinki, Fin- ceedings of the NFPDML conference, Toulouse land, April 2007. France, 2008. [18] G. Kiczales, J. Lamping, A. Mendhekar, [28] T. Reiter and al. Model integration through C. Maeda, C. Lopes, J.-M. Loingtier, and mega operations. In Proceedings of the J. Irwin. Aspect-oriented programming. In Workshop on Model-driven Web Engineering Proceedings of the European Conference on (MDWE), Sydney, 2005. Object-Oriented Programming, pages 220–242, [29] M. Sabetzadeh and S. Easterbrook. Easter- 1997. brook: An algebraic framework for merging in- [19] D. Kolovos, R. Paige, and F. Polack. Eclipse complete and inconsistent views. In Proceedings development tools for epsilon. In Proceedings of the 13th IEEE International Requirements of the Eclipse Summit Europe, Eclipse Modeling Engineering Conference, pages 306–318, 2005. Symposium, Esslingen, Germany, 2006. [30] M. Voelter and I. Groher. Product line [20] D. Kolovos, R. Paige, and F. Polack. Merging implementation using aspect-oriented and models with the epsilon merging language (eml). model-driven software development. In In Proceedings of MoDELS’06, pages 215–229. Proceedings of the 11th International Software LNCS 4199, 2006. Prouct Line Conference (SPLC), Kyoto, Japan, [21] I. Kurtev and M. Didonet Del Fabro. A DSL 2007. for definition of model composition operators. In Proceedings of the Models and Aspects Work- shop at ECOOP, Nantes, France, 2006. e-Informatica Software Engineering Journal, Volume 3, Issue 1, 2009

Aspect-Oriented Change Realizations and Their Interaction

Valentino Vranić∗, Radoslav Menkyna∗, Michal Bebjak∗, Peter Dolog∗∗

∗Institute of Informatics and Software Engineering, Faculty of Informatics and Information Technologies, Slovak University of Technology in Bratislava, Slovakia ∗∗Department of Computer Science, Aalborg University, Denmark [email protected], [email protected], [email protected], [email protected]

Abstract With aspect-oriented programming, changes can be treated explicitly and directly at the programming language level. An approach to aspect-oriented change realization based on a two-level change type model is presented in this paper. In this approach, aspect-oriented change realizations are mainly based on aspect-oriented design patterns or themselves constitute pattern-like forms in connection to which domain independent change types can be identified. However, it is more convenient to plan changes in a domain specific manner. Domain specific change types can be seen as subtypes of generally applicable change types. These relationships can be maintained in a form of a catalog. Some changes can actually affect existing aspect-oriented change realizations, which can be solved by adapting the existing change implementation or by implementing an aspect-oriented change realization of the existing change without having to modify its source code. As demonstrated partially by the approach evaluation, the problem of change interaction may be avoided to a large extent by using appropriate aspect-oriented development tools, but for a large number of changes, dependencies between them have to be tracked. Constructing partial feature models in which changes are represented by variable features is sufficient to discover indirect change dependencies that may lead to change interaction.

1. Introduction Customization of web applications represents a prominent example of that kind. In Change realization consumes enormous effort customization, a general application is being and time during software evolution. Once imple- adapted to the client’s needs by a series of mented, changes get lost in the code. While in- changes. With each new version of the base ap- dividual code modifications are usually tracked plication, all the changes have to be applied to by a version control tool, the logic of a change it. In many occasions, the difference between as a whole vanishes without a proper support in the new and old application does not affect the the programming language itself. structure of changes, so if changes have been im- By its capability to separate crosscutting plemented using aspect-oriented programming, concerns, aspect-oriented programming enables they can be simply included into the new appli- to deal with change explicitly and directly at cation build without any additional effort. programming language level. Changes imple- Even conventionally realized changes may in- mented this way are pluggable and — to the teract, i.e. they may be mutually dependent or great extent — reapplicable to similar applica- some change realizations may depend on the tions, such as applications from the same prod- parts of the underlying system affected by other uct line. change realizations. This is even more remark- 44 Valentino Vranić, Radoslav Menkyna, Michal Bebjak, Peter Dolog able in aspect-oriented change realization due to vision is given to the affiliate who referred the pervasiveness of aspect-oriented programming sale. A general affiliate marketing software en- as such. ables to manage affiliates, track sales referred We have already reported briefly our initial by these affiliates, and compute provisions for work in change realization using aspect-oriented referred sales. It is also able to send notifications programming [1]. In this paper1, we present about new sales, signed up affiliates, etc. our improved view of the approach to change The general affiliate marketing software has realization based on a two-level change type to be adapted (customized), which involves a model. Section 2 presents our approach to series of changes. We will assume the affiliate aspect-oriented change realization. Section 3 de- marketing software is written in Java, so we can scribes briefly the change types we have discov- use AspectJ, the most popular aspect-oriented ered so far in the web application domain. Sec- language, which is based on Java, to implement tion 4 discusses how to deal with a change of a some of these changes. change. Section 5 proposes a feature modeling In the AspectJ style of aspect-oriented pro- based approach of dealing with change interac- gramming, the crosscutting concerns are cap- tion. Section 6 describes the approach evalua- tured in units called aspects. Aspects may con- tion and outlooks for tool support. Section 7 tain fields and methods much the same way the discusses related work. Section 8 presents con- usual Java classes do, but what makes possi- clusions and directions of further work. ble for them to affect other code are genuine aspect-oriented constructs, namely: pointcuts, which specify the places in the code to be af- 2. Changes as Crosscutting fected, advices, which implement the additional Requirements behavior before, after, or instead of the captured join point (a well-defined place in the program A change is initiated by a change request made execution) — most often method calls or execu- by a user or some other stakeholder. Change tions — and inter-type declarations, which en- requests are specified in domain notions simi- able introduction of new members into types, as larly as initial requirements are. A change re- well as introduction of compilation warnings and quest tends to be focused, but it often consists of errors. several different — though usually interrelated — requirements that specify actual changes to 2.1. Domain Specific Changes be realized. By decomposing a change request into individual changes and by abstracting the One of the changes of the affiliate marketing essence out of each such change while generaliz- software would be adding a backup SMTP server ing it at the same time, a change type applicable to ensure delivery of the notifications to users. to a range of the applications that belong to the Each time the affiliate marketing software needs same domain can be defined. to send a notification, it creates an instance of We will present our approach by a series of the SMTPServer class which handles the con- examples on a common scenario2. Suppose a nection to the SMTP server. merchant who runs his online music shop pur- An SMTP server is a kind of a resource that chases a general affiliate marketing software [11] needs to be backed up, so in general, the type to advertise at third party web sites denoted of the change we are talking about could be as affiliates. In a simplified schema of affiliate denoted as Introducing Resource Backup. This marketing, a customer visits an affiliate’s site change type is still expressed in a domain spe- which refers him to the merchant’s site. When cific way. We can clearly identify a crosscutting he buys something from the merchant, the pro- concern of maintaining a backup resource that

1 This paper represents an extended version of our paper presented at CEE-SET 2008 [28]. 2 This is an adapted scenario published in our earlier work [1]. Aspect-Oriented Change Realizations and Their Interaction 45 has to be activated if the original one fails and it actually performs a class exchange. This implement this change in a single aspect without idea can be generalized and domain details ab- modifying the original code: stracted out of it bringing us to the Class public class SMTPServerM extends SMTPServer { Exchange change type [1] which is based on ... the Cuckoo’s Egg aspect-oriented design pat- } tern [20]: ... public aspect SMTPServerBackupA { public class AnotherClass extends MyClass { public pointcut SMTPServerConstructor(URL url, ... String user, } String password): ... call(SMTPServer.new (..)) && args(url, user, public aspect MyClassSwapper { password); public pointcut myConstructors(): SMTPServer around(URL url, String user, call(MyClass.new ()); String password): Object around(): myConstructors() SMTPServerConstructor(url, user, password) { { return new AnotherClass(); return getSMTPServerBackup(proceed(url, user, } password)); } } private SMTPServer getSMTPServerBackup(SMTPServer obj) 2.3. Applying a Change Type { if (obj.isConnected()) { It would be beneficial if the developer could get a return obj; hint on using the Cuckoo’s Egg pattern based on } else { the information that a resource backup had to return new SMTPServerM(obj.getUrl(), obj.getUser(), be introduced. This could be achieved by main- obj.getPassword()); taining a catalog of changes in which each do- } main specific change type would be defined as a } specialization of one or more generally applica- } ble changes. The around() advice captures constructor When determining a change type to be ap- calls of the SMTPServer class and their ar- plied, a developer chooses a particular change guments. This kind of advice takes complete request, identifies individual changes in it, and control over the captured join point and its determines their type. Figure 1 shows an exam- return clause, which is used in this example ple situation. Domain specific changes of the D1 to control the type of the SMTP server be- and D2 type have been identified in the Change ing returned. The policy is implemented in the Request 1. From the previously identified and getSMTPServerBackup() method: if the original cataloged relationships between change types we SMTP server can’t be connected to, a backup would know their generally applicable change SMTP server class SMTPServerM instance is types are G1 and G2. created and returned. A generally applicable change type can be a We can also have another aspect — say kind of an aspect-oriented design pattern (con- SMTPServerBackupB — intended for another sider G2 and AO Pattern 2). A domain specific application configuration that would implement change realization can also be complemented a different backup policy or simply instantiate a by an aspect-oriented design pattern (or several different backup SMTP server. ones), which is expressed by an association between them (consider D1 and AO Pattern 1). 2.2. Generally Applicable Changes Each generally applicable change has a known domain independent code scheme (G2’s Looking at this code and leaving aside SMTP code scheme is omitted from the figure). This servers and resources altogether, we notice that code scheme has to be adapted to the context 46 Valentino Vranić, Radoslav Menkyna, Michal Bebjak, Peter Dolog

Figure 1. Generally applicable and domain specific changes of a particular domain specific change, which – Introducing Resource Backup: Class Ex- may be seen as a kind of refinement (consider change. D1 Code and D2 Code). We have already described Introducing Re- source Backup and the corresponding generally applicable change, Class Exchange. Here, we will 3. Catalog of Changes briefly describe the rest of the domain specific change types we identified in the web applica- To support the process of change selection, tion domain along with the corresponding gen- the catalog of changes is needed in which the erally applicable changes. The generally appli- generalization–specialization relationships be- cable change types are described where they are tween change types would be explicitly estab- first mentioned to make sequential reading of lished. The following list sums up these relation- this section easier. In a real catalog of changes, ships between change types we have identified in each change type would be described separately. the web application domain (the domain specific change type is introduced first): 3.1. Integration Changes – One Way Integration: Performing Action Af- ter Event, Web applications often have to be integrated – Two Way Integration: Performing Action Af- with other systems. Suppose that in our exter Event, ample the merchant wants to integrate the af- – Adding Column to Grid: Performing Action filiate marketing software with the third party After Event, newsletter which he uses. Every affiliate should – Removing Column from Grid: Method Sub- be a member of the newsletter. When an affili- stitution, ate signs up to the affiliate marketing software, – Altering Column Presentation in Grid: he should be signed up to the newsletter, too. Method Substitution, Upon deleting his account, the affiliate should – Adding Fields to Form: Enumeration Modifi- be removed from the newsletter, too. cation with Additional Return Value Check- This is a typical example of the One Way ing/Modification, Integration change type [1]. Its essence is the – Removing Fields from Form: Additional Re- one way notification: the integrating application turn Value Checking/Modification, notifies the integrated application of relevant – Introducing Additional Constraint on Fields: events. In our case, such events are the affiliate Additional Parameter Checking or Perform- sign-up and affiliate account deletion. ing Action After Event, Such integration corresponds to the Per- – Introducing User Rights Management: Bor- forming Action After Event change type [1]. der Control with Method Substitution, Since events are actually represented by meth- – User Interface Restriction: Additional Re- ods, the desired action can be implemented in turn Value Checking/Modifications, an after advice: Aspect-Oriented Change Realizations and Their Interaction 47 public aspect PerformActionAfterEvent { and banners packages. The calls to these meth- pointcut methodCalls(TargetClass t, int a ):...; ods can be viewed as a region prohibited to after( / captured arguments /): ∗ ∗ the restricted administrator. The Border Con- methodCalls( / captured arguments /) ∗ ∗ { trol design pattern [20] enables to partition an performAction( / captured arguments /); application into a series of regions implemented ∗ ∗ } as pointcuts that can later be operated on by private void performAction( / arguments /) ∗ ∗ { advices [1]: / action logic / ∗ ∗ pointcut prohibitedRegion(): } (within(application.Proxy) } && call(void . (..))) ∗ ∗ || (within(application.campaigns. +) The after advice executes after the captured && call(void . (..))) ∗ ∗ method calls. The actual action is implemented || within(application.banners. +) as the performAction() method called by the ad- || call(void Affiliate . decline (..)) || call(void Affiliate . delete (..)); vice. To implement the one way integration, in the What we actually need is to substitute the after advice we will make a post to the newslet- calls to the methods in the region with our own ter sign-up/sign-out script and pass it the e-mail code that will let the original methods execute address and name of the newly signed-up or only if the current user has sufficient rights. This deleted affiliate. We can seamlessly combine can be achieved by applying the Method Substi- multiple one way integrations to integrate with tution change type which is based on an around several systems. advice that enables to change or completely dis- The Two Way Integration change type can able the execution of methods. The following be seen as a double One Way Integration. A typ- pointcut captures all method calls of the method ical example of such a change is data synchro- called method() belonging to the TargetClass nization (e.g., synchronization of user accounts) class: across multiple systems. When a user changes pointcut allmethodCalls(TargetClass t, int a): his profile in one of the systems, these changes call(ReturnType TargetClass.method(..)) && should be visible in all of them. In our exam- target(t) && args(a); ple, introducing a forum for affiliates with syn- Note that we capture method calls, not ex- chronized user accounts for affiliate convenience ecutions, which gives us the flexibility in con- would represent a Two Way Integration. straining the method substitution logic by the context of the method call. The call() pointcut 3.2. Introducing User Rights captures all the calls of TargetClass.method(), Management the target() pointcut is used to capture the reference to the target object, and the method ar- In our affiliate marketing application, the mar- guments (if we need them) are captured by an keting is managed by several co-workers with args() pointcut. In the example code, we assume different roles. Therefore, its database has to method() has one integer argument and capture be updated from an administrator account with it with this pointcut. limited permissions. A restricted administrator The following example captures the should not be able to decline or delete affiliates, method() calls made within the control flow nor modify the advertising campaigns and ban- of any of the CallingClass methods: ners that have been integrated with the web sites pointcut specificmethodCalls(TargetClass t, int a): of affiliates. This is an instance of the Introduc- call(ReturnType TargetClass.method(a)) ing User Rights Management change type. && target(t) && args(a) && cflow(call( CallingClass . (..))); Suppose all the methods for managing cam- ∗ ∗ paigns and banners are located in the campaigns 48 Valentino Vranić, Radoslav Menkyna, Michal Bebjak, Peter Dolog

This embraces the calls made directly in these In the around advice, we assign the original re- methods, but also any of the method() calls turn value to the private attribute of the as- made further in the methods called directly or pect. Afterwards, this value is processed by the indirectly by the CallingClass methods. processOutput() method and the result is re- By making an around advice on the specified turned by the around advice. method call capturing pointcut, we can create a new logic of the method to be substituted: 3.4. Grid Display Changes public aspect MethodSubstition { pointcut methodCalls(TargetClass t, int a): . . .; It is often necessary to modify the way data ReturnType around(TargetClass t, int a): are displayed or inserted. In web applications, methodCalls(t, a) { data are often displayed in grids, and data in- if (. . .) { ...} // the new method logic put is usually realized via forms. Grids usually else display the content of a database table or colla- proceed(t, a); tion of data from multiple tables directly. Typi- } cal changes required on grid are adding columns, } removing them, and modifying their presentation. A grid that is going to be modified must be 3.3. User Interface Restriction implemented either as some kind of a reusable component or generated by row and cell pro- It is quite annoying when a user sees, but can’t cessing methods. If the grid is hard coded for a access some options due to user rights restric- specific view, it is difficult or even impossible to tions. This requires a User Interface Restriction modify it using aspect-oriented techniques. change type to be applied. We have created a If the grid is implemented as a data driven similar situation in our example by a previous component, we just have to modify the data change implementation that introduced the re- passed to the grid. This corresponds to the Ad- stricted administrator (see Sect. 3.2). Since the ditional Return Value Checking/Modification restricted administrator can’t access advertising change (see Sect. 3.3). If the grid is not a data campaigns and banners, he shouldn’t see them driven component, it has to be provided at least in menu either. with the methods for processing rows and cells. Menu items are retrieved by a method and Adding Column to Grid can be performed af- all we have to do to remove the banners and ter an event of displaying the existing columns campaigns items is to modify the return value of of the grid which brings us to the Performing this method. This may be achieved by applying Action After Event change type (see Sect. 3.1). a Additional Return Value Checking/Modifica- Note that the database has to reflect the change, tion change which checks or modifies a method too. Removing Column from Grid requires a return value using an around advice: conditional execution of the method that dis- public aspect AdditionalReturnValueProcessing { plays cells, which may be realized as a Method pointcut methodCalls(TargetClass t, int a): . . .; Substitution change (see Sect. 3.2). private ReturnType retValue; Alterations of a grid are often necessary due ReturnType around(): to software localization. For example, in Japan methodCalls(/ captured arguments /){ ∗ ∗ retValue = proceed(/ captured arguments /); and Hungary, in contrast to most other coun- ∗ ∗ processOutput(/ captured arguments /); tries, the surname is placed before the given ∗ ∗ return retValue; names. The Altering Column Presentation in } Grid change type requires preprocessing of all private void processOutput(/ arguments /){ ∗ ∗ // processing logic the data to be displayed in a grid before actually } displaying them. This may be easily achieved by } modifying the way the grid cells are rendered, Aspect-Oriented Change Realizations and Their Interaction 49 which may be implemented again as a Method that holds the actual (usually integer) value and Substitution (see Sect. 3.2): its name. We add a new enumeration value by public aspect ChangeUserNameDisplay { introducing the corresponding static field: pointcut displayCellCalls(String name, String value): public aspect NewEnumType { call(void UserTable.displayCell (..)) || public static EnumValueType args(name, value); EnumType.NEWVALUE = around(String name, String value): new EnumValueType(10, ""); displayCellCalls (name, value) { } if (name == "") { The fields in a form are generated according ... // display the modified column to the enumeration values. The list of enumera- } else { proceed(name, value); tion values is typically accessible via a method } provided by it. This method has to be addressed } by an Additional Return Value Checking/Mod- } ification change. For Removing Fields from Form, an Ad- 3.5. Input Form Changes ditional Return Value Checking/Modification change is sufficient. Actually, the enumeration Similarly to tables, forms are often subject to value would still be included in the enumeration, modifications. Users often want to add or re- but this would not affect the form generation. move fields from forms or pose additional con- If we want to introduce additional vali- straints on their input fields. Note that to be dations on form input fields in an applica- possible to modify forms using aspect-oriented tion without a built-in validation, which consti- programming they may not be hard coded in tutes an Introducing Additional Constraint on HTML, but generated by a method. Typically Fields change, an Additional Parameter Check- they are generated from a list of fields imple- ing change can be applied to methods that pro- mented by an enumeration. cess values submitted by the form. This change Going back to our example, assume that the enables to introduce an additional validation or merchant wants to know the genre of the music constraint on method arguments. For this, we which is promoted by his affiliates. We need to have to specify a pointcut that will capture all add the genre field to the generic affiliate sign-up the calls of the affected methods along with their form and his profile form to acquire the informa- context similarly as in Sect. 3.2. Their argu- tion about the genre to be promoted at different ments will be checked by the check() method affiliate web sites. This is a change of the Adding called from within an around advice which will Fields to Form type. To display the required in- throw WrongParamsException if they are not formation, we need to modify the affiliate table correct: of the merchant panel to display genre in a new public aspect AdditionalParameterChecking { column. This can be realized by applying the pointcut methodCalls(TargetClass t, int a): . . .; ReturnType around(/ arguments /) throws ∗ ∗ Enumeration Modification change type to add WrongParamsException: the genre field along with already mentioned Ad- methodCalls(/ arguments /){ ∗ ∗ check(/ arguments /); ditional Return Value Checking/Modification in ∗ ∗ return proceed(/ arguments /); order to modify the list of fields being returned ∗ ∗ } (see Sect. 3.3). void check(/ arguments /) throws ∗ ∗ The realization of the Enumeration Modifi- WrongParamsException { cation change type depends on the enumeration if (arg1 != ) throw new WrongParamsException(); type implementation. Enumeration types are of- } ten represented as classes with a static field for } each enumeration value. A single enumeration Adding a new validator to an application value type is represented as a class with a field that already has a built-in validation is realized 50 Valentino Vranić, Radoslav Menkyna, Michal Bebjak, Peter Dolog by simply including it in the list of validators. of a change using aspect-oriented programming This can be done by implementing the Perform- and without modifying the original change is ing Action After Event change (see Sect. 3.1), interesting mainly if it leads to separation of which would add the validator to the list of val- another crosscutting concern. idators after the list initialization.

5. Capturing Change Interaction by 4. Changing a Change Feature Models

Sooner or later there will be a need for a change Some change realizations can interact: they may whose realization will affect some of the already be mutually dependent or some change realiza- applied changes. There are two possibilities to tions may depend on the parts of the underly- deal with this situation: a new change can be im- ing system affected by other change realizations. plemented separately using aspect-oriented pro- With increasing number of changes, change in- gramming or the affected change source code teraction can easily escalate into a serious prob- could be modified directly. Either way, the lem: serious as feature interaction. changes remain separate from the rest of the ap- Change realizations in the sense of the application. proach presented so far actually resemble fea- The possibility to implement a change of tures as coherent pieces of functionality. More- a change using aspect-oriented programming over, they are virtually pluggable and as such and without modifying the original change is represent variable features. This brings us to given by the aspect-oriented programming lan- feature modeling as an appropriate technique guage capabilities. Consider, for example, ad- for managing variability in software develop- vices in AspectJ. They are unnamed, so can’t ment including variability among changes. This be referred to directly. The primitive pointcut section will show how to model aspect-oriented adviceexecution(), which captures execution changes using feature modeling. of all advices, can be restricted by the within() pointcut to a given aspect, but if an aspect con- 5.1. Representing Change Realizations tains several advices, advices have to be an- notated and accessed by the @annotation() There are several feature modeling nota- pointcut, which was impossible in AspectJ ver- tions [26] of which we will stick to a widely sions that existed before Java was extended with accepted and simple Czarnecki–Eisenecker basic annotations. notation [5]. Further in this section, we will show An interesting consequence of aspect-oriented how feature modeling can be used to manage change realization is the separation of cross- change interaction with elements of the notation cutting concerns in the application which im- explained as needed. proves its modularity (and thus makes easier Aspect-oriented change realizations can be further changes) and may be seen as a kind of perceived as variable features that extend an aspect-oriented refactoring. For example, in our existing system. Fig. 2 shows the change re- affiliate marketing application, the integration alizations from our affiliate marketing scenario with a newsletter — identified as a kind of One a feature diagram. A feature diagram is com- Way Integration — actually was a separation monly represented as a tree whose root repre- of integration connection, which may be seen sents a concept being modeled. Our concept is as a concern of its own. Even if these once our affiliate marketing software. All the changes separated concerns are further maintained by are modeled as optional features (marked by an direct source code modification, the important empty circle ended edges) that can but do not thing is that they remain separate from the have to be included in a feature configuration — rest of the application. Implementing a change known also as concept instance — for it to be Aspect-Oriented Change Realizations and Their Interaction 51

Affiliate Marketing

SMTP Server SMTP Server Newsletter Restricted User Name Backup A Backup B Sign Up Administrator Account Display Change

Hide Options Unavailable to Restricted Administrator

Figure 2. Affiliate marketing software change realizations in a feature diagram valid. Recall adding a backup SMTP server dis- pendant feature semantics with respect to the cussed in Sect. 2.1. We considered a possibility implementation of the software being changed. of having another realization of this change, but This is beyond feature modeling capabilities. we don’t want both realizations simultaneously. Indirect feature dependencies may also rep- In the feature diagram, this is expressed by alter- resent potential change interactions. Additional native features (marked by an arc), so no Affili- dependencies among changes can be discovered ate Marketing instance will contain both SMTP by exploring the software to which the changes Server Backup A and SMTP Server Backup B. are introduced. For this, it is necessary to have A change realization can be meaningful only a feature model of the software itself, which is in the context of another change realization. In seldom the case. Constructing a complete fea- other words, such a change realization requires ture model can be too costly with respect to ex- the other change realization. In our scenario, pected benefits for change interaction identifica- hiding options unavailable to a restricted ad- tion. However, only a part of the feature model ministrator makes sense only if we introduced that actually contains edges that connect the a restricted administrator account (see Sect. 3.3 features under consideration is needed in order and 3.2). Thus, the Hide Options Unavailable to reveal indirect dependencies among them. to Restricted Administrator feature is a subfeature of the Restricted Administrator Account 5.3. Partial Feature Model Construction feature. For a subfeature to be included in a concept instance its parent feature must be in- The process of constructing partial feature cluded, too. model is based on the feature model in which aspect-oriented change realizations are repre- 5.2. Identifying Direct Change sented by variable features that extend an ex- Interactions isting system represented as a concept (see Sect. 5.1). Direct change interactions can be identified in a The concept node in this case is an abstract feature diagram with change realizations mod- representation of the underlying software sys- eled as features of the affected software con- tem. Potential dependencies of the change real- cept. Each dependency among features repre- izations are hidden inside of it. In order to reveal sents a potential change interaction. A direct them, we must factor out concrete features from change interaction may occur among alterna- the concept. Starting at the features that rep- tive features or a feature and its subfeatures: resent change realizations (leaves) we proceed such changes may affect the common join points. bottom up trying to identify their parent fea- In our affiliate marketing scenario, alternative tures until related changes are not grouped in SMTP backup server change realizations are an common subtrees. Figure 3 depicts this process. example of such changes. Determining whether The process will be demonstrated on Yon- changes really interact requires analysis of de- Ban, a student project management system de- 52 Valentino Vranić, Radoslav Menkyna, Michal Bebjak, Peter Dolog

[Application Concept]

[Feature A]

[Change 1] [Feature E]

[Feature B] [Feature D]

[Change 2] [Change 3] [Feature C] [Change 6]

[Change4 ] [Change 5]

Figure 3. Constructing a partial feature model veloped at Slovak University of Technology. We the features that represent them either. The con- will consider the following changes in YonBan cept of the system as such is marked as open (in- and their respective realizations indicated by dicated by square brackets), which means that generally applicable change types: new variable subfeatures are expected at it. This – Telephone Number Validating (realized as is so because we show only a part of the analyzed Performing Action After Event): to validate system knowing there are other features there. a telephone number the user has entered; Following this initial stage, we attempt to – Telephone Number Formatting (realized as identify parent features of the change realiza- Additional Return Value Checking/Modifi- tion features as the features of the underly- cation): to format a telephone number by ing system that are affected by them. Fig- adding country prefix; ure 5 shows such changes identified in our case. – Project Registration Statistics (realized as We found that Name Formatting affects the One Way Integration): to gain statistic in- Name Entering feature. Project Registration formation about the project registrations; Statistic and Project Registration Constraint – Project Registration Constraint (realized as change User Registration. Telephone Number Additional Parameter Checking/Modifica- Formatting and Telephone Number Validating tion): to check whether the student who are changes of Telephone Number Entering. Ex- wants to register a project has a valid e-mail ception Logging affects all the features in the address in his profile; application, so it remains a direct feature of the – Exception Logging (realized as Performing concept. All these newly identified features are Action After Event): to log the exceptions open because we are aware of the incompleteness thrown during the program execution; of their subfeature sets. – Name Formatting (realized as Method Sub- We continue this process until we are able to stitution): to change the way how student identify parent features or until all the changes names are formatted. are found in a common subtree of the feature These change realizations are captured in the diagram, whichever comes first. In our example, initial feature diagram presented Fig. 4. Since we reached this stage within the following — there was no relevant information about direct and thus last — iteration which is presented in dependencies among changes during their speci- Fig. 6: we realized that Telephone Number En- fication, there are no direct dependencies among tering is a part of User Registration. Aspect-Oriented Change Realizations and Their Interaction 53

[YonBan]

Exception Name Project Project Telephone Telephone Logging Formatting Registration Registration Number Number Constraint Statistics Formatting Validating

Figure 4. Initial stage of the YonBan partial feature model construction

[YonBan]

Exception [Name [User [Telephone Number Logging Entering] Registration] Entering]

Name Project Project Telephone Telephone Formatting Registration Registration Number Number Constraint Statistics Formatting Validating

Figure 5. Identifying parent features in YonBan partial feature model construction

[YonBan]

Exception [User Logging Registration]

[Name Project Project [Telephone Number Entering] Registration Registration Entering] Constraint Statistics

Name Telephone Telephone Formatting Number Number Formatting Validating

Figure 6. The final YonBan partial feature model 5.4. Dependency Evaluation so we have to analyze these, too. Speaking in terms of change implementation, the code that Dependencies among change realization features implements the parent feature altered by one of in a partial feature model constitute potential the sibling change features can be dependent on change realization interactions. A careful analy- the code altered by another sibling change fea- sis of the feature model can reveal dependencies ture or vice versa. The feature model points us we have overlooked during its construction. to the locations of potential interaction. Sibling features (direct subfeatures of the In our example, we have a partial feature same parent feature) are potentially interdepen- model (recall Fig. 6) and we understand the dent. This problem can occur also among the way the changes should be implemented based features that are — to say so — indirect siblings, on their type (see Sect. 5.3). Project Registra- 54 Valentino Vranić, Radoslav Menkyna, Michal Bebjak, Peter Dolog tion Constraint and Project Registration Statis- agrams by allowing them to be directed acyclic tic change are both direct subfeatures of User graphs instead of just trees [10]. Registration. The two aspects that would im- Some dependencies between changes may ex- plement these changes would advise the same hibit only recommending character, i.e. whether project registration method, and this indeed they are expected to be included or not included can lead to interaction. In such cases, prece- together, but their application remains mean- dence of aspects should be set (in AspectJ, ingful either way. An example of this are fea- dominates inter-type declaration enables this). tures that belong to the same change request. Another possible problem in this particular situ- Again, feature modeling can be used to model ation is that the Project Registration Constraint such dependencies with so-called default depen- change can disable the execution of the project dency rules that may also be represented by log- registration method. If the Project Registra- ical expressions [27]. tion Statistic change would use an execution() pointcut, everything would be all right. On the other hand, if the Project Registration Statistic 6. Evaluation and Tool Support change would use a call() pointcut, the regis- Outlooks tration statistic advice would be still executed even when the registration method would not We have successfully applied the aspect-oriented be executed. This would cause an undesirable approach to change realization to introduce system behavior where also registrations can- changes into YonBan, the student project man- celed by Project Registration Constraint would agement system discussed in previous section. be counted in statistic. The probability of a mis- YonBan is based on J2EE, Spring, Hibernate, take when a call() pointcut is used instead of and Acegi frameworks. The YonBan architecture the execution() pointcut is higher if the Project is based on the Inversion of Control principle Registration Statistic change would be added and Model-View-Controller pattern. first. We implemented all the changes listed in Telephone Number Formatting and Tele- Sect. 5.3. No original code of the system had to phone Number Validating are another exam- be modified. Except in the case of project reg- ple of direct subfeatures. In this case, the as- istration statistics and project registration con- pects that would implement these changes ap- straint, which where well separated from the rest ply to different join points, so apparently, no of the code, other changes would require exten- interaction should occur. However, a detailed sive code modifications if they have had been look uncovers that Telephone Number Format- implemented the conventional way. ting change alters the value which the Telephone As we discussed in Sect 5.4, we encountered Number Validating change has to validate. This one change interaction: between the telephone introduces a kind of logical dependency and to number formatting and validating. These two this point the two changes interact. For instance, changes are interrelated — they would probably altering Telephone Number Formatting to for- be part of one change request — so it comes as mat the number in a different way may require no surprise they affect the same method. How- adapting Telephone Number Validating. ever, no intervention was needed in the actual We saw that the dependencies between implementation. changes could be as complex as feature depen- We managed to implement the changes easily dencies in feature modeling and accordingly rep- even without a dedicated tool, but to cope with resented by feature diagrams. For dependencies a large number of changes, such a tool may be- appearing among features without a common come crucial. Even general aspect-oriented pro- parent, additional constraints expressed as log- gramming support tools — usually integrated ical expressions [27] could be used. These con- with development environments — may be of straints can be partly embedded into feature di- some help in this. AJDT (AspectJ Development Aspect-Oriented Change Realizations and Their Interaction 55

Tools) for Eclipse is a prominent example of such However, a version model for aspect dependency a tool. AJDT shows whether a particular code management [23] with appropriate aspect model is affected by advices, the list of join points af- that enables to control aspect recursion and fected by each advice, and the order of advice stratification [2] would be needed as well. execution, which all are important to track when We tend to regard changes as concerns, multiple changes affect the same code. Advices which is similar to the approach of facilitating that do not affect any join point are reported configurability by separation of concerns in the in compilation warnings, which may help detect source code [9]. This approach actually enables a pointcuts invalidated by direct modifications of kind of aspect-oriented programming on top of a the application base code such as identifier name versioning system. Parts of the code that belong changes or changes in method arguments. to one concern need to be marked manually in A dedicated tool could provide a much more the code. This enables to easily plug in or out sophisticated support. A change implementation concerns. However, the major drawback, besides can consist of several aspects, classes, and in- having to manually mark the parts of concerns, terfaces, commonly denoted as types. The tool is that — unlike in aspect-oriented programming should keep a track of all the parts of a change. — concerns remain tangled in code. Some types may be shared among changes, so Others have explored several issues gener- the tool should enable simple inclusion and ex- ally related to our work, but none of these clusion of changes. This is related to change in- works aims at actual capturing changes by as- teraction, which can be addressed by feature pects. These issues include database schema evo- modeling as we described in the previous sec- lution with aspects [12] or aspect-oriented ex- tion. tensions of business processes and web services with crosscutting concerns of reliability, security, and transactions [3]. Also, an increased 7. Related Work changeability of components implemented using aspect-oriented programming [17], [18], [22] and The work presented in this paper is based aspect-oriented programming with the frame on our initial efforts related to aspect-oriented technology [19], as well as enhanced reusabil- change control [8] in which we related our ap- ity and evolvability of design patterns achieved proach to change-based approaches in version by using generic aspect-oriented languages to control. We concluded that the problem with implement them [24] have been reported. The change-based approaches that could be solved impact of changes implemented by aspects has by aspect-oriented programming is the lack of been studied using slicing in concern graphs [15]. programming language awareness in change re- While we do see potential of aspect-orien- alizations. tation for configuration and reconfiguration of In our work on the evolution of web applica- applications, our current work does not aim at tions based on aspect-oriented design patterns automatic adaptation in application evolution, and pattern-like forms [1], we reported the fun- such as event triggered evolutionary actions [21], damentals of aspect-oriented change realizations evolution based on active rules [6], adaptation based on the two level model of domain specific of languages instead of software systems [16], and generally applicable change types, as well as or as an alternative to version model based four particular change types: Class Exchange, context-awareness [7], [13]. Performing Action After Event, and One/Two Way Integration. Applying feature modeling to maintain 8. Conclusions and Further Work change dependencies (see Sect. 4) is similar to constraints and preferences proposed in SIO In this paper, we have described our approach software configuration management system [4]. to change realization using aspect-oriented pro- 56 Valentino Vranić, Radoslav Menkyna, Michal Bebjak, Peter Dolog gramming and proposed a feature modeling By applying the multi-paradigm design with based approach of dealing with change interac- feature modeling [27] to select the generally ap- tion. We deal with changes at two levels dis- plicable changes (understood as paradigms) ap- tinguishing between domain specific and gen- propriate to given application specific changes erally applicable change types. We described we may avoid the need for catalogs of domain change types specific to web application domain specific change types or we can even use it to along with corresponding generally applicable develop them. This constitutes the main course changes. We also discussed consequences of hav- of our further research. ing to implement a change of a change. Acknowledgements The work was sup- The approach does not require exclusive- ported by the Scientific Grant Agency of Slovak ness in its application: a part of the changes Republic (VEGA) grant No. VG 1/0508/09. can be realized in a traditional way. In fact, the approach is not appropriate for realization of all changes, and some of them can’t be re- References alized by it at all. This is due to a techni- [1] M. Bebjak, V. Vranić, and P. Dolog. Evolu- cal limitation given by the capabilities of the tion of web applications with aspect-oriented underlying aspect-oriented language or frame- design patterns. In M. Brambilla and work. Although some work towards addressing E. Mendes, editors, Proc. of ICWE 2007 Work- method-level constructs such as loops has been shops, 2nd International Workshop on Adap- reported [14], this is still uncommon practice. tation and Evolution in Web Systems Engi- What is more important is that relying on the neering, AEWSE 2007, in conjunction with 7th International Conference on Web Engineering, inner details of methods could easily compro- ICWE 2007, pages 80–86, Como, Italy, July mise the portability of changes across the ver- 2007. sions since the stability of method bodies be- [2] E. Bodden, F. Forster, and F. Steimann. Avoid- tween versions is questionable. ing infinite recursion with stratified aspects. In Change interaction can, of course, be an- R. Hirschfeld et al., editors, Proc. of NODe alyzed in code, but it would be very benefi- 2006, LNI P-88, pages 49–64, Erfurt, Germany, cial to deal with it already during modeling. Sept. 2006. GI. [3] A. Charfi, B. Schmeling, A. Heizenreder, and We showed that feature modeling can success- M. Mezini. Reliable, secure, and transacted fully be applied whereby change realizations web service compositions with AO4BPEL. In would be modeled as variable features of the 4th IEEE European Conf. on Web Services application concept. Based on such a model, (ECOWS 2006), pages 23–34, Zürich, Switzer- change dependencies could be tracked through land, Dec. 2006. IEEE Computer Society. feature dependencies. In the absence of a fea- [4] R. Conradi and B. Westfechtel. Version models ture model of the application under change, for software configuration management. ACM which is often the case, a partial feature model Computing Surveys, 30(2):232–282, June 1998. [5] K. Czarnecki and U. W. Eisenecker. Generative can be developed at far less cost to serve the Programing: Methods, Tools, and Applications. same purpose. Addison-Wesley, 2000. For further evaluation, it would be interest- [6] F. Daniel, M. Matera, and G. Pozzi. Combin- ing to develop catalogs of domain specific change ing conceptual modeling and active rules for the types of other domains like service-oriented ar- design of adaptive web applications. In Work- chitecture for which we have a suitable applica- shop Proc. of 6th Int. Conf. on Web Engineering tion developed in Java available [25]. Although (ICWE 2006), New York, NY, USA, 2006. ACM Press. the evaluation of the approach has shown the [7] F. Dantas, T. Batista, N. Cacho, and A. Gar- approach can be applied even without a dedi- cia. Towards aspect-oriented programming for cated tool support, we believe that tool support context-aware systems: A comparative study. In is important in dealing with change interaction, Proc. of 1st International Workshop on Soft- especially if their number is high. ware Engineering for Pervasive Computing Ap- Aspect-Oriented Change Realizations and Their Interaction 57

plications, Systems, and Environments, SEP- 1491–1497, Santa Fe, New Mexico, USA, 2005. CASE’07, Minneapolis, USA, May 2007. IEEE. ACM. [8] P. Dolog, V. Vranić, and M. Bieliková. Rep- [18] J. Li, A. A. Kvale, and R. Conradi. A case study resenting change by aspect. ACM SIGPLAN on improving changeability of COTS-based sys- Notices, 36(12):77–83, Dec. 2001. tem using aspect-oriented programming. Jour- [9] Z. Fazekas. Facilitating configurability by sepa- nal of Information Science and Engineering, ration of concerns in the source code. Journal of 22(2):375–390, Mar. 2006. Computing and Information Technology (CIT), [19] N. Loughran, A. Rashid, W. Zhang, and 13(3):195–210, Sept. 2005. S. Jarzabek. Supporting product line evolu- [10] R. Filkorn and P. Návrat. An approach for tion with framed aspects. In Workshop on As- integrating analysis patterns and feature dia- pects, Componentsand Patterns for Infrastruc- grams into model driven architecture. In P. Voj- ture Software (held with AOSD 2004, Interna- táš, M. Bieliková, and B. Charron-Bost, edi- tional Conference on Aspect-Oriented Software tors, Proc. 31st Conference on Current Trends Development), Lancaster, UK, Mar. 2004. in Theory and Practice of Informatics (SOF- [20] R. Miles. AspectJ Cookbook. O’Reilly, 2004. SEM 2005), LNCS 3381, Liptovský Jan, Slo- [21] F. Molina-Ortiz, N. Medina-Medina, and vakia, Jan. 2005. Springer. L. García-Cabrera. An author tool based on [11] S. Goldschmidt, S. Junghagen, and U. Harris. SEM-HP for the creation and evolution of adap- Strategic Affiliate Marketing. Edward Elgar tive hypermedia systems. In Workshop Proc. Publishing, 2003. of 6th Int. Conf. on Web Engineering (ICWE [12] R. Green and A. Rashid. An aspect-oriented 2006), New York, NY, USA, 2006. ACM Press. framework for schema evolution in [22] O. Papapetrou and G. A. Papadopoulos. object-oriented databases. In Proc. of the Aspect-oriented programming for a component Workshop on Aspects, Components and based real life application: A case study. In 2004 Patterns for Infrastructure Software (in ACM Symposium on Applied Computing, pages conjunction with AOSD 2002), Enschede, 1554–1558, Nicosia, Cyprus, 2004. ACM. Netherlands, Apr. 2002. [23] E. Pulvermüller, A. Speck, and J. O. Coplien. [13] M. Grossniklaus and M. C. Norrie. An A version model for aspect dependency man- object-oriented version model for context-aware agement. In Proc. of 3rd Int. Conf. on Gener- data management. In M. Weske, M.-S. Hacid, ative and Component-Based Software Engineer- and C. Godart, editors, Proc. of 8th Interna- ing (GCSE 2001), LNCS 2186, pages 70–79, Er- tional Conference on Web Information Systems furt, Germany, Sept. 2001. Springer. Engineering, WISE 2007, LNCS 4831, Nancy, [24] T. Rho and G. Kniesel. Independent evolu- France, Dec. 2007. Springer. tion of design patterns and application logic with [14] B. Harbulot and J. R. Gurd. A join point for generic aspects — a case study. Technical Re- loops in AspectJ. In Proc. of 5th International port IAI-TR-2006-4, University of Bonn, Bonn, Conference on Aspect-Oriented Software Devel- Germany, Apr. 2006. opment, AOSD 2006, pages 63–74, Bonn, Ger- [25] V. Rozinajová, M. Braun, P. Návrat, and many, 2006. ACM. M. Bieliková. Bridging the gap between [15] S. Khan and A. Rashid. Analysing require- service-oriented and object-oriented approach in ments dependencies and change impact using information systems development. In D. Avi- concern slicing. In Proc. of Aspects, Depen- son, G. M. Kasper, B. Pernici, I. Ramos, dencies, and Interactions Workshop (affiliated and D. Roode, editors, Proc. of IFIP 20th to ECOOP 2008), Nantes, France, July 2006. World Computer Congress, TC 8, Information [16] J. Kollár, J. Porubän, P. Václavík, Systems, Milano, Italy, Sept. 2008. Springer J. Bandáková, and M. Forgáč. Functional Boston. approach to the adaptation of languages [26] V. Vranić. Reconciling feature model- instead of software systems. Computer Science ing: A feature modeling metamodel. In and Information Systems Journal (ComSIS), M. Weske and P. Liggsmeyer, editors, Proc. 4(2), Dec. 2007. of 5th Annual International Conference on [17] A. A. Kvale, J. Li, and R. Conradi. A case Object-Oriented and Internet-Based Technolo- study on building COTS-based system us- gies, Concepts, and Applications for a Net- ing aspect-oriented programming. In 2005 worked World (Net.ObjectDays 2004), LNCS ACM Symposium on Applied Computing, pages 58 Valentino Vranić, Radoslav Menkyna, Michal Bebjak, Peter Dolog

3263, pages 122–137, Erfurt, Germany, Sept. pect-oriented change realization. In Proc. of 2004. Springer. 3rd IFIP TC2 Central and East European Con- [27] V. Vranić. Multi-paradigm design with feature ference on Software Engineering Techniques modeling. Computer Science and Information CEE-SET 2008, LNCS, Brno, Czech Republic, Systems Journal (ComSIS), 2(1):79–102, June 2008. 2005. [28] V. Vranić, M. Bebjak, R. Menkyna, and P. Dolog. Developing applications with as- e-Informatica Software Engineering Journal, Volume 3, Issue 1, 2009

Two Hemisphere Model Driven Approach for Generation of UML Class Diagram in the Context of MDA

Oksana Nikiforova∗

∗Faculty of Computer Science and Information Technology, Riga Technical University [email protected]

Abstract The Model Driven Architecture (MDA) separates the system business aspects from the system implementation aspects on a specific technology platform. MDA proposes a software development process in which the key notions are models and model transformation, where the input models are platform independent and the output models are platform specific and can be transformed into a format that is executable. In this paper principles of MDA and model transformations are applied for generation of UML class diagram from two hemisphere model, which is presented in the form of business process model related with concept model. Two hemisphere model is developed for the problem domain concerned with an application for driving school and UML class diagram is generated using the approach offered in the paper.

1. Introduction of abstraction. Nowadays MDA tools support translation of platform independent system pre- One of the modern research goals in software sentation into software components and code engineering is to find a software development generation and researchers try to “raise” it as process, which would provide fast and quali- high as possible to fulfill the main statement tative software development. Most of currently of the MDA [13]. One of the most important proposed methodologies and approaches try to and problematic stages in MDA realization is make the development process easier and still derivation of PIM elements from a problem do- more qualitative. For achievement of this goal main and PIM construction in the form that the role of explicit models becomes more and is suitable for the PSM. It is necessary to find more important. Lately, the most popular ap- the way to develop PIM using formal represen- proach is Model Driven Architecture [18]. MDA tation, so far keeping the level of abstraction is the central component in the OMG’s strat- high enough. PIM model should represent sys- egy for maximizing return on investment, reduc- tem static and dynamic aspects. Class diagram ing development complexity and future-proofing shows static structure of the developed system. against technological change [29]. MDA tools But UML is a modelling language and does not do not support the complete code-generation have all the possibilities to specify context and capabilities from the initial business infor- the way of modelling, which is always required mation, and the most problematic stage is to be defined in a methodology. Therefore, the system modelling based on knowledge about construction of class diagram has to be based problem domain [22]. on well defined rules for its elements generation The main idea of MDA is to achieve for- from the problem domain model presented in the mal system representation at the highest level suitable form. 60 Oksana Nikiforova

Class diagram discussed in the paper con- on these applications. Section 5 concludes on the tains classes, relations among them, attributes research presented in the paper and gives several and operations of classes. Dynamic aspects, remarks on author’s future work in the area of which are another meaningful component of sys- model transformations. tem presentation at the platform independent level is not the object of the current research. To obtain the class diagram the initial busi- 2. Main Principles of Model Driven ness knowledge represented with two hemisphere Architecture model may be used. The transformation of this model into class diagram is discussed in the pa- MDA introduces an approach to system specifi- per. The transformation should be defined in cation that separates the views on three different formal way and should be acceptable for use in layers of abstraction: high level specification of transformation tool. The structure of a transfor- how system is working (Computation Indepen- mation tool is discussed in [13] with definition of dent Model or CIM), the specification of system models, necessary for transformation and transi- functionality, i.e. of what the system is expected tion between these models. Transformation tools to do (Platform Independent Model or PIM) and take a source model as an input, and create the specification of the implementation of that another model, called target model, as an out- functionality on a specific technology platform put [13]. Therefore, implementation of transfor- (Platform Specific Model or PSM). In OMG mation needs well-defined set of notational ele- Model Driven Architecture these models are pri- ments of source and target models and definition mary artefacts in software developments process for transformation of elements of one model into and all the activities are concentrated on going elements of another one. The paper describes from CIM to PIM, from PIM to PSM and from class diagram development based on two hemi- PSM to code. The very important role there is sphere model. Therefore, according to Kleppe’s played by the quality of PIM, i.e. its capability definition source model is defined in terms of two to adequately represent system under develop- hemisphere model (business process and concept ment [18]. model) and target model is defined in terms of UML class diagram [28]. The structure of the 2.1. Models within the MDA paper is as follows. The next section presents main principles of model driven architecture, de- CIM presents the requirements for the system fines models to be developed within it, describes to be modelled in a platform independent model, transformations to be formalized to be able to describing the situation in which the system will develop the tool for support of that transforma- be used. Such a model is sometimes called a do- tions. Section 3 presents an information about main model or a business model. It may hide using of two hemisphere model to fulfil the main much or all information about the use of au- statement of MDA corresponds to formal trans- tomated data processing systems. A CIM is a formations between models. An essence of two model of a system that shows the system in hemisphere model is shown in several aspects the environment in which it will operate, and of its historical evolution and refinement and thus it helps in presenting exactly what the sys- transformations of two hemisphere model into tem is expected to do. It is useful, not only as elements of class diagram are described accord- an aid to understanding a problem, but also ing to the present state of author’s investiga- as a source of a shared vocabulary for use in tions. The transformations presented in the pa- other models [18]. PIM is describing that part per are verified in section 4, where the approach of information system specification, which is offered in the paper is applied for several prob- close to code, but is independent of platform lem domains. Due to limitations on volume of specific features. PIM is representing informa- the paper the section shows only general results tion system in that way that will remain un- Two Hemisphere Model Driven Approach for Generation of UML Class Diagram in the Context of MDA 61 changed on any programming platform. Never- An MDA idea is promising – raising up the theless PIM usually is accommodated to spe- level of abstraction, on which systems are devel- cific architecture style [18]. Platform Indepen- oped, we could develop more complex systems dent Model is the model that resolves busi- more qualitatively. Core of solution domain de- ness requirements through purely problem-space velopment strategies focuses on the transforma- terms and it does not include platform specific tion of system model from the aspects of busi- concepts. The PIM provides formal specifica- ness level into the application level (Transfor- tion of the structure and functionality of the mation 2 in Fig. 1). The main idea of MDA is to system that abstracts away technical details. achieve formal system representation at the as There has to be rules for PIM checking if it high level of abstraction as possible. Nowadays defines all problem domain concepts in the cor- MDA tools support translation of solution el- rect way [18]. Platform Specific Model is a so- ements into software components (Transforma- lution model that resolves both functional and tion 3 in Fig. 1) and code generation (Trans- non-functional requirements through the use of formation 4 in Fig. 1), and researchers try to platform specific concepts. The platform def- “raise” it up as high as possible to fulfil the main inition can include wide range of conceptions statement of the MDA [18]. in the context of MDA. It can be operation Transformations 1 and Transformation 2 are system, programming language, any technolog- defined within different solutions [33], [36], [16], ical platform, such as CORBA, Java 2 Enter- [30], [12], but there is no any solution, where prise Edition, also any specific vendor platform complete transformation CIM PIMinitial → → (for example, Microsoft .NET) [18]. Platform PIMrefined would be defined [22]. can imply any of engineering and technologi- One of the most important and problematic cal characteristics, which are not important for stages in MDA realization is derivation of PIM program unit fundamental business functional- elements from a problem domain, and PIM con- ity [18]. struction in the form that is suitable for the PSM. Solutions that are focused on Transfor- 2.2. Model Transformations mation 1 can’t insure that a PIM contains all within the MDA the necessary information, and that the presentation of the PIM is formal enough to be able Generally, system model refinement and evolu- to transform it into the correct PSM, that is to tion in the framework of MDA is presented in support already the Transformation 3 [22]. It is Figure 1. necessary to find the way to develop PIM using CIM presents specification of the system at formal representation, so far keeping the level problem domain level and can be transformed of abstraction high enough, i.e. to implement into initial elements of PIM. PIM provides for- Transformation 2 in formal way. The central ele- mal specification of the system structure and ment of PIM is the presentation of system struc- functions that abstracts from technical details, ture, which would be independent from further and thus presents solution aspects of the sys- implementation and usually is presented in the tem to be developed. Development of the solu- form of class diagram in UML notation [28], as tion domain model is based on derivation of all well as adequate presentation of system dynam- the necessary elements from problem domain de- ics. Different modelling tools are used for that. scription (Transformation 1 in Fig. 1). The PIM The paper discusses the class diagram develop- received as a result of Transformation 1 has to ment aspects, which satisfies the main statement be refined (Transformation 2 in Fig. 1) to get of MDA and are based on transformation from a form suitable for PSM generation, i.e. PIM- two hemisphere model into elements of class di- refined enables model transformation (Transfor- agram defined in UML. mation 3 in Fig. 1) to the platform level, named Currently, transformations between UML Software Domain in Figure 1. models are still a subject of intensive investiga- 62 Oksana Nikiforova

Definition of MDA principles in terms of 2HMD Definition of MDA principles in terms of MDA approach for software architecture development Problem Specification Presentation of problem domain elements Process model and conceptual model of CIM domain level suitable for further transformation problem domain

Transformation 1: Derivation of solution Derivation of automated processes from process elements at business level from problem model and definition of structure of their information domain flow based on concepts in conceptual model

Business Presentation (and required transformations) Selected processes and their PIM initial level of solution elements at business level information flow structure

Transformation 2: Transformation of solution Solution Application of 2HMD transformation algorithm elements at business level into solution elements domain for defined processes and concepts at application level

Application Presentation (and required transformations) Elements of class diagram generated based on PIM refined level of solution elements at application level application of 2HMD transformation algorithm

Transformation 3: Transformation of solution elements at application level into software elements at platform level

Platform Presentation (and required transformations) PSM level of software elements at platform level

Transformation 4: Transformation of software Software elements at platform level domain into software elements at implementation level

Implementation Presentation (and required transformations) Code level of software components

Figure 1. General structure of model transformation in the framework of MDA tion. Principles of simple language for transfor- elements generation from the problem do- mations are presented in [13]. Several propos- main model presented in the form suitable als [6] are made in response to OMG request for that. for proposals to MOF Query/View/Transforma- tion [6]. The great attention is devoted to UML 2.3. Structure of a Tool for Model class diagram development, because class dia- Transformation gram in UML-based CASE systems serves as a main source of knowledge for development of The MDA process shows the role that the var- software system: database specification, graphi- ious models, PIM, PSM, and code play within cal user interface, application code, etc. [35]. the MDA framework. A transformation tool Class diagram is the most often used takes a PIM and transforms it into a PSM. model for visual representation of static as- A second (or the same) transformation tool pects of classes [35]. Class diagrams in transforms the PSM to code. These transforma- object-oriented software development are typ- tions are essential in the MDA development pro- ically used: as domain models to explore do- cess. The transformation tool takes one model main concepts; as conceptual/analysis mod- as input and produces a second model as its els to analyse requirements; as systems de- output. There is a distinction between the trans- sign models to depict detailed design of formation itself, which is the process of gener- object-oriented software [1]. But UML is ating a new model from another model, and the a modelling language and does not have transformation definition. The transformation all the possibilities to specify context and tool uses the same transformation definition the way of modelling, which is required al- for each transformation of any input model. ways to be defined in a methodology. There A transformation is defined in [13] as the auto- fore the construction of class diagram has matic generation of a target model from a source to be based on well defined rules for its model, according to a transformation definition. Two Hemisphere Model Driven Approach for Generation of UML Class Diagram in the Context of MDA 63

Source model Transformation Target model definition

Process Model Concept Model Transformation Class tool Diagram Two-hemisphere model

Figure 2. Schema of model transformation tool And a transformation definition is defined in [13] target model is defined as a notation for con- as a set of transformation rules that together destruction of UML class diagram (see Fig. 2). scribe how a model in the source language can be transformed into a model in the target language. 3. Models and Model Transformations The recent tendency of automation of infor- in terms of Two Hemisphere Model mation handling process is essential in industry of information technology [9]. It gives a possi- According to [32] the significant aspect of real bility to spare human and time resources. The world behaviour seen from the process point of implementation of tool, which automates trans- view, where process is understood as the col- formation into class diagram, gives a possibility lection of actions, chronologically ordered and to receive static structure of the system with- influencing objects and is more then “just an out spending of a lot of time on design. For amorphous heap of the action”. Similarly to the any transformation the initial data and needed structural modelling of the real world [32]. Two result should be defined before. A transforma- hemisphere model corresponds to both funda- tion tool or approach takes a model on input, so mental things – functional aspects of the sys- called source model, and creates another model, tem defined in terms of business processes and so called target model, on output, see Fig. 2 [13]. the structural ones defined in terms of concept The two hemisphere model has been marked model. The details in the right column of the as input with mapping rules, the class diagram table in Figure 1 correspond to the two hemi- and transformation trace has been received on sphere approach, which addresses the construc- output. Transformation trace shows the plan tion of information about problem domain by how an element of the two hemisphere model use of two interrelated models at problem do- is transformed into the corresponding element main level, namely, the process model and the of the class diagram, and which parts of the conceptual model. The conceptual model is used mapping are used for transformation of every in parallel with process model to cross-examine part of the two hemisphere model [18]. Figure 2 software developers understanding of procedural shows how a transformation tool takes input – and semantic aspects of problem domain. the two hemisphere model and receives output – the class diagram. Therefore implementation 3.1. Essence of Two Hemisphere Model of model transformation (in our case transformation from two hemisphere model into class Two hemisphere model driven approach [21] pro- diagram) needs well-defined set of notational el- poses using of business process modelling and ements of source model, well-defined set of no- concept modelling to represent systems in the tational elements of target model and definition platform independent manner and describes how for transformation of elements of one model into to transform business process models into UML elements of another one. models. For the first time the strategy was pro- According to key notes of the paper the lan- posed in [20], where the general framework for guage for description of source model is defined object-oriented software development had been as a notation for construction of two hemisphere presented and the idea about usage of two in- model [21] and the language for description of terrelated models for software system develop- 64 Oksana Nikiforova ment has been stated and discussed. The strat- ment and redesign [10]. This implies that many egy supports gradual model transformation from companies are common with business process problem domain models into program compo- modelling techniques [10] or at least they employ nents, where problem domain models reflect two particular business process description frame- fundamental things: system functioning (pro- works [31]. On the other hand practice of soft- cesses) and structure (concepts and their rela- ware development shows that functional require- tions). The title of the proposed strategy [21] ments can be derived from problem domain task is derived from cognitive psychology [2]. Hu- descriptions even about 7 times faster than if man brain consists of two hemispheres: one is trying to elicit them directly from users [17]. responsible for logic and another one for con- Both facts mentioned above and existence of cepts. Harmonic interrelated functioning of both many commercial business modelling tools are a hemispheres is a precondition of an adequate strong motivation to base software development human behaviour. A metaphor of two hemi- on the business process model rather than on spheres may be applied to software develop- any other soft or hard models [21]. The concept ment process because this process is based on model (graph G2 in Fig. 3) is used in parallel investigation of two fundamental things: busi- with business process model to cross-examine ness and application domain logic (processes) software developers understanding of problem and business and application domain concepts and platform independent models. According to and relations between them. Two hemisphere Larman [16] real-world classes with attributes approach proposes to start process of software relevant to the problem domain and their rela- development based on two hemisphere problem tionships are presented in concepts model. It is a domain model, where one model reflects func- variation of well known entity relationship (ER) tional (procedural) aspects of the business and diagram notation [4] and consists of concepts software system, and another model reflects cor- (i.e. entities or objects) and their attributes. Ap- responding concept structures. The co-existence plication of two hemisphere model for generation and inter-relatedness of these models enables use of class diagram gives a possibility to avoid rela- of knowledge transfer from one model to an- tions between classes in concept model at busi- other, as well as utilization of particular knowl- ness level (of problem domain). Due to transfor- edge completeness and consistency checks [21]. mation of process model into elements of object Figure 3 shows the essence of two hemisphere communication expressed in terms of UML com- model for an example of an application for driv- munication diagram it becomes possible to de- ing school. fine the relations between classes already accord- A notation of the business process model, ing system realization at software level (of imple- which reflects functional perspectives of the mentation domain). Therefore relations between problem and application domains, is optional, concepts are not shown in concept model in however, it must reflect the following compo- Fig. 3). The notational conventions of the busi- nents of business processes: processes; perform- ness process diagram gives a possibility to ad- ers; information flows; and information (data) dress concepts in concept model to information stores [21]. For current research is used busi- flows (e.g. events) in process model (see Fig. 3). ness process model constructed with GRAPES All elements of the two-hemisphere model stated [11] notation. Current functional requirements as source model in Figure 2 are as follows: always are present in the business process model – Business process diagram/ Process – busi- that helps to maintain their consistency. As a re- ness process usually means a chain of tasks sult sophisticated models are used without dis- that produce a result which is valuable to turbing software developers’ and business ex- some hypothetical customer. A business pro- perts’ natural ways of thinking [21]. Some recent cess is a gradually refined description of a surveys show that about 80 percent of compa- business activity (task). Task is an atomic nies are engaged in business process improve- business process unit, which actually de- Two Hemisphere Model Driven Approach for Generation of UML Class Diagram in the Context of MDA 65

Applicant data Group blank apply for learning form group (applicant) (director) name time applicant data blanks of available groups ID address look for appropriate group address

applicant data appropriate group Teacher data Instructor data

add applicant to group name name

group blank with applicant data load load form list of teachers form list of instructors car (director) assign start date of learning (director) Driving card Group register group blank group blank teacher data instructor data with applicant data with applicant data pupil pupil

assign teacher for group assign instructor for applicant instructor teacher

group blank with applicant data learning dates group data driving card and teacher examination data learning dates

prepare group register examination data

group register for submission

assign learning dates

group register driving card with learning dates with learning dates learn theory learn driving (pupil) (pupil) Business process model Concept model

Figure 3. Example of two hemisphere model (application for driving school) scribes some step or function and is done by The investigation of two hemisphere model a Performer [11]. driven approach under the MDA framework in – Business process diagram/Performer – per- [25] shows that approach could be applied for former is an attribute of a task of business generation of several elements of class diagram. process and serve as a resources required to This paper shows the strategy of two hemisphere perform the activities [11]. model application for generation of UML class – Business process diagram/Event – events are diagram in a more precise way. The elements an input/output object (or more precisely – of the class diagram stated as target model in the arrival of an input object and departure Figure 2 are as follows (only the main elements of an output object) of certain business proof the class diagram are listed here): cess. These objects can be material things or – Class diagram/Class – a class is the descrip- just information [11]. tor for a set of objects with similar structure, – Concept model/Concept – conceptual classes behaviour, and relationships [28]. that are software (analysis) class candidates – Class diagram/Actor – an actor specifies a in essence. A conceptual class is an idea, role played by a user or any other system thing, or object. A conceptual class may be that interacts with the subject [28]. considered in terms of its symbols – words – Class diagram/Class/Attribute – an at- or images, intensions – definitions, and ex- tribute is a logical data value of an ob- tensions – the set of examples [16]. ject [28]. – Concept model/Concept/Attribute – an at- – Class diagram/Class/Operation – an opera- tribute is a logical data value of an object [16]. tion is a specification of a transformation or 66 Oksana Nikiforova

G1 G2

Process Model Concept Model

G3 G4

Intermediate model Communication diagram

Class Diagram

Figure 4. Transformations from two hemisphere model into class diagram under two hemisphere model driven approach query that an object may be called to exe- model (graph G2 in Fig. 4) are transformed into cute [28]. elements of class diagram (graph G5 in Fig. 4), – Class diagram/Relationship – a relationship using intermediate model (graph G3 in Fig. 4) between instances of the two classes. There and UML communication diagram (graph G4 in is an association between two classes if an Fig. 4) [25]. instance of one class must know about the Analysis of two hemisphere model proposed other in order to perform its work [28]. in [22] and application of two hemisphere model It is necessary to find the way how source model for knowledge architecture development in the elements can be transformed into target model task of study program development presented elements according to the definition of transfor- in [22] makes to think that notational conven- mations in the framework of MDA. tions of UML communication diagram is more suitable for definitions of formal transformations 3.2. Description of Transformations of two hemisphere model into object interac- between Models within Two tion and then into class diagram, than using of Hemisphere Model Driven Approach UML sequence diagram. Although the aspect of time sequence, which is a component of UML se- The two hemisphere model driven approach quence diagram and is not shown in communica- [20], [21], [27] proposes to apply transformations tion diagram, is missed in this case. And author from business process model into scenarios for of the paper now is investigating the possibility object interactions by using so called intermedi- to save time aspect in transition from two hemi- ate model, which is received in a direct trans- sphere model into class diagram through the de- formation way from process model. Appropriate fined transformations [26]. interacting objects are extracted from concept Intermediate model (graph G3 in Fig. 4 and model. Class diagram is based on concept model Fig. 5) is used to simplify the transition between and is formed according to information about business process model and model of object in- object interaction. All defined transformations teraction, which is presented in the form of UML from two hemisphere model into elements of communication diagram (graph G4 in Fig. 4 and class diagram are shown in Figure 4. The schema Fig. 5). presents the way how elements of business pro- Intermediate model is a graph generated cess model (graph G1 in Fig. 4) and concept from business process models using methods of Two Hemisphere Model Driven Approach for Generation of UML Class Diagram in the Context of MDA 67

Perform action 1 / event1 event2 G1 Perform action 2 Performer 1 Perform action 3 event3 event4 Perform action 4 / Perform action 5 / Process model Performer 4 Performer 5

Perform Performer 1= Perform event1 event2 Actor1 action2 action1 Perform Perform action2 action3 G3 event3 event4 Perform Perform action4 action5 Performer 4= Performer 5= Actor4 Actor5 Intermediate model

Figure 5. Transformations from business process model into intermediate model

DataTypeB DataTypeA G2 (AKA ConceptA) (AKA ConceptB) attribute a1 attribute b1 attribute b2 attribute a2 Concept model

Perform perform perform G4 Performer 1= Perform event1 event2 Actor1 action1 action2 action1() action2() Perform Perform Event1:ClassA Event2:ClassA action2 action3 G3 event3 event4 Actor1 perform action2() perform action3() Perform Perform action4 action5 Event3:ClassB Event4:ClassB Performer 4= Performer 5= message Actor4 message Actor5 Actor4 Actor5 {perform action4} {perform action5} Intermediate model Communication diagram

Figure 6. Transformations from intermediate model and concept model into object communication diagram direct graph transformations based on principles mediate model, where the class-receiver of this of graph theory [8]. The nodes of the graph G1 method is defined as ClassA, because ConceptA in Figure 5 are transformed into the arcs of the defines a data type for event1 in concept model. graph G3 of Figure 5, and the arcs of the graph Therefore if each process is examined as a mes- G1 in Figure 5 are transformed into the nodes sage, and each data flow as an object, a draft of the graph G3 of Figure 5 [25]. communication diagram could be received by In a case of abstract names of arcs and nodes of replacing all events of intermediate model with graphs in Figure 5 business process “perform ac- concerned class exemplars and the actions of in- tion 1” is transformed into an arc “perform action termediate model with messages or operations. 1” of intermediate model (graph G3 on Fig. 5) and The last transformation of this business pro- events are transformed into nodes of intermediate cess defines the responsible class of this method model. Constructed intermediate model serves as in class diagram (graph G5 in Fig. 4 and Fig. 7) a base for communication model. The communi- based on information that the type of the event cation diagram is represented as a graph G4 in “event 1” is defined by class in. The element “per- Figure 4 and Figure 6. former 1” is transformed as a node of interme- The next transformation defines the method diate model, and as “actor 1” of communication “perform action 1()” in communication diagram model. This element is defined as “actor 1” in (graph G4 on Fig. 6) from the same arc of inter- class diagram. Data types for elements “event 1” 68 Oksana Nikiforova

perform perform G4 G2 action1() action2() Event1:ClassA Event2:ClassA DataTypeA DataTypeB (AKA ConceptA) (AKA ConceptB) Actor1 perform action2() perform action3() attribute a1 attribute b1 attribute b2 Event3:ClassB Event4:ClassB attribute a2 message Actor4 message Actor5 Concept model {perform action4} {perform action5} Communication diagram

G5 ClassA ClassB Actor4 attribute a1 attribute b1 Actor1 attribute a2 attribute b2 perform action1() perform action2() Class perform action2() perform action3() diagram Actor5

Figure 7. Transformations from intermediate model and object communication diagram into class diagram

G1 G2 group blank Group blank Driving card with applicant data time pupil assign instructor for applicant address instructor

driving card learning dates

Process Model Concept Model examination data

G3 group blank G4 : Group_blank with applicant data

assign instructor for applicant assign_instructor_for_applicant ( )

driving card : Driving_card Intermediate model Communication diagram

G5 Group_blank Driving_card time pupil address instructor learning_dates examination_data Class Diagram assign_instructor_for_applicant ( )

Figure 8. An example of transformation of process and concept elements into class elements and “event 3” is defined as “DataType A” or on information of object communication and all “Concept A” of concept model. events and concepts defined as objects in graph These transformations are based on the hy- G4 are defined as classes in class diagram (graph pothesis that elements of the class diagram G5 in Fig. 7). Class diagram presents the set of (graph G5 in Fig. 7) can be received from the attributes based on attributes defined in concept two hemisphere model by applying defined tech- model. niques of graph transformation [8]. The next step In a very simple example, transformation de- of transition is a class diagram. Here all messages scribed above looks like it is shown in Figure 8, of object communication (graph G4 in Fig. 7) are where transformation of fragment of two hemi- encapsulated as operations of classes using main sphere model for driving school into a fragment principles of class diagram development based of the exact class is represented. Two Hemisphere Model Driven Approach for Generation of UML Class Diagram in the Context of MDA 69

There is one process “assign instructor to ap- cess of input data transformation into output plicant”, which has an input event “group blank data.Class diagram generation should consist of with applicant data”, where concept “Group four steps according to the application of two blank” with its attributes defines data type for hemisphere model (see Fig. 9): the event, and an output event “driving card”, 1. construction of two hemisphere model; where concept “Driving card” with its attributes 2. generation of model elements and their in- defines data type for the event. These interre- terrelations in some structured form; lated elements define a two hemisphere model, 3. application of the transformation rules de- which serve as a base for transformation into fined (processing algorithm); intermediate model, with the same names of el- 4. definition of class specification in well struc- ements, but different position – arcs of process tured form suitable for class diagram con- model are transformed into nodes of interme- struction (for example, XML format). diate model, and nodes of business process are One of the tools for business process mod- transformed into the arcs of intermediate model. elling, which gives a possibility to construct two Intermediate model allows to define communi- interrelated models (business process and the cation diagram, where initial process “assign in- concept ones), is GRADE [7]. Indeed, GRADE structor to applicant” is defined as a method. generates text descriptions of model with per- And object-sender and object-receiver are de- manent structure, therefore it is chosen as a tool fined in accordance with discussion above. Based for development of two hemisphere model and on a communication of objects defined, it is pos- further generation of textual files. It defines all sible to construct class diagram according to the elements of the model and their relations from rules of object-oriented system modelling [20]. one into another. Generated text files serves as Experiments with different combinations of an input information into the tool developed and of incoming and outgoing arcs in the model of described in [27] in order to support the pro- business process and a variety of different data cessing algorithm and XML file, which contains types defined in a concept model, where the data structure of the class diagram required. XML type can be the same for incoming and outgoing format of class specification gives a possibility events or different, give a possibility to define to receive visual representation of class diagram different types of relationships between classes. in any tool, which supports import from XML The results of full investigations of all the possi- for class diagram development. An ability to de- ble combinations of two hemisphere model, which velop an automated tool for generation of class gives a possibility to define relationships between structure in XML format demonstrated in [27] classes, are shown in [24]. The paper has a discus- proves, that transformations discussed in the pa- sion of a possibility to share class responsibilities per are enough formal for programming. The tool and to encapsulate class attributes and methods is applied for generation of class diagram from according defined transformations from arcs and two hemisphere model developed for problem do- nodes of two hemisphere model. The paper of- main of pupil application for learning in a driving fers the description of tool for the usage of two school shown in Figure 3. Classes, attributes, op- hemisphere model for class diagram generation erations and relations among classes, which could based on the defined transformations. be determined from the business process diagram and the data structure, were defined applying discussed transformations from business process 4. Verification of Transformation and concept model to class diagram. Figure 9 rep- within Two Hemisphere Model resents the structure of class diagram obtained. Driven Approach One of the limitations of the approach is an impossibility to define the full specification of When the structures of input and output data methods with its arguments. This could be one are known, it is possible to automate a proof the potential directions for future investiga- 70 Oksana Nikiforova

Applicant data Group blank Group register name time pupil ID address teacher address form_group() group data apply_for_learning() look_for_appropriate_group() learning dates add_applicant_to_group() add_applicant_to_group() examination data assign_start_date_of_learning() prepare_group_register() Applicant assign_teacher_for_group() assign_learning_dates()

Teacher data name load form_list_of_teachers() Driving card Director pupil Instructor data instructor name learning dates load examination data car assign_instructor_for_applicant() form_list_of_instructors() assign_learning_dates()

Figure 9. Initial structure of class diagram defined based on transformations from two hemisphere model tion of application of two hemisphere model for periments on applying discussed transformations generation of class diagram elements. In order to from two hemisphere model into class diagram verify the transformations offered in the paper, in different problem domain prove that transfor- the transformations defined for two hemisphere mations are independent from problem domain. model driven approach in addition to an exam- Experiments on applying transformation from ple of driving school are applied in some more two hemisphere model, constructed in various examples: (1) problem area of hotel room reserva- CASE tools and notations, prove that transfor- tion, where initial business process model is con- mations from two hemisphere model into class structed in GRAPES notation [11] with CASE diagram are independent from used notation of tool GRADE [7], the two hemisphere model is business process modelling, as well as CASE tool, developed by authors and results of these exper- used for initial model creation. iments are shown in [23]; this case approve the possibility to define class diagram by application of the transformations offered in the paper; 5. Conclusion (2) problem area of insurance system, where initial model is constructed in GRAPES notation The Model Driven Architecture is the central with CASE tool GRADE [7], the two hemisphere component in the OMG’s strategy for maximis- model is constructed by developers of GRADE ing return on investment, reducing development tool as demo example and results of these ex- complexity and future-proofing against tech- periments are shown in [25]; this case approve nological change [29]. But still the “complete an independence of the transformations offered code-generation capabilities” are no supported in the paper from the constructor of two hemi- in MDA tools and the more problematic stage is sphere model. The problem area of hotel room exactly platform independent system modelling reservation also is approbated by construction of based on knowledge about problem domain. Since initial business process model in IDEF0 [14] no- beginning of eighties a numerous accounts of tation with CASE tool BPWin. Unfortunately, it model generated software systems have been of- does not provide construction of concept or object fered to attack problems regarding software pro- model. Therefore attributes of classes, received ductivity and quality [3]. CASE tools developed for hotel room reservation system with initial in- up that time were oversold on their “complete formation in IDEF0 notation are missing in the code-generation capabilities” [15]. Nowadays, class diagram. Even in this case automation of similar arguments are exposed to Object Manage- distributing methods among classes is important ment Group (OMG) Model Driven Architecture contribution within software development. Ex- (MDA) [34], using and integrating Unified Mod- Two Hemisphere Model Driven Approach for Generation of UML Class Diagram in the Context of MDA 71 elling Language (UML) models [28] at different hemisphere model and to investigate abilities of levels of abstraction. Manipulation with models usage of two hemisphere model for dynamic com- enables software development automation within ponent of platform independent model expressed CASE tools supported by MDA [5], [13], [19]. in terms of object interaction and state transi- The paper discusses abilities on usage of prob- tion. A deeper analysis of notational conventions lem domain knowledge presentation in terms of of nowadays available notations for business pro- two hemisphere model, which contains two in- cess modelling is required and could be stated as terrelated models of system aspects – process one of further researches directions. and concept presentation. The proposed trans- Acknowledgements The research reflected formations are applied to two hemisphere model in the paper is supported by the research grant of application for driving school and classes with No. FLPP-2009/10 of Riga Technical University attributes and different kinds of relationships are “Development of Conceptual Model for Tran- identified based on elements of process and con- sition from Traditional Software Development cept models. The ability to define all the types into MDA-Oriented.” And partially the research of transformations in a formal way gives a pos- reflected in the paper is supported by Grant of sibility to automate the process of class diagram Latvian Council of Science No. 09.1245 “Meth- development from correct and precise two hemi- ods, models and tools for developing and gover- sphere model. On one hand, it enables knowl- nance of agile information systems”. edge representation in a form understandable for both business users and system analyst, moreover cover complete and consistent presentation of different system aspects. And on the another hand, References it supports the formal transformations of model [1] S. Ambler. The Elements of UML Style. Cam- elements into elements of UML class diagram, bridge University Press, 2003. which often is a starting point during software [2] J. Anderson. Cognitive Psychology and Its Im- development by using nowadays CASE tools, es- plications. W.H. Freeman and Company, New pecially in the ones following an idea of MDA. York, 1995. The central hypothesis of this research is that it [3] R. Balzer. A 15 year perspective on automatic programming. IEEE Transactions on Software is possible to apply the graph theory technique for Engineering, 11(11):1257–1268, 1985. model transformation in the framework of MDA, [4] P. Chen. The entity relationship model – to- where the source model is defined in terms of a wards a unified view of data. ACM Transactions business process model, associated with a con- on Database Systems, 1(1):9–36, 1976. cept model, and the target model is defined in [5] D. Frankel. Model Driven Architecture: Apply- terms of a class diagram. Analysis of the system ing MDA to Enterprise Computing. Woley Pub- models presented as a set of graphs developed on lishing, Inc., Indianapolis, Indiana, 2003. the basis of the initial two hemisphere model en- [6] T. Gardner and C. A. Griffin. Review of OMG MOF 2.0 Query/Views/Transformations Sub- ables derivation of the class diagram, which is the missions and Recommendations Towards the Fi- central component of PIM and is sufficiently de- nal Standards. Object Management Group. tailed in order for the PSM to be generated. Two OMG documents ad/03-08-02, available at http: hemisphere model gives a possibility to define //www.omg.org. classes with attributes and operations they have [7] GRADE Development Group. GRADE tools. to perform, as well as different types of relations [8] J. Gross and J. Yellen. Graph Theory and Its can be defined between classes, based on analysis Applications. Discrete Mathematics and Its Ap- plications. Chapman and Hall/CRC, 2nd edi- of different combinations of type definition for tion, 2006. incoming and outgoing flows of processes of two [9] M. Guttman and J. Parodi. Real-Life MDA: hemisphere model. At the moment authors try to Solving Business Problems with Model Driven investigate the possibility of exact definitions of Architecture. San Francisco, CA: Morgan Kauf- method’s arguments based on information in two mann Publishers, 2007. 72 Oksana Nikiforova

[10] P. Harmon. Business process management. based on initial business knowledge. Proceeding In Lecture Notes in Computer Science, volume of the 17th International Conference on Infor- 5240/2008. Springer Berlin/Heidelberg, 2008. mation Systems Development, Information Sys- [11] INFOLOGISTIK GmbH. GRADE Business tems Development: Towards a Service Provision Modeling, Language Guide, 1998. Society, August 2008. In press. [12] I. Jacobson, G. Booch, and J. Rumbaugh. [25] O. Nikiforova and N. Pavlova. Open work The Unified Software Development Process. of two-hemisphere model transformation defini- Addison-Wesley, 2002. tion into uml class diagram in the context of [13] A. Kleppe, J. Warmer, and W. Bast. MDA Ex- mda. Preprint of the Proceedings of the 3rd plained: The Model Driven Architecture – Prac- IFIP TC 2 Central and East Europe Conference tise and Promise. Addison Wesley, 2003. on Software Engineering Techniques, CEE-SET [14] Knowledge Based Systems Inc. IDEF Inte- 2008, pages 133–146, October 2008. grated Definition Methods. Available at http: [26] O. Nikiforova and N. Pavlova. Modeling of //www.idef.com/. object interaction with two-hemisphere model [15] J. Krogstie. Integrating enterprise and is de- driven approach. 2009. Submitted to the velopment using a model driven approach. In 13th East-European Conference on Advances in Proceedings of 13th International Conference on Databases and Information Systems. Information Systems Development-Advances in [27] O. Nikiforova, N. Pavlova, and J. Grigorjevs. Theory, Practice and Education, pages 43–53. Several facilities of class diagram generation Springer Science+Business media, New York, from two-hemisphere model in the framework 2005. of MDA. Proceedings of 23rd IEEE Interna- [16] C. Larman. Applying UML and Patterns: An tional Symposium on Computer and Informa- Introduction to Object-Oriented Analysis and tion Sciences, pages 1–6, 2008. Available at Design. Prentice Hall, New Jersey, 2000. http://ieeexplore.ieee.org/. [17] S. Lausen. Task descriptions as func- [28] Object Management Group. Unified Model- tional requirements. IEEE Software, 20:58–65, ing Language Specification. Available at http: March/April 2003. //www.omg.org. [18] MDA Guide Version 1.0.1, June 2003. Available [29] T. Pokorny. The Model Driven Architecture: No at http://www.omg.org/docs/omg/03-06-01. Easy Answers, 2005. pdf. [30] T. Quatrany. Visual Modeling with Rational [19] S. Mellor and M. Balcer. Executable UML. Rose 2000 and UML. Addison-Wesley, second A Foundation for Model-Driven Architecture. edition, 2000. Addison-Wesley, Boston, 2002. [31] C. Raistrick, P. Francis, J. Wright, C. Carter, [20] O. Nikiforova. General framework for object-ori- and I. Wilkie. Model Driven Architecture with ented software development process. Scien- Executable UML. Cambridge University Press, tific Proceedings of Riga Technical University, 2004. 13:132–144, 2002. [32] V. Repa. Modelling business processes in public [21] O. Nikiforova and M. Kirikova. Two-hemisphere administration. Advances in Information Sys- driven approach: Engineering based software de- tems Development. Bridging the Gap between velopment. Advanced Information Systems En- Academia and Industry, 1:107–118, 2006. gineering, pages 219–233, June 2004. [33] J. Rumbaugh. Omt: The developing process. [22] O. Nikiforova, M. Kirikova, and N. Pavlova. Object Oriented Programming, (8):14–18, 1995. Principles of model driven architecture in [34] J. Siegel. Developing in OMG’s Model- knowledge modeling for the task of study pro- Driven Architecture, 2001. OMG document gram evaluation. Databases and Information omg/01-12-01. Available at http://www.omg. Systems IV, pages 291–304, 2007. org/mda/papers.htm. [23] O. Nikiforova and N. Pavlova. Development [35] T. Skersys and S. Gudas. Class model devel- of the tool for generation of uml class dia- opment using business rules. Advances in In- gram from two-hemisphere model. Proceed- formation Systems Development. Bridging the ings of The third International Conference on Gap between Academia and Industry, 1:203–216, Software Engineering Advances, International 2006. Workshop on Enterprise Information Systems, [36] D. Tkach, W. Fang, and A. So. Visual mod- pages 105–112, October 2008. eling technique: object technology using visual [24] O. Nikiforova and N. Pavlova. Foundations programming. Addison Wesley, 1996. on generation of relationships between classes e-Informatica Software Engineering Journal, Volume 3, Issue 1, 2009

Automated Code Generation from System Requirements in Natural Language

Jan Franců∗, Petr Hnětynka∗

∗Faculty of Mathematics and Physics, Department of Software Engineering, Charles University in Prague [email protected], [email protected]

Abstract An initial stage of a software development is specification of the system requirements. Typically, these requirements are expressed in UML and consist of use cases and domain model. A use case is a sequence of tasks, which have to be performed to achieve a specific goal. The tasks of the use case are written in a natural language. The domain model describes objects used in the use cases. In this paper, we present an approach that allows automated generation of executable code directly from the use cases written in a natural language. Usage of the generation significantly accelerates the system development, e.g. it makes immediate verification of requirements completeness possible and the generated code can be used as a starting point for the final implementation. A prototype implementation of the approach is also described in the paper.

1. Introduction entities are either parts of the system or users of the system. A step of a use case is specified Development of software is covered by several by natural language sentences. The use cases of stages from which one of the most important the system are completed by a domain model is the initial stage – collecting system require- that describes entities, which together form the ments. These requirements can be captured in designed system and which are referred to in the many forms, however, use of the Unified Mod- use cases. eling Language (UML) has become an industry Bringing a system from the design stage to standard at least for large and medium-size en- the market is a very time-consuming and also terprise applications. Development with UML money-consuming task. A possibility to gener- [8] is based on modeling the developed system at ate an implementation draft directly from the multiple levels of abstraction. Such a separation system requirements would be very helpful for helps developers to reflect specific aspects of the both requirement engineers and developers and designed system on different levels and therefore it would significantly speed up development of to get a “whole picture” of the system. the system and decrease time required to de- Development with the UML starts with def- liver the system to the market and also decrease inition of goals of the system. Then, main char- amount of money spent. The system use cases acteristics of the system requirements are iden- contain work-flow information and together with tified and described. A behaviour of the devel- the domain model capture all important infor- oped system is specified as a set of use cases. mation and therefore seem to be sufficient for A use case is a description of a single task per- such a generation. But the problem is that the formed in the designed system [3]. The task itself use cases are written in a natural language and is further divided into a sequence of steps that there is a gap to overcome to generate the sys- are performed by communicating entities. These tem code. 74 Jan Franců, Petr Hnětynka

1.1. Goals of the paper The developers can use several existing modeling tools/frameworks (e.g. [10]) to support this In this paper, we describe an approach, which al- process. lows to generate an implementation of a system In this paper, we work with the UML doc- from the use cases written in a natural language. uments created during the initial stage of the The process proposed in the paper enables soft- system development, i.e. with the requirement ware developers to take an advantage of the specification. Results of the stage are captured carefully written system requirements in order in use cases and domain model. to accelerate the development and to provide immediate feedback for the project’s require- 2.1. Use Cases ment engineers by highlighting missing parts of the system requirements. The process fits in A use case in the context of UML is a description the incremental development process where in of a process where a set of entities cooperates each iteration developers can eliminate short- together to achieve a goal of the use case. The comings in design. In addition, the process can entities in the use case can refer to the whole sys- be customized to fit in any enterprise application tem, parts of the system, or users. Each use case project. has a single entity called system under discus- Described approach is implemented in a sion (SuD); from the perspective of this entity, proof-of-the-concept tool and tested on a case the whole use case is written. An entity primar- study. ily communicating with SuD is called a primary To achieve the goals, the paper is structured actor (PA). Other entities involved in the use as follows. Section 2 provides an overview of the case are called supporting actors (SA). UML models and technologies required for use Each use case is a textual document writ- case analysis. Section 3 shows how our genera- ten in a natural language. The book [3] recom- tion tool is employed in the application develop- mends the following structure of the use case: (1) ment process. Section 4 describes the tool and header, (2) main scenario, (3) extensions, and all generation steps in detail while Section 5 (4) sub-variations. presents particular examples of the generated The header contains the name of the use code. Section 6 evaluates our approach and the case, SuD entity, primary actor and support- paper is concluded in Section 7, where future ing actors. The main scenario (also called the plans are also shown. success scenario) defines a list of steps (also called actions) written as sentences in a natural language that are performed to achieve the 2. Specification of Requirements goal of the use case. An action can be extended with a branch action, which reflects possible The Unified Modeling Language (UML) is a diversions from the main scenario. There are standardized specification language for the soft- two types of the branch actions: extensions and ware development. Development with UML is sub-variations. In an extension, actions are per- based on modeling a system at multiple lev- formed in addition to the extended action, while els of abstraction in separated models. Each in a sub-variation, actions are performed instead model represented as a set of documents clar- of the extended action. The first sub-action of a ifies the abstraction on a particular level and branch action is called a conditional label and captures different aspects of the modeled sys- describes necessary condition under which the tem. The UML-based methodologies standard- branch action is performed. ize whole development process and ensure that The above described structure is not the only the designed system will meet all the require- possible one – designers can use any structure ments. UML also increases possibilities to reuse they like. In our approach, we assume the use existing models and simplifies reuse of code. cases satisfy these recommendation as it allows Automated Code Generation from System Requirements in Natural Language 75

Figure 1. The Marketplace project entities

UseCase: Buyer buys a selected item SuD: Clerk PA: Buyer Supporting actor: Computer System

Main success scenario speciﬁcation: 1 Buyer submits to the clerk a reference to a selected oﬀer. 2 Clerk submits the reference to the system. 3 Clerk reports the system response to the seller and requests billing and shipping information, payment method and payment details. 4 Buyer submits to the clerk the requested billing and shipping information, payment method and payment details. 5 Clerk enters the billing and shipping information, payment method and payment details. 6 Clerk reports the system response (with the unique acknowledgment) to the buyer.

Extensions: 3a System failed to validate the offer. 3a1 Use case abort. Figure 2. Use case example us to process the use case automatically and tains the Computer system. A Credit verification generate the system implementation. Such an agency verifies Seller’s and Buyer’s operations assumption does not limit the whole approach and finally a Trade commission confirms the of- in a significant way, hence the book [3] is widely fers. considered as a “bible” for writing the use cases The use case on Figure 2 is a part of the (in addition, we already have an approach for Marketplace specification (the whole specifica- using use cases in fact with any structure – see tion has 19 use cases) and it describes commu- Sect. 7). nication between the Buyer (as PA), Clerk (as In the rest of the paper we use as an exam- SuD), and Computer system. It is prepared ac- ple a Marketplace project for on-line selling and cording to the recommendations. buying. A global view of the application entities is depicted on Figure 1. There are several actors, 2.2. Domain Model which communicate with the system. Sellers enter offers to the system and Buyers search for A domain model describes entities appearing interesting offers. Both of them mainly commu- in the designed system. Typically, the domain nicate directly with the Computer system – in model is captured as a UML class diagram and few cases, they have to communicate through a consists of three types of elements: (1) concep- Clerk who passes information to the Computer tual classes, (2) attributes of conceptual classes, system. There is also a Supervisor which main- and (3) associations among conceptual classes. 76 Jan Franců, Petr Hnětynka

Conceptual classes represent objects used in resents a single action that has to be performed the system use cases. The attributes are fea- and its notation is composed of several parts. tures of the represented objects and associations First, there is a single character representing a describe relations among the classes. Figure 3 type of the action. The possible types are ? resp. shows the Marketplace domain model. ! for request receiving resp. sending action, # As described in [8], noun phrases appearing for internal actions (unobservable by others than in the use cases can be used for determining class SuD) and % for special actions. The action type names during creation of the domain model (in is followed by the entity name on which the action further detail, such a relation between the class is performed. Finally, the name of the action itself diagrams and use cases is investigated in [1]). is the last part (separated by a dot). In a case, there is no entity name, the action is internal. For example, ?B.submitSelectOffer is the submitSe- lectOffer action where SuD waits for a request from the B (Buyer) entity. The procases use the same set of operation as regular expressions. These are: * for iteration, ; for sequencing, and + for alternatives. In this paper, we call the alternative operator as a branch action, its operands (actions) as branches, and the iteration operator with its operand as a loop action. A special action is NULL which means no Figure 3. Marketplace domain model activity and is used in places with no activity but the procase syntax requires an action spec- 2.3. Procasor Tool and Procases ified there (e.g. with the alternative operator). Another special action is the first action inside The Procasor [6] is a tool for automated trans- a non-main scenario branch, which is alled con- formation of natural language (English) use dition branch label and expresses the condition cases into a formal behaviour specification. The under which the branch is triggered. Finally, transformations are described in [9] and further the %ABORT special action represents a failure extended in [4] where almost all restrictions of a ending of the procase. use case step syntax were removed. Procedure calls (written as a sequence of ac- As a formalism into which the natural lan- tions in curly brackets) represent a behaviour guage use cases are transformed the Procasor (mostly composed of inner actions) of the re- uses procases [9] that are a special form of be- quest receive action after which they are placed haviour protocols [14]. In addition to procases, a (the action is called trigger action). UML state machine diagram is also generated. A procase is a regular expression-like specifi- 2.4. Goals Revisited cation, which can describe behaviour of a single entity as well as of the whole system [13]. The As described in the sections above, the Proca- procases generate so called traces that represent sor tool parses the use cases written in a natural all possible valid sequences of actions described language and generates a formal specification of by the use cases. Figure 7 shows a procase de- behaviour of the designed system. A straightfor- rived from the use case shown in Figure 2. ward idea is then why to stop just with the gen- A procase is composed of operators (i.e. +, ;), erated behaviour description and not to gener- procedure calls ({,}), action tokens, and support- ate also an implementation of the system which ing symbols (i.e. round parenthesis for specifying implements the work-flow captured in the use operators’ precedence). Each action token rep- cases. Automated Code Generation from System Requirements in Natural Language 77

Figure 4. Development process overview The goal of this paper is to present an ex- The system requirements cannot be understood tension of the Procasor tool that based on the as final and unchangeable. Especially in incre- use cases generates executable implementation mental development, the requirements are cre- of the designed system. ated in several iterations and obviously the first versions are incomplete. Therefore if the generator is used on such input, it can generate a 3. Generating Process completely wrong implementation. But this implementation can be used to validate the use The development process with our generating cases, repair them and regenerate the implemen- tool is as follows. First, requirement engineers tation. collect all requirements and describe them in the form of use cases. Then the Procasor tool automatically generates procases. In parallel, the 4. Generating Tool in Detail requirement engineers create a project domain model. As a next step of validating the use cases, The generator of the implementation takes as the generated procases can be reviewed. Then, an input the procases generated by the Procasor our generator is employed and produces an imple- and the created domain model of the designed mentation of the developed system. The gener- system. From these inputs, it generates the ex- ated implementation consists of three main parts: ecutable implementation. (i) use case objects where work-flow captured in The generation is automated and it consists a use case is generated, (ii) pages which are used of three steps: to communicate with users of the system, and 1. First, procases generated from the Procasor (iii) entity objects where the business logic is are rearranged into a form, in which they kept. still follow the procases syntax but are more The generated implementation is only an ini- suitable for generating the implementation tial draft and serves primarily for testing the (Sect. 4.1). use cases and domain model. But it can be also 2. Then, a relation between words used in the used as a skeleton for the actual implementation use cases and elements in the domain model and/or to allow customers to gain first impres- is obtained and parameters (i.e. their num- sions of the application. The whole development bers and types) of the methods are identified process is illustrated in Figure 4. (Sect. 4.2). At this point a common mistake has to be 3. Finally, the implementation of the designed emphasized (which is also emphasized in [8]). system is generated (Sect. 4.3). 78 Jan Franců, Petr Hnětynka

4.1. Procase Preprocessing Two other cases cannot be solved directly and require more complex preprocessing. To The procases produced by the Procasor do not solve these cases, we have enhanced procases contain procedure calls brackets (see 2.3), which with so called conditional events, which allow are crucial for successful transformation of the “cutting” branches of the procase and arrange procases into the code. Except several marginal them in a sequence, but which do not modify cases, each use case is a request-response sequence the procase syntax. between SuD and PA (for enterprise applica- The conditional events allow to mark tions). In the procase, a single request-response branches of the alternatives by a boolean vari- element is represented as a sequence of actions able (written in the procase just as a name with- from which the first one is the request receive out any prefix symbol followed by a colon, e.g. action (i.e. starts with ?) and then followed by D:). The variables can be set to true via the ac- zero or more other actions (i.e. sending request tion written as the variable name prefixed with action, internal actions, etc.). In other words, SuD the $ symbol (e.g. $D) or to false by its name receives the request action, then performs a list of with the $ and symbols (e.g. $D). At the ∼ ∼ other actions, and finally returns the result (i.e. beginning of each procase, all variables are un- end of the initial request receive action). Hence, declared. the sequence of actions after the request receive These events modify the behaviour of the action can be modeled as a procedure content and procase in a way that only traces containing enclosed in the procedure call brackets. the action, which sets the variable to true, con- The following example is a simple procase in tinue with the branches marked by this variable. a form produced by the Procasor: When the value of the variable is false, the traces ?P A.a;#b;!SA.c;?P A.d;#e;#f continue with the unmarked branches as in un- After identifying the procedure calls, the changed procase. procase is modified into the following form: ?P A.a #b;!SA.c ;?P A.d #e;#f 4.1.1. Branch transformation { } { } At the end, the code generated from this pro- First, we show how to rearrange a procase with case consists of two procedures – first one gener- the request receive action placed in a branch. ated from the ?PA.a action and internally call- The general approach of identifying procedures ing the procedures resulted from #b and !SA.c, as described above does not work as it would and the second one generated from ?PA.d and result in nested procedures. To avoid them, it is calling #e and #f. necessary to rearrange the procase in order to The approach described in the paragraph place affected branches sequentially. above works fine except for several cases. In par- We illustrate the branch transformation on ticular, these are: (1) first action of the use case the following example: is not a request receive action, (2) a request re- ?a;#b; (#c;??d;#e + #f; (#g;#h + #i)); #j ceive action is in a branch(es), and (3) a request receive action is anywhere inside a loop. The problematic action is ?d placed in a branch In the case when the first action of the use and the whole example is visualized in Fig. 5(a). case is not a request receive action, a special The approach of rearranging branches is as action INIT is prepended to the use case and follows. Instead of the affected request receive the actions till the first request receive action action, the declaration of a conditional event are enclosed in the procedure call brackets. In variable is placed. The original action with all the generated code, a procedure generated from subsequent actions till the end of the branch are the INIT action is called automatically before moved outside the alternative and marked with the other actions. the chosen variable – depicted in Fig. 5(a b). ⇒ Automated Code Generation from System Requirements in Natural Language 79

Figure 5. First part of the Branch transformation The NULL action is added as a second branch 4.1.2. Loop transformation of the newly created marked branch. Now, the actions that followed after the orig- The transformation of the procases with the re- inal branch action (till the ﬁrst request receive quest receive action located in a loop action is action) have to be appended to all other branches quite similar to the previous case. Again, the of this branch action except the branch with the transformation guarantees that the resulting pro- variable declaration – depicted in Fig. 5(b c). case generates the same traces as the original one. ⇒ In addition, these actions are placed at the end of The following procase is an example with the the newly created branch. In a case the variable request receive action inside the loop: declaration is placed in more than one branch ?P A.a;#b; (#c;??P A.d;#e) #f (i.e. the request receive actions were in more ∗ branches), appending of subsequent actions (till And the resulting transformed procase: the ﬁrst request receive action) has to be done ?P A.a #b; (#c; $D + #f) ; for all these branches and variables – depicted in { } (D :?P A.d #e; (#c + #f; $D) + NULL) Fig. 6(d e). This appending guarantees that { ∼ } ∗ ⇒ the resulting procase in Fig. 6(f) generates the 4.1.3. Unresolved cases same traces as the original one. Now, the general approach of identifying procedures can be applied In a case the request receive action is located in and yields the following procase: two or more nested loops or in a loop nested in ?a #b; (#c; $D + #f; (#g;#h;#j + #i;#j)) ; branches, the previous two transformations do { } not work. The procase is then marked as unre- (D :?d #e;#j + NULL) { } solved, excluded from the further processing and Another example is in Figure 7, which shows has to be managed manually. On the other hand, the procase of the use case in Fig. 2 that also such use cases are very unreadable (see [8] for sug- contains problematic request receive action. Fig- gestions about avoiding extensions of extensions ure 8 depicts the procase after the branch trans- or complex nested loops which results into this formation, i.e. it is completely equivalent to the problematic procases) and therefore the skipped former one and does not contain the problematic use cases are candidates for rewriting in a more branch. simple and readable way. 80 Jan Franců, Petr Hnětynka

Figure 6. Second part of the Branch transformation

?B.submitSelectOffer; !CS.submitSelectOffer; !B.reportSystemResponse; ( ?B.submitBillingShippingInformationPaymentMethodPaymentDetail; !CS.enterBillingShippingInformationPaymentMethodPaymentDetail; !B.reportSystemResponse + #validateSystemFail; %ABORT ) Figure 7. Procase example before the branch transformation 4.2. Determining Arguments First, all noun phrases (which may refer to the data manipulated in the use case step) are Once the procases have been preprocessed into extracted by the Procasor from the use case step sequences of actions grouped as procedure calls, sentence. In addition, we also take into account the next step is to determine arguments of the verbs from the sentence as they can refer to the identified procedures, types of these arguments, relations between the conceptual classes in the and how their values are assigned. The argu- domain model. ments are subsequently used as arguments for The list of extracted words is then matched methods in the final generated code. against keywords of the domain model (by the In our approach, we are using a fact men- keywords we mean names of the classes, at- tioned in [8] that noun phrases appearing in the tributes, and associations) in order to discover use cases are directly related with the domain which words are actual attributes and to obtain model elements names. The process of determin- their types. There are many options to match ing arguments is as follows. the keywords – currently in our implementa- Automated Code Generation from System Requirements in Natural Language 81

?B.submitSelectOffer { !CS.submitSelectOffer; !B.reportSystemResponse; ( #validateSystemFail; %ABORT + $SBSIPMPD ) }; (SBSIPMPD: ?B.submitBillingShippingInformationPaymentMethodPaymentDetail { !CS.enterBillingShippingInformationPaymentMethodPaymentDetail; !B.reportSystemResponse1 } + NULL ) Figure 8. Procase example from Fig. 7 after the branch transformation tion we use a simple case-insensitive equality of 4.3. Generating Application strings. Such a matching approach can be seen as insufficient but on the other hand, projects Structure of the generated application employs commonly follow a chosen terminology (many multiple commonly used design patterns for en- times explicitly captured in the requirement terprise applications. Based on these patterns, documents) and therefore our approach is sat- the generated code is structured into three lay- isfactory in most of the cases. ers – presentation layer, middle (business) layer, The determined arguments are compared (by and data layer. In the following text, we re- the name and type) with arguments of previous fer to objects of the presentation layer as pages procedures (if they exist) and the already used because the most commonly used presentation arguments are copied (their values). If the previ- layer in contemporary large applications em- ous procedures are located in a branch parallel ploys web pages, but any type of the user in- with the NULL action they are excluded from terface can be generated in a similar way. processing as they may not be called before the The middle layer consists of so called use processed one. case objects which contain the business logic of Now, the process behaves differently based the application. Also, the middle layer contains on a type of the entity, on which the action is entity objects where the internal logic (imple- called. The types are (i) human user entities mentation of the basic actions) is generated. The (UE) such as buyer, seller, etc. and (ii) parts use case objects implement the ordering of the of the system or other computer systems (i.e. actions and call the entity objects. system entity – SE). We do not describe generation of the data For the trigger action and actions with layer, as it is well captured in common UML UE SuD, the unmatched determined types are tools and frameworks (generation of classes from used as arguments (i.e. parameters which have class diagrams etc. – see Sect. 6). to be inputted by users). For actions with The generation depends on the type of en- SE SuD the unmatched determined types are tity – pages are generated for UE while for SE a also added as arguments but with default val- non-interactive code only. Thus, a page is gen- ues (during the development of the final ap- erated for every action performed by UE (pro- plication, developers have to provide correct cedure call triggering actions and procedure call values for them). internal actions). 82 Jan Franců, Petr Hnětynka

If the use case has SuD as UE then ele- generated for each action interacting with UE. ments generated from the actions located inside In a case of UE PA, there is a page for every a procedure call are named with the suffix “X” triggering action and, in addition for UE SuD, to allow their easier identification during future there is also a page for every procedure call in- development, as in most cases they have to be ternal action. If the action has arguments which modified by developers. can be inputted then for each of them an input Based on combination of the communicating field is generated. Values are assigned by humans actors (UE vs. SE), the generation distinguishes during testing of the generated system. four cases how the code is generated from a pro- For the UE PA actions, the corresponding cedure call: pages have a button (an input control element) 1. If PA and/or SA is UE, then a page is gen- that allows to continue to the next page, i.e. to erated for every procedure call triggering ac- continue in the use case (there is only a single tion, which is triggered by this UE. button as there is no other choice to continue). 2. If PA and/or SA is SE, an action implemen- On the pages belonging to the UE SuD actions, tation method is generated in the actor en- there are several buttons, which reflect the pos- tity object and the action method body con- sibilities of continuation in the original use case. tains a call to the corresponding use case ob- For a sequence of the actions, the page contains ject. the “continue” button; if the next action is a 3. If SuD is UE, then a method in the cor- branch action then the page contains a button responding use case object is generated for for each branch (the default button is for the each procedure call of SuD. The method main scenario branch – the buttons for the rest body calls the actor entity object and redi- of the branches are labeled by the branch con- rects to “X” pages, which manage the in- dition label; if the next action is a loop action ternal procedure call actions. Internal pro- then the page has a button to enter the loop cedure call actions are generated in a sim- and another button to skip the loop (following ilar way to the request receive action with the definition of loop operation). UE PA – the “X” page and a method inside the “X” use case object are generated. The 4.3.2. Use Case Objects method inside the “X” use case object is generated as a simple delegation method to the The use case objects contain the business logic corresponding entity object and redirection (work-flow) of the use case, i.e an order of to the particular page. actions in the main scenario and all possible 4. And finally if SuD is SE, then inside the cor- branches. Bodies of the generated methods differ responding use case object, a method with according to SuD. the body containing the internal procedure UE SuD: As described above, a method call actions is generated. in the corresponding use case object is gener- Figure 9 shows the procase of the Clerk- ated for each procedure call of UE SuD. For -buys-selected-Offer-on-behalf-of-Buyer use case each trigger action, the method body contains and Figure 10 overviews all generated elements a call to the particular entity object and redi- from the use case. rection to a page of the subsequent action. The following sections describe each type of For internal procedure call actions, a similar the generated objects in more details. method body is created in “X” use case object. 4.3.1. Pages SE SuD: A body of the method generated for the procedure call trigger action contains the As generated, pages are intended for testing the internal procedure calls. For the SuD internal use cases and are expected to be reimplemented actions, methods are called on the use case SuD during the further development. A single page is entity object and for request send actions, meth- Automated Code Generation from System Requirements in Natural Language 83

?CL.submitItemDescription { ( #priceAssessmentAvailable; !Sl.providePriceAssessment + #validateDescription; ( #validationPerformedSystemFails; %ABORT + NULL ) ) }; ?CL.enterPriceContactBillingInformation { #validateContactInformation; !SU.validateSeller }; ?SU.permitSeller { !TC.validateOffer; ( #listOffer; !Sl.respondUniquelyIdentifiedAuthorizationNumber + #tradeCommissionRejectsOffer; %ABORT ) }

Figure 9. Clerk-buys-selected-Offer-on-behalf-of-Buyer use case ods are called on the action triggered entity ob- Therefore, the entity objects are generated with jects. almost empty methods containing only calls to a The branch actions are generated as a se- logger and they have to be finished by develop- quence of the condition statements (i.e. if () ... ers. For testing purposes, the logging methods else if () ...) with as many elements as branches seem to be the most suitable ones as designers in the branch action. In each if statement, par- can immediately check the traces of the gener- ticular actions are generated, while the last else ated system. statement contains the main scenario actions. A similar construction but with a loop statement 4.4. Navigation (while) is created for the loop action. The number of iteration in the loop state- Navigation (transitions) between the pages is an ment and choice of the particular branch in important part of the application internal logic the condition statements cannot be determined as it determines the part of the system work flow from the use case. Therefore, the statements are (the order of procedure calls and sequence of ac- generated with predefined but configurable con- tions). The navigation is derived from the pro- stants inside the use case object. cases as a set of navigation rules. The pages/objects have associated these rules that contain un- 4.3.3. Entity Objects der which circumstances a transition has to be chosen. The internal logic of actions is not captured In general, the navigation rules are created by the use cases neither by the domain model. from the branch actions, loops, and special ac- 84 Jan Franců, Petr Hnětynka

Figure 10. Overview of elements generated from the procase in Fig. 9 tions that can change transitions (aborts, etc.). they can be used as starting point for con- In a case of the use case with SE SuD, the tinuing the application implementation. The rules are applied to determine transitions be- generator itself has been written in plain tween calls of the actions. In a case of UE Java. SuD, the rules determine how the pages are The generator produces code together with generated, i.e. which buttons are placed on an Ant build file, which can immediately compile them. and deploy the application to the JBoss application server [7], which allows users to inspect and modify code and iteratively test the application. 5. Generated Application Example Based on the chosen technologies and used design patterns the first two application layers To prove that our approach is feasible, we are mapped into the following five tiers. The have implemented the proposed generator. As pages results in two tiers: (i) JSF pages and (ii) a particular technology for the generated ap- backing beans (BB). The middle layer then re- plications, we have chosen the Java EE plat- sults into three tiers: (iii) business delegator tier form with Enterprise Java Beans (EJB) as the (BD), (iv) Enterprise Java Bean tier (EJB), and business layer and Java Server Faces (JSF) as finally (v) manager tier (MGR). Generation of the presentation layer. These technologies have the data persistence layer is not currently sup- been chosen as they are commonly used for ported but it is a simple task, which we are plan large enterprise applications today and thus to add soon (see Sect. 7). Automated Code Generation from System Requirements in Natural Language 85

In the rest of this section, we describe in value="#{ComputerSystem_ more detail all the generated elements produced ClerkSubmitsAnOfferOnBehalfOfASeller_ from a single use case. As a particular example, ClerkBBean.itemDescription}" />
the Clerk submits an offer on behalf of a Seller use case from the Marketplace example is used. a Seller (part)
SuD: Computer System 1 Clerk submits information describing an item. 2 System validates the description. The JSF page has a simple form with Extensions: an input field for the action argument 2a Validation performed by the system fails. and a submit button. The triggering ac- 2a1 Use case aborted. tion submitItemDescription has an argument itemDescription which is bound to the use case Sub-variations: backing bean variable. 2b Price assessment available. 2b1 System provides the seller with a price assessment. 5.2. Backing Beans The Procasor and the preprocessing step of According to the JSF framework, the pages are our generator produce the following procase: supported by backing beans, which are Java ?CL.submitItemDescription { classes containing all variables that can be set ( by the pages and handling all actions possibly #priceAssessmentAvailable; !Sl.providePriceAssessment activated by the pages. For the variables, BBs + provide setter/getter methods. Also, BBs pro- #validateDescription; vide methods for calls to the next tier – business ( delegators. #validationPerformedSystemFails; %ABORT The following listing shows the BB’s method, + which is called when a user submits the form on NULL the page. ) ) public String submitItemDescription() { } try { return computerSystem_ ClerkSubmitsAnOfferOnBehalfOfASellerBD 5.1. JSF Pages .submitItemDescription(getSessionObject() . getSellerBillingInformation (), itemDescription, All action pages are generated as described getSessionObject()); in 4.3.1. To allow easy testing, each page dis- } catch (DelegateException e) { e.printStackTrace(); plays the use case together with the correspond- } ing procase – both with the highlighted cur- return "abort"; rently processed action and acting entity. The } following listing shows a core of the generated Before the method call starts, the value of JSF page for the use case above. the form’s input field is automatically set via the BB’s setter method. The value is then used in the method as a parameter of the call to the

5.3. Business Delegator getComputerSystemManager() . validateDescription(itemDescription); Business delegators are Java classes created on if (Constants.computerSystem_ the basis of the Business Delegate pattern [17]. ClerkSubmitsAnOfferOnBehalfOfASeller_ validationPerformedSystemFails) { In the generated application, each use case has return NavigationConstants.ABORT; its own BD, which provides calls to the use case } EJBs. Internally, methods of BDs use the Ser- } vice Locator pattern [17] to locate EJBs. return NavigationConstants.CONTINUE; } The method shown in the listing only delegates calls to the use case EJB. The getBean method contains code for obtaining a use case 5.5. Entity Managers bean LocalHome interface, creating the bean, and returning the use case bean stub. The stub The entity objects are generated as entity man- is then used for the actual call. ager classes and they are accessed from the public String submitItemDescription(String beans, again using the Service locator pat- sellerBillingInformation, tern [17]. The methods of the managers print String itemDescription, ComputerSystem_ logs to a console (as explained in Section 4.3.3). ClerkSubmitsAnOfferOnBehalfOfASellerSO We do not show here the generated MGR as its sessionObject) { try { methods contain only these logger calls. return getBean().submitItemDescription( sellerBillingInformation, itemDescription, sessionObject); 5.6. Additional Elements } catch (BeanException e) { throw new DelegateException( In addition to the described elements, there are this .getClass (). getName() + several additional generated objects that are ".submitItemDescription()", e); used across the tiers. Namely, they are Value } } objects and Session objects. The former ones are generated and used for each type of arguments 5.4. EJB of the use case actions, while the later ones hold the value objects among different calls in a use The use case objects are generated as stateless case. session beans. There is no change against the The INIT procedure call is generated as the general process described in 4.3.2. init method of the corresponding use case EJB. The shown EJB method contains internal The special action %ABORT is not modeled as logic, i.e. actions located inside the triggered an exception but rather as a predefined constant procedure call are executed in this method. returned from the particular methods. The method body structure corresponds to the procase procedure call. Each action is generated as method delegating call to the 6. Evaluation and Related Work particular MGR. public String submitItemDescription(String To verify our generator, we used it on the Mar- sellerBillingInformation, ketplace application described in Sect. 2.1. The String itemDescription, ComputerSystem_ generated implementation was compiled and di- ClerkSubmitsAnOfferOnBehalfOfASellerSO rectly deployed to an application server. The sessionObject) { if (Constants.computerSystem_ implementation consists of approx. 70 classes ClerkSubmitsAnOfferOnBehalfOfASeller_ with 13 EJBs. The complete application has 92 priceAssessmentAvailable) { action, from which only 16 actions were gen- getSellerManager().providePriceAssessment(); erated with wrong arguments and had to be } else { repaired manually (we are working on an en- Automated Code Generation from System Requirements in Natural Language 87 hanced method of argument detection – see Similarly in [5], Java code fragments are Sect. 7). generated from the collaboration and class dia- Testing of the generated application discov- grams. The authors use enhanced collaboration ered a necessity to add one use case, two missing diagrams in order to allow better management extensions in another use case, and also sug- of variables in the generated code. gested restructuring other two use cases. All In [16], the use cases are automatically these defects could be detected directly from the parsed and together with a domain model are use cases but with generated application, they used to produce a state transition machine, became evident immediately. which reflects behaviour of the system. From the Our tool can be also viewed as an ideal high level view, the used approach is very similar application of the Model-driven Architectures to our solution but they allow for processing only (MDA) [11] approach. In this view, the uses very restricted use cases and thus the approach cases and domain model serve as a platform in- is quite limited. dependent model, which via several transformations are transformed directly into an executable code, i.e. platform specific model. 7. Conclusion and Future Work Currently, the existing tools usually generate just data structures (source code files, database The approach proposed in the paper allows for tables, or XML descriptors) from the UML class automated generation of executable code di- diagrams but no interaction between entities rectly from a requirement specification written (i.e. they handle just the class diagrams) and as use cases in a natural language. Also, we have as far as we know, there is no tool/project developed a prototype, which generates JEE ap- that generates the implementation from the de- plications via the proposed approach. scription in a natural language. Below, there Applications generated by our tool are im- are several projects or tools that take as an mediately ready to be deployed and launched input not only class diagrams but still they and they are suitable for testing the use cases work with diagrams and not with a natural (i.e. if the requirement specification is complete language. and well structured) and as a starting point for The AndroMDA [2] is the generator frame- the development of the real implementation. work which transforms the UML models into The proposed generator has several issues, an implementation. It supports transformations which suit for further improvements. An impor- into several technologies and it is possible to tant issue is connected with associations among add new transformations. In general, it works the classes in the domain model. The current im- with the class diagrams and based on the class plementation correctly handles just one-to-one stereotypes, it generates the source code. More- associations. The one-to-many or many-to-many over, it can be extended to work with other di- associations result in the code to lists or ar- agram types. A similar generator (made as an rays and therefore the determination of the ar- Eclipse extension) is openArchitectureWare [12], guments is more complex. We plan to solve as- which is a general model-to-model transforma- sociation limitation by analysis of sentence to tion framework. determine whether a method argument is the In [15], the sequence diagrams together with list or object itself. Also, we plan to add a class diagram are used to generate fragments of categorization of verbs to allow better manage- code in a language similar to Java. The genera- ment of arguments of the procedures. We plan tion is based on the order of messages captured to employ some platform independent template in the sequence diagram and the structure of framework which will enable to generate more the class diagram. There is also a proposed al- configurable system implementation for several gorithm for checking consistency between these platforms. The planned output of the generator two types of diagrams. then would be a XML file which will be an input 88 Jan Franců, Petr Hnětynka for the employed framework. Finally, we plan to tive environment for requirement specification. add generation of the data layer to applications. http://dsrg.mff.cuni.cz/~mencl/procasor-env. The required structure of the use cases [7] JBoss application server. http://jboss.org. (based on recommendations in [3]) can be seen [8] C. Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and as another limitation but we already have an Design and the Unified Process. Prentice Hall approach, which allows processing of use cases PTR, 2nd edition, 2001. with almost any structure (see [4]) and we are [9] V. Mencl. Deriving behavior specifications from incorporating it to the implementation. textual use cases. In Proceedings of WITSE ’04, Acknowledgements The authors would Linz, Austria, Sep. 2004. like to thank Vladimir Mencl, Jiri Adamek, and [10] Objecteering software. Objecteering 6. http: Pavel Parizek for valuable comments. This work //www.objecteering.com. was partially supported by the Czech Academy [11] OMG. Model driven architecture (MDA). OMG document ormsc/01-07-01, Jul. 2001. of Sciences project 1ET400300504. [12] openArchitectureWare. http://www.openarchitectureware.org. References [13] F. Plasil and V. Mencl. Getting “whole picture” behavior in a use case model. In Proceedings of [1] B. Anda and D. I. Sjober. Investigating the IDPT, Austin, Texas, USA, Dec. 2003. role of use cases in the construction of class dia- [14] F. Plasil and S. Visnovsky. Behavior protocols grams. Empirical Software Engineering, Volume for software components. IEEE Transactions 10(3), Jul. 2005. on Software Engineering, Volume 28(11), Nov. [2] AndroMDA. http://galaxy.andromda.org. 2002. [3] A. Cockburn. Writing Effective Use Cases. [15] L. Quan, L. Zhiming, L. Xiaoshan, and Addison-Wesley, Jan. 2000. H. Jifeng. Consistent code generation from [4] J. Drazan and V. Mencl. Improved processing UML models. UNU-IIST Rep. No. 319, The of textual use cases: Deriving behavior specifi- United Nations University, Apr. 2005. cations. In Proceedings of SOFSEM 2007, Har- [16] S. S. Somé. Supporting use cases based require- rachov, Czech Republic, Jan. 2007. ments engineering. Information and Software [5] G. Engels, R. Huecking, S. Sauer, and A. Wag- Technology, 48(11):43–58, 2006. ner. UML collaboration diagrams and their [17] Sun Microsystems. Core J2EE patterns: Best transformation to Java. In Proceedings of UML practices and design strategies. http://java.sun. ’99, Fort Collins, USA, Oct. 1999. com/blueprints/corej2eepatterns. [6] M. Fiedler, J. Francu, V. Mencl, J. Ondrusek, and A. Plsek. Procasor environment: Interac- e-Informatica Software Engineering Journal, Volume 3, Issue 1, 2009

Tool Based Support of the Pattern Instance Creation

Ľubomír Majtás∗

∗Faculty of Informatics and Information Technologies, Institute of Informatics and Software Engineering, Slovak University of Technology [email protected]

Abstract Patterns introduce very useful way of improving the quality of the software development process. Nowadays modeling tools and techniques provide some kind of support for modeling with pattern instances, but these are often based on manual pattern creation and connection to the rest of the model. Our approach presents the support of pattern instance creation on the model level in semi automatic way that simpliﬁes the whole process. The main idea of this approach is that the developer should assign the domain dependent parts of pattern and specify the requirements over the pattern variants. The rest of the pattern instance is to be created by the machine.

1. Introduction – Identification of pattern instances in existing codes. Pattern introduction [1] had large asset for more To solve this drawback, there were presented areas. Probably the most familiar pattern’s ful- many other works that extend the original cat- fillment in the software engineering was intro- alog by the different models that are trying to duced by the work of GoF [12], where the au- capture the core structure of patterns, e.g. [11], thors identified and in detail described 23 de- [13], [7]. sign patterns. Their description of each pat- In this paper we would like to introduce the tern contains the verbal description of its main approach that would support developers in their idea, the example of its appropriate usage (in- work with pattern instances. Nowadays model- cluding the source codes), the description of ing tools and techniques provide some kind of solution it offers and discussion about its al- support for modeling with pattern instances, ternatives and consequences of its usage. The but these are often based on manual pattern main part of description is presentation of the instance creation and connection to the rest of pattern model according to the OMT/UML the model. Our approach presents the support diagrams. The authors provided patterns’ ex- of pattern instance creation at the model level planations by examples and textual descrip- in semi automatic way that simplifies the whole tion so the catalog means a useful knowledge process. The core idea of the approach is that the base for software professionals. On the other developer should assign the domain dependent hand they did not try to present any “com- parts of pattern and specify the requirements puter friendly” knowledge that could be basis for over the pattern variants. The rest of the pat- automation of typical pattern processes which tern instance should be generated automatically. are: In this paper we will analyze the processes tak- – Creating of pattern custom instances, ing place while creating the pattern instance. We – Validating existing pattern instances, will identify the places where can be this process 90 Ľubomír Majtás automated. Finally we will provide our approach In our approach we look for possibilities for of automation in a way that will support but not automation of the pattern instance creation. We limit the developers. see higher potential in the process of concretization than in process of specialization. The specialization is based on the ability of developer to 2. Process of the Pattern Instance move the pattern to the particular target soft- Creation ware environment. It can be seen as a domain based pattern description, what we consider as Process of the pattern instance creation means almost impossible to be performed by the ma- the application of the solution offered by the pat- chine. There can be found only minimal space tern to the environment of the developed soft- for automation of this process. On the other ware system. The inputs of this process are the hand, there is a potential for tool based support actual environment of the developed software of concretization process. When the pattern in- and the general description of the pattern. As stance is correctly specialized, its concretization the output we consider modified software sys- is often based more on pattern structure descrip- tem extended by correctly created instance of tion than on developer’s skills. It means that the pattern. there is a space for automation of this process. We distinguish two activities that are necessary to follow out while creating the pattern 2.1. Pattern Roles, Domain Dependency instance [15]: abstract and general pattern instance needs to be concretized and specialized. Patterns are often being described as a collection At the first moment both activities seem to be of cooperating roles. These roles can be often similar, but it is not so. Each one moves the divided into two groups: roles dealing with the first idea of the pattern application to the final domain of the created software system (domain instance, while it is necessary to follow up both, roles) and roles performing the pattern’s infras- to be able to declare the pattern instance as the tructure (infrastructure roles). The domain roles correct one. Differences between these activities can be considered as the “hot spots” while they are presented in the Figure 1, where the degrees can be modified, added or deleted according of generality and abstraction are being presented to the requirements of the particular software in two dimensional space (degree of generality environment. The roles performing the pattern horizontally, degree of abstraction vertically). infrastructure are not changing frequently be- The created instance is becoming more con- tween the pattern instances. Their purpose is crete when it contains more building blocks cre- to glue the domain roles together to be able to ating the correct instance. To the beginning perform desired common functionality. abstract idea of the pattern application there One of the main contributions of the whole are subsequently being added classes, their at- pattern approach is that it allows thinking at the tributes, methods and relations until instance higher level of abstraction. Developers do not becomes complete. Specialization of the instance have to always keep in mind all details about means the movement of the general pattern de- the solution, they can work with the pattern in- scription to the context of the developed system. stance as with single unit hiding unnecessary The specialization follows such modifications of complexity. When the developer thinks about the pattern instance that make the instance do- applying the pattern to the project, first thing main specific and subsequently specific for the he needs to decide is how to connect pattern current software system. As the examples of the instance to the context of the software. He does specialization steps we can consider definitions so be specifying the domain roles’ participants. of roles’ participants count, naming of the par- The other issues are often second-rate at that ticipants or creating the relations between par- moment. Table 1 describes selected patterns and ticipants according to the domain. Tool Based Support of the Pattern Instance Creation 91

Figure 1. Two dimensional space of generality and abstraction [15]

Table 1. Specialization of the domain dependent pattern roles Pattern Domain dependent roles Description Composite Leaf and its Operations Leafs and their operations provide all domain dependent functionality. Everything else is just infrastructure allowing the hierarchical access to the leaf instances. Chain of HandleRequest, Ancestor The domain dependent is the business logic process- Responsibility ing the event and the ancestor to which should be the unprocessable event passed. Decorator Concrete Component, The domain dependent are the Concrete Component Concrete Decorator (which often exists before Decorator pattern application) and functionality of Concrete Decorator participants that provide extended functionality to the Con- crete Component. Flyweight Concrete Flyweight Concrete Flyweight provides all domain dependent functionality. The rest is infrastructure for storing instances in memory and providing access to them. Proxy Real Subject, Proxy The domain dependent is the Real Subject (which often exists before Proxy pattern application) and functionality of Proxy participants that provide access to the Real Subject. their roles from the perspective of the domain tomizing instance according our needs. By the dependency. variability we do not understand definition of participants playing defined roles. 2.2. Pattern Variability General understanding of the patterns does not always satisfy the ideas of their authors. As the pattern variability we understand the Many developers understand design patterns possibility to provide patterns functionality in only as constant templates with strictly speci- slightly different ways. Each variant of the pat- fied purpose of each class, attribute or method. tern has its own pros and cons and therefore the However the original idea was to discuss a prob- decision which variant to select does not need to lem and offer a solution. Examples provided be easy. Selecting the proper variant is part of with pattern description were never meant as pattern instantiation process, when we are cus- the only best solutions. Their purpose was to 92 Ľubomír Majtás

Table 2. Examples of possible variants of pattern instances Pattern Variability description Abstract Factory Class structures do not differ much. Majority of variants are dealing with realizations of ConreteFactories: they can be implemented normally or as Singletons, they can employ Factory Method or Prototype patterns. Adapter There are more different variations how can Target, Adapter and Adaptee communicate together. Bridge Possible variants: Omitting the Implementer interface in case of the only one ConcreteImplementor. Chain of References to the successor can be maintained commonly in Handler or responsibility custom for each ConcreteHandler. Handler can be a class with default for- warding functionality or just an interface. Flyweight The Flyweight interface can be omitted. provide hint, to show one of many possible ways cording the user needs. In Table 2 we present of idea realization. examples of possible variabilities of selected GoF When we look closer on the patterns from design patterns. the GoF catalog, we can distinguish differences of examples generality between patterns. On the 2.3. Pattern Instantiation Support one side stands Singleton. It is very simple with in CASE Tools accurate example that is not keeping much space for different variations while it prescribes all de- Many existing CASE tools are trying to pro- sired functionality. On the other side we can vide some kind of support in pattern instan- see patterns such as Memento. Their examples tiation process. The level of such support dif- are very general; they do not provide expected fers. Often they allow inserting of example pat- functionality but only briefly draft the solutions. tern instances to the model. The others can Their concrete instances can be far different run wizards through which developer can spec- from the presented examples. In the middle of ify the participant count of the selected roles these extremes stands majority of the patterns. and specify the name for each one. In general Their examples are able to provide desired func- the support is based on single template, where tionality while they are keeping a space for their the developer can or cannot specify the partic- customization. Typical representatives are Com- ipants before the creation of the instance. Ad- posite, Observer or Decorator. vanced CASE tools are tacking the informa- From the perspective of tool based support tion about pattern occurrence (often by UML of instantiation, it is very difficult to create sup- Collaboration element). This helps the further port for instantiation of pattern with very gen- developers to identify the pattern with min- eral examples. It would be very difficult (if it is imal effort and thereby it reduces the risk even possible) to automatically instantiate fully of instance damage that can happen by im- functional Memento that would fit to the rest of proper modifications in later project phases the system. On the other hand there are mini- (e.g. maintenance). However, these tools do not mal difficulties for pattern with strictly defined try to automate the process pattern instan- structure keeping minimal space for variability. tiation – participants of all roles need to be Pattern such as Singleton can be automatically specified by developers. Alike the support for instantiated with minimal efforts. The simple other kinds of customizations is often omitted; template based instantiation would be sufficient. it is left to developers’ knowledge and expe- For the majority of patterns the simple template rience to modify the instance according their based approach cannot cover all known variabil- needs. ity, such approach cannot be considered as suf- Employing the automation of pattern instan- ficient. In this case we need to employ approach tiation in CASE tools can lead to the following that is based on templates that are created ac- benefits: Tool Based Support of the Pattern Instance Creation 93

– Developers do not need to perform typical 3.1. Pattern Inner Structure Description modifications manually. By minimizing the effort that needs the developer to perform To be able to provide machine based pattern to create pattern instance or by giving him processing, we require precise models of the pat- possibility to select the proper pattern vari- terns’ inner structures. We are using custom role ant they can save time and avoid mistakes, based models which are defining the collabora- so the instantiation process becomes more ef- tions between the roles that perform the prede- fective. fined functionality. As the roles we do not con- – Developers do not need to know all pattern sider only ones typically played by classes but complexity or inner structure. They can fo- also ones which participants are attributes or cus on the domain dependent context of the methods. Only the definitions of the roles do pattern; they “do not need to care” about not capture whole pattern inner structure and the rest. This can help the inexperienced de- therefore cannot be used as the blueprint for the velopers with pattern application, and in this machine based pattern instance creation. The way support them to utilize patterns in their very important parts of the pattern structure everyday work. are the definitions of the inner structure con- – Developers can be informed about possible straints. These constraints associate roles that variants. Sometimes developers do not have are somehow linked together. Example of such to know about existence of different pat- constraints can be clearly seen in the Abstract tern variant. When they are informed im- Factory pattern where the roles createProduct() mediately about more possibilities they can of Abstract Factory and Abstract Product are choose most proper variant without former linked together. It means that there has to be knowledge about it. Developers are able to the same count of participants of this role where get best from the pattern application. each participant of the createProduct() role is responsible for creation of the appropriate participant of the Abstract Product. The exact def- 3. Our Approach of the Tool Based initions of constraints are very important in the Support process of machine based pattern instantiation while they help to specify the count of all par- In the previous sections we have described why ticipants and set the proper links between them. should we consider the tool based support for We have identified and capture in our models the the pattern instance creation and where are the following relationships which are bases of con- spots for the automation. In this section we straints: will describe how can be such automation pro- 1. Inheritance – inheritance between classes, vided. We focus on two different ways of sup- 2. Association – associations between classes, port. The first one is dealing with the process of 3. Overriding – in case of inheritance where the instance creation, it lets the developer to define one method role overrides the other method domain based participants and automatically role, supplement infrastructure participants to form a 4. Method delegation – one role invokes other valid instance. The second one provides support role to delegate the functionality, for pattern variability; it informs the developer 5. Instance creation – role creates the instances about possible variants of the pattern, asks for of other role, desired ones and automatically reasons the valid 6. Class linked with its members – role which configuration according the developer’s choice. participants are regularly classes and can be The result of this step is the role based model of played by more than one participant needs the proper pattern configuration, which comes to be explicitly linked with its method and as an input for the first mentioned support. attribute roles. 94 Ľubomír Majtás

Some roles are part of definition of more than ticipant Constraint Matrix are depicted in one constraint. For example in the Abstract Fac- the Figures 2, 3 and 4. tory pattern the count of participant of role Con- In the following section we describe the steps crete Product is dependent on count of partic- of the algorithm creating the pattern instance. ipants of roles Concrete Factory and Abstract We will describe the algorithm also on example, Product. We say that the dimension [13] of the each step will contain example of execution re- role Concrete Factory is two because it is part sults of this step. In our example we will create of two different constraints. the instance of the pattern Composite. As the input we get the incomplete instance containing 3.2. Algorithm of the Pattern Instance only partial definitions of two participants of the Creation domain role Leaf: Leaf1 containing the Opera- tion1() and Leaf2 containing the Operation2(). Our process of pattern instance creation is based The algorithm will create the correct instance on supplementing the incomplete pattern in- according these inputs. The algorithm takes the stance defined by developer. As the inputs the following steps: algorithm requires proper role based pattern 1. Add participants of non constrained roles. model (according to the previous section) and Create the participants of the roles that are the partially created pattern instance contain- not concerned in any constraint. For each ing some participants of the domain role. The role create exactly one participant and name algorithm progressively adds the missing partic- it as the role. Create the links that are re- ipant to comply the pattern’s inner structure lated to the new participants. description and all constraints of the pattern. Example: Add the participants of roles Com- The output of the algorithm is the model of pat- ponent, Composite, Composite’s childs and tern instance containing all participants that are links between them: generalization and asso- meeting all constraints. ciation. The algorithm stores information about all 2. Create the empty Participant Constraint Ma- participants which are part of the pattern in- trix. Create the empty PCM according to the stance at the moment. Moreover it stores in- definition of pattern constraints. formation about instances of all constraints 3. Initialize the PCM according to the current connecting the linked corresponding partici- of the pattern instance. Fill the PCM with pants. Some roles are present in more con- already created the participants. straints (their dimension is more than one) Example: Fill the PCM as depicted in the what causes that instances of constraints Figure 2. overlap over the participants of such roles. 4. while (the PCM contains empty fields) Therefore the algorithm stores the informa- a) Add participant to fill one empty field of tion about instances of constraints in the PCM. Select one empty field of the PCM n-dimensional structure where n is the maxi- and create the participant that will fit mum dimension of all pattern roles (the GoF to this field. When selecting the empty pattern do not have roles with dimension fields, start with class participants and more than 2). We call this structure Partici- continue with association and method pant Constraint Matrix (PCM). Each dimen- participants. Prefer empty fields with sion of this matrix corresponds to one pat- lower dimension. tern constraint. Lines in this dimension rep- Example: In the first iteration create the resent the instances of constraints. These in- participant of role Component’s Opera- stances of constraints link corresponding par- tion(). ticipants according to the constraint. Lines b) Add information related to the added cross in the places of more dimensional par- participant. Fill the information about ticipants. Examples of partially filled Par- the new participant and add connections Tool Based Support of the Pattern Instance Creation 95

Figure 2. Initial Pattern Constraint Matrix for incomplete instance of pattern Composite

Figure 3. Extended of Pattern Constraint Matrix after adding Component’s Operation()

Figure 4. Pattern Constraint Matrix for complete instance of pattern Composite 96 Ľubomír Majtás

with the other participants that are requirements elicitation and analysis, help in es- lated to the new one, e.g. generalization, timating development cost and effort, and pro- overriding, association, delegation, etc. vide a basis for automated product configura- Example: Connect the participant with tion. Feature models are also important in gen- Leaf’s Operation1() with overriding re- erative software development which is trying lationship. Name the participant Oper- to automate application engineering based on ation1() because the overriding relation- system families. ship needs the same name of the linked In our approach we use the feature models participants. Extended PCM by this step to capture possible variants of the patterns. The is depicted in the Figure 3. model depicted in the Figure 5 presents selected After successful execution of the algorithm variabilities of the Composite pattern. It says the pattern model of the instance is created. It for example that participant of the role Compo- complies with all rules and constraints coming nent can be either the interface or the abstract from the pattern description. The created model class or that the processing method of the Com- keeps information about the role that partici- posite’s children role can be omitted, present pants play and therefore can be used for further only in the Composite or in the whole struc- source code generation of the pattern instance. ture. The feature model also presents relations PCM for the complete pattern instance is de- between the features. For example it is not pos- picted in the Figure 4. sible to omit these processing methods when the Composite’s children is private attribute. Such 3.3. Pattern Variability configuration would disable the whole pattern’s functionality because the structure would be- As mentioned in previous sections patterns are come unmodifiable. not simple units with the only one valid tem- The presented model is considered only as an plate. Most of them are highly customizable al- example. It does not cover all the variabilities lowing changes in their example templates in such as the way of Composite’s children collec- many different ways. In this section we describe tion realization. the approach of employing the variability to the instantiation process. The result of this step is 3.3.2. Configuration Reasoning role based model describing the customized pattern template that stands as an input for previ- When creating a pattern instance, developer ous algorithm. needs to specify his requirements dealing the variability. The target is to specify whole fea- 3.3.1. Variability Modeling ture selection (also called product configuration), which is a group of desired functional ca- To capture possible variability, we are employ- pabilities that constitute a complete configura- ing feature modeling technique that was origi- tion of an application and adhere to the con- nally designed for the product-line engineering straints specified in the feature model. We do [6]. It is important for capturing and manag- not want to force the user to provide information ing commonalities and variabilities in product about each feature whether he wishes to employ lines throughout all stages of product-line engi- it or not. We give him a chance to specify which neering. In early stages it is used for scoping of features he wishes to employ and the rest of the product line (i.e. deciding which features should configuration is set by the tool. The final con- be supported by a product line). In product-line figuration has to fulfill all constraints defined by design, the variation captured from feature mod- the feature model, so if the developer’s require- els are mapped to product-line architecture comments do not meet these constraints or do not mon for all parallel product lines. In the prod- allow creation of valid configuration, the devel- uct development, feature models can drive re- oper has to be asked to change his preferences. Tool Based Support of the Pattern Instance Creation 97

Figure 5. Feature model example capturing the Composite pattern variability To reason a valid configuration we trans- be present in parent class or only in child form the feature model and partial configuration classes. based on developers preferences to Constraint – Define the implementation aspects relevant Specification Problem (CSP) environment and for code generation apply existing CSP solver to reason final con- – Specify the form of participants’ real- figuration or to notify us about impossibility izations. For example they can specify to finish this task. To create the CSP from whether class role would be played by class a feature model we apply transformation rules or interface or whether list will be realized specified in [2]. As the CSP solver we chose as array, linked list, map or something else. Choco CSP [4] which is an open source Java – Specify the participants’ visibilities: Pub- based software. lic/Private/Protected. The definition of the roles occurrence or positions 3.3.3. Final Model prescribes the output role based model. It is provided by reduction of the general pattern tem- When the configuration is set up, we are able to plate containing all variability roles. This tem- provide concrete role based model of the pattern plate contains all roles including the conditions instance. The variants represented in the feature when should be these role applied (which feature model have several possible impacts to the final needs to be part of the configuration to activate instance, while they can: the variability role). The Figure 6 contains such – Prescribe the role based model template for the Composite pattern according the – Specify the occurrence of the role, whether features presented in the Figure 5. The variability participants of the role should be part of roles are filled grey and the activating features are pattern instance or not. placed next to them as a bold text. According the – Specify the position of the role. For exam- current configuration, the variability roles with ple specify, whether the operation should features that are not contained in the configura- 98 Ľubomír Majtás

Figure 6. Role based template of the Composite pattern extended by variability roles

tion will be omitted, the rest will form the final 1. Inquire the user about pattern he wishes to role based model according the input configura- instantiate; tion. 2. Inquire the desired domain participants; As an example, when we take the Compos- 3. Inquire the desired variants of the pattern; ite’s feature model from the Figure 5 and select 4. Reason pattern configuration; the following variants: Parent tracking – Get- 5. Create the role based model for the reasoned Parent() realization in Component and the Chil- configuration; dren list manipulation – No processing methods. 6. Supplement all missing participants from the The final role base model representing the con- incomplete user specification according the figuration received from the previous inputs is actual role based model; depicted in the Figure 7. 7. Create the instance of the pattern. In general the user is inquired for the domain 3.4. Overall Instantiation Process dependent information and customizations while the tool creates the pattern instance satisfying the Presented approaches form a complex process user needs. The architecture scheme of the overall of computer aided pattern instantiation deliber- approach is sketched in the Figure 8. The general ating the pattern variability. It consists of the input for the entire process is role based pattern following steps: model containing all variability roles. Variabil- Tool Based Support of the Pattern Instance Creation 99

Figure 7. Example of output role based model according the custom configuration ity support module reduces this model into the by the other authors. Ó Cinnéide et. al. [5] concrete role based model for the custom pattern have presented a methodology for the creation of configuration inferred from developer’s variants behavior-preserving design pattern transforma- selection. Pattern instance creation module takes tions and applied this methodology to GoF de- this model and according to it and developer’s sign patterns. The methodology is taking place specification of domain dependent participants in refactoring process when it provides descrip- creates the final pattern instance. This final in- tions of transformations to modify the spots stance reflects the developer’s variants selection for pattern instance placement (so called pre- and pattern domain specialization. cursors) by the application of so called mi- cropatterns to the final pattern instances. While 3.5. Realization Ó Cinnéide’s approach is supposed to guide the developers to pattern employment in the phase The presented approach was partially imple- of refactoring (based on source code analysis), mented and verified. It was realized as the Briand et. al. [3] are trying identify the spots for plug-in of the Rational Software Modeler which pattern instance in design phase (based on UML is based on open source platform Eclipse. The model analysis). They provide semi-automatic Figure 9 contains screenshots of the model be- suggestion mechanism based on decision tree fore and after the execution of the overall pat- combining evaluation the automatic detection tern instantiation process. As the inputs for this rules with user queries. scenario we have used the inputs of the examples There exist several approaches introducing presented in former sections. their own tool based support for the pattern instantiation. El Boussaidi et. al. [10] present model transformations based on Eclipse EMF 4. Related Work and JRule framework. Wang et. al. [16] provide similar functionality by XSLT based trans- Different approaches of automating the pattern formations of the models stored in XMI-Light utilization in software projects were introduced format. Both approaches can be considered as 100 Ľubomír Majtás

Figure 8. Architecture overview of the overall approach the single template driven while they are fo- We have not found any approach regarding cusing most on the transformation process and the feature modeling application in pattern in- do not set a space for the pattern customiza- stantiation area. The feature models were suc- tions. More advanced method was introduced cessfully employed in other areas, for example by Mapelsden et. al [14]. Their approach sup- in automation attempt of enterprise application ports instance configuration by specifying the configuration presented by White et. al. [17]. role participants including those playing more dimensional roles. All of these approaches are based on strict forward participants generation 5. Conclusion and the Future Work – participants of all roles are created according the single template. Our approach accen- In this paper we have presented our approach tuates on collaboration between the developer dealing with a tool based support for pattern and the CASE tool. We do not intent to create instance creation. Our key concept was to cre- all pattern participants. We let the developer ate such methodology that would help the devel- define the ones he needs and subsequently we opers with application of the pattern solution infer and create the rest ones to form a valid to their software but allow them to customize instance. We do not force the developer to our the pattern according their needs. We were try- solution, we let the template and the final in- ing to handle two different courses while more stance be customized according the developers’ generative parts often mean less space for cus- needs. tomization and vice versa. We believe that our All the former approaches were focusing on approach balances these opposing courses into the creation of pattern instances. The ones pre- final solution in a way that forms useful a tool sented by Dong et. al. presume the presence of for developers interested in pattern employment. the pattern instances in the model. They are In the future we would like to extent the cre- providing the support for the evolution of the ated pattern instance model with behavioral in- existing pattern instances resulting from the ap- formation. The correctly created instance would plication changes. The first one [8] implemen- be represented class diagram together with se- tation employs QVT based model transforma- quence diagram. The main building blocks of tions, the other one [9] does the some by the such behavioral model will be method invoca- XSLT transformations over the model stored as tion and delegation, instance creation together XMI. However, both are working with the single with structural blocks such as condition or it- configuration pattern template allowing only the eration over collection. Also we would like to changes in presence of hot spots participants. prepare definitions of more GoF design pattern Other possible variabilities are omitted. to evaluate the algorithm on the larger scale. Tool Based Support of the Pattern Instance Creation 101

Figure 9. Screenshots of models before and after the overall process execution We are thinking about other patterns that can [5] M. Ó Cinnéide and P. Nixon. Automated be input for the algorithm. It could be applica- software evolution towards design patterns. ble on all patterns that are at the design level In Proceedings of the 4th International Work- of abstraction and their inner structure can be shop on Principles of Software Evolution, pages 162–165, Vienna, Austria, 2001. ACM. described by relation based constraints. Candi- [6] K. Czarnecki, S. Helsen, and U. Eisenecker. dates for such patterns are for example the J2EE Staged conﬁguration through specialization and design patterns. multilevel conﬁguration of feature models. Software Process: Improvement and Practice, References 10(2):143–169, 2005. [7] J. Dietrich and C. Elgar. A formal description of [1] C. Alexander, S. Ishikawa, and M. Silverstein. A design patterns using owl. In ASWEC ’05: Pro- Pattern Language: Towns, Buildings, Construc- ceedings of the 2005 Australian conference on tion. Oxford University Press, August 1977. Software Engineering, pages 243–250, Washing- [2] D. Benavides, P. Trinidad, and A. Ruiz-Cortés. ton, DC, USA, 2005. IEEE Computer Society. Automated reasoning on feature models. In [8] J. Dong and S. Yang. Qvt based model transfor- LNCS, Advanced Information Systems Engi- mation for design pattern evolutions. In IMSA neering: 17th International Conference, CAiSE ’06 : Proceedings of the 10th IASTED interna- 2005. Springer, 2005. tional conference on Internet and multimedia [3] L. C. Briand, Y. Labiche, and A. Sauve. Guid- systems and applications, pages 16–22, 2006. ing the application of design patterns based on [9] J. Dong, S. Yang, and K. Zhang. A model trans- UML models. In ICSM ’06: Proceedings of the formation approach for design pattern evolu- 22nd IEEE International Conference on Soft- tions. In ECBS ’06: Proceedings of the 13th An- ware Maintenance, pages 234–243, Washington, nual IEEE International Symposium and Work- DC, USA, 2006. IEEE Computer Society. shop on Engineering of Computer Based Sys- [4] Choco constraint programming system. http: tems, pages 80–92, Washington, DC, USA, 2006. //choco.sourceforge.net/. IEEE Computer Society. 102 Ľubomír Majtás

[10] G. El Boussaidi and H. Mili. A model-driven eth International Conference on Tools Pacific, framework for representing and applying de- pages 3–11, Darlinghurst, Australia, Australia, sign patterns. In COMPSAC ’07: Proceed- 2002. Australian Computer Society, Inc. ings of the 31st Annual International Computer [15] M. Smolárová, P. Návrat, and M. Bieliková. Software and Applications Conference, pages A technique for modelling design pat- 97–100, Washington, DC, USA, 2007. IEEE terns. In JCKBSE ’98: Proceedings of the Computer Society. Knowledge-Based Software Engineering, pages [11] R. B. France, D.-K. Kim, S. Ghosh, and E. Song. 89–97. IOS Press, 1998. A UML-based pattern specification technique. [16] X.-B. Wang, Q.-Y. Wu, H.-M. Wang, and IEEE Trans. Softw. Eng., 30(3):193–206, 2004. D.-X. Shi. Research and implementation of [12] E. Gamma, R. Helm, R. Johnson, and J. Vlis- design pattern-oriented model transformation. sides. Design patterns: elements of reusable In ICCGI ’07: Proceedings of the International object-oriented software. Addison-Wesley Pro- Multi-Conference on Computing in the Global fessional, 1995. Information Technology, page 24, Washington, [13] J. K. H. Mak, C. S. T. Choy, and D. P. K. Lun. DC, USA, 2007. IEEE Computer Society. Precise modeling of design patterns in UML. [17] J. White, D. C. Schmidt, K. Czarnecki, In ICSE ’04: Proceedings of the 26th Inter- C. Wienands, G. Lenz, E. Wuchner, and national Conference on Software Engineering, L. Fiege. Automated model-based configura- pages 252–261, Washington, DC, USA, 2004. tion of enterprise java applications. In EDOC IEEE Computer Society. ’07: Proceedings of the 11th IEEE International [14] D. Mapelsden, J. Hosking, and J. Grundy. De- Enterprise Distributed Object Computing Con- sign pattern modelling and instantiation using ference, page 301, Washington, DC, USA, 2007. dpml. In CRPIT ’02: Proceedings of the Forti- IEEE Computer Society. e-Informatica Software Engineering Journal, Volume 3, Issue 1, 2009

Transformational Design of Business Processes in BPEL Language

Andrzej Ratkowski∗, Andrzej Zalewski∗, Bartłomiej Piech∗∗

∗Institiute of Control and Computation Engineering, Warsaw University of Technology ∗∗Department of Electronics and Information Technology, Warsaw University of Technology [email protected], [email protected], [email protected]

Abstract A transformational approach to the design of executable processes in Business Process Execution Language (BPEL) is presented. It has been built upon the transformations of business processes accompanied by a formal approach based on process algebras used to verify the behavioral equivalence of business processes. The initial business process can be denoted in BPEL, then a series of transformations is executed upon it. The process resulting from the transformation is verified whether it preserves behaviour denoted by the process being transformed. The transformations improve non-functional properties of the process (performance, modifiability, granularity, maintainability) but do not change its original behaviour. The transformations are steered by Archi- tecture Trade-off Analysis Method (ATAM) that shows the direction of changes and helps an architect to decide which of them to apply. An example of the application of our approach in real-life business process design has also been presented. The paper presents general idea of the design process, theoretical basis of the method as well as experimental verification of the approach and a tool implemented to support the method.

1. Introduction ing and verification techniques suitable for those processes. The following paper presents the concept of de- The approaches presented above, as well as sign method that is a subject of PhD thesis writ- the verification techniques, can indicate absence ten by Andrzej Ratkowski under Prof. Krzysztof or existence of certain flows in BPEL processes. Sacha’s supervision. The article is an extension However, these are not methods of business proof a previous paper [26]. cesses design – they do not provide any guid- The ability to define and execute business ance on how to improve the quality attributes processes seems to be one of the most important of designed systems like maintainability, per- advances introduced by the research and com- formance, reusability etc. This is what the ap- mercial developments on Service-Oriented Ar- proach is aimed at. chitectures (SOA). The worlds of business mod- In this paper we advocate an idea of trans- elling and software systems development have formational design of BPEL business processes never been closer to each other – it is now pos- in which specified behaviour remains preserved, sible to express software requirements in terms while quality attributes get improved. There are of services and business processes composed of three basic roots of our approach: them. BPEL have become a standard for defin- 1. software refactoring – the approach intro- ing executable business processes. This in turn duced by Opdyke in [24], further devel- triggered an extensive research on the model- oped in [20], in which the transformations 104 Andrzej Ratkowski, Andrzej Zalewski, Bartłomiej Piech

of source code are defined so as to improve 2. modeling – the purpose of this part is to its quality attributes; model and make conclusions on process exe- 2. business process design – in the realm of cution before its practical application; SOA informal or semiformal methods domi- 3. execution – in execution phase processes are nate the research carried out so far – comp. put into practice and run in physical envi- Service Responsibility and Interaction De- ronment; sign Method (SRI-DM) [21]; 4. monitoring – running processes are moni- 3. business process equivalence – there have tored, functional and non-functional proper- already been developed several notions of ties are measured; the equivalence between business processes 5. optimization – this phase is responsible for based on Petri Nets [19] and Process Alge- improvement of processes. bras [29]. The BPM concept is broadly applied in the pro- The transformations of Business Processes cesses domain, however, we believe that there is are in the core of our approach and repre- no specialised application in SOA context. Cur- sent similar concept as popular software refac- rent paper tries to fill this gap. torings. Our original notion of business pro- In the field of general process modeling there cess equivalence has been introduced on a for- are approaches based on Unified Modeling Lan- mal Process Algebra model of business pro- guage (UML) like presented in [28]. The authors cesses (explained and discussed in section Be- present suitability of UML activity diagrams for havioural Equivalence) and it has been proved business process. that the defined transformations create pro- In the context of Service Oriented Archi- cesses equivalent to the one being trans- tecture there exist special methods devoted to formed. These transformed processes are com- design business processes like mentioned pre- pliant in terms of their behaviour, however, viously Service Responsibility and Interaction they have quality attributes changed. These Design Method (SRI-DM) [21]. The SRI-DM transformations may be steered by the qual- method is based on transformation from UML ity scenarios and assessments performed us- use-cases towards services with proper divided ing Architecture Trade-off Analysis Method functionality and sequence diagrams that ex- (ATAM) [18]. press desired process. This provides a foundation for the trans- The approach similar to proposed in the cur- formational design method in which a starting rent paper is presented in [15]. The authors pro- BPEL process is subject to a series of trans- pose modeling business process as a Petri net formations yielding as a result behaviourally and such transformations of the net to reach op- compatible model with improved non-functional timal value of some goal function. The proposed properties like modifiability, maintainability, approach is based on optimization techniques. performance, reusability etc. The research of the current paper is concentrated on converting BPEL processes to one of the formal models that can be subject to 2. State of the Art model-checking techniques. A survey of such approaches can be found in [3]. It reveals that all Many business processes design and mainte- of the most important formal models of con- nance methods are based on Business Process current systems have been applied: Petri nets Management (BPM) concepts [31]. According to (basic model, high-level, coloured) – comp. [14], BPM, process life-cycle consist of five phases: [32], Process Algebras – comp. [12], [11], Lotos – 1. design – existing business processes are anal- comp. [9], [30], Promela and LTL – comp. [13], ysed and “to-be” processed are designed. The [16], Abstract State Machines – comp. [8], [27], results of this phase are: process flows, main Finite State Automata – comp. [11]. These con- actors, resources and so on; versions make it possible to detect deadlock and Transformational Design of Business Processes in BPEL Language 105

Figure 1. Process transformation algorithm livelock as well as reachability analysis with au- transformations is possible and a smaller tomated model checkers. subset is rational. 2. A few independent refactorings on a current process make a few alternative pro- 3. Process Transformation Design cesses which should be equivalent to the orig- Approach inal process or at least changes in behaviour should be known. The algorithm of process transformation design 3. Behaviour preservation is checked by means is depicted in Figure 1. of behavioural equivalence verification step. 1. As it was mentioned in the introduction, the In this step formal methods of Process Alge- algorithm starts with the original process bra (PA) [6] are used. The result of verifica- that is delivered by business oriented staff tion is either elimination of not-equivalent al- and the primal process bring up only func- ternative or accepting changes in behaviour tional aspects of the process. Functional as- that the transformation makes. The way the pects of the process are: necessary activities, transformation changes behaviour is exactly order of activities, relation between them, known owing to PA formalism. exchanged data, basic external services invo- 4. After eliminating or accepting, all alterna- cation and so on. The process is called refer- tives that are left are evaluated against in- ence process. In following iterations the origi- teresting non-functional properties like: nal process is slightly changed by refactoring – performance, transformations [25], [20] like: – safety, – service split – split one complex services – maintainability, into two or more smaller ones that cover – availability, the primary one functionality, – or any important property. – service aggregation – opposite to service The measure of each property is calculated split – composing two or more services in by using specified metrics, models [7] or sim- one larger service, ulations. – parallelization – making serial activities 5. In the following step one alternative is se- to run parallel, lected amongst others. The selection is based – asynchronization – reconstruction of on Architecture Trade-off Analysis Method communication protocol from syn- (ATAM) [18]. In short, the method exam- chronous to asynchronous. ines sensitivity of non-functional parameters The above transformations are called to design properties and marks out trade-off refactorings and they are only exam- points. Trade-off points are decision variables ples of possible refactorings. Obviously, that affect more than one quality attributes. in a given process only some subset of Changing the value of trade-off points in- 106 Andrzej Ratkowski, Andrzej Zalewski, Bartłomiej Piech

creases some quality attributes and decreases tailored to BPEL analysis. During our research others. In case of SOA, services granulation we used LOTOS [2] realisation of PA. is an example of such trade-off point. When Using the LOTOS notation, one can model services are bigger and not numerous then we any process or chain of communicating pro- have good performance and weak maintain- cesses, simulate processes execution and, what ability and reusability. If we split the system is the most important in the context of refactor- into more services, performance will decrease ing, verify equivalence of two different processes. but maintainability and reusability will in- The equivalence is verified by simulation, bisim- crease. ulation or preordering analysis [6]. 6. After selecting one alternative process, the To be able to use PA in stated problem it selected process becomes new reference pro- is necessary to use some kind of mapping from cess and the algorithm returns to the begin- BPEL activities to PA terms. There are a few ning. existing BPEL to PA mappings [10, 4], but none The above steps lead from process that is correct of them exactly fit to the needs of transforma- from functional point of view to process that has tional process design. Firstly, because they de- best or acceptable good non-functional quality mand full semantic checking in equivalence ver- attributes. ification, that is too precise for refactoring. In All steps of the algorithm are guided by a hu- case of the refactoring equivalence verification, if man designer and supported by automatic tools one process is transformed, its semantic changes that may: but its behaviour does not. Another aspect is – suggest possible transformations of a refer- that an important property of mapping BPEL ence process, to PA for refactoring is that it has to make sim- – verify behavioural equivalence, ple models with possibly the smallest statespace – compute quality metrics of alternatives, – during the design procedure there are a few – point out trade-off points. changing scenarios and each of them has to be The conclusion is that the transformational verified – the time spent for one verification is approach does not try to make a to- limited. This is the motivation for us to develop tally automatic process design, because, in new mapping. Mappings of BPEL activities to our opinion, it is impossible without hu- PA formulas are presented in Table 1. man ability involvement. Instead, the trans- The mappings do not take into account data formational method supports a human de- values or condition probability. This is moti- signer’s creative work in tasks difficult for vated by simplification (and better verification a human. performance) of the model. From another point of view, making some assumptions, there is no actual need to examine values of variables in 4. Behavioural Equivalence equivalence verification. There is an artificial mapping of activity Behavioural equivalence verification is based on which is not explicit part of BPEL but is nec- Process Algebra transformation and manipula- essary for equivalence verification. This is action of BPEL processes [6]. tivity dependency mapping. Let us assume that there are two activities in BPEL process that 4.1. Process Algebra for Behavioural are not directly attached to each other (by e.g. Equivalence or ) but by shared variable, like in the following example: Process Algebra (PA) [6] is formal semantic that It is specially devoted for parallel, loosely cou- ... pled and asynchronous communication so it is Transformational Design of Business Processes in BPEL Language 107

Table 1. Sample mappings BPEL activities to PA formulas. Part 1 BPEL LOTOS Process Algebra empty endproc

external service invocation endproc [...]

receive message [vName] := [...] vName;exit endproc

reply vName;exit [...] endproc

assign variable value fromVar;toVar;exit endproc

parallel execution <flow name="flowName"> process flow_flowName[dummy] := < ... name="activityA"/> activityA || activityB ... < ... name="activityB"/> [...] endproc

sequential execution process sequence_seqName[linkSyn] := < ... name="activityA"/> activityA >> linkSyn;activityB >> ... < ... name="activityB"/> endproc [...] Note: linkSyn should be placed according to potential link synchronization usage. 108 Andrzej Ratkowski, Andrzej Zalewski, Bartłomiej Piech

Table 2. Sample mappings BPEL activities to PA formulas. Part 2 BPEL LOTOS Process Algebra conditional execution process switch_switchName[dummy] := hide ended in ( < ... name="activityA"/> activityA [ ] activityB ... ) endproc < ... name="activityB"/>

pick process pick_pickName[dummy] := activityA activityB

link <flow name="flowName"> process flow_flowName[dummy] := hide XtoY in (sequence_X[XtoY] |[ XtoY]| sequence_Y[XtoY]) endproc

For example parallel execution (without synchronization) has 2 symmetric rules: || x B1 B10 Then activity dependency mapping will be: −→x and B1 B2 B10 B2 process act_dependency[dummy] || −→ x || (3) B2 B2 receive_ReceivePurchase[PurchaseOrder] −→ 0 |[ PurchaseOrder]| x B1 B2 B1 B20 assign_assignOrder[PurchaseOrder, || −→ || ShippingRequest] an preceding (sequential composition) >> has 2 endproc rules: The activity dependency expresses indirect x B1 B10 dependency of two activities of which, one needs −→x and output data from another, no matter what struc- B1 >> B2 B10 >> B2 −→ σ (4) tural dependency (sequence or parallel) in the B2 B2 −→ 0 process are. i B1 >> B2 B2 −→ σ 4.2. BPEL Behavioural Equivalence where is successful termination and i is unobservable (hidden) event. There are a few approaches to determine be- If external service S is stateless then: havioural equivalence (or in other words be- y y YS S (5) haviour preservation) of refactored processes. In ∀ ∈ −→ [24] the author proposes such definition, that where Y is a set of all events. This means that two systems are equivalent when the response every event, generated externally or from the for each request is the same from both systems. subjected service, does not change the state and According to [22] communication-oriented sys- answer from the service. tems are equivalent if they send messages in the To analyse a BPEL process using PA terms, same order. the BPEL process has to be translated into PA In case of transformational design we assume using mapping mentioned in previous section. that every service fulfills stateless postulate. It The product of translation is a set of PA pro- means that when BPEL process invokes exter- cesses that are sequentially ordered by BPEL nal service then in every invocation response for steering instructions – sequences, flows, switches some request is always the same, it is indepen- and so on. Additionally, a part of mapping is ac- dent of history. This assumption leads to a con- tivity dependency processes. This artifact sym- clusion that state of external services (and all bolizes data dependency between elements. environment) is encapsulated inside the invok- Let us symbolize it with dependency operator: ing service. A]x]B (6) To make this assumption usable and to prove how it can be used we needed some PA theory. which means that state B can be started after A x is successfully terminated and event x is emitted B B0 (1) −→ (or received). The above formula means that process B Below we can see some example, that shows reaches state B0 after receiving an event (mes- what is our behavioural equivalence based on. sage) x. The given process has a set of operations con- Now PA semantics is defined using inference nected with dependency sequence: rules that has form: (A]x]C]z]D) (7) premises (sidecondition) (2) C waits for A result and D for C result. conclusions 110 Andrzej Ratkowski, Andrzej Zalewski, Bartłomiej Piech

Beside the above dependency, the pro- straints (sequences, flows, conditional and so cess has also structural sequence defined by on) is called minimal dependency process and instruction A B C D, is used to check the behavioural equivalence. → → → where B is instruction which is not connected by After refactoring, the new (refactored) process activity dependency. We can relax the structural has to be translated to PA and its PA image sequence and consider the process as: must fulfill preorder relationship with the minimal dependency process. Refactored process has (A]x]C]z]D) B (8) || to be subgraph of minimal dependency process That means that we can treat (A]x]C]z]D) and states graph. B as two parallel independent activities. The proof that (8) is true for stateless services. 5. Transformation Steering 1. If there is no external service (8) is true by the definition because there is no interaction The process of transformations is steered by between (A]x]C]z]D) and B, a method based on the Architecture Trade-off 2. If there is stateless external service S, then: Analysis Methods (ATAM) [18]. The ATAM y helps to identify trade-off points, that are pa- y(A]x]C]z]D) S ((A]x]C]z]D))0 S (9) ∀ || −→ || rameters that have impact on a few quality as- and y pects of the analyzed system. The impact of yS B S B0 (10) ∀ || −→ || trade-off points is positive on one aspect and which leads to: negative on another. So to designate proper y (A]x]C]z]D) (A]x]C]z]D)0 value of such parameter there a trade-off has to −→y (11) be reach on this parameter. (A]x]C]z]D) B (A]x]C]z]D)0 B ⇒ || −→ || ATAM helps to decide which alternative and should be selected during the process design. In y that way ATAM steers transformation in a de- B B0 −→ sign algorithm. y (12) (A]x]C]z]D) B (A]x]C]z]D) B ⇒ || −→ || 0 The equation (12) is parallel execution 6. Process Design Example inference rules (3) which is proof of (8) If S was stateful, then In order to illustrate how transformational de- y y(A]x]C]z]D) S (A]x]C]z]D)0 S0 (13) sign works in practice, a simple example is ∃ || −→ || then presented below. The example is inspired by y BPEL specification [17]. The quality of pro- (A]x]C]z]D) B (A]x]C]z]D)0 B0 (14) || −→ || cess is measured in two aspects: performance this would mean that there are some interactions and reusability. The performance metric is re- between (A]x]C]z]D) and B, and that they can sponse time under a given load, and reusability not be treated independently. is measured by number of interfaces that whole The above theory makes it possible to di- service provides. vide the whole BPEL process into parts, that are only dependant by activity dependency and 6.1. Reference process also makes possible to check if every refactored process is contained in these dependen- The business process is a typical purchase of cies. This technique is related to program slic- goods service. The service is composed of three ing [1] used broadly in source code refactor- activities: invoicing, order shipping and producing. The BPEL service with defined activ- tion scheduling. The activities of the process are ity dependencies and without structured con- organized as follows: Transformational Design of Business Processes in BPEL Language 111

1. the process receives purchase order, receives services, the third service composes two subser- product type, quantity and desired shipping vices. The alternatives are presented in Fig. 3. method, 2. shipping service is requested and the price of 6.3. Equivalence verification shipping is received, 3. an invoice is requested from an invoicing ser- In the current stage of algorithm, alternatives vice, the invoice contains product price and are verified to be behavioural equivalents to ref- shipping price, erence process. The technique of verification is 4. the production of goods is scheduled by re- described in section 5. The result of the verifi- quest to a scheduling service. cation is as follows: Each activity is executed in sequence. Next ac- – alternative 1 is behaviourally equivalent un- tivity starts after the previous is finished. The conditionally, reference process and surrounding services are – alternative 2 is not equivalent, because a re- depicted in Fig. 2. quest to invoicing service and shipping service depends on data received from shipping service. When all three requests startsat the same time, we can not guarantee, that the data from shipping service is received before a request to scheduling and invoicing services is made. – alternative 3 is behaviourally equivalent. Upon the above information, the designer decides to remove alternative 2 from the alternatives set.

6.4. Alternatives Evaluation – Performance

As it was mentioned at the beginning of the section, alternatives are evaluated in performance and reusability aspects. Performance is deﬁned as a mean response time estimation. The web Figure 2. Purchase order reference process service and connections between services can be modeled, with queueing theory, as M/M/1//inf 6.2. Process Alternatives system. It means that requests arrive to the system independently with exponential interval dis- For the current reference process, the designer tribution and response time is also exponentially proposes three alternatives that seem to be distributed. Thanks to the above assumptions, equivalent. Alternative (1) is a process that ﬁrst average response time of whole system can be es- makes request for shipping service and after- timated as a sum of average responses from its wards, parallelly requests shipping service and components: services and links between them. invoice service. To make evaluation simpler, we assume that ev- Alternative (2) starts all three requests paral- ery network connection has the same average la- lelly – invoicing, shipping and scheduling service. tency RN . So average response time of the ref- Alternative (3) is a bit more sophisticated – erence process is: the reference service is split into three services. RRP = RBPEL P + Rshipping + Rinvoicing One of them invokes shipping service, the second R (15) one parallelly invokes invoicing and scheduling + Rscheduling + 7RN 112 Andrzej Ratkowski, Andrzej Zalewski, Bartłomiej Piech

Figure 3. Possible alternatives for reference process Transformational Design of Business Processes in BPEL Language 113

An important fact in the above equation, is ence process and alternative 1 delivers four inter- that average response times of invoicing, ship- faces: one to main composed process and three ping and scheduling are simply added, because to elementary services: invoicing, shipping and requests to services are made consequently, one scheduling. Alternative 3 delivers 6 interfaces: by one. Let us assume additionally values of each three to basic services, one to composite ser- parameter: vice and two new interfaces to two sub services

– RBPELRP = 2 ms (average time of processing – shipping request and invoicing scheduling re- of main BPEL process), quest. – Rshipping = 3 ms (avg. resp. time from ship- All the above data are gathered in Table 3. ping service), – Rinvoicing = 5 ms (avg. resp. time from in- 6.6. Best Alternative Selection voicing service), – Rscheduling = 4 ms (avg. resp. time from ser- By means of ATAM method it is possible to vice), identify the trade-off point, which is in following – RN = 1 ms (avg. network latency). example services quantity. If composite service That gives RRP = 21 ms. consist of more basic services, then it is more For alternative 1 average response time is: reusable, however, performance suffers. In the current stage the new reference pro- RA1 = RBP ELA1 + Rshipping (16) cess has to be designated. Apparently alterna- + max(R ,R ) + 7R invoicing scheduling N tive 1 is the best choice. Alternative 1 is bet- the difference between alternative 1 and refer- ter than the current reference process in per- ence process is that invoice and scheduling ser- formance measure and not worse in reusability. vices are requested parallelly, so response time Alternative 3 is better in reusability than alter- from the parallel part is a maximum of response native 1 but much worse in performance, even times from invoicing and scheduling. When we worse than reference process. assume that RBP ELA1 = RBP ELRP then: RA1 = 17 ms. Finally alternative 3 average response time is: 7. Tool Support

RA3 = RBP ELA31 + RBP ELA32 As it was mentioned previously, an important

+ RBP ELA33 + Rshipping (17) goal of the research is to deliver a tool that will

+ max(Rinvoicing,Rscheduling) + 11RN support usage of transformational process design. The tool is currently under development. that gives: RA3 = 25 ms. In the current section a current status of tool development is described. The tool is based on 6.5. Alternatives Evaluation – open-source NetBeans IDE [23]. It is planned Reusability that whole design process will be held in Net- Beans. BPEL editor, which is already imple- As a reusability metrics is taken the total num- mented in the IDE, is used. Beside BPEL editor, ber of interfaces that a service delivers. Refer- a graphical editor is necessary as it will guide

Table 3. Quality metrics for reference process and alternatives Reference Alternative 1 Alternative 3 process Average response 21 ms 17 ms 25 ms time Reusability 4 4 6 Services quantity 1 1 3 114 Andrzej Ratkowski, Andrzej Zalewski, Bartłomiej Piech the process design iteration – its layout will be other BPEL constructions – program will do it similar to Figure 1. The editor will be the main for us automatically. window of the tool. A designing user will be able to click on every alternative and look inside us- 7.1.2. Aggregation ing native BPEL editor. In the main window there will also be all the important data about Composing one or more services into larger one quality of alternatives. seems to be easy. It is because somebody may think that it is enough to move logic from one 7.1. BPEL Refactoring service to another and that is all. It is a wrong approach because there are a lot of other ele- To automate refactoring process in BPEL lan- ments which we have to focus on. guage it was necessary to create the tool which First of all, we must find the BPEL file that provides these features. It was proposed to au- contains the logic of the invoked process which tomate such types of transformation: renam- is automatically done by the proposed tool. ing (variable, partnerLink, and correlationSet), Secondly, it is needed to move elements aggregation, asynchronization, parallelization, such as variable, partnerLink, correlationSet split. After selecting a part of the code in BPEL and namespaces to the process that is invoking, file one of the mentioned transformations can because all the elements are used in logic which be realized (if it is possible). Such tool has not we want to encapsulate. been already implemented – this is why I de- Last but not least, it may happen that the used cided to implement an idea of creating the ap- variables, partnerLinks or namespaces in invoked plication as a plug-in to Netbeans IDE which process have the same name as in process which is automates refactoring process. There are nu- invoking the first one. This situation is considered merous engineering challenges connected with in the proposed tool – when the situation occurs, the detailed design of tool support for BPEL application changes the name of the specified el- transformations. These have been presented ement in all constructions where reference to this in detail below. element occur in order to prevent name collision. A similar situation may happen in namespaces 7.1.1. Renaming because the one we want to add is already defined. In this case it is also needed to change the name It is the simplest type of refactoring – changes the of the added namespace in every place where it name one of the three elements in BPEL (vari- occurs. Also a very important thing is to ensure able, partnerLink, and correlationSet) and all that variable used as input in invoked process the occurrences of this element in other language (attribute variable in receive element) after the constructions. It seems to be an easy transfor- transformation will be the same as input in invoke mation but it is relevant. It would be difficult to element before transformation. A similar situa- do it manually because BPEL contains a lot of tion occurs when we have synchronous invocation constructions with reference to other elements. with output variable it has to be checked whether For instance reference to variable may occur in variable used in reply element will be the same such elements: receive, reply, invoke, onMessage, as an output variable in invoke element before throw, copy from, copy to and in XPath expres- refactoring. This situation is also supported by sions: wait, onAlarm, if, else if, while, repeatUntil, the application. forEach. As we can see it is much easier to use an automatic tool which finds all the occurrences 7.1.3. Asynchronization of the chosen element in BPEL code. The offered application provides these features. We can In this type of refactoring the offered tool also change the name one of the mentioned elements provides a few conveniences that automate pro- and do not have to worry about occurrences in cess of transformation. First of them is finding Transformational Design of Business Processes in BPEL Language 115 as many operations as it is possible which are part of the service and then create another ser- invoked after selected element and they are in- vice to be invoked inside the primary service we dependent. After that we can change the invoca- have to create two new files – a BPEL file and tion method from synchronous to asynchronous. a WSDL file. Moreover, we must fill them with If there are no independent operations transfor- all the necessary information which is indispens- mation will be terminated. able to make a network connection with the new To change the invocation from synchronous process. As well it is requisite to change the pri- to asynchronous some changes in WSDL and mary process so that the connection with the BPEL file in invoked process are needed. We new process will be possible. All the mentioned have to delete (in WSDL file) an output element operations are supported by our tool. in operation construction (to make invocation First of all, the application chooses two vari- asynchronous) and add a new input element for ables – one as input variable and second as out- a reply to the primary process (we can not use put variable for synchronous invocation of the the same input element for the reply because the new process. Choosing variables is not compli- types of used variables may be different). More- cated operation because as input variable is cho- over in BPEL file we must change synchronous sen first which occurs in selected code to extract element reply to element invoke to make con- and it is used for one of the operations. In case nection asynchronous – we need to define ad- of the occurrence more than one variable, all of ditional partnerLink element to make the con- which are not initiated in a chosen logic, the nection possible. The application supports all of transformation will be terminated. Selection of these transformations. the output variable is very similar to the selec- To finish the transformations it is necessary tion of the input variable – if exists exactly one to provide some modifications in the primary variable, which is initiated in the selected logic process. This is because of the type of invoca- and used later after the selected code, it will be tion (asynchronous) which we introduce earlier chosen as output variable. by changing a partner WSDL file. After all in- Next, BPEL and WSDL files are created. dependent operations we need to place element In a WSDL file all the necessary constructions receive to collect a response from partner pro- are created, such as: message, portType, oper- cess and delete an attribute outputVariable in ation, partnerLinkType and namespaces which the invoke element. defines complex types of the variables. Then The last thing to remember is to define cor- using definition created in a WSDL file it is relation element to ensure that response will be possible to make a new BPEL file and cre- transferred to the right instance of the primary ate constructions: variable, partnerLink, names- process. This is why proposed tool makes some paces, etc. and place selected logic in new modifications in WSDL file of partner process. file. All of the operations are supported by To be more accurate application defines prop- the application. erty element and two propertyAlias elements. At the end it is necessary to modify the pri- Thanks to that it is possible to define corre- mary process. To make a connection with the lationSet and correlation elements in primary new process the application adds invoke activ- process file which guarantee that message will ity (with all attributes) instead of the extracted be delivered to right process instance. After all logic and element partnerLink (also with all at- mentioned operations, which proposed tool sup- tributes). After all these transformations split- ports, refactoring is finished. ting the process into parts is possible.

7.1.4. Split 7.2. Tools for Equivalence Veriﬁcation

Splitting the service without using the auto- The algorithm of equivalence veriﬁcation consist matic tool may also be diﬃcult. To extract a of three steps: 116 Andrzej Ratkowski, Andrzej Zalewski, Bartłomiej Piech

Figure 4. Structure of verification process 1. translating BPEL process to minimal depen- The whole framework has been accompanied dency process (MDP) – this step is made by a prototype tool which has been integrated only once at the beginning of the refactoring with NetBeans environment in the form of a process, plug-in. The challenges resolved during tool de- 2. translating BPEL process to its PA image, velopment have by no means turned out to be 3. checking preorder relationship of PA image trivial. Therefore, they have also been discussed with minimal dependency process. in the paper which should become a valuable As a part of the developed tool, translation resource of the real implementation experiences BPEL to PA was made by means of an XSLT in the field of transforming BPEL as well as for processor, as the PA processor was used Concur- the continuation of the work presented here. rence Workbench for New Century (CWB-NC) The approach has been validated on an ex- [5]. The structure of verification system is in the emplary design case. The result of such a case Figure 4. study are promising though some more compli- The transformation from BPEL to its PA cated cases would provide a chance for a more image is a quite trivial action as it was used in-depth validation of the whole approach. XSLT preprocessor. The XSLT processor automatically maps BPEL instructions into their PA References equivalences as it is listed in Tables 1 and 2. The second type of mapping – from BPEL [1] D. Binkley and K. B. Gallagher. Program slic- to its MDP image is more sophisticated. As it is ing. Advances in Computers, 43:1–50, 1996. needed to resolve indirect dependencies between [2] T. Bolognesi and E. Brinksma. Introduction to the ISO specification language LOTOS. Com- BPEL activities there graph manipulation tech- put. Netw. ISDN Syst., 14(1):25–59, 1987. niques are applied. [3] F. Breugel and M. Koshkina. Models and verification of BPEL. 2006. [4] J. Cámara, C. Canal, J. Cubo, and A. Vallecillo. 8. Summary and Further Work Formalizing WSBPEL business processes using process algebra. Electr. Notes Theor. Comput. A method for transformational design of SOA Sci., 154(1):159–173, 2006. [5] R. Cleaveland. Concurrency workbench of the business processes in BPEL has been presented. new century, 2000. http://www.cs.sunysb.edu/ It has been founded on the formal framework ~cwb/. of process algebras as well as the concept of [6] R. Cleaveland and S. Smolka. Process algebra. process equivalence originally developed by the 1999. authors. The transformations are aimed at im- [7] A. D’Ambrogio and P. Bocciarelli. A proving certain properties like e.g. modifiability model-driven approach to describe and pre- and performance while preserving the behaviour dict the performance of composite services. In specified by the starting business process model. WOSP ’07: Proceedings of the 6th international Transformational Design of Business Processes in BPEL Language 117

workshop on Software and performance, pages [21] D. E. Millard, H. C. Davis, Y. Howard, 78–89, New York, NY, USA, 2007. ACM. L. Gilbert, R. J. Walters, N. Abbas, and G. B. [8] D. Fahland and W. Reisig. ASM-based seman- Wills. The service responsibility and interaction tics for BPEL: The negative control flow. In design method: Using an agile approach for web Abstract State Machines, pages 131–152, 2005. service design. pages 235–244, 2007. [9] A. Ferrara. Web services: a process algebra [22] I. Moore. Automatic inheritance hierarchy approach. In ICSOC ’04: Proceedings of the restructuring and method refactoring. In 2nd international conference on Service ori- OOPSLA ’96: Proceedings of the 11th ACM ented computing, pages 242–251, New York, NY, SIGPLAN conference on Object-oriented pro- USA, 2004. ACM Press. gramming, systems, languages, and applica- [10] A. Ferrara. Web services: a process algebra tions, pages 235–250, New York, NY, USA, approach. In ICSOC ’04: Proceedings of the 1996. ACM. 2nd international conference on Service ori- [23] NetBeans IDE. http://www.netbeans.org/. ented computing, pages 242–251, New York, NY, [24] W. F. Opdyke. Refactoring Object-Oriented USA, 2004. ACM Press. Frameworks. PhD thesis, Urbana-Champaign, [11] H. Foster, J. Kramer, J. Magee, and S. Uchi- IL, USA, 1992. tel. Model-based verification of web service [25] A. Ratkowski and A. Zalewski. Performance compositions. In 18th IEEE International refactoring for service oriented architecture. Conference on Automated Software Engineering ISAT ’2007: Information Systems Architecture (ASE), 2003. And Technology, 2007. [12] H. Foster, S. Uchitel, J. Magee, J. Kramer, and [26] A. Ratkowski and A. Zalewski. Transforma- M. Hu. Using a rigorous approach for engineer- tional design of business processes in SOA. In ing web service compositions: A case study. In Proceedings of CEE-SET, 2008. SCC ’05: Proceedings of the 2005 IEEE Interna- [27] W. Reisig. Modeling and Analysis Techniques tional Conference on Services Computing, pages for Web Services and Business Processes. In 217–224, Washington, DC, USA, 2005. IEEE FMOODS 2005, Athens, Greece, June 15–17, Computer Society. 2005. Proceedings, volume 3535, pages 243–258. [13] X. Fu, T. Bultan, and J. Su. Analysis of in- Springer Verlag, May 2005. teracting BPEL web services. In WWW ’04: [28] N. Russell, W. van der Aalst, Arthur, and Proceedings of the 13th international conference P. Wohed. On the suitability of UML 2.0 on World Wide Web, pages 621–630, New York, activity diagrams for business process mod- NY, USA, 2004. ACM. elling. In APCCM ’06: Proceedings of the 3rd [14] S. Hinz, K. Schmidt, and C. Stahl. Transform- Asia-Pacific conference on Conceptual mod- ing BPEL to Petri Nets. In Proceedings of the elling, pages 95–104, Darlinghurst, Australia, BPM 2005, pages 220–235, Nancy, France, Sept. Australia, 2006. Australian Computer Soci- 2005. Springer-Verlag. ety, Inc. [15] I. Hofacker and R. Vetschera. Algorithmical ap- [29] G. Salaün, L. Bordeaux, and M. Schaerf. De- proaches to business process design. Computers scribing and reasoning on web services using & OR, 28(13):1253–1275, 2001. process algebra. In ICWS ’04: Proceedings of [16] G. J. Holzmann. The SPIN Model Checker: the IEEE International Conference on Web Ser- Primer and Reference Manual. Addison-Wesley vices, page 43, Washington, DC, USA, 2004. Professional, September 2003. IEEE Computer Society. [17] IBM, BEA, and Microsoft. Business process [30] G. Salaün, A. Ferrara, and A. Chirichiello. Ne- execution language for web services. http:// gotiation among web services using LOTOS/- citeseer.ist.psu.edu/669609.html, 2003. CADP. In ECOWS, pages 198–212, 2004. [18] R. Kazman, M. H. Klein, M. Barbacci, T. A. [31] W. van der Aalst, A. ter Hofstede, and Longstaff, H. F. Lipson, and S. J. Carrière. The M. Weske. Business process management: A sur- architecture tradeoff analysis method. In Pro- vey. In Business Process Management, Lec- ceedings of ICECCS, pages 68–78, 1998. ture Notes in Computer Science, pages 1–12. [19] A. Martens. Simulation and equivalence be- Springer, Berlin, Heidelberg, 2003. tween BPEL process models. In Proc. of Intl. [32] Y. Yang, T. Tan, J. Yu, and F. Liu. Transforma- Conference DASD’05, 2005. tion BPEL to CP-Nets for verifying web services [20] F. Martin. Refactoring: improving the design of composition. In Proceedings of NWESP ’05, existing code. Addison-Wesley Longman Pub- page 137, Washington, DC, USA, 2005. IEEE lishing Co., Inc., Boston, MA, USA, 1999. Computer Society. e-Informatica Software Engineering Journal, Volume 3, Issue 1, 2009

Satisfying Stakeholders’ Needs – Balancing Agile and Formal Usability Test Results

Jeﬀ Winter∗, Kari Rönkkö∗

∗School of Engineering, Dept. of Interaction & System Design, Blekinge Institute of Technology [email protected], [email protected]

Abstract This paper deals with a case study of testing with a usability testing package (UTUM), which is also a tool for quality assurance, developed in cooperation between industry and research. It shows that within the studied company, there is a need to balance agility and formalism when producing and presenting results of usability testing to groups who we have called Designers and Product Owners. We have found that these groups have diﬀerent needs, which can be placed on opposite sides of a scale, based on the agile manifesto. This becomes a Designer and a Product Owner Manifesto. The test package is seen as a successful hybrid method combining agility with formalism, satisfying organisational needs, and fulﬁlling the desire to create a closer relation between industry and research.

1. Introduction in a world of continuously changing business decisions often makes this approach impractical or Product quality is becoming the dominant suc- impossible, pointing to a need for agility. At a cess criterion in the software industry, and Os- keynote speech at the 5th Workshop on Soft- terweil states that the challenge for research is to ware Quality, held at ICSE 2007 [45], Boehm provide the industry with the means to deploy stated that both agility and quality are becom- quality software, allowing companies to compete ing more and more important. Many areas of effectively [23]. Quality is multi-dimensional, technology exhibit a tremendous pace of change, and impossible to show through one simple mea- due to changes in technology and related infras- sure, and research should focus on identifying tructures, the dynamics of the marketplace and various dimensions of quality and measures ap- competition, and organisational change. This is propriate for it [23]. A more effective collab- particularly obvious in mobile phone develop- oration between practitioners and researchers ment, where their pace of development and pen- would be of great value [23]. Quality is also etration into the market has exploded over the important owing to the criticality of software last 5 years. This kind of situation demands an systems (a view supported by Harrold in her agile approach [6]. roadmap for testing [14]) and even to changes This article is based on two case studies of a in legislation that make executives responsible usability evaluation framework called UIQ Tech- for damages caused by faulty software. nology Usability Metrics (UTUM) [39], the re- One approach to achieving quality has been sult of a long research cooperation between the to rely on complete, testable and consistent re- research group “Use-Oriented Design and Devel- quirements, traceability to design, code and test opment” (U-ODD) [37] at Blekinge Institute of cases, and heavyweight documentation. How- Technology (BTH), and UIQ Technology (UIQ) ever, a demand for continuous and rapid results [38]. With the help of Martin et al.’s study [21] 120 Jeff Winter, Kari Rönkkö and our own case studies, it presents an ap- – Do the information needs, and preferred proach to achieving quality, related to an organi- methods change during different phases of a zational need for agile and formal usability test design and development project? results. We use concepts such as “agility under- – Can results be presented in a meaningful way stood as good organizational reasons” and “plan without the test leader being present? driven processes as the formal side in testing”, The structure of the article is as follows. An to identify and exemplify a practical solution to overview of two testing paradigms is provided. assuring quality through an agile approach. The A description of the test method comes next, research question for the first case study was: followed by a presentation of the methodology, – How can we balance demands for agile re- and the material from the case studies, examin- sults with demands for formal results when ing the balance between agility and formalism, performing usability testing for quality as- the information needs of different stakeholders, surance? the relationship between agility, formality and We use the term “formal” as a contrast to quality, and the need for research/industry co- the term “agile” not because we see agile pro- operation. The article ends with a discussion of cesses as being informal or unstructured, but the work, and conclusions. since “formal” is more representative than “plan driven” to characterise the results of testing and how they are presented to certain stake- 2. Testing – Prevailing Models vs. holders. We examine how the results of the Agile Testing UTUM test are suitable for use in an agile process. eXtreme Programming (XP) is used Testing is performed to support quality assur- as an illustrative example in this article, but ance, and an emphasis on software quality re- note that there is no strong connection to any quires improved testing methodologies that can particular agile methodology; rather, there is a be used by practitioners to test their software philosophical connection between the test and [14]. Since we regard the test framework as an the ideas behind the agile movement. We ex- agile testing methodology, this section presents amine how the test satisfies requirements for a discussion of testing from the viewpoints of formal and informal statements of usability both the software engineering community and and quality. the agile community. In the first study, we identify two groups Within software engineering, there are many of stakeholders that we designated as Designers types of testing, in many process models, (e.g. (D) and Product Owners (PO), with an inter- the Waterfall model [30], Boehm’s Spiral model est in the different elements of the test data. A [4]). Testing is often phase based, and the typical further case study was performed to discover if stages of testing (see e.g. [33], [25]) are Unit test- these findings could be confirmed. It attempted ing, Integration testing, Function testing, Per- to answer the following research questions: formance testing, Acceptance testing, and Instal- – Are there any presentation methods that are lation testing. The stages from Function testing generally preferred? and onwards are characterised as System Test- – Is it possible to find factors in the data that ing, where the system is tested as a whole rather allow us to identify differences between the than as individual pieces [25]. Usability testing separate groups (D & PO) that were tenta- (otherwise named Human Factors Testing) has tively identified in the case study presented been characterised as investigating requirements in the previous chapter? dealing with the user interface, and has been – Are there methods that the respondents regarded as a part of Performance testing [25]. think are lacking in the presentation meth- The prevailing approach to testing is reliant on ods currently in use within UTUM? formal aspects and best practice. Satisfying Stakeholders’ Needs – Balancing Agile and Formal Usability Test Results 121

Agile software development changes how soft- area of usability and testing, and generalists in ware development organisations work, especially the area of the product and process as a whole. regarding testing [34]. In agile development, exemplified here by XP [1], a key tenet is that testing is performed continuously by developers. 3. The UTUM Usability Evaluation Tests should be isolated, i.e. should not inter- Framework act with the other tests that are written, and should preferably be automatic, although not UTUM is a usability evaluation framework for all companies applying XP automate all tests mass market mobile devices, and is a tool for [21]. Tests come from both programmers and quality assurance, measuring usability empiri- customers, who create tests that serve to in- cally on the basis of metrics for satisfaction, crease their confidence in the operation of the efficiency and effectiveness, complemented by a program. Customers specify functional tests to test leader’s observations. Its primary aim is to show that the system works how they expect measure usability, based on the definition in ISO it to, and developers write unit tests to en- 9241-11, where usability is defined as “the extent sure that the programs work how they think to which a product can be used by specified users it does. These are the main testing methods in to achieve specified goals with effectiveness, ef- XP, but can be complemented by other types of ficiency and satisfaction in a specified context tests when necessary. Some XP teams may have of use” [17]. This is similar to the definition of dedicated testers, who help customers translate quality in use defined in ISO 9126-1, where us- their test needs into tests, who can help cus- ability is instead defined as understandability, tomers create tools to write, run and main- learnability and operability [18]. The intention tain their own tests, and who translate the cus- of the test is also to measure “The User eXperi- tomer’s testing ideas into automatic, isolated ence” (UX), which is seen as more encompassing tests [1]. than the view of usability that is contained in The role of the tester is a matter of debate. It e.g. the ISO standards [39], although it is still is primarily developers who design and perform uncertain how UX differs from the traditional testing. However, within industry, there are seen usability perspective [41] and exactly how UX to be fundamental differences between the peo- should be defined (for some definitions, see e.g. ple who are “good” testers and those who are ([15], [16], [42]). good developers. In theory, it is often assumed In UTUM testing, one or more test leaders that the tester is also a developer, even when carry out the test according to predefined re- teams use dedicated testers. Within industry, quirements and procedure. The test itself takes however, it is common that the roles are clearly place in a neutral environment rather than a lab, separated, and that testers are generalists with in order to put the test participant at ease. The the kind of knowledge that users have, who test is led by a test leader, and it is performed to- complement the perspectives and skills of the gether with one tester at a time. The test leader testers. A good tester can have traits that are in welcomes the tester, and the process begins with direct contrast with the traits that good devel- the collection of some data regarding the tester opers need (see e.g. Pettichord [24] for a discus- and his or her current phone and typical phone sion regarding this). Pettichord claims that good use. Whilst the test leader is preparing the test, testers think empirically in terms of observed the tester has the opportunity to get acquainted behaviour, and must be encouraged to under- with the device to be tested, and after a few stand customers’ needs. Thus, although there minutes is asked to fill in a hardware evaluation, are similarities, there are substantial differences a questionnaire regarding attitudes to the look in testing paradigms, how they treat testing, and feel of the device. and the role of the tester and test designer. In The tester performs a number of use cases on our testing, the test leaders are specialists in the the device, based on the tester’s normal phone 122 Jeff Winter, Kari Rönkkö

Test User User Interested satisfaction satisfaction knowledge Appraised Appraised inefficiency efficiency parties User

User User dissatisfaction dissatisfaction Appra Appra Influence

Knowledge Metrics/ graphs

UTUM test data

RESULTS

Figure 1. Contents of the UTUM testing, a mix of metrics and mental data use or organisational testing needs. The test Figure 1 illustrates the flow of data and leader observes what happens during the use knowledge contained in the test and the test re- case performance, and records any observations, sults, and how the test is related to different the time taken to complete the use cases, and groups of stakeholders. Stakeholders, who can answers to follow-up questions that arise. After be within the organisation, or licensees, or cus- the use case is complete, the tester answers ques- tomers in other organisations, can be seen at tions about how well the telephone lets the user the top of the flow, as interested parties. Their accomplish the use case. requirements influence the design and contents When all of the use cases are completed, the of the test. The data collected is found both as tester completes a questionnaire based on the knowledge stored in the mind of the test leader, System Usability Scale (SUS) [7] about his or and as metrics and qualitative data in spread- her subjective impressions of how easy the in- sheets. terface is to use. It expresses the tester’s opin- The results of the testing are thereby a com- ion of the phone as a whole. The tester is finally bination of metrics and knowledge, where the thanked for their participation in the test, and different types of data confirm one another. Met- is usually given a small gift, such as a cinema rics based material is presented in the form of ticket, to thank them for their help. diagrams, graphs and charts, showing compar- The data obtained are transferred to spread- isons, relations and tendencies. This can be cor- sheets. These contain both quantitative data, roborated by the knowledge possessed by the such as use case completion times and attitude test leader, who has interacted with the testers assessments, and qualitative data, such as com- and who knows most about the process and con- ments made by testers and information about text of the testing. Knowledge material is often problems that arose. The data is used to cal- presented verbally, but can if necessary be sup- culate metrics for performance, efficiency, effec- ported and confirmed by metrics and visual pre- tiveness and satisfaction, and the relationships sentations of the data. between them, leading to a view of usability for UTUM has been found to be a customer the device as a whole. The test leader is an im- driven tool that is quick and efficient, is eas- portant source of data and information in this ily transferable to new environments, and that process, as he or she has detailed knowledge of handles complexity [44]. For more detailed in- what happened during testing. formation on the contents and performance of Satisfying Stakeholders’ Needs – Balancing Agile and Formal Usability Test Results 123 the UTUM test and the principles behind it, see search and deliberating improvements, and in- ([39], and [44]). A brief video presentation of the volving the practitioners in the improvements. whole test process (6 minutes) can be found on This approach is inspired by a participatory de- YouTube [8]. sign (PD) perspective. PD is an approach towards system design in which those who are expected to use the system are actively involved 4. The Study Methodology and and play a critical role in its design. It includes the Case Studies stakeholders in design processes, and demands shared responsibility, participation, and a part- This work has been part of a long-term research nership between users and implementers [32]. cooperation between U-ODD and UIQ, which These studies have been performed as case has centred on the development and evaluation studies, defined by Yin as “an empirical en- of a usability evaluation framework (for more in- quiry that investigates a contemporary phe- formation, see [44], [40]). The case studies in this nomenon within its real-life context, especially phase of the research cooperation were based on when the boundaries between phenomenon and tests performed by together by UIQ in Ronneby, context are not clearly evident” ([46], p. 13). Yin and by Sony Ericsson Mobile Development in presents a number of criteria that are used to Manchester. establish the quality of empirical social research The process of research cooperation is ac- and states that they should be applied both in tion research (AR) according to the research the design and conduct of a case study. They and method development methodology called deal with construct validity, internal validity, ex- Cooperative Method Development (CMD), see ternal validity and reliability ([46], pp. 35–39). [11], [10], [12] and ([28], chapter 8) for further Three tactics are available to increase con- details. AR “involves practical problem solving struct validity, which deals with establishing which has theoretical relevance” ([22] p. 12). It correct measures for the concepts being stud- involves gaining an understanding of a problem, ied, and is especially problematic in case study generating and spreading practical improvement research. These are: using multiple sources ideas, applying the ideas in a real world situa- of information; ensuring a chain of evidence tion and spreading the theoretical conclusions and; using member checking, i.e. having the within academia [22]. Improvement and involve- key participants review the case study report. ment are central to AR, and its purpose is to In this study, we have used many different influence or change some aspect of whatever the sources of information. The data was obtained research has as its focus ([27] p. 215). A cen- through observation, through a series of unstruc- tral aspect of AR is collaboration between re- tured and semi-structured interviews [27], both searchers and those who are the focus of the re- face-to-face and via telephone, through partici- search. It is often called participatory research pation in meetings between different stakehold- or participatory action research ([27] p. 216). ers in the process, and from project documents CMD is built upon guidelines that include the and working material. The interviews have been use of ethnomethodological and ethnographi- performed with test leaders, and with staff on cally inspired empirical research, combined with management level within the two companies. other methods if suitable. Ethnography is a re- Interviews have been audio taped, and tran- search strategy taken from sociology, with foun- scribed, and all material has been stored. The dations in anthropology [29]. It relies upon the second case study involves the use of a survey. first-hand experience of a field worker who is The mix of data and collection methods has directly involved in the setting that is under given a triangulation of data that serves to val- investigation [29]. CMD focuses on shop floor idate the results that have been reached. development practices, taking the practitioners’ To ensure a chain of evidence a “study perspective when evaluating the empirical re- database” or research diary has been main- 124 Jeff Winter, Kari Rönkkö tained. It collects all of the information in the research colleagues, giving them the chance to study, allowing for traceability and transparency react to the analysis and suggest and discuss of the material, and reliability [46]. It is mainly alternative explanations or approaches. computer based, and is an account of the study External validity, knowing whether the re- recording activities performed in the study, tran- sults of a case study are generalisable outside scriptions of interviews and observation notes, the immediate case study, has been seen as a and records of relevant documents and articles. major hinder to doing case studies, as single case The audio recordings are also stored digitally. studies have been seen as a poor basis for gener- The written document contains notations of alisation. However, this is based on a fallacious thoughts concerning themes and concepts that analogy, where critics contrast the situation to arise when reading or writing material in the survey research, where samples readily gener- account of the study. The chain of evidence is alise to a larger population. In a case study, the also a part of the writing process. investigator tries to generalise a set of results to The most important research collaborators a wider theory, but, generalisation is not auto- in the industrial organisation have been an in- matic, and a theory must be tested by replicat- tegral part of the study, and have been closely ing the findings, in much the same way as exper- involved in many stages of the work. They have iments are replicated. Although Yin advises per- been available for testing thoughts and hypothe- forming multiple-case studies, since the chances ses during the study, giving opportunities for of doing a good case study are better than us- member checking. They have also been involved ing a single-case design ([46], p. 53), this study as co-authors when writing articles, which also has been performed as a single-case study and means that member checking has been an inte- has been performed to generate theory. The case gral part of the research. here represents a unique case ([46], p. 40), since Internal validity is especially important in the testing has mainly been performed within exploratory case studies, where an investigator UIQ, and it is thereby the only place where it has tries to determine whether one event leads to been possible to evaluate the testing methodol- another. It must be possible to show that these ogy in its actual context. One particular threat events are causal, and that no other events have is in our study is therefore that most of the data caused the change. If this is not done, then comes from UIQ. Due to close proximity to UIQ, the study does not deal with threats to inter- the interaction there has been frequent and in- nal validity. Some ways of dealing with this are formal, and everyday contacts and discussions via pattern matching, explanation building, ad- on many topics have influenced the interviews dressing rival explanations, and using logic mod- and their analysis. Interaction with Sony Er- els. This study has been a mix of exploratory icsson has been limited to interviews and dis- and explanatory studies. To address the issues cussions, but data from Sony Ericsson confirms of internal validity in the case studies, we have what was found at UIQ. A further threat is that used the general repertoire of data analysis as most of the data in the case study comes from in- mentioned in the previous paragraph. The ma- formants who work within the usability/testing terial in the research diary has been analysed area, but once again, they come from two differ- to find emerging themes, in an editing approach ent organisations and corroborate one another, that is consistent with Grounded Theory (see have been complemented by information from Robson [27] p. 458). The analysis process has af- other stakeholders, and thus present a valid pic- fected the further rounds of questioning, narrow- ture of industrial reality. ing down the focus, and shifting the main area A threat in the second case study is the of interest, opening up for the inclusion of new fact that only ten people have participated. This respondents who shed light on new aspects of makes it difficult to draw generalisable conclu- the study. A further method for ensuring valid- sions from the results. Also, since the company ity has been through discussions together with is now disbanded, it is not possible to return Satisfying Stakeholders’ Needs – Balancing Agile and Formal Usability Test Results 125 to the field to perform cross checking with the the data collection and analysis process. This participants in the study. The analysis is there- ensures that the study is theoretically replica- fore based on the knowledge we have of the con- ble. One problem regarding the replicability of ditions at the company and the context where this study, however, is that the rapidly changing they worked, and is supported by discussions conditions for the branch that we have studied with a people who were previously employed mean that the context is constantly changing, within the company, whom we are still in contact whereby it is difficult to replicate the exact con- with. These people can however mainly be char- text of the study. acterised as Designers, and therefore may not In the following, we begin by presenting accurately reflect the views of Product Owners. the results of the first case study, and dis- Thus, since this research is mainly based on cuss in which way the results are agile or a study of one company in a limited context, it plan-driven/formal, who is interested in the dif- is not possible to make confident claims about ferent types of results, and which of the organisa- the external validity of the study. However, we tional stakeholders needs agile or formal results. can say that we have created theory from the study, and that readings appear to suggest that much of what we have found in this study can 5. Agile or Formal? also be found in other similar contexts. Further work remains to see how applicable the theory The first focus of the study was the fact that is for other organisations in other or wider con- testing was distributed, and the effect this had texts. Extending the case study and performing on the testing and the analysis of the results a similar study in another organisation is a way During the case study, as often happens in of testing this theory, and further analysis may case studies [46], the research question changed. show that the case at UIQ is actually represen- Gradually, another area of interest became the tative of the situation in other organisations. elements of agility in the test, and the bal- Reliability deals with the replicability of a ance between the formal and informal parts of study, whereby a later investigator should be the testing. The framework has always been re- able to follow the same procedures as a previ- garded as a tool for quality, and verifying this ous investigator, and arrive at the same findings was one purpose of the testing that this case and conclusions. By ensuring reliability you min- study was based on. Given the need for agility imize errors and bias in a study. One prerequi- mentioned above, the intention became to see site for this is to document procedures followed how the test is related to agile processes and in your work, and this can be done by main- whether the items in the agile manifesto can be taining a case study protocol to deal with the identified in the results from the test framework. documentation problem, or the development of a The following is the result of having studied the case study database. The general way to ensure material from the case study from the perspec- reliability is to conduct the study so that some- tive of the spectrum of different items that are one else could repeat the procedures and arrive taken up in the agile manifesto. at the same result ([46], pp. 35–39). The case The agile movement is based on core val- study protocol is intended to guide the investi- ues, described in the agile manifesto [35], and gator in carrying out the data collection. It con- explicated in the agile principles [36]. The agile tains both the instrument and the procedures manifesto states that: “We are uncovering better and general rules for data collection. It should ways of developing software by doing it and by contain an overview of the project, the field pro- helping others do it. Through this work we have cedures, case study questions, and a guide for come to value: Individuals and interactions over the case study report ([46], p. 69). As mentioned processes and tools, Working software over com- previously, a case study database has been main- prehensive documentation, Customer collabora- tained, containing the most important details of tion over contract negotiation, and Responding 126 Jeff Winter, Kari Rönkkö to change over following a plan. That is, while who lead the test, and who actually perform there is value in the items on the right, we value the testing on the devices. The central figure the items on the left more”. Cockburn stresses here is the test leader, who functions as a that the intention is not to demolish the house of pivot point in the whole process, interacting software development, represented here by the with the testers, observing and registering items on the right (e.g. working software over the data, and presenting the results. This comprehensive documentation), but claims that interaction is clearly important in the long those who embrace the items on the left rather run from a PO perspective, but it is D who than those on the right are more likely to suc- has the greatest and immediate benefit of the ceed in the long run [9]. Even within the ag- interaction, showing how users reacted to de- ile community there is some disagreement about sign decisions, that is a central part of the the choices, but it is accepted that discussions testing. can lead to constructive criticism. Our analysis Processes and Tools – The test is based • showed that all these elements could be identi- upon a well-defined process that can be re- fied in the test and its results. peated to collect similar data that can be In our research we have always been con- compared over a period of time. This is im- scious of a division of roles within the company, portant for the designers, but in the short often expressed as “shop floor” and “manage- term they are more concerned with the ev- ment”, and working with a participatory design eryday activities of design and development perspective we have worked very much from the that they are involved in. Therefore we see shop floor point of view. During the study, this this as being of greatest interest to PO, who viewpoint of separate groups emerged and crys- can get a long-term view of the product, tallised, and two disparate groups became ap- its development, and e.g. comparisons with parent. We called these groups Designers, repre- competitors, based on a stable and standard- sented by e.g. interaction designers and system ised method. and interaction architects, representing the shop Working information – The test produces • floor perspective, and Product Owners, includ- working information quickly. Directly after ing management, product planning, and market- the short period of testing that is the sub- ing, representing the management perspective. ject of this case study, before the data was When regarding this in light of the Agile collated in the spreadsheets, the test lead- manifesto, we began to see how different groups ers met and discussed and agreed upon their may have an interest in different factors of the findings. They could present the most im- framework and the results that it can produce, portant qualitative findings to system and and it became a point of interest to see how these interaction architects within the two organ- factors related to the manifesto and which of the isations 14 days after the testing began, groups, Designers (D) or Product Owners (PO), and changes in the implementation were re- is mainly interested in each particular item in quested soon after that. An advantage of do- the manifesto. The case study data was anal- ing the testing in-house is having access to ysed on the basis of these emerging thoughts. the test leaders, who can explain and clarify Where the groups were found to fit on the scale what has happened and the implications of is marked in bold text in the paragraphs that it. This is obviously of primary interest to D. follow. One of the items is changed from “Work- Comprehensive documentation – The • ing software” to “Working information” as we documentation consists mainly of spread- see the information resulting from the testing sheets containing metrics and qualitative process as a metaphor for the software that is data. Metrics back up qualitative data and produced in software development. open up ways to present test results that Individuals and interactions – The test- can be understood without having to include • ing process is dependent on the individuals contextual information. They make test re- Satisfying Stakeholders’ Needs – Balancing Agile and Formal Usability Test Results 127

sults accessible for new groups. The quanti- Following a plan – From a short-term per- • tative data gives statistical confirmation of spective, this is important for D, but since the early qualitative findings, but are re- they work in a rapidly changing situation, it garded as most useful for PO, who want fig- is more important for them to be able to re- ures of the findings that have been reached. spond to change. This is however important There is less pressure of time to get these for PO who are responsible for well func- results compiled, as the critical findings are tioning strategies and long-term operations already being implemented. The metrics can in the company. be subject to stringent analysis to show comparisons and correlations between different 5.1. On Opposite Sides of the Spectrum factors. In both organisations there is beginning to be a demand for Key Performance In this analysis, we found that “Designers”, as in Indicators for usability, and although it is the agile manifesto, are interested in the items still unsure what these may consist of, it is on the left, rather than the items on the right still an indication of a trend that comes from (see Figure 2). We see this as being “A De- PO level. signer’s Manifesto”. “Product Owners” are more Customer collaboration – in the testing interested in the items on the right. Boehm char- • procedure it is important for the testers to acterised the items on the right side as being have easy access to individuals, to gain in- “An Auditor Manifesto”[6]. We see it as be- formation about customer needs, end user ing “A Product Owner’s Manifesto”. This is of patterns, etc. The whole idea of the test is course a sliding scale; some of the groups may to collect the information that is needed at be closer to the middle of the scale. Neither of the current time regarding the product and the two groups is uninterested in what is hap- its development. How this is done in practice pening at the opposite end of the spectrum, but is obviously of concern to PO in the long run, as in the agile manifesto, while there is value but in the immediate day to day operation in the items on one side, they value the items it is primarily of interest to D. on the other side more. We are conscious of Contract negotiation – On a high level the fact that these two groups are very coarsely • it is up to PO to decide what sort of coop- drawn, and that some groups and roles will lie eration should take place between different between these extremes. We are unsure exactly organisations and customers, and this is not which roles in the development process belong something that involves D, so this is seen as to which group, but are interested in looking at most important for PO. these extremes to see their information require- Respond to change – The test is eas- ments in regard to the results of usability test- • ily adapted to changes, and is not particu- ing. On closer inspection it may be found that larly resource-intensive. If there is a need to none of the groups is on the far side of the spec- change the format of a test, or a new test trum for all of the points in the manifesto. To requirement turns up suddenly, it is easy to gain further information regarding this, a case change the test without having expended ex- study has been performed, which we present in tensive resources on the testing. It is also the next section. easy to do a “Light” version of a test to check a particular feature that arises in the everyday work of design, and this has happened 6. Follow-up Study of Preferred several times at UIQ. This is the sort of thing Presentation Methods that is a characteristic of the day to day work with interaction design, and is nothing that This study is thus an investigation of attitudes is of immediate concern for PO, so this is regarding which types of usability findings dif- seen as D. ferent stakeholders need to see, and their pre- 128 Jeff Winter, Kari Rönkkö

D = Designers Product Owner = PO

Individuals Processes & Interactions D PO tools

Working Comprehensive information D PO documentation

Customer Contract collaboration D PO negotiation

Respond to Following a plan change D PO Agile Plan Driven

Figure 2. Groups and their diverging interests ferred presentation methods. In the previous itative findings of the testing. It shows issues study we identified two groups of stakeholders that have been found, on the basis of each tester with different information needs, ranging from and each device, for every use case. Comments Designers, who appear to want quick results, made by the test participants and observations often qualitative results rather than quantita- made by the test leader are stored in the spread- tive results, to Product Owners, who want more sheet. detailed information, are more concerned with Method 2: A spreadsheet containing quantitative results, but are not as concerned all “raw” data. All of the quantitative data with the speediness of the results. To test this from a series of tests. Worksheets contain theory, we sent a questionnaire to a number of the numerical data collected in a specific se- stakeholders within UIQ and their customers, ries of tests, which are also illustrated in a who are participants in the design and develop- number of graphs. The data includes times ment process. taken to complete use cases, and the results of A document was compiled illustrating ten attitude assessments. methods for presenting the results of UTUM Method 3: A Curve diagram. A graph tests. It contained a brief description of the pre- illustrating a comparison of time taken to com- sentation method and the information contained plete one particular use case. One curve illus- in it. The methods were chosen together with trates the average time for all tested telephones, a usability expert from UIQ who often presents and the other curves show the time taken for the results of testing to different groups of stake- individual phones. holders. The methods were chosen on the basis Method 4: Comparison of two factors of his experience of presenting test results to dif- (basic version). An image showing the results ferent stakeholders and are the most used and of a series of tests, where three telephones are most representative ways of presenting results. rated and compared with regard to satisfaction The methods range from a verbal presentation and efficiency. No more information is given in of early findings, to spreadsheets containing all this diagram. of the quantitative or the qualitative data from Method 5: Comparison of two factors the testing, plus a number of graphical represen- (brief details). The same image as Method 4, tations of the data. The methods were as follows with a very brief explanation of the findings. Method 1: The Structured Data Sum- Method 6: Comparison of two factors mary (the SDS). A spreadsheet with the qual- (more in depth details). The same image as Satisfying Stakeholders’ Needs – Balancing Agile and Formal Usability Test Results 129

Methods 4 and 5. Here, there is a more exten- e-mail, and have been summarised in a spread- sive explanation of the results, and the findings sheet and then analysed on the basis of a number made by the test leader. The test leader has also of criteria to see what general conclusions can be written suggestions for short term and long term drawn from the answers. solutions to issues that have been found. The method whereby the participants were Method 7: The “Form Factor” – an asked to prioritize the presentation methods immediate response. A visual comparison was based on cumulative voting [19], [43], a well of which telephone was preferred by men and known voting system in the political and the cor- women, where the participants were asked to porate sphere ([13], [31]), also known as the $100 give an immediate response to the phones, and test or $100 method [20]. Cumulative voting is choose a favourite phone on the basis of “Form a method that has previously been used in the Factor” – the “pleasingness” of the design. software engineering context, for e.g. software Method 8: PowerPoint presentation, requirement prioritization [26] and the prioritiza- no verbal presentation. A PowerPoint pre- tion of process improvements [3], and in [2] where sentation, produced by the test leader. A sum- it is compared to and found to be superior to mary of the main results is presented graphically Analytical Hierarchy Process in several respects. and briefly in writing. This does not give the The questionnaire was sent to 29 people, opportunity to ask follow-up questions in direct mostly within UIQ but also to some people connection with the presentation. from UIQ’s licensees. Only six respondents had Method 9: Verbal presentation sup- replied to the questionnaire within the stipu- ported by PowerPoint. A PowerPoint pre- lated time, so one day after the first deadline, we sentation, given by the test leader. A summary sent out a reminder to the respondents who had of the main results is presented graphically and not answered. This resulted in a further three briefly in writing, and explained verbally, giv- replies. After one more week, we sent out a final ing the listener the chance to ask questions reminder, leading to one more reply. Thus, we about e.g. the findings and suggestions for im- received 10 replies to the questionnaire, of which provements. This type of presentation takes the nine were from respondents within UIQ. On fur- longest to prepare and deliver. ther enquiry, the reason given for not replying Method 10: Verbal presentation of to the questionnaire was in general the fact that early results. The test leader gives a verbal the company was in an intensive working phase presentation of the results of a series of tests. for a planned product release, and that the staff These are based mainly on his or her impressions at the company could not prioritise allocating of issues found, rather than an analysis of the the time needed to complete the questionnaire. metrics, and can be given after having observed This makes it impossible to give full answers to a relatively small number of tests. This is the the research questions in this study, although it fastest and most informal type of presentation, helps us to answer some of the questions, and and can be given early in the testing process. gives us a better understanding of factors that The participants in the study were chosen to- affect the answers to the other questions. This gether with the usability expert at UIQ. Some of study helps us formulate hypotheses for further the participants were people who are regularly work regarding these questions. given presentations of test results, whilst others The division of roles amongst the respon- were people who are not usually recipients of the dents, and the number of respondents in the results, but who in their professional roles could categories was as follows: be assumed to have an interest in the results of 2: UI designers • usability testing. They were asked to read the 2: Product planning • document and complete the task by filling in 4: System design • their preferences in a spreadsheet. The results 1: Other (Usability) • of the survey were returned to the researcher via 1: Other (CTO Office) • 130 Jeff Winter, Kari Rönkkö

Distribution of allocated points

40 Mean

30 Points allocated

0 r r er gn gn gn n si he the si si sig e Ot O e e e D D D D Planning Planning t em em em UI st UI Designer st uct st y y S S Sy System Design Produc Prod Test respondents

Figure 3. Distribution of points allocated per respondent We have divided the respondents according spread of points differs greatly from person to to the tentative schema found in the first case person. Although this reflects the actual needs study, between Designers (D) and Product Own- of the respondent, the way of allocating points ers (PO). Some respondents were difficult to could also reflect tactical choices, or even the place in a particular category. The roles the re- respondent’s character. To get more informa- spondents held in the company were discussed tion about how the choices were made would with a member of the management staff at UIQ, require a further study, where the respondents with long work experience at the company, who were interviewed concerning their strategies and was well versed in the thoughts we had regarding choices. the difference between Designers and Product In what follows, we use various ways of sum- Owners. Due to turbulence within the company, marising the data. To obtain a composite picture it was not possible to verify the respondents’ at- of the respondents’ attitudes, the methods are titudes to their positions, and would have been ranked according to a number of criteria. Given difficult, since they were not familiar with the the small numbers of respondents in the study, terminology that we used, and the meaning of this compilation of results is used to give a more the roles that we had specified. complex picture of the results, rather than sim- Five respondents, the two UI designers, the ply relying on one aspect of the questionnaire. usability specialist and two of the system de- The methods are ranked according to: the total signers, belonged to the Designer group. The re- number of points that were allocated by all re- maining five respondents, the two members of spondents; the number of times the method has product planning, the respondent from the CTO been chosen, and; the average ranking, which is office and two of the system designers, were rep- the sum of the rankings given by each respon- resentatives of the group of Product Owners. dent, divided by the number of respondents that Figure 3 is a box and whisker plot that shows chose the method (e.g., if one respondent chose a the distribution of the points and the mean method in first place, whilst another respondent points allocated per person. As can be seen, the chose it in third place, the average position is Satisfying Stakeholders’ Needs – Balancing Agile and Formal Usability Test Results 131

Comparison of different stakeholder groups

10 9 8 7 6 All respondents 5 Designers 4 Product Owners

Assigned rankAssigned 3 2 1 0

) ” ls int ils) r et ai am a e t Po cto h e et a l s d er e SDS d e e diagr o r 10. Verbalow Th xc P (n E 1. n . (mo . urve 2 8 C n . riso 7. “Form f rbal & PowerPoint son (brief3 details) riso ri pa pa pa 9. Ve om Com Com 4. 6. 5. C Method number

Figure 4. Comparison: All, Designers and Product Owners (lowest point is best) (1+3)/2 = 2). A lower average ranking means a possible to do a follow-up study of the attitudes better result in the evaluation, although it gives of the participants, so the analysis is based on no information about the number of times it has the knowledge we have of the operations at the been chosen. company and the context where they worked. To Figure 4 shows a summary of the results for verify these results, further studies are needed. all respondents and a comparison with the re- Method 3: The Curve Diagram. Design- sults for the group of Designers and Product ers ranked this presentation highly because if Owners. For all respondents, total rank is very it is interpreted properly, it can give a great similar to ranking according to points allocated, deal of information about the use case as it and only two methods (ranked 5 and 6) have is performed on the device. If the device per- swapped places. Three methods head the list. forms poorly in comparison to the other de- Two are verbal presentations, one being sup- vices, which can easily be seen by the placement ported by PowerPoint and the other is purely and shape of the curve, this indicates that there verbal. are problems that need to be investigated fur- Even within the two groups of Designers and ther. Use case performance time indicates the Product Owners, there is little discrepancy be- performance of the device, which can be corre- tween the results for total rank and position ac- lated with user satisfaction. The shape of the cording to points awarded. Table 1 illustrates curve illustrates when problems arose. If prob- the ranks. The Methods are ordered according lems arise when performing the use case, these to the points allocated by all respondents. The will be visible in the diagram and the Design- next columns show the composite results, for all ers will know that there are issues that must respondents and according to the two groups. be attended to. Cases where the opinions differ significantly be- Product Owners ranked this method poorly tween Designers and Product Owners (a differ- because the information is on the level of an in- ence of 3 places or more) will be the subject of dividual use case, whilst they need information a brief discussion, to see whether we can draw about the product or device at a coarser level of any tentative conclusions about the presentation detail that is easy to interpret, giving an overall requirements of the different stakeholder groups. view of the product. They trust that problems These methods, which are shown in italics in Ta- at this level of detail are dealt with by the De- ble 1, are Methods 1, 3, 4 and 8. Since the com- signers, whilst they have responsibility for the pany has now ceased operations, it is no longer product and process as a whole. 132 Jeff Winter, Kari Rönkkö

Table 1. Comparison of ranks: All, Designers and Product Owners Rankings Method All respondents Designers Product Diﬀerence Owners between groups 9. Verbal & PowerPoint 1 1 3 2 6. Comparison (more details) 2 3 2 1 10. Verbal 3 4 4 0 8. PowerPoint 4 7 1 6 5. Comparison (brief details) 6 6 5 1 3. Curve diagram 5 2 9 7 1. The SDS 7 5 10 5 4. Comparison (no details) 8 8 5 3 7. “Form factor” 9 9 7 2 2. Spreadsheet 10 10 8 2

Method 8: PowerPoint presentation, no Owners are often schooled in an engineering tra- verbal presentation. This can contain several dition and are used to this way of presenting ways of presenting the results of testing. De- information. signers find this type of presentation of lim- Method 1: The Structured Data Summary ited use because of the lack of contextual in- (the SDS). Designers value this method of pre- formation and the lack of opportunity to pose sentation because of the extent and character of follow-up questions. It gives a lot of information, the contextual information it includes, and be- but does not contain sufficient details to allow cause of the way the data is visualised. For ev- Designers to identify the problems or make de- ery device and use case, there is information on cisions about solutions. Without details of the issues that were observed, and records of com- context and what happened in the testing situ- ments made by the testers. It is easy to see ation, it is hard to interpret differences between which use cases were problematic, due to the devices, to know which problems there are in number of comments written by the test leader, the device, and thereby difficult to know what and the presence of many user comments also to do about the problems. The length of time suggests that there are issues that need inves- taken to produce the presentation also means tigation. The contextual information gives clues that it is not suitable for Designers, who are to problems and issues that must be dealt with concerned with fixing product issues as early and gives hints on possible solutions. The effort in the development process as possible. We also required to read and summarise the information believe that there is also a difference in “cul- contained in the spreadsheet, leading to a de- ture” where Designers are still unused to be- gree of cognitive friction, means however that it ing presented with results in this fashion, and is rated in the middle of the field rather than cannot translate this easily to fit in with their higher. work practices. Product Owners rate this method poorly This type of presentation is of primary in- because they are uninterested in products on terest to Product Owners because it provides the level of use cases, which this presentation an overall view of the product in comparison gives provides, and it is difficult to interpret for to other devices, without including too much the device as a whole. The information is not information about the context and test situa- adapted to the broad view of the product that tion. It contains sufficient text, and gives an the Product Owners need. The contextual in- indication of the status of the product. It is formation is difficult to summarise and does not also adapted to viewing without the presence give a readily understandable of the device as a of the test leader, so the recipient can view the whole. Product Owners find it difficult to make presentation and return to it at will. Product use of the information contained in this spread- Satisfying Stakeholders’ Needs – Balancing Agile and Formal Usability Test Results 133 sheet and thereby rank it as least useful for their the interaction designers are most active, was needs. best satisfied through the verbal presentations of Method 4: Comparison of two factors (ba- early results and verbal presentation supported sic version). The lack of detail and of contextual by PowerPoint, whilst a non-verbal presenta- information make if difficult for Designers to tion, in conjunction with the metrics data in the read any information that allows them to iden- spreadsheet and the SDS would be more appro- tify problems with the device. It simply provides priate later in the project, where the project ac- them with a snapshot of how their product com- tivities were no longer as dependent on the work pares to other devices at a given moment. tasks and activities of the interaction designers. Product Owners ranked this in the middle A second respondent (D) stated that the ver- of the field. This is a simple way of visualising bal presentations are most appropriate in the re- the state of the product at a given time, which quirements/design processes. Once the problem is easy to compare over a period of time, to see domain is understood, and the task is to iterate whether a device is competitive with the other towards the best solution, the metrics data and devices included in the comparison. This is typ- the SDS would become more appropriate, be- ically one of the elements that are included in cause the problem is understood and the quali- the PowerPoint presentation that Product Own- tative answers are more easily interpreted than ers have ranked highest (Method 8). However, the qualitative answers. this particular method, when taken in isolation, Another respondent (PO) wrote that it was lacks the richness of the overall picture given in important to move the focus from methods that Method 8 and is therefore ranked as lower. were primarily concerned with verification to- To summarise these results, we find that the wards methods that could be of assistance in re- greatest difference between the two groups con- quirements handling, in prioritisation and deci- cerns the level of detail included in the presen- sion making in the early phases of development. tation, the ease with which the information can In other words, the methods presented are most be interpreted, and the presence of contextual appropriate for later stages of a project, and information in the presentation. Designers pri- there is a lack of appropriate methods for early oritise methods that give specific information stages. about the device and its features. Product Own- Given the limited number of answers to these ers prioritise methods that give more overarch- questions, it is of course difficult to draw any ing information about the product as a whole, general conclusions, although it does appear to and that is not dependent on including contex- be the case that the verbal results are most im- tual information. portant in the early stages of a project, to those who are involved in the actual work of design- 6.1. Changing Information Needs ing and developing the product, whilst the more quantitative data is more useful as reference ma- Participants were informed that the survey was terial in the later stages of a project, or further mainly focused on the presentation of results projects. that are relevant during ongoing design and development. We pointed out that we believed that 6.2. Attitudes Towards the Role of different presentation methods may be impor- the Test Leader tant in the starting and finishing phases of these processes. We stated that comments regarding The respondents were asked to judge whether this would be appreciated. Three respondents or not they would need the help of the test wrote comments about this factor. leader in order to understand the presentation One respondent (D) stated that the infor- method in question. Two of the respondents sup- mation needed in their everyday work as a UI plied no answers to this question, and one of designer, in the early stages of projects when the respondents only supplied answers regarding 134 Jeff Winter, Kari Rönkkö methods 9 and 10, which presuppose the pres- presentation is found in several variants in the ence of the test leader and are therefore excluded study, and those with more explanatory detail from the analysis. If we exclude these three re- are more popular than those with fewer details. spondents from the summary, there were seven Following these is a block of graphical presenta- respondents, of whom four gave answers for all tion methods that are not designed to be depen- eight methods, one gave five answers, and two dent on verbal explanations. Amongst these is gave three answers. The three respondents who a spreadsheet containing qualitative data about did not answer these questions were all Product the test results. At the bottom of the list is a Owners, meaning that there were five designers spreadsheet that contains the quantitative data and two Product Owners who answered these from the study. This presentation differs in char- questions. acter from the SDS, the spreadsheet containing Analysis of the answers showed that, with qualitative data, since the SDS offers a view of the exception of Method 7 the methods that are the data that allows the identification of prob- primarily graphical representations of the data lem areas for the tested devices. This illustrates do not appear to require the presence of the the fact that even a spreadsheet, if it offers a test leader to explain the presentation. Method graphical illustration of the data that it con- 7 was found to require the presence of the test tains, can also be found useful for stakeholders, leader, presumably because it was not directly even without an explicit explanation of the data concerned with the operations of the company. that it contains. The spreadsheets however, one containing qual- Concerning the second question, we could itative and one containing quantitative data, identify differences between the two groups of both require the presence of a test leader to ex- stakeholders, and the greatest difference be- plain the contents. tween the groups concerns the level of detail in- Given the fact that the Designers were in the cluded in the presentation, the ease with which majority, there were few obvious differences be- the information can be interpreted, and the pres- tween Designers and Product Owners, although ence of contextual information in the presenta- the most consistent findings here regard meth- tion. Designers prioritise methods that give spe- ods 4, 5, and 6, variations of the same presenta- cific information about the device and its fea- tion method with different amounts of written tures. Product Owners prioritise methods that information. Here, Product Owners needed the give more overarching information about the test leader to be present whilst Designers did product as a whole, and that is not dependent not. on including contextual information. We also found that both groups chose PowerPoint pre- 6.2.1. In Summary sentations as their preferred method, but that the Designers chose a presentation that was pri- We now summarise the results of the research marily verbal, whilst Product Owners preferred questions posed in this case study. The answer the purely visual presentation. Another aspect to the first question, whether any presentation of this second question is the attitude towards methods are generally preferred, is that the re- the role of the test leader, where there were spondents as a whole generally preferred verbal few obvious differences between Designers and presentations. The primarily verbal methods are Product Owners. The most consistent findings found in both first and third place. The most here concern variations of the same presenta- popular form was a PowerPoint presentation tion method with different amounts of writ- that was supported by verbal explanations of the ten information. Here, Product Owners needed findings. In second place is a non-verbal illustra- the test leader to be present whilst Designers tion showing a comparison of two factors, where did not. detailed information is given explaining the di- Regarding the third question, if there are agram and the results it contains. This type of methods that are lacking in the current presen- Satisfying Stakeholders’ Needs – Balancing Agile and Formal Usability Test Results 135 tation methods, it was found that taking into for quality assurance in development and design account and visualising aspects of UX is be- processes. coming more important, and the results indicate that testing must be adapted to capture these aspects more implicitly. There is also a 7. Discussion need for a composite presentation method combining the positive features of all of the cur- We begin by discussing our results in relation rent methods – however, given the fact that to academic discourses, to answer our first re- there do appear to be differences between in- search question: How can we balance demands formation needs, it may be found to be dif- for agile results with demands for formal results ficult to devise one method that satisfies all when performing usability testing for quality as- groups. surance? We also comment upon two related dis- No clear answers can be found for the fourth courses from the introductory chapter, i.e. the question, whether information needs, and pre- relation between quality and a need for coop- ferred methods change during different phases eration between industry and research, and the of a design and development project. How- relationship between quality and agility. ever, the replies suggest that the required meth- Since we work in a mass-market situation, ods do change during a project, that more and the system that we are looking at is too verbally oriented and qualitative presentations large and complex for a single customer to spec- are important in early stages of a project, in ify, the testing process must be flexible enough the concrete practice of design and develop- to accommodate the needs of many different ment, and that quantitative orientated methods stakeholders. The product must appeal to the are important in later stages and as reference broadest possible group, so it is difficult for material. customers to operate in dedicated mode with Regarding the final question, whether results development team, with sufficient knowledge can be presented without the presence of the to span the whole range of the application, test leader, we find that the methods that are which is what an agile approach requires to primarily graphical representations of the data work best [5]. In this case, test leaders work do not appear to require the presence of the test as proxies for the user in the mass market. leader to explain the presentation. The spread- We had a dedicated specialist test leader who sheets however, containing qualitative and quan- brought in the knowledge that users have, in titative data, both require the presence of a test accordance with Pettichord [24]. Evidence sug- leader to explain the contents. gests that drawing and learning from experi- To verify these results, further studies are of ence may be as important as taking a ratio- course needed. Despite the small scale of this nal approach to testing [21]. The fact that the study, the results give a basis for performing a test leaders involved in the testing are usabil- further study, and allow us to formulate a hy- ity experts working in the field in their every- pothesis for following up our results. In line with day work activities means that they have con- the rest of the work performed as part of this siderable experience of their products and their research, we feel that the this work should be a field. They have specialist knowledge, gained survey based study in combination with an in- over a period of time through interaction with terview based study, in order to verify the results end-users, customers, developers, and other par- from the survey and gain a depth of information ties that have an interest in the testing process that is difficult to obtain from a purely survey and results. This is in line with the idea that based study. agile methods get much of their agility from We continue by discussing the results of the a reliance on tacit knowledge embodied in a two case studies in relation to the industrial situ- team, rather than from knowledge written down ation where we have been working, and the need in plans [5]. 136 Jeff Winter, Kari Rönkkö

It would be difficult to gain acceptance of case is a confirmation of [21]. Here, it is based the test results within the whole organisation on the dynamics of customer relationships, us- without the element of formalism. In sectors ing limited effort in the most effective way, and with large customer bases, companies require the timing of software releases to the needs of both rapid value and high assurance. This can- customers as to which features to release. The not be met by pure agility or plan-driven disci- present paper illustrates how this happens in in- pline; only a mix of these is sufficient, and or- dustry, since the agile type of testing studied ganisations must evolve towards the mix that here is not according to “best practice” but is suits them best [5]. In our case this evolution a complement that meets organisational needs has taken place during the whole period of the for a mass-market product in a rapidly chang- research cooperation, and has reached a phase ing marketplace, with many different customers where it has become apparent that this mix is and end-users. desirable and even necessary. To summarise our second case study, the In relation to the above, Osterweil [23] states findings presented here are the results of a pre- that there is a body of knowledge that could liminary study that indicates the needs of dif- do much to improve quality, but that there is ferent actors in the telecom industry. They are “a yawning chasm separating practice from re- a validation of the ways in which UTUM research that blocks needed improvements in both sults have been presented. They provide guide- communities”, thereby hindering quality. Prac- lines to improving the ways in which the results tice is not as effective as it must be, and research can be presented in the future. They are also a suffers from a lack of validation of good ideas confirmation of the fact that there are different and redirection that result from serious use in groups of stakeholders, the Designers and Prod- the real world. This case study is part of a suc- uct Owners found in our first case study, who cessful cooperation between research and indus- have different information requirements. Further try, where the results enrich the work of both studies are obviously needed, but despite the parts. Osterweil [23] also requests the identifi- small scale of this study, it is a basis for perform- cation of dimensions of quality and measures ing a wider and deeper study, and it lets us for- appropriate for it. The particular understand- mulate a hypothesis regarding the presentation ing of agility discussed in our case study can of testing results. We feel that the continuation be an answer to this request. The agility of the of this work should be a survey based study in test process is in accordance with the “good or- combination with an interview based study. ganisational reasons” for “bad testing” that are argued by Martin et al [21]. These authors state that testing research has concentrated mainly 8. Conclusions and Further Work on improving the formal aspects of testing, such as measuring test coverage and designing tools In the usability evaluation framework, we have to support testing. However, despite advances in managed to implement a working balance be- formal and automated fault discovery and their tween agility and plan driven formalism to sat- adoption in industry, the principal approach for isfy practitioners in many roles. The industrial validation and verification appears to be demon- reality that has driven the development of this strating that the software is “good enough”. test package confirms the fact that quality and Hence, improving formal aspects does not nec- agility are vital for a company that is working essarily help to design the testing that most ef- in a rapidly changing environment, attempting ficiently satisfies organisational needs and min- to develop a product for a mass market. There imises the effort needed to perform testing. In is also an obvious need for formal data that can the results of this work, the main reason for support the quick and agile results. The UTUM not adopting “best practice” is precisely to ori- test package demonstrates one way to balance ent testing to meet organisational needs. Our demands for agile results with demands for for- Satisfying Stakeholders’ Needs – Balancing Agile and Formal Usability Test Results 137 mal results when performing usability testing for References quality assurance. The test package conforms to both the Designer’s manifesto, and the Product [1] K. Beck. Extreme Programming Explained. Ad- Owner’s manifesto, and ensures that there is a dison Wesley, Reading, MA, 2000. [2] P. Berander and P. Jönsson. Hierarchical cu- mix of agility and formalism in the process. mulative voting (HCV) – prioritization of re- The case in the present paper confirms quirements in hierarchies. International Journal the argumentation emphasizing ’good organi- of Software Engineering & Knowledge Engineer- zational reasons’, since this type of testing is ing, 16(6):819, 2006. not according to “best practice” but is a com- [3] P. Berander and C. Wohlin. Identification of plement that meets organisational needs for key factors in software process management – a mass-market product in a rapidly chang- a case study. In 2003 International Symposium ing marketplace, with many different customers on Empirical Software Engineering, ISESE ’03, pages 316–325, Rome, Italy, 2003. and end-users. This is partly an illustration of [4] B. W. Boehm. A spiral model of software the chasm between industry and research, and development and enhancement. Computer, partly an illustration of how agile approaches 21(5):61–72, 1988. are taken to adjust to industrial reality. In re- [5] B. W. Boehm. Get ready for agile methods, lation to the former this case study is a suc- with care. Computer, 35(1):64–69, 2002. cessful cooperation between research and in- [6] B. W. Boehm. Keynote address, 5th Workshop dustry. It has been ongoing since 2001, and on Software Quality (WoSQ), 2007. [7] J. Brooke. System usability scale (SUS): a the work has an impact in industry, and re- Quick-and-Dirty method of system evaluation sults enrich the work of both parts. The in- user information, 1986. clusion of Sony Ericsson in this case study [8] BTH. UIQ, usability test. http://www.youtube. gave even greater possibilities to spread the com/watch?v=5IjIRlVwgeo, Aug. 2008. benefits of the cooperative research. More and [9] A. Cockburn and J. Highsmith. Agile Software more hybrid methods are emerging, where ag- Development. The Agile Software Development ile and plan driven methods are combined, Series. Addison-Wesley, Boston, 2002. and success stories are beginning to emerge. [10] Y. Dittrich, C. Floyd, and R. Klischewski. Doing Empirical Research in Software Engi- We see the results of this case study and the neering: finding a path between understanding, UTUM test as being one of these success sto- intervention and method development, pages ries. How do we know that the test is suc- 243–262. MIT Press, 2002. cessful? By seeing that it is in successful use [11] Y. Dittrich, K. Rönkkö, J. Erickson, C. Hans- in everyday practice in an industrial environ- son, and O. Lindeberg. Co-operative method ment. We have found a successful balance be- development: Combining qualitative empirical tween agility and formalism that works in in- research with method, technique and process improvement. Journal of Empirical Software dustry and that exhibits qualities that can be Engineering, 2007. of interest to both the agile and the software [12] Y. Dittrich, K. Rönkkö, O. Lindeberg, J. Er- engineering community. ickson, and C. Hansson. Co-operative method Acknowledgements This work was partly development revisited. SIGSOFT Softw. Eng. funded by The Knowledge Foundation in Swe- Notes, 30(4):1–3, 2005. den under a research grant for the software de- [13] J. N. Gordon. Institutions as relational in- velopment project “Blekinge – Engineering Soft- vestors: A new look at cumulative voting. ware Qualities”, www.bth.se/besq. Thanks to Columbia Law Review, 94(4):124–193, 1994. [14] M. J. Harrold. Testing: A roadmap. In Proceed- the participants in the study and to my col- ings of the Conference on the Future of Software leagues in the U ODD research group for their Engineering, Limmerick, Ireland, 2000. ACM help in data analysis and structuring my writing. Press. Thanks also to Gary Denman for permission to [15] M. Hassenzahl, E. L. Law, and E. T. Hvannberg. use the Structured Data Summary. User experience – towards a unified view. In 138 Jeff Winter, Kari Rönkkö

UX WS NordiCHI’06, pages 1–3, Oslo, Norway, In 9th international conference on Software En- 2006. cost294.org. gineering, pages 328–338, Monterey, California, [16] M. Hassenzahl and N. Tractinsky. User experi- United States, 1987. IEEE Computer Society ence – a research agenda. Behaviour & Infor- Press. mation Technology, 25(2):91–97, 2006. [31] J. Sawyer and D. McRae, Jr. Game the- [17] International Organization for Standardization. ory and cumulative voting in Illinois: 1902– ISO 9241-11 (1998): Ergonomic requirements 1954. The American Political Science Review, for office work with visual display terminals 56(4):936–946, 1994. (VDTs) – part 11: Guidance on usability. Tech- [32] D. Schuler and A. Namioka. Participatory De- nical report, 1998. sign – Principles and Practices, volume 1st. [18] International Organization for Standardization. Lawrence Erlbaum Associates, Hillsdale, New ISO 9126-1 software engineering – product qual- Jersey, 1993. ity – part 1: Quality model, 2001. [33] I. Sommerville. Software Engineering, volume 8. [19] Investopedia.com. Cumulative voting. Addison Wesley, 1982. http://www.investopedia.com/terms/c/ [34] D. Talby, O. Hazzan, Y. Dubinsky, and cumulativevoting.asp, Apr. 2009. A. Keren. Agile software testing in a Large-Scale [20] D. Leffingwell and D. Widrig. Managing Soft- project. IEEE Software, 23(4):30–37, 2006. ware Requirements: A Use Case Approach, vol- [35] The Agile Alliance. The agile manifesto. http: ume 2nd. Addison Wesley, 2003. //agilemanifesto.org/, Apr. 2009. [21] D. Martin, J. Rooksby, M. Rouncefield, and [36] The Agile Alliance. Principles of ag- I. Sommerville. ‘Good’ organisational reasons ile software. http://www.agilemanifesto.org/ for ‘Bad’ software testing: An ethnographic principles.html, Apr. 2009. study of testing in a small software company. [37] U-ODD. Use-Oriented Design and Devel- In ICSE ’07, Minneapolis, MN, 2007. IEEE. opment. http://www.bth.se/tek/u-odd, Apr. [22] E. Mumford. Advice for an action re- 2009. searcher. Information Technology and People, [38] UIQ Technology. Company information. http: 14(1):12–27, 2001. //uiq.com/aboutus.html, June 2008. [23] L. Osterweil. Strategic directions in software [39] UIQ Technology. UIQ Technology Usability quality. ACM Computing Surveys (CSUR), Metrics. http://uiq.com/utum.html, June 2008. 28(4):738–750, 1996. [40] UIQ Technology. UTUM website. http://uiq. [24] B. Pettichord. Testers and developers think dif- com/utum.html, June 2008. ferently. STGE magazine, Vol. 2(Jan/Feb 2000 [41] UXEM. User eXperience Evaluation Meth- (Issue 1)), 2000. ods in product development (UXEM). [25] S. L. Pfleeger and J. M. Atlee. Software Engi- http://www.cs.tut.fi/ihte/CHI08_workshop/ neering, volume 3rd. Prentice Hall, Upper Sad- slides/Poster_UXEM_CHI08_V1.1.pdf, June dle River, NJ, 2006. 2008. [26] B. Regnell, M. Höst, J. N. och Dag, P. Bere- [42] UXNet: the user experience network. http: mark, and T. Hjelm. An industrial case study //uxnet.org/, June 2008. on distributed prioritisation in Market-Driven [43] Wikipedia. Cumulative voting. http: requirements engineering for packaged software. //en.wikipedia.org/wiki/Cumulative_voting, Requirements Engineering, 6(1):51–62, 2001. Apr. 2009. [27] C. Robson. Real World Research, volume 2nd. [44] J. Winter, K. Rönkkö, M. Ahlberg, M. Hinely, Blackwell Publishing, Oxford, 1993. and M. Hellman. Developing quality through [28] K. Rönkkö. Making Methods Work in Software measuring usability: The UTUM test package. Engineering: Method Deployment as a Social In ICSE 2007, 5th Workshop on Software Qual- achievement. PhD thesis, Blekinge Institute of ity, at ICSE 2007, 2007. Technology, School of Engineering, 2005. Dis- [45] WoSQ. Fifth workshop on software quality, at sertation Series No. 2005:04; Doctoral Thesis. ICSE 07. http://attend.it.uts.edu.au/icse2007/, [29] K. Rönkkö. Ethnography. In P. Laplante, edi- June 2008. tor, Encyclopedia of Software Engineering. Tay- [46] R. K. Yin and S. Robinson. Case Study Re- lor and Francis Group, New York, 2008. search – Design and Methods, volume 3rd of [30] W. W. Royce. Managing the development of Applied Social Research Methods Series. SAGE large software systems: concepts and techniques. publications, 5, 2003. e-Informatica Software Engineering Journal, Volume 3, Issue 1, 2009

Web–Server Systems HTCPNs-Based Development Tool Application in Load Balance Modelling

Slawomir Samolej∗, Tomasz Szmuc∗∗

∗Department of Computer and Control Engineering, Rzeszów University of Technology ∗∗Institute of Automatics, AGH University of Science and Technology [email protected], [email protected]

Abstract A new software tool for web–server systems development is presented. The tool consist of a set of predeﬁned Hierarchical Timed Coloured Petri Net (HTCPN) structures – patterns. The patterns make it possible to naturally construct typical and experimental server–systems structures. The preliminary patterns are executable queueing systems. A simulation based methodology of web–server model analysis and validation has been proposed. The paper focuses on presenting the construction of the software tool and its application for selected cluster–based web–servers load balancing strategies evaluation.

1. Introduction puters that constitute the front-end or WWW cluster. The front–end cluster offers a system Gradually, the Internet becomes the most im- interface and some procedures that optimize portant medium for conducting business, sell- the load of the next system layer–the database ing services and remote control of industrial server. processes. Typical modern software applications To improve the quality of service of have a client–server logical structure where pre- web–server clusters two main research paths dominant role plays an Internet server offer- are followed. First, the software of individual ing data access or computation abilities for re- web–server nodes is modified to offer average mote clients. The hardware of an Internet or response time to dedicated classes of consumers web–server is now usually designed as a set of [11], [18], [19]. Second, some distribution strate- (locally) deployed computers. The computers gies of cluster nodes are investigated [4], [29] in are divided into some layers or clusters where conjunction with searching for load balancing each layer executes separate web–system task policies for the nodes [6], [32], [39], [37], [5], [2], [4], [12], [24], [34], [39], [37], [5], [2], [22], [9], [29], [22]. In several research projects reported in [12], [23]. This design approach makes it possible to [30], [34] load balancing algorithms and modified distribute services among the nodes of a cluster cluster node structures are analyzed together. and to improve the scalability of the system. Re- It is worth noticing that in some of above- dundancy which intrinsically exists in such hard- mentioned manuscripts searching for a solution ware structure provides higher system depend- of the problem goes together with searching for ability. Fig. 1 shows an example cluster–based the adequate formal language to express the Internet system structure. The Internet requests system developed [3], [12], [30], [32], [34], [39]. are generated by the clients. Then they are dis- In [3], [32], [34], [39] Queueing Nets whereas tributed by the load balancer among set of com- in [30] Stochastic Petri Nets are applied for 140 Slawomir Samolej, Tomasz Szmuc

Figure 1. Example distributed cluster–based Internet system system model construction and examination. – The basic patterns will be executable models However, the most mature and expressive lan- of queueing systems, guage proposed for the web–cluster modelling – A set of design rules will be provided to cope seems to be Queueing Petri Nets (QPNs) [12]. with the patterns during the system model The nets combine coloured and stochastic Petri creation, nets with queueing systems [1] and consequently – The final model will be an executable and an- make it possible to model relatively complex alyzable Hierarchical Timed Coloured Petri web–server systems in a concise way. Moreover, Net, there exists a software tool for the nets sim- – A well established Design/CPN and CPN ulation [13]. The research results reported in Tools software toolkits will be used for the [12] include a systematic approach to apply- design patterns construction and validation, ing QPNs in distributed applications modelling – The toolkits will also be used as a platform and evaluation. The modelling process has been for the web–server modelling and develop- divided into following stages: system compo- ment, nents and resources modelling, workload mod- – Performance analysis modules of the toolkits elling, intercomponent interactions and process- will be used for capturing and monitoring the ing steps modelling, and finally – model param- state of the net during execution. eterization. The final QPNs based model can be The choice of HTCPNs formalism as a mod- executed and used for modelled system perfor- elling language comes from the following pre- mance prediction. requisites. First, HTCPNs have an expression The successful application of QPNs in power comparable to QPNs. Second, the avail- web–cluster modelling become motivation to re- able software toolkits for HTCPNs composi- search reported in this paper. The aim of the tion and validation seem to be more popu- research is to provide an alternative methodol- lar than“SimQPN” [13]. Third, there exists a ogy and software tool for cluster–based hard- reach knowledge base of successful HTCPNs ware/software systems development. The main applications to modelling and validation of features of the methodology are as follows: wide range software/hardware systems [7] in- – The modelling language will be Hierarchical cluding web–servers [24], [27], [36]. The rest Timed Coloured Petri Nets (HTCPNs) [7], named features of design methodology intro- – A set of so called HTCPNs design patterns duced in this paper results from both gen- (predefined net structures) will be prepared erally known capabilities of software toolkits and validated to model typical web cluster for HTCPNs modelling and some previous ex- components, perience gained by the authors in applica- Web–Server Systems HTCPNs-Based Development Tool Application in Load Balance Modelling 141 tion HTCPNs to real–time systems develop- tion has been proposed. The top–level TCPN ment [25], [26]. represents the general view of system compo- This paper is organized as follows. Section nents. The middle–level TCPNs structures rep- 2 describes some selected design patterns and resent the queueing systems interconnections. rules of applying them to web–server cluster And the lowest level includes executable queue- model construction. An example queueing sys- ing systems implementations. tem, web–server subsystem and top–level sys- The modelling methodology assumes, that tem models are presented. Then the simulation the actual state of the Internet requests servic- based HTCPNs models validation methods are ing in the system can be monitored. Moreover, discussed. Section 3 presents HTCPNs models of from the logical point of view the model of the selected experimental and applied load balanc- server cluster is an open queueing network, so ing strategies for computer clusters. The load the requests are generated, serviced and finally balancing models construction and some simu- removed from the system. As a result an impor- lation results are discussed. Conclusions and fu- tant component of the software tool for server ture research program complete the paper. cluster development is the logical representation It has been assumed that the reader is fa- of the requests. miliar with the basic principles of Hierarchical In the next subsections the following features Timed Coloured Petri Nets theory [7], [8], [14]. of the modelling methodology will be explained All the Coloured Petri Nets in the paper have in detail. First, the logical representation of In- been edited and analysed using Design/CPN ternet requests will be shown. Second, queueing tool [21], [36]. Equivalent HTCPNs models may system modelling rules will be explained. Third, be developed using CPN Tools [8], [35] software an example cluster subsystem with an individ- toolkit. ual load–balancing strategy will be proposed. Fourth, Internet request generator structure will be examined. Fifth, top–level HTCPNs struc- 2. Cluster Server Modelling ture of an example cluster–server model will be Methodology shown. Finally, model analysis capabilities will be discussed. The main concept of the methodology lies in the definition of reusable timed coloured Petri nets 2.1. Logical Request Representation structures (patterns) making it possible to compose web–server models in a systematic manner. In the server–cluster modelling methodology The basic set of the patterns includes typical that is introducing in the paper the structure queueing systems TCPNs implementations, eg. of the HTCPN represents a hardvare/software –/M/PS/ , –/M/FIFO/ [24], [27]. Packet architecture of web–server. Yet, the dynamics of ∞ ∞ distribution TCPNs patterns constitute the next the modelled system behavior is determined by group of reusable blocks. They preliminary role state and allocation of tokens in the net struc- is to provide some predefined web–server clus- ture. Two groups of tokens has been proposed for ter substructures composed from the queueing model construction. The first group consists of systems. At this stage of subsystem modelling the so–called local tokens, that “live” in individ- the queueing systems are represented as sub- ual design patters. They provide local functions stitution transitions (compare [24], [27]). The and data structures for the patterns. The sec- separate models of system arrival processes are ond group of tokens represents Internet requests also the members of the group mentioned. The that are serviced in the system. They are trans- packet distribution patterns represented as sub- ported throughout several cluster components. stitution transitions are in turn used for the gen- Their internal state carries data that may be eral top–level system model composition. As a used for timing and performance evaluation of result, the 3–level web–server model composi- the system modelled. As the tokens represent- 142 Slawomir Samolej, Tomasz Szmuc ing the requests have the predominant role in place after ADD_FIFO transition execution. the modelling methodology, they structure will TIMERS place and REMOVE_FIFO transi- be explained in detail. tion constitute a clock–like structure and are Each token representing an Internet request used for modelling of duration of packet exe- is a tuple cution. When REMOVE_FIFO transition fires, PACKAGE = (ID, PRT, START_TIME, then the first packet from the queue is with- drawn and directed to the service procedure. PROB, AUTIL, RUTIL), The packets under service acquire the ade- where ID is a request identifier, PRT is a request quate time stamps generated according to the priority, START_TIME is a value of simula- assumed service time random distribution function time when the request is generated, PROB tion. The time stamps associated with the is a random value, AUTIL is an absolute request tokens prevent from using the packet tuples utilization value, and RUTIL is a relative re- (the tokens) for any transition firing until the quest utilization value. Request identifier makes stated simulation time elapses (according to fir- it possible to give the request an unique number. ing rules defined for HTCPNs [7]). The pack- Request priority is an integer value that may ets are treated as serviced when they can leave be taken into consideration when the requests OUTPUT_PACKS place as their time stamps are scheduled according priority driven strategy expired. The number of tokens in TIMERS place [11]. START_TIME parameter can store a sim- defines the quantity of queue servicing units in ulation time value and can be used for the tim- the system. ing validation of the requests. Absolute request Main parameters that define the queueing utilization value, and relative request utilization system model dynamics are queue mean service value are exploited in some queueing systems time, service time probability distribution func- execution models (e.g. with processor sharing tion and number of servicing units. Capacity of service). the queue is not now taken into consideration and theoretically may be unlimited. 2.2. Queueing System Models For future applications the primary queueing system design pattern explained above has The basic components of the software tool for been equipped with an auxiliary “plug–in”. web–server clusters development introduced in COUNT_QL transition and TIMER_QL, QL this paper are the executable queueing systems and COUNTER places make it possible to mea- models. At the current state of the software tool sure the queue length and export the mea- construction the queueing systems models can sured value to the parent CPNs page during have FIFO, LIFO, processor sharing or prior- the net execution. TIMER_QL place includes ity based service discipline. For each queue an a timer token that can periodically enable the arbitrary number of service units may be de- COUNT_QL transition. QL port place includes fined. Additionally, the basic queueing systems a token storing the last measured queue length has been equipped with auxiliary components and an individual number of a queueing system that are responsible for monitoring of internal in the system. The COUNTER place includes a states of the queue during its execution. counter token used for the synchronization pur- An example HTCPNs based –/1/FIFO/ pose. ∞ queueing system model is shown in Fig. 2. The model is a HTCPNs subpage that 2.3. Packet Distribution Models can communicate with the parent page via INPUT_PACKS, OUTPUT_PACKS and QL Having a set of queueing systems design pat- port places. Request packets (that arrive terns some packet distribution HTCPNs struc- through INPUT_PACK place) are placed tures may be proposed. In [24] a typical ho- into a queue structure within PACK_QUEUE mogeneous multi–tier web–server structure pat- Web–Server Systems HTCPNs-Based Development Tool Application in Load Balance Modelling 143

P Ge FG Fifo queue n QL_A_ID INT QL COUNTER 1`0

1`(length fifo_queue, qlen_a_id n+1 #2 qlen_a_id) TIMER 1`1 n tim1 TIMERS TIMER TIMER_QL COUNT_QL 1`1 1`tim1@+ ql_timer_val fifo_queue 1`tim1 1`tim1@+tim_val update_FIFO P Ge P Ge fifo_queue nil (fifo_queue) REMOVE_FIFO n n pack INPUT_PACKS PACK_QUEUE OUTPUT_PACKS

C PACKAGE ADD_FIFO add_FIFO(pack,fifo_queue) fifo_queue release_FIFO PACKAGE (fifo_queue)@+tim_val PACK_QUEUE [fifo_queue<>nil] output (tim_val); action discExp(1.0/fifo1_ser_mean_time) ; Figure 2. HTCPNs based –/1/FIFO/ queueing system model ∞

Load Balacer Server Cluster

FIFO1 PACKAGE

T3 PACKS3 PACKS8 T8 pack pack pack pack pack HS PACKAGE pack

P In FIFO2 PACKAGE P Out

PACKS1 T4 PACKS4 PACKS9 T9 PACKS13 pack pack pack pack pack pack PACKAGE PACKAGE PACKAGE HS

pack pack FIFO3 PACKAGE

T5 PACKS5 PACKS10 T10 pack pack pack pack PACKAGE HS

Figure 3. WWW cluster with stochastic load balancer tern was examined, in [23] a detailed distributed ter consists of 3 computers (compare Fig. 1) database cluster model was proposed, whereas represented as FIFO1 ... FIFO3 substitution in [27] a preliminary version of server structure transitions, where each transition is attached with feedback like admission control of Inter- to the corresponding FIFO queueing pat- net requests was introduced. The packet dis- tern. The Internet requests serviced by the tribution patterns presented in this paper are cluster arrive through PACKS1 port place. also related to the load balancing in web–server A load balancer decides where the cur- cluster problem. The detailed discussion of some rently acquired request should be send. When selected load balancing strategies models is in- a token arrives in PACKS1 place, transi- cluded in section 3. In this section a simple tions T3 ... T5 are in conﬂict. According to WWW cluster model with stochastic packed dis- CPN properties, a transition is randomly tribution policy is concerned. chosen for ﬁring. Consequently, the stochas- Figure 3 includes an example of clus- tic packet distribution policy is naturally ter load–balancing HTCPNs model. The clus- modelled. 144 Slawomir Samolej, Tomasz Szmuc

2.4. Request Generator Model modelled and tested at the early stage of development process. At the top–level modelling According to one of main assumptions of the process each of the main components of the sys- web–server cluster modelling methodology pre- tem can be represented as a HTCPNs substitu- sented in this paper, the system model can be tion transition. The modelling methodology pre- treated as an open queueing network. Conse- sented in the paper suggest that at the top–level quently, the crucial model component must be a model construction the arrival process and main network arrival process simulating the Internet server cluster layers should be highlighted. Af- service requests that are sent to the server. ter that each of the main components (main Figure 4 shows an example HTCPNs sub- substitution transition) should be decomposed page that models a typical Internet request gen- into an adequate packed distribution subpage, erator. The core of the packet generator is a were under some of transitions queueing system clock composed from TIMER0 place and T0 models will be attached. It is easily to notice transition. The code segment attached to the that a typical top–down modelling approach of T0 transition produces values of time–stamps software/hardware system modelling has been for tokens stored in TIMER0 place. The values adapted in the web server modelling methodol- are defined by the defined probability function. ogy proposed in the paper. As a result the Internet requests appear into Figure 5 includes an example top–level PACKS1 place at random moments in simula- HTCPN model of cluster–based server (com- tion time. The frequency at which tokens ap- pare Fig. 1) that follows the abovementioned pear in PACKS1 place is determined by the modelling development rules. The HTCPN mentioned above distribution function. PACKS1 in Fig. 5 consists of 3 substitution transi- place has a port place status and thereafter to- tions. Input_P rocs transition represents the kens appearing in it can be consumed by other arrival process for the server cluster, whereas model components (e.g. server cluster model). WWW _Server_Cluster transition represents the first–layer of multi–tier web–server, and fi- INT 1`1 nally DataBaseServer transition represents the COUNT0 data base server. n+1 (n,1,intTime(), The modelling process can be easily ex- ran'random_val(),0,0) TIMER 1`1 n tended by attaching the request generator model tim1 P Ge TIMER0 T0 PACKS1 as in section 2.4 under the Input_P rocs transi- tim1 n C tion and by attaching the WWW cluster model @+tim_val PACKAGE output (tim_val); with load balancing module as in section 2.3 action under WWW _Server_Cluster transition. The discExp(1.0/ pack_gen_mean_time); final executable model can be acquired by attaching FIFO design patterns under FIFO1, Figure 4. Web–server arrival process model FIFO2 and FIFO3 transitions in the load balancing module (compare sections 2.2 and 2.3). The Internet request frequency can have any A separate model should be proposed for the standard probability distribution function or packet distribution and queueing models layers can be individually constructed as it was proof the data base server. posed in [36]. 2.6. Model Validation Capabilities 2.5. Example Top–Level Multi–Tier Server Model Typical elements of HTCPNs modelling software tools are performance evaluation routines, Having the adequate set of design patterns, a e.g.: [16], [35] . The routines make it possible to wide area of server cluster architectures can be capture the state of dedicated tokens or places Web–Server Systems HTCPNs-Based Development Tool Application in Load Balance Modelling 145

Input_Procs WWW_Server_Cluster DataBaseServer PACKAGE PACKAGE PACKAGE

PACKS1 PACKS13 PACKS18

T13

Figure 5. Example top–level multi–tier server model during the HTCPN execution. A special kind anced model can be estimated. Provided that of log files showing the changes in the state of the arrival process model and the server nodes HTCPN can be received and analyzed offline. models parameters are acquired from the real At the currently reported version of devices as in [18], [30], [34], [36], the software web–server cluster modelling and analysis soft- model can be used for derivation the system ware tool, queue lengths and service time properties under different load conditions. In the lengths can be stored during the model ex- Fig. 7 queue lengths (Fig. 7 (left)) and service ecution. Detecting the queue lengths seems times (Fig. 7 (right)) under stable system execu- to be the most natural load measure avail- tion are shown. The cluster had a heterogeneous able in typical software systems. The service structure, where server 2 (FIFO2 model) had time lengths are measurable in the proposed 4 times lower performance. FIFO1 and FIFO3 modelling method because of a special kind average queue length was 1.7, whereas FIFO3 PACKAGE type tokens construction (compare queue length was 4.4. The average service time section 2.1). The tokens “remember” the simu- for FIFO1 and FIFO3 cluster nodes was 811 lation time at which their appear in the cluster time units whereas for FIFO2 was 7471 time and thereafter the time at each state of their units. service may be captured. In real systems the Third, some individual properties of cluster service time is a predominant quality of service node structures or load balancing strategies may parameter for performance evaluation. be observed. Some selected load balancing algo- The performance analysis of models of web rithms properties derived from simulation exper- servers constructed according the proposed in iments will be discussed in section 3. the paper methodology can be applied in the following domains. First, the system instability may be easily 3. Example of Load Balancing detected. The stable or balanced queueing sys- Strategies Evaluation tem in a steady state has an approximately con- stans average queue length and correspondingly Load balancing is an important issue in parallel average service time. On the contrary, when the and distributed systems. In traditional computa- arrival process is to intensive for the queueing tion systems load balancing procedures were used systems to serve, both queue lengths and service to distribute the computation task among system times increase. This kind of analysis is possible nodes. It improved the general system utilisation when there are no limitations for queue lengths and usually led to faster processing. In recent in the proposed modelling method. Fig. 6 shows years, the load balancing algorithms elaborated the queue lengths (Fig. 6 (left)) and service time for general parallel and distributed systems [31] lengths (Fig. 6 (right)) when the considered web were naturally re-applied in the emerging locally server cluster model is permanently overloaded. distributed Internet or web systems. The first Second, the average values of queueing sys- load balancing strategies successively applied in tem systems parameters such as average queue Internet systems were static random distribution lengths and average servicing times for the bal- policy [28] and static modulus-based round-robin 146 Slawomir Samolej, Tomasz Szmuc

Queue 1,2,3 Lengths Service Time Lengths 900 900000 Fifo1_length Server 1 serv. len. 800 Fifo2_length 800000 Server 2 serv. len. 700 Fifo3_length 700000 Server 3 serv. len. 600 600000 500 500000 400 400000 300 300000 Queue Length 200 200000 100 Service Time Length 100000 0 0 0 500000 1e+06 1.5e+06 2e+06 2.5e+06 0 500000 1e+06 1.5e+06 2e+06 2.5e+06 Time [sim. time units] Time [sim. time units] Figure 6. Queue lengths (left) and service times (right) under overload condition

Queue 1,2,3 Lengths Service Time Lengths 12 30000 Fifo1_length Server 1 serv. len. 10 Fifo2_length 25000 Server 2 serv. len. Fifo3_length Server 3 serv. len. 8 20000

6 15000

4 10000 Queue Length

2 Service Time Length 5000

0 0 0 500000 1e+06 1.5e+06 2e+06 2.5e+06 0 500000 1e+06 1.5e+06 2e+06 2.5e+06 Time [sim. time units] Time [sim. time units] Figure 7. Queue lengths (left) and service times (right) under stable system execution policy [15]. There were described in the paper gies for web–oriented systems. Generally, the [38] successful implementations of round-robin, dynamic load balancing polices use some kind weighted round-robin, least-connection and of feedback information from the cluster nodes weight least-connection load balancing strate- to redirect the incoming request among the gies in Linux Virtual Server [17] . The abovemen- nodes. In [30] the so called “fewest server pro- tioned strategies are now standard algorithms cesses first” and “extended fewest server pro- in commercial load balancing solutions as men- cesses first” dynamic load balancing policies tioned in [20], [33]. were compared. The fewest server processes first The rapid development of web–server ori- policy concept is (in our opinion) comparable to ented load balancing policies was tentatively least–connection policy. In both algorithms the systematised in [5], [2]. Paper [5] classi- least loaded server gets the next incoming re- fies distributed web-server architectures request. The “extension” of the preliminary algo- garding the entity which distributes requests rithm lies in the fact that the request can have among servers. It defines 4 approaches of re- priorities. The paper presents high-level Petri quest distribution: client–based, DNS–based, net approach to efficiency analysis of the poli- dispatcher–based, and server–based. In [2] an at- cies in different priority levels scenarios. A dy- tempt of simulation based on comparison of se- namic web system load balancing policy pre- lected load balancing algorithms such as “round sented in [37] (AdaptLoad policy) adopts the robin”, “least connection first”, “round-trip” load of the servers according to size of docu- and “Xmitbyte” was carried out. ments requested. The policy builds a discrete During last few years research has focused data histogram encoding empirical size distri- on the so-called dynamic load balancing strate- bution of batches of K requests as they ar- Web–Server Systems HTCPNs-Based Development Tool Application in Load Balance Modelling 147 rive in the system. Each server “offers” files in Fig. 3. The cluster consists of 3 computers within a certain range of size. The range de- servicing requests incoming via P ACKS1 port pends of “popularity” of the files derived from place. The incoming Internet requests are redis- the histogram. The paper presents simulation tributed among the cluster nodes according to results of the policy behaviour under histori- round-robin load balancing policy. The model cal load conditions. Paper [6] at first discusses of the policy works as follows. Each incoming such so called nonprediction–based load balanc- packet “passes” T 2 transition and after the tran- ing techiques as “first fit”, “stream–based map- sition firing the forth element of the tuple mod- ping” and “adaptive load sharing” correspond- elling the requests (see subsection 2.1) is modi- ingly. The techniques are examined with respect fied. The element includes a number of the server to possible application in multimedia applica- where the packet will be serviced. Guard functions. The prediction–based load balancing tech- tions attached to T 3, T 4, T 5 transitions “check” niques as “least load first”, “prediction–based the fourth element of each packed model and least load first”, “adaptive partition” and “pass” the related requests. The presented load “prediction–based adaptive partition” are intro- balancing policy model can be easily extended duced and experimentally evaluated. In [22] a to “weighted round-robin” policy by extending sum of weighted factors such as CPU usage, the numbers generated for the forth element of memory usage, number of processors, number the packet tuple and by the corresponding mod- of I/O operations, amount of free local storage ifications of the guards. and network I/O usage are taken into consideration to compute the load of a cluster node. The 3.2. Fewest Server Processes First Load load of the node may then be applied to a load Balancing Policy Model balancing policy. At the current state of the development of Figure 9 includes HTCPNs–based model of the the HTCPNs–based tool, some selected load computer cluster similar to the cluster model balancing HTCPNs templates were modelled. in Fig. 3 and Fig. 8. The incoming Internet Three of the most widely applied polices such requests are redistributed among the cluster as “random”, “round-robin” and “fewest server nodes according fewest serwer processes first processes first” were implemented. Addition- load balancing policy. The the model of the pol- ally one experimental–“adaptive load sharing” icy works as follows. During the model execu- policy was chosen for the implementation, be- tion, the lengths of the queues in the queue- cause as it was claimed in [6], this policy of- ing systems modelling servers are periodically fers reasonable balance between the through- monitored. The monitoring is possible due to put and out–of–order departures of the exter- appropriate construction of queueing systems nal requests. In the following subsections the models (compare subsection 2.2). QL1, QL2, HTCPNs–based models of the mentioned load and QL3 places include the current values of balancing policies will be presented. The fi- queue’s lengths. The queue’s lengths are com- nal subsection will include some simulation re- pared during BALANCE transition execution sults of the HTCPNs–based load balancing al- and FEWEST place acquires a number of the gorithms. The model of the simplest– “random” serwer which serves the fewest number of re- load balancing policy was presented in subsec- quests (the server with the shortest request tion 2.3. queue). Guard functions associated to T3, T4, and T5 transitions “open” (for the incoming re- 3.1. Round-robin Load Balancing quests) only this branch of the cluster which Policy Model includes the least loaded server. The frequency of the queue’s lengths measurement can be ad- Figure 8 presents HTCPNs–based model of the justed to derive the balance between additional computer cluster similar to the cluster model system load caused by the measurement and the 148 Slawomir Samolej, Tomasz Szmuc

Load Balacer Server Cluster

FIFO1 PACKAGE

T3 PACKS3 PACKS8 T8 pack (#1 pack, pack pack pack pack #2 pack, HS #3 pack, PACKAGE pack n, [#4 pack =1] #5 pack, #6 pack) P In FIFO2 PACKAGE P Out

PACKS2 T4 PACKS4 PACKS9 T9 PACKS13 PACKS1 T2 pack pack pack pack pack pack pack PACKAGE PACKAGE [#4 pack =2] PACKAGE HS PACKAGE if n<3 then n+1 n else 1 pack pack FIFO3 CUR PACKAGE T5 PACKS5 PACKS10 T10 1`1 INT pack pack pack pack [#4 pack =3] PACKAGE HS

Figure 8. WWW cluster with round-robin load balancing policy

MEAN_TABLE Load Balancer Server Cluster 1`(0,0,0,0,0,0,0,0,0,0,1,0,1) QL1_

mean_ql_val1

find_fewest_proc_of3 (mean_ql_val1,mean_ql_val2,mean_ql_val3) FIFO1 BALANCE [n=k] PACKAGE INT n FEWEST T3 PACKS3 PACKS8 T8 pack k 1`1 pack HS mean_ql_val2 k k PACKAGE H n INT MEAN_TABLE S1_ID 1`1 QL2_ FIFO2 PACKAGE [n=k] T4 PACKS4 PACKS9 T9 1`(0,0,0,0,0,0,0,0,0,0,1,0,2) pack pack PACKAGE H k k pack pack pack mean_ql_val3 INT S2_ID P Gen P Gen pack n 1`2 FIFO3 PACKAGE QL3_ PACKS2 T5 PACKS5 PACKS10 T10 PACKS13 pack pack pack pack MEAN_TABLE [n=k] k PACKAGE PACKAGE k H PACKAGE 1`(0,0,0,0,0,0,0,0,0,0,1,0,3) S3_ID INT 1`3

Figure 9. WWW cluster with fewest server processes first load balancing policy quality of the balance process. It is possible to balancing policy inspired by [6], [10]. The model define digital filters to “smooth out” the queue of the policy works as follows. During the sys- length “signal”. tem model execution lengths of the queues in the queueing systems modelling servers are periodi- 3.3. Adaptive Load Sharing – Load cally monitored. QL1, QL2, and QL3 places in- Balancing Policy Model clude the current values of queue’s lengths. Dur- ing execution of the BALANCE transition the Fig. 10 presents HTCPNs–based model of the utilisation of each node of the cluster is calcu- computer cluster where the incoming Internet lated. Depending on the utilisation values some requests are redistributed among the cluster ranges of amounts of the Internet requests that nodes according to adaptive load sharing load each server may serve are calculated. The cal- Web–Server Systems HTCPNs-Based Development Tool Application in Load Balance Modelling 149

Load Balancer Server Cluster QL_A_ID 1`(0,1) QL1_

qlen_a_id1 1`((1,33),(34,66),(67,100))

BALANCE BAND_TABLE3 count_bands_of3(qlen_a_id1, [b_guard31( b_tab3,pack)] FIFO1 qlen_a_id2, qlen_a_id3) PACKAGE b_tab3 B_TABLE T3 PACKS3 PACKS8 T8 pack b_tab3 pack H qlen_a_id2 PACKAGE H QL_A_ID b_tab3

QL2_ FIFO2 PACKAGE

1`(0,2) T4 PACKS4 PACKS9 T9 pack pack [b_guard32 PACKAGE H ( b_tab3,pack)] pack pack qlen_a_id3 pack b_tab3 P G 1`(0,3) P G pack FIFO3 PACKAGE QL3_ PACKS2 T5 PACKS5 PACKS10 T10 PACKS13 pack pack pack pack PACKAGE QL_A_ID [b_guard33( b_tab3,pack)] H PACKAGE PACKAGE

Figure 10. WWW cluster with adaptive load sharing load balancing policy culated ranges are stored in B_TABLE place. modelled. It can be easily seen, that the load bal- Generally, servers having lower utilisation values ancer does not “notice” the performance degra- will be given more chances to acquire the Inter- dation. The requests directed to second server net requests in the future. Guard functions asso- are serviced later than the others. ciated to T3, T4, and T5 transitions can be un- The queue lengths for clusters where fewest derstand as “valves” that adjust the amounts of server processes first and adaptive load sharing the requests to be passed through to the servers load balancing policies are coping with server 2 according the range table stored in B_TABLE performance degradation are shown in Fig. 12. place. The frequency of the queue’s lengths mea- Both polices (fewest server processes first – surement can be adjusted to derive the balance Fig. 12 (left), adaptive load sharing – Fig. 12 between additional system load caused by the (right)) “reconfigured” the loads for the cluster measurement and the quality of the balance pro- nodes and managed to keep the average queue cess. It is possible to define digital filters to lengths for all cluster nodes at the same level. “smooth out” the queue length “signal”. The simulation experiment proved that dynamic load balancing polices better cope with dynamic 3.4. Simulation Based on Load changes during system execution. However, it Balancing Policies Evaluation must be noticed that the dynamic load balancing policies need some feedback information col- For the above mentioned models of load balanc- lected from the nodes of the cluster. To fulfill ing policies a set of simulation analysies was such requirement both modern load balancers carried out. In Figure 11 results of 2 differ- and cluster nodes (e.g. WWW servers) soft- ent simulations are shown. Figure 11 (left) in- ware must be modified. Additionally the feed- cludes queue lengths of 3 balanced servers where back data collection can increase the load of the load balancing policy followed round-robin algo- system. rithm. In the (right) simulation a performance Figure 13 shows more possibilities for design degradation of server 2 in 200000 time units was of dynamic load–balancing policies. The simula- 150 Slawomir Samolej, Tomasz Szmuc

Queue 1,2,3 Lengths Queue 1,2,3 Lengths 10 45 Fifo1_length Fifo1_length 9 Fifo2_length 40 Fifo2_length 8 Fifo3_length 35 Fifo3_length 7 30 6 25 5 20 4 15 Queue Length 3 Queue Length 10 2 5 1 0 0 50000 100000 150000 200000 250000 300000 350000 400000 0 50000 100000 150000 200000 250000 300000 350000 400000 Time [sim. time units] Time [sim. time units] Figure 11. Queue lengths under round-robin load balancing policy (left) balanced (right) unbalanced after server 2 performance reduction

Queue 1,2,3 Lengths Queue 1,2,3 Lengths 20 45 Fifo1_length Fifo1_length 18 Fifo2_length 40 Fifo2_length 16 Fifo3_length 35 Fifo3_length 14 30 12 25 10 20 8 6 15 Queue Length Queue Length 4 10 2 5 0 0 0 200000 400000 600000 800000 1e+06 1.2e+06 0 2e+06 4e+06 6e+06 8e+06 1e+07 1.2e+07 Time [sim. time units] Time [sim. time units] Figure 12. Queue lengths under fewest server processes first (left) and adaptive load sharing (right) load balancing policy after server 2 performance reduction tion results show that the application of some els of typical queueing systems. The queueing feedback data to cluster state modification may systems templates may be arranged into server cause system’s behaviour similar to control–loop cluster subsystems by means of packet distribu- systems. In Figure 13 (left) the queue lengths os- tion patterns. Finally, the subsystems patterns cillations caused by an inadequate data collec- may be naturally used for top level system mod- tion frequency may be noticed. The system in elling, where individual substitution transitions Fig. 13 (right) seems to “suffer” from the high “hide” the main components of the system. The sensibility that may in consequence lead to the final model is a hierarchical timed coloured Petri instability. net. Simulation and performance analysis are the predominant methods that can be applied for the model validation. Queueing systems tem- 4. Conclusions and Future Research plates was checked whether they meet theoretically derived performance functions. The anal- The first part of the paper introduces the ysis of HTCPNs simulation reports enables to HTCPNs–based software tool providing support predict the load of the modelled system under for development and validation of web–server the certain arrival request stream; to detect the clusters executable models. The main concept stability of the system; to test a new algorithms of the tool lies in the definition of reusable for Internet requests redirection and for their HTCPNs structures (patterns) involving typical service within cluster structures. components of cluster–based server structures. The second part of the paper includes the re- The preliminary patterns are executable mod- view of recently published research results con- Web–Server Systems HTCPNs-Based Development Tool Application in Load Balance Modelling 151

Queue 1,2,3 Lengths Queue 1,2,3 Lengths 120 35 Fifo1_length Fifo1_length 100 Fifo2_length 30 Fifo2_length Fifo3_length Fifo3_length 25 80 20 60 15 40

Queue Length Queue Length 10 20 5 0 0 0 200000 400000 600000 800000 1e+06 1.2e+06 0 200000 400000 600000 800000 1e+06 1.2e+06 Time [sim. time units] Time [sim. time units] Figure 13. Queue lengths under fewest server processes first load balancing policy: queue lengths oscillation (left), high system sensitivity (right) cerning application load balancing policies in M/G/1/K*PS queue. In CT 2003, 10th In- Internet systems. Subsequently, the HTCPNs ternational Conference on Telecommunications, based models of some selected polices have pages 1501–1506. IEEE, 2003. been proposed. The most popular load balanc- [4] V. Cardellini, E. Casalicchio, and M. Cola- janni. The state of the art in locally distributed ing policies models such as “random”, “round web-server systems. ACM Computing Surveys, robin”, and “fewest server processes first” as well Volume 34(2):263–311, June 2002. as one experimental–“adaptive load sharing” [5] V. Cardellini, M. Colajanni, and P. Yu. Dy- have been applied and evaluated. The worked namic load balancing on web-server systems. out HTCPNs structures become the integrated IEEE Internet Computing, Volume 3(3):28–39, modules of the HTCPNs based software tool May/June 1999. presented in the first part of the paper. [6] J. Guo and L. Bhuyan. Load balancing in a Currently, the software tool described in the cluster-based web server for multimedia applications. IEEE Transactions on Parallel and paper can be applied for a limited web–server Distributed Systems, Volume 17(11):1321–1334, cluster structures modelling and validation. 2006. Thereafter the main stream of author’s future [7] K. Jensen. Coloured Petri Nets, Basic Con- research will concentrate on developing next cepts, Analysis Methods and Practical Use, vol- web–server node structures models. This may ume I-III. Springer, 1996. result in following advantages. First, an open [8] K. Jensen, L. Kristensen, and L. Wells. library of already proposed web–server clus- Coloured Petri Nets and CPN tools for modelling and validation of concurrent sys- ter structures could be created and applied by tems. International Journal on Software the future web–server developers. Second, some Tools for Technology Transfer (STTT), Volume new solutions for distributed web–server sys- 9(3-4):213–254, 2007. tems may be proposed and validated. [9] Y. Ji and I. S. Ko. A design of the simulator for web-based load balancing. Springer LNCS, References Volume 4496/2007:884–891, July 2007. [10] L. Kencl and J.-Y. L. Boudec. Adaptive load [1] F. Bause. Queueing Petri Nets – a formalism sharing for network processors. In Twenty-First for the combined qualititative and quantitative Annual Joint Conference of the IEEE Com- analysis of systems. In PNPM’93, pages 14–23. puter and Communications Societies. Proceed- IEEE, IEEE Press, 1993. ings, pages 545–554. IEEE, 2002. [2] H. Bryhni, E. Klovning, and O. Kure. A [11] D. Kim, S. Lee, S. Han, and A. Abraham. Im- comparison of load balancing techniques for proving web services performance using priority scalable web servers. IEEE Network, Volume allocation method. In Proc. Of International 14(4):58–64, Jul./Aug. 2000. Conference on Next Generation Web Services [3] J. Cao, M. Andersson, C. Nyberg, and M. Khil. Practices, pages 201–206. IEEE, 2005. Web server performance modeling using an 152 Slawomir Samolej, Tomasz Szmuc

[12] S. Konunev. Performance modelling and eval- [24] S. Samolej and T. Rak. Timing properties of in- uation of distributed component–based sys- ternet systems modelling using Coloured Petri tems using Queuing Petri Nets. IEEE Nets. In Systemy czasu rzeczywistego – Kierunki Transactions on Software Engineering, Volume badań i rozwoju, pages 91–100. Wydawnictwa 32(7):486–502, 2006. Komunikacji i Łączności, 2005. In Polish. [13] S. Kounev and A. Buchmann. SimQPN–a [25] S. Samolej and T. Szmuc. TCPN–based tool for tool and methodology for analyzing Queueing timing constraints modelling and validation. In Petri Net models by means of simulation. Per- Software Engineering: Evolution and Emerging formance Evaluation, Volume 36(4–5):364–394, Technologies, Volume 130 Frontiers in Artificial 2006. Intelligence and Applications, pages 194–205. [14] M. Kristensen, S. Christensen, and K. Jensen. IOS Press, 2005. The practitioner’s guide to coloured Petri Nets. [26] S. Samolej and T. Szmuc. Time constraints International Journal on Software Tools for modeling and verification using Timed Colored Technology Transfer (STTT), Volume 2:98–132, Petri Nets. In Real–Time Programming 2004, 1998. pages 127–132. Elsevier, 2005. [15] T. T. Kwan, R. E. McGrath, and D. A. Reed. [27] S. Samolej and T. Szmuc. Dedicated inter- Ncsa’s world wide web server: Design and per- net systems design using Timed Coloured Petri formance. Computer, Volume 28(11):68–74, Nets. In Systemy czasu rzeczywistego – Metody Nov. 1995. i zastosowania, pages 87–96. Wydawnictwa Ko- [16] B. Linstrom and L. Wells. Design/CPN Per- munikacji i Łączności, 2007. In Polish. formance Tool Manual. CPN Group, Univ. of [28] M. Satyanarayanan. Scalable, secure, and Aarhus, Denmark, 1999. highly available distributed file access. Com- [17] Linux virtual server project. http://www. puter, Volume 23(5):9–18, 20–21, May 1990. linuxvirtualserver.org/. [29] T. Schroeder, S. Goddard, and B. Ramamurthy. [18] X. Liu, L. Sha, Y. Diao, S. Froehlich, J. L. Scalable web server clustering technologies. Hellerstein, and S. Parekh. Online response IEEE Network, Volume 14(4):38–45, May/June time optimization of Apache web server. In 2000. IWQoS 2003: 11th International Workshop, [30] Z. Shan, C. Lin, D. Marinecu, and Y. Yang. pages 461–478. Springer, 2003. LNCS. Modelling and performance analysis of [19] X. Liu, R. Zheng, J. Heo, Q. Wang, and L. Sha. QoS–aware load balancing of web–server clus- Timing performance control in web server sys- ters. Computer Networks, Volume 40:235–256, tems utilizing server internal state information. 2002. In Proc. of the Joint Internat. Conf. on Auto- [31] B. A. Shirazi, A. R. Hurson, and K. M. Kavi. nomic and Autonomous Systems and Interna- Scheduling and Load Balancing in Parallel and tional Conference on Networking and Services, Distributed Systems. Wiley-IEEE Computer So- page 75. IEEE, 2005. ciety Press, April 1995. [20] loadbalancers.org. http://loadbalancer.org/. [32] F. Spies. Modeling of optimal load balancing [21] Meta Software Corporation. Design/CPN Ref- strategy using queueing theory. Microprocessing erence Manual for X-Windows, 1993. and Microprogramming, Volume 41:555–570, [22] G. Park, B. Gu, J. Heo, S. Yi, J. Han, J. Park, 1996. H. Min, X. Piao, Y. Cho, C. W. Park, H. J. [33] Thomas-kern load balancers. http://www. Chung, B. Lee, and S. Lee. Adaptive load bal- thomas-krenn.com. ancing mechanism for server cluster. Springer [34] B. Urgaonkar, G. Pacifici, P. Shenoy, M. Spre- LNCS, Volume 3983/2006:549–557, May 2006. itzer, and A. Tantawi. Analytic modeling of [23] T. Rak and S. Samolej. Distributed internet multitier Internet applications. ACM Transac- systems modeling using tcpns. In Proc. of Inter- tions on the Web, Volume 1(2), 2007. national Multiconference on Computer Science [35] L. Wells. Performance analysis using CPN tools. and Information Technology, pages 559–566. In Proc. of the 1st Inter. Conf. on Performance IEEE, 2008. Web–Server Systems HTCPNs-Based Development Tool Application in Load Balance Modelling 153

Evaluation Methodolgies and Tools, 2006. Arti- on Parallel and Distributed Systems, Volume cle No. 59. 16(3):219–233, March 2005. [36] L. Wells, S. Christensen, L. Kristensen, and [38] W. Zhang. Linux virtual server for scalable net- K. Mortensen. Simulation based performance work services. In Ottava Linux Symposioum. analysis of web servers. In Proc. of the 9th Inter- Proceedings, 2000. nat. Workshop on Petri Nets and Perf. Models, [39] Z. Zhang and W. Fan. Web server load balanc- page 59. IEEE, 2001. ing: A queueing analysis. European Journal of [37] Q. Zhang, A. Riska, W. Sun, E. Smirni, and Operational Research, Volume 186(2):681–693, G. Ciardo. Workload-aware load balancing April 2008. for clustered web servers. IEEE Transactions