A Process for Documenting Variability Design Rationale of Flexible ...

A Process for Documenting Variability Design Rationale of Flexible and Adaptive PLAs Jessica D´ıaz1 , Jennifer P´erez1, Juan Garbajosa1, and Alexander L. Wolf2 1

Technical University of Madrid (UPM) - Universidad Polit´ecnica de Madrid, Systems & Software Technology Group (SYST), E.U. Inform´ atica, Madrid, Spain [email protected], {jenifer.perez,jgs}@eui.upm.es 2 Department of Computing, Imperial College London, London, UK [email protected]

Abstract. Variability is a means for evolution of component-based architectures, driving flexible and adaptive architectures. In recent years, researches have emphasized the need for documenting architectural knowledge to maintain and evolve software, i.e. the need for documenting not only the design of the solution, but also the decisions driving the design and their rationale. However, few approaches document the architectural knowledge behind variability, known as variability design rationale. This paper presents the process for documenting variability design rationale of flexible and adaptive architectures alongside their architectural description. This process is supported by the metamodels Flexible-PLA and Product-Line Architectural Knowledge which define the modeling primitives to completely describe the structure of product-line architectures and to document variability design rationale, respectively. The tool FPLA implements these modeling primitives supporting the specification of architectural models ready to be involved in a modeldriven development process. It is illustrated with an example. Keywords: Variability design rationale, product-line architectures.

1

Introduction

The specification of variability is a backbone in the development but also in the evolution of families of products, widely known as software product lines (SPLs). Architectural descriptions, and especially architectural variability modeling has become a recurring issue on numerous workshops and conferences due to the relevance that architectural variability has in the evolution of component-based architectures, specifically product-line architectures (PLAs) [14,3]. Although more recently, a second recurring issue is the documentation of architectural knowledge [1,4,9,23], i.e. the capturing of the decisions driving the design and their rationale. Both issues provide the basis to address software evolution. The first one drives the description of flexible and adaptive architectures1 , while the 1

Flexibility is concerned with variability definition at a given point of time, whereas adaptability is concerned with variation over time.

R. Meersman, T. Dillon, and P. Herrero (Eds.): OTM 2011 Workshops, LNCS 7046, pp. 612–621, 2011. c Springer-Verlag Berlin Heidelberg 2011 

Documenting Variability Design Rationale of PLAs

613

second one provides the insight necessary to guide software evolution. However, both issues present several challenges that still have to be dealt with. First, most current approaches supporting architectural descriptions [8,6,20] only consider architectural variability specification by modifying the configuration of the PLA in terms of adding or removing components and connections (external variability). From our experience in developing SPLs [13], it is also necessary to specify variations inside components (internal variability). Several approaches describe this internal variability by using inheritance or aggregation to establish relations between components and their variants [2,10]. These approaches may imply (i) replication of variants if these variants crosscut the architecture, and/or (ii) multiple inheritance and ambiguity problem. To deal with internal variability, this work is based on a previous concept called Plastic Partial Component (PPC) [17] that uses the principles of invasive software composition to improve flexibility and reusability of architectures. A PPC is a component with a part of its behavior common for all the products of the SPL, and another one variable for specific products of the SPL. As a result, the variability mechanism underlying PPCs pursues to increase the flexibility and adaptability of architecture design through highly malleable components that can be partially described to implement variability inside components. Second, few approaches address the documentation of the architectural knowledge behind variability —variability design rationale—, i.e. the design decisions driving the variability, their dependencies and rationale. In recent years, researchers have emphasized the need for documenting architectural knowledge to maintain and evolve architectural artifacts [1,4,9,23] and to avoid architectural erosion, drift, or aging [18]. If the explicit capture and documentation of design rationale provide important advantages in software architectures, these advantages are still higher in PLAs because the architecture does not realize the design of a single product, otherwise the design of a family of products. As a result, various stakeholders of various products of a product-line must agree on all design decisions related to the definition of the PLA, for the common and variable parts of the PLA. Therefore, the documentation of variability design rationale has a high strategic value and deep impact on the success of PLAs design, and by extension on the product-line development and evolution [12]. This paper defines the process for documenting the variability design rationale of flexible and adaptive architectures. As variability design rationale should be documented alongside the architectural description, architectural descriptions should support the documentation of knowledge of this sort. Key to this approach is a rich architectural model that combines the architectural concepts that support for internal and external variability with those from the field of architectural knowledge. To support this, two metamodels are required: Flexible-PLA and Product-Line Architectural Knowledge. The first one defines the modeling primitives to specify external and internal variability of architectures using the concept of PPC. The second one defines the modeling primitives to document architectural knowledge, and specifically variability design rationale. The automation of the process is implemented by the tool Flexible-PLA (FPLA).

