Enhancement of a Model Transformation and Code Generation System to Support Software Product Lines by Using Feature Models

Transcription

1 Enhancement of a Model Transformation and Code Generation System to Support Software Product Lines by Using Feature Models Diplomarbeit zur Erlangung des akademischen Grades Diplom-Informatiker eingereicht von Rolf-Helge Pfeier h.pfeiffer@informatik.uni-jena.de Betreuer Prof. Dr. Wilhelm R. Rossak Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Institut für Informatik Lehrstuhl für Softwaretechnik Ernst-Abbe-Platz Jena Dipl.-Ing. Peter Hänsgen Intershop Communications AG Intershop Tower Jena 1. August 2008

2 Today can be gladness, mister, you don't know Tomorrow can be sadness, sister, you don't know What makes the world go round, round and round? You'll never know, you don't know So save a bread, mister, save it for the future Save a bread, sister, because things will be better You know not the minute nor the hour man shall come You know not the minute nor the hour, the time is now What you know, you know, and what you don't know, you don't know The greatest thing is to know that what you don't know, you don't know Anywhere you go, what you don't know, you don't know Save a Bread Justin Hinds

3 Abstract Feature modelling is a key technique for modelling software product lines. Model driven software development may start with feature modelling. If model transformations and code generators already exist and product lining via feature modelling should be used, one faces the problem how to combine both approaches. This thesis describes a model transformation and code generation (MTCG) system, discusses where to alter it to support software product lining, introduces a new solution based on aspect models, and examines the impact of an MTCG system that supports software product lining to the overall software manufacturing process. Zusammenfassung Merkmalsmodelle sind eine Schlüsseltechnologie für die Modellierung von Softwareproduktlinien. Merkmalsmodelle können als höchste Abstraktionsstufe in der modellgetriebenen Softwareentwicklung eingesetzt werden. Besteht schon eine Infrastruktur zur modellgetriebenen Softwareentwicklung, d. h. Modeltransformatoren und Codegeneratoren existieren bereits, so wirft die Einführung von Softwareproduktlinien in eine solche Infrastruktur Probleme auf. Diese Diplomarbeit beschreibt ein Modelltransformations- und Codegenerierungssystem, neuartige Änderungen des Systems zur Unterstützung von Softwareproduktlinien, stellt eine mögliche Lösung mit Hilfe von Aspektmodellen vor und untersucht die Auswirkungen der Einführung eines Softwareproduktlinien unterstützenden Modelltransformations- und Codegenerierungssystem auf den gesamten Prozess der Softwareherstellung. i

4 Acknowledgements I would like to thank my supervisors Peter Hänsgen and Christian Schachtzabel for the numerous and helpful discussions and for the constructive criticism. I oer my heartfelt thanks to my brother Hendrik Pfeier for being ready to listen to all what is on my mind, for his thoughts and words of encouragement, for reading this work, and for his suggestions. Special thanks to my mother Gabriele Pfeier for encouraging and supporting me. All my thanks to the members of the band Paolo Macho. Even if it is exhausting, the music always manages to put a smile on my lips.

5

6 iv

7 Contents 1 Introduction 1 2 Terms, Denitions, and Techniques Models in this Work Model A Denition Metamodels Formal Models Domain Specic Models Aspect Models Feature Models Features Feature Diagrams Feature Model Variant Model Techniques for MDSD and Feature Modelling Model Transformation and Code Generation Systems Model Transformations Model Modication Model Linking Model Transformation Model Merging Code Generation Transformation Flow Specication MTCG Languages Aspect-Orientation in General Introduction to Aspect-Oriented Programming Introduction to Aspect-Oriented Modelling Comparison of AOP and AOM v

8 vi CONTENTS Product Line Software Engineering Tools Feature Modelling pure::variants Feature Modeling Plug-In (fmp) EMF and Ecore MDSD Framework openarchitectureware The Workow Engine The oaw Expression Language XTend XPand Subprojects of oaw XVar XWeave Software Manufacturing at Intershop The Existing Software Manufacturing Process The Existing MTCG System A Concept for Software Manufacturing Using SPL Product Lining for an MTCG System Eects of Features on a Software System in General Eects of Features on an MTCG System Feature Types in MTCG Systems Feature Models in MTCG Systems Merging of Aspect Models, General Strategies Merging of Aspect Models in Practice Notation Implementation of Merging of Aspect Models Feature Dependency Model Transformation to Aspect BOM Pointcut Generation Control Features Implementing a Transformation Flow A Software Manufacturing Process Using Product Lining Versioning with SPL

9 CONTENTS vii 5 A Case Study The Scenario The Feature Diagram The UML Base Model The UML Aspect Models The Extended Address Aspect Model The Billing Aspect Model The Catalogue Aspect Model The Scale Price Aspect Model An Aspect Model for Demonstration The Feature Model The Transformation Flow The MTCG System in Action The Variant Model The Feature Dependency Model The BOM Base Model The BOM Aspect Models Model Merging on BOM Level The Tailored BOM Base Model An Automatically Generated Pointcut File Calling XWeave Adjusting the Relations The BOM Base Model after Merging and Further Processing 62 6 Conclusion Contribution Future Work References 67 List of Figures 71 List of Tables 73

10 viii CONTENTS

11 Chapter 1 Introduction It can be observed that, today, the focus of software development increasingly shifts from the development of source code to the development of models in order to increase the quality and reusability of development artefacts and the overall products. For this reason model driven software development (MDSD) has become popular. MDSD is the application of model transformation and code generation systems on domain specic models for software development. MDSD has matured and becomes more and more accepted in practice. Tools for MDSD, such as the Eclipse Modeling Framework (EMF) [emf08] or openarchitectureware [E07], have matured and are increasingly available for software development. Many companies, such as Intershopwhich is a manufacturer of e-commerce software, made signicant investments to deploy MDSD in real-world projects, for example for the development of models, transformers, and generators. Intershop's products are all from the e-commerce domain, and they share a lot of commonality and dier among each other only in a few product features. Consequentially, it is desired to implement software product lining on top of MDSD technologies to improve software development. Software product lines regard software products as parts of a family, where the products possess a high degree of commonality and vary only a little. The current MDSD techniques and the current software engineering approaches deployed at Intershop, are not suitable to support software product lining. They face two major problems: A Problem of Engineering: In contrast to other companies that manufacture software products, where each product can be of another domain, and the products among each other possess only a little commonality, Intershop operates only in one domain, the e-commerce domain, and thus all products possess a lot of commonalities and dier only partially, i. e., they can form a software product family. However, recent engineering approaches, e. g., Object-Oriented Analysis and Design (OOAD), that are also deployed at Intershop, focus on the development of single, heterogeneous software systems. They are not intended to develop software system families. A Problem of Development: Since the main focus in software development shifts from the development of source code to the development of models Intershop has developed a Model Transformation and Code Generation (MTCG) system to introduce MDSD to software development. The current MTCG system enables to model and 1

12 2 CHAPTER 1. INTRODUCTION automatically generate a single software system. It provides no support for software families. Consquentially, development and engineering methods need to shift their focus from manufacturing and modelling single software systems to manufacturing, handling, and modelling software system families, to solve the before described problems. This is feasible by using feature models for modelling software system families, since they... are the preferred domain modeling mechanism for product lines. Unlike mechanisms designed for modeling individual problems... [JG04]. Therefore, this work's thesis is: It is possible to enhance an existing MTCG system to support software product lining by using feature models. To solve the problem of engineering, this work uses feature models on top of recent engineering and development methods. These are: Object-Oriented Modelling (OOM) for modelling a base system containing a minimal set of features and Aspect-Oriented Modelling (AOM) for modelling and encapsulating the variability of software systems of a family. Concerning the second problem, i. e., enhancing an existing MTCG system to support software product lining, this work focuses on the following key issues: What information is needed to form a complete feature model that enables software product lining in an MTCG system? How can the information be used in an MTCG system to allow for product lining? The rst issue is solved by using a feature model to control the invocation of particular model transformers and code generators and, furthermore, by associating certain features with aspect models. When generating a single software system, the aspect models are merged into the model of a base system according to the feature model. The second issue is crucial for an automatic generation of members of a software system family. Therefore, a model merger that merges aspect models into a model of a base system is newly implemented by using openarchitectureware. The result of this thesis, is an MTCG system that can automatically generate single software products of a family, by selecting features of a feature model. The remainder of this thesis is structured as follows: The second chapter denes the terms that are important in this work, it describes the technical concepts of MTCG systems, of aspect oriented software development, and of product line software engineering. Furthermore, it introduces and discusses tools that are used for MDSD. In the third chapter the software manufacturing process and the MDSD infrastructure at Intershopis described. In the fourth chapter a new concept of how to implement support for software product lining into an MTCG system by using feature models and by using aspect models is developed. Furthermore, the impact of such an implementation to the overall software manufacturing process is examined. A case study that provides initial evidence that the developed concept is suitable to enhance an MTCG system to support software product lining is presented in Chapter 5.

13 Chapter 2 Terms, Denitions, and Techniques This chapter provides the required notional basis for this thesis. It denes the terms and notions used in this work. Section 2.1 denes models in general and some particular models, such as feature models. Section 2.2 describes techniques that are important for MDSD in general and for supporting product lining in MTCG systems. Finally, tools for MDSD and for feature modelling are presented, see Section 2.3. Readers with knowledge in models, feature modelling, aspect-oriented modelling, and concepts of model driven software development, might wish to skip this chapter and only refer back to it if the later chapters raise questions with regard to the terms, denitions, and concepts used in this thesis. 2.1 Models in this Work As the title of this thesis hints, models play a key role in this work. They can be used for improving software development by enhancing the level of abstraction on which software is developed. To allow for the eective usage of models, one needs to know what they are and what they are not. On that account, the following sections provide a closer look on models Model A Denition The etymological origin of the term model is the Latin modulus that is the diminutive of modus which means measure, measuring unit or in a broader sense character, manner, form, or specication [Har11]. Generally, a model is a description of something. In that way, it is used in [JG04], where:... a model is an abstract description of software that hides information about some aspects of the software to present a simpler description of others. This model denition is directly tied to the description of software, but since the models that will be used within this work can contain more than just software related information a more general notion for the term is necessary. This work uses a denition of models similarly to [Sta73]. There, a model is characterised by its conformance to the following three main characteristics. 3

