[email protected] · 2016. 5. 16. · e-Informatica Software Engineering Journal, Volume 3,...

Editors

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

Wrocław University of TechnologyInstitute of Applied InformaticsWrocław University of Technology, 50-370 Wrocław, Poland

e-Informatica Software Engineering Journalhttp://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, orothervise, without the prior written permission of the publishers.

Printed in the camera ready form

c© Copyright by Oficyna Wydawnicza Politechniki Wrocławskiej, Wrocław 2009

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

ISSN 1897-7979

Drukarnia Oficyny Wydawniczej Politechniki Wrocławskiej. Order No. 757/2009 .

Editorial BoardEditor-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

EditorialZbigniew Huzar, Lech Madeyski . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Regular PaperA Component Model with Support of Mobile Architectures and Formal Description

Marek Rychlý . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Special Issue Papers

Bi-dimensional Composition with Domain Specific LanguagesAnca Daniela Ionita, Jacky Estublier, Thomas Leveque, Tam Nguyen . . . . . . . 27

Aspect-Oriented Change Realizations and Their InteractionValentino Vranić, Radoslav Menkyna, Michal Bebjak, Peter Dolog . . . . . . . . 43

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

Oksana Nikiforova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Automated Code Generation from System Requirements in Natural Language

Jan Franců, Petr Hnětynka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Tool Based Support of the Pattern Instance Creation

Ľubomír Majtás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Transformational Design of Business Processes in BPEL Language

Andrzej Ratkowski, Andrzej Zalewski, Bartłomiej Piech . . . . . . . . . . . . . . 103Satisfying Stakeholders’ Needs – Balancing Agile and Formal Usability Test Results

Jeff Winter, Kari Rönkkö . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Web–Server Systems HTCPNs-Based Development Tool Application in Load BalanceModelling

Slawomir Samolej, Tomasz Szmuc . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Editorial

It is a pleasure to present to our readersthe third issue of the e-Informatica SoftwareEngineering Journal (ISEJ).

The mission of the e-Informatica SoftwareEngineering Journal is to be a prime interna-tional journal to publish research findings andIT industry experiences related to theory, prac-tice and experimentation in software engineer-ing. The scope of the journal includes method-ologies, practices, architectures, technologiesand tools used in processes along the softwaredevelopment lifecycle, but particular interest isin empirical evaluation.

The third issue of the journal includes ninepapers. Eight of the papers are extendedversions of the best papers presented at theCEE-SET’2008 conference (IFIP Central andEastern European Conference on Software En-gineering Techniques) carefully selected by theeditors, while the ninth is a regular paper.

The first of the papers by Ionita et al.presents how domain modelling may leveragethe hierarchical composition, supporting two or-thogonal mechanisms for composing completelyautonomous parts. The vertical mechanism isin charge of coordinating heterogeneous compo-nents, tools or services at a high level of abstrac-tion, by hiding the technical details. The resultof such a composition is called “domain” and ischaracterised by a Domain Specific Language(DSL). The horizontal mechanism composes do-mains at the level of their DSLs, even if theyhave been independently designed and imple-

mented. The second paper by Vrani et al. de-scribes the approach to aspect-oriented changerealization based on a two-level change typemodel in the web application domain. The thirdpaper by Nikiforova proposes two hemispheremodel driven approach for generation of UMLclass diagram. The fourth paper by Franců andHnětynka presents an approach that allows au-tomated generation of executable code directlyfrom the use cases written in a natural lan-guage. The fifth paper by Majtás presents toolbased support of the pattern instance creationon the model level in a semi automatic way. Thesixth paper by Ratkowski et al. demonstratesa transformational approach to the design ofexecutable processes in Business Process Execu-tion Language (BPEL). The seventh paper byWinter and Rönkkö is about balancing agile andformal usability test results. The eight paper bySamolej and Szmuc focuses on a new softwaretool for web-server systems development. Thetool consist of a set of predefined HierarchicalTimed Coloured Petri Net (HTCPN) structures– patterns. The last paper by Rychlý is a regularone and presents the component model that ad-dresses component mobility including dynamicreconfiguration, allows to combine control andfunctional interfaces, and separates a compo-nent’s specification from its implementation.

We look forward to receiving quality contri-butions from researchers and practitioners insoftware engineering for the next issue of thejournal.

EditorsZbigniew HuzarLech Madeyski

e-Informatica Software Engineering Journal, Volume 3, Issue 1, 2009

A Component Model with Support of Mobile

Architectures and Formal Description

Marek Rychlý∗∗Department of Information Systems, Faculty of Information Technology,

Brno University of Technology, Božetěchova 2, 612 66 Brno, Czech [email protected]

AbstractCommon features of current information systems have significant impact on software architecturesof these systems. The systems can not be realised as monoliths, formal specification of behaviourand 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 compo-nents and to move the copies across a network (component mobility), creation, destruction andupdating of components and connections during the systems’ run-time (dynamic reconfiguration),maintaining components’ compatibility, etc. In this paper, we present the component model thataddresses component mobility including dynamic reconfiguration, allows to combine control andfunctional interfaces, and separates a component’s specification from its implementation. We focuson the formal basis of the component model in detail. We also review the related research on thecurrent theory and practice of formal component-based development of software systems.

1. Introduction

Increasing globalisation of information societyand its progression create needs for extensiveand reliable information technology solutions.Common requirements for current informationsystems include adaptability to variable struc-ture of organisations, support of distributedactivities, integration of well-established (thirdparty) software products, connection to a vari-able set of external systems, etc. Those fea-tures have significant impact on software archi-tectures of the systems. The systems can notbe realised as monoliths, exact specification offunctions and interfaces of the systems’ partsare necessary, as well as specification of theircommunication and deployment. Therefore, theinformation systems of organisations are realisedas networks of quite autonomous, but cooper-ative, units communicating asynchronously viamessages of appropriate format [7]. Unfortu-

nately, design and implementation of those sys-tems have to deal with many problems includingthe ability to clone components and to move thecopies across a network (i.e. component mobil-ity), creation, destruction and updating of com-ponents and connections during the systems’run-time (i.e. dynamic reconfiguration), main-taining components’ compatibility, etc. [6]

Moreover, distributed information systemsare getting involved. Their architectures areevolving during a run-time and formal spec-ifications are necessary, particularly in criti-cal applications. Design of the systems withdynamic architectures (i.e. architectures withdynamic reconfigurations) and mobile archi-tectures (i.e. dynamic architectures with com-ponent mobility) can not be done by meansof conventional software design methods. Inmost cases, these methods are able to describesemi-formally only sequential processing or sim-ple concurrent processing bounded to one com-

10 Marek Rychlý

ponent without advanced features such as dy-namic reconfiguration.

The component-based development (CBD,see [17]) is a software development methodol-ogy, which is strongly oriented to composabilityand re-usability in a software system’s architec-ture. In the CBD, from a structural point ofview, a software system is composed of com-ponents, which are self contained entities ac-cessible through well-defined interfaces. A con-nection of compatible interfaces of cooperatingcomponents is realised via their bindings (con-nectors). Actual organisation of interconnectedcomponents is called configuration. Componentmodels are specific meta-models of software ar-chitectures supporting the CBD, which definesyntax, semantics and composition of compo-nents.

Although the CBD can be the right way tocope with the problems of the distributed in-formation systems, it has some limitations informal description, which restrict the full sup-port for the mobile architectures. Those restric-tions can be delimited by usage of formal basesthat do not consider dynamic reconfigurationsand component mobility, strict isolation of con-trol and business logic of components that doesnot allow full integration of dynamic reconfigu-rations into the components, etc.

This paper proposes a high-level componentmodel addressing the mentioned issues. Themodel allows dynamic reconfigurations and com-ponent mobility, defined combination of controland business logic of components, and sepa-ration of a component’s specification from itsimplementation. The paper also introduces aformal basis for description of the componentmodel’s semantics, i.e. the structure and be-haviour of the components.

The remainder of this paper is organised asfollows. In Section 2, we introduce the compo-nent model in more detail. In Section 3, we pro-vide the formal basis for description of the com-ponent model. In Section 5, we review main ap-proaches that are relevant to our subject. In Sec-

tion 6, we discuss advantages and disadvantagesof our component model and its formal descrip-tion compared with the reviewed approachesand outline the future work. To conclude, in Sec-tion 7, we summarise our approach and currentresults.

2. Component Model

In this section, we describe our approach to thecomponent model. The component model is pre-sented in two views: structural and behavioural.At first, in Section 2.1, we introduce the compo-nent model’s meta-model, which describes basicentities of the component model and their rela-tions and properties. The second view, in Sec-tion 2.2, is focused on behaviour of the compo-nent model’s entities, especially on the compo-nent mobility.

