An MDA Approach for Variability Managementin Product-Line Engineering

Andre L. Santos1*, Antonia Lopes1, and Kai Koskimies2

1 Department of Informatics, Faculty of Sciences, University of LisbonCampo Grande, 1700 Lisboa, Portugal{andre.santos,mal}@di.fc.ul.pt

2 Institute of Software Systems, Tampere University of TechnologyP.O.BOX 553, FIN-33101 Tampere, Finland

kai.koskimies@tut.fi

Abstract. Object-oriented frameworks play an essential role in large-scale software development, namely for implementing product-line ar-chitectures (PLAs). This paper presents an ongoing PhD work on anMDA approach for specialization of framework-based PLAs. The maincontribution is an approach for bridging the gap between domain andapplication engineering activities in product-line development. Our goalis to develop a technique that leverages the difficulty on PLA comprehen-sion and learning, provides validation mechanisms for specializations, andgives support for documentation of PLA variability and its specializa-tions. This paper presents a layered model and proposes a specializationprocess that drives the developer in a stepwise fashion, by manipulatingvariability models at different abstraction levels.

1 Introduction

A software product-line [1] consists of a family of products belonging to a certainapplication domain, which are based on a common architecture – the product-linearchitecture (PLA). A specialization consists in a product that is built upon thePLA. The specialization process is often called product derivation. A key issuein product-lines is variability management in product derivations, handling themechanisms for achieving variation within the different applications. In order tobridge the gap between PLA and its specializations, the variability scope of theproduct-line has to be identified and the mechanisms to achieve variation haveto be implemented. A well-identified part where variation can occur is called avariation point.

The development in product-lines is divided into domain engineering andapplication engineering. Domain engineering deals with the development of thePLA, while application engineering handles the development of the distinct prod-ucts based on it (specializations). Figure 1 illustrates the described concepts.

? On leave at (2) with the support of the Portuguese Fundacao para a Ciencia eTecnologia

Fig. 1. Domain and application engineering in software product-lines

Development strategies based on product-lines have proven to be adequatefor achieving large-scale software reuse and reduced time-to-market [2]. (Object-oriented) 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 ofclasses that embodies an abstract design for solutions to a family of relatedproblems. An application that is developed using a framework is called a spe-cialization, analogously to the PLA specialization concept. In framework-basedPLAs, domain engineering consists in the development of the framework, whileapplication engineering consists in using the framework for developing an appli-cation. A hot spot [5] is a design solution within the framework which supportscertain variation in the specializations. In the case of PLAs, a hot spot imple-ments the mechanism for achieving variation in a certain variation point.

Our approach to product-line engineering assumes framework-based PLAsand is applicable to existing ones. Performing product derivations in framework-based PLAs currently faces difficulties related to framework learning [6], spe-cialization process, correctness of specializations, evolution, and documentation[2,7].

Brooks distinguishes essential and accidental difficulty in the developmentof software systems [8]. The first corresponds to the inherent complexity inthe nature of software. The latter is related with characteristics that attendthe development but are not inherent. Although frameworks support large-scalereusability in software development, learning and using them are still considereddifficult tasks. The development of framework specializations is faced with signif-icant accidental difficulty, due to the need of correctly understand the variabilitymechanisms 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 thatare relevant to a particular concern (e.g. concept, goal, purpose) [10]. The ca-pability of having a good separation of concerns in framework specializations isadvantageous for their maintenance, reuse, and comprehension.

OMG’s MDA initiative [11] aims to introduce a paradigm shift in software de-velopment, where a system is built using the following types of models: the Com-putation Independent Model (CIM), the Platform Independent Model (PIM),and Platform Specific Models (PSMs). A CIM describes the system from acomputation-independent viewpoint – it does not show details of the structure ofthe 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 specifictechnology (e.g. J2EE, .NET). PSMs for different platforms are obtained fromthe PIM through transformation rules.

