31. Feature Models and MDA for Product Lines

Transcription

1 Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie Prof. Aßmann - Softwaretechnologie II 31. Feature Models and MDA for Product Lines Prof. Dr. U. Aßmann Technische Universität Dresden Institut für Software- und Multimediatechnik Gruppe Softwaretechnologie Version , 14. Januar Feature Models 2. Product Linie Configuration with Feature Models 3. Multi-Stage Configuration 4. Multi-Stage Configuration of Transformations

2 Literature 2 Softwaretechnologie II Florian Heidenreich, Jan Kopcsek, and Christian Wende. FeatureMapper: Mapping Features to Models. In Companion Proceedings of the 30th International Conference on Software Engineering (ICSE'08), Leipzig, Germany, May Models.pdf Paul C. Clements, Linda M. Northrop: Software Product Lines: Practices and Patterns. Addison-Wesley Professional, Sven Apel, Don Batory, Christian Kästner, Gunter Saake: Feature-Oriented Software Product Lines Concepts and Implementation. Springer, 2013.

3 References Slide 3 Softwaretechnologie II [Aßm03] U. Aßmann. Invasive Software Composition. Springer, [TraCo] Florian Heidenreich, Jan Kopcsek, and Uwe Aßmann. Safe composition of transformations. Journal of Object Technology, 10:7: 1-20, [Cza05] K. Czarnecki and M. Antkiewicz. Mapping Features to Models: 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 Model 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. [Hei08a] F. Heidenreich, J. Kopcsek, and C. Wende. FeatureMapper: Mapping Features to Models. 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

4 Software Development in the V-Model 4 Softwaretechnologie II The most simple software development process is the V-model, but for software product lines (SPL) we need other processes Software Product Line Engineering (SPLE) is the discipline of creating product lines Pre-Study Product concept catalogue (Lastenheft) Requirements Analysis Software Requirement Specification (SRS) Acceptance test cases Acceptance Test Installation, Beta Test Achitectural Design Architecture (Grobentwurf) System test cases System Test (inhouse) Detailed Design (Feinentwurf) Implementation Unit test cases Component, Subsystem Test Contracts, Class Tests

5 Object-Oriented Analysis vs Object-Oriented Design Softwaretechnologie II requirements specification textual requirements (stories) context model analysis model use cases domain model analysis model architectural design detailed design

6 Extended to Model-Driven Architecture (MDA) 6 Softwaretechnologie II Horizontal product line: one product idea in several markets requirements specification textual requirements (stories) use cases context model analysis model (CIM) analysis model domain model Platform independent model Platform-1 specific model Platform-(1,.., n) specific model

7 Software Product Lines (Software Product Families) 7 Softwaretechnologie II requirements specification textual requirements (stories) context model Feature Model (varability model) analysis Model Product 1 use cases domain model Product 2 Product n

8 Adding Extensions to Abstract Models in the MDA 8 Softwaretechnologie II In the following, we extend the MDA (below) with configuration Platform independent model (PIM) Platform-1-specific extension (PSE) Model weaving Platform-1 specific model (PIM) Platform-2 specific extension (PSE) Model weaving Platform-(1+2) specific model (PSM)

9 Configuration of Variabilities in Vertical Product Lines (MDA for Vertical Product Lines) 9 Softwaretechnologie II Vertical product line: several products (different feature sets) in one or several markets The VIM (variant independent model) is the common model of the product family Domain Model Configuration With FeatureModel Variants Product Variants Design Variants Analysis Model Product Line Model (Framework, VIM) Model weaving Configuration With FeatureModel Variants PSM Variants Extensions Product PIM Model weaving Product Product PSM PSM Product PSM

10 Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie Prof. Aßmann - Softwaretechnologie II 31.1 PRODUCT LINES WITH FEATURE TREES AND FEATURE MODELS Feature-driven SPLE 10

11 Feature Models for Product Configuration 11 Softwaretechnologie II Feature models are used to express variability in Product Lines alternative, mandatory, optional features, and their relations XOR OR A variant model represents a concrete product (variant) from the product line The variant model results from a selection of a subgraph of the feature model The variant model can be used to parameterize and drive the product instantiation process

12 Feature Models 12 Softwaretechnologie II The Feature Tree Notation is derived from And-Or-Trees Group of AND Features Group of Alternative (XOR) Features Mandatory Feature Optional Feature Group of OR Features FeatureA FeatureB PhD Thesis, Czarnecki (1998) based on FODA-Notation by Kang et al. (1990) FeatureC FeatureD

13 Example 13 Softwaretechnologie II A1 or A2 or A3 B1; B2 xor B3 B4; optional B5 B1; B7 A1 A2 A3 B1 B2 B3 B4 B5 B6 B7

14 A Feature Model for Computer-Aided Cognitive Rehabilitation 14 Softwaretechnologie II [K. Lehmann-Siegemund, Diplomarbeit] 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 K J E S CE CU NO NM... [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

15 Feature Models form a Specific Concern space 15 Softwaretechnologie II Remember: Aspect-oriented modeling means to separate a concern space from a component space In SPLE, the feature space forms a concern space; the component space is usually called the solution space Concern Space (Aspektraum) Component Space (Solution Space) Concern 1 Perspective P Concern 2 Concern mapping (Sichtenabbildung) Perspective Q Aspekt 3

16 Ex: Plugins have Features (in Eclipse) Softwaretechnologie II Feature-driven SPLE 16

17 Softwaretechnologie II MODEL-BASED PRODUCT LINES Prof. U. Aßmann Feature-driven SPLE 17

18 Mapping Features to Model Fragments (Model Snippets) 18 Softwaretechnologie II Feature mapping bridges the gap between configuration space and solution space Possible artefacts in the solution space: Models defined in DSLs; Model fragments (snippets) Architectural artefacts (components, connectors, aspects) Source code, Files A Model-based Product Line is a SPL with models in the component space Feature space Feature 1 Component Space (Solution Space) Feature 3 Feature 2 Feature mapping

19 Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie Prof. Aßmann - Softwaretechnologie II 31.2 PRODUCT-LINE CONFIGURATION WITH FEATURE MODELS Feature-driven SPLE 19

20 Different Approaches of Variant Selection in an SPL Additive approach 20 Softwaretechnologie II Map all features to model fragments (model snippets) Compose them with a core model based on the presence of the feature in the variant model Pros: conflicting variants can be modelled correctly strong per-feature decomposition Cons: traceability problems increased overhead in linking the different fragments

21 Different Approaches of Variant Selection (2) Subtractive approach 21 Softwaretechnologie II Model all features in one model Remove model elements based on absence of the feature in the variant model Pros: no need for redundant links between artifacts short cognitive distance Cons: conflicting variants can't be modelled correctly huge and inconcise models

22 The Mapping Problem between Features and Solution Elements Slide 22Softwaretechnologie II Creation Visualisation Validation Problem Space Derivation Solution Space FeatureA A B FeatureB FeatureC F G E D FeatureD FeatureE

23 Mapping Features to Models 23 Softwaretechnologie II FeatureMapper - a tool for mapping of feature models to modelling artefacts developed at the ST Group Screencast and paper available at 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 Model and code snippets can be traced to requirements

24 FeatureMapper Slide 24Softwaretechnologie II

25 Mapping Features to Models Slide 25Softwaretechnologie II We chose an explicit Mapping Representation in our tool FeatureMapper Mappings are stored in a mapping model that is based on a mapping metamodel Feature Model Mapping Model Solution Models FeatureA FeatureC D A B FeatureC E FeatureB FeatureC FeatureD FeatureE FeatureE FeatureC FeatureE G F F G E D

26 From Feature Mappings to Model Transformations 26 Softwaretechnologie II

27 Visualisation of Mappings (1) Slide 27Softwaretechnologie II Visualisations of Feature Mappings by colors (as in AOP) View construction: In many cases, developers are interested only in a particular aspect of the connection between a feature model 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: MappingViews, a visualisation technique that provides four basic visualisations Realisation View Variant View Context View Property-Changes View

28 Realisation View Slide 28Softwaretechnologie II For one Variant Model, the realisation in the solution space is shown Feature Model Mapping System Relationship Relationship FeatureB Relationship

29 Variant View Slide 29Softwaretechnologie II The variant view shows different variant realisations (variant models) in parallel Feature Model Mapping System Relationship Relationship Relationship Address Address

30 Context View Slide 30Softwaretechnologie II The Context View draws the variants with different colors Aspect-separation: each variant forms an aspect Feature Model Mapping System Relationship Relationship... Address Relationship Group Group Group... Address Address...

31 Property-Changes View Slide 31Softwaretechnologie II Feature Model System Arbitrary Depth Mapping Recorded change-set of changing the cardinality of the reflexive association of Group to itself from 1 to many Other Feature Arbitrary Depth

32 Textual Languages Support (1) Slide 32Softwaretechnologie II Unified handling of modelling languages and textual languages by lifting textual languages to the modelling level with the help of EMFText All >80 languages from the EMFText Syntax Zoo are supported, including Java 5

33 Textual Languages Support (2) Slide 33Softwaretechnologie II Aspect-related color markup of the code

34 Mapping-based Derivation of Transformations Slide 34Softwaretechnologie II Transformations in the solution space Mapping Model build the product Feature Model Solution Models FeatureA FeatureC D A B FeatureC E FeatureB FeatureC FeatureE G D FeatureC F F G E FeatureD FeatureE FeatureE Variant Model <<in>> <<in>> Variant FeatureA A B FeatureB FeatureD FeatureC <<in>> Derivation Of Transformations <<out>> E D

35 Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie Prof. Aßmann - Softwaretechnologie II 31.3 MULTI-STAGE CONFIGURATION Feature-driven SPLE 35

36 FEASIPLE: A Multi-Stage Process Architecture for PLE 36 Softwaretechnologie II Chose one variant on each level Feature Tree as input for the configuration of the model weavings

37 FEASIPLE: A Multi-Stage Process Architecture for PLE 37 Softwaretechnologie II Goal: a staged MDSD-framework for PLE where each stage produces the software artefacts used for the next stage

38 Advantages of FEASIPLE 38 Softwaretechnologie II Characteristic feature 1: Variability on each stage

39 Advantages of FEASIPLE 39 Softwaretechnologie II Characteristic feature 2: Different modelling languages, component systems and composition languages per stage

40 Advantages of FEASIPLE 40 Softwaretechnologie II Characteristic feature 3: Different composition mechanisms per stage

41 Advantages of FEASIPLE 41 Softwaretechnologie II Characteristic feature 4: Composition mechanisms are driven by variant selection

42 Softwaretechnologie II 31.4 MULTI-STAGE CONFIGURATION OF TRANSFORMATIONS Feature-driven SPLE 42

43 Multi-Staged Derivation of Transformations Folie 43Softwaretechnologie II How do we compose transformations? Between different stages? functional Feature Model VIM Mapping Variant Independent Model M2M Trafos context Feature Model PIM Mapping Platform Independent Models Platform Independent Models Platform Independent Models M2M Trafos platform Feature Model PSM Mapping Platform Specific Models Platform Specific Models Platform Specific Models M2C Generators Platform Specific Code

44 TraCo: A Framework for Safe Multi-Stage Composition of Transformations Folie 44Softwaretechnologie II TraCo encapsulates transformations into composable components [TraCo] Arranges them with composition programs of parallel and sequential transformation steps (multi-threaded transformation SA1 Functional variant V1 M1 T1 SA2 SA1* Platform variant V2 M2 T2 T1* M1* V1* SA3 SA2* V1 Feature Selection M1 Mapping SA1 Solution Artefact T1 Transformation Context variant Vn Mn SAn- 1 Tn SAn

45 Steps in Multi-Staged Derivation of Transformations Slide 45Softwaretechnologie II 1. In TraCo, 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 Component instances Component Adapter references Actual Transformation Code Connectors Constant value

46 Multi-Staged Derivation of Transformations Slide 46Softwaretechnologie II Implemented in our tool TraCo Component Model, Composition Language, Composition Technique

47 Composition Programs can be Configured (Metacomposition) Folie 47Softwaretechnologie II Anything you can do, I do meta (Charles Simonyi) The composition program shown in the last slide can be subject to transformation and composition If we build a product line with TraCo, platform variability can be realised by different transformation steps A TraCo composition program can be used with FeatureMapper Multi-Staged transformation steps Even of composition programs More about metacomposition in CBSE course

48 Loading Functional Variability Add EJB Semantics Platform Variability Domain Load Domain Model Folie 48Softwaretechnologie II VIM to VSM Domain Model to UML Attributes to Properties UML to Java Actions Model to SimpleImpl UML UML to Java Load Actions Model VIM to VSM Actions Model to SimpleDelegateUML UML to Java Actions Actions to EJB UML Add EJB Persistence Semantics UML to Java Add Local Memory Semantics Actions to EJB Delegate UML UML to Java Application State Load ApplicationState Model VIM to VSM ApplicationState Model to UML Attributes to Properties UML to Java Presentation SWT User Interface Load User Interface Model VIM to VSM Ensure Control IDs SWT User Interface JSP Business Logic Java JSP User Interface EJB January 2011 Navigation Load Navigation Model VIM to VSM Navigation Model to Java Navigation Model to JSP Persistence In-Memory EJB Persistence Mixed EJB + In-Memory EJB + EJB Persistence

49 The final frontier: Ensuring Well-formedness of SPLs Slide 49Softwaretechnologie II Motivation: Make sure that well-formedness of all participating models is ensured Feature Model Mapping Model Solution Models Well-formedness rules are described using OCL Constraints are enforced during mapping time

50 Case Studies with FeatureMapper, TraCo, and FEASIPLE Slide 50Softwaretechnologie II Simple Contact Management Application Software Product Line FeatureMapper used to map features to UML2 model elements Both static and dynamic modelling 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 SalesScenario Software Product Line FeatureMapper used to tailor models expressed in Ecore-based DSLs was developed in project feasiple ( TAOSD AOM Crisis Management System

51 Summary Slide 51Softwaretechnologie II Configuration of product lines with mapping of feature models to solution spaces Mapping of Features to models in Ecore-based languages using FeatureMapper Visualisations of those mappings using MappingViews Realisation View Variant View Context View Property-Changes View Derivation of solution models based on variant selection and mapping Multi-Staged derivation using TraCo Ensuring well-formedness of SPLs

52 The End 52 Softwaretechnologie II Many slides are courtesy Florian Heidenreich