Requirements for Modeling Software Product Lines
Keywords: Software Product Lines, Object-Oriented Analysis and
Design
Classification: PhD work, first year
1 Introduction
Today software development produces two types of software: individual software
and standard software. Individual software is built on special order and
tailored to the specific requirements of one customer. Standard software,
on the other hand, is supposed to meet the needs of many customers. Once
developed standard software is produced in a mass production process by
duplicating the distribution medium. The main problems of both types of
software are: individual software causes high development costs because
it takes a long time to implement the software; standard software is cheaper,
but seldom meets exactly the customers' requirements.
A solution to these problems is batch production of software systems:
given a customer's requirements, a generator automatically assembles a
tailored system from prefabricated components. Some advantages of this
method are: short production times, resulting systems are cheaper than
individual software, the functionality of the systems match the customers'
requirements better than standard software, as a consequence users need
fewer training hours and the systems consume less resources (cf. Figure
1). The economic setting for batch production is a product line. A
product line describes a "group of products that are closely related because
they function in a similar manner" [10, p.
298]. Software product lines are "developed from a common set of core assets"
[3, p. 3].
Figure 1: Benefits of product lines for customers
One important task in the development of a software product line is
the design of the product line model, i.e. modeling the reusable assets.
This paper examines, which methodical support is necessary to design product
line models, in particular object-oriented product line models. Additionally,
a short overview of existing object-oriented product line methods is given.
The paper concludes by identifying future directions of this work.
2 Requirements for
Product Line Methods and Models
A product line model describes a family of related software systems and,
thus, expresses the commonalities and differences (or variabilities) of
all family members. One member may differ from another one in both functional
and technical requirements, for example business processes and objects
or distribution and persistence mechanisms.
Various stakeholders make use of a product line model:
-
marketeers who sell systems built from the product line
-
customers who would like to buy such a system
-
developers who model and implement the product line
-
administrators who install and run the system
In the following requirements for product line methods and models are derived
from the point of view of these four stakeholders.
2.1 From the Marketeers' and Customers' Point of View
Marketeers and customers are primarily interested in the functionality
or features of a product line. With respect to each stakeholder the model
of a product line has to answer either the question "What functionality
(at which price) can I offer the customer?" or "What are the features I
can choose from to configure my system?"
Requirement 1: A product line method needs a systematic
procedure to identify and describe the features of a product line.
While configuring a system, features cannot be chosen arbitrarily. Rules
in the model determine if two features can be combined in a system and,
when one feature is chosen, if there are other features that must also
be chosen.
Requirement 2: A product line model must define dependencies
between features.
To describe features and their interdependencies, feature diagrams [9]
and use cases [7] have proven to be useful.
2.2 From the Developers' Point of View
Developers refine the features of a product line into a design and finally
into an implementation. A key task within this process is to manage the
inherent complexity of product lines, so that they remain understandable
and maintainable. Therefore, it is necessary to connect features with their
refined design elements (traceability). For example, features may link
to the following elements of the UML (Unified Modeling Language): activities,
packages, classes, attributes, or operations.
Requirement 3: A product line model must link features
with their respective design elements.
Systems built from a product line differ in their static structure as well
as in their runtime behavior. Hence, variability can be found not only
in class diagrams but also in activity and sequence diagrams.
Requirement 4: A product line model must consider both
structural and behavioral variability.
2.3 From the Administrators' Point of View
Administrators install and run a system built from a product line, so they
are mostly interested in that the system consumes not much resources and
users need few training hours. A product line system can fulfill these
requirements by implementing and offering users only those features that
the customer has chosen to be part of the system. This is called zero-overhead
rule [4].
Requirement 5: A product line model must be modularized
in a way, so that the generator can produce lean, zero-overhead systems.
To achieve this, the principle "separation of concerns" [5,
p. 211] has to be applied while modeling product lines. In the context
of product lines, the concerns are features. Therefore, in addition to
decompose a product line by objects, the product line has to be decomposed
into a second dimension---by features. Tools are required to help maintaining
the consistency of the resulting product line model.
3 Overview of Object-Oriented
Product Line Methods
By the time of writing, two object-oriented product line methods exist:
FeatuRSEB and KobrA. Both use an extended version of the UML as notation
for product line models.
FeatuRSEB [6] is the successor of the Reuse-Driven
Software Engineering Business (RSEB) [8]. Based
on the Object-Oriented Software Engineering Method [7],
RSEB defines processes and methods to develop product lines. FeatuRSEB
integrates concepts and diagrams from the Feature-Oriented Domain Analysis
Method [9] into RSEB.
KobrA [1] is an instance of PuLSE, the Product
Line Software Engineering Methodology [2]. PuLSE
defines a process component and a number of abstract technical components
to develop product lines. KobrA refines the abstract components of PuLSE,
so that product lines can be developed using object-oriented techniques.
4 Summary and Outlook
The paper has derived requirements for product line methods and models
from the point of view of various stakeholders. In addition, two object-oriented
product line methods were briefly introduced.
Next in the PhD work is the evaluation and assessment of these methods
with respect to the identified requirements. The aim is to improve and
extend those methods and, finally, to integrate them into one coherent
method.
References
-
[1]
-
Colin Atkinson, Joachim Bayer, and Dirk Muthig. Component-based product
line development: The KobrA approach. In Proceedings of the 1st Software
Product Line Conference, 2000. (To appear.)
-
[2]
-
Joachim Bayer, Oliver Flege, Peter Knauber, Roland Laqua, Dirk Muthig,
Klaus Schmid, Tanya Widen, and Jean-Marc DeBaud. PuLSE: A methodology to
develop software product lines. In Proceedings of the 5th Symposium
on Software Reusability, pages 122-131, 1999.
-
[3]
-
Paul Clements and Linda Northrop. A Framework for Software Product Line
Practice, Version 2.7, July 1999. Available at http://www.sei.cmu.edu/plp/framework.html.
-
[4]
-
Krzysztof Czarnecki, Ulrich W. Eisenecker, and Patrick Steyaert. Beyond
objects: Generative programming. Position paper at the ECOOP '97 Workshop
on Aspect-Oriented Programming, 1997. Available at http://www.prakinf.tu-ilmenau.de/~czarn/aop97.html.
-
[5]
-
Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall,
Englewood Cliffs, NJ, 1976.
-
[6]
-
Martin L. Griss, John Favaro, and Massimo d'Alessandro. Integrating feature
modeling with the RSEB. In P. Devanbu and J. Poulin, editors, Proceedings
of the 5th International Conference on Software Reuse, pages 76-85.
IEEE Computer Society Press, 1998.
-
[7]
-
Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard.
Object-Oriented
Software Engineering: A Use Case Driven Approach. Addison-Wesley, 1992.
-
[8]
-
Ivar Jacobson, Martin Griss, and Patrik Jonsson. Software Reuse: Architecture,
Process and Organization for Business Success. Addison-Wesley, 1997.
-
[9]
-
Kyo Kang, Sholom Cohen, James Hess, William Novak, and Spencer Peterson.
Feature-oriented domain analysis (FODA) feasibility study. Technical Report
CMU/SEI-90-TR-021, Software Engineering Institute, Carnegie Mellon University,
Pittsburgh, PA, November 1990. Available at http://www.sei.cmu.edu/domain-engineering/FODA.html.
-
[10]
-
Philip Kotler and Gary Armstrong. Principles of Marketing. Prentice-Hall,
Englewood Cliffs, NJ, 7th edition, 1996.
kai.boellert@theoinf.tu-ilmenau.de
detlef.streitferdt@theoinf.tu-ilmenau.de
Last modified: 13 July 2000