14 4 CHAPTER 2. TERMS, DEFINITIONS, AND TECHNIQUES Mapping Characteristic: Models are mappings or representations of articial or inarti- cial originals, where these originals may be models, too. Shortening Characteristic: Generally models do not cover all attributes of the original that they represent, but only those that seem to be relevant to the particular model creators or users. Pragmatic Characteristic: Models are not always unambiguously assigned to their originals. They full their substitution function for particular individuals, within particular time slices, and with restriction to particular notional or actual operations. Consequently, a model is something that is constrained to subjects that create and use it and is nothing that contains the genuine truth for the present, past, or future. Additionally, the term is ambiguous; a model can be a mapping, or a prototype for something, and it can be a representation of an original. This will become obvious in the remainder of this work, when models are used for code generation or serve as a basis for the construction of new models. In [Tho01] it is suggested to distinguish models by their originals, their intention, their attributes and the adequateness of original and model. Therefore, some particular models will be introduced in the subsequent sections Metamodels Figure 2.1: A model hierarchy and its relation to real-world elements, adapted from [SVEH07]. As usual when using meta-terms and as explained in [SVEH07], metamodels describe other models, they provide the structure for their instances, they provide the rules for constructing, and can be used to validate models that are their instances. Since a metamodel is a model, it can possess a metamodel, called metametamodel. That way, an innite chain of models that describe each other is produced, but usually on metametamodel level the hierarchy ends with a self-references, i. e., self-description. Figure 2.1 shows such an hierarchy schematically. An example for a metametamodel is the Meta-Object Facility (MOF) [mof08] of the Object Management Group (OMG) [omg08], the metamodel of Unied Modeling Language (UML) [uml08b]. It denes the UML.

15 2.1. MODELS IN THIS WORK Formal Models Formal models are models that describe a particular entity completely, i. e., there are hard rules for what the model describes. Models that are described by a metamodel are formal, see [SVEH07]. Such models can be used for automatic processing and for code generation. There is no constraint to the syntax that the models use. Graphical as well as textual models can be formal. The remainder of this work uses the term model synonymously for formal models Domain Specic Models Domain specic models are metamodels that describe a particular domain. They describe facts of a domain, where a domain is a limited eld of knowledge or interest. Intershop for example, uses domain specic models to describe business processes, persistent objects of software systems, or databases. Section 3.1 describes a selection of domain specic models which are used at Intershop Aspect Models Aspect models are models that refer to another model, a base model. They may be called dierence models since they express a dierence between the base model and the one that results in merging the base with an aspect model. With respect to the base model, aspect models can express positive and negative variability [GV07b]. Positive Variability: Means adding model elements to a base model. Parts of models or even complete models can be added. Negative Variability: Is the counterpart to positive variability. Here an aspect model denes which parts of the base model are removed. Aspect models can describe positive and negative variability, with respect to the base model, at the same time. Section will explain in more detail how to use aspect models Feature Models Feature models were introduced in Feature-Oriented Domain Analysis (FODA) [KCH + 90]. They describe requirement spaces of software products, and are used to capture commonality and variability of software systems, e. g., applications from a software family. The following sections introduce required terms, such as feature, feature diagram, feature model, and variant model Features In [KCH + 90], Feature-Oriented Domain Analysis is proposed as new software engineering paradigm. There a feature is dened as:

16 6 CHAPTER 2. TERMS, DEFINITIONS, AND TECHNIQUES A prominent or distinctive user-visible aspect, quality, or characteristic of a software system or systems. Similarly it is stated in [Gri00] that: A feature is a product characteristic that users and customers view as important in describing and distinguishing members of a product-line. A feature can be a specic requirement, a selection amongst optional or alternative requirements, or related to certain product characteristics, such as size, execution platform or compatibility with certain standards. Later user-visibility was generalised to the visibility to end-users, domain experts, developers, etc., therefore, features in [LKL02] are dened as:... any prominent and distinctive concepts or characteristics that are visible to various stakeholders. Since there are multiple slightly dierent denitions for features and feature models, some works aim to be more precise: A feature represents an aspect valuable to the customer. It is represented by a single term. There are three categories of features: Functional features express the behavior or the way users may interact with a product. Interface features express the product's conformance to a standard or a subsystem. Parameter features express enumerable, listable environmental or nonfunctional properties. [Rie03] Czarnecki [Cza98], denes a feature as:... an important property of a concept... where a concept is an area of knowledge. In later works, such as [CA05] and [CHE04], the notion of a feature changed to: A feature is a system property that is relevant to some stakeholder and is used to capture commonalities or discriminate among systems in a family. The last mentioned denition is the most general. It considers various stakeholders. It is the feature denition that is used in the remainder of this work.

17 2.1. MODELS IN THIS WORK Feature Diagrams Since a feature is a property of a system, a system can be characterised by a set of features. A family of systems is characterised by the set of all possible combinations of features, where each single combination represents one family member, i. e., a particular system. Feature diagrams are graphical representations of systems and their features. In [CA05], it is stated about feature diagrams: Features are organized in feature diagrams. A feature diagram is a tree with the root representing a concept (e. g., a software system), and its descendant nodes are features. When characterising a system by all possible combinations of features, there are relationships and interdependencies among features. A feature diagram should also depict how single features depend on each other. Therefore, [KKL + 98] denes: A feature diagram [as a] graphical AND/OR hierarchy of features, that captures logical structural relationships... among features. There may be relationships or interdependencies that are too complex to be modelled by visual means, for example,... knowledge of invalid feature combinations or underlying issues and rationales., see [KCH + 90]. That is why, feature diagrams also have to provide means to denote complex interdependencies. Figure 2.2: Feature diagram using the FODA notation, adapted from [KCH + 90]. Figure 2.2 shows an example feature diagram for the family of cars. The diagram uses the FODA [KCH + 90] notation. Its syntax is specied in Figure 2.3. The feature diagram declares that a car is characterised by the kind of transmission it uses, i. e., manual or automatic transmission, by its horsepower, and by an optional air condition. It even shows a possible way of expressing further relationships by using a so-called composition rule. A connection between software system families and software product lining is established for example in [SVEH07]. Basically, a feature diagram shows which features are mandatory, optional, or alternative for a product of a software system family. After clarifying what a feature diagram is, one needs to know the syntax and semantics used by feature diagrams. In [Cza98] it is dened that:

18 8 CHAPTER 2. TERMS, DEFINITIONS, AND TECHNIQUES A feature diagram consists of a set of nodes, a set of directed edges, and a set of edge decorations. The nodes and the edges form a tree.... The root of a feature diagram represents a concept.... The remaining nodes in a feature diagram represent features and we refer to them as feature nodes. Figure 2.3: Selected feature diagram notations, originally published in [CHE04]. Figure 2.3 shows possible edge decorations for selected feature diagram notations. Beside these notations, there are other approaches, e. g., [ZJF03, RFP02], that try to extend UML to support feature diagrams. Until now there is no standard concerning the syntax of feature diagrams. They are not part of the UML. Due to non-standardisation a great number of slightly dierent notations exist. However, all notations for feature diagrams have in common that they use some kind of tree structure, an and/or tree. The name of the domain that is modelled is the root node of such a tree. A node that is a child of a parent node implies a requirement relation,

19 2.1. MODELS IN THIS WORK 9 i. e., the feature in a child node requires the feature within the parent node. Conversely, parent features are composed out of their sub-features. Each notation provides graphical symbols that indicate, whether a feature is mandatory or optional, and, depending on the notation, some more or less complex graphical elements for expressing alternative features. Furthermore, interdependencies that are not expressible by graphical means are expressed by rules that annotate features. The syntax of such rules depends on the chosen dialect of feature diagrams. Commonly used are operators that express that a feature requires another one and that features exclude each other. In FODA these are for example the requires and mutex-with, i. e., mutually-exclusive-with operators. Further operators, such as recommends or discourages that softens the requirement and exclusion operators may be provided by the feature diagram notation. Commonly used languages for expressing rules between features are OCL and XPath. Most of the feature diagram notations that try to extend the FODA notation aim at increasing the expressiveness of feature diagrams. But in [BHST04] it is proofed, that the FODA notation is maximally expressive and moreover, that the extended notations contain ambiguity Feature Model As for features and feature diagrams there are several notions for feature models. Some of them do not distinguish between feature diagrams and feature models, for example in [Rie03]:... a feature model represents a hierarchy of properties of domain concepts. The properties are used to discriminate between concept instances, i. e.systems or applications within that domain.... At the root of the hierarchy there is a so-called concept feature, representing a whole class of solutions. In this thesis the notions of feature diagrams and feature models are regarded as separated. In [AC04] a feature model consists of... one ore more feature diagrams.... In [CA05], that denition is rened: Feature models are feature diagrams plus additional information such as feature descriptions, global constraints, binding times, priorities, stakeholders, etc. Thus, feature models are regarded as a superstructure that must contain at least one feature diagram and arbitrary information that is important to a stakeholder. The last denition is used in the remainder of this work, since it allows to enrich feature models with specic information. Section shows how feature models are used in the particular case. In the following it is described what feature models capture and at what they aim. Generally, a feature model... denes a 'decision space' for application development [KKL + 98], that can be rened, as in [LKL02], where feature models have to:... focus on identifying external visible characters of products in terms of commonality and variability, rather than describing all details of products such as other modeling techniques...

20 10 CHAPTER 2. TERMS, DEFINITIONS, AND TECHNIQUES The focus on identifying commonality and variability as externally visible characteristics is stressed in [JG04]. There, the connection between feature models and modelling of domains is described as follows: Feature models are the preferred domain modeling mechanism for product lines. Unlike mechanisms designed for modeling individual problems, feature models are designed to model domains. They explicitly distinguish between common and variable features, and represent parameters of variation directly as constraints. In addition they are independent of any implementation technology, and are therefore preferable to mechanisms like genericity and inheritance. This implies, that feature models provide a more abstract view on the systems they represent than other models, such as UML models. As Section illustrates they can be used on top of models that model individual problems. Individual problems can be single software products of a software system family Variant Model A variant model describes a view on a feature model. It denes instances of feature models that contain selected features and user specied attribute values. Variant models always contain a valid selection of features and assignments of attributes. Automatic checking for valid selections means checking a feature selection against the rules that exist between several features. Figure 2.4 shows an example using the tree-editor notation of pure::variants, see Section On the left hand side, a feature model of an exemplary online store is illustrated and on the right hand side one possible valid variant model is shown. The developers of pure::variants use the term variant description model (VDM) which is synonymous to variant model. 2.2 Techniques for MDSD and Feature Modelling The following sections describe techniques and terms that are used for model driven software development (MDSD). At rst, a detailed view on model transformations is given. Thereafter, aspect-oriented methods are introduced, since the support for product lining in an MTCG system is based on aspect models. This is followed by a short section that explains software system families and software product lines Model Transformation and Code Generation Systems A Model Transformation and Code Generation (MTCG) system is a computer program that allows for transforming one model into another, where models may represent dierent abstraction levels, technical domains, etc. Furthermore it allows to generate arbitrary textual artefacts. Textual artefacts are entities without a well-dened metamodel, such as source code of a programming language, conguration les, documentation, etc. An MTCG system operates on models that share at least one metametamodel. They may support multiple dierent metametamodels, because a variety of such metamodels,

