31) Feature Models and MDA for Product Lines

Size: px

Start display at page:

Download "31) Feature Models and MDA for Product Lines"

Jemima Chandler
5 years ago
Views:

Obligatory Literature Fakultät Informatik, Institut für Software- und Multimediatechnik, Lehrstuhl für Softwaretechnologie Ø Florian Heidenreich, Jan Kopcsek, and Christian Wende.

de/work/files/icse08-featuremapper---features-to- s.pdf 31) Feature s and MDA for Product Lines 1. Feature s 2. Product Linie Configuration with Feature s 3. Multi-Stage Configuration Ø Prof. Dr. U.

1 Obligatory Literature Fakultät Informatik, Institut für Software- und Multimediatechnik, Lehrstuhl für Softwaretechnologie Ø Florian Heidenreich, Jan Kopcsek, and Christian Wende. FeatureMapper: Features to s. In Companion Proceedings of the 30th International Conference on Software Engineering (ICSE'08), Leipzig, Germany, May s.pdf 31) Feature s and MDA for Product Lines 1. Feature s 2. Product Linie Configuration with Feature s 3. Multi-Stage Configuration Ø Prof. Dr. U. Aßmann Ø Florian Heidenreich Ø Technische Universität Dresden Ø Institut für Software- und Multimediatechnik Ø Gruppe Softwaretechnologie Ø Ø Version , January 23, 2013 References 2 Object-Oriented Analysis vs Object-Oriented Design Ø [Aßm03] U. Aßmann. Invasive Software Composition. Springer, Ø Ø [Cza05] K. Czarnecki and M. Antkiewicz. Features to s: A Template Approach Based on Superimposed Variants. In R. Glück and M. Lowry, editors, Proceedings of the 4th International Conference on Generative Programming and Component Engineering (GPCE'05), volume 3676 of LNCS, pages Springer, [Cza06] K. Czarnecki and K. Pietroszek. Verifying Feature-Based Templates Against Well-Formedness OCL Constraints. In Proceedings of the 5th International Conference on Generative Programming and Component Engineering (GPCE'06), pages , New York, NY, USA, ACM. textual requirements (stories) requirements specification context analysis Ø Ø Ø [Hei08a] F. Heidenreich, J. Kopcsek, and C. Wende. FeatureMapper: Features to s. In Companion Proceedings of the 30th International Conference on Software Engineering (ICSE'08), pages , New York, NY, USA, May ACM. [Hei08b] Florian Heidenreich, Ilie Şavga and Christian Wende. On Controlled Visualisations in Software Product Line Engineering. In Proc. of the 2nd Int l Workshop on Visualisation in Software Product Line Engineering (ViSPLE 2008), collocated with the 12th Int l Software Product Line Conference (SPLC 2008), Limerick, Ireland, September [Hei09] Florian Heidenreich. Towards Systematic Ensuring Well-Formedness of Software Product Lines. In Proceedings of the 1st Workshop on Feature- Oriented Software Development (FOSD 2009) collocated with MODELS/GPCE/ SLE Denver, Colorado, USA, October ACM Press use cases analysis domain architectural design detailed design Slide 3 4

Extended to -Driven Architecture (MDA) Product Lines (Product Families) Ø Horizontal product line: one product idea in several markets textual requirements (stories) use cases requirements

., n) specific Feature textual requirements (stories) (varability Product 1 use cases requirements specification context ) domain analysis Product 2 Product n 5 Adding Extensions to Abstract s in the

products in one or several markets The VIM (variant independent ) is the common of the product family Domain Platform independent (PIM) Platform-1-specific extension (PSE) weaving Configuration With

2 Extended to -Driven Architecture (MDA) Product Lines (Product Families) Ø Horizontal product line: one product idea in several markets textual requirements (stories) use cases requirements specification context analysis (CIM) analysis domain Platform independent Platform-1 specific Platform-(1,.., n) specific Feature textual requirements (stories) (varability Product 1 use cases requirements specification context ) domain analysis Product 2 Product n 5 Adding Extensions to Abstract s in the MDA 6 Configuration of Variabilities in Vertical Product Lines (MDA for Vertical Product Lines) Ø In the following, we extend the MDA (below) with configuration Vertical product line: several products in one or several markets The VIM (variant independent ) is the common of the product family Domain Platform independent (PIM) Platform-1-specific extension (PSE) weaving Configuration With Feature Variants Product Variants Design Variants Analysis Product Line (Framework, VIM) Platform-1 specific (PIM) Platform-2 specific extension (PSE) weaving weaving Configuration With Feature Variants PSM Variants Extensions Product PIM weaving Platform-(1+2) specific (PSM) 7 Product Product PSM PSM Product PSM 8

