Introducing Separation of Concerns to Product Line Engineering

Joachim Bayer
Fraunhofer Institute for Experimental Software Engineering (IESE)
Sauerwiesen 6
D-67661 Kaiserslautern, Germany
bayer@iese.fhg.de http://www.iese.fhg.de/Staff/bayer/

Keywords: Separation of Concerns, Product Line Engineering, Product Line Infrastructures

Classification: Ph.D. Proposal accepted, Planned Submission in Winter 2001/2002

1 Introduction

Product line engineering aims at improving development efficiency for families of related systems by facilitating large-scale reuse. This is achieved with a reuse infrastructure that can be used to derive the product line members. The infrastructure contains all assets that are used to construct, use, and evolve the product line. These assets contain aspects that are common to all product line members and aspects that vary among them. Such an infrastructure can only be used coherently when all known forces that influence the product line infrastructure are modeled explicitly. Separation of concerns is an approach that has been promoted for single system development to achieve such an explicit handling of forces.
The idea of separation of concerns is to describe and handle the important and critical aspects of a software system separately. This leads to reduced complexity in the description of the individual aspects. Separation of concerns during software development is realized by having a set of development models, in which each model describes the software system from a different perspective. The models together provide a view on the system that contains more information than the added information of the individual models. It improves the comprehensibility of the system, supports evolution and maintenance, enables consistency checking, facilitates reuse, and enables traceability among models.
The need for separation of concerns has long been recognized in software engineering. The concept was introduced at different software development life cycle stages. In its beginning, separation of concerns was realized at code level and expressed as the need for modularization [9]. Many approaches for separation of concerns have been proposed. Recent examples are Aspect-Oriented Programming [6], Subject-Oriented Programming [5], and Multi-Dimensional Separation of Concerns [12]. Other approaches for separation of concerns include view based requirements engineering (e.g., in [8], [11]), architectural views (the most influencing paper here was [7]), as well as object-oriented analysis and design (Catalysis [4] provides means to compose design models; in OORAM [10] concerns are modeled as roles that can be synthesized).
However, the existing approaches for separation of concerns do not take into account the special situation that product line engineering methods impose [2]. Because product line engineering is concerned with the development of a reuse infrastructure that encompasses numerous products, it is a long-term investment that has numerous stakeholders over time. The stakeholders all have concerns on the product line infrastructure, some of which might contradict each other. Because a product line infrastructure encompasses the full life cycle of a product line, concerns must be usable and reusable at different development stages. Additional problems arise when the set of models used in the product line infrastructure are customized, as it is the case in PuLSE, the product line engineering approach developed at IESE [3]. Its customization includes the definition of model sets for the different development stages. Therefore, separation of concerns must provide the possibility to choose the used paradigm and set of models to model the concerns.

2 Goal of the Ph.D. Work

The goal is to define and validate techniques for the separation of concerns that is devised to support product line engineering and fulfills the following requirements:

It must be applicable to the product line full life cycle, that is, it must be able to reuse concerns and to capture different definition for concerns for the different life cycle stages
It must be fully customizable, that is, it must be independent of the used model set and of the underlying paradigm
It must be able to handle variabilities in models. If concerns are realized differently for different product line members that can lead to contradicting models that realize the same concern. These inconsistencies can not be resolved; a technique for separation of concerns for product line must be able to handle such situations.

3 Approach

