Feature models have been used to support requirements analysis and domain engineering in. Software Product Line. By identifying the mapping between ...
Fifth International Conference on Computational Science and Applications
Identifying Traceability between Feature Model and Software Architecture in Software Product Line using Formal Concept Analysis Tonny Kurniadi Satyananda, Danhyung Lee, Sungwon Kang, and Sajid Ibrahim Hashmi Information and Communications University 119 Munji-ro Yuseong-gu, Daejeon 305-732, Korea {tonny, danlee, kangsw, hashmi}@icu.ac.kr traceability among software product line artifacts. But still, the traceability should be managed and verified. The main goal of our work is to establish a framework for automated formal identification of the traceability between feature model and architecture model. In this approach, we focus only on feature model and architecture model in core asset development. By identifying the mapping between feature model’s elements and architecture model’s elements, we can identify the traceability between the two models. To identify the traceability, we need a basis for matching the elements. We use functional decomposition of a feature and functional decomposition of an architecture component to find matching elements. We define functional decomposition as a list of functionality descriptions which describes the functional capability. The description should be provided in feature description and architecture description in a consistent way. Different keywords are interpreted as different functional capability. And then, based on functional decomposition, we utilize Formal Concept Analysis to identify the mapping among elements. Later, the identified mapping can be used to verify consistency between feature model and architecture model. The rest of this paper is organized as follows. Section 2 presents the basic concepts of feature model, architecture model, and formal concept analysis. Section 3 then provides the overview of our approach to identify the traceability between feature model and architecture model. The application of our approach is shown using a case study of Digital Watch product line in Section 4. In Section 5, we conclude this paper and present the future direction of our research.
Abstract Feature models have been used to support requirements analysis and domain engineering in Software Product Line. By identifying the mapping between feature model and architecture model by capturing the relationships among elements in the models, we can establish the traceability between the two models. The identified traceability can be used to verify consistency between feature model and architecture model. On small scale models, the relationships among elements can be easily identified by manually analyzing the descriptions of models. But when the complexity of a model is high, a more formal approach will be useful to help identifying the traceability. In this paper, we develop an approach to identify traceability between feature model and component and connector view of software architecture using Formal Concept Analysis (FCA) technique. This technique constructs a concept lattice structure. We propose several analysis criteria for concept lattice structure to identify traceability between the two models.
1. Introduction According to Software Engineering Institute (SEI) definition, a software product line is “a set of softwareintensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way” [1]. In this sense, feature modeling plays an important role in establishing the baseline for product line development, because it defines the commonalities and the variabilities in product domain. The commonalities and variabilities in software product line will increase the difficulty in managing
0-7695-2945-3/07 $25.00 © 2007 IEEE DOI 10.1109/ICCSA.2007.59
380
Figure 1. An example of Digital Watch Product Line Feature Model [8], which is quite formal, but not descriptive enough to specify specific feature property, such as functional decomposition. Asikainen in [9][18] proposed Forfamel, a conceptual basis and language for expressing feature models. Even though Forfamel doesn’t’ specify functional decomposition, we modified it to accommodate functional decomposition. In our approach, we use Forfamel to describe feature model description. For simplicity, we declare functional decomposition of a feature in Forfamel explicitly using functional list identifier, e.g. functional .
2. Background As a basis for discussion, in this section, we provide a brief explanation of some key concepts, and how they are used in our approach: feature model concept, architecture model concept, and Formal Concept Analysis.
2.1. Feature Model Feature modeling is a method for describing commonalities and variabilities in software product line. It was introduced for the first time by Kang et al. in 1990 in Feature Oriented Domain Analysis (FODA) [2]. Since then, many researches have been done to suggest improvement over feature model [3][4][5][6][7]. Kang et al. [2] define features as the attributes of a system that directly affect end-users. A feature model consists of a feature diagram and other information such as rationale, constraint, and dependency rule. A feature diagram is a tree-like notation that shows the hierarchical structure of features. The root of the tree is referred as concept node. In FODA, there are several definitions of feature variability: mandatory features must be selected whenever its parent is selected; an optional feature may or may not be selected when its parent is selected, an alternative feature consists of a set of alternatives of which exactly one must be selected whenever the parent feature is selected. Feature dependency (static constraint) is classified into ‘requires’ or ‘mutex’ (excludes). Fig. 1 shows an example of Digital Watch product line feature model. Deursen and Klint proposed a Feature Description Language (FDL), a textual language to describe feature
2.2. Architecture Model According to Bass et al. [10], software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. In software product line, it is important to explicitly represent commonality and variability in product line architecture, because the architecture will be used to build a variety of different product. Component and connector (C&C) views define models consisting of elements that have some runtime presence (such as processes, objects, clients, servers, and data stores) and their interactions [11]. Variability of element in this view can be classified as mandatory, optional, or variant. Architecture description language (ADL) is used to describe architecture model in textual format. A large number of ADLs have been proposed, e.g. ACME [12]. Asikainen et al. in [13] present a comparison analysis of ADLs for software product lines (ACME, Wright, and Koala).
381
(o,a) ∈R); otherwise it is false [14]. From the relation R, a lattice is computed which allows examination of concepts shared among objects. A concept can be thought of as a maximal set of shared attributes. Further details on concept lattices theory can be found in [20]. In our approach, FCA will be used to identify mapping relationships among feature elements and architecture elements. Because architecture consists of ‘what parts’ (problem domain) and ‘how parts’ (solution domain), the ‘what parts’ must be mapped to features. This means some architecture elements (such as components, connectors, or ports) must have similar functional decomposition with feature elements. This information is used to identify traceability. In FCA, features and architecture elements are defined as members of FCA extent, and functional decomposition is defined as members of FCA intent. Functional decomposition should be provided in feature description and architecture description in a consistent way. Different keywords are interpreted as different functional capability. Rules for analyzing concept lattice to identify mapping relationship are explained in next section.
DigitalWatch
Stopwatch
Main Controller Time
Alarm
Light Controller
Audio Controller
Legend Component Types
Connector Types Invoke
Subsystem caller Component Controller Component
callee
Data Exchange provider requester
Variability Mandatory Component
Mandatory Connector
Optional Component
Optional Connector
Mandatory Port Optional Port
Figure 2. An example of Digital Watch Product Line Architecture Model
3. The Approach
In our approach, we will use ACME to describe architecture model. Functional decomposition of an architecture element is declared explicitly using specific property for functional list, e.g. Property Functional: String = “list-offunctional-name“. Fig. 2 shows an example of Digital Watch product line architecture model (high level).
In this section, we explain each step to identify traceability and rules for identifying mapping relationship. Traceability identification approach is illustrated in Fig. 3.
3.1. Steps To identify traceability we proposed the following steps: 1. Extract functional decomposition. The first step in our approach is extracting functional decomposition from feature description and architecture description. In order to simplify the extraction process, each of the description should conform to a specific definition language. In our case, as a simple example, we use modified Forfamel (by adding functional decomposition declaration) to describe feature model, and ACME to describe architecture model. The output of this step should be formatted according to the input format of FCA tool. This step can be automated by implementing parser algorithm for referred feature description language and referred architecture description language. The extraction algorithms are not discussed here.
2.2. Formal Concept Analysis Formal Concept Analysis (FCA) is a theory of data analysis which identifies conceptual structures among data sets. It uses lattice theory to provide a way to group and discuss objects based upon their common attributes. FCA has been applied in many part of software development, e.g. for architectural element matching [14], analyzing product maps [15], locating features in source code [16], establishing model dependency [19]. In FCA, the basic object of manipulation is the formal context (C) which is defined as the ordered triple (O, A, R) where O is the extent (or set of objects), A is the intent (or set of attributes), and R is a relation between the extent and intent (R ⊆ O× A). This relation can be visualized as a table where rows are indexed by objects and columns by attributes. If object o has attribute a, then the table entry (relation) is true (or
382
Figure 3. Traceability Identification Approach 2.
3.
z
If a concept with feature element is not directly subsumed by any subconcept with architecture element, then the link to every superconcept (with an intent) in direction to universal concept must be checked. From that superconcept, find every subconcept with architecture element; then, the feature element is mapped to the architecture elements. (The feature element is implemented by several architecture elements.) When we trace mapping relationships starting from each feature element, we can identify mapping-pair of feature element and architecture element. Depending on how we implement graph traversal algorithm to find mapping relationships, we can further identify one-toone mapping, one-to-many mapping, and many-to-one mapping relationships. Many-to-many mapping relationship can be covered also as intersection of oneto-many mapping-pair set and many-to-one mappingpair set.
Build concept lattice. The second step is building concept lattice using FCA tool. In our case, we use Christian Lindig’s concept package [17] to build the concept lattice. This concept package implements mathematical algorithm to generate concept lattice graph and it will give a result in simple textual format. Analyze concept lattice. The final step is analyzing concept lattice to identify mapping elements. Concept lattice is traversed to identify functional decompositionbased mapping between feature elements and architecture elements. Mapping analysis rules are explained in next subsection. This step can be automated by implementing mapping analysis rules and apply it to concept lattice.
3.2. Mapping Analysis Rules To identify mapping relationship, we have to interpret the meaning of concept lattice representation. Because we want to identify which architecture elements implement which feature elements, we have to check the relation among concepts, starting from every concept which has feature object: z If in a concept node, there are feature element and architecture element, then it means that the feature element is mapped to the architecture element. (They exactly have same functional decomposition.) If a concept with feature element is directly z subsumed by a subconcept with architecture element, then it means that the feature element is mapped to the architecture elements (The feature element is implemented by the architecture element.)
4. Case Study In order to illustrate how our approach can be applied, we use the example of Digital Watch product line. Because the models shown in Fig. 1 and Fig. 2 are too big, we will focus on mapping identification on a portion of Digital Watch models shown in Fig. 4. Without loss of generality, we limit the discussion to feature to architecture component mapping. This makes the relations easier to detect visually in the computed concept lattice. From feature description and architecture description, we extract functional decompositions. For illustration purpose, the elements and functional decompositions are listed using tabular format in Table 1. Note that concept feature is not mapped to any architecture element.
383
Figure 4. Portion of Digital Watch Feature Model and Architecture Model In Table 1, for the sake of clarity, every feature element is prefixed with ‘FE.’ and every component element is prefixed with ‘AE’. Each row of Table 1 represents each member of FCA extent (which is a feature element or an architecture component) and its relationship with each functional capability. This information is obtained through functional decomposition extraction step. The computed concept lattice result is illustrated in Fig. 5. By applying mapping rules to the lattice, we get
feature to architecture component mapping. The identified mapping is shown in Fig. 6. Note that, in order to identify mapping relationship, we must implement graph searching algorithm to traverse each concept node with feature element. In this example, the result can be easily validated by visually comparing the content of Table 1 and the structure represented in lattice graph. When the complexities of models are high, this automated approach will be helpful.
Table 1. Elements and Functional Decompositions
384
Figure 5. Concept Lattice for Digital Watch
5. Conclusion In this paper, based on functional decomposition, we developed an approach for identifying traceability between feature model and architecture model using Formal Concept Analysis. We have proposed several analysis criteria for concept lattice structure to identify traceability between the two models. Using the case study of Digital Watch, we showed the applicability of our approach. Our approach can be used as a first step toward automated verification of consistency between feature model and architecture model. For future work, we plan to perform the verification work automatically. For that we will work on formally stating consistency conditions based on the traceability identified with this approach, and on how to encode them into the language of Prototype Verification System (PVS).
Figure 6. Identified Mapping
385
6. Acknowledgment
[10] Bass, L., Clements, P., and Kazman, R., Software Architecture in Practice, 2nd edition, Addison-Wesley, 2003.
This work was supported by the Industrial Technology Development Program funded by the Ministry of Commerce, Industry and Energy (MOCIE, Korea).
[11] Clements P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nord, R., and Stafford, J., Documenting Software Architectures: Views and Beyond, Addison-Wesley, 2002. [12] Garlan, D., Monroe, R. T., and Wile, D., ACME: An Architecture Description Interchange Language, in Proceedings of CASCON'97, Toronto, Ontario, 1997.
7. References [1] Clements, P. and Northrop, L., Software Product Lines: Practices and Patterns, Addison-Wesley, 2001.
[13] T. Asikainen, T. Soininen, and T. Männistö, Towards Managing Variability using Software Product Family Architecture Models and Product Configurators, in Proceedings of Software Variability Management Workshop, 2003.
[2] K. Kang, S. Cohen, J. Hess, W. Nowak, and S. Peterson, Feature Oriented Domain Analysis (FODA) Feasibility Study, Technical Report CMU/SEI- 90-TR-21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, USA, November 1990. [3] K. C. Kang, S. Kim, J. Lee, and K. Kim, FORM: A Feature-Oriented Reuse Method, in Annals of Software Engineering 5, pages 143-168,1998.
[14] Waters, R., Rugaber, S., and Abowd, G.D., Architectural element matching using concept analysis, in the Proceedings of 14th IEEE International Conference on Automated Software Engineering, 1999.
[4] M. Griss, J. Favaro, and M. d'Alessandro, Integrating Feature Modeling with the RSEB, in Proceedings of the 5th International Conference on Software Reuse, Vancouver, BC, Canada, 1998.
[15] Eisenbarth, T., Koschke, R., and Simon, D., A Formal Method for the Analysis of Product Maps, Requirements Engineering for Product Lines Workshop, Essen, Germany, September 2002.
[5] J. van Gurp, J. Bosch, and M. Svahnberg, On the Notion of Variability in Software Product Lines, in Proceedings of the Working IEEEPFIP Conference on Software Architecture (WZCSA'OI), 2001.
[16] T. Eisenbarth, R. Koschke, and D. Simon, Locating features in source code, IEEE Transactions on Software Engineering, vol. 29, pp. 210--224, Mar 2003. [17] C. Lindig: Concepts. Available electronically at http://www.st.cs.uni-sb.de/~lindig/src/concepts-0.3f.tar.gz, 1999.
[6] M. Riebisch, K. Bollert, D. Streitferdt, and I. Philippow, Extending Feature Diagrams with UML Multiplicities, in Proceedings of the 6th Conference on Integrated Design and Process Technology (IDPT2002), Pasadena, CA, 2002.
[18] Timo Asikainen, Tomi Männistö, Timo Soininen, A Unified Conceptual Foundation for Feature Modelling, in Proceedings of Software Product Lines Conference 2006, Baltimore, Maryland, USA, August 2006.
[7] U. W. Eisenecker and K. Czarnecki, Generative Programming: Methods, Tools, and Applications, AddisonWesley, 2000.
[19] Igor Ivkovic, Kostas Kontogiannis, Using Formal Concept Analysis to Establish Model Dependencies, in Proceedings of International Symposium on Information Technology: Coding and Computing (ITCC), 2005.
[8] A. van Deursen and P. Klint, Domain-Specific Language Design Requires Feature Descriptions, Journal of Computing and Information Technology, 2001. [9] Timo Asikainen, Modelling Methods for Managing Variability of Configurable Software Product Families, Licentiate thesis, Helsinki University of Technology, 2004.
[20] B.Ganter and R. Wille, Formal Concept Analysis: Mathematical Foundations, Berlin: Springer Verlag, 1999.
386