3 Feature s for Product configuration Ø Feature s are used to express variability in Product Lines Ø alternative, Ø mandatory, Ø optional features, and Ø their relations OR XOR 31.1 PRODUCT LINES WITH FEATURE TREES AND FEATURE MODELS Ø A variant represents a concrete product (variant) from the product line Ø The variant results from a selection of a subgraph of the feature Ø The variant can be used to parameterize and drive the product instantiation process Prof. U. Aßmann Feature-driven SPLE 9 10 Feature s Example Ø The Feature Tree Notation is derived from And-Or-Trees Group of AND Features Ø A1 or A2 or A3 Ø B1; B2 xor B3 Ø B4; optional B5 Ø B1; B7 Group of Alternative (XOR) Features Mandatory Feature Optional Feature Group of OR Features A1 A2 A3 FeatureA FeatureB FeatureD B1 B2 B3 B4 B5 B6 B7 PhD Thesis, Czarnecki (1998) based on FODA-Notation by Kang et al. (1990) 11 12

Ø [K. Lehmann-Siegemund, Diplomarbeit] Ein Featurel for Computer-Aided cognitive Rehabilitation Features to Fragments ( Snippets) Ø Bridging the gap between configuration and solution space FM K J E

4 Ø [K. Lehmann-Siegemund, Diplomarbeit] Ein Featurel for Computer-Aided cognitive Rehabilitation Features to Fragments ( Snippets) Ø Bridging the gap between configuration and solution space FM K J E S CE CU NO NM... ge gz IS IT T A IS IT ge gz T A ge gz IS IT T A ge gz IS IT T A [1-2] [1-2] [1-2] [1-2] A/K Ø Need for mapping of features from feature s to artefacts of the solution space Ø Possible artefacts Ø s defined in DSLs Ø fragments (snippets) Ø Architectural artefacts (components, connectors, aspects) Ø Source code Ø Files K J E S CE CU NO NM... Ø But how can we achieve the mapping...? [c1] ge T A IS IT IS IT [c1] T A [c1] ge gz IS IT T A [1-2] [1-2] [1-2] [1-2] [c1] IS IT T A Ex: Plugins have Features (in Eclipse) 15 Prof. U. Aßmann 31.2 PRODUCT-LINE CONFIGURATION WITH FEATURE MODELS Feature-driven SPLE 16

Different Approaches of Variant Selection Additive approach Ø Map all features to fragments ( snippets) Ø Compose them with a core based on the presence of the

in the variant Ø Pros: Ø conflicting variants can be led correctly Ø strong per-feature decomposition Ø Cons: Ø traceability problems Ø increased overhead in

correctly Ø huge and inconcise s 17 The Problem between Features and Solution Elements 18 Features to s Ø FeatureMapper - a tool for mapping of feature s to ling

org Problem Space FeatureA Creation Solu5on Space A B Ø Advantages: Ø Explicit representation of mappings Ø Configuration of large product lines from selection of

5 Different Approaches of Variant Selection Additive approach Ø Map all features to fragments ( snippets) Ø Compose them with a core based on the presence of the feature in the variant Different Approaches of Variant Selection (2) Subtractive approach Ø all features in one Ø Remove elements based on absence of the feature in the variant Ø Pros: Ø conflicting variants can be led correctly Ø strong per-feature decomposition Ø Cons: Ø traceability problems Ø increased overhead in linking the different fragments Ø Pros: Ø no need for redundant links between artifacts Ø short cognitive distance Ø Cons: Ø conflicting variants can't be led correctly Ø huge and inconcise s 17 The Problem between Features and Solution Elements 18 Features to s Ø FeatureMapper - a tool for mapping of feature s to ling artefacts developed at the ST Group Ø Screencast and paper available at Problem Space FeatureA Creation Solu5on Space A B Ø Advantages: Ø Explicit representation of mappings Ø Configuration of large product lines from selection of variants in feature trees Ø Customers understand Ø Consistency of each product in the line is simple to check Ø and code snippets can be traced to requirements Visualisation FeatureB FeatureD FeatureE Validation Derivation F G E D Slide 19 20

FeatureMapper Features to s Ø We chose an explicit Representation in our tool FeatureMapper Ø s are stored in a mapping that is based on a mapping meta Feature

Aßmann Slide 21 Feature-driven SPLE Slide 22 From Feature s to Transformations Visualisation of s (1) Ø Visualisations play a crucial role in Software Engineering

particular aspect of the connection between a feature and realising artefacts How a particular feature is realised?

