CORRECT MATCHING OF COMPONENTS

WITH EXTRA-FUNCTIONAL PROPERTIES

A Framework Applicable to a Variety of Component Models

Kamil Je

zek and P

remek Brada

Department of Computer Science and Engineering, University of West Bohemia, Univerzitni 8, 30614 Pilsen, Czech Republic

Keywords:

Software components, Extra-functional properties, Compatibility, Inter-component binding, Framework.

Abstract:

A lot of current approaches attempt to enrich software systems with extra-functional properties. These attempts

become remarkably important with the gradual adoption of component-based programming. Typically, extra-

functional properties need to be taken into account in the phase of component binding and therefore included

in the process of verifying component compatibility. Although a lot of research has been done, practical

usage of extra-functional properties is still rather scarce. The main problem could be in a slow adaptability of

specialized research models to rapidly changing industrial needs. We have designed a solution to this issue in

the form of a modular framework which provides a formally sound yet practical means to declare, assign and

evaluate extra-functional properties in the context of component-based applications. One of its strengths is

applicability to a variety of industrial as well as research component models. This paper describes the models

and algorithms of the framework and introduces a prototype implementation proving the concept.

1 INTRODUCTION

With today’s need for software systems, techniques

which help improve their production are becoming

more important. Both industry and the research com-

munity therefore invest considerable effort into im-

proving such approaches as component programming

or service oriented architecture. Despite noticeable

beneﬁts which they bring, new issues keep to arise.

One of the important ones is enriching components or

services with extra-functional properties (EFPs).

For instance, (1) qualitative properties such as

speed, response time, memory consumption or (2)

user requirements such as marketability, price, regu-

lar updates, technical support or (3) behavior proper-

ties such as synchronisation, concurrent access, dead-

lock free computation should be taken into account

once particular components are selected to compose a

ﬁnal software. Hence, EFPs provide developers with

strong means to assess the applicability and compati-

bility of components with the task and architecture at

hand.

There have been several attempts at providing EFP

support for software systems. They start from de-

scribing EFPs (Chung et al., 1999; ISO/IEC, 2001)

through they applicability to other systems to the de-

velopment of complex systems embedding as their

part either EFPs (Muskens et al., 2005; Bondarev

et al., 2006) or quality of service speciﬁcations (Yan

and Piao, 2009; Garc

ıa et al., 2007). Although these

research frameworks have already shown directions

leading to the successful implementation of EFPs,

their practical applications are still rare and industrial

component frameworks with no EFP support such as

Spring or OSGi are widely used.

In this paper we present a different approach to

this problem. Rather than creating a complex com-

ponent model which natively supports EFPs, we pro-

pose an independent framework which enables to en-

rich existing industrial systems with EFPs through a

set of extension points. The rationale is that even a

basic EFPs support is beneﬁcial for industrial com-

ponent frameworks. In addition, evolution of these

frameworks is then not limited to the adaptation of

EFPs.

1.1 Structure of the Paper

We ﬁrst introduce the proposed extra-functional

framework with its modules in Section 2. A brief in-

troduction of the concept is followed by formalisa-

tions of each part of the framework in Section 3. It

155

Ježek K. and Brada P..

CORRECT MATCHING OF COMPONENTS WITH EXTRA-FUNCTIONAL PROPERTIES - A Framework Applicable to a Variety of Component Models.

DOI: 10.5220/0003468401550166

In Proceedings of the 6th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE-2011), pages 155-166

ISBN: 978-989-8425-57-7

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

includes an algorithm of EFP evaluation and match-

ing. In Section 4 we provide some details on a pro-

totype implementation validating the introduced con-

cept and Section 5 presents examples of the appli-

cability of the approach to selected industrial frame-

works.

2 EXTRA-FUNCTIONAL

FRAMEWORK MODULES

The proposed framework aims to cover the typical

user roles and activities in component-based develop-

ment. A domain expert or architect ﬁrst designs the

extra-functional properties to be used across a range

of components and applications, then a developer

states the concrete properties of his components and

their values. Finally, when the component software

is being composed, an application assembler needs to

verify the compatibility of components which should

form the application. The framework proposed here

consequently allows to declare EFPs, store their deﬁ-

nitions and values in a repository, assign them to par-

ticular components and evaluate their compatibility.

The conceptual structure of the framework con-

sists of four modules as depicted in Figure 1. The

Repository stores EFP deﬁnitions and is accessed by

other modules to obtain, create or modify the proper-

ties. The EFP Assignment part uses the Repository

so it can attach the declared EFPs to each component.

Once components are enriched by EFPs the Evalua-

tor takes care of comparing attached EFPs when ver-

ifying component compatibility during their binding

process. While the Assignment works with separate

components, the Evaluator covers a set of components

which compose a ﬁnal component application.

All these modules are tied together by EFP Types

which deﬁnes the structure (type and values) of indi-

vidual extra-functional properties (Je

zek, 2010a).

What we aim at is a loosely coupled framework

which may be easily extended and applied to a wide

set of component models. The only assumption is that

the targeted component models recognize required

and provided counterpart elements used when creat-

ing inter-component bindings (Szyperski et al., 2002).

In the following subsections we respectively de-

scribe the details of the EFP Types, the Reposi-

tory, how the Assignment module achieves compo-

nent framework linking, and EFP evaluation.

2.1 Extra-functional Properties Types

The interchange of extra-functional properties be-

tween the modules of the framework requires a shared

Figure 1: Framework Overview.

understanding of EFP data. This is realized by the

module called EFP Types which is the implementa-

tion of the model of extra-functional properties pre-

sented in (Je

zek, 2010a) and formalized in (Jezek

et al., 2010). It deﬁnes individual EFPs, their struc-

ture and relations to a system of registries (Jezek et al.,

2010; Je

zek, 2010b).

Getting some inspiration in NoFun (Franch,

1998), we distinguish between simple and derived

extra-functional properties. The semantics is that a

derived property is based on a set of other (simple or

derived) properties and its value is assigned according

to a logical formula expressing the conditions when