614

J. D´ıaz et al.

FPLA is an graphical tool that implements the modeling primitives that the metamodels before mentioned define, guiding the construction of models and guaranteeing their correctness. FPLA assists software engineers in specifying and documenting architectural models ready to be involved in a model-driven development (MDD) process. The process defined in this paper is illustrated with an example and several snapshots of the tool FPLA. The structure of this paper is as follows: Section 2 introduces the main concepts of the metamodels Flexible-PLA and Product-Line Architectural Knowledge. Section 3 describes the process for specifying and documenting flexible and adaptive architectures. Section 4 illustrate our proposal using the tool FPLA. Section 5 discusses related work. Finally, conclusions are presented in Section 6.

2

Background

Below, we briefly describe the concepts of the Flexible-PLA metamodel [17] and the PLAK metamodel2 needed for the purposes of this paper. 2.1

Flexible-PLA Metamodel

The Flexible-PLA metamodel defines the modeling primitives to completely describe the structure of PLAs by specifying external variation, but also internal variations. Internal variations are specified using Plastic Partial Components (PPCs). The variability of a PPC is specified using variability points, which hook fragments of code to the PPC known as variants. These variants, as well as components and PPCs, realize the requirements at architectural level. We have stated that those variants that realize crosscutting concerns are called aspects, and those that realize non-crosscutting concerns are called features. Variability points allow us to specify the weaving between the PPC and their variants — aspects or features—. The weaving principles of aspect-oriented programming (AOP) [11] provide the needed functionality to specify where and when extending the PPCs using variants. A formal and more complete definition of the PPC, its metamodel and its graphical metaphor can be found in [17]. 2.2

PLAK Metamodel

The PLAK metamodel defines the modeling primitives to capture architectural knowledge including variability design rationale. The modeling primitives are the following: Closed design decisions (Closed DDs) support the realization of the common structure of SPLs. Open design decisions (Open DDs) support the realization of the variability of SPLs. Open DDs consist of a set of optional design decisions. Optional design decisions (Optional DDs) support each of the variants of an Open DD. Alternative design decisions (Alternative DDs) support the alternative realization of Closed and Open DDs. Constraints, assumptions, 2

The PLAK metamodel is the main contribution of a paper currently under review.

Documenting Variability Design Rationale of PLAs

615

rationale,design, and patterns are the major elements of design rationale models [22] and so adopted in our metamodel. Feature concepts are the concrete representation of requirements in the metamodel. This follows Czarnecki’s feature metamodel [5]. PLA concepts are the concrete representation of architectural design in the metamodel. This follow the Flexible-PLA metamodel. As DDs act as the traceability links between requirements and PLAs, Linkage rules comprise the semantics that establish the bridge between features and PLAs. Linkage rules define the logic to create links between specific concepts of the feature metamodel and specific concepts of the Flexible-PLA metamodel.

3

The Process for Documenting PLAs

This section defines the process for specifying and documenting flexible and adaptive PLAs, taking into account the following issues: (1) Architectural descriptions should support the documentation of variability design rationale. (2) The process should preserve main properties of software architectures. (3) The process should fit into common frameworks for SPL Engineering. Issue (1): As architectural descriptions should support the documentation of variability design rationale, it is important to select the appropriate architectural description language. It should provide completely support for specify variability of PLAs: external but also internal variability. Key to this approach is a rich architectural model that combines the architectural concepts that support for internal and external variability with those from the field of architectural knowledge. We propose the integration of the metamodels Flexible-PLA and Product-Line Architectural Knowledge (see Section 2). As a result, the approach facilitates an incremental architecting process by using flexible and adaptive components —PPCs— in which all design decisions and rationale driving architectural design are integrally captured and related. Issue (2): Since the main properties of software architectures —abstraction and encapsulation— must be preserved, the definition of PPCs and the rest of variations must be specified without mixing these variability specifications with the core descriptions of software architectures. The black box view of architectural elements must be also preserved. This is why the process to define PLAs is carried out by several steps according to a model decomposition into several views. These views are: core, service, variability, weaving, derivation, and product [17]. As the goal of this paper is to document architectural knowledge —specifically variability design rationale— alongside PLAs descriptions, we have considered a new view to capture the architectural decisions driving the design of the solution, the dependencies between design decisions, and their rationale. Issue (3): The process should fit into common frameworks for SPL Engineering such as that defined by Pohl et al. [19]. This framework defines two subprocesses: domain engineering and application engineering. Domain engineering focuses on defining the common platform for all products of the family, while application engineering focuses on developing products through systematic reuse

