Model Transformations for DSL Processing Stefan Kapferer January 7, 2019 University of Applied Sciences of Eastern Switzerland (HSR FHO)
Table of contents 1. Introduction 2. Example & Live Demo 3. Model Transformations with Henshin 4. Algebraic Graph Transformation 5. Summary & Conclusions 1
Introduction
Models are everywhere Models are used in all disciplines and phases of the software development lifecycle. MD* approaches: • Model-driven Development (MDD) • Model-driven Engineering (MDE) • Model-driven Architecture (MDA) [6] • Model-driven Security (MDS) [4] • and so on ... 2
Models in SE disciplines Software Engineering Examples of Models Discipline Business Modeling & Re- Domain Models, Use Case Models, quirements Engineering Business Process Models Analysis & Design Domain Models, Architecture View Models, DDD Context Maps, System Sequence Diagrams, State Machine Diagrams, Activity Diagrams Implementation Class, Object, Data Models Testing Performance Simulation Model, Test Case Specification Model Operations & Mainte- Deployment Models, Maintenance nance Models 3
Model Transformation Models need to be transformed into other models: • Different representations for different audiences • Change level of abstraction • Refinement of domain model towards fully-fledged class diagram • Keep level of abstraction but change language • Refactorings • Code migration into other language 4
Model Transformation Taxonomy [5] Different types of model transformations: • Endogenous vs. Exogenous • Endogenous: Source and target model are represented by the same language • Exogenous: Transformation between models in different languages/representations • In-place vs. Out-place • Concerns endogenous transformations only. Exogenous transformations are always out-place. • In-place: Transformation within the same meta-model • Out-place: Source meta-model differs from output meta-model • Horizontal vs. Vertical • Horizontal: Source and target model are on same level of abstraction • Vertical: Transformation changes the level of abstraction 5
Example & Live Demo
ContextMapper DSL [2] A Domain-specific Language for Context Mapping & Service Decomposition 1 • Modeling Domain-driven Design (DDD) Context Maps • Goal: Apply model transformations to realize architectural refactorings [8] towards service decomposition • Split bounded contexts DSL Processing via Model Transformation : parsing • DSL Text → Abstract Syntax Tree (AST) − → Model − − − − transformation • Model → Model − − − − − − − − unparsing • Model − → Abstract Syntax Tree (AST) → DSL Text − − − − − − 1 https://contextmapper.github.io/ 6
9 14 8 12 7 6 13 5 4 10 15 3 16 2 17 1 11 ContextMapper DSL Example Context Map Example Context Map: /* The DDD Cargo sample application modeled in CML. */ ContextMap { contains CargoBookingContext contains VoyagePlanningContext contains LocationContext /* 'Shared-Kernel' between CargoBooking and VoyagePlanning. */ CargoBookingContext <-> VoyagePlanningContext : Shared-Kernel /* CargoBooking and VoyagePlanning use Location OHS */ CargoBookingContext -> LocationContext : Upstream-Downstream { upstream implements OPEN_HOST_SERVICE, PUBLISHED_LANGUAGE } VoyagePlanningContext -> LocationContext : Upstream-Downstream { upstream implements OPEN_HOST_SERVICE, PUBLISHED_LANGUAGE } } 7
11 17 13 9 14 8 15 7 16 6 5 12 18 4 19 3 20 2 21 1 10 ContextMapper DSL Example: Input DSL snippet modeling a bounded context: /* Example Bounded Context in CML */ BoundedContext CustomerManagement { Aggregate Customers { Entity Customer { String firstName String familyName Account customerBankAccount } Entity Account { String iban String bankName } } Aggregate CustomerSelfService { Entity Account { String username String password Customer owner } } } 8
Live Demo: «Split Bounded Context by Duplicate Entity Name» 8
19 18 17 20 16 21 15 22 14 23 13 1 12 11 10 9 4 2 7 3 6 8 5 ContextMapper DSL Example: Output /* Example Bounded Context in CML */ BoundedContext CustomerManagement { Aggregate Customers { Entity Customer{ String firstName String familyName Account customerBankAccount } Entity Account { String iban String bankName } } } BoundedContext SplitBoundedContext { Aggregate CustomerSelfService { Entity Account { String username String password Customer owner } } } 9
Model Transformations with Henshin
Henshin Transformation Tool Henshin [1] is an EMF [7] based transformation tool. • Henshin means transformation in Japanese • Supports in-place model transformations • Endogenous & Exogenous • Horizontal & Vertical • Based on Algebraic Graph Transformation [3] 10
The Henshin Transformation Meta-Model 2 2 Copied from https://wiki.eclipse.org/Henshin/Transformation_Meta-Model 11
Example Transformation Model Transformation model for example seen in the live demo: • LHS graph: «preserve» + «delete» • RHS graph: «preserve» + «create» 12
Algebraic Graph Transformation
From String Grammars ... The classical string grammar you know: DecimalNumeral − > 0 | NonZeroDigit D i g i t s D i g i t s − > ε | D i g i t | D i g i t s D i g i t D i g i t − > 0 | NonZeroDigit NonZeroDigit − > 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 • Example: DecimalNumeral grammar of the Java Language Specification in Backus-Naur Form (BNF). • String grammar consists of a set of production rules . 13
... to Graph Grammars Similar principle with graphs: • Left-hand side (LHS) of the rule has to be matched in graph on which the rule is applied to. • Right-hand side (RHS) describes the changes which will be applied Example: Banking scenario «create new account for a customer». 14
Typed Graphs A simple graph is not sufficient. • Vertices and edges have to be typed. • Implicitly suggested in this example: Lets make this concept explicit ... 15
Typed Graph Fundamentals A typed graph is based on the concept of a graph morphism : A graph G ( V , E , s , t ) consists of a set V of vertices, a set E of edges, source and target functions s , t : E → V . A type graph is a graph TG = ( V TG , E TG , s TG , t TG ) . A graph morphism is an application f : G 1 → G 2 , f = ( f V , f E ) of a graph G 1 to another graph G 2 which consists of two functions f V : V 1 → V 2 and f E : E 1 → E 2 . 16
Typed Graph A typed graph G T = ( G , f type ) over a type graph TG is a graph G and a graph morphism f type : G → TG . 17
Graph Productions Graph rewriting rules , such as shown below, are also called graph productions : l r A graph production p = ( LHS − K → RHS ) consists of (typed) graphs ← − LHS, K and RHS, and injective (typed) graph morphisms l and r . K is called the gluing graph and is derived by the mapping between the LHS and the RHS graph. 18
Pushout The so-called pushout is an operator transforming a graph G into another graph G ′ given a production p . This is the key concept for applying transformations according to the algebraic graph transformation concept: A pushout PO over two graph morphisms f : G 1 → G 2 and g : G 1 → G 3 is defined by a pushout graph G 4 and morphisms f ′ : G 3 → G 4 and g ′ : G 2 → G 4 with f ′ ◦ g = g ′ ◦ f . 19
Pushout Example The pushout concept applied to our banking example: 20
Single Pushout Summarized The Single Pushout (SPO) method applied to a graph G can be summarized as follows: 1. Find a match of LHS in G , or formally, find a morphism m : LHS → G . 2. Deleting the sub-graph m ( LHS ) − m ( LHS ∩ RHS ) from G , which trivially removes all elements from the graph that are within the LHS graph but not in the intersection graph of the LHS and RHS graph and thus are meant to be deleted by the rewriting rule. 3. Adding the sub-graph m ( RHS ) − m ( LHS ∩ RHS ) to G to get the result G ′ . This step adds all elements which are part of the RHS graph but not part of the intersection of the LHS and RHS graph and thus are meant to be created in G ′ by the rewriting rule. 21
Graph Grammar Definition From graph productions to graph transformation systems and finally, graph grammars: p,m ⇒ G ′ is given by POs , a A direct (typed) graph transformation G = = production p and match m : LHS → G . ∗ A (typed) graph transformation G 0 ⇒ G n is a sequence G 0 ⇒ G 1 ... = ⇒ G n of direct (typed) graph transformations. A (typed) graph transformation system GTS = ( TG , P ) consists of a type graph TG and a set of (typed) graph productions P . A (typed) graph grammar GG = ( GTS , S ) consists of a graph transformation system GTS and a (typed) start graph S . 22
Why do we need these formalisms? The presented algebraic graph transformation approach behind Henshin allows formal reasoning about a transformation system: • Reasoning about applicability • Analyze if productions are parallel independent • Important for performance if you have huge transformation systems • Find so-called critical pairs • Pairs of direct transformations which are parallel dependent 23
Summary & Conclusions
Recommend
More recommend