21 2.2. TECHNIQUES FOR MDSD AND FEATURE MODELLING 11 Figure 2.4: A feature model on the left and an corresponding variant model on the right. e. g., Ecore, EMOF, MOF, XML Schema, exists. MTCG systems have to provide or understand a language in which model transformation and code generation functions are declared. Consecutive model transformations and code generation steps are called a transformation ow. Furthermore, a language that allows to specify which transformation and generation step follows another, i. e., a transformation ow specication language, must be available. The following two sections describe what is meant by model transformation and code generation. Afterwards some general ideas about specifying a transformation ow are expressed Model Transformations Generally, a model transformation is the application of operations that modify a model, or the application of operations that generate another model. More precisely, model transformations are operations that perform a model-to-model transformation. That is, both models are instances of formal metamodels. The following categorisation of model transformations is proposed, whereas the rst three categories are adapted from [SVEH07]. Figure 2.5: Principle of a model modication, adapted from [SVEH07].

22 12 CHAPTER 2. TERMS, DEFINITIONS, AND TECHNIQUES Model Modication Model modication is an operation where the input and the output model are instances of the same metamodel. It can be said, that such an operation changes the state of a model, existing model elements can be altered and new ones can be added. In contrast to the denition in [SVEH07], model elements can even be removed. Figure 2.5 exemplies model modication. Grey model elements denote elements that are newly inserted into the model. Figure 2.6: Principle of linking model elements, adapted from [SVEH07] Model Linking A special case of model modication is model linking. The state of a model is changed by linking model elements to elements of other models. Linking means attaching a reference. Figure 2.6 shows a schematic for linking. Additionally, not only model elements may be linked even complete models can be linked to model elements. Model linking is a method for separating information or concerns. It allows for distribution of information over multiple models if desired. Figure 2.7: Principle of a model transformation, adapted from [SVEH07] Model Transformation Unlike a model modication, a model transformation generates a model out of an input model and both are not instances of the same metamodel; as the input model remains unmodied. Those transformations can be arbitrarily complex. Usually, they are used to bridge an abstraction gap. The level of abstraction decreases with each model transformation. See for example the abstraction layers in Section 3.1. There, each model level that is the outcome of a model transformation represents a more concrete view on a particular domain. But even model transformations that lead to higher abstractions are conceivable, for example for visualisation purposes Model Merging Another specialisation of model manipulation is model merging. In contrast to model manipulation, the information of what is changed is not

23 2.2. TECHNIQUES FOR MDSD AND FEATURE MODELLING 13 specied using particular transformer directives. Instead, a universal model merger, universal since it can merge models that are instances of the same metametamodel, modies a model according to information that is specied in separate models. As the remainder of this work will show, model merging becomes the key issue for supporting product lining in MTCG systems Merging Strategies Generally, the following two strategies for model merging can be distinguished. The explanation refers to merging of models but since they are general strategies they are adaptable to merging in general. Symmetric Merging Is omnidirectional merging, i. e., the result of merging is independent of the order of the arguments, as analogous to the commutative law in mathematics. For example: A B = B A = C, where A, B, and C are models and is a symmetric merging operator. Asymmetric Merging Is unidirectional merging, i. e., the result depends on the merging direction, where only one direction is viable. There is one designated base model with which aspect models are merged. Example: A B = A' B A = B', where the left hand side of the asymmetric merging operator ( ) denotes the base model and the right hand side denotes an aspect model. Figure 2.8: Merging of positive variability (on the left) and negative variability (on the right), adapted from [GV07b]. In case of symmetric merging, models can be regarded as sets and the merging operator is equivalent to the union operator ( ) for sets. Symmetric merging is a generalisation of the asymmetric case. Since both models are complete, i. e., none of them is an aspect model, it is possible to generate an aspect model out of one of the complete models and subsequently merge that aspect into the corresponding base model. In the asymmetric case it is not possible to express the merging operator as operator on sets, since an aspect model refers to the structure of a base model. The remainder of this work uses merging synonymously for asymmetric merging, i. e., there is one base model and a set of aspect models. That decision was made for technical reasons, since XWeave, see Section ,

24 14 CHAPTER 2. TERMS, DEFINITIONS, AND TECHNIQUES which is used to implement a model merger, weaves models asymmetrically. Furthermore, the symmetric case of merging expects two complete models whose contents may overlap, i. e., information is stored two times what complicates modelling. In Section it is stated, that aspect models contain positive or negative variability, with respect to the base model. The process of applying positive or negative variability expressed in aspect models to a base model is called merging, see Figure 2.8. The illustration is separated for the application of positive variability and the application of negative variability. The asymmetric merging operator for the application of positive variability is and for the application of negative variability is. In this work the merging of aspect models into a base model is not called weaving, as suggested in [SVEH07] or as used for Aspect Oriented Programming (AOP) languages, since weaving only refers to positive variability. Furthermore, weaving in AOP is not an operation that modies the structure of base classes. Aspects on model level are thus more expressive than aspects on source code level. Figure 2.9: Consecutive merging of dependent aspect models Consecutive Merging Aspect models may depend on each other, i. e., one aspect refers to another aspect. Since such dependencies are directed, aspect models may form chains tied by their dependency relations. To correctly merge depending aspect models with a base model, merging is performed in cascades, starting with the top of the chain, i. e.an aspect that has no dependencies. Figure 2.9 illustrates that Code Generation Code generation is another term for a model-to-code transformation. With code generation not only source code can be generated, more precisely all textual artefacts can be generated. As the term transformation indicates, code generation could be regarded as a special case of a model transformation. If only source code of a programming language is generated, the language's compiler or interpreter denes a metamodel. But since generated artefacts can be anything, i. e., there is no metamodel, code genereration is in fact not a model

25 2.2. TECHNIQUES FOR MDSD AND FEATURE MODELLING 15 transformation. According to [CH03] there are two approaches for generating code out of models. Visitor-Based Approach A representation of a model is traversed by visitors that write appropriate source code for model elements to a text stream. Visitors contain information about what to write to a text stream for each particular model element. This means, such generators are tied to a single kind of source code they can generate; as a result it is hard to adapt the visitors to generate another kind of source code. Template-Based Approach Here, templates are mixtures of text and commands in a metalanguage that access or select model elements. Such a metalanguage may be the Object Constraint Language (OCL), XPath, or a language that provides more complex functionality. Section describes the template mechanism used by openarchitectureware that is used for the implementation of code generators in this work Transformation Flow Specication To let an MTCG system perform subsequent model transformations and code generation steps a transformation ow engine is responsible for calling transformers and generators on appropriate models in the correct order. Generally, there are two ways in that such an engine can deal with transformation ows. Figure 2.10: Principle of a transformation ow engine using an implicit transformation ow declaration. Implicit Transformation Flow: In this case there is no transformation ow declared explicitly. The transformation ow engine decides based on the models it receives, whether a transformer or generator is invoked. If an invocation is neccessary, it decides which transformer or generator to invoke exactly. Figure 2.10 shows the case of an implicit transformation ow specication. The transformed models may serve as new input to the transformation ow engine, to allow for cascading model transformations. Explicit Transformation Flow: An explicit transformation ow is declared in an imperative form. The transformation ow engine is responsible to process such a specication and calls transformers and generators appropriately. Figure 2.11 illustrates such a behaviour. As language for a transformation ow declaration any imperative language can be used. Another, solution is to use a kind of conguration le that species the order of transformer and generator calls, see Section that describes how to declare a transformation ow in openarchitectureware.

26 16 CHAPTER 2. TERMS, DEFINITIONS, AND TECHNIQUES Figure 2.11: Principle of a transformation ow engine using an explicit transformation ow declaration MTCG Languages To eciently deploy MTCG systems there need to be languages in which model transformers, code generators, and transformation ows are specied. Such languages can be standard programming languages such as Java, graphical languages such as VIATRA [VB07], or textual languages such as ATL [atl08], or those provided by openarchitectureware, see Section Often, performing model transformations and code generation using standard programming languages is not advisable, since describing simple transformations quickly becomes complex [SVEH07], because of the handling of collections, cycles, object identity, etc Aspect-Orientation in General Aspect-oriented modelling (AOM) lifts concepts known from aspect-oriented programming (AOP) to the level of modelling, thus, it augments the level of abstraction. As a consequence, some concepts and terms that are used for AOP change or are not longer available for AOM. The following sections will briey introduce the main terms and concepts of AOP and AOM and compare them. The history of software engineering and programming languages shows that development of good software requires the use of encapsulation and modularisation of concerns to uncouple the developed software components to increase their reusability. As analogous to [Lad03] a concern is a:... specic requirement or consideration that must be addressed in order to satisfy the overall system goal., whereas A software system is the realization of a set of concerns.. Procedural programming languages encapsulate software functionality in functions or procedures. Object-oriented languages modularises data and behaviour to objects or modules. Today object-oriented programming (OOP) is state-of-the art. With OOP, it is possible to modularise core concerns of software systems in objects. But one faces the problem

27 2.2. TECHNIQUES FOR MDSD AND FEATURE MODELLING 17 Figure 2.12: Problems that might arise from using OOP: tangled code (top left), scattered code (top right), coupled code (bottom). Images from [Lad03].

28 18 CHAPTER 2. TERMS, DEFINITIONS, AND TECHNIQUES that there is functionality of software systems that is not easily modularised in that way. The following three examples present problems that might arise from using object-oriented programming, see [Lad03]. Tangled Code: Emerges when one module or object implements multiple, or fragments of multiple concerns, see Figure 2.12 top left. Scattered Code: One concern that is implemented in multiple modules produces scattered code, see Figure 2.12 top right. Changing a concern, implies changing of all modules that implement it. Coupled Code: Imagine a concern that is successfully implemented in a single module, i. e., it is separated from other logic. Other modules that call its functionality become coupled, since they contain code that does not implement their specic concerns, see bottom of Figure Concerns that are not easy to modularise because they cut across a large part of a software system are called crosscutting concerns. They aect a software system on various points. To encapsulate crosscutting concerns and to avoid the problems explained above, a new program construct an aspect is introduced. That leads directly to AOP, what is described in the following section Introduction to Aspect-Oriented Programming This Section describes AOP with regard to Java and AspectJ. The choice is for simplicity reasons only, other aspect-oriented languages use similar terms and concepts. According to [Lad03], the following descriptions dene the most important terms of AOP. Weaving: Is the process of applying positive variability expressed in aspects. Dynamic Crosscutting: Is weaving of behaviour specied in aspects into the execution of a software system, i. e., the behaviour of a system is modied at runtime. Static Crosscutting: Is weaving of new static program elements into the static structure of a software system, e. g., introducing new attributes in a class. Joinpoints: Denote the set of identiable points in the execution of a program to which an aspect can refer. Generally, each single point in a class may serve as a joinpoint, but not all are exposed by the joinpoint models of aspect-oriented languages. Among others, AspectJ exposes the following joinpoints: method joinpoints, that allow for referencing the call or execution of methods, constructor joinpoints, that allow for referencing the call or execution of constructors, eld acces joinpoints, that allow for referencing read or write access to attributes of a class, last mentioned are advice execution joinpoints, that refer to the execution of advice located in other aspects. For all other joinpoints see [asp08, Lad03]. Pointcuts: Are program constructs that select to which single joinpoint or to which subset of joinpoints an aspect refers, i. e., they express weaving rules. Furthermore pointcuts collect context information about the execution environment of a joinpoint. For example, if the joinpoint is a method execution joinpoint, information about the objects on that the method is called is exposed.