616

J. D´ıaz et al.

of the common platform. As a result, the process that we propose provides software engineers with different views depending on the subprocess —domain or application— they are addressing. Therefore, the process to specify and document flexible and adaptive PLAs is defined as follows: → Domain Engineering 1. In the Feature View analysts specify requirements in terms of features: mandatory and optional features, and features groups which consist of a set of alternative grouped features. 2. In the Core View architects specify common (mandatory)components, PPCs, ports, connections, and attachments. 3. In the Rationale View architects document the decisions driving the design: (i) Closed DDs that trace mandatory features with (mandatory)components or PPCs, (ii) Open DDs that trace features which hook feature groups with PPCs, (iii) the alternatives to Closed and Open DDs, and (iv) the constraints, assumptions, rationale, and patterns for these DDs. 4. In the External Variability View architects specify (optional)components, their ports, connections and attachments. 5. In the Rationale View architects document the decisions driving the design: Open DDs that trace optional features with (optional)components, their alternatives, constraints, assumptions, rationale, and patterns. 6. In the Service View architects specify the interfaces and services that components and PPCs provide. 7. In the Internal Variability View architects specify the variability points, variants —features and aspects—, and weavings that constitute PPCs. 8. In the Service View architects specify the services that variants provide. 9. In the Weaving View architects specify the pointcuts and advices of weavings, i.e where and when extending PPCs using variants. 10. In the Rationale View architects document the decisions driving the design: (i) Open DDs that trace feature groups with variability points, and (iii) Optional DDs that trace grouped features with variants —features and aspects—, their alternatives, constraints, assumptions, rationale, etc. Therefore, for the purpose of the domain engineering process, Closed DDs are completely closed (or bound) and Open DDs are intentionally left open (or delayed) to support the customization of the products of SPLs. → Application Engineering 11. In the Derivation View architects specify the configuration of PPCs for a given product of the family, i.e. variability points are resolved for a specific product of the family, and also indicates those optional components, connectors and attachments which are mandatory for the product. 12. In the Rationale View architects bound Open DDs to the appropriate Optional DD.

Documenting Variability Design Rationale of PLAs

617

13. In the Product View architects can verify the result of applying the selections of the derivation view. It extends the core architecture by providing the final architecture description of a given product of the family. Therefore, the derivation of products implies the binding of all Open DDs to the appropriate options, i.e. their transformation into Closed DDs. Summing up, flexible and adaptive PLAs are defined by specifying the components —mandatory and/or optional—, PPCs, ports, connectors, attachments, interfaces, services, variability points, features, variants, and weavings. Then, PLAs are documented by specifying the {Closed, Open,Optional,Alternative} DDs, as well as their constraints, assumptions, rationale, and patterns.

4

Illustrating the Process

This section describes a scenario to illustrate the use of our approach using the tool FPLA3 . The scenario exemplifies a SPL for banking systems. Banking systems typically consist of a set of core features that offer their functionality to ATM machines. From all the functionalities banking systems provide, this example focuses on that of maintaining accounts balance. This functionality must fulfill the non-functional requirement of availability. Some products of this SPL require strict 24/7 availability, while others allow a more relaxed, non-strict availability. Following the process described in Section 3, analysts specify the requirements in terms of features. Fig. 1 shows the feature model for this example in which we have considered the following features: ATMFeature, AccountBalanceFeature and Availability24/7Feature. All of them are mandatory as it is represented by fulled circles. The feature Availability24/7Feature has a XOR feature group in which only one of the grouped features can be selected to derive a specific product: strict or non-strict availability.

Fig. 1. Banking systems SPL - Step 1: feature model 3