the combinations of values of other properties is valid.

The form of the properties allows also to deﬁne

deloyment contracts (Lau and Ukis, 2006), which ex-

press relations between components and a runtime en-

vironment.

We formally deﬁne a collection of extra-

functional properties as a set

E = {e | e = (n, E

,γ,T,META)} (1)

where

n is the name of a property,

T ∈ T

types

= T

∪ T

is the type of a property,

is a set of simple (primitive) types. T

{real,integer, boolean,enum, set,ratio,string},

= {(T

,· ·· ,T

) | N > 1,T

∈ T

types

} is a set of

complex types containing non primitive values,

γ : T × T → Z; Z = integer ∪ {“n/d”} is a func-

tion which compares two instances x,y ∈ T of the

property with type T , stating which of the two val-

ues is better. The meaning of the return values is:

negative integer: x is worse than y, 0: x is equal

to y, positive integer: x is better than y, “n/d”:

not-deﬁned.

ENASE 2011 - 6th International Conference on Evaluation of Novel Software Approaches to Software Engineering

156

The function may not be explicitly deﬁned for

each type T and then the following implicit rules

hold: (i) real, integer, ratio use mappings -1: x <

y, 0: x = y, +1: x > y, (ii) string uses mappings 0:

x literally equal to y else “n/d”, (iii) boolean uses

mappings 0: x = y else “n/d”, (iv) set, enum and

complex use previous rules for each element and

the result is “n/d” unless each evaluation results

in the same value. When an explicit rule does not

exist and comparison can not be determined by

the implicit rule, the value “n/d” is returned.

⊂ E,e /∈ E

is an optional set containing other

properties composing this EFP,

META is a record containing any additional informa-

tion meaningful in the domain. Its elements are

described by an extensible model which currently

contains the items unit, names, where

unit : String is a measuring unit of the property,

names is an ordered enumeration containing ev-

ery name for the values of this property allowed

to be used in local registries from Section 2.2.

For instance, two simple properties are deﬁned as

follows:

(time_to_process, no-gamma, integer,

META {unit:‘‘ms’’,

names: {low, average, high}}

)

(data_transferred, no-gamma, integer,

META {unit:‘‘MB’’,

names: {low, average, high}}

)

A derived property deﬁnition then looks like this:

(performance,

{time_to_process, data_transferred},

no-gamma,

enum {sufficient, insufficient}, META {}

)

2.2 Universal EFP Repository

A stand-alone repository provides one commonly ac-

cessible place to store the EFPs. The reason for

this centralization is that in component development,

the components are typically developed and used by

world-wide organizations. If two vendors attach an

EFP with the same name to their components, the

same understanding of its structure and semantics is

needed (Je

zek, 2010b). This is the role of the repos-

itory and therefore other modules load data from this

common repository.

Since a given component or service can be run

in different environments, an EFPs mechanism must

take this heterogeneity into account. We therefore use

a layered design of the repository (Jezek et al., 2010).

The upper layer called Global Registry (GR) is a

storage of EFP deﬁnitions. It collects deﬁnitions of

EFP types from Section 2.1 and thus ensures all its

EFPs are valid and meaningful in a particular domain

(e.g. education, healthcare, automotive). Let us fur-

thermore highlight that Global Registry does not con-

tain concrete values of EFPs because they may differ

widely among runtime and application environments.

Formally, the Global Registry is a triple

GR = (id, name,E) (2)

where:

id : Integer is the registry’s unique identiﬁer,

name : String is a human readable name of this GR,

E is a set of extra-functional properties (Section 2.1).

The lower layer of the repository is called Local

Registry (LR). It stores EFP values pertinent to a par-

ticular computational environment, i.e. each environ-

ment has its own Local Registry with concrete values

of the properties deﬁned in the Global Registry.

Local Registry is formally deﬁned as

LR = (id, GR,name,id

parent

,S, D) (3)

where:

id : Integer is the registry’s unique identiﬁer,

GR is the Global Registry this LR is linked to,

name : String is a human readable repository name,

parent

: Integer is the (optional) identiﬁer of a parent

LR, which allows to build LRs in tree hierachies.

The semantic is that a value from a parent is in-

herited unless this LR overrides the value.

S = {(e,value

name,v) | e ∈ E ∧ value name ∈

String ∧ v ∈ V

} is a set deﬁning context depen-

dent values for simple properties,

D = {(e,value name,v, r) | e ∈ E ∧ value name ∈

String ∧ r ∈ R ∧ v ∈ V

} is a set of derived prop-

erty deﬁnitions, where each derived property e is

governed by a logical rule r for which

= {v

}

i∈I

set holds all values for the given

EFP assigned in this LR or its parents. I is the

set indexing values assigned in LR or its par-

ents,

v is an assigned value,

e is a property from GR,

value name is an assigned name of the value

which must be selected from the list of avail-

able names given in the META :: names part of

the deﬁnition of the property in GR.

CORRECT MATCHING OF COMPONENTS WITH EXTRA-FUNCTIONAL PROPERTIES - A Framework Applicable

to a Variety of Component Models

157

r ∈ R = E × LF ×V

is a set of derivation rules.

E is a set of EFPs, LF is a set of logical expres-

sions LF = { f (x) | f : String → Boolean}. A

value v is assigned to the EFP when the evalua-

tion of f is true.

One advantage of using a Local Registry is that it

holds context-dependent values with assigned names.

The names remain the same while concrete values dif-

fer, and a developer using the Local Registry mech-

anism may think of the semantics of the EFP value

as denoted by the name rather than about a concrete

number.

For example, a Local Registry for smartphones

with GPRS-only connection may contain the follow-

ing value deﬁnitions:

time_to_process: low = 10, high=5000, ...

data_transferred: low = 1, high=100, ...

whereas a LR for wiﬁ-connected tablets could deﬁne

time_to_process: low = 1, high=1000, ...

data_transferred: low = 10, high=500, ...

Another advantage of this solution is that conti-

nuous intervals of values can be partitioned into a