29 2.2. TECHNIQUES FOR MDSD AND FEATURE MODELLING 19 Advice: Species new behaviour for a matched joinpoint and whether it prepends to, appends to, or replaces the behaviour at a particular joinpoint. Together with pointcuts it forms dynamic crosscutting. Introductions: Declare static crosscutting. They describe how to change the static structure of a program, i. e., what is newly introduced in classes, interfaces, or other aspects. Aspect: An aspect is a class-like entity. It encapsulates data and behaviour. It diers from a class by the fact, that it is no independent entity. Aspects always refer to a class. By using pointcut denitions, aspects declare at which joinpoint some new behaviour the advice shall be introduced in one or more classes which are targeted by the pointcut denitions. All in all, aspects are the central element in AOP. They can contain pointcuts, advice, introductions, attributes and methods in the same way Java classes do Introduction to Aspect-Oriented Modelling AOM diers from AOP in the level of abstraction. Modelling is more abstract programming. Therefore, some notions and terms are dierent. They are introduced in the following. Merging: Is the consecutive application of negative or positive variability expressed by an aspect model. Static Crosscutting: Is merging of designated model elements into the base model, i. e., modifying its structure. Joinpoints: Denote the set of points in models to which an aspect model can refer. Pointcuts: Denote functions that express to which single joinpoint or to which subset of joinpoints an aspect model refers. Introductions: Are the model elements contained in an aspect model, which are designated to be newly inserted into a base model, or to be removed from a base model. Aspect Model: See Section for a denition Comparison of AOP and AOM This section contrasts the terms and notions of the last two sections and emphasises their dierences. Weaving and Merging: Aspect weavers for programming languages generally do not allow for removing model elements. Thus, they support positive variability expressed in aspects. In contrast an aspect merger, as described in Section 4.1, allows for the application of negative and positive variability expressed in aspect models, therefore, in this work the term merging is used, see Section

30 20 CHAPTER 2. TERMS, DEFINITIONS, AND TECHNIQUES Dynamic Crosscutting: In AOM there is no equivalent for dynamic crosscutting. This is due to the notion of model mergers used in this work, see Section Here a model merger is regarded as a precompiler. It works on the static structure of models. Even if models describe behaviour, the model merger operates on the structure of models, it removes or inserts elements according to the aspect models. Changing the structure of a model results in changed behaviour of a software system. In contrast, aspects in AspectJ modify behaviour without a structural modication of the source code of the class or aspect to which an aspect refers. Furthermore, it would contradict the intention of modelling to let an aspect model aect a software system at runtime, since models are used for enhancing abstraction. That is, an aspect model should aect another model and not the artefacts that are generated out of it. Static Crosscutting: This term remains the same for AOP and AOM. It refers to modifying the structure of source code or models, where either program constructs or models elements are designated in aspects. Joinpoints: Depending on the joinpoint model used by an aspect-oriented programming language, not all possible joinpoints are exposed, i. e., are usable in pointcuts. In AOM all points in a model structure are joinpoints, and are usable in pointcuts. Pointcuts: Both AOP and AOM use the term pointcut to specify the weaving rules, i. e., program constructs or functions that declare to which joinpoint an aspect refers. Advice: Since AOM, as described above, supports the modication of a software systems behaviour by changing the structure of models there is no equivalent for the term advice in AOM. Introduction: In AOP as in AOM introductions are the elements that are introduced to a class or a base model. In AOM, as it is used in this work, also model elements that are removed are called introduction. Aspect and Aspect Model: Aspects and aspect models are the key entities of aspectorientation. They have in common that they encapsulate crosscutting concerns and variability Product Line Software Engineering The intention of this work is to make software product development at Intershop more eective and more ecient. It is the awareness, that Intershop develops and sells products that are all members of the same domain the e-commerce domain. The products share a high grade of commonality, and vary among each other only in well dened variabilities. In that case, it is said, that the products form a software system family. First dened in [Par76], a software system family is:... a set of programs... constitute[s] a family whenever it is worthwhile to study programs from the set and then determining the special properties of the individual family members.

31 2.2. TECHNIQUES FOR MDSD AND FEATURE MODELLING 21 Commonalities in an MDSD context can, according to [SVEH07], be of infrastructural, architectural, or functional nature. When producing software products of a family, one can make reuse of the commonalities that are developed once, and concentrate on developing the variabilities. The facilities to eectively develop members of software system families are called Software Product Lines (SPL). SPLs aspire to:... produce a family of software products more quickly, more cheaply and with less risk and higher quality than would be feasible by producing them individually. [JG04] Thus, SPLs describe how to produce single software products of a family. When developing software via SPLs, current software engineering approaches are often not suitable, since most of them, such as OOAD, focus on the development of single software systems. New engineering approaches that respect the existence of commonality and variability are necessary. Product Line Software Engineering (PLSE) is such an approach and in [LKL02] it is dened as:... an emerging software engineering paradigm, which guides organizations toward the development of products from core assets rather than the development of products one by one from scratch. Core assets capture commonality of software products. They are intended to be reusable, so that one can benet during new software development eorts from work that was carried out before. An asset can be a software component, a model, a process, a tool, etc. PLSE can be decomposed in two major activities. These are: Core Asset Development: Is the engineering of the product line itself. The goal is to identify reusable assets from the domain that a software system family should cover. There are multiple domain analysis or domain engineering approaches, such as [KCH + 90, KKL + 98, KLD02] etc. It is not important which one is applied exactly, since they all identify reusable assets. Product Development: Is how to use the identied assets and develop a single member of a particular software system family. This work does not further investigate on how to perform domain analysis, how to obtain good core assets or features, how to receive a good feature model, or how to assure that features models appropriately capture realities. Instead, it is assumed that a software system family is appropriately decomposed into features and that their relations are also modelled appropriately. The focus of this work, with respect to allowing an MTCG system to support product lining, is: 1. What additional information is needed to form a complete feature model to allow an MTCG system for product lining? 2. How can the additional information be invoked in an MTCG system to allow for product lining?

32 22 CHAPTER 2. TERMS, DEFINITIONS, AND TECHNIQUES As the remainder of this work will show, feature models are used on top of UML models, i. e., on top of Object-Oriented Analysis and Design methods. This implies that, software product line engineering is a more abstract engineering approach, than current approaches. 2.3 Tools Tools for MDSD, i. e., for the implementation of MTCG systems, have matured and are increasingly available for software development. A selection of such tools and frameworks is described in the following sections. There are two categories of tools; those that allow for feature modelling and those that are MDSD frameworks. All the tools and frameworks are based on Eclipse (an Integrated Development Environment [ecl08]), since Intershop uses Eclipse for software development and it is required, that a solution for enhancing an MTCG system to support software product lining, integrates to the existing development infrastructure Feature Modelling Feature modelling becomes more useful when feature models are used for automatic processing, for model driven software development, and not only for documentation purposes. The usefulness of a feature modelling tool can be measured by its capability to: 1. display large amounts of features and their interdependencies, 2. provide means to specify rules between features, 3. automatically check selections for validity, 4. generate a variant model for further processing. There is a choice of tools available that allow feature modelling [xfe08, cpt08, AC04, pur08]. Two of them are introduced in more detail pure::variants The Eclipse plug-in pure::variants (PV) is a variant managing framework for software product line development and automatic generation of single products of a SPL. It is developed by pure-systems [pur08] and distributed in three dierent versions. The Community Edition is free of charge, but does not provide the complete amount of product features. This edition is used for the case study, that is described in Chapter 5. PV is more than just a feature modelling plug-in. By separation of concerns it is possible to model an SPL via feature models. Further, family models provide information about how to assemble a single product of an SPL out of existing components. Components can be source code, documentation, or any other textual entity. Each selection of features generates a variant model that describes a single product, in Figure 2.13 a variant model is called feature selection. A transformer engine is capable of assembling a concrete product out of these three models. Figure 2.13 illustrates the transformation process that generates a product of an SPL.

33 2.3. TOOLS 23 Figure 2.13: The transformation process of pure::variants from a feature model to a product variant. An important feature of pure::variants is, that it provides a connector to openarchitectureware. With the connector, it is possible to export variant models as instances of Ecore models. Such instances are processable by openarchitectureware workows, see Section With the help of the connector a feature model can control an openarchitectureware workow. Figure 2.14: Notations for feature diagrams used in pure::variants. On the left hand side tree-editor notation and on the right hand side graph notation. Feature models in pure::variants use a dierent syntax from any of the other notations illustrated in Figure 2.3. The notation of pure::variants is illustrated in Figure 2.14, that gives an overview of what is expressible by graphical means. Used symbols are yellow exclamation marks for mandatory features, pink question marks for optional features, double-headed arrows in green for alternative (XOR) features, and blue crosses for ORfeatures. Rules between features are called restrictions in pure::variants. For declaring restrictions between features pvprolog, an expression language, can be used. It is a Prolog dialect with predened operators and functions, that resemble OCL. In case that restrictions are not expressible via the predened functions, missing functionality can be implemented in Prolog. Restrictions are automatically checked whenever a variant model is generated and invalid selections are indicated. pure::variants also provides an auto-resolver, that is capable of resolving restrictions if there are no ambiguities. Features that use restrictions, are marked by a small exclamation mark on yellow ground that annotates the corresponding feature symbol. Since pure::variants appears to be the most mature feature modelling tool that easily connects to openarchitectureware, it was chosen to be deployed in the implementation of