6 FeatureMapper Features to s Ø We chose an explicit Representation in our tool FeatureMapper Ø s are stored in a mapping that is based on a mapping meta Feature Solu5on s FeatureA D A B E FeatureB FeatureD FeatureE FeatureE FeatureE G F F G E D Prof. U. Aßmann Slide 21 Feature-driven SPLE Slide 22 From Feature s to Transformations Visualisation of s (1) Ø Visualisations play a crucial role in Software Engineering It s hard to impossible to understand a complex system unless you look at it from different points of view Ø In many cases, developers are interested only in a particular aspect of the connection between a feature and realising artefacts How a particular feature is realised? Which features communicate or interact in their realisation? Which artefacts may be effectively used in a variant? Ø Solution of the FeatureMapper: Views, a visualisation technique that provides four basic visualisations Realisation View Variant View Context View Property-Changes View 23 Slide 24

Realisation View Variant View Ø For one Variant, the realisation in the solution space is shown Ø The variant

Address Address Address Slide 25 Slide 26 Context View Property-Changes View Ø The Context View draws the

.. Feature System Arbitrary Depth Recorded change- set of changing the cardinality of the reflexive

7 Realisation View Variant View Ø For one Variant, the realisation in the solution space is shown Ø The variant view shows different variant realisations (variant s) in parallel Feature Feature System System FeatureB Address Address Address Slide 25 Slide 26 Context View Property-Changes View Ø The Context View draws the variants with different colors Aspect-separation: each variant forms an aspect Feature System... Feature System Arbitrary Depth Recorded change- set of changing the cardinality of the reflexive associa5on of Group to itself from 1 to many Address Group Other Feature Arbitrary Depth Group Group... Address Address... Slide 27 Slide 28

Textual Languages Support (1) Textual Languages Support (2) Ø Unified handling of ling languages and textual languages by

languages from the EMFText Syntax Zoo are supported, including Java 5 Ø http://emftext.

Feature Solu5on s FeatureA D A B E FeatureB FeatureE G F F G E D FeatureD FeatureE FeatureE Variant <<in>> <<in>> Variant

8 Textual Languages Support (1) Textual Languages Support (2) Ø Unified handling of ling languages and textual languages by lifting textual languages to the ling level with the help of EMFText Ø Aspect-related color markup of the code Ø All >80 languages from the EMFText Syntax Zoo are supported, including Java 5 Ø Slide 29 Slide 30 -based Derivation of Transformations Ø Transformations in the solution space build the product Feature Solu5on s FeatureA D A B E FeatureB FeatureE G F F G E D FeatureD FeatureE FeatureE Variant <<in>> <<in>> Variant FeatureA FeatureB FeatureD <<in>> Derivation Of Transformations <<out>> A B E D 31.3 MULTI-STAGE CONFIGURATION Prof. U. Aßmann Feature-driven SPLE 32 Slide 31

FEASIPLE: A Multi-Stage Process Architecture for PLE FEASIPLE: A Multi-Stage Process Architecture for PLE Ø Chose one variant on each level Ø Feature Tree as input for the configuration of the

9 FEASIPLE: A Multi-Stage Process Architecture for PLE FEASIPLE: A Multi-Stage Process Architecture for PLE Ø Chose one variant on each level Ø Feature Tree as input for the configuration of the weavings Ø Goal: a staged MDSD-framework for PLE where each stage produces the software artefacts used for the next stage Advantages of FEASIPLE Advantages of FEASIPLE Ø Characteristic feature 1: Ø Variability on each stage Ø Characteristic feature 2: Ø Different ling languages, component systems and composition languages per stage 35 36

Advantages of FEASIPLE Advantages of FEASIPLE Ø Characteristic feature 3: Ø Different composition mechanisms per stage Ø Characteristic feature 4: Ø Composition mechanisms

38 TraCo: A Framework for Safe Multi-Stage Composition of Transformations Ø TraCo encapsulates transformations into composable components Arranges them with composition

SA2 SA1* context Feature PIM Platform Independent s Platform Independent s PlaLorm Independent s Platform variant V2 M2 T2 T1* M1* V1* M2M Trafos SA3 SA2* pla-orm Feature

10 Advantages of FEASIPLE Advantages of FEASIPLE Ø Characteristic feature 3: Ø Different composition mechanisms per stage Ø Characteristic feature 4: Ø Composition mechanisms are driven by variant selection 37 Multi-Staged Derivation of Transformations Ø How do we compose transformations? Between different stages? 38 TraCo: A Framework for Safe Multi-Stage Composition of Transformations Ø TraCo encapsulates transformations into composable components Arranges them with composition programs of parallel and sequential transformation steps (multi-threaded transformation func)onal Feature VIM Variant Independent Functional variant V1 M1 SA1 T1 M2M Trafos SA2 SA1* context Feature PIM Platform Independent s Platform Independent s PlaLorm Independent s Platform variant V2 M2 T2 T1* M1* V1* M2M Trafos SA3 SA2* pla-orm Feature PSM Platform Specific s Platform Specific s PlaLorm Specific s V1 Feature Selection M1 SA1 Solution Artefact T1 Transformation SAn-1 M2C Generators Context variant Vn Mn Tn PlaLorm Specific Code SAn Folie 39 Folie 40