disjunctive set of named intervals, values or subsets.

Hence all values in one partition may be treated as

equivalent in the EFP evaluation process. For exam-

ple, memory consumption in an interval {1,+∞}GB

may be considered as too high for resource con-

strained devices. It does not matter whether the real

value is 1GB, 1.2GB or 5GB – they all belong to one

named group.

2.3 Applicability of EFPs to Variety of

Component Models

The assignment of EFPs to components actually con-

sists of two phases of EFPs manipulation. In the ﬁrst

phase a developer attaches EFPs to components, load-

ing the properties from the repository. In the second

phase the Assignment module provides the previously

attached EFPs to other systems (see Figure 2). The

form of transfered data are so called EFP Assignment

Types.

When designing the module, special care has been

taken not to depend on a concrete component model.

The EFP Assignment module solves the indepen-

dence using two separate sub-modules.

The EFP Mirror sub-module shown in Figure 2

represents the independent part of the EFP Assign-

ment module. In the phase of attaching EFPs to a

component, a developer loads EFPs from the remote

EFP repository and applies them to the component

(e.g. attaches a time to process property to a service

Figure 2: EFP Assignment Module.

interface). Since it would be impractical to call the

EFP repository every time the data are needed later

on, the EFP Assignment module stores complete in-

formation about the attached EFPs together with the

component.

The beneﬁt of this approach is that it creates a gen-

eral mechanism usable for all supported component

models. The detailed structure of EFP data is hidden

from (or at least irrelevant to) the “plain” component

framework and this sub-module provides an interface

transparently accessing EFPs in a component model

independent format. A small drawback is that consid-

erable amount of extra information may potentially

need to be stored together with the component in case

the EFPs are many or deeply structured.

The Data Storage Sub-module from Figure 2 pro-

vides an extension point where implementations for

supported component models are plugged.

This sub-module brings the desired ﬂexibility and

applicability for different component models in a

form of lightweight plug-ins. Obviously, components

look differently in different component models. For

that reason each implementation of this sub-module

decides (1) where and how to store EFP data, (2) how

to link the data with concrete features of the compo-

nent.

In Section 4 we describe an implementation of this

framework for the CoSi component model (Brada,

2008) together with technical details on the modules.

2.4 EFP Evaluation and Binding

The most innovative part of the framework is the

Evaluator. Its main purpose is to load a set of compo-

nents and verify their compatibility in terms of extra-

functional properties.

The module ﬁrst obtains EFPs of components call-

ing the EFP Assignment module for each component.

The received data are then composed to a graph repre-

senting components and their bindings, which serves

the evaluator to ﬁnd problems in component compati-

bility. Shortly, binding problems have forms of miss-

ing edges in the graph while EFP incompatibilities

ENASE 2011 - 6th International Conference on Evaluation of Novel Software Approaches to Software Engineering

158

show as mismatches on respective edges. Sections 3.1

and 3.2 provide more details.

Unlike other modules the Evaluator is not cus-

tomizable because it works on a generic model of

EFPs and component application architecture. The

variability of features and forms in component models

is addressed by the EFP Assignment module.

2.5 EFP Assignment Types

Since the evaluator aims at generality, data coming

in must cover a wide spectrum of component models.

For that reason EFP Assignment Types is a generic

representation of EFPs attached to components. It ag-

gregates EFP Types and the information about assign-

ments of EFP values to components. The correspond-

ing sub-module in the framework is able to serve this

data to its other parts; in particular, the Evaluator re-

ceives data from the Assignment module via EFP As-

signment Types.

The model used by EFP Assignment Types is for-

mally deﬁned as a set AT = F ×E ×V where F is a set

of all generic representations of component features:

F = { f | f = (name,type,role,mandatory,µ)} (4)

with the following meaning of the tuple elements:

name : String is the name of the feature.

role ∈ {“required“,“provided“} expressing if the

feature is put on the required or the provided side

of a component respectively.

mandatory : Boolean determines whether this fea-

ture must be bound to another feature in the

matching proccess.

type is the meta-type of the feature including a

name (for instance “interface”, “package”, “com-

ponent”), parameters (for instance inputs and out-

puts of methods). Very often, the type is extended

with a version of the feature where version =

...s

),N > 1 and s is a tuple expressing a part

of a full feature version information. Typical form

of the version is a triplet concerning major, minor

and micro change in interfaces together with a re-

lease note. E.g. a version may read 1.0.1.RC1.

µ is a matching function on F.

Implementing a default behavior, the µ function

matches two features only if following rules hold:

• Names are equal for both features,

• a provided feature matches only with a required

one or vice versa,

• mandatory required feature must have a provided

counterpart,

• features are compatible in terms of their types

(e.g. parameters of interfaces are of the same

types). A required feature must be a sub-type of

the provided feature. If the type compatibility is

explicitly expressed as versions, then a version on

the provided side is equal or greater than a version

on the required side or vice versa.

However a more sophisticated matching µ func-

tion can be provided. For example, compatibility on

interfaces using subtype relation (Bauml and Brada,

2009) would reach more accurate results. Since in-

stances of the features come from the EFP Assign-

ment module, the extension is straightforward: the re-

implementation of a component-speciﬁc sub-module

in the assignment module provides different µ func-

tion while the algorithm of the evaluator remains un-

changed.

Continuing with the deﬁnition of EFP Assign-

ment, E is a set of extra-functional properties from

Section 2.1 and V is a set of values (Je

zek, 2010a)

assigned to the properties which has three forms:

V = V

direct

∪V

f ormula

(5)

v ∈ V

direct

is a directly assigned value typically in-

dependent on a context of usage. In other words,

these values remain constants independently on a

runtime environment.

v ∈ V

is a value valid for a particular context of

usage as deﬁned by a local EFP repository (LR)

typically holding values dependent on a context

of usage and varying among contexts. A compo-

nent can thus contain multiple values of a given

property for different contexts. Evaluating com-

ponents, one must select which context a result

should be computed for and the evaluator then

uses only values valid for the selected context.

v ∈ V