MDA concentrates on one aspect of variability – the variation of the im-plementation platform. Our approach to product-line engineering addresses theproblem of handling other types of variations, namely the variable parts withinthe product family. Our work is an MDA approach in the sense that it allowsmodel-based variability management of PLAs, considering different abstractionlevels and concerns, which are relevant to specializations. We propose a layeredmodel that could be situated between MDA’s CIM and PIM, focusing on thearchitectural variation of a product-line.

Our approach is based on the adoption of a high-level abstraction for de-scribing PLA variability conceptually, an implementation level of abstractionfor describing patterns for PLA specialization, and an application-specific levelof abstraction for describing the increments that a specialization introduces ina product. Bridging the gap between domain and application engineering is amain concern in the approach. It intends to allow a stepwise specialization pro-cess that is adaptable to product-specific goals, where the starting point is aselection of PLA’s features that drives the process to relevant specializationpatterns, which are automatically customized according to the product require-ments. This technique does not intend to be a full-scale MDA approach, since inorder to have the complete implementation of specializations, product-specificcode is required. However, the previously described problems related to acciden-tal difficulty in PLA specializations are addressed.

The remainder of this paper is organized as follows. Section 2 presents ourapproach for model-based product derivations of PLAs. Section 3 presents no-tations and mechanisms for describing the variability, throughout a case studywith concrete examples. Section 4 presents related work, while Section 5 dis-cusses 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 atdifferent abstraction levels, and different views within those levels. Section 2.1describes the proposed layered model and the variability management processessupported by our approach. Section 2.2 details the modeling abstractions andtheir relationships.

2.1 Layered model

We propose the following abstraction layers, from higher to lower level (see Fig-ure 2):

Fig. 2. Model-driven approach for PLA specialization

Conceptual Variation Model (CVM) – This type of model describes the vari-ability offered by a PLA at a conceptual level of abstraction, therefore indepen-dently of the implementation of the variability mechanisms. A CVM is intendedto describe PLA variability in terms of its features. A CVM instantiation rep-resents a set of selected features of the product-line – often called a featureconfiguration. A CVM is associated with a PLA and gives a high-level overviewof the variability. The CVM resembles MDA’s CIM concept.

Application Independent Model (AIM) – This type of model describes PLAvariability at a level of abstraction of the actual variability mechanisms of theframework.

The work in [12] introduces the concept of specialization pattern. This typeof patterns are a variant of design patterns, especially intended for describingframework extension points related to high-level specialization goals. In contrastto design patterns, specialization patterns are typically framework-specific.

Each AIM describes a specialization pattern. AIMs themselves can have con-figurable parts – in this case they are called AIM templates. An AIM instancerepresents a configured AIM template. AIMs are instantiated by AIM instanti-ation rules. Several AIMs are associated with a PLA, each one associated to afeature. In addition, instantiation rules can also be associated with a feature.

Application Specific Model (ASM) – This type of model describes incrementsthat a specialization contains in addition to the PLA, within the scope of aspecialization pattern. Each ASM is associated with a single AIM, as it is aninstantiation of its specialization pattern. An ASM has to conform to the as-sociated AIM. A specialization is intended to have a set of ASMs, which areable to derive its implementation structure. This set of ASMs resemble MDA’sPIM concept, in the sense that they both describe a system at an architecturalabstraction level.

Application Specific Code (ASC) – This corresponds to the specific sourcecode of an application, which is not able to be obtained by code generation fromthe modeling abstractions (CVM, AIM, ASM). ASC is intended to fit in thestructure imposed by ASMs.

Consider the domain and application engineering perspectives, and the dif-ferent levels of abstraction: conceptual, architectural, and application-specificmodeling; and product’s full implementation. At the conceptual level, a CVM isdeveloped by domain engineers, and can then be used by an application engi-neer for defining a CVM instance – a concrete variability configuration. At thearchitectural level, domain engineers develop AIM templates. In addition, theydefine mappings between CVM and AIM elements, which associate either AIMtemplates or instantiation rules to CVM features.

