=Paper=
{{Paper
|id=Vol-1294/paper11
|storemode=property
|title=Component-Based Specification of Software Product Line Architecture
|pdfUrl=https://ceur-ws.org/Vol-1294/paper11.pdf
|volume=Vol-1294
|dblpUrl=https://dblp.org/rec/conf/icaase/GuendouzB14
}}
==Component-Based Specification of Software Product Line Architecture==
https://ceur-ws.org/Vol-1294/paper11.pdf
ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework
Component-Based Specification of
Software Product Line Architecture
Amina Guendouz Djamal Bennouar
CS Department, Saad Dahlab University CS Department, Akli Mohand OulHadj University
Blida, Algeria Bouira Algeria
guendouz.amina@yahoo.fr dbennouar@gmail.com
Abstract – Software product lines have known an increasing use over the last years, taking advantage
from the important benefits they may bring to software development in terms of time, cost and effort.
However, product line approaches remain immature owing to the fact that they still base on traditional
design concepts of software engineering which are not adequate to the basic principles of software
product lines engineering. Considering that software product lines are inspired by industry where
production activity is based on assembling certified components, and in light of the recent progress in
Component-based development field, we believe that integrating these two approaches will bring
significant benefits to software development. This paper describes a new approach for Component-
Based Product Lines engineering focusing on the Component-Based specification of the Product Line
architecture. The aim is to overcome the shortcomings of traditional product lines by unifying the
strengths of two complementary approaches, and to facilitate the derivation process since applications
will be produced by the simple composition of existing components.
Keywords – Software Product Lines, Component-Based Development, Reuse, Components, Variability,
IASA.
Software Product Line approach intends to
1. INTRODUCTION adapt to the software development, the
principles that we find in the automotive,
Software Product Lines are emerging as a aeronautics and electronics industries.
viable and important development paradigm Production in these industries is organized into
allowing companies to realize order-of- ranges with similar parts and offering a
magnitude improvements in time to market, number of options. For example, in automotive
cost, productivity, quality, and other business industry, various car models come out the
drivers. A software product line (SPL) is “A set same assembling chains using the same
of software-intensive systems sharing a chassis, the same engines and the same test
common, managed set of features1 that satisfy plans. The aim is to improve productivity,
the specific needs of a particular market decrease time to market, and reduce
segment or mission and that are developed production, maintenance and test costs. The
from a common set of core assets 2 in a idea is to transpose the principles of
prescribed way” [1]. manufacturing of these industries in software
development, to benefit from the before-
1
mentioned advantages.
A feature is an end-user visible characteristic of a
system [4]. Although, the principles of software product
2
lines are inspired by industry where production
A reusable artifact or resource that is used in the activity is based on assembling certified
production of more than one product in a software components, most of software product lines
product line. A core asset may be an architecture, a today are based on traditional design concepts
software component, a domain model, a
of software engineering such as modular
requirements statement or specification, a
document, a plan, a test case, a process
design and object-oriented design. These
description, or any other useful element of a
design concepts are not able to support the
software production process [1]. assembly of certified components which
International Conference on Advanced Aspects of Software Engineering
ICAASE, November, 2-4, 2014, Constantine, Algeria. 100
ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework
makes the derivation and maintenance while maintaining diversity between products.
processes difficult to perform. Furthermore, This is ensured by involving “Variability
both of software product lines and component management” activity along all the software
based development promote reuse; putting development process.
them together will bring significant benefits to
Introducing a new CBPL approach must take
software development.
into account these two aspects. It must be
SPL improve reuse while maintain diversity able to reconcile between the two
between products. In most cases, software development processes (component-based
components intended for reuse must be process and SPL process) on the one hand,
adapted to meet specific requirements of and enable the effective management of
customers. If flexibility is not considered since variability on the other hand. In next
the early development process phases, subsections we present how our approach
developers will meet lot of difficulties in considers these two aspects.
adaptation step, which lead them to leave
these components even they will have to 2.1. COMPONENT BASED PRODUCT LINE
redevelop components from scratch. SPL ENGINEERING
simplify adaptation phase by involving Software product line engineering relies on a
“Variability management” activity along all the fundamental distinction of development for
software development process.
reuse and development with reuse [3], [4].
However, traditional component-based Development for reuse or “Domain
approaches do not support variability engineering” consists in developing core
management. It becomes necessary to assets through the domain analysis, domain
establish new approaches or enhance existing design and domain implementation processes.
component-based approaches in order to Development with reuse or Application
allow an effective variability management. In engineering consists in developing the final
this paper, we propose an approach that products, using the core assets and the
integrates SPL engineering and component- specific requirements expressed by the
based engineering, aiming to unify the power customers.
of these two approaches. Firstly, we will
The development process of CBPL we
present the development process of propose (figure 1) is an integration of the
component-based SPL (CBPL). Then, we will development process of SPLs [4] and the
show the extension of a component-based
component-based development process [5].
approach (IASA [11]) in order to allow the
modeling of variability in CBPL. The proposed Unlike to the traditional SPL engineering, the
approach is, afterward, supported by a case base of core assets obtained from CBPL
study. engineering relies mainly on software
architecture (reference architecture,
The remainder of this paper is organized as
refinement of components and reusable
follows: Section 2 introduces the proposed
components...). While, its difference compared
approach. Section 3 shows the specification of to the traditional Component-based
a CBPL for e-Meeting applications. Section 4
development is the introduction of variability
reports the related work and comments on it, management activity. Since variability is
while Section 5 summarizes the paper and
handled from the early stages of development,
outlines future work. reusable components obtained from domain
engineering process do not have to be
2. COMPONENT BASED PRODUCT LINES adapted to the specific needs of final
applications, which make the step of
The crucial aim of introducing product line application assembly easier and faster.
approach in software engineering is to improve
reuse. SPL differs from traditional reusing Domain engineering consists of three activities
approaches in two ways: the first one is that that are Domain analysis, Product-line
SPL approach systematizes reuse throughout architecture design and Components
all the software development process: from implementation (Figure 1). The purpose of this
requirements engineering to the final code and sub-process is to produce the reusable core
test plans, in contrast of traditional software assets and to provide the effective means that
reuse approaches which exploit reuse only at help in using these core assets to build new
design and coding phases [2]. The SPL products within the SPL. The main outputs of
engineering process is thus decomposed into this process are: reference requirements,
two sub-processes (section 2.1): development reference architecture and reusable
for reuse and development with reuse [3], [4]. components.
The second one is that, SPL improve reuse
International Conference on Advanced Aspects of Software Engineering
ICAASE, November, 2-4, 2014, Constantine, Algeria. 101
ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework
Figure 1: Component-Based Product Line engineering.
Application engineering consists in developing main objectives are: to make the variability
the final products, using the core assets and explicit in the early stages of the project, and
the specific requirements expressed by to reduce the complexity related to variability
customers. This sub-process consists of three management throughout the development
steps: Application analysis, Application process [2],[10].
architecture design for the specific application
and finally Application assembling. Each step For the modeling of variability in the
is facilitated by the reuse of the outputs from architecture view, we have chosen to extend
the previous process. The result of application the component-based model IASA (Integrated
engineering is an application ready to be used. Approach to Software Architecture) [11]. IASA
was used to realize complex e-Government
2.2. VARIABILITY MODELING IN CBPLs software system, and was proved as a clear
and easy specification language to design at a
Variability management is a key activity that high level of abstraction using Aspect Oriented
usually affects the degree to which a SPL is approach [12] [13].
successful [6]. Variability refers to the ability of
an artefact to be configured, customized, 2.2.1. Architecture design with IASA
extended, or changed for use in a specific
The design according to IASA approach uses
context [7], [8], [9]. This variability must be
a component-oriented process which proceeds
identified, represented, exploited,
implemented, evolved, etc. – in one word by successive refinement. An IASA
component is seen from the outside as a
managed – throughout software product line
engineering [3]. black-box that communicates with the external
world through Ports [14], which define the
After being identified, variability must be services it can provide or require. The internal
represented. The second step in managing view of a primitive component is inaccessible,
variability is to model it in all software while the structure of a composite component
artefacts. Modeling variability is a technique is well defined, it consists of three parts:
used firstly to document the variability and Operative Part, Aspect Part, and Control Part.
secondly to reason about the variability. Its Figure 2 sets out the basic notations of IASA.
International Conference on Advanced Aspects of Software Engineering
ICAASE, November, 2-4, 2014, Constantine, Algeria. 102
ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework
Figure 2: Basic notations of IASA.
2.2.2. Variability modeling with IASA
Since IASA have not been developed to
capture all types of variability explicitly, we
propose to extend it in order to meet the needs
of SPL engineering. We define three types of
variability in architecture: Mandatory, Optional
and choice.
Mandatory and Optional elements: Each
element in the architecture can be mandatory
or optional according to the context in which it
will be used. In order to represent explicitly Figure 3: Component choice.
these types of variation, Components and
Connectors are annotated by: «Mdr» and The number of components that can be
«Opt» which means respectively: Mandatory supported by the connector is expressed by a
and Optional. cardinality [n..m], such as:
Considering that interfaces in the same n=m if the type of the relation is AND;
component can be optional if they are not m>=n if the type of the relation is OR;
needed in some contexts, variability in n=m=1 if the type of the relation is XOR or
interfaces is represented as follow: Alternative.
Mandatory provided interface
Mandatory required interface
Optional provided interface
Optional required interface
Choices: We distinguish between two types of
choices:
1. Component choice: When there are a
variety of implementations for the same
component, the variable component is
annotated by: «Choice» and related
through the same interface to all its variants
as shown in figure 3.
2. Connector choice: When a component is
related to a variable set of components, the
relation between these components
becomes a connector annotated by: Figure 4: Connector choice.
«Choice» and related with different
interfaces to each variant as shown in
figure 4.
International Conference on Advanced Aspects of Software Engineering
ICAASE, November, 2-4, 2014, Constantine, Algeria. 103
ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework
Figure 5: Business feature diagram for e-Meeting product line.
between the SPL members. To document the
3. CASE STUDY: E-MEETING CBPL common and variable features of our product
line, we have used the Feature Model. The
In this section we apply our approach in a Feature Model is the first language dedicated
specific domain which is: E-Meeting to the modeling of variability; it was first
applications. E-meeting applications exhibit an introduced in the Feature-Oriented Domain
excellent solution to overcome the problems Analysis (FODA) method [15]. It has known a
that can occur when organizing a face to face broad use in the field of SPLE, since it is a
meeting namely: distance, costs and simple and easy to use language in
availability. Using online meeting technologies comparison with other more complex modeling
allow us to simplify the meeting organization languages such as: UML and BPMN. The
processes, save time and displacement feature model is generally described by a
expenses. hierarchy of the set of features of a system or
The concept of meeting can be found in what is called feature tree [4]. Figures 5 and 6
various fields. For instance: meetings for year- show a part of the feature model of our CBPL.
end deliberation, meetings of a Scientific For the notation, we must note that all of AND,
OR, XOR variability types are expressed
Council, meetings of elected members of an
APC3, APW 4 or APN5, meetings of business through cardinality (as shown in section 2) to
leader, etc. E-meeting applications designed avoid cluttering the diagram with more
for these various types of meetings share notations, for us cardinality is sufficient to
many similarities and are distinguished by represent all kinds of choices.
some particular aspects. It becomes very The constructed feature model is divided into
important to take advantage of similarities three diagrams according to the type of
between these applications to develop a family features it includes: Business features,
of e-meeting applications. This family of technical features, and implementation
product (SPL) once implemented is able to features. Features in the first diagram called
produce for each meeting type, the appropriate Business features (Figure 5), represent the
software in a very short time. In this case study Business functionalities provided by the
we will focus on the component-based system. This diagram shows that the main
specification of the e-Meeting SPL. Next sub- features of an e-Meeting application are
sections describe the artefacts obtained from “Create meeting” and “Manage meeting”.
Domain analysis and Product-line architecture
design steps. Each e-Meeting application must allow at least
the planning of a meeting and the generation
3.1. Domain analysis of reports. However, in some cases a prior
step can be needed before performing a
The goal of domain analysis is to extract and meeting which is: the discussion of the
document the similarities and variations meeting item, modeled by “Request for
meeting” in the Feature diagram.
3
An APC is the elected assembly which governs a “Management of recurring items” feature can
commune (baladiyah). be included if the customer is interested to the
4
An APW is the elected assembly which governs a
history of previously treated items, there
wilaya (province).
5
An APN is the national elected assembly.
results, statistics about them and so on.
International Conference on Advanced Aspects of Software Engineering
ICAASE, November, 2-4, 2014, Constantine, Algeria. 104
ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework
Figure 6: Technical feature diagram for e-Meeting product line.
“Configuring” a Meeting is an optional feature “Meeting tools” might include “Attendance
that consist in preparing the application by management”, “Participation management”,
fixing the meeting type (video, audio, chat...), “Schedule manage”… the application can
in addition to the needed tools to run a eventually be extended by new tools if
meeting according to the user’s requirements. required.
Figure 7: Reference architecture of e-Meeting product line.
International Conference on Advanced Aspects of Software Engineering
ICAASE, November, 2-4, 2014, Constantine, Algeria. 105
ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework
The second diagram Figure 6 represents the and audio files). Those features could be
technical features; it means features that do found in any e-Meeting application, but not all
not reflect the business aspect of e-Meeting of them are mandatory.
applications. Technical features encompass
features related to the application The third diagram represents the
implementation features of the system it
(configuration, UI management), features
means implementation details at lower levels.
related to users (Accounts management,
Roles management, Authentication), and We do not show this diagram in the paper
owing to space reasons.
features related to files (including: text, video
Figure 8: Variability model for “Meeting_Configuration” component.
3.2. Product-line architecture design assembly, configuration or might be delayed
until runtime, this leads developers to have
The purpose of Product-line architecture more flexible applications and thus better
design is to establish the generic software customer satisfaction.
architecture of the product line. Variability
identified during domain analysis must be
explicitly specified in the product-line 4. RELATED WORK
architecture. To design the reference
The most known approaches that integrate
architecture of our composite SPL we have Software Product Line engineering and
used the notation presented in section 2. The Component-based engineering are: Kobra [17]
reference architecture of our e-Meeting
and Koala [18] [19]. The basic goal of Kobra is
product line is reported in figure 7. The
to provide a systematic approach to the
mandatory components that must be included
development of component-based application
in each member of the SPL are annotated by
frameworks. Nevertheless, Kobra approach
«Mdr»(Meeting_Management,Meeting_Planni
interest to the internal structure of components
ng, Roles_Management…), while those which
for which it uses UML modeling. Therefore,
are optional are annotated by «Opt»
this approach cannot be compared to ours.
(Items_Management,
Meeting_Configuration…). Koala is a component model based on an
architectural description language used to
Figure 8 shows the refinement of the
build a large diversity of products from a
“Meeting_Configuration_Cmp”. This latter can
repository of components. Its aim is to manage
be connected to (can use) no or many tools
the growing complexity and diversity of
components(Attendance_Cmp,Participation_C
software in consumer electronics products.
mp, Schedule_Cmp, FilesManage_Cmp). The
Various concepts are used in the koala
choice connector “Meeting_tools_Cnt” allows
components models, like interfaces,
us to represent this type of variability. The
connectors, subcomponents and compound
binding time 6 of this variability can be: design,
6
Is an attribute of variation points and/or variability decisions to later stages in the software
technique used to delay the architectural design development process [16].
International Conference on Advanced Aspects of Software Engineering
ICAASE, November, 2-4, 2014, Constantine, Algeria. 106
ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework
components. Koala allows the modeling of [4] P. Klaus, B. Günter and F. van der Linden,
variability related to interfaces (optional Software Product Line Engineering:
interfaces) and connections between Foundations, Principles, and Techniques,
interfaces (switch). However, the model Springer, 2005.
proposed by Koala does not cover all types of [5] S. Roger Pressman, “Software engineering:
variability that can be found and must be a practitioner’s approach”, Edition: 5,
explicitly defined in a SPL, such as: mandatory McGraw-Hill Higher Education, June 2000.
or optional components, AND, OR, XOR [6] L. Chen, M.A. Babar, A. Nour, “Variability
Management in Software Product Lines: A
relations… Furthermore, Koala consider
Systematic Review,” SPLC, San Francisco,
variability binding only at configuration time, California, 2009.
while SPL engineering allows several binding [7] B. Felix and C.C. Paul, “Variability in
times, according to the context, ranging from Software Product Lines”, technical report
design to configuration and runtime [16]. CMU/SEI, 2005.
[8] G. Jilles van, B. Jan, S. Mikael , “On the
Notion of Variability in Software Product
5. CONCLUSION Lines”, WICSA, 2001.
The work presented in this paper aims to [9] S. Mikael, G. Jilles van, and B. Jan, “A
reach a high level of reuse that can be taxonomy of variability realization
obtained through the integration of two techniques”, Software Practice and
approaches: Software product lines and Experience, 2005.
[10] M. Andreas, P. Klaus, H. Patrick, S. Pierre-
Component-based development. Each of
Yves, S. Germain, “Disambiguating the
these approaches promotes reuse at different Documentation of Variability in Software
granularity levels. Component-based Product Lines: A Separation of Concerns,
development supplies technologies for reuse Formalization and Automated Analysis”,
in the small, while Software product line 15th IEEE International In Requirements
approach intends reuse in the large. Putting Engineering Conference, 2007.
them together allow us to reach large scale [11] B. Djamal, “The Integrated Approach to
reuse and flexibility at the same time. Software Architecture”, Ph.D. Thesis, Ecole
Moreover, Component-based development Supérieure d’Informatique, Oued Smar,
can overcome the lack of maturity in SPL Algiers (in French), 2009.
engineering by providing efficient technologies [12] B. Djamal, S. Abdelfettah, “The Design of
of development. an eGovernment Application Using an
Aspect Oriented Software Architecture
Since our approach needs more space to be Approach”, AOSA conference, 2009.
well define, this paper presented the outlines [13] B. Djamal, H. Abderrezak, S. Abdelfettah,
of the proposed approach, mainly: the “The Design of A Complex Software System
development process and the Component- Using A Software Architecture Approach”,
based model. The paper presents also a case ACIT, 2008.
study for an ambitious field (e-Meeting) aiming [14] B. Djamal, T. Khammaci, H. Abderrezak, “A
to validate the proposed approach. The new approach for component’s port
designed e-Meeting reference architecture modeling in software architecture”, In:
represents a framework for all foreseeable e- Journal of System and Software, Elsevier,
Meeting applications and can be extended to Volume 83 Issue 8, August, 2010.
cover specific requirements if needed. Since, [15] K. Kang, S. Cohen, J. Hess, W. Nowak, and
software can be quickly derived from a CBPL S. Peterson, “Feature- Oriented Domain
by the simple composition of existing Analysis (FODA) Feasibility Study,”
components; the activity of deriving new Technical Report CMU/SEI-90-TR-21, 1990.
members in a CBPL can be greatly automated. [16] C. Rafael, B. Jan, “Binding Time and
Evolution, Systems and Software Variability
The automation of applications derivation step Management”, pp 57-73, Springer, 2013.
is an important perspective of our work. [17] A. Colin, B. Joachim, M. Dirk, “Component-
Based Product Line Development: The
KobrA Approach”, software Product Line
6. REFERENCES Conference, 2000.
[1] M. N. Linda, C. C. Paul, “A Framework for [18] O. Rob van, “The Koala component model
Software Product Line Practice”, Version for consumer electronics software”, Philips
5.0 (online), http://www.sei.cmu.edu/. Research Eindhoven, IEEE Computer
[2] C. Jean, “Les lignes de produits logiciels 33(3), MAR 2000.
Réutilisation et variabilité ”, Publication [19] A. Timo, S. Timo, and M. Tomi, “A Koala-
périodique de Smals, Juin 2009. Based Approach for Modelling and
[3] F. van der Linden, S. Klaus, R. Eelco, Deploying Configurable Software Product
“Software Product Lines in Action: The Best Families”, PFE-5, 2004.
Industrial Practice in Product Line
Engineering”, Springer, 2007.
International Conference on Advanced Aspects of Software Engineering
ICAASE, November, 2-4, 2014, Constantine, Algeria. 107