The work will contain three facets: theoretical contribution, validation, and tool support. The theoretical contribution encompasses techniques for the definition, separation, and composition of concerns, as well as support for identifying concerns. A concern is a goal, anticipation, or expectation a stakeholder has on a system. A concern is expressed as a set of requirements associated with the stakeholder. Concerns are persistent over the life cycle of the product line, but the requirements they impose in the different life cycle phases are different. A concern is realized in a number of models consisting of a number of model ele-ments that together are able to express how the system fulfills the requirements imposed by the concern.
A concern is described by a set of models on one hand and the stakeholders with their interests, goals, or expectations on the concern on the other. A model set itself is defined by defining the relationships of its constituting models based on overlap. Two models are said to overlap, if they designate common aspects. This can be a model element that appears in several models (e.g., methods appear in class diagrams and in collaboration diagrams). More complex relations among models can be expressed in transformations (e.g., methods are derived from use cases). The description of the overlap is necessary to capture the semantics and overall meaning of the model set and to compose the separated concerns in order to derive a complete description. The model sets depend on the domain and the life cycle phase. Therefore, the definition of overlap must be customized. The overlap definition is also the basis for consistency checks and traceability.
Each goal or concern a stakeholder has on a model set must explicitly be stated. This is broken down to the models that serve a certain purpose within the set. Concerns can be related to each other, too. This is done by hierarchically composing model sets. Using the same mechanism that is used to relate the models and concerns in one life cycle stage, different stages can be related.
For validation, two case studies will be performed. The first will be done in the context of PuLSE. The focus is on the scope and the architecture of a product line in the domain of stock market applications. The technique will be applied to provide a basis for the traceability support.
The second case study is a KobrA [1] case study, in which the domain of library systems is being modeled to provide a complete application example of the method. This case study does not contain information on concerns. After the case study has been finished, parts of it will be redone based on the technique for separating concerns. To validate the benefits, the two case studies will be compared in detail.
Tools support is essential for the success of the proposed technique. There is a great amount of information that must be captured and kept consistent in order to model concerns as described above. Therefore, the thesis will provide a proof of concept in order to show that tool support can be provided. The approach is to add support for the separation and composition of concerns to existing software engineering environments (SEE). A prototype will be created that handles concerns and their relations to models that reside in a SEE. Possible ways of linking the prototype to the SEE are the XML Metadata Interchange Specification (XMI) from the OMG or application programming interfaces provided by the SEE. The prototype will provide means to export composed models.

4 Summary and Outlook

This Ph.D. is aiming at introducing the notion of separation of concerns to product line engineering. It will thereby support the coherent and consistent creation and evolution of product line infrastructures.
The work on the theoretical contribution is finished and the case studies are being performed.

References

[1]: C. Atkinson, J. Bayer, and D. Muthig. Component-Based Product Line Development: The KobrA Approach. In Proceedings of the First Software Product Line Conference (SPLC-1), Denver, Colorado, August 2000.
[2]: J. Bayer. Towards Engineering Product Lines Using Concerns. In Workshop on Multi-Dimensional Separation of Concerns in Software Engineering (ICSE 2000), June 2000.
[3]: J. Bayer, O. Flege, P. Knauber, R. Laqua, D. Muthig, K. Schmid, T. Widen, and J.-M. DeBaud. PuLSE: A methodology to develop software product lines. In Proceedings of the Symposium on Software Reuse (SSR’99), May 1999.
[4]: D. D’Souza and A. Wills. Objects, Components, and Frameworks with UML: The Catalysis Approach. Addison-Wesley, 1998.
[5]: W. Harrison and H. Tarr. Subject-Oriented Programming (A Critique of Pure Objects). In Proceedings of the 8th Conference on Object-Oriented Program-ming: Systems, Languages, and Applications (OOPSLA’93), pp. 411-428, Washington, D.C., September 1993.
[6]: G. Kiczales, J. Lamping, A. Mendhekar, C. Medea, C. Lopes, J.-M. Loingtier, and J. Irving. Aspect-oriented Programming. In Proceedings of the 11th European Conference on Object-Oriented Programming (ECOOP’97), pp. 220-242, Jyväskylä, Finland, June 1997.
[7]: P. Kruchten. The 4+1 View Model of Architecture. IEEE Software, November 1995, pp. 42-50.
[8]: J.C.S.P. Leite and P.A. Freeman. Requirements Validation through Viewpoint Resolution. IEEE Transactions on Software Engineering, 17(12):1253-1269, 1991.
[9]: D. L. Parnas. On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12):1053-1058, December, 1972.
[10]: T. Reenskaug, P. Wold, and O.A. Lehne. Working with Objects: The OOram Software Engineering Method. Manning Publications Co, 1995.
[11]: G. Spanoudakis, A. Finkelstein, and D. Till. Overlaps in Requirements Engineering. Automated Software Engineering, 6(2):171-198, April 1999.
[12]: P. Tarr, H. Ossher, W. Harrison, S. Sutton. N Degrees of Separation: Multi-Dimensional Separation of Concerns. In Proceedings of the 21st International Conference on Software Engineering, Los Angeles, CA, May 1999.

bayer@iese.fhg.de

Last modified: Fri July 21 10:02:03 CET 2000