EXTRA-FUNCTIONAL PROPERTIES FRAMEWORK WITH
CONFIGURATION BASED ON DEPLOYMENT ENVIRONMENT
Tool Demonstration and Case-study
Kamil Je
ˇ
zek and Premek Brada
Department of Computer Science and Engineering, University of West Bohemia
Univerzitni 8, 30614 Pilsen, Czech Republic
Keywords:
Extra-functional properties, Evaluation, Case-study, Tool, Component.
Abstract:
Current software systems tend to share not only data but also software parts in a form of software compo-
nents or web services. Once users cooperate third-party software parts, mechanisms and tools integrating and
validating these software parts are desired. Therefore, advanced techniques for verifying compatibility and
interchangeability should also consider extra-functional properties. This paper aims at supporting these tech-
niques introducing a tool capable of definition, application and evaluation of extra-functional properties. The
ability of the tool is demonstrated in a case-study developed on Common Component Modeling Example.
1 INTRODUCTION
Nowadays, industry and the research community deal
with the issue of extra-functional properties (EFPs).
For instance, (1) qualities such as speed, response
time, memory consumption or (2) user requirements
such as marketability, price, regular updates, techni-
cal support or (3) behaviour such as synchronisation,
concurrent access, deadlock free computation are of-
ten addressed EFPs.
In our previous work an independent EFP frame-
work (Je
ˇ
zek and Brada, 2011) enabling EFPs in ex-
isting industrial systems was proposed. This paper
demonstrates that approach in a form of a case-study
developed according to Common Component Model-
ing Example (CoCoME) (Herold et al., 2010).
This paper first introduces the case-study in Sec-
tion 3 followed by domain EFP definitions in Section
3.1 and context-of-usage dependent EFP definitions
in Section 3.2. Finally, Section 3.3 demonstrates the
EFP evaluation process.
The work was partially supported by the UWB grant
SGS-2010-028 Advanced Computer and Information Sys-
tems, by the Grant Agency of the Czech Republic project
number 103/11/1489 Methods of development and verifi-
cation of component-based applications using natural lan-
guage specifications and by the SPAV grant with the regis-
tration number CZ 1.07/2.3.00/09.0050.
2 RELATED WORK
Other approaches target several disjunctive groups
of EFPs. One group treats EFPs in isolation
(Aagedal, 2001; Franch, 1998; Chung et al., 1999;
ISO/IEC, 2001) while another consider their depen-
dency (Zschaler and Meyerhfer, 2003). They provide
basic ideas of a structure of EFPs, however, lack of
tool support limits their practical usage.
There are structural frameworks with EFPs (Mo-
hammad and Alagar, 2008) or systems with native
support of either EFP or quality of service specifica-
tions (Yan and Piao, 2009; Garc
´
ıa et al., 2007) which
still focus on a limited set of EFPs.
In addition, there are several component models
(Becker et al., 2009; Muskens et al., 2005) which sup-
port specialised sets of EFPs. As in our work there
are attempts to tool support (Sentilles et al., 2008) or
Q-ImPrESS
2
targeted at a selected set of component
models.
In our previous work, we stated formal defini-
tions of EFPs (Jezek et al., 2010) which extension and
implementation we developed in (Je
ˇ
zek and Brada,
2011).
2
http://www.q-impress.eu/wordpress/
322
Ježek K. and Brada P..
EXTRA-FUNCTIONAL PROPERTIES FRAMEWORK WITH CONFIGURATION BASED ON DEPLOYMENT ENVIRONMENT - Tool Demonstration and
Case-study.
DOI: 10.5220/0003639403220325
In Proceedings of the International Conference on Knowledge Management and Information Sharing (KMIS-2011), pages 322-325
ISBN: 978-989-8425-81-2
Copyright
c
2011 SCITEPRESS (Science and Technology Publications, Lda.)
3 CASE-STUDY AND TOOL
DEMONSTRATION
Case-study is in this paper based on CoCoME that
is an example of a trading system with a set of hi-
erarchical components. For the sake of brevity only
few components have been selected to demonstrate
the tool. The components composing the case-study
are shown in Figure 1 with Notes to show attached
EFPs.
Figure 1: CoCoME Sub-part.
3.1 Domain Dependent Definitions of
Properties
The presented tool uses commonly accessible EFP
repository spiting domain and context-of-usage con-
cerns. For that, Global Registries (GRs) (Jezek et al.,
2010) hold domain specific EFP definitions filled by
domain experts.
Figure 2 shows a GUI editor of GR. The tool ac-
cesses a remote web-server storing the GR structure
(Je
ˇ
zek and Brada, 2011). A user selects GR which
he or she tends to work with, then EFPs are edited in
terms of their names, data types, comparing functions
and named values (in detail formalised in (Jezek et al.,
2010)).
Figure 2: EFP Registry Tool.
For our study, a GR named CoCoME with sev-
eral EFPs (response time, express mode supported,
bar code type, bar code scanner type) has been cre-
ated. The EFPs defined in one GR bounds EFPs as
valid and meaningful in one domain. Hence, the EFPs
created for CoCoME cover the domain of trading sys-
tems.
Figure 3: EFP Local Registry Editor.
The context-of-usage concern is captured in a set
of Local Registries (LRs) (Jezek et al., 2010) with
an editor shown in Figure 3. In the tool a user cre-
ates named intervals of values that has two advan-
tages: (1) the “plain“ values are given the semantics
and (2) values from one interval are unified to the
same scale. For instance, response time in an inter-
val {1000, 3000}ms may be “average” for back-end
office (Inventory in CoCoME) for all values 1000ms,
2000ms, 3000ms as long as they belong to one group.
3.2 Application of Property Values
Once EFPs are defined in Registries, the tool shown
in Figure 4 is used for attaching selected values to
components. Components are shown in one panel and
EXTRA-FUNCTIONAL PROPERTIES FRAMEWORK WITH CONFIGURATION BASED ON DEPLOYMENT
ENVIRONMENT - Tool Demonstration and Case-study
323
EFPs in the other one. A user drag-and-drops to attach
EFPs.
Figure 4: EFP Assignment Tool.
The tool allows to assign three type of values
(Je
ˇ
zek and Brada, 2011):
Context Independent Values. A lot of EFPs ex-
press values unchanged among all contexts-of-usage.
Here, the tool assigns a concrete EFP value (e.g. num-
ber, string, boolean). An example of a property is
the express mode supported attached to ExpressMod-
eEnabledEvent. It is a boolean indicating the express
mode of a cash desk which essentially has the same
meaning all the time.
Context Dependent Values. Often values vary
among contexts-of-usage. Here, several LR named
values may be assigned. In the evaluation a user
selects the LR to evaluator for. Such a property is
response time in the case-study. E.g. a cash desk
may have harder performance needs than Inventory.
Hence, the property values are defined in two sepa-
rated LRs to distinguish two environments.
Computed Values. Complex properties are typi-
cally influenced each other (e.g. performance of one
component is influenced by a connected components).
Here, the tool adds mathematical or logical formulas
computing an EFP value depending on other EFPs.
In CoCoME, the component Inventory::Database,
Inventory::Data and Inventory::Application are used.
Modeling EFPs, the property response time on
the output of Inventory::Data is influenced by
the output on Inventory::Database. A user
may define e.g. a mathematical formula Inven-
tory::Data: response time(PersistenceI f ) = 1.2
response time(JDBC)
Another example uses the bar code type with val-
ues {EAN-8, EAN-13, UPC-A, UPC-E, ...} for ex-
isting bar codes. Bar code scanner type may be com-
puted by a logical formula: bar code scanner type =
EU bar code type = {EAN8, EAN13} where EU
is the item of an enumeration.
3.3 Evaluation Process
When components are being assembled into an ap-
plication, the EFPs of the provided and required fea-
tures need to be evaluated for the compatibility. This
is performed by an evaluator tool which, unlike other
tools, does not have a GUI. It is rather implemented
as a framework embeddable to other systems. It uses
two steps to evaluate EFPs: (1) it binds components
via their features and creates a graph expressing their
connections, (2) the properties on bound features are
compared by the algorithm from (Je
ˇ
zek and Brada,
2011).
For context independent values, the evaluator
compares values directly attached on both con-
nected properties. According to the case-study,
if the CashDesk::CashDeskApplication requires the
property express mode enabled set to true, then a
compatible CashDesk::CardReaderController com-
ponent has to provide express mode enabled also set
to true.
Evaluation of context dependent values compares
only values from a selected LR where a LR setting is
a matter of configuration. Values irrelevant for other
LRs are ignored. For instance, values on the proper-
ties response time for Inventory are taken only from
Store LR while others are ignored.
Computed values evaluation uses depth-first
search algorithm to recursively compute properties
in a formula. In the use-case, evaluation on Inven-
tory::Application:PersistenceIf needs to find Inven-
tory::Database::JDBC first. Then a value of response
time on Inventory::Data:PersistenceIf depending on
Inventory::Data:JDBC may be computed. At the end,
the values are compared as for direct values.
4 CONCLUSIONS
In this work a tool concerning extra-functional prop-
erties in terms of their definition, application and eval-
uation has been presented. The tool is based on a
framework, developed in our previous work.
KMIS 2011 - International Conference on Knowledge Management and Information Sharing
324
The tool aims at improving adoption of extra-
functional properties in practice. This aim has been
demonstrated by the presented case-study which com-
prises a part of the Common Component Modeling
Example proving the framework’s applicability to a
practical application.
The case-study has shown that the system of reg-
istries is capable of managing extra-functional prop-
erties on systems deployed in different runtime envi-
ronments. On the other hand a few weakness have
been found. Namely, there are properties which need
more sophisticated evaluating methods (for instance,
memory consumption is not a simple summation of
each component if they use shared libraries). Such
evaluating methods we will target in the future. In ad-
dition, filling of values in LRs is a time consuming
manual work. For that reason formulas transferring
values among LRs would improve the approach.
ACKNOWLEDGEMENTS
We would like to thank students Martin
ˇ
Stulc, Luk
´
a
ˇ
s
Vl
ˇ
cek and Jan
ˇ
Sv
´
ab for their considerable help in
preparing the presented case-study.
REFERENCES
Aagedal, J. Ø. (2001). Quality of Service Support in Devel-
opment of Distributed Systems. PhD thesis, University
of Oslo.
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.
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-
7.
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.
Herold, S., Klus, H., Welsch, Y., Rausch, A., Reuss-
ner, R., Krogmann, K., Koziolek, H., Miran-
dola, R., Benjamin, Hummel, Meisinger, M.,
and Pfaller, C. (2010). Common component
modelling example (CoCoME). Book Chap-
ter. Available at http://agrausch.informatik.uni-
kl.de/CoCoME/downloads (2010).
ISO/IEC (2001). ISO/IEC 9126: Informational technology
- product quality - part1: Quality model, international
standard iso/iec 9126, international standard organiza-
tion.
Je
ˇ
zek, K. and Brada, P. (2011). Correct matching of compo-
nents with extra-functional properties - a framework
applicable to a variety of component models. In Eval-
uation of Novel Approaches to Software Engineering
(ENASE 2011). [accepted to publication].
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.
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.
Sentilles, S., H
˚
akansson, J., Pettersson, P., and Crnkovic,
I. (2008). Save-ide an integrated development en-
vironment for building predictable component-based
embedded systems. In Proceedings of the 23rd
IEEE/ACM International Conference on Automated
Software Engineering (ASE 2008).
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.
Zschaler, S. and Meyerhfer, M. (2003). Explicit mod-
elling of qos-dependencies. In Proceedings of the
1st International Workshop on Quality of Service
in Component-Based Software Engineering, Cpadus-
ditions, Toulouse, France, pages 57–66.
EXTRA-FUNCTIONAL PROPERTIES FRAMEWORK WITH CONFIGURATION BASED ON DEPLOYMENT
ENVIRONMENT - Tool Demonstration and Case-study
325