34 24 CHAPTER 2. TERMS, DEFINITIONS, AND TECHNIQUES product line support for an MTCG system. It is used in real-world scenarios and of proven value in industry projects Feature Modeling Plug-In (fmp) The Feature Modeling Plug-In (fmp) [AC04] is an Eclipse plug-in that allows for constructing, editing, and conguring of feature models. It was developed at University of Waterloo. It is distributed as open source software under the Eclipse Public License (EPL). Each con- guration of a feature model with fmp generates a variant model. During conguration, existing rules between features are evaluated and non-valid selections are indicated. In fmp such rules are called constraints. Furthermore, product lining is supported by using fmp in combination with the fmp2rsm plug-in. The latter allows to map features on sets of UML model elements in Rational Software Modeler (RSM). In [CA05], it is described how to use UML models as templates, whose instances, i. e., single products of the product line, are generated via variant models. Out of each UML model instance, source code or a whole software system can be generated. fmp2rsm requires RSM, i. e., one is tied to the use of this tool. Figure 2.15: A feature model in fmp that contains a mandatory and an optional feature, a group of exclusive (XOR), and a group of alternative (OR) features. For feature modelling with fmp, the cardinality based notation is used, see the rightmost column in Figure 2.3 or [CHE05]. The notation is slightly modied and iconised to be usable in a tree-editor. Figure 2.15 shows some basic structures modelled with fmp. As in other tools, it is possible to declare rules between features with fmp. Rules are specied using the XML Path Language (XPath), i. e., via direct references to the elements of the XML document that contains the feature model. The fmp tool is presented, since it is an open source tool that readers may want to consider when developing a feature modelling solution. It is not chosen to act as feature modelling tool for the implementation of product line support to an MTCG system, see Chapter 5, since Intershop requires to use openarchitectureware as MDSD framework for the transformation process and fmp provides no openarchitectureware connector by default EMF and Ecore The Eclipse Modeling Framework (EMF) [emf08] is an Eclipse project that allows for creating metamodels and the automatic generation of Java source code out of metamodels. This source code serves as API (Application Programming Interface) for further modelling.

35 2.3. TOOLS 25 The most important EMF component is Ecore. Ecore is a metametamodel that is based on Essential MOF (EMOF) which is a subset of the Meta Object Facility (MOF). Ecore is selfdescribing and contains model elements, such as entities, attributes, operations, relations, for dening metamodels. All models used in the remainder of this work are Ecore based models, since openarchitectureware supports Ecore models by default. Ecore models are stored using XML. A model can be generated using the generated Java-API, or preferably, using the EMF tree-editor that is generated for each metamodel MDSD Framework openarchitectureware The existing MTCG system at Intershop is implemented using openarchitectureware. As already mentioned, the existing MTCG system needs to be extended to support SPL by using feature models. Since it is required to reuse the MDSD framework and the already implemented model transformers and code generators of the existing MTCG system, openarchitectureware and its components are described in the following sections. To get a closer look at openarchitectureware and its components, refer to its documentation [SE07] and its homepage [E07]. openarchitectureware [E07] is a modular, open source MDSD generator framework. It contains a language family that allows for transforming models, code generation, and model checking. Furthermore, a workow engine is provided that forms the backbone for MTCG systems, i. e., it allows the specication and execution of transformation ows. The workow engine is freely adaptable and extensible to t needs that are not met by prebuilt workow components. As an outstanding feature, openarchitectureware is able to deal with instances of dierent metametamodels such as Ecore, XML, UML2, etc. Furthermore, XVar and XWeave provide means for handling negative and positive variability in models The Workow Engine Transformation ows of MTCG systems are implemented as workows when using open- ArchitectureWare. Therefor, a workow engine is provided. At the moment, in openarchitectureware version 4.1, workows are implemented using an XML based, declarative conguration language. A workow consists of workow components that are subsequently declared. Each component represents the invocation of model transformers, code generators, model parsers, or model validators. openarchitectureware provides ready to use, standard workow components. If they do not t particular needs, proprietary workow components can be implemented, which makes the workow engine arbitrarily extensible. Section described the two possible strategies for transformation ow specications. With openarchitectureware transformation ows are implemented explicitly The oaw Expression Language As described in Section , languages for specifying model transformers and code generators are required. openarchitectureware provides a set of textual languages for several tasks, that are characteristic in an MDSD context. These are: XTend for specifying model transformers, Xpand for specifying code generators, and Check as a model checking or verication language. These three languages are based on a common expression language and common type system. The type system together with the expression language forms

36 26 CHAPTER 2. TERMS, DEFINITIONS, AND TECHNIQUES the expression framework. The advantage is, that the syntax for all three languages that use the expression framework remains the same. As stated above openarchitectureware is capable of handling models with dierent metametamodels, such as Ecore, UML2, JavaBeans, XML Schema, etc. The expression framework forms an abstraction layer over the metametamodels to unify their types, so that they are usable with the expression language XTend Model transformers in an openarchitectureware environment are implemented in XTend. It is a functional language in which transformation rules are specied as functions. These functions are called extensions, since they extend models or model elements for the time of a transformation non-invasively with behaviour. A model transformation can contain multiple transformation rules, what means that there can be multiple extensions within an extension le. Each le represents a model transformer. XTend uses expressions of openarchitectureware's expression language and operates on types provided by openarchitectureware's type system. Extensions written in XTend can be called from the other openarchitectureware languages XPand and Check XPand When using openarchitectureware, code generators are implemented in XPand. It is a template language. XPand code is used as metaterms in templates to control what is generated to a le. Such templates contain plain text that is written to a le. Additionally, the text is enriched with metaterms that serve as anchor for insertions that are produced by the generator Subprojects of oaw Since openarchitectureware is an MDSD framework it consists of multiple components that might be useful in model driven software development. The following paragraphs only explain XVar and XWeave in more detail. Both components are deployed for the implementation of product lining in an MTCG system XVar XVar [GV07a] is the openarchitectureware component for dealing with negative variability in models or metamodels. It enables removing model elements from a model with respect to the selected features in a variant model. As mentioned before, openarchitectureware is an open source project and XVar is a comparatively young project. Until now, there is no real documentation, except a screencast [SE07]. Due to its importance for the implementation of a model merger, it is explained more detailed in this paragraph. To tailor a model with respect to the selected features in a variant model via XVar, three models are needed. Firstly, an arbitrary model M that should be tailored, secondly a variant model containing features that are associated with elements of the model M, and

37 2.3. TOOLS 27 Figure 2.16: A schematic illustration of XVar's required inputs and its output. at last a feature dependency model (FDM) which is a model that associates model elements with features. An FDM has a simple structure for expressing dependencies. Each dependency refers to one feature and one or more model elements of a base model that are removed whenever a feature is not selected and therefore not part of a variant model. Removing of elements is performed via string comparisons of the names of the elements declared in dependencies within an FDM and those within the model. An example for an FDM in XML is given in Section openarchitectureware provides a component for invoking XVar with the corresponding models within a workow. That is depicted in Figure Therefore, XVar performs a model transformation, that is completely described by models XWeave XWeave [GV07a, GV07b] is an openarchitectureware component that handles positive variability of models or metamodels. It weaves model elements, contained in aspect models into a base model. Similarly, to XVar, there is no real documentation for XWeave. But the screencast [SE07] gives a rst brief glimpse on the function of XWeave. Because of that, this paragraph explains XWeave and the syntax it uses in more detail. Figure 2.17: A schematic illustration of XWeave's required inputs and its output. To correctly weave an aspect model into a base model, the model weaver needs to know where to weave the appropriate elements of an aspect model into the base model. The weaving rules, i. e., the pointcuts, are specied in a separate pointcut le, that is passed

38 28 CHAPTER 2. TERMS, DEFINITIONS, AND TECHNIQUES to the weaver together with an aspect model. XWeave expects the pointcuts to be implemented as XTend extensions. For the specication of the joinpoints that shall be matched in a base model, one can use a number of wildcards. They prex the name of elements in aspect models. The wildcards are: *-Wildcard: The asterisk replaces the name of a model element in an aspect model. It means that all model elements in the base model, that are of the same type as the one that is tagged with an asterisk in the aspect model, are matched by the pointcut. The asterisk is the single wildcard that requires no further extension declaration in the pointcut le. It is resolved by the model weaver. %-Wildcard: The percent sign is used to identify a collection of pointcuts. That is, the extension matches to a at least one joinpoint that is returned as a collection. $-Wildcard: This sign is used to declare, that the pointcut extension matches exactly one joinpoint in the base model.?-wildcard: The question mark identies the extension as a string function, i. e., it returns a string. They are used to calculate names for elements of the aspect model that should change their name when they are woven into a base model. All model elements within the aspect model that are not tagged with wildcards are added unaltered to the base model. An example for an aspect model and its corresponding pointcut le can be found in Chapter 5. openarchitectureware provides a component for invoking XWeave with the corresponding models and pointcut les within a workow. This is depicted in Figure XWeave, similarly to XVar, is a model transformation that is completely described by models.

39 Chapter 3 Software Manufacturing at Intershop Intershop is a leading manufacturer of e-commerce software. The current product Ennity Suite 6, allows for an easy setup of online shops and provides support for dierent e- commerce business models. When manufacturing software in an industrial environment one faces two major problems. 1. How to improve the overall process of manufacturing and how to improve its eciency? 2. How to improve eectiveness of single development steps? To nd possible solutions and improvements, it is necessary to analyse current approaches. Therefore, this chapter describes the current manufacturing process of Intershop in Section 3.1, and an existing MDSD infrastructure for the development phase in Section The Existing Software Manufacturing Process The existing software manufacturing approach used at Intershop is a phase-based, iterative approach. It is illustrated in Figure 3.1. The development platform is the current release of the Ennity Suite. It contains a set of features that are oered to customers as a standard product. Usually, customers require a customisation of this standard product to t their particular needs. In such a case, negotiations between customers and sales employees lead to a contract and to a specication of the new features. There are two types of projects. These are projects that implement: Project Features: Project features customise the product for a single customer. Product Features: Product features implement customisations that become merged into the platform, and thus form a new product release. It is neither illustrated nor further explained how the merging of new features into the platform is performed exactly. One or more project managers decide whether a feature is a project or a product feature. The decision is driven by economical and legal issues. In both cases, software, documentation, etc., is developed. The new developments are integrated 29

40 30 CHAPTER 3. SOFTWARE MANUFACTURING AT INTERSHOP Figure 3.1: Intershop's software manufacturing process. On the left a time bar with the phases of the manufacturing process, aside, the involved groups with their relations (blue arrows), and on the right the actual state of the product.

