Content uploaded by İbrahim Onuralp Yiğit
Author content
All content in this area was uploaded by İbrahim Onuralp Yiğit on Apr 29, 2016
Content may be subject to copyright.
Content uploaded by İbrahim Onuralp Yiğit
Author content
All content in this area was uploaded by İbrahim Onuralp Yiğit on Apr 29, 2016
Content may be subject to copyright.
SDPS-2015
Printed in the United States of America, November, 2015
©2015 Society for Design and Process Science
1
DEFINITION OF DOMAIN SPECIFIC COMPONENTS IN SOFTWARE
PRODUCT LINES BASED ON FEATURE VARIABILITY
Ibrahim O. Yigit1, Ali H. Dogru2
1,2 Computer Engineering Department, METU
Ankara, Turkey
{ 1yigit.onuralp@metu.edu.tr 2dogru@ceng.metu.edu.tr }
ABSTRACT
This research proposes a preliminary methodology for
the determination of a set of components to populate the
domain model of a Software Product Line infrastructure. The
approach is based on variability specifications that is rooted
in Feature Models and reflected a variable component model:
VCOSEML. An initial set of proposed components is
modified with respect to the feature constraints and other
design metrics such as coupling, cohesion, and size-oriented
complexity. Modifications in the component set are refined
through the iterative methodology, and an optimal set of
components is tried to be achieved. The goal is to yield a set
that supports reusability – to arrive at a more manageable and
quickly converging design in terms of component
assignments to required features. A case study is exploited in
the validation of the approach.
INTRODUCTION
Nowadays, software reuse is a crucial factor for
improving quality and productivity (Basili et al., 1996).
Notably, software reuse is more efficient when
systematically planned and managed for a set of applications
in a specific domain. Software product family is developed
instead of creating software from scratch for each project. In
this way, companies can not only quickly respond to the
different requests from the customer but also put a new
product on the market in a short period.
Software Product Line (SPL) is a set of software-
intensive systems sharing a common, managed a set of
features (Pohl et al., 2005). The set of features specifies the
particular needs of a market segment. Software products are
developed from a common set of core assets. Also, software
product line engineering is a methodology for developing
software products at lower cost, in less time and with higher
quality (Pohl et al., 2005). The crucial aim of the software
product line approach is to improve reuse systematically. For
successful Software Product Line Engineering (SPLE),
developing a set of core assets deals with commonality and
variability among software product family (Bosch, 2000).
Therefore, a suitable environment is prepared for reuse of
core assets.
Definition of domain specific components is a critical
aspect of SPLE. However, the existing methodologies do not
present a systematic way of how to define the set of domain
specific components. In this paper, we propose an initial
methodology for the determination of a set of components to
populate the domain model of an SPL infrastructure. This
research presents an approach based on a well-defined set of
principles, guidelines, and metrics. Moreover, it makes
available to exploit the commonality and manage variability
in both problem and solution spaces. A case study is utilized
in the validation of the approach.
This paper is structured as follows. In Section II, the
general principles of SPLE are explained. Section III
explores VCOSEML that is a new component variability
model. In Section IV, the proposed approach defining a set of
domain specific components is discussed as a preparation for
variability modeling with supported illustrative example
concurrently. The results of the experimental study that
evaluates the approach are presented in Section V. The paper
is summarized in Section VI.
BACKGROUND
Software Product Line Engineering
SPL is a popular approach in Software Engineering due
to the advantages it offers to software development regarding
time, cost and effort (Guendouz et al., 2014). SPLE is an
approach to handle commonality and variability among
software products for the product family (Svahnberg et al.,
2001).
SPLE is composed of two phases: domain engineering
for reuse and application engineering for development with
reuse (Van Der Linden, 2007). Domain engineering is a
phase that is composed of developing core assets through the
domain analysis, domain design, domain realization, and
domain testing processes. Application Engineering is a
development process where software products are produced
from reusable core assets.
Variability Management
Variability defines how different products can be
changed or customized SPLs (Svahnberg et al., 2001).
Variability management is about handling the introduction,
use, and evolution of variability (Razavian et al., 2008).
Managing variability among software products of a family is
one of the most considerable activities in SPLE. SPLE deals
with developing domain specific products, taking into
consideration commonality and variability among them
2
(Bosch, 2000). For developing software products by using
core assets, domain engineers must detect and manage
variability between software products.
Variability modeling is a method representing variability
among software products of a domain. It provides not only
understanding of variability but also assisting domain
engineers in the task of variability management (Razavian et
al., 2008). Variability modeling expresses common and
variable parts in SPLs. Moreover, it defines constraints
between variable parts explicitly. Variability management
plays a significant role in both phases of SPLE, domain
engineering and application engineering. Consequently,
variability modeling should work for both phases.
A feature defines a software property and represents
functionality in a domain (Kang et al., 1990). A feature
model as represented in a hierarchical tree structure is a
composition of mandatory, optional, or, and alternative
features (Kang et al., 1990). Also, feature model is a
powerful notion of handling the complexity in SPLs. From
the end user view, the model provides a presentation of the
characteristics in a domain. Essentially, it consists of the
common features and variations of software products in a
domain. Thus, variability modeling with feature model is one
of the key strategies for indicating the problem space of
SPLs.
Features are indicated as mandatory, optional, or, and
alternatives (Kang et al., 1990). Variation points and variants
express feature variability. A variation point defines what
can vary in a feature (Pohl et al., 2005). A variant specifies
how a feature can vary (Pohl et al., 2005). Every variation
point has a set of related variants that determine how the
variation point can be resolved (Haber et al., 2011).
Feature variability also defines two kinds of constraints
between features: requires and excludes (Gherardi, 2013).
- Requires constraint: if a feature A is selected to be
part of a configuration, then also feature B has to be
selected.
- Excludes constraint: if a feature A is selected to be
part of a configuration, then feature B cannot be
selected.
VCOSEML
Component is an element of software, as a building
block that contains complex functionalities. Component-
based software systems are developed by selecting
appropriate components and assembling them together
(Dogru, 1999). Component Oriented Software Engineering
Modeling Language (COSEML) is a graphical and proper
modeling language for visualizing a hierarchical
decomposition (Dogru, 2006). Different from the
component-based approaches, components are the
fundamental notions starting with the abstractions in
requirements and continuing through the executable code.
COSEML is supported with a graphical tool, modeling a
system as components and their connections. COSEML
begins with the abstraction of system parts to introduce the
building blocks of a system. After that physical components
need to be corresponded to encapsulate the detailed
functionalities in the defined abstract modules (Ileri et at,
2013). Links connect abstractions to physical components.
Abstractions in COSEML are Package, Data, Control and
Function at the logical level. Also, components and their
interfaces are main elements at the physical level.
Connectors represent communications among components.
Therefore, COSEML is capable of representing not only the
solution space but also the problem space for designing
component-oriented software systems.
COSEML does not support variability management.
Moreover, COSEML model does not point out which
elements are variable and how the variability is realized.
Therefore, it becomes a requirement to find new approaches
or improve COSEML to manage variability at the design
level. Variability modeling has been introduced to
component-oriented development by importing from the
Orthogonal Variability Model (Pohl et al., 2005) and the
feature model. Hence, COSEML with variability
(VCOSEML) is introduced. VCOSEML is a representation
technique specified for variability modeling (Yigit & Dogru,
2015). Therefore, variability can be tracked not only in the
problem space but also in the solution space through
VCOSEML.
Fig. 1 Example component model of VCOSEML
3
Figure 1 shows an example component model of
VCOSEML. In this example, the problem space of the
domain is modeled through abstraction elements. Also, the
solution space is designed by using components and
connectors that represent communications among
components. This modeling view provides the general aspect
of the set of components for the purpose of developing
software products with domain specific components in an
SPL. Moreover, it decreases complexity in managing the
variability in an SPL through assisting the domain engineers
in their analysis of change effects for component selections.
PROPOSED APPROACH
Domain design is highlighted as a crucial concept to
develop reusable and flexible domain specific components.
The main purpose of domain design is to define domain
specific components and their connections. The set of
domain specific components must be reusable and flexible
because all software products of the family are developed
using these components.
The proposed solution is an introductory approach to
building and evolving a reusable infrastructure, which covers
all variability requirements contained in an SPL. The
approach is based on variability specifications that is rooted
in feature models and reflected a variable component model
represented in VCOSEML. An initial set of proposed
components is modified with respect to the variability
constraints and design metrics that regard coupling,
cohesion, and size oriented complexity. Modifications in the
component set continue through iterations until an optimal
set of components is achieved.
Fig. 2 Overview of the proposed solution
The following steps are suggested in defining domain
specific components:
1- Map feature model to abstractions,
2- Embed feature variability in abstractions,
3- Define domain specific components, and
4- Evaluate and revise the component set.
The rest of this section contains explanations of the
recommended steps.
Map Feature Model to Abstractions
The transition process from the feature model in the
domain analysis to the definition of domain specific
components begins with the creation of a VCOSEML model.
The model is created to map the feature model to the
abstractions in VCOSEML. The mapping process from
features to abstractions is a straightforward and concerns
one-to-one relationship between features and abstractions.
Domain engineers manually assign features to abstraction
elements of VCOSEML. The mapping process is carried out
with the tool that can help domain engineers to understand
the complex design of SPLs.
Domain engineers use abstractions of VCOSEML such
as Package, Function and Data for modeling the system
graphically. The Package abstraction illustrates subparts of a
system at the logical level. Function and Data abstractions
represent the details for each subpart of a system.
Embed Feature Variability in Abstractions
We consider that feature variability should be trackable
through the abstractions of VCOSEML model in the design
of components. Determined feature variability during domain
analysis is embedded in the abstractions though the
variability elements of VCOSEML. Variation points,
variants, and variability constraints in a feature model can be
reflected a VCOSEML model. Thanks to the visualization
abilities of VCOSEML, feature variability can be traced at
the design level.
Define Domain Specific Components
The relationship between abstractions and components
are established at this step. While abstractions reside in the
problem space, realizations of the abstractions are part of the
solution space. The abstractions are implemented by
components at the physical level. A top-down approach is
followed for defining components in the domain. The
components that correspond to the abstractions are
determined by applying the following steps:
1- Each variation point in the abstraction corresponds
to at least one component.
2- If a variant excludes another variant at the same
variation point, variants will be mapped to separate
components.
3- If a variant is an alternative to another variant at the
same variation point, variants will be mapped to
separate to components.
4- If a variant requires another variant at the same
variation point, variants will be mapped to the same
component.
5- If a variant requires another variant at a different
variation point, variants will be mapped to different
components, which are linked with connectors.
6- If variants excluding each other require another
variant at the same variation point, the required
variant will be mapped to the individual component
that links with other components by using
connectors.
7- If a variant is optional, it will be mapped to the
component that links with other components, which
contain mandatory variants at the same variation
point, by using connectors.
4
8- If a variant at different variation point is required by
at least two variants at different variation points, the
variant will be mapped to the individual component
that links with other components.
Evaluate Set of Domain Specific Components
The approach suggests that the determined set of domain
specific components should be evaluated in terms of
complexity size, coupling and cohesion metrics. COSMIC is
a method to measure the functional size of a component
(Dumke & Abran, 2011). The studies indicate the suitability
of COSMIC method for measuring functional component
size at the design level. Components in a set are preferred to
be less dependent on each other as much as possible.
Therefore, the determined set of components should be
evaluated considering the low coupling and high cohesion
principles. Coupling between components (Yadav & Tomar,
2014) and average interface complexity of a component-
based system (Kumar et al., 2014) are metrics used for
calculating coupling between components. Moreover,
cohesion between components (Yadav & Tomar, 2014) is a
design metric that can be utilized to compute cohesion for
each component in the set.
The result of measurements is evaluated in terms of
component size, coupling, and cohesion. The set of
components is reviewed in the direction of the results of
measurements. Components having the above average
complexity and dependence on other components are
detected. The component set can be modified by reapplying
the recommended rules of the approach, after considering the
outputs about the evaluations. This process might be
performed in numerous iterations until an optimal set of
components is reached.
CASE STUDY: CLOUD MANAGEMENT SYSTEM
In this section, we conducted a case study to investigate
the validation of the approach. The case study involves a
product family of the cloud management domain. The
software products in the domain provide not only cloud
monitoring but also resource planning for managing cloud
resources. Also, it is planned to optimize the utilization of
cloud resources aspects of performance, cost and energy
consumption.
Domain analysis was conducted before applying the
approach. Domain requirements and feature model were
prepared during the domain analysis process. The feature
model of Cloud Management System is given in Figure 3.
In the first stage of the approach, the feature model was
mapped directly to a VCOSEML model through the
abstractions. After mapping the features to the abstractions,
feature variability (variation points, variants and variability
constraints) was embedded in the VCOSEML model. Then,
we continued the next step of the approach that is the
definition of domain specific components. The set of domain
specific components was determined by applying the
recommended rules. Finally, the set of domain specific
components was modified with respect to the design metric
such as complexity size, coupling, and cohesion. The results
of the first iteration are presented in Table 1.
Fig. 3 Feature model of cloud management system
Table 1 Results of the first iteration
Component
CFP
Coupling
Cohesion
ResourceDiscovery
26
3
1
IaasManager
40
5
0.86
PaasManager
29
3
0.75
SaasManager
25
3
0.75
SystemTracker
35
2
0.66
ApplicationTracker
38
3
0.5
CostTracker
32
2
0.66
EnergyTracker
32
2
0.66
CustomTracker
41
5
0.57
UsageDataManager
42
5
0.80
PerformanceDataManager
47
4
0.75
CostDataManager
38
5
0.80
EnergyDataManager
38
3
0.75
Reporter
50
2
1
Analyzer
87
8
0.44
BillManager
36
1
1
EventManager
88
7
0.43
HealthChecker
40
2
0.66
TroubleShooter
42
1
1
UsageOptimizer
50
3
1
PerformanceOptimizer
36
3
1
CostOptimizer
20
3
1
EnergyOptimizer
20
3
1
5
When we analyzed the outputs of the first iteration, we
detected two anomalous components (Analyzer and
EventManager) in terms of not only complexity size, but also
the dependency of other components. Therefore, the feature
model was reviewed for expanding the features realized by
the determined components. Moreover, the feature variability
is updated according to the emerging features. After updating
the feature model and feature variability, we continued the
second iteration. In the second iteration, the Analyzer was
noticed to require to be decomposed into four
subcomponents (PerformanceAnalyzer, CostAnalyzer,
TrendAnalyzer, WhatIfAnalyzer). Also, EventManager was
divided into three subcomponents (EventLogger,
AlertManager, NotificationManager). At the end of the
second iteration, we reached a more appropriate set of
components in terms of reusability.
CONCLUSION & FUTURE WORK
In conclusion, this paper discussed a systematic
approach based on a set of guidelines, activities, and metrics
for designing of a set of domain specific components. We
also presented the definition, planning, operation, analysis
and interpretation of the experimental study that evaluated
the viability of the domain design approach. Our current
experimentation revealed the usability of this approach. The
techniques were adequate in evaluating the determined set of
components. Also, the suggested steps of the approach
yielded a refined set that makes sense.
Our case study demonstrated the usability of this
approach. Industrial scale case studies are missing until now.
We are planning to improve the approach based on the
experience to be gathered from its usage in real industrial
projects.
REFERENCES
Basili, V., Briand, L., & Melo, W. (1996). How reuse
influences productivity in object-oriented systems.
Communications of the ACM Commun. ACM, 104-116.
Bosch, J. (2000). Design and Use of Software Architectures:
Adopting and Evolving a Product-Line Approach. ACM
Press.
Dogru, A. H., 1999, Component Oriented Software
Engineering Modeling Language: COSEML, Computer
Engineering Department, Middle East Technical
University, Ankara, Turkey.
Dogru, A. H., 2006, Component Oriented Software
Engineering, The Atlas Publications, Dallas, Texas,
ISBN: 0-9778129-0-1.
Dumke, R., & Abran, A. (2011). COSMIC function points
theory and advanced practices. Boca Raton: CRC Press.
Gherardi, L. (2013). Variability Modeling and Resolution in
Component-based Robotics Systems, (February).
Guendouz, A., & Bennouar, D. (2014). Component-Based
Specification of Software Product Line Architecture. In
International Conference on Advanced Aspects of
Software Engineering (pp. 2–4).
Haber, A., Rendel, H., Rumpe, B., Schaefer, I., & Van Der
Linden, F. (2011). Hierarchical variability modeling for
software architectures. In Proceedings - 15th
International Software Product Line Conference, SPLC
2011 (pp. 150–159). doi:10.1109/SPLC.2011.28
Ileri, I., Eroglu, A., & Dogru, A. H. (2013). Component-
Based Variability Modeling. In Society for Design and
Process Science (pp. 55–61).
Kang, K. C., Cohen, S. G., Hess, J. a, Novak, W. E., &
Peterson, A. S. (1990). Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Distribution (Vol.
17). doi:10.1080/10629360701306050
Kumar, S., Tomar, P., Nagar, R., & Yadav, S. (2014).
Coupling Metric to Measure the Complexity of
Component Based Software through Interfaces, 4(4),
157–162.
Pohl, K., Böckle, G., & Van Der Linden, F. (2005). Software
Product Line Engineering. Foundations, Principles, and
Techniques. uwplatt.edu (Vol. 49). doi:10.1007/3-540-
28901-1
Razavian, M., & Khosravi, R. (2008). Modeling variability in
the component and connector view of architecture using
UML. In AICCSA 08 - 6th IEEE/ACS International
Conference on Computer Systems and Applications (pp.
801–809). doi:10.1109/AICCSA.2008.4493618
Svahnberg, M., Gurp, J., & van, Bosch, J. (2001). On the
notion of variability in software product lines.
Proceedings Working IEEE/IFIP Conference on
Software Architecture.
doi:10.1109/WICSA.2001.948406
Yadav, K., & Tomar, P. (2014). Design of Metrics for
Component-Based Software System at Design Level.
International Journal of Engineering and Technical
Research, 2(4), 285–289.
Yigit, I. O., & Dogru, A. H., (2015). Yazılım Urun
Hatlarinda Alana Ozgu Bilesenleri Belirleme Yaklasimi.
Proceedings of the 9th Turkish National Software
Engineering Symposium.
doi:10.1109/WICSA.2001.948406
Van Der Linden, F., Schmid, K., & Rommes, E. (2007).
Software Product Lines in Action: The Best
Industrial Practice in Product Line Engineering.
SpringerVerlag Berlin Heidelberg. doi:10.1007/978-
3-540-71437-8Arpen, A. (2013). Another title.
Journal of Science, 1(4), PP:10-22.