2.1. Meta-model

The Figure 1 describes an outline of the compo-nent model’s meta-model1 in the UML notation[20]. Three basic entities represent the core enti-ties of a component based architecture: a compo-nent, an interface and a binding (a connector).

The component is an active communicat-ing entity in a component based software sys-tem. In our approach, the component con-sists of component abstraction and compo-nent implementation. The component abstrac-tion (CompAbstraction in the meta-model) rep-resents the component’s specification and be-haviour given by the component’s formal de-scription (semantics of services provided bythe component). The component implementa-tion (CompImplementation) represents a specificimplementation of the component’s behaviour(an implementation of the services). The imple-mentation can be primitive or composite. Theprimitive implementation (CompImplPrimitive)is realised directly, beyond the scope of archi-tecture description (it is “a black-box”). The

1 The figured diagram can not describe additional constraints, e.g. a composite component “contains” bindingsthat 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

accessible via

to

contains

from

impl. by

consists ofis of

is of

input

is of

outputprovides

ref.

ref.

InterfaceCompAbstraction

ReqInterface

CompImplComposite

CompImplementation

Binding

CompImplPrimitive

TypeOfBinding

NamedEntityname : string

TypeOfInterface

IntCtrlTypeEnum

start : voidstop : voidclone : voidattach : voiddetach : voidgetFuncInterf : voidbindFuncInterf : void

ProvInterface

ICProxyInward

ToIReference

ToIRefComp ToIRefInt

ToIControltype : IntCtrlTypeEnum

TypeOfValue

ToIFuncParamIntCompProxy ICProxyOutward

ToIFunctional

bindings*

output1

interfacescomponent

*1

input1..*

implementation1*

subcomponents*

type1*

type1

*

inParams

*

type1

*

outParams1..*proxies*

inner1 inner1outer

1outer1

component

1

*interface

1

*

Figure 1. The meta-model of the component model (the UML notation [20])

composite implementation (CompImplComposite)is decomposable on a system of subcompo-nents at the lower level of architecture de-scription (it is “a grey-box”). Those subcom-ponents are represented by component ab-stractions (CompAbstraction and relation “con-sists of”).

Interfaces of a component are described inrelation to the component’s abstraction (re-lation “accessible via” from CompAbstraction).We distinguish two types of interfaces: re-quired and provided (ReqInterface and Prov-Interface, respectively), according to the typeof services required or provided by the com-ponent from or to its neighbouring compo-nents, respectively, at the same level of hi-erarchy of components (i.e. not from or tosubcomponents of a neighbouring component,for example). Moreover, the composite com-ponents’ implementations (CompImplComposite)provide special internal interfaces, which areavailable only for the component’s subcom-ponents and make accessible the component’sexternal interfaces (i.e. the interfaces de-scribed in relation to CompAbstraction). The en-tity ICProxyInward connects a composite com-ponent’s external provided interface to thecomponent’s internal required interface, whilethe entity ICProxyOutward connects a com-posite component’s internal provided interfaceto the component’s external required inter-

face (the relations “outer” and “inner” andvice versa).

According to the functionality of inter-faces, we can distinguish functional, con-trol and reference interfaces (described byTypeOfInterface). The functional interfaces(ToIFunct-ional) represent business orientedservices with typed input and output parame-ters (ToIFuncParam and TypeOfValue). The con-trol interfaces (ToIControl and its attribute’stype) provide services for obtaining referencesto a component’s provided functional interfaces(type getFuncInterfaces), for binding a compo-nent’s required functional interfaces (type bind-FuncInterface), and for changes of behaviour(types start and stop) and architecture. Theservices for changes of architecture are clone,attach and detach for obtaining references to afresh copy of a component (type “cloning”), at-taching of a new component as a subcomponentand detaching of an old subcomponent, respec-tively. The reference interfaces (ToIReference)are able to transmit references to componentsor interfaces, which is required to support com-ponent mobility.

Finally, the binding describes connection ofrequired and provided interfaces of the identi-cal types and of components at the same levelof the hierarchy into a reliable communicationlink (entity Binding). The type of a binding(TypeOfBinding) can specify a communication

12 Marek Rychlý

style (buffered and unbuffered connection), atype of synchronisation (blocking and outputnon-blocking), etc.

2.2. Behaviour and Support ofMobile Architectures

The previous section introduces the structureof the component model. A system describedby means of the component model is one com-ponent with provided and required interfaces,which represent the system’s input and outputactions, respectively. The component can be im-plemented as a primitive component or as a com-posite component. The primitive component isrealised directly, beyond the scope of architec-ture description, while the composite componentis decomposable at the lower level of hierarchyinto a system of subcomponents communicatingvia their interfaces and their bindings.

Behaviour of a primitive component has tobe defined by a developer, simultaneously withdefinitions of the component’s interfaces. Theprimitive component is defined as “a black-box”,i.e. its behaviour can be described as a de-pendence relation of input and output actions.Behaviour of a composite component dependson behaviour of its subcomponents, but it in-cludes also a description of communication be-tween connected interfaces of those subcompo-nents and processing of specific control actionsin the component (e.g. requests for starting orstopping of the component and their distribu-tion to the component’s subcomponents, etc.).

In the following description, we focus on thebehaviour of control parts of components par-ticularly related to the features of mobile ar-chitectures, i.e. on creation and destruction ofcomponents and connections and on passing ofcomponents. Evolution of a system’s architec-ture begins in the state where its initialisationis finished.

A new component can be created as a copy ofan existing component by means of its controlinterface clone. The resulting new componentis deactivated (i.e. stopped) and packed into amessage, which can be sent via outgoing con-nections into different location (via interfaces of

type ToIRefComp) where it can be placed as asubcomponent of a parent component (by meansof attach interface), connected to local neigh-bouring components (by means of bindFunc-Interf and getFuncInterf interfaces) and acti-vated (by means of start interface). Destructionof an old component can be done automaticallyafter deactivating of the component (by meansof stop interface), releasing of all its provided in-terfaces and disconnecting from its parent com-ponent (by means of detach interface).

Creation of new connections between twocompatible functional interfaces can be done bymeans of passing of functional interfaces (via in-terfaces of type ToIRefInt). At first, a referenceto provided functional interface (a target inter-face) is obtained from a component (via controlinterface getFuncInterf). This reference is sentvia outgoing connections into different location(via interfaces of type ToIRefInt), but only inthe same parent component and at the samelevel of hierarchy of components (i.e. crossingthe boundary of a composite component is notallowed). The reference is received by a compo-nent with compatible required functional inter-face (a source interface) and a binding of thisinterface to referenced interface is created (bymeans of control interface bindFuncInterf). De-struction of a connection can be done by rebind-ing of a required interface participating in thisconnection.

As it follows from the description of be-haviour, the connections can interconnect onlyinterfaces of the same types. Moreover, dynamiccreation of new connections and destruction ofexisting connection are permitted only for func-tional interfaces (type ToIFunctional). Those re-strictions, together with the restriction of pass-ing of interfaces’ references described in the pre-vious paragraph, prevent architectural erosionand architectural drift [11], which are causedby uncontrollable evolution of dynamic and mo-bile architecture resulting into degradation ofthe components’ dependencies over time. In thecomponent model, the architecture of control in-terfaces and their interconnections, which allowevolution and component mobility, is a static ar-chitecture.


Despite those restrictions, combining of ac-tions of functional interfaces with actions ofcontrol interfaces is permitted inside primi-tive components. This allows to build systemswhere functional (business) requirements implychanges of a systems’ architectures.

3. Formal Description

In this section, formal description of behaviourof the component model’s entities is presented.The Section 3.1 provides an introduction to theprocess algebra π-calculus, which is used in de-scription in Section 3.2. The description is basedon our previous research on distributed informa-tion systems as systems of asynchronous concur-rent processes [13] and the mobile architecture’sfeatures in such systems [15, 14].

3.1. The π-Calculus

The process algebra π-calculus, known also as acalculus of mobile processes [10], is an extensionof Robin Milner’s calculus of communicatingsystems (CCS). This section briefly summarisesthe fundamentals of the π-calculus, a theory ofmobile processes, according to [16]. The follow-ing theoretical background is required for thecomponent model’s formal description in Sec-tion 3.2. The π-calculus allows modelling of sys-tems with dynamic communication structures(i.e. mobile processes) by means of two concepts:

a process – an active communicating en-tity in a system, primitive or expressed inπ-calculus (denoted by uppercase letters inexpressions)2,a name – anything else, e.g. a communica-tion link (a port), variable, constant (data),etc. (denoted by lowercase letters in expres-sions)3.Processes use names (as communication

links) to interact, and pass names (as variables,constants, and communication links) to another