f ormula

is a mathematical formula, declared di-

rectly at the component, determining a value of an

EFP from other EFPs. This kind of value allows

to compute EFPs on the provided side of compo-

nents based on those on the required side. In other

words, it determines how an output of a compo-

nent is inﬂuenced by its inputs.

For instance, a component may declare its speed-

up by the Amdahl’s law

(1−P)+

. P expresses

the amount of a code which may be parallelized

and for a particular component it is constant (e.g.

30%). S is a number of processors depending

on a runtime environment. Hence the component

claims its speed-up based on the input parameter

from the runtime.

Following example concludes thos section. It

shows the EFP from Section 2.1 attached two a fea-

ture using several different values:

CORRECT MATCHING OF COMPONENTS WITH EXTRA-FUNCTIONAL PROPERTIES - A Framework Applicable

to a Variety of Component Models

159

( # feature

("DataAccess", "interface", "provided", true,

"matched-by-name"),

# EFP

(time_to_process, ... ),

# values

(LR.1::low, LR.2::average, direct::20,

math::(2 * DataAccess::data_transferred) )

)

Let us note that matched-by-name denotes a

function which matches two features with the same

names. LR.1 and LR.2 are two local registries

identiﬁed by their IDs, direct is a direct value

– 20ms in this example, math deﬁnes a math for-

mula. There must be also assignment for the EFP

data_transferred which we omit here for space

constraints. Typical cases have only a one type of a

value (LR, direct or math-formula one) deﬁned in as-

signment. It is only a purpose of this example to show

all possibilities.

3 EFP EVALUATOR

ALGORITHMS AND

FORMALIZATIONS

The following sections detail the process of the evalu-

ation using more formal means. Formal deﬁnitions of

data used by the evaluator and the algorithm verifying

compatibility of components are also introduced.

3.1 Structure of EFPs Graph

Once the EFP Evaluator obtains a set of EFP Assign-

ment Types, it can compose a graph representing the

application structure annotated with properties.

The graph which is created by the EFP Evaluator

is an oriented graph

−→

G = (V,E) where V is a set of

vertexes and E is a set of edges, with specialized types

of vertexes and edges:

V (

−→

G ) = V

component

(

−→

G ) ∪V

f eature

(

−→

G ) ∪V

e f p

(

−→

G )

−→

G ) = E

belong

(

−→

G ) ∪ E

match

(

−→

G ) (6)

The following rules hold for each vertex v:

v ∈ V

component

(

−→

G ) if v represents a component. It

is a root meta-vertex which purpose is to simply

aggregate all features of a component,

v ∈ V

f eature

(

−→

G ) if the vertex represents a feature. It

expresses one type of feature depending on con-

crete implementation for a particular component

model. It may express e.g. “interface”, “service”

or whole “component”,

v ∈ V

e f p

(

−→

G ) if the vertex represents an EFP. These

vertexes are connected with V

f eature

(

−→

G ) vertexes

to express EFPs on concrete features of a compo-

nent.

Furthermore, the following rules hold for each

edge e:

e ∈ E

belong

(

−→

G ) :











) | v

∈ V

component

(

−→

G ) ∧ v

∈ V

f eature

(

−→

G )

: required feature,

) | v

∈ V

f eature

(

−→

G ) ∧ v

∈ V

component

(

−→

G )

: provided feature,

) | v

∈ V

f eature

(

−→

G ) ∧ v

∈ V

e f p

(

−→

G )

: required EFP,

) | v

∈ V

e f p

(

−→

G ) ∧ v

∈ V

f eature

(

−→

G )

: provided EFP.

This kind of edge expresses how components, fea-

tures and EFPs are connected.

e ∈ E

match

(

−→

G ) :











) | v

∈ V

f eature

(

−→

G ) ∧ v

∈ V

f eature

(

−→

G )

: binding features,

) | v

∈ V

e f p

(

−→

G ) ∧ v

∈ V

e f p

(

−→

G )

: matching EFPs.

While features are bound by the mentioned func-

tion µ, EFPs are matched via their names and their

relation to a feature. It means that one EFP may

be attached to multiple features, but only once to

the same feature.

Using this model, the Evaluator generates the graph

in several steps. It ﬁrst creates component vertexes

component

(

−→

G )) from a set of components a user de-

sires to evaluate. Secondly, the EFP Assignment

Types are added for each component and vertexes for

features (V

f eature

(

−→

G )) and EFPs (V

e f p

(

−→

G )) are cre-

ated. Furthermore, the vertexes are connected us-

ing the “belong” edges (E

belong

(

−→

G )) to express which

features and EFPs are attached to the components.

Finally, isolated graphs, representing individual

components, produced by the previous steps are

connected by matching all pairs of corresponding

provided-required features as well as EFPs. Hence,

“match” edges of the type (E

match

(

−→

G )) complete the

graph. These edges denote the connections of features

among components and pairs of EFPs attached to the

features.

The ﬁnal graph completely represents components

and their binding together with their EFPs.

3.2 Evaluation of EFPs

Having a graph representation of component connec-

tions, the evaluation is quite straightforward. The

ENASE 2011 - 6th International Conference on Evaluation of Novel Software Approaches to Software Engineering

160

evaluator must go through the graph and ﬁnd possi-

ble problems in vertex connections ﬁrst, then it uses

the values attached to EFPs to compare the value pairs

of two connected EFPs.

Figure 3: Example Graph.

3.2.1 Construction of EFP Graph

The algorithm which computes the values of attached

EFPs as well as checks the connection of components

with each other uses a modiﬁed depth ﬁrst search al-

gorithm. It has the following steps (let us use a nota-

tion v

where x,y ∈ I and I is a ﬁnite index set for

indexing vertexes and edges respectively):

1. Input sets of vertexes V

component

(

−→

G ), V

f eature

(

−→

G )

and V

e f p

(

−→

G ) are established and the ﬁrst vertex

∈ V

component

(

−→

G ) is selected, temporary vertexes

= null, previous vertex v

i−1

= null.