From an application engineering viewpoint, by having a CVM instance, aset of instantiated AIMs can be automatically obtained based on the selectedfeatures and the mappings defined by domain engineers. For each of the AIMinstances, a corresponding ASM is then developed. Having the set of ASMs for aspecialization, the source code that implements its structure can then be derived.Finally, it is then augmented with ASC, in order to have a full implementationof the product.

Figure 3 presents in a single activity diagram, the related tasks of specifyingvariability (domain engineering) and product derivation (application engineer-ing), since the latter is dependent on the deliverables of the first. An existingPLA developed by domain engineers is assumed.

2.2 Modeling concepts

The Conceptual Variation Model (CVM) describes the product-line variabil-ity conceptually. A feature modeling notation was originally proposed in theFeature-Oriented Domain Analysis (FODA) method [13], while posteriorly ex-tended 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 featuremodels have an hierarchical structure headed by a single root feature. Except forthe root, a feature can have an associated cardinality range (i.e. [x..y], where xis the lower and y the upper limit). If the cardinality lower limit is zero, thenthe feature is optional. Features may have child features, which may be grouped

Fig. 3. The tasks of specifying PLA variability (domain engineering), and productderivation (application engineering)

in order to establish a constraint on the cardinality of the feature group (i.e.<x-y>, where x is the minimal, and y the maximum).

A feature model may have several valid configurations, which can be inferredby analyzing it having the root feature as a starting point. Except for the root,features can be selected according to their cardinalities and group constraintsdefined in the diagram. If an optional feature is not included in a configuration,its child features are recursively not included, too. In addition, features canrequire other features. Figure 4 presents the conceptual model for CVMs, basedon cardinality-based feature modeling [14].

Fig. 4. Conceptual model for CVMs

Fig. 5. Conceptual model for the relations between the CVM, CVM instances, AIMtemplates, AIM instances, ASMs, framework and a specialization

The adopted notations for AIMs and ASMs are based on refinements ofthe concepts of architectural profiles [18] and design/composition forms [19].The notation was developed having in mind the need of representing frameworkspecialization patterns [12] explicitly, with clear separation between the roles ofdomain engineering (framework) and application engineering (specializations).

An AIM is a model that describes a specialization pattern, where its patternroles are either domain roles that refer to domain elements (i.e. framework el-ements), or specific roles for referring to application-specific elements. Specificroles may have relationships with domain roles, imposing structural constraintson the pattern instances. In addition, a specific role may have a constraint itselfthat can involve other roles. In an AIM template there might be unbound do-main roles. However, in an AIM instance, all the domain roles have to be boundto domain elements. The AIMs that are presented to application engineers areall AIM instances.

Figure 5 presents the conceptual model of our approach in terms of therelations 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. Theselection 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 whichAIM instantiation rules are associated to, implies those rules to take effect onthat AIM (i.e. on its roles). For a particular specialization, this allows to obtainAIM 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 boundto. All the AIM instance’s specific roles must be bound to application-specificelements, 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 approachcan be used in practice. The framework JHotDraw3 is introduced first as anexample of a PLA, with the purpose of being used for illustrations in the forth-coming subsections.

3.1 Example framework: JHotDraw

JHotDraw is a Java GUI framework for applications that deal with technical andstructured 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 theframework are going to be omitted or simplified in the following subsections, inorder to obtain illustrations that are more clear and easy to understand.

Figure 6 illustrates the type of layout of the applications based upon JHot-Draw, where some variable parts are marked with a circle. The illustratedvariable parts are the left-hand side palette, which can be customized withapplication-specific tools, and the menu bar where application-specific menuscan be included. In addition, an application can vary between having a singledrawing pane or multiple sub-windows.

Having the JHotDraw framework as a PLA, consider the following list ofhypothetical application engineering goals for developing specializations:3 http://www.jhotdraw.org/