41 3.2. THE EXISTING MTCG SYSTEM 31 into the platform. For product customisation either one or both of the two possible project types are carried out. This way, a customised product is developed, deployed, and delivered to the customer. By using such a software manufacturing approach it is possible to customise a standard product to t customer needs. Furthermore, a separation of development steps is possible, this enables for versioning of the platform. A disadvantage is, that the customer receives a product that fulls its particular requirements, but, since it is based on a platform, it may provide features and functionality that will never be used, it exceeds its requirements. Obviously, the product can not be perfectly tailored to customer needs when using a software manufacturing process as described above. Since product features are merged into the platform, over time it becomes bloated with features. Another drawback is that the decision between the two project types is slightly articial, since both types develop features and it would be more ecient to dene a customised product solely by the features it contains. To reach this goal, this work proposes a dierent software development process (Section 4.1), that simplies the software manufacturing process which is described in Section The Existing MTCG System Figure 3.2: Illustration of a transformation ow of an MTCG system, transforming domain specic models. Transformers (vertical arrows) and generators (horizontal arrows) are implemented using oaw. To increase eciency of software development at Intershop, MDSD is regarded as a key technology, and an MTCG system was developed. Figure 3.1 shows, that during the development phase, the main focus is on the development of source code. Shifting the focus from developing source code to the development of models, leads to a more abstract,

42 32 CHAPTER 3. SOFTWARE MANUFACTURING AT INTERSHOP stable, and ecient development process. Furthermore, development artefacts become more reusable. The overall software manufacturing process remains the same as depicted in Figure 3.1. Intershop's MTCG system consists of domain-specic, Ecore based models, cascading model transformations, and code generation steps. The current architecture of this MTCG system is described below. Figure 3.2 depicts the transformation ow of Intershop's MTCG system. A transformation ow consists of cascading model-to-model transformations and intermediate artefact generation steps. Each box in Figure 3.2 symbolises a domain-specic model on a particular abstraction layer, i. e., a model level. The level of abstraction decreases from top to bottom. All models are based on the EMF metametamodel Ecore [emf08]. The domainspecic models, that are currently used capture parts of software systems that need to be persistent, i. e., data models, on dierent abstraction levels. DBM Level: Database models (DBM )describe the structure of particular databases, e. g., Oracle or MySQL databases. They are the most concrete platform dependent models in the transformation ow. Database models contain tables with columns, particular constraints, etc. They are used to generate, e. g., SQL les for conguring the database. ORM Level: The object relational mapping layer (ORM ) is an intermediate model level. It models persistent business objects and describes their mapping to the database, but provides less abstraction than BOM models. The key model elements are ORM Beans and their relations. Models on ORM level provide concepts, such as inheritance among ORM Beans and 1-to-n relations. Amongst others, Java classes which implement the ORM Beans are generated out of ORM models. BOM Level: The business object model (BOM ) level contains platform independent models for persistent business objects and their relations, it is an object model. A BOM model provides a view, i. e., additional abstractions, on the underlying ORM model. It was established to further simplify the development of persistent business objects. Persistent business objects are modelled via BOM Beans. Examples for higher abstraction in contrast to the ORM level are that BOM Beans may contain multiple localised attributes, or that there are association BOM Beans and n-to-m relations. Figure 3.3 illustrates some examples for how structures in BOM models are transformed to ORM level. UML Level: UML class diagrams are used to capture the structure of a software system. This level is used as modelling and presentation layer. A complete software system structure can be modelled, but for further processing, only BOM -specic model elements are used. They are marked by stereotypes dened in an UML prole, such as BOM Bean for classes. Transformers, symbolised by vertical arrows in Figure 3.2, are implemented using XTend. Generators for Java source code, documentation, conguration les, and other textual artefacts are implemented using XPand. Generators are symbolised by horizontal arrows in Figure 3.2. The whole transformation ow is implemented by a workow that uses openarchitectureware's workow engine. The approach described above is suitable for development phases in processes for developing single software products that share the same systems architecture, so-called heterogeneous

43 3.2. THE EXISTING MTCG SYSTEM 33 Figure 3.3: Example for decreasing the abstraction level. Association BOM Beans are transformed to ORM Beans with adjusting the relations (left hand side), n-to-m relations become 1-to-n relations by introducing a new helper bean (centre), and localised attributes in BOM Beans are transformed to attributes of a helper ORM Bean (right hand side). systems. However, Intershop provides an e-commerce software that is adapted to customer requirements, as described in Section 4.2. This means, all delivered products share many commonalities, they are homogeneous systems. Homogeneous software systems of a same domain form a software product family. For managing software product families, product lining becomes interesting. But how can the transformation ow be altered to include variability, and where can be intervened? How can the existing system be adapted to support product lining? How can existing large models be split into smaller models representing single distinctive features? The following chapter discusses possible answers to these questions and describes a possible solution.

44 34 CHAPTER 3. SOFTWARE MANUFACTURING AT INTERSHOP

45 Chapter 4 A Concept for Software Manufacturing Using SPL The software manufacturing process, especially the development phases, that are described in the last chapter are not perfectly suitable when developing multiple software products that share a high degree of commonality. The described manufacturing process and the development phase ts better to the development of heterogeneous software systems. Producing software of one domain, as Intershop does for the e-commerce domain, requires to modify the present MTCG system, the one of Section 3.2, to allow for the generation of software products of a family. The following sections describe a new approach for modifying the present MTCG system to allow for software product lining under control of a feature model, with help of aspect models. It is described what is generally possible and what seems to be suitable for a prototypical implementation of an MTCG system, which supports product lining. Furthermore, the eect of using such an MTCG system within the development phases, for the overall software manufacturing process is described. 4.1 Product Lining for an MTCG System The goal of this section is to modify the present MTCG system to support product lining. Since feature models represent software families and variant models represent single products of such a family, the idea is to let a feature model, or its instances the variant models, control the MTCG system in a manner that the resulting software system is dened by its features. As the remainder of this chapter will show, the key issue is how the features that represent the variabilities of software systems and the information that is associated with features, can be merged to generate a complete product Eects of Features on a Software System in General First introduced in FODA [KCH + 90] and as described in Section 2.1.6, feature models can be used for modelling variability and commonality between software systems. Generally, selected or deselected features, i. e., a variant model, may aect a software system at various points. According to [SVEH07], a feature may aect a software system: 35

46 36 CHAPTER 4. A CONCEPT FOR SOFTWARE MANUFACTURING USING SPL On Source Code Level: Where features may represent some snippets of source code that, if a feature is selected, become coded into the software sources. At Compile Time: Features represent code snippets but they are not injected into the source code directly, instead a code or aspect weaver cares about including particular code into the compilation whenever an corresponding feature is selected. At Linking Time: A product may be congured by a linker that binds some particular libraries that depend on selected features. At Installation Time: Software products that are explicitly deployed may be congured during the installation phase. At Loading Time: A feature may also represent one or more parts of software that are included at the time the application is loaded. Think of plug-ins, DLL's, etc. At Run Time: Even at run time it is possible to alter the behaviour of software, e. g., by polymorphism Eects of Features on an MTCG System A subset of the above mentioned alternatives for the point at which a feature eects a software system was chosen for further investigations. These are: A feature aects the software's source code directly, or a feature is considered at compile time. Compile Time as used in [SVEH07] means compiling of source code written in a programming language. But the intent of the term can be extended to compiling of models. As stated earlier, features are associated with additional information. In this work the additional information can be models. Models represent more abstract code. In this case, the current MTCG system is regarded as compiler for models that are converted into another representation, into software. That way, the terms of aecting a software system on source code level and on compile time become equivalent, since the content of models associated with features, is automatically coded into artefacts by running a compiler, which is the model transformation system in Figure 4.4. As Section will show, features are associated with aspect models that encapsulate variability. In Section it is argued that it is not suitable to support dynamic crosscutting for AOM, i. e., it is not suitable to let an aspect model aect a software system at runtime. It should rather be invoked on model level. Therefore, it is obvious to consider only the model compiler, more precisely, the transformation ow, to be controlled by a feature model that denes the automatically generated software. After the decision to let a feature model aect an MTCG system at compile time is made, there are two ways to implement it: Alter Existing Transformers and Generators: This means manually modifying their source code in some way, by new modules, or new aspects.

47 4.1. PRODUCT LINING FOR AN MTCG SYSTEM 37 Alter the Transformation Flow: This means reusing existing transformers and generators and introducing new ones that are plugged into the transformation ow. Beyond that, the invocation of existing transformers and generators will be controlled by features Feature Types in MTCG Systems In case of Intershop, altering transformers and generators is inappropriate, since these components are already in use in production systems and are working reliably. Altering the transformation ow of an MTCG system implies two types of features, that are characterised by the manner in which they aect the transformation ow. These are: Figure 4.1: Overview of how a feature model can control a transformation ow. Aspect Features: Are features that control model transformations that are newly inserted into an existing transformation ow. Each aspect feature refers to an aspect model, see Section In the case of modifying an existent MTCG system to

48 38 CHAPTER 4. A CONCEPT FOR SOFTWARE MANUFACTURING USING SPL support product lining, aspect features control a model merging transformation, as depicted in Figure 4.1. Control Features: Are features that simply determine whether a particular transformer or generator is invoked or not. In Figure 4.1, they are symbolised by small circles on generation and transformation arrows. Aspect and control features may inuence the transformation ow whenever a transformation or generation step is performed, independently of the model level, even if Figure 4.1 illustrates only the control of a merging operation on BOM level Feature Models in MTCG Systems Figure 4.2: Feature models as they are used in this work. In addition to feature diagrams, they contain associations between features, models, and processing information. For a better understanding of the two feature types mentioned above, Figure 4.2 illustrates, how feature models are used in this work. Section states, that feature models contain feature diagrams and additional information. In this work, feature models contain exactly one feature diagram that contains features which are associated with additional information. For aspect features the additional information consists of aspect models and processing information and for control features, additional information is processing information solely. Processing information, is information about the structure and contents of a transformation ow, for example the order of transformer invocations. Figure 4.2 indicates that in this work, an aspect feature is associated with exactly one aspect model. Generally, an aspect feature can be associated with multiple aspect models, what extends the corresponding processing information. This way, the expressiveness of a feature can be enhanced, since it is not just the representation of one aspect model.when multiple aspect models are used, the processing information must however, contain information about how to process the aspect models before invoking them in the overall transformation ow. Section illustrates how such feature models are used in the case study that demonstrates the modied MTCG system. In comparison with software components, features may represent very ne grained variability of software systems. That is why, it has been decided to associate features with