2. Find a ﬁrst feature vertex ﬁnding the ﬁrst edge

i j

∈ E(

−→

G ) where v

∈ V

f eature

(

−→

G ). The direc-

tion of the edge is from a component to the feature

which symbols a required feature. If there is no

such edge, the component has no required element

and a new input set is speciﬁed V

component

(

−→

G ) =

component

(

−→

G ) − {v

} and the algorithm goes to

step 5. Otherwise, proceed.

3. Find the ﬁrst edge e

∈ E(

−→

G ) where v

∈

f eature

(

−→

G ). A direction is from a feature to

another feature representing a connection of re-

quired feature to a matching provided one. If the

edge is not found and the feature is mandatory, it

means that a requirement of the component is not

fulﬁlled → ERROR. For non-mandatory features,

the algorithm goes back to step 2. Otherwise, set

i−1

= v

4. An edge e

∈ E(

−→

G ) where v

∈ V

component

(

−→

G ) is

selected. The new ﬁrst vertex v

= v

is set and the

algorithm goes back to step 2.

5. If v

6= null two sets of vertexes V

e f p

| ∃k : e

∈ E(

−→

G ) ∧ v

∈ V

f eature

(

−→

G ) ∧ v

∈

e f p

(

−→

G )} and V

e f p

= {v

| ∃ j : e

∈ E(

−→

G ) ∧

∈ V

f eature

(

−→

G ) ∧ v

∈ V

e f p

(

−→

G )} are selected.

e f p

is a set of EFPs on the feature v

and their

values are computed ﬁrst, then EFPs V

e f p

on the

feature v

are also computed. The vertexes are

removed from the input set V

f eature

= V

f eature

−

The computation of EFP values differs for three

types of values (Je

zek, 2010a)

• Direct value: a concrete value assigned to the

EFP is directly used;

• Local value: a value for a context of usage a

user aims to compute is used;

• Mathematical formula: computed using values

on connected components which must be cer-

tainly known at this time (because the depth

ﬁrst search algorithm must have already visited

connected components).

In addition, the following must hold: ∀p∃o : e

∈

−→

G ) ∧ v

∈ V

e f p

(

−→

G ) ∧ v

∈ V

e f p

(

−→

G ) meaning

that all EFPs on the required side must be con-

nected to their provided counterparts, otherwise

→ ERROR.

6. If v

i−1

6= null a new initial vertex is set v

= v

i−1

else if the set V

component

0, select another ver-

tex v

∈ V

component

(

−→

G ). Then go back to step 2.

Otherwise, the graph evaluation ends.

The algorithm veriﬁes any inconsistency in the

graph in terms of component bindings. The veri-

ﬁcation ﬁnds missing provided component elements

connected to the required sides of other components.

It furthermore ﬁnds missing EFPs on the provided

sides matching EFPs on the required sides attached

on bound components.

3.2.2 Evaluation of EFP Values in Graph

Once the components are bound and the EFPs are in

matching pairs, as a result of the algorithm, it is pos-

sible to compare values on the EFPs. This step veri-

ﬁes whether a quality demanded on the required side

is guaranteed by the EFPs on the matching provided

side.

The veriﬁcation of values must ﬁrst select a se-

quence of required-provided EFP pairs from the

graph. The sequence P(V (

−→

G ),V (

−→

G )) = {(v

) |

∀x∃y : e

∈ E(

−→

G ) ∧ v

∈ V

e f p

(

−→

G ) ∧ v

∈ V

e f p

(

−→

G )}

contains EFP vertexes to be compared. A sequence

of EFP values attached to these vertexes is obtained

applying the function:

value : V (

−→

G ) ×V (

−→

G ) → T × T (7)

where T is a set of EFP value instances computed on

respective vertexes.

CORRECT MATCHING OF COMPONENTS WITH EXTRA-FUNCTIONAL PROPERTIES - A Framework Applicable

to a Variety of Component Models

161

Furthermore a function γ : T ×T → Z (Section 2.1,

equation 1) compares value pairs returning a numeric

result. Taking it together, the sequence of vertex pairs

is transformed to a set of numbers.

γ ◦ value : V (

−→

G ) ×V (

−→

G ) → Z (8)

Using the functions, vertexes from the input se-

quence are ﬁnally compared:

= γ

(value

(P(V (

−→

G ),V (

−→

G ))

)),

k = 1..|P(V (

−→

G ),V (

−→

G ))|

The resulting sequence of numbers is checked. A

non-negative number means that a quality has been

satisﬁed. For that reason the evaluator veriﬁes that

∀k∃z

: z

∈ [0,∞) ⊂ Z holds. Otherwise the evaluator

signals an error for the EFP wrapped in the respective

vertex.

For instance, let us assume the property

time_to_process with numeric values and a γ func-

tion γ(x, y) = x − y (shorter processing time is bet-

ter). Following Figure 3 with values assigned to ver-

texes v

:= 10 and v

:= 30 the evaluation returns

γ(value(v

)) = γ(value(10,30)) = 10−30 = −20.

The result of the evaluation for these vertexes leads to

incompatible EFPs. For different values v

:= 40 and

:= 30 the evaluation would succeed.

4 IMPLEMENTATION AND

TOOLBOX

As a proof of the concept, the framework has been im-

plemented

in the form of a set of modules and tools.

4.1 EFP Repository Server

In our case, the EFP repository has been imple-

mented as a web application storing data in a rela-

tional database and producing raw output via web ser-

vices using SOAP. This approach provides a low-level

XML data via standard HTTP protocol. The server,

in addition, provides WSDL ﬁles describing the web

service interfaces with the advantage of generating a

client program communicating with the server.

On one hand this technology allows a low-level

access by several clients working with SOAP proto-

col, on the other hand the plain XML data may be

awkward for other modules. In order to solve this

problem we have created a sub-module named the

EFP Client, shown in Figure 4, which basically turns

https://www.assembla.com/code/cosi/subversion/nodes

/efps

XML data into EFP Types and vice versa. Hence,

