TOWARDS A MORE FLEXIBLE MODEL-DRIVEN ENGINEERING

Size: px

Start display at page:

Download "TOWARDS A MORE FLEXIBLE MODEL-DRIVEN ENGINEERING"

Audra Flynn
5 years ago
Views:

1 TOWARDS A MORE FLEXIBLE MODEL-DRIVEN ENGINEERING Juan de Lara Computer Science Department Universidad Autónoma de Madrid (Spain) NWPT 12 Bergen, Norway

MDE can be seen as a reutilization approach: DSMLs are reused across projects within the same domain.

2 MOTIVATION Model-Driven Engineering (MDE) is about building systems by an active use of models: Modelling as oposed to programming. Domain-Specific Modelling Languages (DSMLs). Code generators. MDE can be seen as a reutilization approach: DSMLs are reused across projects within the same domain. Similar approach to Software Product Lines. But MDE artefacts are defined for specific DSMLs, and are not applicable to similar DSMLs. 2

3 AGENDA Model-Driven Engineering (MDE). Meta-Modelling and DSMLs. Model Transformations. Limitations. Reutilization Appropaches for MDE. Concept-based Genericity. Multi-level-based Genericity. Example: Reusable abstractions for Modelling Languages. Conclusions and Outlook. 3

4 MODEL DRIVEN ENGINEERING Increase the level of abstraction in software development. Models are actively used to: Describe the problem Simulate/verify/test Generate code for the final application. Move from the solution space (code-centric) to the problem space: Higher levels of productivity and quality. Less accidental details. 4

5 MODEL DRIVEN ENGINEERING For specific domains: Avoid coding the same solutions over and over. Families of applications. Domain-Specific Modelling Languages. Code Generator Modelling, validation and automatic generation of telephony services. 5

6 MODEL DRIVEN ENGINEERING For specific domains: Avoid coding the same solutions over and over. Families of applications. Domain-Specific Modelling Languages. Code generator Code generation from State-Machines for Railway Signaling Systems. 6

7 DOMAIN SPECIFIC MODELLING LANGUAGES Describe the structure of the domain Relevant primitives and abstractions. Relations, features. Explicit expert knowledge. 7 MetaEdit+

8 DOMAIN SPECIFIC MODELLING LANGUAGES DSMLs need not be graphical 8 xtext

9 MODELS AND META-MODELS The abstract syntax of DSMLs is defined through a meta-model Classes, Attributes, Relations. Conveyor parts Part inps 1.. outs 1.. Generator Factory meta-model Machine Assembler Terminator 9

10 MODELS AND META-MODELS The abstract syntax of DSMLs is defined through a meta-model Classes, Attributes, Relations. «conforms to» Conveyor parts Part inps outs Generator Factory meta-model Machine Assembler Terminator outs g:generator outs c1:conveyor c2:conveyor inps inps p2: Part a:assembler outs p2: Part c3:conveyor inps t:terminator 10

11 OCL CONSTRAINTS Object Constraint Language Well-formedness rules, which every model should satisfy. Conveyor inps outs Factory meta-model Machine parts Based on First-Order Logic. Part Generator Assembler Terminator context Generator inv: inv: self.inps->isempty() «conforms to» and and self.outs->size()>0 context Terminator inv: self.outs->isempty() and self.inps->size()>0 c:conveyor context Assembler inv: self.inps->size()>0 and self.outs.size()>0 g:generator 11

12 MODELS AND META-MODELS Models are represented using concrete syntax Visual Textual No need for a 1-1 correspondence between abstract and concrete syntax elements. asse 12

13 MODEL TRANSFORMATIONS Models need to be manipulated for: Simulation. Optimization/refactoring. Generating another model. Generating code. in-place transformations 13

14 MODEL TRANSFORMATIONS Models need to be manipulated for: Simulation. Optimization/refactoring. Generating another model. Generating code. model-to-model transformations Source Target 14

15 MODEL TRANSFORMATIONS Models need to be manipulated for: Simulation. Optimization/refactoring. Generating another model. Generating code. model-to-model transformations Transformation developer MM src from Transformation definition to MM tar «conforms to» «conforms to» Final user M src Transformation execution M tar 15

16 MODEL TRANSFORMATIONS Models need to be manipulated for: Simulation. Optimization/refactoring. Generating another model. Generating code. query and model navigation Template languages 16

17 SPECIFYING MODEL TRANSFORMATIONS Model transformations are not normally specified using general purpose languages Specialized languages for transformation Declarative/imperative Visual/textual LHS work RHS Formal/semi-formal G H 17

18 SPECIFYING MODEL TRANSFORMATIONS Model transformations are not normally specified using general purpose languages Specialized languages for transformation Declarative/imperative Visual/textual Formal/semi-formal L G l m P.O. k P.O. m f K D r d R H 18