49 4.1. PRODUCT LINING FOR AN MTCG SYSTEM 39 aspect models. Other associations might be useful aswell. For example, variability can be encapsulated in component models that are translated to components of a software system, see [Gri00]. In such a case, the issue of implementing a model merging transformation, that is described in the following sections, disappears Merging of Aspect Models, General Strategies This work uses a base model to model a minimal software system that contains some features by default. It is enriched with other features by merging aspect models into it. Now, that it is claried how features and aspect models are interconnected it still is unexplained how an aspect model can be merged with a base model when the according feature is selected within a variability model. The question of merging variability contained in aspect models is the key issue for supporting SPL in an MTCG system. Figure 4.1 indicates that models are merged directly; but another, indirect approach, is possible. Merging Models: Within a transformation ow, models could be merged on any model level. Depending on the implementation, a merger for each kind of metamodel or each kind of metametamodel is required. Whether a merger is dependent on metamodels or metametamodels depends on the implementation technique used for model merging, see Section However, a model merger that is only dependent to metametamodels is more desirable, since mergers that depend on metamodels need to be reimplemented for each new kind of metamodel. Figure 4.1 depicts model merging on BOM level. Merging Artefacts: In order to merge artefacts, a complete transformation ow is executed for the base model and all aspect models. The transformation ows for aspect models generate aspectual artefacts, e. g., aspects in a programming language as AspectJ. A complete software system is formed by merging the artefacts. Such a transformation ow is illustrated in Figure 4.3. This approach is dicult since artefacts may be anything from source code to documentation, and for each class of artefacts a merger is required. If generated artefacts take the form of source code, the above described approach is suitable when aspect weavers for the generated programming languages exist. Initial implementations of an MTCG system that supports SPL by being controlled by a feature model, tried to merge artefacts by generating Java classes and AspectJ [Lad03] aspects. Merging artefacts seemed to be not suitable, since the existing MTCG infrastructure already generates artefacts of dierent kinds, such as documentation, XML documents, etc. Thus, it does not seem reasonable to implement weavers for all kinds of artefacts and for any kind of artefact that will be developed in the future. Therefore, for merging models it is focused on solving the key issue of applying variability to a software system. The following section shows how a feature model can control an MTCG system using model transformations that merge models Merging of Aspect Models in Practice Model merging is generally possible on any model abstraction level. Figure 4.1 depicts the merging on BOM level. This manner of merging is chosen for the following reasons:

50 40 CHAPTER 4. A CONCEPT FOR SOFTWARE MANUFACTURING USING SPL Figure 4.3: A transformation ow that merges artefacts that are generated out of a base model and multiple aspect models. 1. As described in Section , merging is implemented via the consecutive application of XVar and XWeave. As metamodel for the models on UML level, serves the UML metametamodel of the Eclipse UML2 Project [uml08a]. Since XWeave requires that a model implements the standard Ecore API, and UML2 provides its own, it is not possible to use XWeave for merging at this level. 2. In the case of Intershop, UML is used as graphical editing and presentation layer, whereas, other methods for creating models, such as textual Domain Specic Languages (DSL), are imaginable. All real processing is done on BOM level and below. Moreover, model merging should be done on the highest possible model level, since other models and artefacts are automatically derived. Figure 4.4 provides a more detailed view of the extended transformation ow that allows for product lining, and shows where it is controlled by a feature model. Red circles highlight the points within the transformation ow where control features switch between alternative transformer or generator calls. The grey box with the merging operator represents the schematic of the new model merging implementation that is controlled by aspect features. The following sections explain technical details of the model merging implementation Notation As previously stated, models on UML level are used for presentation and editing. For modelling BOM models the standard UML is extended with a prole which contains BOM specic stereotypes. This prole is extended to enable aspect modelling with UML and for merging aspect models on BOM level. A set of aspect specic stereotypes has been introduced. They are applicable to a subset of UML model elements, i. e., at the moment the stereotypes are applicable to classes and properties. Table 4.1 provides an overview of the stereotypes and their usage.

51 4.1. PRODUCT LINING FOR AN MTCG SYSTEM 41 Figure 4.4: Extended transformation ow from Figure 3.2 that is controlled by a feature model. It is possible to use this extension along with the aspect model syntax provided by openarchitectureware, see [GV07a] or Section , in one model, e. g., for specifying pointcuts that are not easily expressible using only the stereotypes. Section 5.1.3, especially the demo aspect model, provides examples for all possible applications of the mentioned stereotypes to UML model elements.

52 42 CHAPTER 4. A CONCEPT FOR SOFTWARE MANUFACTURING USING SPL Stereotype Properties Meaning BOMBaseElement Refers to a model element that resides in the base model. It is used to dene a particular joinpoint in the base model. BOM XVar nameofowningfeature Species elements of a base model that will be removed from the model whenever a feature declared in nameofowningfeature is not included in the corresponding variant model. This stereotype is applicable to properties to allow for removing of relations of a base model. BOM XWeave pointcutspec Species model elements that will be added to the base model. The property pointcutspec declares the name of the pointcut function. If pointcutspec is left empty, the model element marked with BOM XWeave is woven into exactly one element in the base model. Using an asterisk (*) weaves the marked model element to each class of the base model. Using the syntax of XWeave it is possible to declare arbitrary pointcut specications. Table 4.1: Overview over stereotypes used in UML aspect models. If it is desired to switch from UML as presentation and editing layer to another model and to reuse the model merger of this work, it is necessary to implement equivalents for the stereotypes. In such a case the transformation from aspect UML to aspect BOM needs to be slightly reworked, so that the correct XWeave syntax, see Section is generated on BOM level. To allow for aspect modelling it was decided to use a prole that denes stereotypes that extend UML, because aspect modelling is not supported by the UML standard Implementation of Merging of Aspect Models Model merging is a special kind of model transformation. With openarchitectureware, model merging can be implemented in the following two ways: Using XTend: Since model merging is a special case of a model transformation and XTend is the openarchitectureware model transformation language, it is possible to implement a merger that makes use of the stereotypes described in with XTend, but such a merger becomes highly coupled to a particular metamodel. That is, when it is desired to switch the model level where models are merged, a new merger that implements the same logic but works on new metamodel elements must be built. Using XVar and XWeave: Makes the implementation of a merger more independent of a specic metamodel, since XVar and XWeave depend only on Ecore as metametamodel. XVar is openarchitectureware's component to handle negative variability.

53 4.1. PRODUCT LINING FOR AN MTCG SYSTEM 43 It allows for removing model elements from a model according to selected features in a variant model. XWeave handles positive variability. It weaves model elements into a base model. Section states that merging is the consecutive application of negative and positive variability to a base model. Thus, a merger consists of a consecutive application of XVar and XWeave, as shown in Figure 4.4. Since new models with new metamodels may be introduced in a MTCG system, the second approach was chosen for implementing a merging transformation. The following sections describe how merging works and how it is implemented in the transformation ow of the present MTCG system Feature Dependency Model Feature dependency models are explained in Section This section describes how an FDM is used for the implementation of model merging. XVar requires an FDM to tailor a base model according to features selected in a variant model. For all available UML aspect models, an FDM is automatically generated once. A transformation visits each aspect, extracts all elements marked with the stereotype BOM XVar, and creates an appropriate dependency item in the FDM out of the stereotypes property nameofowningfeature. Subsequently, openarchitectureware's XVar component is fed with a base model on BOM level, with an automatically generated FDM, and with a variant model representing the software system to generate. The result of this transformation step is an intermediate BOM base model. An example for a FDM and the contained dependency components is provided in Section of the case study. Section describes the consecutive model merging. Since the application of negative variability is the rst component of a merging operation, it would be desirable to create an FDM for each aspect model and apply the negative variability by invoking XVar in cascades to properly remove model elements that are contained in depending aspect models. As explained before, this work only uses one FDM, therefore, aspect models can only remove elements of the base model and not those of other aspect models. This drawback is due to the fact, that each instance of openarchitectureware's workow engine can handle only one instance of an FDM. With the further development of openarchitectureware this barrier is likely to disappear. The implemented transformation that automatically generates an FDM can be further applied in such a case Transformation to Aspect BOM All aspect models on UML level are transformed to BOM level by extending the already existing transformer. This is necessary since the notation introduced by the UML prole in Section needs to be transformed to the syntax that is used by XWeave [GV07b]. Such a transformer performs two transformations at the same time: 1. A transformation from aspects on UML level to aspect models on BOM level, and 2. a transformation from aspect UML syntax to XWeave syntax.

54 44 CHAPTER 4. A CONCEPT FOR SOFTWARE MANUFACTURING USING SPL The second transformation can be adapted to operate on models that are based on the same metamodel, e. g., an intermediate aspect model on UML level, that uses the syntax of XWeave. XWeave is fed with a base model, an aspect model, and a le that contains specications of pointcuts. Similarly to XVar, independent of the kind of metamodel, but deals with models that are Ecore instances. The XWeave component is called separately for each aspect model, i. e., model weaving is performed in cascades, as explained for consecutive model merging of Section Examples for aspect models on BOM level that use the syntax required by XWeave are provided in Section Pointcut Generation Pointcuts and how they are specied with extensions are explained in Section Simple pointcut specications, those that are matching exactly one or all joinpoints of some type, are generated automatically. If a UML aspect model makes use of the stereotypes as introduced in Section , pointcut specications are generated automatically. If the property pointcutspec of stereotype BOM XWeave is left empty, the marked element will be woven to one model element in the base model that shares the same name. Such a pointcut specication is generated automatically. If the property pointcutspec contains an asterisk *, the marked model element is woven to all classes in the base model. Any other name of a pointcut specication function within that eld requires a manual implementation in a pointcut specication le. A workow component merges the automatically generated and the manually implemented pointcut specications together and, therefore, XWeave considers both types of pointcuts. Section provides an example Control Features Control features are interpreted as if -components in an openarchitectureware workow. These components allow to control the invocation of workow components depending on the features of a variant model. The four grey circles in Figure 4.4 symbolise control features. That is, each call for a generator or transformer component depends on a selected feature. An example for how control features aect an openarchitectureware workow is given as pseudocode in Section Implementing a Transformation Flow At the moment transformation ows are manually implemented as openarchitectureware workows. That is, a developer needs to take care to implement the ow correctly to produce the desired result. The associations between features and their additional information, see Section 4.1.4, are given implicitly; at present, there is no model or conguration le that contains the information about the associations. Furthermore, the processing information is also given implicitly. For this reason, a developer who implements the openarchitectureware worklow needs to take care that features, that should serve as control features, are surrounded by an if component, and that the aspect models that are associated with aspect features are considered and merged in the right order.