Steps in Multi-Staged Derivation of Transformations Multi-Staged Derivation of Transformations 1. Transformations are represented as composable components 2.

Validation of each transformation and composition step Type-checking Invariant- and constraint-checking Correctness of port and parameter binding Static and dynamic analysis 4.

Connectors Constant value Slide 41 Slide 42 Composition Programs can be Configured (Metacomposition) Loading Functional Variability Add EJB Semantics Platform Variability Domain Load Domain VIM to

composition Load Actions VIM to VSM Actions to SimpleImpl UML UML to Java Actions to SimpleDelegateUML UML to Java Ø If we build a product line with TraCo, platform variability can be realised by

11 Steps in Multi-Staged Derivation of Transformations Multi-Staged Derivation of Transformations 1. Transformations are represented as composable components 2. Definition and Composition of Transformation Steps A Composition System is needed (course CBSE): Allows for reuse of arbitrary existing transformation techniques 3. Validation of each transformation and composition step Type-checking Invariant- and constraint-checking Correctness of port and parameter binding Static and dynamic analysis 4. Execution of composition program Ø Implemented in our tool TraCo Component, Composition Language, Composition Technique Component instances Component Adapter references Actual Transformation Code Connectors Constant value Slide 41 Slide 42 Composition Programs can be Configured (Metacomposition) Loading Functional Variability Add EJB Semantics Platform Variability Domain Load Domain VIM to VSM Domain to UML Attributes to Properties UML to Java Anything you can do, I do meta (Charles Simonyi) Ø The composition program shown in the last slide can be subject to transformation and composition Load Actions VIM to VSM Actions to SimpleImpl UML UML to Java Actions to SimpleDelegateUML UML to Java Ø If we build a product line with TraCo, platform variability can be realised by different transformation steps Actions Actions to EJB UML Add EJB Persistence Semantics UML to Java Ø A TraCo composition program can be used with FeatureMapper Multi-Staged transformation steps Even of composition programs Ø More about metacomposition in CBSE course Folie 43 January 2011 Florian Heidenreich - Feature-driven SPLE Folie 44 Application State User Interface Navigation Load ApplicationState Load User Interface Load Navigation VIM to VSM VIM to VSM VIM to VSM Actions to EJB Delegate UML ApplicationState to UML Ensure Control IDs Add Local Memory Semantics Attributes to Properties SWT User Interface JSP User Interface Navigation to Java Navigation to JSP Presentation SWT JSP UML to Java UML to Java Business Logic Java EJB Persistence In-Memory EJB Persistence Mixed EJB + In-Memory EJB + EJB Persistence

The final frontier: Ensuring Well-formedness of SPLs Ø Motivation: Make sure that well-formedness of all participating s is ensured Feature Solution s Ø Well-formedness rules are described using OCL

Simple Time Sheet Application Software Product Line FeatureMapper used to tailor ISC composition programs ISC used as a universal variability mechanism in SPLE Meta Transformation Ø Constraints are

12 The final frontier: Ensuring Well-formedness of SPLs Ø Motivation: Make sure that well-formedness of all participating s is ensured Feature Solution s Ø Well-formedness rules are described using OCL Case Studies with FeatureMapper, TraCo, and FEASIPLE Ø Simple Contact Management Application Software Product Line FeatureMapper used to map features to UML2 elements Both static and dynamic ling Ø Simple Time Sheet Application Software Product Line FeatureMapper used to tailor ISC composition programs ISC used as a universal variability mechanism in SPLE Meta Transformation Ø Constraints are enforced during mapping time The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. Ø SalesScenario Software Product Line FeatureMapper used to tailor s expressed in Ecore-based DSLs was developed in project feasiple ( Ø TAOSD AOM Crisis Management System Slide 45 Slide 46 Summary The End Ø Configuration of product lines with mapping of feature s to solution spaces Ø of Features to s in Ecore-based languages using FeatureMapper Ø Visualisations of those mappings using Views Realisation View Variant View Context View Property-Changes View Ø Derivation of solution s based on variant selection and mapping Ø Multi-Staged derivation using TraCo Ø Ensuring well-formedness of SPLs Slide 47 48

30 Transformational Design with Essential Aspect Decomposition: Model-Driven Architecture (MDA)

Fakultät Informatik, Institut für Software- und Multimediatechnik, Lehrstuhl für Softwaretechnologie 30 Transformational Design with Essential Aspect Decomposition: Model-Driven Architecture () Prof. Dr.