Conference PaperPDF Available

DEFINITION OF DOMAIN SPECIFIC COMPONENTS IN SOFTWARE PRODUCT LINES BASED ON FEATURE VARIABILITY

Authors:

Abstract and Figures

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.
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. 24).
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. 150159). 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. 5561).
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),
157162.
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.
801809). 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), 285289.
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.
ResearchGate has not been able to resolve any citations for this publication.
Book
Full-text available
Designed to conform to the ISO/IEC standard 14143, the Common Software Measurement International Consortium (COSMIC) Function Point method has become the major estimation technique based on international standards for building software-intensive systems. COSMIC Function Points: Theory and Advanced Practices supplies a cutting-edge look at current and emerging practices in the international software measurement community. The editors have assembled an international panel of experts who detail the steps for measuring the functional size of software and developing project estimates with improved accuracy. They explain how to evaluate and compare systems to improve software reuse and development. Touching on the essential aspects of the next generation of functional size measurement methods, the book delineates best estimation and measurement practices as well as the development of benchmarks for quality improvement, including Six Sigma. This complete resource covers software measurement and estimation methods and practices for embedded systems, business applications, communications software, and control systems. Each chapter supplies the practical understanding required to create, implement, standardize, distribute, and adapt functional size measurement and project estimation to virtually any software context.
Conference Paper
Full-text available
zetçe. Bu bildiride, yazılım ürün hatlarında değişkenlik modelini dikkate alarak nasıl alana özgü bileşenlerin belirleneceğine yönelik bir yaklaşım anlatılmaktadır. Yazılım ürün hatlarında yazılım ürünleri önceden geliştirilmiş alana özgü bileşenlerin bir araya getirilmesi ile oluşturulmaktadır. Geliştirilecek her bir yazılım ürününde alana özgü bileşenleri yeniden kullanabilmek için bu bileşenleri çalışılan alandaki ortaklıkları ve değişkenlikleri göz önüne alarak belirleyip geliştirmek gerekmektedir. Önerilen yaklaşımla alan analizi aşamasında tanımlanan alandaki ortaklıklar ve değişkenlikler doğrudan tasarım aşamasına taşınmaktadır. Tasarım aşamasında yaklaşımda anlatılan adımlar izlenerek alana özgü bileşenler belirlenmektedir. Bu yaklaşımın uygulanması sonucunda alana özgü yeniden kullanıma uygun bir bileşen kümesinin ortaya çıkarılması planlanmaktadır. Bu sayede ortaya çıkan bileşenler yeniden kullanılarak hızlı ve etkin bir şekilde, kaliteli yazılımların geliştirilmesi hedeflenmektedir.
Thesis
Full-text available
The routine use of existing solutions in the development of new systems is a key attribute of every mature engineering discipline. Software reuse is indeed the state of the practice in various application domains, such as telecommunications, enterprise resource planning, automotive and avionics. One of the key factors that enable the development of reusable software is the flexibility, which is the ease with which a system or a component can be modified to be used in applications or environments that are different from those for which it was originally designed. In robotics software reuse is still at an early stage. This is mainly due to the complexity and the huge variability that characterize this particular domain. The complexity makes the development of reusable software a task that requires advanced software engineering techniques, which are not always mastered by robotics experts. The variability of hardware, environment and task instead makes frequent and quick the changes that occur in the application requirements. The research documented in this thesis investigates new approaches for the development of component-based robotics systems, which are flexible enough to accommodate the changes that are likely to occur to the software requirements. Addressing the flexibility of robotics software systems and variability modeling and resolution are thus the main topics of this document. The first contribution of this thesis is a software development process that explicitly takes into account the variability. The process is based on two of the most recent and promising approaches to software reuse, namely the Software Product Lines (SPL) and the Model Driven Engineering (MDE). This thesis describes the process, illustrates a set of models and tools that have been developed for supporting it, and exemplifies its application by means of the robust navigation case study. The second contribution instead consists of a set of tools and approaches that have been designed in order to develop component-based system with an high level of flexibility and reusability. In particular this approaches focus on addressing the software framework variability and the hardware variability.
Conference Paper
Full-text available
Hierarchically decomposed component-based system development reduces design complexity by supporting distribution of work and component reuse. For product line development, the variability of the components to be deployed in different products has to be represented by appropriate means. In this paper, we propose hierarchical variability modeling which allows specifying component variability integrated with the component hierarchy and locally to the components. Components can contain variation points determining where components may vary. Associated variants define how this variability can be realized in different component configurations. We present a meta model for hierarchical variability modeling to formalize the conceptual ideas. In order to obtain an implementation of the proposed approach together with tool support, we extend the existing architectural description language MontiArc with hierarchical variability modeling. We illustrate the presented approach using an example from the automotive systems domain.
Article
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.
Book
Software product lines represent perhaps the most exciting paradigm shift in software development since the advent of high-level programming languages. Nowhere else in software engineering have we seen such breathtaking improvements in cost, quality, time to market, and developer productivity, often registering in the order-of-magnitude range. While the underlying concepts are straightforward enough - building a family of related products or systems by planned and careful reuse of a base of generalized software development assets - the devil can be in the details, as successful product line practice can involve organizational change, business process change, and technology change. The authors ideally combine academic research results with industrial real-world experiences, thus presenting a broad view on product line engineering so that both managers and technical specialists will benefit from reading it. After presenting a common framework for the description of the industrial case studies, they capture the wealth of knowledge that eight companies have gathered during the introduction of the software product line engineering approach in their daily practice. After reading this book, you will understand all the relevant aspects, regarding business, architecture, process, and organizational issues, of applying software product line engineering. If you consider using a product line approach in your organization, or if you want to improve your current practices you will find a rich set of useful information at your fingertips - from practitioners to practitioners. © Springer-Verlag Berlin Heidelberg 2007. All rights are reserved.
Book
This textbook addresses students, professionals, lecturers and researchers interested in software product line engineering. With more than 100 examples and about 150 illustrations, the authors describe in detail the essential foundations, principles and techniques of software product line engineering. The authors are professionals and researchers who significantly influenced the software product line engineering paradigm and successfully applied software product line engineering principles in industry. They have structured this textbook around a comprehensive product line framework. Software product line engineering has proven to be the paradigm for developing a diversity of software products and software-intensive systems in shorter time, at lower cost, and with higher quality. It facilitates platform-based development and mass customisation. The authors elaborate on the two key principles behind software product line engineering: (1) the separation of software development in two distinct processes, domain a d application engineering; (2) the explicit definition and management of the variability of the product line across all development artefacts. As a student, you will find a detailed description of the key processes, their activities and underlying techniques for defining and managing software product line artefacts. As a researcher or lecturer, you will find a comprehensive discussion of the state of the art organised around the comprehensive framework. As a professional, you will find guidelines for introducing this paradigm in your company and an overview of industrial experiences with software product line engineering.