1. To have either a single or multi-window application2. To have an application-specific type of tool in the palette3. 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, consideringthe variable parts that were described previously. Application is the root feature;SingleWindow and MultiWindow are a group of features with cardinality con-straint of <1> (denoted by the special notation that joins the two parent-childlinks); unfilled circles denote that a feature is optional (Tools, DefaultSelect andMenu), while filled circle features denote compulsory features (AppSpecific). Thenumbers between square brackets represent the feature cardinality. If a featurehas no notational element for cardinality means that it is equal to [0..1] for op-tional features, or equal to [1] for compulsory features. An underlined featuredenotes that an AIM is associated with that feature – consider that the AIMhas the same name as the feature. Having knowledge about the domain andreading the diagram, we infer that: an application may be either single windowor multi-window; there is the possibility of having tools; if there are tools, theremust 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 con-figuration of features for a particular product. Figure 8 presents an instance ofthe CVM of Figure 7, where the darker elements indicate the selected features.Notice that the cardinality of the feature AppSpecific is also defined. Having thisconfiguration for a specialization, we can infer that two AIMs correspondingto the features Application and Tools are going to be included in the productderivation.

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 descriptionwill 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 classesrefer to pattern roles instead of concrete classes, and the relationships betweenthose classes represent structural constraints among the pattern participants.This resembles the concept of design form [19] (more details in Section 4). How-ever, in our approach we distinguish between domain and application-specificpattern roles.

When presenting AIMs, the darker classes represent domain roles, while blankclasses represent specific roles. The domain roles must be bound to existingframework elements, whereas specific roles must be bound to application-specificelements. An AIM template may include rules that govern its instantiation. Inthe 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 inFigure 9. Type refers to the main class that implements the application (whichcan be either single or multi window). We can observe a UML note attachedto it, which contains AIM instantiation rules in the form “CVM-feature :=Domain-element”, stating that if SingleWindow is a selected feature then theclass DrawingApplication is bound to the Type role, and otherwise if MultiWin-

dow selected, would be MDI DrawingApplication to be bound instead. These typeof instantiation rules bound concrete classes to pattern roles.

Custom refers to the main class that a specialization will develop for imple-menting the application. We can see a constraint attached in a note stating thatthe pattern role Custom has cardinality equal to 1. Notice also that Custom hasa structural constraint of inheritance to Type.

The features Application and SingleWindow of the CVM were handled. Pro-ceeding, 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.AIM-role” denotes a composition relationship. For instance, in the case of Applica-tion.Type, it means that this pattern role is a reference to the role Type of theAIM Application. Composition relationships imply that a same concrete class tobe bound to both of the composed roles. This mechanism resembles the compo-sition form [19] concept (more details in Section 4).

Although roles are referencing others, they can introduce child roles. In thiscase, the methods createTools() and createButton() were introduced as child roles.

In Application.Custom we can see an instantiation rule in the form “CVM-feature :+ Role {...}”, stating that if the DefaultSelect is selected, the create-Tools() should be augmented with a call to its superclass constructor.

In SpecificTool we can see another instantiation rule in the form “CVM-feature :+ cardinality=x”, which adds a constraint to the role, setting its cardi-nality according to the cardinality of the feature AppSpecific.

Yet another issue, is the definition of the constraint “palette add”, statingthat for each binding to SpecificTool (one to one association), it must exist a callin createTools() for adding an instance of the bounded class in the applicationpalette. This note does not correspond to an instantiation rule, but to a patternconstraint instead.

Notice also that in this AIM template the role ToolType is already bound toAbstractTool.

3.5 Application Independent Model (AIM) instances andApplication Specific Model (ASM)

Recall that AIM instances are presented to application engineers, which have todevelop the ASMs in conformance to them.

Following the AIM templates of the previous section, Figure 11 presents theAIM Application instance that is presented to application engineers, instanti-ated according to the CVM instance (SingleWindow was selected in Figure 8).The stereotyped classes represent the pattern roles that are already bound. Inthis case, we see that Type is bound to DrawingApplication. The task in thecorresponding 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 in-stance, which bounds Custom to the class MyApplication.