client modules access data via EFP Client using fa-

miliar EFP Types ﬁrst, then the repository transpar-

ently receives XML data.

From a technological point of view, the server is

a Java application using the Spring framework

. It

integrates the Hibernate framework

for the database

layer and Apache CXF

providing web-services.

While Hibernate offers an independent access to a va-

riety of database systems, CXF provides a rapid cre-

ation of web-services. Currently, Spring is used as an

inversion-of-control container, however, its usage al-

lows extensibility in the future. For instance, a web

client may be implemented to improve a user comfort

to interact with the server. The EFP Client has been

created as a web-services client and thus it also uses

Apache CXF.

Figure 4: Server Communication.

4.2 EFP Assignment and Evaluator

The two modules for transferring data (EFP Types and

EFP Assignment Types) as well as the EFP Assign-

ment module have been developed in a pure Java.

Figure 5: EFP Repository Tool.

www.springsource.org/

www.hibernate.org/

cxf.apache.org/

ENASE 2011 - 6th International Conference on Evaluation of Novel Software Approaches to Software Engineering

162

EFP Types module is implemented as a set of

classes implementing generic interfaces that are able

to hold a complete EFP representation. Main ad-

vantage of this approach is its extensibility (Je

zek,

2010a). It allows to modify data processed by the

framework in the future by writing different imple-

mentation of the generic interfaces.

The sub-module of EFP Asssignment data uses

XML ﬁles for storing EFP. It creates an off-line mirror

of the component related data from the EFP reposi-

tory. In practice, as the data are loaded and applied on

the component, the EFP Assignment module mirrors

them to a XML ﬁle. Where and how the ﬁle is stored

is up to the other sub-module.

The other sub-module of EFP Assignment, which

adresses differences of component models, is devel-

oped as a prototype implementation for the CoSi com-

ponent framework (Brada, 2008). Components in

CoSi have a form of Java JAR ﬁles. Hence, the pro-

totype implementation packages the XML ﬁle into

the JAR archive under the Meta-Inf folder. Further-

more, a linkage of EFPs to each service is stored in the

manifest.mf ﬁle. A similar strategy may be used for

other component models.

The EFP evaluator has been also written in pure

Java, however, it uses the JgraphT

library for both

creating and discovering vertexes of the graph. It

leads to an easier implementation of the evaluating

algorithm. The evaluator publishes the results via a

set of objects aggregating all incompatibility errors.

Client applications may process the results as they de-

sire. For instance, the results may be printed to users

or they may be sent to other systems.

Moreover, all modules are built and distributed as

a set of Java JAR ﬁles. The distribution form provides

other Java-based applications with a possibility to in-

tegrate this framework as a third-party library. For

instance, the framework may be integrated to a com-

ponent repository as a tool checking component as-

semblies.

4.3 Tools

Since modules composing the framework aim at be-

ing used in other systems, their direct access by users

is impractical. For that reason, we have developed

tools offering comfortable graphical interfaces.

The ﬁrst tool shown in Figure 5 works with the

EFP repository to provide control upon the repository

data. The implementation is a Java JFC Swing client

communicating with the server via web-services. Al-

though the selected technologies would allow to cre-

ate a web client, the choice taken has been more prac-

www.jgrapht.org/

tical for research purposes, because the process of de-

velopment simultaneously tests the web-services.

Figure 6: EFP Assignment Tool.

The other tool shown in Figure 6 is a Java JFC

Swing client accessing the EFP Assignment module.

The client’s main functionality is to show EFPs avail-

able in the repository and to attach them to compo-

nents. In a basic scenario the users drag-and-drop

EFPs within one panel to the other panel listing com-

ponent features. Moreover, each drag-and-drop oper-

ation opens a dialog to input a value for the EFP to

be attached. Another important aspect is the ability

to switch the tool to other component models if the

EFP Assignment module contains an appropriate im-

plementation.

5 APPLICATON TO INDUSTRIAL

FRAMEWORK

This section brieﬂy shows a possible implementation

of the EFP framework for an existing industrial com-

ponent framework.

5.1 EFPs in Spring Framework

One of the widely used component frameworks is

Spring. Components in Spring have forms of so called

Beans where one Bean is one Java class. Dependen-

cies between components are explicitly expressed in

conﬁguration XML ﬁles which in essence deﬁne a so

called Application Context (Spring, 2010).

Let us note that despite complexity of Spring,

we will for the purposes of this paper use only the

CORRECT MATCHING OF COMPONENTS WITH EXTRA-FUNCTIONAL PROPERTIES - A Framework Applicable

to a Variety of Component Models

163

Spring’s XML based conﬁguration with setter injec-

tion. Details concerning the application of the EFP

framework to the Spring’s annotation driven conﬁgu-

ration are avoided to preserve clarity of the presented

approach.

Spring Beans deﬁned in the application context

may be considered as provided features in terms of

the EFP framework. Each setter of a Bean denotes

the required side of the Bean. Hence, the binding of

the provided to required side is equivalent to the ex-

amination of values (objects) injected into the setters

of the Bean.

Since Spring does not handle extra-functional

properties, they must be explicitly added by the EFP

framework. The EFP Assignment module must there-

fore be extended to attach EFPs to Spring Beans.

This may for instance be achieved by extending

Spring’s XML conﬁguration ﬁles using XML name-

spaces to include also the EFP declarations. We sug-

gest a solution in which the EFP data mirror is a stand-

alone XML ﬁle – as has been mentioned in Section 4

– and the links between the mirror and Spring Beans

are stored in the extended Spring XML ﬁles.

The main advantage of this solution is that the

new XML tags do not clash with existing ones and

the Bean deﬁnition is separated from the deﬁnition of

EFPs.

Example of the solution based on the extended

XML ﬁles:

<bean id="data"

class="cz.zcu.kiv.example.DataAccess" >

<efp:name="response-time" property="jdbc">

<efp:values>

<efp:lr id="1" value="average" />

<efp:direct value="100" />

</efp:values>

</efp:name>

</bean>

In order to evaluate EFPs attached on Spring

