An MDA Approach for Variability Management in Product-Line Engineering Andr´e L. Santos1 *, Ant´onia Lopes1 , and Kai Koskimies2 1
Department of Informatics, Faculty of Sciences, University of Lisbon Campo Grande, 1700 Lisboa, Portugal {andre.santos,mal}@di.fc.ul.pt 2 Institute of Software Systems, Tampere University of Technology P.O.BOX 553, FIN-33101 Tampere, Finland
[email protected]
Abstract. Object-oriented frameworks play an essential role in largescale software development, namely for implementing product-line architectures (PLAs). This paper presents an ongoing PhD work on an MDA approach for specialization of framework-based PLAs. The main contribution is an approach for bridging the gap between domain and application engineering activities in product-line development. Our goal is to develop a technique that leverages the difficulty on PLA comprehension and learning, provides validation mechanisms for specializations, and gives support for documentation of PLA variability and its specializations. This paper presents a layered model and proposes a specialization process that drives the developer in a stepwise fashion, by manipulating variability models at different abstraction levels.
1
Introduction
A software product-line [1] consists of a family of products belonging to a certain application domain, which are based on a common architecture – the product-line architecture (PLA). A specialization consists in a product that is built upon the PLA. The specialization process is often called product derivation. A key issue in product-lines is variability management in product derivations, handling the mechanisms for achieving variation within the different applications. In order to bridge the gap between PLA and its specializations, the variability scope of the product-line has to be identified and the mechanisms to achieve variation have to be implemented. A well-identified part where variation can occur is called a variation point. The development in product-lines is divided into domain engineering and application engineering. Domain engineering deals with the development of the PLA, while application engineering handles the development of the distinct products based on it (specializations). Figure 1 illustrates the described concepts. ?
On leave at (2) with the support of the Portuguese Funda¸c˜ ao para a Ciˆencia e Tecnologia
Fig. 1. Domain and application engineering in software product-lines
Development strategies based on product-lines have proven to be adequate for achieving large-scale software reuse and reduced time-to-market [2]. (Objectoriented) frameworks [3,4] play an important role in product-line engineering, since they are a popular way to implement PLAs [1]. A framework is a set of classes that embodies an abstract design for solutions to a family of related problems. An application that is developed using a framework is called a specialization, analogously to the PLA specialization concept. In framework-based PLAs, domain engineering consists in the development of the framework, while application engineering consists in using the framework for developing an application. A hot spot [5] is a design solution within the framework which supports certain variation in the specializations. In the case of PLAs, a hot spot implements the mechanism for achieving variation in a certain variation point. Our approach to product-line engineering assumes framework-based PLAs and is applicable to existing ones. Performing product derivations in frameworkbased PLAs currently faces difficulties related to framework learning [6], specialization process, correctness of specializations, evolution, and documentation [2,7]. Brooks distinguishes essential and accidental difficulty in the development of software systems [8]. The first corresponds to the inherent complexity in the nature of software. The latter is related with characteristics that attend the development but are not inherent. Although frameworks support large-scale reusability in software development, learning and using them are still considered difficult tasks. The development of framework specializations is faced with significant accidental difficulty, due to the need of correctly understand the variability mechanisms and cope with framework rules. Another important issue is related to separation of concerns [9] (SoC), i.e. the ability to identify, encapsulate, and manipulate those parts of software that are relevant to a particular concern (e.g. concept, goal, purpose) [10]. The capability of having a good separation of concerns in framework specializations is advantageous for their maintenance, reuse, and comprehension. OMG’s MDA initiative [11] aims to introduce a paradigm shift in software development, where a system is built using the following types of models: the Computation Independent Model (CIM), the Platform Independent Model (PIM), and Platform Specific Models (PSMs). A CIM describes the system from a computation-independent viewpoint – it does not show details of the structure of the system, and it is close to the application domain concepts. A PIM describes
the implementation of a system, independently of the technology to be adopted. In turn, a PSM describes the implementation of a system considering a specific technology (e.g. J2EE, .NET). PSMs for different platforms are obtained from the PIM through transformation rules. MDA concentrates on one aspect of variability – the variation of the implementation platform. Our approach to product-line engineering addresses the problem of handling other types of variations, namely the variable parts within the product family. Our work is an MDA approach in the sense that it allows model-based variability management of PLAs, considering different abstraction levels and concerns, which are relevant to specializations. We propose a layered model that could be situated between MDA’s CIM and PIM, focusing on the architectural variation of a product-line. Our approach is based on the adoption of a high-level abstraction for describing PLA variability conceptually, an implementation level of abstraction for describing patterns for PLA specialization, and an application-specific level of abstraction for describing the increments that a specialization introduces in a product. Bridging the gap between domain and application engineering is a main concern in the approach. It intends to allow a stepwise specialization process that is adaptable to product-specific goals, where the starting point is a selection of PLA’s features that drives the process to relevant specialization patterns, which are automatically customized according to the product requirements. This technique does not intend to be a full-scale MDA approach, since in order to have the complete implementation of specializations, product-specific code is required. However, the previously described problems related to accidental difficulty in PLA specializations are addressed. The remainder of this paper is organized as follows. Section 2 presents our approach for model-based product derivations of PLAs. Section 3 presents notations and mechanisms for describing the variability, throughout a case study with concrete examples. Section 4 presents related work, while Section 5 discusses benefits of the proposed approach and future work.
2
Overview of the approach
Our approach is based on the representation of the PLA variability by models at different abstraction levels, and different views within those levels. Section 2.1 describes the proposed layered model and the variability management processes supported by our approach. Section 2.2 details the modeling abstractions and their relationships. 2.1
Layered model
We propose the following abstraction layers, from higher to lower level (see Figure 2):
Fig. 2. Model-driven approach for PLA specialization
Conceptual Variation Model (CVM) – This type of model describes the variability offered by a PLA at a conceptual level of abstraction, therefore independently of the implementation of the variability mechanisms. A CVM is intended to describe PLA variability in terms of its features. A CVM instantiation represents a set of selected features of the product-line – often called a feature configuration. A CVM is associated with a PLA and gives a high-level overview of the variability. The CVM resembles MDA’s CIM concept. Application Independent Model (AIM) – This type of model describes PLA variability at a level of abstraction of the actual variability mechanisms of the framework. The work in [12] introduces the concept of specialization pattern. This type of patterns are a variant of design patterns, especially intended for describing framework extension points related to high-level specialization goals. In contrast to design patterns, specialization patterns are typically framework-specific. Each AIM describes a specialization pattern. AIMs themselves can have configurable parts – in this case they are called AIM templates. An AIM instance represents a configured AIM template. AIMs are instantiated by AIM instantiation rules. Several AIMs are associated with a PLA, each one associated to a feature. In addition, instantiation rules can also be associated with a feature.
Application Specific Model (ASM) – This type of model describes increments that a specialization contains in addition to the PLA, within the scope of a specialization pattern. Each ASM is associated with a single AIM, as it is an instantiation of its specialization pattern. An ASM has to conform to the associated AIM. A specialization is intended to have a set of ASMs, which are able to derive its implementation structure. This set of ASMs resemble MDA’s PIM concept, in the sense that they both describe a system at an architectural abstraction level. Application Specific Code (ASC) – This corresponds to the specific source code of an application, which is not able to be obtained by code generation from the modeling abstractions (CVM, AIM, ASM). ASC is intended to fit in the structure imposed by ASMs. Consider the domain and application engineering perspectives, and the different levels of abstraction: conceptual, architectural, and application-specific modeling; and product’s full implementation. At the conceptual level, a CVM is developed by domain engineers, and can then be used by an application engineer for defining a CVM instance – a concrete variability configuration. At the architectural level, domain engineers develop AIM templates. In addition, they define mappings between CVM and AIM elements, which associate either AIM templates or instantiation rules to CVM features. From an application engineering viewpoint, by having a CVM instance, a set of instantiated AIMs can be automatically obtained based on the selected features and the mappings defined by domain engineers. For each of the AIM instances, a corresponding ASM is then developed. Having the set of ASMs for a specialization, the source code that implements its structure can then be derived. Finally, it is then augmented with ASC, in order to have a full implementation of the product. Figure 3 presents in a single activity diagram, the related tasks of specifying variability (domain engineering) and product derivation (application engineering), since the latter is dependent on the deliverables of the first. An existing PLA developed by domain engineers is assumed. 2.2
Modeling concepts
The Conceptual Variation Model (CVM) describes the product-line variability conceptually. A feature modeling notation was originally proposed in the Feature-Oriented Domain Analysis (FODA) method [13], while posteriorly extended and adapted in other approaches such as cardinality-based feature models [14], feature graphs [15], and UML-based feature models [16,17]. We adopted a notation for CVMs based on [14]. Cardinality-based feature models have an hierarchical structure headed by a single root feature. Except for the root, a feature can have an associated cardinality range (i.e. [x..y], where x is the lower and y the upper limit). If the cardinality lower limit is zero, then the feature is optional. Features may have child features, which may be grouped
Fig. 3. The tasks of specifying PLA variability (domain engineering), and product derivation (application engineering)
in order to establish a constraint on the cardinality of the feature group (i.e. , where x is the minimal, and y the maximum). A feature model may have several valid configurations, which can be inferred by analyzing it having the root feature as a starting point. Except for the root, features can be selected according to their cardinalities and group constraints defined in the diagram. If an optional feature is not included in a configuration, its child features are recursively not included, too. In addition, features can require other features. Figure 4 presents the conceptual model for CVMs, based on cardinality-based feature modeling [14].
Fig. 4. Conceptual model for CVMs
Fig. 5. Conceptual model for the relations between the CVM, CVM instances, AIM templates, AIM instances, ASMs, framework and a specialization
The adopted notations for AIMs and ASMs are based on refinements of the concepts of architectural profiles [18] and design/composition forms [19]. The notation was developed having in mind the need of representing framework specialization patterns [12] explicitly, with clear separation between the roles of domain engineering (framework) and application engineering (specializations). An AIM is a model that describes a specialization pattern, where its pattern roles are either domain roles that refer to domain elements (i.e. framework elements), or specific roles for referring to application-specific elements. Specific roles may have relationships with domain roles, imposing structural constraints on the pattern instances. In addition, a specific role may have a constraint itself that can involve other roles. In an AIM template there might be unbound domain roles. However, in an AIM instance, all the domain roles have to be bound to domain elements. The AIMs that are presented to application engineers are all AIM instances. Figure 5 presents the conceptual model of our approach in terms of the relations between the CVM, CVM instances, AIM templates, AIM instances, ASMs, framework and a specialization. A CVM is composed by several features. A CVM instance selects a set of features for a particular specialization. The selection of a feature which an AIM is associated to, simply implies that AIM to
Fig. 6. JHotDraw framework and its variable parts.
be part of the specialization. On the other hand, the selection of a feature which AIM instantiation rules are associated to, implies those rules to take effect on that AIM (i.e. on its roles). For a particular specialization, this allows to obtain AIM instances from a CVM instance. For each AIM instance, the specialization will develop an associated ASM, which introduces application-specific elements where the specific roles are bound to. All the AIM instance’s specific roles must be bound to application-specific elements, and these have to conform to the constraints imposed by the AIMs.
3
Presenting variation points
This section describes how the modeling abstractions proposed by our approach can be used in practice. The framework JHotDraw3 is introduced first as an example of a PLA, with the purpose of being used for illustrations in the forthcoming subsections. 3.1
Example framework: JHotDraw
JHotDraw is a Java GUI framework for applications that deal with technical and structured graphics. Its design relies heavily on some well-known design patterns, and it is considered by the academia to have a good design. Some details of the framework are going to be omitted or simplified in the following subsections, in order to obtain illustrations that are more clear and easy to understand. Figure 6 illustrates the type of layout of the applications based upon JHotDraw, where some variable parts are marked with a circle. The illustrated variable parts are the left-hand side palette, which can be customized with application-specific tools, and the menu bar where application-specific menus can be included. In addition, an application can vary between having a single drawing pane or multiple sub-windows. Having the JHotDraw framework as a PLA, consider the following list of hypothetical application engineering goals for developing specializations: 3
http://www.jhotdraw.org/
1. To have either a single or multi-window application 2. To have an application-specific type of tool in the palette 3. To have an application-specific menu in the menu bar These goals are likely to be relevant for developing applications using JHotDraw, and will be used in the following subsections for describing our technique. 3.2
Conceptual Variation Model (CVM)
Recall that the development of the CVM is a responsibility of domain engineers. Figure 7 presents an example CVM for the JHotDraw framework, considering the variable parts that were described previously. Application is the root feature; SingleWindow and MultiWindow are a group of features with cardinality constraint of (denoted by the special notation that joins the two parent-child links); unfilled circles denote that a feature is optional (Tools, DefaultSelect and Menu), while filled circle features denote compulsory features (AppSpecific). The numbers between square brackets represent the feature cardinality. If a feature has no notational element for cardinality means that it is equal to [0..1] for optional features, or equal to [1] for compulsory features. An underlined feature denotes that an AIM is associated with that feature – consider that the AIM has the same name as the feature. Having knowledge about the domain and reading the diagram, we infer that: an application may be either single window or multi-window; there is the possibility of having tools; if there are tools, there must be at least one application-specific tool; the default select tool is optional; an application may have a maximum of three application-specific menus.
Fig. 7. CVM for the JHotDraw framework
3.3
Conceptual Variation Model (CVM) instance
The application engineer uses the CVM to obtain a CVM instance, i.e. a configuration of features for a particular product. Figure 8 presents an instance of the CVM of Figure 7, where the darker elements indicate the selected features. Notice that the cardinality of the feature AppSpecific is also defined. Having this configuration for a specialization, we can infer that two AIMs corresponding to the features Application and Tools are going to be included in the product derivation.
Fig. 8. CVM instance (possible feature configuration for the CVM of Figure 7)
3.4
Application Independent Model (AIM) templates
Recall that AIM templates are developed by domain engineers. The description will be based on an example following the CVM instance presented in Figure 8. An AIM is a specialization pattern described by class diagrams, where its classes refer to pattern roles instead of concrete classes, and the relationships between those classes represent structural constraints among the pattern participants. This resembles the concept of design form [19] (more details in Section 4). However, in our approach we distinguish between domain and application-specific pattern roles. When presenting AIMs, the darker classes represent domain roles, while blank classes represent specific roles. The domain roles must be bound to existing framework elements, whereas specific roles must be bound to application-specific elements. An AIM template may include rules that govern its instantiation. In the notation used in the examples, these are represented by annotations.
Fig. 9. AIM Application template
Associated with the CVM root, the AIM Application template is presented in Figure 9. Type refers to the main class that implements the application (which can be either single or multi window). We can observe a UML note attached to it, which contains AIM instantiation rules in the form “CVM-feature := Domain-element”, stating that if SingleWindow is a selected feature then the class DrawingApplication is bound to the Type role, and otherwise if MultiWin-
dow selected, would be MDI DrawingApplication to be bound instead. These type of instantiation rules bound concrete classes to pattern roles. Custom refers to the main class that a specialization will develop for implementing the application. We can see a constraint attached in a note stating that the pattern role Custom has cardinality equal to 1. Notice also that Custom has a structural constraint of inheritance to Type. The features Application and SingleWindow of the CVM were handled. Proceeding, Figure 10 presents the AIM Tools template.
Fig. 10. AIM Tools template
We can see several new issues. The role name in the form “AIM-name.AIMrole” denotes a composition relationship. For instance, in the case of Application.Type, it means that this pattern role is a reference to the role Type of the AIM Application. Composition relationships imply that a same concrete class to be bound to both of the composed roles. This mechanism resembles the composition form [19] concept (more details in Section 4). Although roles are referencing others, they can introduce child roles. In this case, the methods createTools() and createButton() were introduced as child roles. In Application.Custom we can see an instantiation rule in the form “CVMfeature :+ Role {...}”, stating that if the DefaultSelect is selected, the createTools() should be augmented with a call to its superclass constructor. In SpecificTool we can see another instantiation rule in the form “CVMfeature :+ cardinality=x”, which adds a constraint to the role, setting its cardinality according to the cardinality of the feature AppSpecific. Yet another issue, is the definition of the constraint “palette add”, stating that for each binding to SpecificTool (one to one association), it must exist a call in createTools() for adding an instance of the bounded class in the application palette. This note does not correspond to an instantiation rule, but to a pattern constraint instead.
Notice also that in this AIM template the role ToolType is already bound to AbstractTool. 3.5
Application Independent Model (AIM) instances and Application Specific Model (ASM)
Recall that AIM instances are presented to application engineers, which have to develop the ASMs in conformance to them. Following the AIM templates of the previous section, Figure 11 presents the AIM Application instance that is presented to application engineers, instantiated according to the CVM instance (SingleWindow was selected in Figure 8). The stereotyped classes represent the pattern roles that are already bound. In this case, we see that Type is bound to DrawingApplication. The task in the corresponding ASM will be to bound the unbound specific roles (Custom).
Fig. 11. AIM Application instance
In Figure 12 we can see an ASM that conforms to the AIM Application instance, which bounds Custom to the class MyApplication.
Fig. 12. ASM Application
Concerning the AIM Tools template, Figure 13 presents the AIM Tools instance that is presented to application engineers according to the CVM instance in Figure 8. The constraint “palette add” is hidden, since it is able to generate
the necessary statements in createTools() once SpecificTool is bound. Notice that Application.Custom is already bound to MyApplication, due to the ASM Application. Since the DefaultSelect feature was not selected, the instantiation rule attached to Application.Custom in the AIM Tools template has no effect.
Fig. 13. AIM Tools instance
Figure 14 presents an ASM that conforms to AIM Tools instance and introduces StarTool and ArrowTool as bindings of SpecificTool.
Fig. 14. ASM Tools
By now, the specialization process would be complete in terms of modeling. The ASMs resulting from a specialization plus associated AIMs, are intended to be able to generate the application’s structural code, as well as behavioral code imposed by the specialization patterns. 3.6
Application Specific Code (ASC)
The ASC represents code that specializations have to develop in addition to the code that can be generated using the modeling abstractions. Figure 15 shows the source code (in Java) that could be generated from the given specialization example. Annotation-like comments indicate the parts generated from the models. Notice the statements that were included by the pattern roles’ constraints
of AIM Tools. The TODO comments mark the locations in the code where the specialization is supposed to add ASC.
1 2
@Application-ASM public class MyApplication extends DrawingApplication {
4 5 6 7 8 9
@Tools-AIM public void createTools(JToolBar palette) { palette.addTool(createButton(new StarTool())); palette.addTool(createButton(new ArrowTool())); } }
11 12 13 14 15 16
@Tools-ASM public class StarTool { public void action() { // TODO: ASC } }
18 19 20 21 22 23
@Tools-ASM public class ArrowTool { public void action() { // TODO: ASC } }
Fig. 15. Specialization code resulting from the example
4
Related work
In [18], an approach for validating UML models against architectural profiles is presented. Architectural profiles are extended UML profiles for describing architectural constraints and rules for a given domain. The main goal of this approach is to check conformance of UML class diagrams against architectural profiles, and it is argued that the approach is helpful for enforcing conventions of product-line architectures. A generalization of [18] as been proposed in [19], introducing the concept of design profile. Design profiles are composed by design forms, composition forms and global forms (not detailed here). A design form, given as UML class diagram, is a pattern-like description of structural properties that must be satisfied by models that are intended to conform to the design profile. Design forms resemble the descriptions of structural solutions as class diagrams, for instance like the ones used in the GoF patterns book [20]. An instantiation of a design form is a model that conforms to it – concrete classes assume pattern roles, and become stereotyped with the role names (i.e. names of the classes in the design form). Since the binding of pattern roles from different design forms may overlap classes, there is the mechanism of composition forms, which defines role
overlapping relationships. In this way, different pattern roles that have a composition relationship are bound to the same concrete class in different design form instantiations. Our approach adopted similar mechanisms to design forms and composition forms. In [14] it is presented a template-based approach for mapping feature models to representations of variability in UML models. Our approach also applies a template-based mechanism in AIMs, however, focusing on exploiting the specific characteristics of framework specialization patterns. COVAMOF [21] is a framework for managing the variability provided by a software product-line that allows representation of the variability at different abstraction layers, which focuses on the configurability of the architecture assets, having for instance specific abstractions for modeling dependencies. Our approach focuses on the specifics of OO framework-based PLAs and their specialization mechanisms, and intends to support variability which implies that specializations develop application-specific components for extending the PLA. COVAMOF does not seem to address these issues as a primary concern.
5
Discussion and further work
MDA’s PIM to PSM transformations intend to allow variability of the implementation platform. Our approach focuses on architectural variability, and could “fit” in MDA’s model layering, in such a way that the sets of ASMs would play the role of the PIM. The platform variability could be then achieved by using those ASMs to obtain PSMs for different platforms. On the other hand, since many framework-based PLAs are already dependent on a technology (e.g. Java, C++, C#), platform variation through PIM to PSMs transformations does not seem to be applicable in these cases. However, for instance when we have a framework that has different implementations in several technologies (e.g. CORBA), deriving different types of PSMs in order to achieve platform variability in specializations becomes appealing. The benefits of combining MDA with configurable product families are outlined in [22]. Our approach does not aim to provide full-scale MDA technique, since ASC has to be developed for having complete implementation of specializations. However, it addresses the fundamental problems related to PLA learning and development of (correct) specializations. Since the adaptation of the specialization process to product requirements hides framework complexity, it is intended to improve usability in the specialization process, and therefore its efficiency. Another issue related to usability is related with the possibility to assist the development of ASMs. Since AIMs formally describe specialization patterns, the required elements in pattern instantiations can be inferred from the model and semi-automatically generate ASM elements, leaving the variable issues such as class names to be defined by the specialization developers. The validation of ASMs against AIMs is advantageous for reducing incorrect specializations in terms of structure and imposing PLA rules.
In terms of documentation, CVMs can be simultaneously a documentation artifact which gives a conceptual overview of the variability offered by the productline, and a development artifact for specializations. Nevertheless, a CVM instance also constitutes specializations’ documentation that describes the adopted product-line features. By describing specialization patterns, AIMs can constitute a significant part of PLA documentation for accessing variation points, and serve simultaneously as a development artifact for specializations. ASMs can also constitute a significant part of the documentation of a PLA specialization, and simultaneously are a development artifact of it. The types of AIM instantiation rules, as well as the types of constraints in AIM roles, are under on-going work, by analyzing the variability mechanisms implemented in existing framework-based PLAs. In order to provide tool support for implementing the described approach, the scope of the rules/constraints must be well-identified.
References 1. Jan Bosch. Design and use of software architectures: adopting and evolving a product-line approach. ACM Press/Addison-Wesley Publishing Co., 2000. 2. Jan Bosch. Product-line architectures in industry: a case study. In ICSE ’99: Proceedings of the 21st International Conference on Software Engineering, 1999. 3. Ralph E. Johnson and Brian Foote. Designing reusable classes. Journal of ObjectOriented Programming, 1988. 4. Mohamed E. Fayad, Douglas C. Schmidt, and Ralph E. Johnson. Building application frameworks: object-oriented foundations of framework design. John Wiley & Sons, Inc., 1999. 5. Wolfgang Pree. Design patterns for object-oriented software development. ACM Press/Addison-Wesley Publishing Co., 1995. 6. Simon Moser and Oscar Nierstrasz. The effect of object-oriented frameworks on developer productivity. Computer, 29:45–51, 1996. 7. Sybren Deelstra, Marco Sinnema, and Jan Bosch. Experiences in software product families: Problems and issues during product derivation. In Proceedings of the Third International Software Product Line Conference (SPLC), 2004. 8. Jr. Frederick P. Brooks. No silver bullet: essence and accidents of software engineering. Computer, 20:10–19, 1987. 9. D. L. Parnas. On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1972. 10. Harold Ossher and Peri Tarr. Using multidimensional separation of concerns to (re)shape evolving software. Commun. ACM, 44:43–50, 2001. 11. OMG. MDA Guide Version 1.0.1. OMG, 2003. 12. Juha Hautam¨ aki. Pattern-Based Tool Support for Frameworks: Towards Architecture-Oriented Software Development Environment. PhD thesis, Tampere University of Technology, 2005. 13. K. Kang, S. Cohen, J. Hess, W. Nowak, and S. Peterson. Feature-oriented domain analysis (FODA) feasibility study. Technical report, Carnegie Mellon University, 1990.
14. Krzysztof Czarnecki, Simon Helsen, and Ulrich W. Eisenecker. Formalizing cardinality-based feature models and their specialization. Software Process: Improvement and Practice, 10(1):7–29, 2005. 15. Jilles Van Gurp, Jan Bosch, and Mikael Svahnberg. On the notion of variability in software product lines. In Proceedings of the Working IEEE/IFIP Conference on Software Architecture (WICSA’01), 2001. 16. Matthias Clauss. Modeling variability with UML. In Net.ObjectDays, 2001. 17. Tewfik Ziadi, Lo¨ıc H´elou¨et, and Jean-Marc J´ez´equel. Towards a uml profile for software product lines. In PFE, 2003. 18. Petri Selonen and Jianli Xu. Validating UML models against architectural profiles. In ESEC/FSE-11: Proceedings of the 9th European software engineering conference held jointly with 11th ACM SIGSOFT international symposium on Foundations of software engineering, 2003. 19. Imed Hammouda, Mika Pussinen, Anna Ruokonen, Kai Koskimies, and Tarja Syst¨ a. Design profiles: Specifying and using structural patterns in uml. In Proceedings of NWUML 2005, 2005. 20. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design patterns: elements of reusable object-oriented software. Addison-Wesley Longman Publishing Co., Inc., 1995. 21. Marco Sinnema, Sybren Deelstra, Jos Nijhuis, and Jan Bosch. COVAMOF: A framework for modeling variability in software product families. In Proceedings of the Third International Software Product Line Conference (SPLC), 2004. 22. Sybren Deelstra, Marco Sinnema, Jilles van Gurp, and Jan Bosch. Model driven architecture as approach to manage variability in software product families. In Proceedings of the Workshop on Model Driven Architectures: Foundations and Applications, 2003.
