Separating Product Variance and Domain Concepts in the Specification of Software Product Lines

Transcription

1 Separating Product Variance and Domain Concepts in the Specification of Software Product Lines Pertti Kellomäki Software Systems Laboratory, Tampere University of Technology P.O. Box 553, FIN Tampere, Finland Tommi Mikkonen Nokia Mobile Phones, Tieteenkatu 1, FIN Tampere, Finland Abstract Software design aims at a mapping from domain concepts to an implementation. Abstractions that are not highlighted in the implementation structure often exist only in the minds of the developers during development. While this works reasonably well for single-purpose systems, software product lines, i.e., systems built by reusing the same core functionality, require explicit presence of several types of abstractions. In particular, the relation between the implementation and underlying domain concepts, and product variance must both be mastered in parallel. In this paper, we will discuss these dimensions of concern, and introduce a way to manage them in software product lines with logical layers. The principal idea is to superimpose different aspects rather than partition the system into straightforward implementation components in the specification phase. Keywords: Software product lines, superposition, logical layers 1. Introduction Software design aims at a mapping from domain concepts to an implementation. Each step in the mapping transforms some abstractions into a less complex form, and finally the design becomes a description that can be interpreted by the underlying hardware. Some of the steps can be automated with compilers, whereas some require human intelligence. As software is immensely flexible, the part that cannot be automated is the partitioning of the system into components that will be highlighted in the system architecture. Rest of the properties are embedded in these components. Based on the above, software systems constitute two sets of abstractions, primitive and non-primitive ones. The primitive ones always have a direct mapping to their implementations, whereas non-primitive abstractions never have straightforward implementation mapping. Current design practices place the emphasis on finding the right primitive abstractions, and neglect non-primitive abstractions embedded in them. While approaches like the statecharts of 'floating nature' [1] and the modeling of a distributed state as an abstract object [5] have been proposed, mainstream specification approaches provide no universally acknowledged way to include abstractions distributed in multiple implementation components in designs.

2 The software product line approach relies on the reuse of common core functionalities in several products. In such systems, there are two main dimensions of concerns for abstractions: the relation of different products, and the relation of domain concepts and implementation for product evaluation. Specification of a product line such that it reflects both dimensions with primitive abstractions is hard at best and impossible at worst. In this paper, we discuss the specification of product lines from the viewpoint of the above concerns. The rest of this paper is structured as follows. Section 2 discusses software product lines, and the dimensions of concerns in them. Section 3 introduces the notion of logical layers, a way to support separation of concern in software product lines. Section 4 sketches a product line for ing devices, and Section 5 concludes the paper. 2. Separation of Concerns in Product Lines The software product line approach aims at more efficient software development. The principal idea is to first implement core functionality common for all the products, and then introduce product-sensitive parts on top of the core. In practice, this can be understood such that the core introduces business logic for the whole product line, like that the line is intended for ing systems. Different products then refine the business logic into product-sensitive forms by defining different reasons for triggering an, or by providing different user interfaces, like a network GUI or hardware buttons, for instance. In current practices, product lines are typically based on a single implementation architecture given for the common parts. Product variance can then be handled with programming-level mechanisms, like inheritance, resulting in new types or classes for different products, or with callbacks that make the core system activate productdependant procedures, for instance. With such an approach to product line specification, variance is the key design driver for primitive abstractions, and domain abstractions become non-primitive ones. What often happens in practice is, that the core architecture actually becomes the domain for product design. Then, diverging architecture options are hard to take into account even if full complexity of the core is needed for the top-of-the-line products only. The alternative solution is to start from domain concepts. This can be achieved with a layered architecture, for instance. Then, the design can reflect domain abstractions in a fashion where higher-level abstractions rely on services offered by lower-level ones. With this approach, product variance becomes a non-primitive abstraction, resulting in poor support for mastering it. Further, potential performance problems have been associated with layering in general, because the handling of behavioral aspects at the corresponding level of abstraction often results in overhead. 3. Introducing Logical Layers Superposition (or superimposition) supports separation of concern in logical rather than implementation sense [2]. A module applying superposition can be considered as a program slice [10], with the exception that here the slices are used to construct new systems, not to decompose existing ones. With superposition, an early partitioning to implementation components and the definition of their implementable interfaces, which have been found to harden reasoning [7], are not the primary design goal. Instead, the