process by mentioning them in interactions. Thenames received by a process can be used andmentioned by it in further interactions (as com-munication links). This “passing of names” per-mits mobility of communication links.

Processes evolve by performing actions. Thecapabilities for action are expressed via threekinds of prefixes (“output”, “input” and “unob-servable”, as it is described later). We can definethe π-calculus processes, their subclass and theprefixes as follows.Definition 1 (π-calculus). The processes,the summations, and the prefixes of theπ-calculus are given respectively by

P ::= M | P | P ′ | (z)P | !PM ::= 0 | π.P | M + M ′π ::= x〈y〉 | x(z) | τ

We give a brief, informal account of seman-tics of π-calculus processes. At first, process 0 isa π-calculus process that can do nothing, it is thenull process or inaction. If processes P and P ′

are π-calculus processes, then following expres-sions are also π-calculus processes with formalsyntax according to the Definition 1 and giveninformal semantics:– x〈y〉.P is an output prefix that can send

name y via name x (i.e. via the communi-cation link x) and continue4 as process P ,

– x(z).P is an input prefix that can receive anyname via name x and continue as process Pwith the received name substituted for everyfree occurrence5 of name z in the process,

– τ.P is an unobservable prefix that can evolveinvisibly to process P , it can do an internal(silent) action and continue as process P ,

– P + P ′ is a sum of capabilities of P togetherwith capabilities of P ′ processes, it proceedsas either process P or process P ′, i.e. whena sum exercises one of its capabilities, theothers are rendered void,

– P | P ′ is a composition of processes P and P ′,which can proceed independently and can in-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 Rychlý

– (z)P is a restriction of the scope6 of name zin process P ,

– !P is a replication that means an infinitecomposition of processes P or, equivalently, aprocess satisfying the equation !P = P | !P .The π-calculus has two name-binding opera-

tors. The binding is defined as follows.Definition 2 (Binding). In each of x(z).Pand (z)P , the displayed occurrence of z is bind-ing with scope P . An occurrence of a name ina process is bound if it is, or it lies within thescope of, a binding occurrence of the name, oth-erwise the occurrence is free.

In our notations, we will omit a transmit-ted name, the second parts of input and out-put prefixes in a π-calculus expression, if it isnot used anywhere else in its scope (e.g. in-stead of (x)((y)x〈y〉.0 | x(z).0), we can write(x)(x.0 | x.0)).

Since the sum and composition operators areassociative and commutative (according to therelation of structural congruence [10]) they canbe used with multiple arguments, independentlyof their order. Also an order of application of therestriction operator is insignificant. We will usethe following notations:– for m ≥ 3, let ∏mi=1 Pi = P1 | P2 | . . . | Pm be

a multi-composition of processes P1, . . . , Pm,which can proceed independently and can in-teract via shared names,

– for n ≥ 2 and x̃ = (x1, . . . , xn), let(x1)(x2) . . . (xn)P = (x1, x2, . . . , xn)P =(x̃)P be a multi-restriction of the scope ofnames x1, . . . , xn to process P .We will omit the null process if the meaning

of the expression is unambiguous according tothe above-mentioned equations (e.g. instead ofx〈y〉.0 | x(z).0, we can write x〈y〉 | x(z)). More-over, the following equations are true for the nullprocess:

M + 0 = M P | 0 = P (x)0 = 0The π-calculus processes can be

parametrised. A parametrised process, an ab-straction, is an expression of the form (x).P .We may also regard abstractions as componentsof input-prefixed processes, viewing a(x).P as

an abstraction located at name a. In (x).P as ina(x).P , the displayed occurrence of x is bindingwith scope P .Definition 3 (Abstraction). An abstractionof arity n ≥ 0 is an expression of the form(x1, . . . , xn).P , where the xi are distinct. Forn = 1, the abstraction is a monoadic abstrac-tion, otherwise it is a polyadic abstraction.

When an abstraction (x).P is applied toan argument y it yields process P {y/x}. Ap-plication is the destructor of abstractions.We can define two types of application:pseudo-application and constant application.The pseudo-application is defined as follows.Definition 4 (Pseudo-application). If F def=(x̃).P is of arity n and ỹ is length n, thenP {ỹ/x̃} is an instance of F . We abbreviateP {ỹ/x̃} to F 〈ỹ〉. We refer to this instance op-eration as pseudo-application of an abstraction.

In contract to the pseudo-application that isonly abbreviation of a substitution, the constantapplication is a real syntactic construct. It al-lows to describe a recursively defined process.Definition 5 (Constant application). A re-cursive definition of a process constant K is anexpression of the form K ∆= (x̃).P , where x̃ con-tains all names that have a free occurrence inP . A constant application, sometimes referredas an instance of the process constant K, is aform of process Kbãc.

Communication between processes (a com-putation step) is formally defined as a reductionrelation → . It is the least relation closed undera set of reduction rules.Definition 6 (Reduction). The reduction re-lation, → , is defined by the following rules:R-Inter (x〈y〉.P1 + M1) | (x(z).P2 + M2) → P1 | P2{y/z}

R-Tau τ.P + M → P

R-ParP1 → P ′1

P1 | P2 → P ′1 | P2

R-Res P → P′

(z)P → (z)P ′

R-StructP1=P2 → P ′2=P ′1

P1 → P ′1

R-Const Kbãc → P{ã/x̃} K∆= (x̃).P

6 The scope of a restriction may change as a result of interaction between processes.


The communication is described by the mainreduction rule R-Inter. It means that a compo-sition of a process proceeding as either processM1 or the process, which sends name y via namex and continues as process P1, and a processproceeding as either process M2 or the process,which receives name z via name x and continuesas process P2, can perform a reduction step. Af-ter this reduction, the process is P1 | P2 {y/z}(all free occurrences of z in P2 are replaced by y).

3.2. Description of the ComponentModel

A software system can be described by meansof the component model as one component withprovided and required interfaces, which repre-sent the system’s input and output actions, re-spectively. According to the component model’sdefinition, every component can be implementedas a primitive component or as a composite com-ponent. Since a primitive component is realisedas “a black-box”, its behaviour has to be de-fined by its developer. This behaviour can beformally described as a π-calculus process, whichuses names representing the component’s inter-faces, but also implements specific control ac-tions provided by the component (e.g. requeststo start or stop the component). On the con-trary, a composite component is decomposableat the lower level of hierarchy into a system ofsubcomponents communicating via their inter-faces and their bindings (the component is “agrey-box”). Formal description of the compositecomponent’s behaviour is a π-calculus process,which is composition of processes representingbehaviour of the component’s subcomponents,processes implementing communication betweeninterconnected interfaces of the subcomponentsand internal interfaces of the component andprocesses realising specific control actions (e.g.the requests to start or stop the composite com-ponent, but including their distribution to thecomponent’s subcomponents, etc.).

Before we define π-calculus processes imple-menting the behaviour of a component’s indi-vidual parts, we need to define the component’sinterfaces within the terms of the π-calculus, i.e.

as names used by the processes. The followingnames can be used in external or internal viewof a component, i.e. for the component’s neigh-bours or the composite component’s subcompo-nents, respectively.– external: s0, s1, c, rs1, . . . , r

sn, p

g1, . . . , p

gm (of a

primitive or composite component),– internal: a, r′s1 , . . . , r′sm, p

′g1 , . . . , p

′gn (of a com-

posite component only),where n is a number of the component’s re-quired functional interfaces, m is a number ofthe component’s provided functional interfaces(both from the external view) and the nameshave the following semantics:

via s0 – a running component accepts a re-quest for its stopping, which a compositecomponent distributes also to all its subcom-ponents,via s1 – a stopped component accepts arequest for its starting, which a compositecomponent distributes also to all its subcom-ponents,via c – a component accepts a request for itscloning and returns a new stopped instanceof the component as a reply,via rsi – a component accepts a request forbinding given provided functional interface(included in the request) to the requiredfunctional interface ri,via pgj – a component accepts a request forreferencing to the provided functional inter-face pj that is returned as a reply,via a – a composite component accepts arequest for attaching its new subcomponent,i.e. for attaching the subcomponent’s s0 ands1 names (stop and start interfaces), whichcan be called when the composite componentwill be stopped or started, respectively, andas a reply, it returns a name accepting therequest to detach the subcomponent.We should remark that there is a relation-

ship between the names representing functionalinterfaces in the external view and the namesrepresenting corresponding functional interfacesin the internal view of the composite compo-nent. The composite component connects its ex-ternal functional interfaces r1, . . . , rn (required)and p1, . . . , pm (provided) accessible via names

