A Systematic Method to Instantiate Core Assets in Product Line Engineering Soo Dong Kim, Soo Ho Chang and Chee Won Chang Department of Computer Science Soongsil University, Seoul, Korea
[email protected] { shchang, cwchang}@otlab.ssu.ac.kr Abstract Product line engineering (PLE) is one of the recent and effective reuse approaches, and it consists of two processes; framework engineering and application engineering. Framework engineering is to model and realize a core asset which represents common functionality and quality attributes in a target domain, and application engineering is to generate a target product by instantiating the core asset. Hence, a core asset is a key element of PLE, and the quality of core assets largely determines the overall quality of products. Although numerous PLE methodologies have been introduced, it is still unclear what should be the elements of a core asset and how the core asset should be instantiated for each application. That is, the overall process and instructions of instantiating core assets have not been studied enough. In this paper, we first define a meta-model of core assets, propose a process of instantiation, and define its instructions on how to carry out each activity in practice. We believe that the proposed meta-model and the process framework can effectively be used in developing core asset and applications in practice.
A core asset, which is also called framework, is the most essential element of PLE, and the quality of core assets largely determines the overall quality of family products, i.e. applications. Although numerous PLE methodologies have been introduced, it is still unclear what the elements of a core asset should be. The term, core asset, has been defined largely conceptually as a software design or implementation that captures the common features among products. It is still not clear that how the core asset is represented physically on a design model, a source program, or a development environment such as EJB or CORBA. Moreover, the process and instructions of instantiating the core asset have not been defined precisely. In this paper, we give a survey of related research work in section 2. Then, we present a meta-model of core assets and instantiated core assets in section 3. We propose a process of instantiation, and define instructions on how to carry out each activity in practice in section 4. Section 5 includes an assessment of the proposed research framework. We believe that the proposed meta-model and the process framework can effectively be used in instantiating core asset for each product.
1. Introduction Product line engineering (PLE) is one of the recent and effective reuse approaches, and it consists of two processes; framework engineering and application engineering. Framework engineering is to analyze a set of requirements in a domain, define a scope of a product line by applying an economic analysis, and develop a core asset which represents common functionality and satisfies quality attributes in the domain. Application engineering is to analyze the application requirement, define a resolution model and instantiate the core asset according to the resolution model and finally generate the target product.
Proceedings of the 11th Asia-Pacific Software Engineering Conference (APSEC’04) 1530-1362/04 $ 20.00 IEEE
2. Related Work In this section, we survey representative research results on process of core asset instantiation.
2.1.
PuLSE
PuLSE (Product Line Software Engineering) is a process for developing product line developed by IESE [2]. It consists of three sub-elements; Deployment Phases, Technical Components, and Support Components. Deployment phases is to produce reusable assets and products using related technical components of PuLSE–BC, PuLSE-Eco, PuLSE-CDA,
PuLSE-DSSA, PuLSE-I, and PuLSE-EM. PuLSE-I is used to develop applications and it includes an activity of instantiating product line model and reference architecture [3]. The product line model which is essentially an object model and storyboards representing a core asset is hierarchically resolved with a decision model and application specific characteristics. The reference architecture is refined into an intermediate architecture which embeds an architectural variability and it defines an architectural resolution decision. This identifies activities for instantiating, however, step-wise and detailed instructions are not given. Moreover, elements of each artifact are not defined. As the result, the practical application of this method is questionable.
2.2.
KobrA
KobrA[4] is a component-based product line engineering method, based on UML. It consists of Framework Engineering and Application Engineering. Framework Engineering defines a framework which is reusable among family members. Application Engineering is to produce applications by instantiating the framework with a decision model. A generic Komponent is translated into a specific Komponent by using decision model. Decision model is tailored to a decision resolution model (DRM) for a specific application. The first step of instantiation is to determine the overlap between the functionality offered by a framework and the functionality required by an application. This step produces a decision model of generic context realization which derives a DRM. The second step is to tailor a Komponent containment tree for a specific application by recursively instantiating Komponent specifications and realization. This work defines a process of instantiation at macro level. The instructions given here need to be further refined in order to be applied in practice.
2.3. SEI Software Product Line SEI Software Product Line is an early foundational work in PLE, and it consists of two activities [5]. Core Assets Development is to produce core assets and Product Development is to develop products by using core assets. Product line scope, core assets, and production plan derived from core assets development and requirements for a particular product are used in production development. However, this work focuses on definition of overall concepts of product line and utilization of other
Proceedings of the 11th Asia-Pacific Software Engineering Conference (APSEC’04) 1530-1362/04 $ 20.00 IEEE
practice areas rather than defining applicable process, work instruction, and defining PLE artifacts in detail.
3. Meta-Models of Core Instantiated Core Assets
Assets
and
In this section, we define meta-models of core assets and instantiated core assets. These models are referred later in defining instantiation process and instructions.
3.1.
Core Assets
A core asset plays a key role in PLE, and it has architecture which is generic to products, a component model capturing components and interfaces, and a decision model defining variability realization, as shown in figure 1. Architecture is generally defined in three views [6], but only module viewtype and component and connector (C&C) viewtype are specified in the core asset because allocation viewtype defines applicationspecific deployment and work assignment decisions. Since module viewtype represents functional elements and their relationships in design level, they can be described by a functional model and an object model at runtime, which in turn can be represented in use case model and class diagram. C&C viewtype specifies the interaction and connection decisions at runtime, and it is described in a behavioral model, which in turn can be represented in interaction diagrams such as sequence, collaboration and/or activity diagrams. The component model consists of classes, interfaces and their relationships, and hence it should conform to the generic architecture. The component model is represented by component specification and interface specification. A decision model is a realization of variability of C&V specification, and it consists of variation points, their associated variants, and effects [4]. A variation point is a place where there exists a minor variation on attributes, logics and workflow among products in a product line. Variants are valid values which fill in a variation point. Variability listed in the decision specification is eventually reflected and realized in architecture specification, component specification and interface specification.
«realizes» Artifact Layer
Core Asset
1
Generic Architecture
1
* Component Model
«refers to»
«realizes»
Decision Model
Element Layer
*
* C&C View
Module View
Variation Point
*
Component
1
Interface
*
Variant Behavioral Model
1
Functional Model
Provided Interface
Object Model
Architecture Specification
* Component
*
*
Required Interface
Component Specification
Effect
*
Sub-Element Layer Decision Specification
Interface Specification
* Inter-Compo. Non-Functional Relationship Design
Representation Layer
Figure 1. Meta-model of Core Asset
3.2. Instantiated Core Assets Instantiated core asset is the result of resolving variability of a core asset by applying a DRM which specifies application specific variants. «realizes»
Instantiated Core Asset Artifact Layer *
Instantiated Architecture
«refers to»
Decision Resolution Model
Instantiated «realizes» Compo. Model
4. Process and Instruction In this section, we present a process and work instructions for instantiating core asset. It is assumed that design of a core asset along with its decision model is available. The process presented in Figure 3 takes the core asset and produces an instantiated core asset as the final deliverable.
Element Layer
Lower layers are same as those in core asset.
Figure 2. Meta-model of Instantiated Core Asset
As in Figure 2, a generic architecture and a component model of a core asset are specialized with a DRM. Note that the decision model of core asset is not represented any more in the instantiated core asset since the variability of the core asset is tailored for a specific application in the instantiated core asset.
Proceedings of the 11th Asia-Pacific Software Engineering Conference (APSEC’04) 1530-1362/04 $ 20.00 IEEE
Ideally, a core asset should cover the whole functionality needed by product members. In reality, applications may need some additional features that are not covered by the core asset. This situation is shown as ‘Features Not Covered by Core Asset’ in Figure 4.
Activity Activity 1. 1. Define Define Resolution Resolution Model Model Step 1a
Identify Identify Overlapped Overlapped Features Features
Step 1b
Step 1c Define Define Variants Variants
Features Overlapped
es tur by Fea ered ov sset tC No ore A C
F No eatu r t Ap Use es pli d cat by ion
Select Select Applicable Applicable Variation Variation Points Points
Features Provided by Core Asset
Activity Activity 2. 2. Resolve Resolve Variability Variability
Features Required by Application
Step 2a
Resolve Resolve Variability Variability of of Architecture Architecture
Figure 4. Matching between Core Asset and Application Step 2b
Resolve Resolve Variability Variability of of Components Components
Hence, step 1a is to identify the features overlapped between the core asset and the application, and the artifact of this step is a list of overlapped features.
Activity Activity 3. 3. Verify Verify Resolution Resolution
Step 1b. Select Applicable Variation Points
Step 3a
Verify Verify Decision Decision Resolution Resolution Model Model
Step 3b
This step is to identify the features which have variation point from the list of overlapped features. Note that, since there are features which are not used by application as shown in the Figure 4, not all variation points defined a decision model are applicable to each application. That is, an application may typically take a subset of those variation points. Therefore the artifact of this step is a list of variation point which is the source of DRM.
Verify Verify Instantiated Instantiated Core Core Assdet Assdet
Figure 3. Process to Instantiate Core Asset
4.1.
Activity 1. Define Resolution Model
A core asset is associated with a decision model, which specifies variation points and relevant variants. Each application is developed by setting application-specific variants for selected variation points. A DRM specifies the variation points and variants selected for a specific application. Step 1a. Identify Overlapped Features This step is to identify the overlapped features that covered by a core asset and are also used by application. This can be done by analyzing requirement of the application and comparing it to specification of core assets.
are the the the
Ideally, a core asset provides the common functionality among product members, implying that all the features in the core asset are used by applications. In reality, some of the features in the core asset may not be needed by an application. Especially, this situation arises when a new application is added to the product line after a core asset has been developed. This is shown as ‘Features Not Used by Application’ in Figure 4.
Step 1c: Define Variants This step is to define application specific variants for associated variation points identified in step1b. The scope of variability can be either closed or open [6]. The scope of closed variability is determined by a set of known valid values for a variation point, where the scope of open variability includes currently unknown future variants. For closed variation point, one of the valid variants is selected for an application. For open variation point, a variant is newly defined for an application. A common example of such variant is a plugIn object instantiated from a class that extends a super class, i.e. specification of open variation point. Table 1 is a template of artifact for DRM. In addition to specifying variation points and variants, the effect of setting a variant and engineering tasks required are also specified in the table.
Proceedings of the 11th Asia-Pacific Software Engineering Conference (APSEC’04) 1530-1362/04 $ 20.00 IEEE
Table 1. Decision Resolution Model ID
VP
Variant
Effect
Task
1 2
Current PLE works commonly specify variation point and variants as the element of DRM, but the effect of setting a variant was not treated in depth [4]. We believe that precisely defining the result and semantics of setting variants is essential. In this paper, an effect can be a post-condition of setting variant or a description of inter-variation point dependencies. Hence, an effect describes the semantics of setting variants. For closed variability, a decision model should have already defined the effects of known variants. For open variability, the effect of a newly defined variant should be explored and defined. Task in the table specifies engineering tasks that should be followed, and it typically includes customization mechanisms involved. Since a variation point may be one of different types; attribute, logic, micro workflow, and interface [7], each type of variability may require different customization mechanisms.
4.2.
Activity 2. Resolve Variability
Step 2a. Resolve Variability of Architecture A system architecture consists of components and their relationships, and it realizes both functional and nonfunctional requirements [8]. A generic architecture in a core asset captures architectural decisions which are common among applications [9][10][11]. Variability on the generic architecture represents variations on functional and non-functional requirements among applications. Such variability is mainly represented on the required components, and/or inter-component relationships. In this step, we first create an intermediate architecture which is copied from the generic architecture and will eventually be tailored for a specific application. Then, we resolve the architectural variability by considering the nature of variation point. If a variation is on the set of components required by applications, then select only the components required by the application. For example, if the security management may be optional in the product line, some applications would not require the components implementing that functionality. Hence, unnecessary components should be deleted from the intermediate architecture.
If a variation is on the relationships among components, then select or re-define the inter-component relationships required by the application. It is common to select and apply architectural styles in defining target architecture [8]. If styles are applied in the architecture design, the inter-component relationships specified in the styles are applied to the intermediate architecture. If styles are not applied, then intercomponent designs are derived from application requirements by developers. Now, we need to remove components and their relationships that are not applicable to the target application from the intermediate architecture. Step 2b. Resolve Variability of Components This step is to assign variants for the variation points in the components of a core asset. Since a component model of a core asset contains all candidate variants for a variation point with closed scope, we should remove variants that are not needed by a target application. As the result, the model after removing unnecessary variants would be optimized for the target application. Resolving a variation point may involve modifying both structural model and behavioral model of a component model. Non-functional requirement is also realized in a component model. Accordingly, variability on nonfunctional requirement is embedded in the component model. Hence, resolving a variation point related to a non-functional requirement will involve the modification of the component model. When modifying the component model, the effect and tasks defined in a DRM should be observed and followed.
4.3.
Activity 3. Verify Resolution
Activity 3 is to verify a DRM and an instantiated core asset. Figure 5 shows a traceability map among core asset, decision resolution specification and instantiated core asset. The representation elements of each artifact are given and traces between two related elements are defined.
Proceedings of the 11th Asia-Pacific Software Engineering Conference (APSEC’04) 1530-1362/04 $ 20.00 IEEE
Core Core Asset Asset Generic Architecture Specification
Instantiated Instantiated Core Core Asset Asset Instantiated Architecture Specification
Component
Component
Inter-Component Rel.
Inter-Component Rel.
Non-Functional Design
Non-Functional Design
Component Spec.
Decision DecisionResolution Resolution Specification Specification
Component Spec. Class Specification
Variation Point
Interaction Specification
Interaction Specification
Variant
s dk
Class Specification
Effects Interface Spec.
Interface Spec.
Method Signature
Method Signature
Method Semantics
Method Semantics
Decision Spec. Variation Point Variant Effects
Figure 5. Trace for Verification Instantiated Core Asset
Step 3a. Verify Decision Resolution Model This step is to verify a decision resolution specification by using application requirement specification. We should check if the decision resolution specification includes all the necessary variation points. Also, we check the validity of variants for each variation point. For open variability, we should verify the supplied variant satisfies the specification of valid variants in the decision model. Step 3b. Verify Instantiated Core Asset In this step, we verify the conformance of an instantiated core asset against the DRM applied. We use the following checklist for this step; y All and only the variation points specified in the DRM should be represented in an instantiated core asset. y All the variation points specified in the DRM must be resolved with variants. y The pre-condition and inter-variation point relationships specified by the effect should have
been preserved in an instantiated core asset. y Variants unselected by the DRM must have been removed in an instantiated core asset.
5. Assessment In this section, our work is compared to the three related works in section 2. We first define the comparison criteria in artifact aspect and process aspect. For Artifact Aspect: y Concreteness of Artifact is to evaluate how precisely and physically the elements of an artifact are defined. y Traceability among Artifacts is to evaluate how precisely the mapping relationships between input and output artifacts are defined. For Process Aspect: y Well-defined Sequence of Activities is to evaluate how logically the order of activities is defined and how effectively and seamlessly activities can be carried out in sequence.
Proceedings of the 11th Asia-Pacific Software Engineering Conference (APSEC’04) 1530-1362/04 $ 20.00 IEEE
y Detailed Level of Steps and Instructions is to evaluate how concretely and precisely the steps and instructions are defined. y Instantiating Architectural Variability is to evaluate the instruction on how the architecture variability is instantiated.
References [1]
Muthig, D. and Atkinson, C., “Model-Driven Product Line Architectures,” Lecture Notes in Computer Science 2379, Proceedings of the 2ND Software Product Line Conference, 2002.
Table 2 shows the result of comparing the research works using the criteria.
[2]
Bayer, J., Flege, O., Knauber, P., Laqua, R., Muthig, D., Schmid, K., Widen, T., and DeBaud, J., “PuLSE: A Methodology to Develop Software Product Lines,” Proceeding of symposium for Software Reusability ’99, ACM, 1999.
[3]
Bayer, J., Gacek, C., Muthig, D., and Widen, T., “PuLSE-I: Deriving Instances from a Product Line Infrastructure,” Proceeding of 7th International Conference and Workshop on the Engineering of Computer Based Systems, IEEE, 2000.
[4]
Atkinson, C., et al., Component-based Product Line Engineering with UML, Addison Wesley, 2001.
[5]
Clements, P. and Northrop, L., Software Product Lines: Practices and Patterns, Addison Wesley, 2001.
[6]
Choi, S., et al., “A Systematic Methodology for Developing Component Frameworks,” Lecture Notes in Computer Science 2984, Proceedings of the 7th Fundamental Approaches to Software Engineering Conference, 2004.
[7]
So, D., Shin, S. and Kim, S., “Formal Views of Types and Scopes of Component Variability,” The Journal of Korean Information Science Society, vol. 30, no. 5, pp. 414-429, June 2003.
[8]
Clements, P., et al., Documenting Architectures Views and Beyond, 2003.
[9]
Matinlassi, M., Niemela, E., and Dobrica, L., “Qualitydriven architecture design and quality analysis method : A revolutionary initiation approach to a product line architecture,” VTT publication 456, VTT Technical Research Center of Finland, ESPOO2002, 2002.
Table 2. Comparison to Other Approaches SEI SPL
PuLS E
Kobr A
Our Work
Concreteness of Artifacts
-
z
z
Traceability among Artifact s
-
-
-
z
Well-defined Sequence of Activities
z
z
Detailed Level of Steps & Instructions
Instantiating Variability
Architectural
z
z z
z Support, Weakly Support, - Not Support It is shown that traceability among artifacts is not treated much in current works, and the steps and instructions given are far from practical use.
6. Concluding Remarks PLE is an effective reuse approach. Framework engineering of PLE is to model and realize a core asset which represents common functionality and quality attributes in a target domain, and application engineering of PLE is to generate a target product by instantiating the core asset. In this paper, we first defined key elements of a core asset, i.e. its meta-model. Then, we proposed a process of instantiation by considering the meta-model. Each activity was further defined by steps, where each step is given work instructions. In addition to component variability, we also explored the issue of architectural variability and provided instructions to resolve the variability. We believe that the proposed meta-model and the instantiation process can effectively and practically be used in tailoring a core asset for each product in the product line.
Proceedings of the 11th Asia-Pacific Software Engineering Conference (APSEC’04) 1530-1362/04 $ 20.00 IEEE
Software
[10] Kang, K., Kim, S., Lee, J., Kim, K., Shin, E. and Huh, M., “FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures,” Annals of Software Engineering, vol.5, p.143- p.168, 1998. [11] Anastasopoulos, M., Bayer, J., Flege, O., and Gacek, C., A Process for Product Line Architecture Creation and Evaluation PuLSE-DSSA-version 2.0, Technical Report, No. 038.00/E, IESE, June 2000.