3 focus can be placed on different concerns one at a time to support validation and verification. For instance, separation of correctness of computation and termination of the computation is a traditional application area of superposition. We will refer to each step applying superposition as a logical layer in the system. A layer contains a set of state variables and atomic actions that alter their values. Actions can be thought operationally as execution sequences like in the DisCo approach [2], or in terms of behaviors in the sense of the temporal logic of actions [8]. A variable can only be modified by the actions given in the same layer. When combined (or conjuncted), actions in different layers can be synchronized, enabling the creation of more complex operations. In general, the combination reminds weaving in the aspect-oriented setting [3], and always preserves safety properties ("Something bad will never happen") of all component layers by construction. For liveness properties ("Something good will eventually happen"), additional considerations are needed. The use of logical layers enables modeling of product variance as follows. The core functionality of the system is constituted with a set of logical layers. Different products refine the core functionality by adding logical layers. Product variance can be handled with parallel refinements adding mutually exclusive layers, with each refinement defining particularities of one product. The other dimension of concern in the development is to support the relation of domain and implementation concepts. In the approach described in this paper, variables reflecting high-level abstractions can be omitted from an implementation, if they are given concrete implementations in terms of less abstract state variables. This results in well-defined nonprimitive abstractions. Proving the implementation mapping for non-primitive abstractions may require a lot of work even for obvious cases. There are two potential solutions to this problem. One is to use an animation tool for testing that the non-primitive abstractions are satisfied [9]. This corresponds to testing in conventional software engineering approaches, and provides adequate validation means for many non-critical applications. The other alternative is to use predefined design steps, i.e., apply a refinement step that has been already verified and validated [6]. Architectural variance is also allowed. Then, there will be mutually exclusive layers in the mapping of domain concepts to different implementations. A related approach has been given in [4], where the concept of variance patterns is introduced. In our terminology, variance patterns of [4] constitute mutually exclusive logical layers. 4. Sketched Example: Product Line for Alarming Devices In this example, we sketch a specification of a product line for ing devices. We use two different product logics, i.e., reasons for triggering an, and two implementation architectures, resulting in four products. Figure 1 illustrates the structure of the specification. In the figure, boxes denote logical layers, and arrows refinement relations needed for composing specifications. Dashed lines indicate different categories of layers discussed in detail in the following. Four main categories of logical layers can be identified. Core functionality layers introduce domain concepts of the system, including issues like turning the device on and

4 Core layers Core functionality Architecture layers architecture architecture Product variance layers Product layers Figure 1. Dimensions of concern in the structure of a layer-based specification off and triggering and cancellation of an for instance. However, implementation details of these events remain non-deterministic, because the rationale for operations may vary depending on the product. Architecture layers provide implementation architecture for the core. In these layers, we introduce how s are indicated in different implementations, and define different implementation mappings for non-primitive abstractions. Product variance layers introduce ing logics for different products. In practice, this covers the definition an ing function for different products. Product layers, obtained by combining the branches addressing different dimensions of concern, are complete product descriptions. As already discussed above, safety properties introduced in different branches are satisfied by construction. 5. Conclusions Software product lines need to support two main dimensions of concern. One dimension places the focus on product variance, and results in an architecture that provides enhanced support for composing different products. The other dimension is domain-driven. There, the goal is the option to trace domain concepts to implementations in a verifiable fashion.

5 Support must be provided for abstractions reside in the core functionality, in productdependant parts, and for those that are shared between the two. As mainstream software engineering approaches solely focus on primitive abstractions explicitly included in implementation architecture, satisfaction of both of these dimensions is hard. In practice, this is reflected in the required experience on implementing several line products prior to the establishment of the product line. We argue that in order to utilize dimensions of concerns discussed in this paper at an abstract level, we need a specification approach that supports parallel design and evolution of both product variance and domain concepts. References [1] Awad, M. and Ziegler, J. A practical approach to object-oriented state modeling. Software Practice and Experience, 27(3): , March [2] Järvinen, H.-M., Kurki-Suonio, R., Sakkinen, M., and Systä, K. Object-oriented specification of reactive systems. Proc. 12 th International Conference on Software Engineering, 63-71, IEEE Computer Society Press, [3] Katz, S. and Gil, J. Aspects and Superimpositions. Position paper at ECOOP'99 AOP workshop, Lisbon, Portugal, June 14, [4] Keepence, B. and Mannion, M. Using patterns to model variability in product families. IEEE Software, , July/August [5] Kellomäki, P. and Mikkonen, T. Modeling distributed state as an abstract object. Distributed and Parallel Embedded Systems, (Ed. F. J. Rammig), , Kluwer Academic Publishers, [6] Kellomäki, P. and Mikkonen, T. Design templates for collective behaviors. Accepted to ECOOP'00, to appear. [7] Lamport, L. Composition: A way to make proofs harder. Digital Systems Research Center, Technical Note a, December [8] Lamport, L. The temporal logic of actions. ACM transactions on programming languages and systems, 16(3): , May [9] Systä, K. A graphical tool for specification of reactive systems. Proc. Euromicro'91 Workshop on Real-Time Systems, 12-19, IEEE Computer Society Press, June [10] Weiser, M. Program slicing. IEEE Transactions on Software Engineering, 10(4): , 1984.