16 Marek Rychlý

rs1, . . . , rsn and p

g1, . . . , p

gm, respectively, to internal functional interfaces p′1, . . . , p′n (provided) and

r′1, . . . , r′m (required) accessible via names p′g1 , . . . , p

′gn and r′s1 , . . . , r′sm, respectively. Requests received

via external functional provided interface pj are forwarded to the interface, which is bound tointernal functional required interface r′j (and analogously for interfaces p

′i and ri).

3.2.1. Interface’s References and Binding

At first, we define an auxiliary process Wire7, 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).

Wire∆= (x, y, d).(x(m).y〈m〉.Wirebx, y, dc + d)

Binding of a component’s functional interfaces is done via control interfaces. These controlinterfaces provide references to a component’s functional provided interfaces and allow to bind acomponent’s functional required interfaces to referenced fictional provided interfaces of anotherlocal components. Process CtrlIfs implementing the control interfaces can be defined as follows

SetIf∆= (r, s, d).s(p).(d.Wirebr, p, dc | SetIfbr, s, dc)

GetIfdef= (p, g).g(r).r〈p〉

Plugdef= (d).d

CtrlIfsdef= (r1, . . . , rn, rs1, . . . , r

sn, p1, . . . , pm, p

g1, . . . , p

gm)

.(n∏

i=1

(rdi )(Plug〈rdi 〉 | SetIfbri, rsi , rdi c) |m∏

j=1

!GetIf〈pj , pgj 〉)

where names r1, . . . , rn, rs1, . . . , rsn, p1, . . . , pm, p

g1, . . . , p

gm have been defined at the beginning of

Section 3.2. Let us assume CtrlIfs shares its names r1, . . . , rn and p1, . . . , pm with a process im-plementing a component’s core functionality via its required and provided interfaces, respectively.Pseudo-application GetIf〈pj , pgj 〉 enables process CtrlIfs to receive a name x via pgj and to send pjvia name x as a reply (it provides a reference to an interface represented by pj). Constant applicationSetIfbri, rsi , rdi c enables process CtrlIfs to receive a name x via rsi , which will be connected to riby means of a new instance of process Wire (it binds a required interface represented by ri to aprovided interface represented by x). To remove a former connection of ri, a request is sent via rdi(in case it is the first connection of ri, i.e. there is no former connection, the request is accepted bypseudo-application Plug〈rdi 〉).

In a composite component, the names representing external functional interfaces r1, . . . , rn,p1, . . . , pm are connected to the names representing internal functional interfaces p′1, . . . , p′n,r′1, . . . , r′m. Requests received via external functional provided interface pj are forwarded to theinterface, which is bound to internal functional required interface r′j (and analogously for interfacesp′i and ri). This is described in process CtrlEI .

CtrlEIdef= (r1, . . . , rn, p1, . . . , pm, r′1, . . . , r

′m, p

′1, . . . , p

′n)

.n∏

i=1

(d)Wirebri, p′i, dc |m∏

j=1

(d)Wirebr′j , pj , dc

7 The process will be used also in the following parts of Section 3.2.


3.2.2. Control of a Component’s Life-cycle

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

Dist∆= (p,m, r).(p〈m〉.Distbp,m, rc + r)

Life∆= (sx, sy, px, py).sx(m).(r)(Distbpx,m, rc | r.Lifebsy, sx, py, pxc)

Attachdef= (a, p0, p1).a(c0, c1, cd)(d)

(cd(m).d〈m〉.d〈m〉 | Wirebp0, c0, dc | Wirebp1, c1, dc)

CtrlSSdef= (s0, s1, a).(p0, p1)(Lifebs1, s0, p1, p0c | !Attach〈a, p0, p1〉)

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 subcomponentsvia names p0 and p1. Constant application Lifebs1, s0, p1, p0c enables process CtrlSS to receivea message m via s0 or s1. Message m is distributed to the subcomponents by means of constantapplication Distbpx,m, rc via shared name px, which can be p0 in case the component is running orp1 in case the component is stopped. When all subcomponents accepted message m, it is announcedvia name r and the component is running or stopped and ready to receive a new request to stopor start, respectively.

Pseudo-application Attach〈a, p0, p1〉 enables process CtrlSS to receive a message via a, a re-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 Wire. Thirdname received via a, cd, can be used later to detach the subcomponent’s previously attached stopand 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 canbe described as follows

Ctrlclone∆= (x).x(k).(s0, s1, c, rs1, . . . , r

sn, p

g1, . . . , p

gm, r, p)

(k〈s0, s1, c, r, p〉 | r〈rs1, . . . , rsn〉 | p〈pg1, . . . , pgm〉| Component〈s0, s1, c, rs1, . . . , rsn, pg1, . . . , pgm〉 | Ctrlclonebxc)

where pseudo-application Component〈s0, s1, c, rs1, . . . , rsn, pg1, . . . , pgm〉 with well-defined parametersdescribes behaviour of the cloned component. When process Ctrlclone receives a request k vianame 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 sendnames representing functional requested and provided interfaces of the new component, i.e. namesrs1, . . . , r

sn via name r names p

g1, . . . , p

gm 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 compos-ite component. The process of update, which describes the replacing of an old subcomponent witha 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 Rychlý

depends on particular configuration of the component (e.g. if the component allows updating of itssubcomponents, a context of the replaced subcomponent, which parts of the component have to bestopped during the updating, etc.). As an illustrative case, we can describe process Update as follows

Update∆= (u, a, s0, sd, rs1, . . . , r

sm, p

g1, . . . , p

gn)(k, s

′d)

.(u〈k〉.k(s′0, s′1, c, r′, p′).s0.a〈s′0, s′1, s′d〉.sd

.r′(r′s1 , . . . , r′sn ).(x)(p

g1〈x〉.x(p).r′s1 〈p〉 . . . pgn〈x〉.x(p).r′sn 〈p〉)

.p′(p′g1 , . . . , p′gm).(x)(p

′g1 〈x〉.x(p).rs1〈p〉 . . . p′gn 〈x〉.x(p).rsm〈p〉)

.s′1.Updatebu, a, s′0, s′d, rs1, . . . , rsm, pg1, . . . , pgnc)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 de-scribing behaviour of the new component, which will replace an old subcomponent in its parentcomponent implementing the update process. Name a provides the parent component’s internalcontrol interface to attach the new subcomponent’s stop and start interfaces (the s′0 and s′1 names)and an interface later used to detach the subcomponent (name s′d). Name s0 is used to stop thereplaced subcomponent and name sd is needed to detach the old subcomponent’s stop and startinterfaces. Finally, names rs1, . . . , r

sm, p

g1, . . . , p

gn 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’sassume that process abstraction Compimpl with parameters s0, s1, r1, . . . , rn, p1, . . . , pm describesbehaviour of the core of a primitive component (i.e. excluding processing of control actions), as it isdefined by the component’s developer. Further, let’s assume that process abstraction Compsubcompswith parameters a, r′s1 , . . . , r′sm, p

′g1 , . . . , p

′gn describes behaviour of a system of subcomponents in-

terconnected by means of their interfaces into a composite component (see Section 3.2.1). Namess0, s1, r1, . . . , rn, p1, . . . , pm and names a, rs1, . . . , r

sm, p

g1, . . . , p

gn are defined 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

Compprimdef= (s0, s1, c, rs1, . . . , r

sn, p

g1, . . . , p

gm)(r1, . . . , rn, p1, . . . , pm)

.(CtrlIfs〈r1, . . . , rn, rs1, . . . , rsn, p1, . . . , pm, pg1, . . . , pgm〉 | Ctrlclonebcc| Compimpl〈s0, s1, r1, . . . , rn, p1, . . . , pm〉)

Compcompdef= (s0, s1, c, rs1, . . . , r

sn, p

g1, . . . , p

gm)

.(a, r1, . . . , rn, p1, . . . , pm, r′1, . . . , r′m, p

′1, . . . , p

′n)

(CtrlIfs〈r1, . . . , rn, rs1, . . . , rsn, p1, . . . , pm, pg1, . . . , pgm〉| CtrlIfs〈r′1, . . . , r′m, r′s1 , . . . , r′sm, p′1, . . . , p′n, p′g1 , . . . , p′gn 〉| CtrlEI〈r1, . . . , rn, p1, . . . , pm, r′1, . . . , r′m, p′1, . . . , p′n〉 | Ctrlclonebcc| CtrlSS〈s0, s1, a〉 | Compsubcomps〈a, r′s1 , . . . , r′sm, p′g1 , . . . , p′gn 〉)