https://syst.eui.upm.es/FPLA/home/

618

J. D´ıaz et al.

Following the process described in Section 3, architects should specify the core view of the PLA, i.e. the realization of the feature model at architectural level. Fig. 2 shows the core view in which the component ATM and the PPC Balance are connected by the connector c. At that moment, the architects made several design decisions such as follows. As the architectural element implementing the feature AccountBalance should implement availability in its two variants, this feature is realized by a PPC called Balance which support this variability (see ClosedDD 001 in Fig. 4). Availability is a concern that could crosscut the architecture, i.e. it is a non-functional requirement that could be reused by more than one components in a complete scenario of a SPL for banking systems. As aspects facilitate reusability, the architects decided to implement availability using aspects (see OpenDD 002 in Fig. 4).

Fig. 2. Banking systems SPL - Step 2: core view

Fig. 3. Banking systems SPL - Step 7: internal variability view

Various architectural tactics to realize availability have been proposed [21]. The architects selected active redundancy and passive redundancy tactics to implement strict and non-strict availability, respectively, as follows: Fig. 3 shows the internal variability view in which the PPC Balance defines two variability

Documenting Variability Design Rationale of PLAs

619

points, Updating and RequestManaging, and the aspects that implement active and passive redundancy. Then, the weavings that specify where and when extending the PPC Balance using the aspects, should be defined. Fig. 4 shows the design decisions driving these solutions, including variability design rationale (see OptionalDDs ActiveRedundancy and PassiveRedudancy in Fig. 4). Finally, in the Derivation View, the product architect resolve the variability points to derive a specific product. In this scenario, the architect could select the weavings to extend the PPC Balance to implement strict or non-strict availability4 .

Fig. 4. Banking systems SPL - Step 3, 5 and 10: architectural knowledge view

In this scenario a PLA has been documented applying the process and using FPLA. Once the model has been completed, FPLA supports the automatic generation of a domain-specific language associated to the architectural model built. It is contained in an XML file and can work as input for many different tools with different purposes such as code generation or change impact analysis.

5

Discussion

Moahn and Ramesch [15,16] assert that the documentation of design decisions associated with variations and the capability to trace the life of these variations are key to effectively support evolution of SPLs. In [7], the authors propose a grammar to specify design rationale, including variability design rationale. However, the concept of variability design rationale is very shallow in the sense that it does not include the knowledge about how and why this variability is implemented in the architecture. These works are very close to ours, but they admit that their approaches should be complemented by specialized designmodeling representations to model variation points. In our proposal, aspects 4

Space restrictions does not allow to show the snapshots for all views.

620

J. D´ıaz et al.

and features only specify the behavior to be inserted into the PPC, i.e. they do not specify the pointcuts as AOP does. The pointcut is specified outside the aspects and features. As a result, aspects and features are unaware of the linking context, and they are completely reusable. This makes architectures more flexible and adaptable. This along with the documentation of variability design rationale facilitates the evolution and maintaining tasks.

6

Conclusions and Further Work

This paper defines a process that integrates the documentation of variability design rationale as a view into a view model for describing PLAs. As a result, this paper contributes a novel architecture evolution approach, with a tool support called FPLA, which brings together architectural specification and documentation with the aim of capturing, managing and guiding architectural evolution. The tool FPLA supports the definition of both external and internal variations of the PLA configuration, and the documentation of variability design rationale. It provides architects a model decomposed in several views that makes the PLA description more intuitive and friendly. Since FPLA is based on two metamodels and their PLA descriptions are models, FPLA is ready to be involved in a MDD process to transform its outputs into platform dependent models and to automatically generate code. As future works we plan to generate automatically C# and Java code from FPLA models. We also plan to integrate FPLA with a middleware support in order to execute the generated code from models. Acknowledgment. This work has been partially sponsored by TIN2008-00889E and TIN2009-13849 projects, and by UPM (Researcher Training program). Authors are indebted to David Musat for participating in the development of FPLA.