55 4.2. A SOFTWARE MANUFACTURING PROCESS USING PRODUCT LINING 45 An improvement to the above described approach would be to use a tool, such as FeatureMapper [HKW08] or fmp [AC04]. Both tools are able to capture the associations between features and parts of models during the modelling activities. Another solution would be to introduce a model that contains the associations between aspect features and aspect models. With such a model a workow could be partially, automatically generated. The concepts discussed in this work, do not extend to the automatic generation of workows, since there may be ambiguities when multiple dependent aspects should be merged and it seems impossible to automatically generate a workow with correctly ordered workow components out of a feature model without additional information. 4.2 A Software Manufacturing Process Using Product Lining When introducing the model driven, feature model controlled, product line supporting approach to the software development phase, the overall software manufacturing process of Figure 3.1 is simplied, resulting in the process that is depicted in Figure 4.5. Similarly, to the manufacturing process of Figure 3.1, negotiations with a customer lead to a contract and a product specication that serves as bases for the product customisation. For the new SPL supporting approach, it is no longer important whether a feature is a project or a product feature. Project managers divide the requirements into features. As stated in Section 2.2.3, this work assumes that features are already identied via a feature oriented domain analysis method. It is likely that the requirements and specication phase becomes more complex, when further investigating on domain engineering and SPL engineering. Project managers also care about the base model which represents a minimal software system that contains some default features. Although the illustration in Figure 4.5 may lead to the assumption that a base model needs to be developed for each project, this is not necessarily the case. Often an existing base model can be reworked; for example, some elements may be encapsulated in aspect models. Subsequently, developers focus on realising product features via aspect models. At present it is left to future research to investigate if the development of aspect models can scale to large projects, since aspect models may depend on each other. This can be a barrier for developing multiple aspect models by multiple developers at the same time. When the development of all aspect models is nished, a lead engineer selects the appropriate features for a certain product and runs the transformation ow that automatically generates a customised product which becomes deployed and delivered. It is worth pointing out that with such a manufacturing process the end product does not become bloated with features that might not be needed by the customer. Instead, the delivered product is perfectly tted to the customers requirements. In this new software manufacturing process, there is no longer a platform, in the sense of product releases as described in Chapter 3, that serves as basis for customisations. In this new manufacturing process a model of a minimal base software system and the technical MDSD infrastructure form a platform. All required functionality of the product is directly developed as features via aspect models. Features that are developed once, are stored in a database for a possible reuse in other projects. There is no longer a standard product, since each time a software product is ordered, a new version that ts the customer needs, is automatically generated by selecting the appropriate features. Therefore, identifying good features becomes crucial for the successful deployment of such an approach.

56 46 CHAPTER 4. A CONCEPT FOR SOFTWARE MANUFACTURING USING SPL Figure 4.5: A new software manufacturing process, that allows for software product lining. On the left hand side a time bar with the phases of the manufacturing process, alongside, the involved groups with their relations (blue arrows), and on the right hand side the actual state of the product.

57 4.2. A SOFTWARE MANUFACTURING PROCESS USING PRODUCT LINING 47 Here, it is not further investigated how testing must be conducted during the development phase. Surely, this becomes a dicult task, since developed features can be tested in multiple variations, e. g., features are tested independently, in composition with selected other features, or all possible feature combinations can be tested Versioning with SPL The feature-oriented MDSD approach that is described in this chapter can be used for versioning of a software product. In this case, a version of a software system is characterised by the features it includes. The dierence to the product line approach is, that not a software family is regarded, but a single product, and that not single products of a family are automatically generated, but versions of a software system. A new version of a software system handles the features and the models that are associated with such features as a base system or a base model, respectively. A new version is generated by adding features to such a base system. It is conceivable to combine the product line approach with the versioning approach in a two staged process. Firstly, a customised product, that serves as a base product, is generated with the help of the product line approach. Secondly, each customised product can be versioned independently.

58 48 CHAPTER 4. A CONCEPT FOR SOFTWARE MANUFACTURING USING SPL

59 Chapter 5 A Case Study This chapter provides a case study for a feature model controlled MTCG system. At rst a scenario is composed. Subsequently, models that appropriately capture the matter of facts are described. This is, a feature model with the corresponding base model and aspect models on UML level. The transformations of the UML models to BOM level are explained. The step of merging aspect models into a base model on BOM level is specied by illustrating the corresponding stepwise application of negative and positive variability. The result of the merging process, that serves as a basis for further model transformations and code generation is presented. 5.1 The Scenario Since Intershop manufactures e-commerce software, the case study uses a very simple example related to e-commerce. The scenario is, that there is a software family of online stores that are characterised by a number of possible features. For such an online store family a feature model is developed with pure::variants. Subsequently, a base model of a minimal software system on UML level and the corresponding features are developed. If a feature is an aspect feature a corresponding UML aspect model is developed that refers to the base model. All UML modelling is done with the UML editor of Intershop's Ennity Studio, which is the Eclipse-based IDE of Intershop. Finally, an openarchitectureware workow which transforms the provided models and generates parts of a software system is implemented The Feature Diagram The family of online store software systems should contain the following features. There are dierent options for how to store contact information of customers. Either only names and addresses shall be stored or the address information is splitted into a name, the street, the house number, and postcode of each customer. That is, there are two ways to store an address. Furthermore, an online store should either contain oered products directly or it should contain catalogues that contain products. Products of an online store can be priced in dierent manners. Either each product has a standard price or there are scale prices or there are product prices, i. e., a third pricing facility that is not further considered at 49

60 50 CHAPTER 5. A CASE STUDY the moment. To correctly administrate the invoices of customers there may be a billing system that is optional. Concerning the technical aspects, an online store should either use an MySQL or Oracle database, and provide some support for exporting and browsing object information. The, above described, very highlevel description of an example system family may be translated to the feature diagram in Figure 5.1 Figure 5.1: The feature diagram for an exemplary family of online stores. That feature diagram shows the features of a an exemplary online store and their relations. It is obvious, that an online store supports two types of address management, since a mandatory feature Address contains two mutually exclusive subfeatures for either Standard or Extended addresses. The mandatory feature database means, that an online store must have a database, either an Oracle or MySQL database. There are three mutually exclusive subfeatures for the feature Pricing. These are Standard Pricing, Scale Pricing, and Product Pricing. The Feature ProductManagement is mandatory. It contains two mutal exclusive subfeatures. Billing is an optional feature. The small exclamation mark signalises that there is a restriction, i. e., it depends on another feature. The Prolog function for expressing such an restriction is requiresfeature('extended'). As Section will show, a feature B that depends on a feature A is associated with an aspect model that depends on the aspect model that is associated with feature A. The optional feature Export formulates the restriction, that it either requiresfeature('json') or (requiresfeature('xom')). A BOMBrowser is a small web application to browse persistent objects. It is automatically generated if the corresponding optional feature is selected. The Demo feature is associated with a demonstration aspect model that serves as example source The UML Base Model The base model on UML level captures the data model of a simple online store. It states that a store has a name and can have multiple customers. Furthermore, a store can contain

61 5.1. THE SCENARIO 51 Figure 5.2: The base model on UML level, it is an exemplary online store. multiple products. For customers, names and addresses are stored, and each customer may have a basket consisting of line items each referring to a product, and storing the price and quantity of a product inside the basket. Each product has a name, a price, and a description The UML Aspect Models As described in Section an aspect feature is associated with exactly one aspect model. The case study example contains ve aspect features. These are: an Extended address, Billing, Product Pricing, and Scale Pricing, Catalogue, and, just for demonstration purposes, a Demo feature. Product Pricing is not further considered. Figure 5.3: UML aspect model that is associated with the aspect feature Extended The Extended Address Aspect Model The Extended address feature is associated with an aspect model that provides additional address information. Figure 5.3 shows the UML model to extend the address information. The address aspect model modies the base model in the following manner:

62 52 CHAPTER 5. A CASE STUDY 1. It adds a new class to the base model. In the aspect model the new class is tagged with the stereotype BOM XWeave. This class contains elements for storing extended address information. 2. It adds a containment relation between the class Customer and the class Address to the base model. 3. It removes two attributes from the class Customer in the base model. These attributes are tagged with the stereotype XVar The Billing Aspect Model Figure 5.4: UML aspect model that is associated with the aspect feature Billing. The Billing aspect model is an example for an aspect that depends on another aspect. Figure 5.4 shows this dependency. There, the class Address is tagged with the stereotype BOM BaseElement. The base model does not contain a class Address until the aspect model of Figure 5.3 is merged into it. Therefore, merging of the aspect models for an extended address and billing, must be performed consecutively, as described in Section The Catalogue Aspect Model Figure 5.5: UML aspect model that is associated with the aspect feature Catalogue. The aspect model that is associated with the aspect feature Catalogue, see Figure 5.5, modies the base model in the following way. 1. A class Catalogue is added to the base model of the online store. 2. The containment relations between the classes Store and Catalogue and Catalogue and Product are added to the base model. 3. The containment relation between the classes Store and Product is removed from the base model, since products are now organised in catalogues.

63 5.1. THE SCENARIO 53 Removing of relations is indicated by assigning the stereotype BOM XVar to the corresponding role names The Scale Price Aspect Model Figure 5.6: UML aspect model that is associated with the aspect feature Scale Pricing. The aspect model for the aspect feature Scale Pricing, Figure 5.6, adds classes to support scale prices, but it contains no new concepts and is thus not explained in more detail An Aspect Model for Demonstration Figure 5.7: UML aspect model that is associated with the aspect feature Demo.

64 54 CHAPTER 5. A CASE STUDY Figure 5.7 shows an aspect model that is not related with the case study. It just demonstrates that merging of an aspect model into a base model works reliably for all required model elements and it demonstrates the following concepts: Adding an Attribute to Exactly One Class: The class LineItem demonstrates how to add an attribute to exactly one class of the base model. It is not necessary to specify any pointcut functions for XWeave. They are generated automatically. Adding an Attribute to All Classes: The class ForAll adds an attribute to all classes of the base model. Therefore, one needs to insert an asterisk to the property pointcutspec of the stereotype BOM XWeave. Using the XWeave Sytnax: It is possible to use the syntax of XWeave on UML level, as it is shown by the class %getsomeclasses. Examplarily, it should refer to the classes Store and Basket. The corresponding poincut specication needs to be implemented manually, e. g., as getsomeclasses ( bom:: BOMModel n): n. eallcontents. typeselect ( bom::bombean ). select (e e. name == " Store " e. name == " Basket "); The Feature Model As described in Section 4.1.4, features are associated with additional information. That is, a feature model in the case study is formed by the feature diagram, the aspect models and processing information. Figure 5.8 illustrates the associations between aspect features and the corresponding aspect models by using dashed lines. Red ellipses in the variant model indicate aspect features. Red ellipses over the base model and the aspect models mark single joinpoints matched by pointcuts of aspect models. Note that, for illustration purposes the matching of pointcuts to joinpoints has been included in Figure 5.8. In fact this matching is performed on BOM level and not on UML level; but as stated in Section 4.1.8, the association information is given implicitly and therefore, Figure 5.8 is intended as a visualisation for better understanding.

65 5.1. THE SCENARIO 55 Figure 5.8: Associations between aspect features and their aspect models (dashed lines) and pointcuts that match single joinpoints (ellipses over UML models).