where processes CtrlIfs represent behaviour of control parts of components related to their inter-faces (see Section 3.2.1), processes Ctrlclone describe behaviour of a control part of componentsrelated to cloning of these components (see Section 3.2.3), process CtrlSS represents behaviour of


a component’s control part handling its stop and start requests (see Section 3.2.2), and processCtrlEI describes behaviour of communication between internal and external functional interfacesof 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 theuser’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 tothe system’s core. It enables the user to access the system’s core functionality and performs theaccess control according to the user’s authorisation. Finally, the session handle is passed back tothe 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 imple-ments simple shared memory – one storage for all users with two interfaces: for saving and loadinga value to and from the memory, respectively.

4.1. Definition of the Components’ Implementations

At first, we describe behaviour of cores of primitive components, i.e. the components’ implemen-tations, which have to be defined by developer of the system (see Section 3.2.4). Description ofbehaviour of the Core component’s implementation is:

Coreimpldef= (s0, s1, psave, pload)(val)Core′implbundef, psave, ploadc

Core′impl∆= (val, psave, pload)(psave(val′).Core′implbval′, psave, ploadc

+ pload(ret).(ret〈val〉 | Core′implbval, psave, ploadc)where process Coreimpl can save a message received via name psave and load the saved messageand send it as a reply on a request received via name pload.

Description of behaviour of the Session component’s implementation is the following:

Sessionimpldef= (s0, s1, rsave, rload, phandle)Session′impl〈rsave, rload, phandle〉

Session′impldef= (rsave, rload, phandle)(save, load)(phandle(ret)

.ret〈save, load〉.Session′implbrsave, rload, phandle, save, loadc)

Session′′impl∆= (rsave, rload, phandle, save, load)

(save(call).rsave〈call〉.Session′impl〈rsave, rload, phandle〉+ load(call).rload〈call〉.Session′impl〈rsave, rload, phandle〉)

20 Marek Rychlý

where process Sessionimpl can receive via name phandle an user’s request, which is specified subse-quently 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:

Loginimpl∆= (s0, s1, pinit, sysattach, sessionclone, coregsave, core

gload)

pinit(username, password, ret).(Loginverify〈username, password, ok, fail〉| Login′implbsysattach, sessionclone, coregsave, coregload, ret, ok, failc| Loginimplbs0, s1, pinit, sysattach, sessionclone, coregsave, coregloadc)

Login′impl∆= (sysattach, sessionclone, coregsave, core

gload, ret, ok, fail)(new, d

′, t)

(fail.ret〈error〉 + ok.sessionclone〈new〉.new(s′0, s′1, clone′, r′, p′).sysattach〈s′0, s′1, d′〉.r′(r′ssave, r′sload).p′(p′ghandle).coregsave〈t〉.t(save).r′ssave〈save〉.coregload〈t〉.t(load).r′sload〈load〉.p′ghandle(handle).(s

′1 | ret〈handle〉)

where process Loginimpl can receive an user’s initial request via name pinit as a triple of names(username, password, ret) and after successful verification of the user’s name and password, theprocess returns a new session’s handle via name ret. Name sysattach provides an interface to attachnew subcomponents into the system (see Section 3.2.2), name sessionclone is connected to a providedinterface for cloning of Session component (see Section 3.2.3), and names coregsave or core

gload are

connected to provided control interfaces for getting references to interfaces save or load of compo-nent Core (see Section 3.2.1), respectively. The definition contains pseudo-application of processabstraction Loginverify〈username, password, ok, fail〉, which represents description of behaviour

of user’s authentication process (e.g. Loginverifydef= (. . . ).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 asbehaviour and structure of a composite component, which represents the whole component basedsystem. According to Section 3.2.4, behaviour of components Core and Session can be describedas follows:

Coredef= (s0, s1, c, pgsave, p

gload).(psave, pload)

(CtrlIfs〈psave, pload, pgsave, pgload〉 | Ctrlclonebcc| Coreimpl〈s0, s1, psave, pload〉)

Sessiondef= (s0, s1, c, rssave, r

sload, p

ghandle).(rsave, rload, phandle)

(CtrlIfs〈rsave, rload, rssave, rsload, phandle, pghandle〉 | Ctrlclonebcc| Sessionimpl〈s0, s1, rsave, rload, phandle〉)

Behaviour of component Login has to be described differently from the others, because it usescontrol interfaces sysattach, sessionclone, core

gsave, core

gload, which can not be referenced (contrary

to functional interfaces, see Section 2.2). This case can be compared with the description of Update


process in Section 3.2.3. The behaviour of component Login can be described as follows:

Logindef= (s0, s1, c, p

ginit, sysattach, sessionclone, core

gsave, core

gload).(pinit)

(CtrlIfs〈pinit, pginit〉 | Ctrlclonebcc| Loginimplbs0, s1, pinit, sysattach, sessionclone, coregsave, coregloadc)

Finally, behaviour and structure of a composite component, which represents the whole com-ponent based system, can be described as follows:

Systemdef= (s0, s1, c, p

ginit)(a, pinit, r

′init, r

′sinit)

.(CtrlIfs〈pinit, pginit〉 | CtrlIfs〈r′init, r′sinit〉 | CtrlEI〈pinit, r′init〉| Ctrlclonebcc | CtrlSS〈s0, s1, a〉 | System′〈a, r′sinit〉)

System′ def= (sysattach, rsinit)(pginit, core

gsave, core

gload, sess

ssave, sess

sload, sess

ghandle, loginclone, coreclone)

(sessclone, slogin0 , s

login1 , d

login, score0 , score1 , d

core, ssess0 , ssess1 , d

sess)

(Login〈slogin0 , slogin1 , loginclone, pginit, sysattach, sessclone, coregsave, coregload〉| Core〈score0 , score1 , coreclone, coregsave, coregload〉| Session〈ssess0 , ssess1 , sessclone, sessssave, sesssload, sessghandle〉

| sysattach〈slogin0 , slogin1 , dlogin〉 | sysattach〈score0 , score1 , dcore〉

| sysattach〈ssess0 , ssess1 , dsess〉 | pginit〈t〉.t(init).rsinit〈init〉)

5. Related Work

There have been proposed several component models [8]. In this section, we focus on two contempo-rary 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 fordynamic 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 withempty content is called a primitive component. Every component can interact with its environmentvia operations at external interfaces of the component’s controller, while internal interfaces areaccessible 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 functionalitiesof a component, while a control interface is a server interface with operations for introspectionof the component and to control its configuration. There are two types of directed connectionsbetween compatible interfaces of components: primitive bindings between a pair of componentsand composite bindings, which can interconnect several components via a connector.

22 Marek Rychlý

Behaviour of Fractal components can be for-mally described by means of parametrised net-works of communicating automata language [2].Behaviour of each primitive component is mod-elled as a finite state parametrised labelled tran-sition system (pLTS) – a labelled transitionsystem with parametrised actions, a set of pa-rameters of the system and variables for eachstate. Behaviour of a composed Fractal compo-nent is defined using a parametrised synchroni-sation network (pNet). It is a pLTS computedas a product of subcomponents’ pLTSs and atransducer. The transducer is a pLTS, whichsynchronises actions of the corresponding LTSsof the subcomponents. When synchronisation ofthe actions occurs, the transducer changes itsstate, which means reconfiguration of the com-ponent’s architecture. Also behaviour of a Frac-tal component’s controller can be formally de-scribed by means of pLTS/pNet. The result iscomposition of pLTSs for binding and unbind-ing of each of the component’s functional inter-faces (one pLTS per one interface) and pLTS forstarting and stopping the component.

5.2. SOFA and SOFA 2.0

In the component model SOFA [12], a part ofSOFA project (SOFtware Appliances), a softwaresystem is described as a hierarchical compositionof primitive and composite components. A com-ponent is an instance of a template, which is de-scribed by its frame and architecture. The frameis a “black-box” specification view of the com-ponent defining its provided and required inter-faces. Primitive components are directly imple-mented by described software system – they havea primitive architecture. The architecture of acomposed component is a “grey-box” implemen-tation view, which defines first level of nestingin the component. It describes direct subcompo-nents and their interconnections via interfaces.The connections of the interfaces can be realisedvia connectors, implicitly for simple connectionsor explicitly. Explicit connectors are describedin a similar way as the components, by a frameand architecture. The connector frame is a set ofroles, i.e. interfaces, which are compatible with

interfaces of components. The connector archi-tecture can be simple (for primitive connectors),i.e. directly implemented by described softwaresystem, or compound (for composite connectors),which contains instances of other connectors andcomponents.

The SOFA uses a component definition lan-guage (CDL) [9] for specification of compo-nents and behaviour protocols (BPs) for formaldescription of their behaviours. The BPs [21]are regular-like expressions on the alphabet ofevent tokens representing emitting and acceptingmethod calls. Behaviour of a component (its in-terface, frame and architecture) can be describedby a BP (interface, frame and architecture proto-col, respectively) as the set of all traces of event to-kens generated by the BP. The architecture pro-tocols can be generated automatically from ar-chitecture description by a CDL compiler. A pro-tocol conformance relation ensures the architec-ture protocol generates only traces allowed by theframe protocol. From dynamic architectures, theSOFA allows only a dynamic update of compo-nents during a system’s runtime. The update con-sists in change of implementation (i.e. an archi-tecture) of the component by a new one. Compat-ibility of the implementations is guaranteed bythe conformance relation of a protocol of the newarchitecture and the component’s frame protocol.

Recently, the SOFA team is working ona new version of the component model. Thecomponent model SOFA 2.0 [5] aims at re-moving several limitations of the original ver-sion of SOFA – mainly the lack of supportof dynamic reconfigurations of an architecture,well-structured and extensible control parts ofcomponents, and multiple communication stylesamong components.

6. Discussion and Future Work

The component model proposed in this paper isable to handle mobile architectures, unlike theSOFA that supports only a subset of dynamicarchitectures (implementing the update opera-tion) or the Fractal/Fractive, which does notsupport components mobility. As is described in


Section 3.2, the π-calculus provides fitting for-malism for description of software systems basedupon the component model.

The proposed semantics of the componentmodel permits to combine control interfacesand functional interfaces inside individual prim-itive components where the control actions canbe invoked by the functional actions, i.e. bya system’s business logic represented by busi-ness oriented services. This allows to build sys-tems where functional (business) requirementsimply changes of the systems’ architectures. Re-gardless, in some cases, this feature can leadto architectural erosion and architectural drift[11], i.e. unpredictable evolution of the system’sarchitecture. For that reason, the componentmodel forbids dynamic changes of connectionsbetween control interfaces, which reduces archi-tecture variability to patterns predetermined ata design-time. Formal description of the com-ponents integrating the control and functionalactions can be compared with the transducer inthe Fractal/Fractive approach (see Section 5.1).

The next feature of the component model ispartially independence of a component’s spec-ification from its implementation (see the de-scription of entities CompAbstraction and Comp-Implementation in Section 2.1). This feature issimilar to the SOFA’s component-template re-lationship. It allows to control behaviour of aprimary component’s implementation, define acomposite component’s border that isolates itssubcomponents, which is called “a membrane”in the Fractal, etc. (for comparison, see Section5.1 and Section 5.2)

The attentive reader will have noticed thatthe process algebra π-calculus, as it is definedin Section 3.1 and applied to the formal de-scription of behaviour of the component model’sentities in Section 3.2, allows to describe onlysynchronous communication. Although, in mostcases, we need to apply the component model todistributed software systems with asynchronouscommunication. This limitation is a consequenceof the reduction relation’s definition (see Defini-tion 6 in Section 3.1). The problem can be solvedby proposing of a “buffered” version of commu-

nication between interfaces (i.e. in process Wirefrom Section 3.2.1) or, alternatively, by using ofan asynchronous π-calculus [16].

The next important extension of thepresented approach is application of typedπ-calculus [10, 16], which allows to distinguishtypes of names. This feature is necessary to for-mally describe constraints of the type systemof interfaces in behaviour of components. In thecomponent model’s metamodel, the type systemis defined by instances of entity TypOfInterfaceand its descendants and related entities (see Sec-tion 2.1).

However, the above mentioned modificationsare out of scope of this paper and a final ver-sion of the component model’s formal descrip-tion including the proposed extensions is partof current work. Further ongoing work is re-lated to the realisation of a supporting envi-ronment, which allows integration of the com-ponent model into software development pro-cesses, including integration of verification toolsand implementation support. The idea is to useresults of the ArchWare project [1], especiallyfor theorem-proving and model-checking9. Weintend to use the Eclipse Modeling Framework(EMF) [4, 19] for modeling and code generationof tools based on the component model and theEclipse Graphical Modeling Framework (GMF)[18] for developing graphical editors accordingto the rules described in the component model’smetamodel (based on EMF).

7. Conclusion

In this paper, we have presented an approach,which contributes to specify component-basedsoftware systems with features of dynamic andmobile architectures. The proposed componentmodel splits a software system into primitiveand composite components according to decom-posability of its parts, and the components’functional and control interfaces according tothe types of required or provided services. Thecomponents can be described at different levelsof abstraction, as their specifications and imple-mentations.

9 See the tools presented in documents D3.5b and D3.6c at [1].

24 Marek Rychlý

Semantics of the component model’s entitiesis formally described by means of the processalgebra π-calculus (known as a calculus of mo-bile processes). Formal description of behaviourof a whole system can be derived from the vis-ible behaviour of its primitive components andtheir compositions and communication, both de-fined at a design-time. The result is a π-calculusprocess, which describes the system’s architec-ture, including its evolution and component mo-bility, and communication behaviour of the sys-tem. Thereafter, critical properties of the systemcan be verified by means of π-calculus modelchecker.

We are currently working on extending ourapproach to use asynchronous communicationbetween components and a type system for theirinterfaces. Future work is related to integrationof the component model into software develop-ment processes, including application of veri-fication tools and implementation support. Inthe broader context, the research is a part ofa project focused on formal specifications andprototyping of distributed information systems.

Acknowledgements This research hasbeen supported by the Research Plan No. MSM0021630528 “Security-Oriented Research in In-formation Technology”.

References

[1] ArchWare project. http://www.arch-ware.org/,Nov. 2006.

[2] T. Barros. Formal specification and verificationof distributed component systems. PhD thesis,Université de Nice – INRIA Sophia Antipolis,Nov. 2005.

[3] E. Bruneton, T. Coupaye, and J.-B. Stefani.The Fractal component model. Draft of spec-ification, version 2.0-3, The ObjectWeb Consor-tium, Feb. 2004.

[4] F. Budinsky, D. Steinberg, E. Merks, R. Eller-sick, and T. J. Grose. Eclipse Modeling Frame-work. The Eclipse Series. Addison Wesley Pro-fessional, Aug. 2003.

[5] T. Bureš, P. Hnětynka, and F. Plášil. SOFA2.0: Balancing advanced features in a hierarchi-cal component model. In Proceedings of SERA2006, Seattle, USA, 2006. IEEE Computer So-ciety.

[6] J. Král and M. Žemlička. Autonomous compo-nents. In SOFSEM 2000: Theory and Practiceof Informatics, volume 1963 of Lecture Notes inComputer Science. Springer, 2000.

[7] J. Král and M. Žemlička. Software confedera-tions and alliances. In CAiSE Short Paper Pro-ceedings, volume 74 of CEUR Workshop Pro-ceedings, pages 229–232. CEUR-WS.org, 2003.

[8] K.-K. Lau and Z. Wang. A survey of softwarecomponent models (second edition). Pre-printCSPP-38, School of Computer Science, Univer-sity of Manchester, Manchester, UK, May 2006.

[9] V. Mencl. Component definition language. Mas-ter’s thesis, Charles University, Prague, 1998.

[10] R. Milner, J. Parrow, and D. Walker. A calculusof mobile processes, parts I and II. Journal ofInformation and Computation, 100:41–77, Sept.1992.

[11] D. E. Perry and A. L. Wolf. Foundations forthe study of software architecture. SIGSOFTSoftware Engineering Notes, 17(4):40–52, Oct.1992.

[12] F. Plášil, D. B́ılek, and R. Janeček.SOFA/DCUP: Architecture for componenttrading and dynamic updating. In 4th Interna-tional Conference on Configurable DistributedSystems, pages 43–51, Los Alamitos, CA, USA,May 1998. IEEE Computer Society.

[13] M. Rychlý. Towards verification of systemsof asynchronous concurrent processes. In Pro-ceedings of 9th International Conference Infor-mation Systems Implementation and Modelling(ISIM’ 06), pages 123–130. MARQ, Apr. 2006.

[14] M. Rychlý. Component model with support ofmobile architectures. In Information Systemsand Formal Models, pages 55–62. Faculty of Phi-losophy and Science in Opava, Silesian Univer-sity in Opava, Apr. 2007.

[15] M. Rychlý and J. Zendulka. Distributed in-formation system as a system of asynchronousconcurrent processes. In MEMICS 2006 SecondDoctoral Workshop on Mathematical and Engi-neering Methods in Computer Science. Facultyof Information Technology BUT, 2006.


[16] D. Sangiorgi and D. Walker. The π-Calculus:A Theory of Mobile Processes. CambridgeUniversity Press, First paperback edition,Oct. 2003.

[17] C. Szyperski. Component Software: BeyondObject-Oriented Programming. Addison WesleyProfessional, second edition, Nov. 2002.

[18] The Eclipse Foundation. Eclipse GraphicalModeling Framework (GMF). http://www.eclipse.org/gmf/, Sept. 2007.

[19] The Eclipse Foundation. Eclipse Model-ing Framework Project (EMF). http://www.eclipse.org/modeling/emf/, Sept. 2007.

[20] Unified Modeling Language, version 1.5. Doc-ument formal/03-03-01, Object ManagementGroup, 2003.

[21] S. Vǐsňovský. Modeling software componentsusing behavior protocols. PhD thesis, Dept. ofSoftware Engineering, Faculty of Mathematicsand Physics, Charles University, Prague, 2002.

e-Informatica Software Engineering Journal, Volume 3, Issue 1, 2009

Bi-dimensional Composition withDomain Specific Languages

Anca Daniela Ionita∗, Jacky Estublier∗∗, Thomas Leveque∗∗, Tam Nguyen∗∗∗University Politehnica of Bucharest, Automatic Control and Computers Faculty

∗∗LIG-IMAG, Grenoble, [email protected], [email protected], [email protected],

[email protected]

AbstractThe paper presents how domain modeling may leverage the hierarchical composition, supportingtwo orthogonal mechanisms (vertical and horizontal) for composing completely autonomous parts.The vertical mechanism is in charge of coordinating heterogeneous components, tools or servicesat a high level of abstraction, by hiding the technical details. The result of such a compositionis called “domain” and represents a high granularity unit of reuse, which may be easily devel-oped 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. Mostoften, 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 manydomains, raising the issue of domain (and DSL) composition. To overcome this problem, thehorizontal mechanism composes domains at the level of their DSLs, even if they have been in-dependently designed and implemented. The paper presents a model and metamodel perspectiveof the Mélusine bi-dimensional composition, assisted and automated with the Codèle tool, whichallows specification at a high level of abstraction, followed by Java and AspectJ code generation.

1. Introduction

In the widely adopted Component Based Soft-ware Engineering (CBSE) approach, compo-nents know each other, must have compatibleinterfaces and must comply with the constraintsof the same component model, which reducesthe likelihood of reusing components, and there-fore the capability to obtain a large variety ofassemblies. Therefore, alternative compositionmechanisms have to be explored, such as to pre-serve the CBSE advantages (coming from hidingthe internal structure and reusing componentswithout any change) but to relax the rigidity ofthe composition constraints:– The components or, generally speaking, the

parts, should ignore each other, such that

they could have been designed and developedindependently, i.e. they do not call each other;

– Composed parts should be of any nature (adhoc, legacy, COTS, local or distant);

– Parts should be allowed to be heterogeneousi.e. they do not need to follow a particularmodel (component model, service etc.);

– Parts should be reused without having to per-form any change in their code.The bi-dimensional composition mechanism

presented here is intended to be a solution forsuch situations. The idea is to obtain compos-able elements that are not traditional compo-nents, but much larger units, called domains,which do not expose simple interfaces, but do-main models, representing DSLs for specifyingthe application models.

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

One of the important problems to be solvedwas related to the heterogeneity of components,tools or services that have to be reused. A pos-sible solution was to imagine that the part tobe composed is wrapped into a “composable el-ement” [22]. There was also a need to definea composition mechanism that is not based onthe traditional method call, for composing partsthat ignore each other, and therefore do notcall each other. The publish/subscribe mecha-nism [2] was an interesting candidate, since thecomponent that sends events ignores who (ifany) is interested in that event, but the receiverknows and must declare what it is interested in.If other events, in other topics, are sent, the re-ceiver code has to be changed. Moreover, theapproach works fine only if the sender is an ac-tive component. A more appropriate solution forour requirements could be given by Aspect Ori-ented Software Development (AOSD) [18], [13],which eliminates some of the constraints above,since the sender (the main program) ignores anddoes not call the receiver (the aspects). Unfor-tunately, the aspect knows the internals of themain program, which defeats the encapsulationprinciple [8] and aspects are defined at a lowlevel of abstraction (the code) [12], [24].

In our approach, heterogeneity is dealt withby coordinating components, tools or servicesfrom a higher abstraction level; this is whatwe call vertical composition and is attained bydefining a domain DSL, which can natively spec-ify entities specific to the domain and nativelygrasp the semantics (behaviour) of these entitieswithin its interpreter; therefore, defining an ap-plication in the domain turns out to be the sim-ple definition of a model in the DSL language. Asusual, each domain is well instrumented with ed-itors, interpreters, debuggers, analyzers, whosedevelopment is rather expensive, even with thehelp of the recent environments. Maybe moreimportant, the practitioners acquire expertise inusing these languages and benefit from a largeset of existing models, which constitute a partof the company assets. Therefore, a large scalereuse of these domains is essential for the ap-plicability of such an approach and is promotedthrough rich DSL semantics. Unfortunately, the

richer the semantics embedded in the DSL, thesimpler the models, but the narrower the lan-guage scope. In this context, the main draw-back of DSLs comes out from the fact that mostreal life applications usually crosscut several do-mains, but they cannot be simply described byselecting a set of independent domain specificmodels, each one describing how the applicationbehaves inside each covered domain.

Consequently there is also a need to composedomains; this is what we call horizontal compo-sition and is not based on calling componentinterfaces, but on composing domain DSLs andmodels. In contrast to method call, model com-position does not impose that models stick tocommon interfaces, or know each other, becauseone can either merge or relate independent con-cepts. Moreover, model composition allows thedefinition of variability points [17], which makesthe mechanism more flexible than componentcomposition.

For building applications spanning differentdomains, the challenge is to reuse the domaintools, the existing models and the practitioner’sexpertise and know-how; this is far from trivialand is not possible if one creates a new languagefor the composite domain. As discussed above,for obtaining a non-invasive method, a possibil-ity is to adopt an implementation based on AOP(Aspect Oriented Programming); the composeddomains and their models are totally unchangedand the new code is isolated with the help ofaspects. However, since the AOP technique isat code level, performing domain compositionhas proved to be very difficult in practice; theconceptual complexity is increased, due to thenecessity to deal with many technical details.This problem has been treated in many researchworks. The elevation of crosscutting modelingconcerns to first-class constructs has been donein having [15], by generating weavers from do-main specific descriptions, using ECL, an exten-sion of OCL (Object Constraint Language). An-other weaver constructed with domain model-ing concepts is presented in [16], while [25] dis-cusses mappings from a design-level language,Theme/UML, to an implementation-level lan-guage, AspectJ. Our solution is to clearly sep-

Bi-dimensional Composition with Domain Specific Languages 29

arate the specification of the composition fromits implementation, by designing at a high con-ceptual level and then generating the code basedon aspects.

For managing the complexity in a userfriendly manner, the user defines the com-position using wizards, for selecting amongpre-defined properties. Designers and program-mers are assisted by the Mélusine engineeringenvironment for developing such autonomousdomains, for composing them and for creat-ing applications based on them [22]. For fa-cilitating an easier domain composition, bygenerating Java and AspectJ code, Mélusinewas leveraged by Codèle, a tool that guidesthe domain expert for performing the compo-sition at the conceptual level, as opposed tothe programming level.

Chapter 2 describes the architecture and theprinciples that stand behind the creation of do-mains driven by their DSLs and the compositionat a high level of abstraction. Chapter 3 presentsthe metamodels that allow code generation forvertical and horizontal composition. Chapter 4introduces some details related to the imple-mentation choices, including some mappings forcode generation. Chapter 5 compares the ap-proach with other related works and evaluatesits usefulness in respect with the domain com-positions performed before the availability of thecode generation facility offered by Codèle.

2. Bi-dimensional CompositionBased on DSLs

The alternative composition idea presentedabove is to create units of reuse that are au-tonomous (eliminating dependencies on the con-text of use) and composable at an abstractlevel (eliminating dependencies on the imple-mentation techniques and details). The solu-tion presented here combines two techniques(see Fig. 1): building autonomous domains usingvertical composition and abstract compositionof domains using horizontal composition, per-formed between the abstract concepts of inde-pendent domains, without modifying their code.

2.1. Developing Autonomous Domains:Vertical Composition

Developing a domain can be performed follow-ing a top-down or a bottom-up approach. Froma top down perspective, the required function-alities of the domain can be specified through amodel, irrespective of its underlying technology.Then, one identifies the software artifacts (avail-able or not) that will be used to implement theexpected functionality and make them interop-erate. From a bottom up perspective, the de-signer already knows the software artifacts thatmay be used for the implementation and willhave to interoperate; therefore, the designer hasto identify the abstract concepts shared by thesesoftware artifacts and how they are supposedto be consistently managed. Finally, one defineshow to coordinate the software artifacts, basedon the behavior of the shared concepts.

Figure 1. Bi-dimensional composition mechanism

In both cases, the composition is called verti-cal, because the real software components, ser-vices or tools are driven based on a high levelmodel of the application. The model elementsare instances of the shared concepts, which areabstractions of the actual software artifacts. Thesynchronization between these software artifactsand the model means that the evolution of themodel is transformed into actions performed bythe software artifacts.

The set of shared concepts and their con-sistency constraints constitute a domain model,to which the application model must conformto. In the Model Driven Engineering (MDE) vo-cabulary, the domain model is the metamodel,


or a DSL for all the application models for thatdomain [12].

The application models are interpreted by avirtual machine, built according to the domainDSL, which orchestrates the lower level servicesor tools. The domain interpreter is realized byJava classes that reify the shared concepts of thedomain model and whose methods implementthe behavior of these concepts. In many cases,these methods are empty, because most, if notall the behavior is actually delegated to othersoftware artifacts, with the help of aspect tech-nology. Thus, the domain interpreter, also calledthe domain virtual machine, separates the ab-stract and conceptual part from the implemen-tation, creating 3 layers architecture [12]. Thedomains may be autonomously executed, theydo not have dependencies and they may be eas-ily used for developing applications.

2.1.1. Domain Specific Languages in Mélusine

The domain specific languages defined in Mélu-sine are rather small, covering a narrow domainand 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 rulesnecessary to define a valid model, while its Se-mantic Domain (SD) is needed to provide themeaning of the abstract syntax concepts. Byconvention, the abstract syntax is defined bya class diagram, while the Semantic Domain isdefined based on the methods pertaining to theAS classes, plus some additional classes. The con-crete syntax (CS) is provided by a specific editor.

The Product domain, one of our intenselyreused domains, is presented in the case study ofthis paper. It was developed as a basic version-ing system for various products, characterisedby a map of attributes, according to their type;the versions are stored in a tree, consisting ofbranches and revisions. The Product domainDSL is shown in Fig. 2 and contains both ASelements (light colored) and SD elements (darkcolored).

From a Language Engineering point of view,this DSL is the definition of a language in which

models are written; from a Domain Modelingpoint of view, it is a model of the applicationdomain [12]. Thus, the DSL is the symbiosisof both views, since it is a language in whichmodels are written, but, being Domain Specific,it contains the domain specific concepts, theirallowed relationships and their behaviors. TheDSL captures both the abstract syntax and thesemantic aspects and it has different purposes:on one hand, it is used to develop models; on theother hand it is used to develop the interpreterand the editor of the domain and to compose do-mains for enlarging their scope. These activitiesinvolve an awareness of the concepts related tothe semantic domain, which is necessary, for in-stance, for developing the interpreters, but alsofor composing them, in order to be able to com-pose domains.

Figure 2. DSL of Product domain

2.1.2. Domain Specific Models

For defining an application, one creates a modelthat is going to be interpreted at run-time. Sup-pose we use our Product domain to version thesoftware artefacts produced when developing anapplication based on the J2EE architecture. AServlet in this application model conforms to theProductType concept from the Product DSL.

In practice, the models can be expressed inseveral formalisms, and represented in a varietyof ways; indeed, models may be defined in UML,or in Ecore, through generated editors (like in

Bi-dimensional Composition with Domain Specific Languages 31

most metamodeling environments), and storedin different formats, currently XML based. Wehave developed a number of filters, allowing oneto define models and metamodels in these dif-ferent formalisms, using different environmentsand editors. An example of editor for Productdomain is given in Fig. 3. However, since ourDSLs are written in Java, models always consistin a set of Java objects at execution. Models, ex-pressed in various formalisms, will be transpar-ently converted to Java objects at the beginningof interpretation phase. In most cases, when do-mains are narrow enough, the complete modelssemantics lies in the DSL. In this case, mod-els are purely structural, and simple editors likethose generated by EMF are sufficient. This isvery important, because it allows non program-mers to define executable models themselves. Ifmodels require specific semantics, it has to bedescribed in Java.

Figure 3. Model editor for Product domain

2.2. Abstract Domain Composition:Horizontal Composition

It may happen that the development of a newapplication requires the cooperation of two con-cepts, pertaining to two different domains, andrealized through two or more software compo-nents, services or tools. In this case, the interop-eration is performed through a horizontal com-position between these abstract concepts, andalso through the domain virtual machines, ig-noring the low level components, services andtools used for the implementation. The mech-anism consists in establishing relationships be-tween concepts of the two DSLs and implement-ing them using aspect technology, such as to

keep the composed domains unchanged. A verystrict definition of the horizontal relationshipproperties is necessary, such as to be able togenerate most of the AOP code for implement-ing them. This code belongs to the CompositionVirtual Machine and is separated from the vir-tual machines of the composed domains.

This composition is called horizontal, be-cause it is performed between parts situated atthe same level of abstraction. It can be seen asa grey box approach, taking into account thatthe only visible part of a domain is its DSL. Itis a non-invasive composition technique, becausethe components and adapters are hidden and arereused as they are. The composition result is anew domain model and therefore, a new domain,with its virtual machine, so that the process maybe iterated. As the domains are executable andthe composition is performed imperatively, itsresult is immediately executable, even if situatedat a high level of abstraction.

Model composition is actually performedby creating links between model elements (in-stances of the DSL classes) so by instantiat-ing the horizontal relationships defined at meta-model level. The choices of links ends may bemade either automatically or manually (interac-tive) with the help of the application designer.Interactive selection is often used, since conceptsof existing models may not match to each otherperfectly (they may have different names, butthe same meaning or have the same name, butbehaviors that partially overlap) and no rulecan be defined for it. However, it may be atedious process, especially for composing largemodels. In contrast, automatic selection can re-lieve model designer from this burden and isparticularly appreciated when models are verylarge. The default criterion for automatic selec-tion can be based on name matching.

2.2.1. Horizontal Composition at Metamodel,Model and Execution Levels

A real example of domain composition, realizedin our industrial applications, is illustrated inFig. 4. On the left, the Activity domain supportsworkflow execution, while on the right, the Prod-


uct domain is meant to store typed products andtheir attributes. Each domain has a DSL (see themetamodel level). The upper part shows the vis-ible concepts (the abstract syntax, in light grey)used for defining the models with appropriateeditors; the lower part (in dark grey) shows thehidden classes, introduced for implementing theinterpreters (the virtual machines) and for hold-ing the state of the models during the executionprocess.

Figure 4. Composition of Activityand Product domains

For each domain, a model is made by instanti-ating the concepts found in the light colored partof the domain DSL. At model level, on the left,Figure 4 shows an Activity model, conforming toitsDSL above. Thismodel describes a very simplesoftware development process, which only con-tains one activity – Programming; the box Pro-gramming is an instance of theActivityDefinitionconcept. Labels on the activity connectors, likespec or source are instances of the DataVariableconcept. These data variables correspond to in-stances of DataType: Specification and Program(not shown in this figure). Similarly, on the rightside of Figure 4, at model level, there is a Product

model, containing two instances of ProductType:JMLSpecification and JavaFile.

TheActivity model in this example is made ofa simple activity, in which a developer john re-ceives a software specification spec, realizes theactivity Programming and produces the sourcecode source. However, the developer john mayneed to work on various revisions of his specifi-cation or of his source, so the Activity domainneeds to be composed with the Product domain,for adding the versioning facility. These two do-mains (Activity andProduct) are related togetherby horizontal relationships at metamodel level,for example, a horizontal relationship is definedbetweenDataType and ProductType and anotherone 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 inthe Product model). Another link relates Pro-gram (the type of source) to the JavaFile prod-uct type. These two links conform to the relation-ships defined between theDataType andProduct-Type concepts. At execution level, a data fromthe Activity model, for example DATA_0097 isrelated to a revision from Product model, for ex-ampleVERSION-0050 (seeFig. 4). This link con-forms to the relationship between Data and Re-vision, situated at metamodel level.

Even if in the example above there wasa clear correspondence between Specificationfrom Activity model and JMLSpecification fromProduct Model, in p

Date post:	08-Feb-2021
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

[email protected] · 2016. 5. 16. · e-Informatica Software Engineering Journal, Volume 3,...

Documents