19 SPECIFYING MODEL TRANSFORMATIONS Model transformations are not normally specified using general purpose languages Specialized languages for transformation Declarative/imperative operation main() { // Epsilon Object Language Visual/textual } Formal/semi-formal operation Machine work() { for (c in self.inps) { var p : Part := c.parts.random(); c.parts.remove(p); delete p; } for (c in self.outs) c.parts.add(new Part); } 19

20 SPECIFYING MODEL TRANSFORMATIONS Model transformations are not normally specified using general purpose languages Specialized languages for transformation Declarative/imperative Visual/textual Formal/semi-formal rule Conveyor2Place transform c : Conveyor to p : Place { p.tokens := c.parts.size(); } 20

21 SPECIFYING MODEL TRANSFORMATIONS Transformations use the types of the meta-model How to reuse such transformations for similar meta-models? operation Machine work() { for (c in self.inps) { var p : Part := c.parts.random(); c.parts.remove(p); delete p; } for (c in self.outs) c.parts.add(new Part); } :Part parts c: Conveyor inps a:assembler outs c: Conveyor LHS c: Conveyor inps a:assembler outs c: Conveyor :Part parts rule Conveyor2Place transform c : Conveyor to p : Place { p.tokens := c.parts.size(); } RHS 21

22 SPECIFYING MODEL TRANSFORMATIONS Transformations use the types of the meta-model :Message LHS b:buffer RHS How to reuse such transformations for similar meta-models? operation Processor work() { for (c in Buffer.all.select(b b.outp.includes(self)) { var p: Message := c.msgs.random(); c.msgs.remove(p); delete p; } for (c in self.outb) c.msgs.add(new Message); } b:buffer p:processor b1:buffer p:processor b1:buffer :Message rule Buffer2Place transform b : Buffer to p: Place { p.tokens:=b.msgs.size(); } 22

23 MAKING TRANSFORMATIONS GENERIC Take ideas from generic programming. part:t LHS RHS input:h Transformation templates: Variable types in transformations. Template instantiation: Bind variable types to specific types. input:h process:p output:h process:p output:h newpart:t 23

24 MAKING TRANSFORMATIONS GENERIC Take ideas from generic programming. part:t LHS RHS input:h Transformation templates: Variable types in transformations. input:h process:p output:h process:p output:h newpart:t Template instantiation: Bind variable types to specific types. Can we express what do we require from meta-models? 24

25 STRUCTURAL CONCEPTS Structural Concepts. They gather the structure needed from meta-models for the transformation to be applicable. They have the form of a meta-model as well. Token-Holder Concept Holder tokens Token in out Process Their elements are treated as variables, which need to be bound to elements in specific meta-models. 25

26 REUSABLE TRANSFORMATIONS Transformations are defined using the types of the concept. Token-Holder Concept Holder tokens Token in out Process LHS RHS :Holder :Process :Holder :Holder :Process :Holder :Token :Token NOT :Holder :Process NOT :Token Application Condition 26

27 BINDING Concept binding: Bind each element in the concept to an element in the meta-model. Token-Holder Concept Holder tokens Token in out Process Binding Holder Conveyor Process Machine Token Part in inps out outps tokens parts Conveyor parts Part inps outs Factory DSL Machine Generator Assembler Terminator 27

28 REUSABLE TRANSFORMATIONS Transformations are retyped to conform to the bound metamodel LHS RHS :Conveyor :Machine :Conveyor :Conveyor :Machine :Conveyor :Part :Part NOT :Conveyor :Machine NOT :Part Application Condition 28

29 REUSABLE TRANSFORMATIONS Concepts con be bound to meta-models sharing essential structural features. Transformations defined over concepts become reusable Meta-Model 1 «conforms to» «binds» executes on Concept A «requires» Transf. executes on «binds» Meta-Model 2 «conforms to» Model 1 Model 1 Model 1 Model 1 29

30 MORE FLEXIBLE BINDINGS Concepts also express a particular design choice on how structure is organized. Holder tokens in out Token binding Process Different meta-models may implement the same essential structure differently. Conveyor parts:int inps outs Machine Generator Assembler 30

31 HYBRID CONCEPTS Hide unessential structure behind required operations. Operations need to be implemented together with the binding. Holder tokens():int addtokens(int n) Process inputs():holder[] outputs():holder[] The generic transformation may use these required operations. 31

32 HYBRID CONCEPTS Hide unessential structure behind required operations. Holder tokens():int addtokens(int n) Process inputs():holder[] outputs():holder[] Operations need to be operation main() { implemented together var enabled with : Set(Process):=enabledSet(); the binding.. while (enabled.size()>0 and numstep<maxstep) {. The generic transformation } may use these } required operations. operation enabledset() : Set(Process) { var en : Set(Process); for (t in Process.all()) if (t.inputs().forall(h h.tokens()>0)) en.add(t); return en; } 32

33 BINDING HYBRID CONCEPTS operation Conveyor tokens() { return self.parts; } operation Machine inputs() { return Conveyor.all().select(c c.outs.includes(self)) } + Holder tokens():int addtokens(int n) Holder Conveyor Process Machine Process inputs():holder[] outputs():holder[] Conveyor parts:int inps outs Machine Generator Assembler 33

34 BINDING ADAPTERS Expressions resolving the heterogeneities between the concept and the meta-model. These induce an adaptation of the transformation. UML reference Domain from: concept UMLClass id : String Class name : String Generalization superclasses Binding: Class UMLClass Class.name UMLClass.id superclasses generals->collect (g g.reference) generals adapter rule class2jclass { from class : OO!Class to jclass : Java!JavaClass ( name <- class.name extends <- class.superclasses.first() ) } generated adapted rule rule class2jclass { from class : UML!UMLClass to jclass : Java!JavaClass ( name <- class.id extends <- class.generals->collect (g g.reference).first() ) } 34

35 MULTI-LEVEL BASED GENERICITY Modelling using multiple metalevels. Many domains can be naturally described using more than two meta-levels at the same time. Clabjects (Kühne&Atkinson) Task src tar Coding:Task src src tar data: Coding : C2T Gateway Seq C2T: Seq T2C: Seq tar Par tar Test: Task unitdt: Test gui: Coding src src tar «conf» «conf» : T2C 35

36 MULTI-LEVEL BASED GENERICITY Domain-specific Meta- Modelling Describe families of related meta-models. Process Modelling Software Process Modelling Language Educational Modelling Language Software Process Models Educational Models 36

37 MULTI-LEVEL BASED GENERICITY Transformations can be defined at the top meta-level defined on Process Modelling Applicable to instances of all languages in the family applicable to Transformation Software Process Modelling Language Educational Modelling Language Software Process Models Educational Models 37

38 MULTI-LEVEL BASED GENERICITY Task src src tar Coding:Task tar Gateway Seq C2T: Seq T2C: Seq Par tar Test: Task src «conf» defined on applicable to rule Task2Place transform t : Level0!Task to p : Place {... }... src data: Coding : C2T tar unitdt: Test gui: Coding «conf» src tar : T2C data: Coding gui: Coding unitdt: Test 38

39 MULTI-LEVEL BASED GENERICITY Task src tar Gateway Seq Par rule Task2Place transform t : Level0!Task to p : Place {... }... Coding:Task src src tar data: Coding : C2T C2T: Seq T2C: Seq tar Test: Task unitdt: Test gui: Coding tar src «conf» «conf» src tar : T2C defined on applicable to rule Coding2Place transform t : Coding to p : Place { } rule Test2Place transform t : Test to p : Place { } data: Coding gui: Coding unitdt: Test 39

40 MULTI-LEVEL VS CONCEPT-BASED GENERICITY A posteriori binding: metamodels may exist first. Adapters and hybrid concepts to solve heterogeneities. Concept-based Genericity Multi-level-based Genericity A priori: meta-meta-model should exist first. Ability to apply an operation several meta-levels below. Domain-Specific metamodelling. 40

41 EXAMPLE: REUSABLE ABSTRACTIONS A model abstraction is an operation that reduces the complexity of some aspect of a model. increases comprehensibility reduces size (e.g. to ease verification while retaining properties of interest). An abstraction may: delete existing model elements, add new ones e.g. aggregate objects or hierarchical constructs encapsulating existing elements with commonalities. Make abstractions reusable! 41

42 TYPES OF ABSTRACTIONS Horizontal. applicable to modelling languages of (perhaps very) different domains Merge. Aggregation. Vertical. specific to a family of DSMLs sharing semantics Deletion. Views. Applicability Behaviour 42

43 TYPES OF ABSTRACTIONS Horizontal. Applicable to modelling languages of (perhaps very) different domains Vertical. specific to a family of DSMLs sharing semantics Merge. a set of elements considered similar is replaced by one element collecting the properties of the merged elements Aggregation. Deletion. Views. Applicability Behaviour 43

44 TYPES OF ABSTRACTIONS Horizontal. S0 Applicable S4 to modelling S1 languages e of (perhaps very) S2 different domains S1 S2 S3 e e Vertical. f S0 S3 specific to a family of DSMLs sharing semantics e f S4 Merge. Aggregation. a set of similar elements is grouped hierarchically under a higher-level aggregate element. Deletion. Views. Applicability Behaviour 44

45 TYPES OF ABSTRACTIONS Horizontal. Applicable to modelling languages of (perhaps very) different domains Vertical. specific to a family of DSMLs sharing semantics Merge. Aggregation. Deletion. deletes elements that are not considered relevant or that do not modify some observed property of a model Views. Applicability Behaviour 45

46 TYPES OF ABSTRACTIONS Horizontal. Applicable to modelling languages of (perhaps very) different domains Perf meeting Report Vertical. start Perf meeting specific to a family of Eval DSMLs sharing semantics Eval report report end Merge. Aggregation. Deletion. Views. produces a new model (the view), perhaps expressed in a different DSML, discarding features of the original model which are irrelevant for the aim of the abstraction Applicability Behaviour 46

47 A CATALOGUE OF ABSTRACTIONS Generic abstractions that designers can select and customize for particular DSMLs. Operations defined over suitable concepts to be bound to the meta-models of specific DSMLs. From a structural concept: when the structure of the concept and meta-model are similar From a hybrid concept: gives freedom regarding Some vertical abstractions defined using multilevel meta-modelling (process modelling). 47

48 HORIZONTAL ABSTRACTIONS Target Parallel. Aggregates items with same target, through a given relation. 48

49 HORIZONTAL ABSTRACTIONS Target Parallel. Aggregates items with same target, through a given relation. 49

50 HORIZONTAL ABSTRACTIONS Sequential. Aggregates a linear sequence of items. Sequential struct. concept next Item canaggregate(item): boolean child Aggregate aggregate(set(item)) next :Item :Item :Item next next next next next next :Aggregate next next next child child child next next :Item :Item :Item 50

51 HORIZONTAL ABSTRACTIONS Sequential. Aggregates a linear sequence of items. Sequential struct. concept next Item canaggregate(item): boolean child Aggregate aggregate(set(item)) next :Item :Item :Item next next next next next next :Aggregate next next next child child child next next :Item :Item :Item child FlowElem Container FlowElement FlowNode Activity SubProcess Item targetref sourceref Gateway Aggregate next Sequence Flow + A 0 A 1 A 2 A 0 A 1 A 2 A 3 + A 4 A 4 A A 4 A 4 51

52 DOMAIN-SPECIFIC ABSTRACTIONS Fusion Series Places. Merges two places in series. Holder tokens Token in out Process 52

53 DOMAIN-SPECIFIC ABSTRACTIONS Fusion Series Places. Merges two places in series. Holder tokens Token in out Process Holder Process asse asse Token asse 53

54 AGENDA Model-Driven Engineering (MDE). Meta-Modelling and DSMLs. Model Transformations and Code generation. Limitations. Reutilization Appropaches for MDE. Concept-based Genericity. Multi-level-based Genericity. Example: Reusable abstractions for Modelling Languages. Conclusions and Outlook. 54

55 SUMMARY MDE promotes an active use of models and automated generation of applications for specific domains. Higher levels of productivity and quality, for specific domains. Model transformations, code generators becomes tied to specific meta-models, difficult to reuse. We have seen two techniques for their reutilization: conceptbased and multi-level based genericity. 55

56 OUTLOOK Type safety, behaviour preservation of transformation template instantiations. More flexible reuse. A posteriori typing in multi level modelling Many interesting research topics in MDE: Mixing modelling and programming: Models at run-time, transformations at run-time. Scalability: how to deal with very large models, distribution. Consistency of artefacts: models, model/meta-model co-evolution, transformation/meta-model co-evolution etc. Correctness of transformations, model analysis, etc. Simpler MDE: use by non-experts. 56

57 THANKS! Questions? With acknowledgements to my collaborators on these topics: E. Guerra, J. S. Cuadrado (Madrid) 57

58 SOME REFERENCES From Types to Type Requirements: Genericity for Model-Driven Engineering J. de Lara, E. Guerra. Software and Systems Modeling (Springer). In press. Flexible Model-to-Model Transformation Templates: An Application to ATL J. Sánchez Cuadrado, E. Guerra, J. de Lara. Best papers of ICMT'11. Journal of Object Technology Volume 11, no. 2. Domain-specific textual meta-modelling languages for modeldriven engineering J. de Lara and E. Guerra. LNCS 7349, pp.: , Springer. Presented at ECMFA'12: 8th European Conference on Modelling Foundations and Applications Abstracting modelling languages: A reutilization approach J. de Lara, E. Guerra and J. Sánchez Cuadrado. LNCS 7328, pp: Presented at CAiSE'12: 24th International Conference on Advanced Information Systems Engineering.

APPROACHES TO MODEL TRANSFORMATION REUSE

APPROACHES TO MODEL TRANSFORMATION REUSE Juan de Lara joint work with Esther Guerra and Jesús Sánchez Cuadrado Modelling&Software Engineering Research Group http://miso.es @miso_uam ICMT 2016, Viena FROM