Fig. 12. ASM Application

Concerning the AIM Tools template, Figure 13 presents the AIM Tools in-stance that is presented to application engineers according to the CVM instancein Figure 8. The constraint “palette add” is hidden, since it is able to generate

the necessary statements in createTools() once SpecificTool is bound. Notice thatApplication.Custom is already bound to MyApplication, due to the ASM Appli-cation. Since the DefaultSelect feature was not selected, the instantiation ruleattached 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 intro-duces 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 tobe able to generate the application’s structural code, as well as behavioral codeimposed by the specialization patterns.

3.6 Application Specific Code (ASC)

The ASC represents code that specializations have to develop in addition to thecode that can be generated using the modeling abstractions. Figure 15 showsthe source code (in Java) that could be generated from the given specializationexample. Annotation-like comments indicate the parts generated from the mod-els. Notice the statements that were included by the pattern roles’ constraints

of AIM Tools. The TODO comments mark the locations in the code where thespecialization is supposed to add ASC.

1 @Application-ASM2 public class MyApplication extends DrawingApplication {

4 @Tools-AIM5 public void createTools(JToolBar palette) {6 palette.addTool(createButton(new StarTool()));7 palette.addTool(createButton(new ArrowTool()));8 }9 }

11 @Tools-ASM12 public class StarTool {13 public void action() {14 // TODO: ASC15 }16 }

18 @Tools-ASM19 public class ArrowTool {20 public void action() {21 // TODO: ASC22 }23 }

Fig. 15. Specialization code resulting from the example

4 Related work

In [18], an approach for validating UML models against architectural profilesis presented. Architectural profiles are extended UML profiles for describingarchitectural constraints and rules for a given domain. The main goal of thisapproach is to check conformance of UML class diagrams against architecturalprofiles, and it is argued that the approach is helpful for enforcing conventionsof product-line architectures.

A generalization of [18] as been proposed in [19], introducing the concept ofdesign profile. Design profiles are composed by design forms, composition formsand global forms (not detailed here). A design form, given as UML class dia-gram, is a pattern-like description of structural properties that must be satisfiedby models that are intended to conform to the design profile. Design forms re-semble the descriptions of structural solutions as class diagrams, for instancelike the ones used in the GoF patterns book [20]. An instantiation of a designform 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 thedesign form). Since the binding of pattern roles from different design forms mayoverlap classes, there is the mechanism of composition forms, which defines role

overlapping relationships. In this way, different pattern roles that have a compo-sition relationship are bound to the same concrete class in different design forminstantiations. Our approach adopted similar mechanisms to design forms andcomposition forms.

In [14] it is presented a template-based approach for mapping feature modelsto representations of variability in UML models. Our approach also applies atemplate-based mechanism in AIMs, however, focusing on exploiting the specificcharacteristics of framework specialization patterns.

COVAMOF [21] is a framework for managing the variability provided by asoftware product-line that allows representation of the variability at differentabstraction layers, which focuses on the configurability of the architecture as-sets, having for instance specific abstractions for modeling dependencies. Ourapproach focuses on the specifics of OO framework-based PLAs and their spe-cialization mechanisms, and intends to support variability which implies thatspecializations 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 imple-mentation 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 playthe role of the PIM. The platform variability could be then achieved by us-ing 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 transformationsdoes not seem to be applicable in these cases. However, for instance when wehave a framework that has different implementations in several technologies (e.g.CORBA), deriving different types of PSMs in order to achieve platform variabil-ity in specializations becomes appealing. The benefits of combining MDA withconfigurable product families are outlined in [22].

Our approach does not aim to provide full-scale MDA technique, since ASChas to be developed for having complete implementation of specializations. How-ever, it addresses the fundamental problems related to PLA learning and devel-opment of (correct) specializations.

Since the adaptation of the specialization process to product requirementshides framework complexity, it is intended to improve usability in the special-ization process, and therefore its efficiency. Another issue related to usabilityis related with the possibility to assist the development of ASMs. Since AIMsformally describe specialization patterns, the required elements in pattern in-stantiations can be inferred from the model and semi-automatically generateASM elements, leaving the variable issues such as class names to be defined bythe specialization developers.

The validation of ASMs against AIMs is advantageous for reducing incorrectspecializations in terms of structure and imposing PLA rules.

In terms of documentation, CVMs can be simultaneously a documentation ar-tifact which gives a conceptual overview of the variability offered by the product-line, and a development artifact for specializations. Nevertheless, a CVM in-stance also constitutes specializations’ documentation that describes the adoptedproduct-line features.

By describing specialization patterns, AIMs can constitute a significant partof PLA documentation for accessing variation points, and serve simultaneously asa development artifact for specializations. ASMs can also constitute a significantpart of the documentation of a PLA specialization, and simultaneously are adevelopment artifact of it.

The types of AIM instantiation rules, as well as the types of constraintsin AIM roles, are under on-going work, by analyzing the variability mechanismsimplemented in existing framework-based PLAs. In order to provide tool supportfor implementing the described approach, the scope of the rules/constraints mustbe well-identified.

References

1. Jan Bosch. Design and use of software architectures: adopting and evolving aproduct-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 Object-Oriented Programming, 1988.

4. Mohamed E. Fayad, Douglas C. Schmidt, and Ralph E. Johnson. Building appli-cation frameworks: object-oriented foundations of framework design. John Wiley& Sons, Inc., 1999.

5. Wolfgang Pree. Design patterns for object-oriented software development. ACMPress/Addison-Wesley Publishing Co., 1995.

6. Simon Moser and Oscar Nierstrasz. The effect of object-oriented frameworks ondeveloper productivity. Computer, 29:45–51, 1996.

7. Sybren Deelstra, Marco Sinnema, and Jan Bosch. Experiences in software productfamilies: Problems and issues during product derivation. In Proceedings of theThird International Software Product Line Conference (SPLC), 2004.

8. Jr. Frederick P. Brooks. No silver bullet: essence and accidents of software engi-neering. 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 Hautamaki. Pattern-Based Tool Support for Frameworks: TowardsArchitecture-Oriented Software Development Environment. PhD thesis, TampereUniversity of Technology, 2005.

13. K. Kang, S. Cohen, J. Hess, W. Nowak, and S. Peterson. Feature-oriented domainanalysis (FODA) feasibility study. Technical report, Carnegie Mellon University,1990.

14. Krzysztof Czarnecki, Simon Helsen, and Ulrich W. Eisenecker. Formalizingcardinality-based feature models and their specialization. Software Process: Im-provement and Practice, 10(1):7–29, 2005.

15. Jilles Van Gurp, Jan Bosch, and Mikael Svahnberg. On the notion of variability insoftware product lines. In Proceedings of the Working IEEE/IFIP Conference onSoftware Architecture (WICSA’01), 2001.

16. Matthias Clauss. Modeling variability with UML. In Net.ObjectDays, 2001.17. Tewfik Ziadi, Loıc Helouet, and Jean-Marc Jezequel. 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 conferenceheld jointly with 11th ACM SIGSOFT international symposium on Foundations ofsoftware engineering, 2003.

19. Imed Hammouda, Mika Pussinen, Anna Ruokonen, Kai Koskimies, and TarjaSysta. Design profiles: Specifying and using structural patterns in uml. In Pro-ceedings 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 PublishingCo., Inc., 1995.

21. Marco Sinnema, Sybren Deelstra, Jos Nijhuis, and Jan Bosch. COVAMOF: Aframework for modeling variability in software product families. In Proceedings ofthe Third International Software Product Line Conference (SPLC), 2004.

22. Sybren Deelstra, Marco Sinnema, Jilles van Gurp, and Jan Bosch. Model drivenarchitecture as approach to manage variability in software product families. InProceedings of the Workshop on Model Driven Architectures: Foundations and Ap-plications, 2003.