Beans, the EFP evaluator must be aware of Beans

binding. To obtain the binding information directly

from the Spring framework the suitable solution is to

participate in the container life-cycle. Spring contains

a set of so called Bean Post Processors providing de-

velopers with a rich spectrum of call-back methods

allowing to modify the container life-cycle.

For the purposes of components matching, the

InstantiationAwareBeanPostProcessorAdapter

is useful to monitor bindings of Bundles with one

another.

An implementation preparing data for the µ

matching function may look like this (in outline):

public class EfpAwareBeanPostProcessor

extends

InstantiationAwareBeanPostProcessorAdapter

{

List<Pair> matchingPairs = ...

public

PropertyValues postProcessPropertyValues(

PropertyValues pvs,

PropertyDescriptor[] pds,

Object bean,

String beanName)

throws BeansException {

for (PropertyDescriptor pd: pds) {

PropertyValue prop = pvs

.getPropertyValue(pd.getName());

Object anotherBean = prop.getValue();

// "bean" and "anotherBean"

//are in a matching pair.

matchingPairs.add(

new Pair(bean, anotherBean));

}

return pvs;

}

The presented code contains the method which is

invoked by the Spring container each time a new Bean

is created. The input parameters hold information

about the Bean and its properties which have already

been set. Hence, the EFP framework uses it to deter-

mine that other Beans have been injected into this one.

This information is used for producing the component

graph (Section 3.1).

An application of the EFP Evaluator for Spring is

straightforward. Using the strategy with Bean Post

Processors, the evaluator is invoked as a new Bean

is instantiated ﬁrst, then the attached EFPs are evalu-

ated (Section 3.2). Depending on particular needs, the

evaluator can be invoked for each change in the Ap-

plication Context or only once when the system starts.

Any errors found in the evaluating process may cause

the Application Context to stop as well as the errors

to be logged.

6 RELATED WORK

This work has been partly based on our previous re-

search. Namely, the structure of data stored in the

EFP repository is an implementation of our formal

deﬁnitions published in (Jezek et al., 2010). EFP

Types has been implemented using meta-models de-

tailed in (Je

zek, 2010a). Hence, the part of the frame-

work concerning the repository is mostly a comple-

ment of our previous work while the other part is a

ENASE 2011 - 6th International Conference on Evaluation of Novel Software Approaches to Software Engineering

164

new contribution.

There are a lot of other approaches targeting extra-

functional properties. They usually cover a rich spec-

trum of issues, from formal deﬁnitions to practical im-

plementations.

An often addressed issue is the description of

extra-functional properties. One of the expressing

means are specialized languages, for example CQML

(Aagedal, 2001) that serves as a complete extra-

functional language, CQML+ (R

ottger and Zschaler,

2003) that explicitly takes a runtime environment

dependency into account, or NoFun (Franch, 1998)

that distinguishes between simple and derived extra-

functional properties. Furthermore there exist rather

specialized languages such as TADL (Mohammad

and Alagar, 2008) which is a language describing

architectures of systems with a concern of EFPs,

HQML (Gu et al., 2001) as a language targeted

to web-development, or the SLAng language suited

especially for service-level agreement speciﬁcations

(Lamanna et al., 2003). A general advantage of such

approaches is that they provide an answer of what

an extra-functional property should stand for. On the

other hand they do not address the question of how the

properties should be evaluated. Developing our ap-

proach, we use these languages to consolidate typical

features of extra-functional properties into our model.

Other works propose component frameworks tak-

ing extra-functional properties into account as a part

of their component models. Let us name at least Pal-

ladio (Becker et al., 2009) that targets mainly per-

formance characteristics, Robocop (Muskens et al.,

2005; Bondarev et al., 2006) for real-time charac-

teristics, or ProCom (Sentilles et al., 2009). These

approaches typically lack modularity in terms of the

peculiar ways of using extra-functional properties. It

prevents their extra-functional properties to be used in

other component frameworks.

Very often, an issue being solved is modeling

of extra-functional characteristics. For instance, the

OMG group standardized a UML proﬁle (OMG,

2008) covering the quality of services.

Comparing these approaches to our contribution,

we aim at a system which is not tied with a concrete

component framework, is not intrusive and provides

easy integration with other frameworks.

7 CONCLUSIONS

This paper has pointed out a need for extra-functional

properties to improve current component based de-

velopment. Moreover a problem of applicability of

extra-functional properties to practice has been men-

tioned. The most important issue targeted in this pa-

per is a discrepancy of industrial and research com-

ponent frameworks together with slow application of

extra-functional properties to practice.

The contribution of this paper lies in the imple-

mentation of an independent framework for working

with EFPs in a comprehensive manner. The frame-

work includes a repository of extra-functional proper-

ties, a module assigning the properties to each com-

ponent and an evaluator of the properties. This ap-

proach enriches, but does not limits, current industrial

component frameworks and aims at ﬁlling the gap be-

tween application of extra-functional properties and

the practically used component frameworks.

The approach has been presented in terms of mod-

els and algorithms and the prototype implementation

has been introduced.

Since the work is still in the progress, we have

some issues to be solved in the future. First of all,

our preliminary implementation works with the CoSi

component framework. Since CoSi is highly inspired

by OSGi, we desire to implement our framework

also for OSGi. Furthermore, the implementation for

Spring-DM or Spring seems to be also worth consid-

ering.

Secondly, the prototype implementation of the

repository does not take questions such as security,

user access rights, or publishing of new versions into

account. We aim at answering these questions as soon

as the prototype is fully tested and working.

ACKNOWLEDGEMENTS

The work was partially supported by the UWB grant

SGS-2010-028 Advanced Computer and Information

Systems and by the Czech Science Foundation project

103/11/1489 Methods of development and veriﬁca-

tion of component-based applications using natural

language speciﬁcations.

We would like to thank students Martin

Stulc,

Luk

s Vl

cek and Jan

ab for their considerable help

in programming the presented framework.

REFERENCES

Aagedal, J. Ø. (2001). Quality of Service Support in Devel-

opment of Distributed Systems. PhD thesis, University

of Oslo.

Bauml, J. and Brada, P. (2009). Automated versioning in

osgi: A mechanism for component software consis-

tency guarantee. In EUROMICRO-SEAA, pages 428–

435.

CORRECT MATCHING OF COMPONENTS WITH EXTRA-FUNCTIONAL PROPERTIES - A Framework Applicable

to a Variety of Component Models

165

Becker, S., Koziolek, H., and Reussner, R. (2009). The pal-

ladio component model for model-driven performance

prediction. Journal of Systems and Software, 82(1):3

– 22. Special Issue: Software Performance - Modeling

and Analysis.

Bondarev, E., Chaudron, M. R., and de With, P. H. (2006).

Compositional performance analysis of component-

based systems on heterogeneous multiprocessor plat-

forms. In Proceedings of Euromicro conference on

Software Engineering and Advanced Applications,

pages 81–91. IEEE Computer Society.

Brada, P. (2008). The CoSi component model: Reviving

the black-box nature of components. In Proceedings

of the 11th International Symposium on Component

Based Software Engineering, number 5282 in LNCS,

Karlsruhe, Germany. Springer Verlag.

Chung, L., Nixon, B. A., Yu, E., and Mylopoulos, J. (1999).

Non-Functional Requirements in Software Engineer-

ing. Series: International Series in Software Engineer-

ing, Vol. 5, Springer, 476 p, ISBN: 978-0-7923-8666-

Franch, X. (1998). Systematic formulation of non-

functional characteristics of software. In Proceedings

of International Conference on Requirements Engi-

neering (ICRE), pages 174–181.

Garc

ıa, J. M., Ruiz, D., Ruiz-Cort

es, A., Mart

ın-D

ıaz, O.,

and Resinas, M. (2007). An hybrid, qos-aware dis-

covery of semantic web services using constraint pro-

gramming. In ICSOC ’07: Proceedings of the 5th in-

ternational conference on Service-Oriented Comput-

ing, Springer-Verlag Berlin, Heidelberg 2007, ISBN:

978-3-540-74973-8, pages 69–80, Berlin, Heidelberg.

Springer-Verlag.

Gu, X., Nahrstedt, K., Yuan, W., Wichadakul, D., and Xu,

D. (2001). An xml-based quality of service enabling

language for the web. Technical report, University of

Illinois at Urbana-Champaign, Champaign, IL, USA.

ISO/IEC (2001). ISO/IEC 9126: Informational technology

- product quality - part1: Quality model, international

standard iso/iec 9126, international standard organiza-

tion.

zek, K. (2010a). A complex meta-model for extra-

functional properties concerning common data types

their comparing and binding. In 2nd World Congress

on Software Engineering (WCSE 2010), Volume 2,

pages: 71-74,ISBN:978-0-7695-4303-1.

zek, K. (2010b). Universal extra-functional proper-

ties repository, model overview and implementation.

In Proceedings of the International Conference on

Knowledge Management and Information Sharing

(KMIS 2010), pages: 382-385,ISBN: 978-989-8425-

30-0.

Jezek, K., Brada, P., and Stepan, P. (2010). Towards con-

text independent extra-functional properties descrip-

tor for components. In Proceedings of the 7th Interna-

tional Workshop on Formal Engineering approaches

to Software Components and Architectures (FESCA

2010), Electronic Notes in Theoretical Computer Sci-

ence (ENTCS) Volume 264, page 55-71, ISSN: 1571-

0661, pages 55–71.

Lamanna, D. D., Skene, J., and Emmerich, W. (2003).

Slang: A language for deﬁning service level agree-

ments. Future Trends of Distributed Computing Sys-

tems, IEEE International Workshop, 0:100.

Lau, K. K. and Ukis, V. (2006). Deﬁning and check-

ing deployment contracts for software components.

In Proceedings of the 9th International Symposium

on Component-Based Software Engineering, volume

4063 of LNCS, pages 1–16.

Mohammad, M. and Alagar, V. S. (2008). TADL -

an architecture description language for trustworthy

component-based systems. In ECSA ’08: Proceedings

of the 2nd European conference on Software Architec-

ture, pages 290–297. Springer.

Muskens, J., Chaudron, M. R., and Lukkien, J. J. (2005).

Component-Based Software Development for Embed-

ded Systems, chapter A Component Framework for

Consumer Electronics Middleware, pages 164–184.

Springer Verlag.

OMG (2008). UML proﬁle for modeling quality of ser-

vice and fault tolerance characteristics and mechanism

speciﬁcation. Technical report, OMG - Object Man-

agement Group.

ottger, S. and Zschaler, S. (2003). CQML+: Enhance-

ments to CQML. In Bruel, J.-M., editor, Proc. 1st

Int’l Workshop on Quality of Service in Component-

Based Software Engineering, Toulouse, France, pages

43–56. C

epadu

es-

Editions.

Sentilles, S., Stepan, P., Carlson, J., and Crnkovic, I. (2009).

Integration of extra-functional properties in compo-

nent models. 12th International Symposium on Com-

ponent Based Software Engineering (CBSE 2009),

LNCS 5582.

Spring (2010). Spring Framework, ver.3,

Reference Documentation. Spring Co-

munity, ver. 3 edition. Available at

http://static.springsource.org/spring/docs/3.0.x/spring-

framework-reference/html/.

Szyperski, C., (with Dominik Gruntz, and Murer), S.

(2002). Component Software - Beyond Object-

Oriented Programming: Second Edition. Addison-

Wesley / ACM Press, 624 pages, ISBN-13: 978-

0201745726.

Yan, J. and Piao, J. (2009). Towards qos-based web services

discovery. In Service-Oriented Computing ICSOC

2008 Workshops, Lecture Notes in Computer Science,

2009, Volume 5472/2009, 200-210, ISBN: 978-3-642-

01246-4.

ENASE 2011 - 6th International Conference on Evaluation of Novel Software Approaches to Software Engineering

166