References 1. Ali Babar, M., Dingsyr, T., Lago, P., Vliet, H.v.: Software Architecture Knowledge Management. Springer, Heidelberg (2009) 2. Bachmann, F., Bass, L.: Managing variability in software architectures. In: SSR 2001: Proceedings of the 2001 Symposium on Software Reusability, pp. 126–132. ACM, New York (2001) 3. Chen, L., Ali Babar, M., Ali, N.: Variability management in software product lines: a systematic review. In: SPLC 2009: Proceedings of the 13th International Software Product Line Conference, pp. 81–90. Carnegie Mellon University (2009) 4. Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nord, R., Stafford, J.A.: Documenting Software Architectures: Views and Beyond, 2nd edn. Addison-Wesley Professional (2010) 5. Czarnecki, K., Helsen, S., Eisenecker, U.W.: Staged configuration through specialization and multilevel configuration of feature models. Software Process: Improvement and Practice 10(2), 143–169 (2005)

Documenting Variability Design Rationale of PLAs

621

6. Dashofy, E.M., Hoek, A.v.d., Taylor, R.N.: A comprehensive approach for the development of modular software architecture description languages. ACM Trans. Softw. Eng. Methodol. 14(2), 199–245 (2005) 7. Galv˜ ao, I., van den Broek, P., Ak¸sit, M.: A model for variability design rationale in spl. In: Proceedings of the Fourth European Conference on Software Architecture: Companion Volume, ECSA 2010, pp. 332–335. ACM, New York (2010) 8. van der Hoek, A., Mikic-Rakic, M., Roshandel, R., Medvidovic, N.: Taming architectural evolution. In: Proceedings of ESEC/FSE-9, pp. 1–10. ACM, New York (2001) 9. Jansen, A., Bosch, J.: Software architecture as a set of architectural design decisions. In: WICSA 2005: Proceedings of 5th Working IEEE/IFIP Conference on Software Architecture, pp. 109–120 (2005) 10. Kakarontzas, G., Stamelos, I., Katsaros, P.: Product line variability with elastic components and test-driven development. In: Proceedings of CIMCA 2008, pp. 146–151. IEEE Computer Society, Washington, DC (2008) 11. Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., Griswold, W.G.: An Overview of AspectJ. In: Lee, S.H. (ed.) ECOOP 2001. LNCS, vol. 2072, pp. 327–353. Springer, Heidelberg (2001) 12. Knodel, J., Muthing, D.: The Role of Rationale in the Design of Product Line Architectures - a Case Study from Industry. In: Rationale Management in Software Engineering, pp. 237–254. Springer, Heidelberg (2006) 13. Magro, B., Garbajosa, J., P´erez, J.: Applied Software Product Line Engineering. In: Applied Software Product Line Engineering, pp. 173–199. Taylor & Francis (2009) 14. Matinlassi, M.: Comparison of software product line architecture design methods: Copa, fast, form, kobra and qada. In: Proceedings of ICSE 2004, pp. 127–136. IEEE Computer Society, Washington, DC (2004) 15. Mohan, K., Ramesh, B.: Managing variability with traceability in product and service families. In: Proceedings of HICSS, pp. 1309–1317 (2002) 16. Mohan, K., Ramesh, B.: Tracing variations in software product families. Commun. ACM 50, 68–73 (2007) 17. P´erez, J., D´ıaz, J., Soria, C.C., Garbajosa, J.: Plastic partial components: A solution to support variability in architectural components. In: Proceedings of WICSA/ECSA 2009, pp. 221–230. IEEE (2009) 18. Perry, D.E., Wolf, A.L.: Foundations for the study of software architecture. SIGSOFT Softw. Eng. Notes 17(4), 40–52 (1992) 19. Pohl, K., B¨ ockle, G., Linden, F.: Software Product Line Engineering: Foundations, Principles and Techniques. Springer, Germany (2005) 20. Razavian, M., Khosravi, R.: Modeling variability in the component and connector view of architecture using uml. In: Proceedings of AICCSA 2008, pp. 801–809. IEEE Computer Society, Washington, DC (2008) 21. Scott, J., Kazman, R.: Realizing and refining architectural tactics: Availability. Tech. rep., Technical report CMU/SEI-2009-TR-006 ESC-TR-2009-006 22. Shahin, M., Liang, P., Khayyambashi, M.: Architectural design decision: Existing models and tools. In: Proceedings of WICSA/ECSA 2009, pp. 293–296 (2009) 23. Tang, A., Avgeriou, P., Jansen, A., Capilla, R., Ali Babar, M.: A comparative study of architecture knowledge management tools. Systems & Software J. (2009)