Introduction to Model Versioning SFM-12: MDE June 22, 2012 Petra - PowerPoint PPT Presentation

Text-based and State-based Merging Version 1 1: class Person { 2: string[1..1] name 3: Vehicle[0..*] owns 4: } 5: class Vehicle { 6: integer[ 1 ..1] carNo Version 0 7: } 1: class Human { 2: string[1..1] name 3: } 4: class Vehicle { 5: integer[0..1] carNo Version 2 6: } 1: class Human { 2: string[1..1] name 3: } 4: class Car { 5: integer[0..1] regId 6: } Version 3 1: class Person { 2: string[1..1] name 3: Vehicle[0..*] owns 4: } 5: class Car { a: integer[ 1 ..1] carNo 6: <<UP/UP>> b : integer[0..1] regId c: integer[ 1 ..1] regId 7: } 30

Text-based and Operation-based Merging Version 1 1: class Person { 2: string[1..1] name 3: Vehicle[0..*] owns 4: } 5: class Vehicle { 6: integer[ 1 ..1] carNo Version 0 7: } 1: class Human { 2: string[1..1] name 3: } 4: class Vehicle { 5: integer[0..1] carNo Version 2 6: } 1: class Human { 2: string[1..1] name 3: } 4: class Car { 5: integer[0..1] regId 6: } Version 3 1: class Person { Rename-Op: 2: string[1..1] name change Class.name; 3: Car [0..*] owns update Property.type 4: } pre@Class.name with 5: class Car { a: integer[ 1 ..1] carNo 6: <<UP/UP>> b : integer[0..1] regId post@Class.name; c: integer[ 1 ..1] regId 7: } 31

Graph-based Merging Example Version 1 Person : Class name : Attribute type = string lower = 1 owns : Reference upper = 1 name : Attribute lower = 0 Graph-based Representation type = string upper = * carNo : Attribute Human : Class lower = 1 type = integer upper = 1 lower = 1 Vehicle : Class upper = 1 carNo : Attribute type = integer Vehicle : Class lower = 0 upper = 1 Version 2 name : Attribute type = string Human : Class lower = 1 Legend upper = 1 Containment Edge <NodeName> : <Type> regId : Attribute <attributeName> = <value> Edge type = integer Car : Class lower = 0 upper = 1 32

Graph-based and State-based Merging Heuristic-based Matching Version 1 Person : Class name : Attribute type = string lower = 1 Version 0 owns : Reference name : Attribute upper = 1 lower = 0 type = string Human : Class upper = * lower = 1 carNo : Attribute upper = 1 type = integer lower = 1 Vehicle : Class upper = 1 carNo : Attribute type = integer Version 2 Vehicle : Class lower = 0 name : Attribute upper = 1 type = string Human : Class lower = 1 upper = 1 regId : Attribute type = integer Car : Class lower = 0 upper = 1 Version 3 Person : Class <<DEL/UP>> name : Attribute carNo : Attribute type = string type = integer lower = 1 lower = 1 owns : Reference upper = 1 upper = 1 lower = 0 upper = * regId : Attribute type = integer Car : Class 33 lower = 0 upper = 1

Graph-based and State-based Merging Match Model based on Heuristic (Name + Structure Equivalence) Version 1 Person : Class name : Attribute type = string lower = 1 owns : Reference upper = 1 lower = 0 upper = * carNo : Attribute Version 0 type = integer name : Attribute lower = 1 Vehicle : Class upper = 1 type = string Human : Class lower = 1 upper = 1 carNo : Attribute type = integer Vehicle : Class lower = 0 upper = 1 Version 2 name : Attribute type = string Human : Class lower = 1 upper = 1 regId : Attribute type = integer Car : Class lower = 0 upper = 1 34

Graph-based and State-based Merging Match Model + Diff Model Version 1 Person : Class name : Attribute type = string lower = 1 owns : Reference upper = 1 lower = 0 upper = * carNo : Attribute Version 0 type = integer name : Attribute lower = 1 Vehicle : Class upper = 1 type = string Human : Class lower = 1 upper = 1 carNo : Attribute type = integer Vehicle : Class lower = 0 upper = 1 Version 2 name : Attribute type = string Human : Class lower = 1 upper = 1 regId : Attribute type = integer Car : Class lower = 0 upper = 1 remove(Vehicle:Class, carNo:Attribute) 35

Graph-based and State-based Merging ID-based Matching Version 1 1 Person : Class 2 name : Attribute type = string lower = 1 Version 0 2 owns : Reference name : Attribute upper = 1 1 lower = 0 type = string 5 Human : Class upper = * 4 lower = 1 carNo : Attribute upper = 1 type = integer 3 lower = 1 Vehicle : Class 4 upper = 1 carNo : Attribute 3 type = integer Version 2 Vehicle : Class 2 lower = 0 name : Attribute upper = 1 1 type = string Human : Class lower = 1 upper = 1 4 regId : Attribute 3 type = integer Car : Class lower = 0 upper = 1 Version 3 1 Person : Class 2 name : Attribute type = string lower = 1 owns : Reference upper = 1 lower = 0 5 4 upper = * regId : Attribute type = integer 36 lower = 1 3 Car : Class upper = 1

State-based Merge Algorithm (agnostic of representation & match and diff realization) for each n0 ∊ V0 Design Decisions n1 := match( n0 in V1 ) n2 := match( n0 in V2 )  Matching (hasMatch) if hasMatch( n0 in V1 ) && hasMatch( n0 in V2 )  By Equivalence if diff( n0 , n1 ) && not diff( n0 , n2) -> use n1 if not diff( n0 , n1 ) && diff( n0 , n2) -> use n2  By ID if diff( n0 , n1 ) && diff( n0 , n2)  By Heuristics -> raise update/update conflict if not diff( n0 , n1 ) && not diff( n0 , n2) -> use n0  Comparison (diff) end if  Element granularity if hasMatch( n0 in V1 ) && not hasMatch( n0 in V2 ) if diff( n0 , n1 ) -> raise delete/update conflict  Feature granularity if not diff( n0 , n1 ) -> remove n0  Consolidation (remove/add) end if if not hasMatch( n0 in V1 ) && hasMatch( n0 in V2 )  Take element from if diff( n0 , n2 ) -> raise delete/update conflict either V1 or V2 if not diff( n0 , n2 ) -> remove n0  Evolve original element (V0) end if if not hasMatch( n0 in V1 ) && not hasMatch( n0 in V2 )  towards operation-based -> remove n0 merging end for for each m1 ∊ V1 | not hasMatch( m1 , V0 ) -> add m1 to merged version for each m2 ∊ V2 | not hasMatch( m2 , V0 ) -> add m2 to merged version 37

Outline  Context of Model Versioning  Foundations of Model Versioning  Conflict Categorization  Adaptable Model Versioning  Future Challenges 38

Conflict Examples Contradicting Change Person Person Person getName() ? 39

Conflict Examples Equivalent Change Person Person Person Person Employee Employee  Employee 40

Conflict Examples Equivalent Change UML Metamodel V1 UML Metamodel V2 Metamodel Class name:String 0..* Class superClasses superClass 1..1 1..* subClasses name:String o1, o2 | o1.id = o2.id Generalization o1 ∈ Class, o2 ∈ Class | o1.name = o2.name c1:Class c1:Class c1:Class c1:Class Model (AS) name=“Person“ name=“Person“ name=“Person“ name=“Person“ g1:Generalization g2:Generalization c2:Class c2:Class c3:Class c3:Class name=“Employee“ name=“Employee“ name=“Employee“ name=“Employee“ Sally Harry Sally Harry Person Person Person Person Model (CS) Person Person Employee  Employee Employee Employee  Employee Employee 41

Conflict Examples Syntactic Inconsistency has Car Engine has 1 1 * has Car Engine Car Engine  * 1 has Car Engine 42

Conflict Categorization Contradicting  What is the reason for a conflict? Operations  Contradicting operations Parallel Non-  One operation cannot be applied after the other Dependence Commutativity  The order in which the operations are applied V o V o m 1 m 2 m 1 m 2 affect the merge result V r1 V r2 V r1 V r2  Operation-based conflicts  The set of applied operations and a specification m 2 m 1 m 2 m 1 ≠ V m' V m'' V m of the characteristics of the operations is required, but no language specific knowledge  Inconsistent resulting state Inconsistent State  Inconsistent regarding abstract syntax rules  Inconsistent regarding the semantics Syntactic Semantic  State-based conflicts Inconsistency Inconsistency  A merged state and consistency rules are required V o m 1 m 2 V r1 V r2 m 2 m 1 43 V m

Conflict Categorization Which information/knowledge is required for detection? Generic information on operations Overlapping Operations Contradicting Equivalent Atomic Operations Operations • Update/Update • Add/Add • Delete/Update • Delete/Delete Language Knowledge Domain Knowledge Different language Different words constructs equi- Redundancy with equivalent Modeling Composite / Atomic valent semantics semantics Language Violations Common Dependent Metamodel Knowledge • Well-formedness Rule • Upper Ontology • Abstract Syntax • Thesaurus • ... Operation User-defined Contract Knowledge Extra • Pre-/Postconditions • Use Case Description • Requirement Specification Knowledge • ... necessary 44

Contradicting Operations: Update/Update V o Overlapping Operations Contradicting Equivalent Driving Atomic Person Operations Operations License • Update/Update • Add/Add • Delete/Update • Delete/Delete Language Knowledge Domain Knowledge V r1 Different language Different words constructs equi- Redundancy with equivalent Composite / Atomic valent semantics semantics 1 Driving Person License Violations Common Metamodel Knowledge • Well-formedness Rule • Upper Ontology • Abstract Syntax • Thesaurus • ... Operation User-defined V r2 Contract Knowledge • Pre-/Postconditions • Use Case Description • Requirement Specification * Driving • ... Person License 45

Equivalent Operations: Add/Add V o Employee Person Overlapping Operations Contradicting Equivalent Atomic Operations Operations • Update/Update • Add/Add • Delete/Update • Delete/Delete Language Knowledge Domain Knowledge V r1 Different language Different words Employee Person constructs equi- Redundancy with equivalent Composite / Atomic valent semantics semantics Violations Common Metamodel Knowledge • Well-formedness Rule • Upper Ontology • Abstract Syntax • Thesaurus • ... Operation User-defined V r2 Contract Knowledge Employee Person • Pre-/Postconditions • Use Case Description • Requirement Specification • ... 46

Equivalent Operations: Delete/Delete V o Employee Overlapping Operations Contradicting Equivalent Atomic contract Operations Operations • Update/Update • Add/Add • Delete/Update • Delete/Delete Language Knowledge Domain Knowledge V r1 Different language Different words constructs equi- Redundancy with equivalent Composite / Atomic valent semantics semantics Violations Common Metamodel Knowledge • Well-formedness Rule • Upper Ontology • Abstract Syntax • Thesaurus • ... Operation User-defined V r2 Contract Knowledge Employee • Pre-/Postconditions • Use Case Description • Requirement Specification • ... 47

Redundancy: Language Knowledge V o Overlapping Operations Contradicting Equivalent Developer Manager Atomic Operations Operations • Update/Update • Add/Add • Delete/Update • Delete/Delete Language Knowledge Domain Knowledge V r1 Different language Different words 1 constructs equi- Redundancy with equivalent Manager Developer Composite / Atomic valent semantics semantics * Violations Common managedBy Metamodel Knowledge • Well-formedness Rule • Upper Ontology • Abstract Syntax • Thesaurus • ... Operation User-defined V r2 Contract Knowledge • Pre-/Postconditions • Use Case Description Developer Manager • Requirement Specification • ... * 1 managedBy 48

Redundancy: Language Knowledge V o Overlapping Operations 1 Contradicting Equivalent * Employee Company Atomic Operations Operations contract • Update/Update • Add/Add • Delete/Update • Delete/Delete Language Knowledge Domain Knowledge V r1 Different language Different words constructs equi- Redundancy with equivalent * * Employee Company Composite / Atomic valent semantics semantics {nonunique} Violations Common Metamodel Knowledge Contract • Well-formedness Rule • Upper Ontology • Abstract Syntax • Thesaurus • ... Operation User-defined V r2 Contract Knowledge • Pre-/Postconditions • Use Case Description Employee Company • Requirement Specification • ... 1 1 * * Contract 49

Redundancy: Domain Knowledge V o Overlapping Operations Contradicting Equivalent Atomic Person Operations Operations • Update/Update • Add/Add • Delete/Update • Delete/Delete Language Knowledge Domain Knowledge V r1 Different language Different words constructs equi- Redundancy with equivalent Person Composite / Atomic valent semantics semantics lastname: String Violations Common Metamodel Knowledge • Well-formedness Rule • Upper Ontology • Abstract Syntax • Thesaurus • ... Operation User-defined V r2 Contract Knowledge • Pre-/Postconditions • Use Case Description • Requirement Specification Person • ... surname: String 50

Metamodel Violation :A :B V o Overlapping t Operations Contradicting Equivalent Atomic Operations Operations t+1 • Update/Update • Add/Add • Delete/Update • Delete/Delete Language Knowledge Domain Knowledge V r1 Different language Different words :A :B constructs equi- Redundancy with equivalent Composite / Atomic valent semantics semantics t Violations Common t+1 Metamodel Knowledge • Well-formedness Rule • Upper Ontology • Abstract Syntax • Thesaurus • ... Operation User-defined V r2 Contract Knowledge :A :B • Pre-/Postconditions • Use Case Description • Requirement Specification • ... t t+1 51

Operation Contract Violation Researcher V o Overlapping Operations Contradicting Equivalent Atomic Operations Operations Assistent Professor • Update/Update • Add/Add getLectures() getLectures() • Delete/Update • Delete/Delete Language Knowledge Domain Knowledge V r1 Different language Different words Researcher constructs equi- Redundancy with equivalent Composite / Atomic valent semantics semantics getLectures() Violations Common Metamodel Knowledge • Well-formedness Rule • Upper Ontology Assistent Professor • Abstract Syntax • Thesaurus • ... Operation User-defined V r2 Contract Knowledge Researcher • Pre-/Postconditions • Use Case Description • Requirement Specification • ... Professor Assistent ProjectAss getLectures() getLectures() 52

Common Knowledge Violation V o Shape Overlapping Operations Contradicting Equivalent Atomic Operations Operations • Update/Update • Add/Add Circle Square Rectangle • Delete/Update • Delete/Delete Language Knowledge Domain Knowledge Shape V r1 Different language Different words constructs equi- Redundancy with equivalent Composite / Atomic valent semantics semantics Circle Rhomboid Violations Common Metamodel Knowledge Square Rectangle • Well-formedness Rule • Upper Ontology • Abstract Syntax • Thesaurus • ... Operation User-defined Shape V r2 Contract Knowledge • Pre-/Postconditions • Use Case Description • Requirement Specification Circle Quadrangle • ... Square Rectangle 53

User-defined Knowledge Violation :A CM V turnOn() o Overlapping Operations Contradicting Equivalent ON Atomic Operations Operations makeCoffee() • Update/Update • Add/Add ON • Delete/Update • Delete/Delete Language Knowledge Domain Knowledge :A CM V r1 turnOn() Different language Different words constructs equi- Redundancy with equivalent Composite / Atomic valent semantics semantics ON makeCoffee() Violations Common turnOff() Metamodel Knowledge OFF • Well-formedness Rule • Upper Ontology • Abstract Syntax • Thesaurus • ... Operation User-defined :A CM V r2 Contract Knowledge turnOn() • Pre-/Postconditions • Use Case Description • Requirement Specification ON • ... makeCoffee() ON makeTea() 54

Outline  Context of Model Versioning  Foundations of Model Versioning  Conflict Categorization  Adaptable Model Versioning  Future Challenges 55

AMOR: Adaptable Model Versioning Overview  FFG FIT-IT Semantic Systems Project  2009 – 2011  Collaborating parties  Vienna University of Technology www.modelversioning.org  Johannes Kepler University, Linz  SparxSystems, the vendor of Enterprise Architect  Three resulting dissertations  Petra Brosch, „ Conflict Resolution in Model Versioning “, TU Wien, 2012.  Philip Langer, „ Adaptable Model Versioning using Model Transformation By Demonstration “, TU Wien, 2011.  Konrad Wieland, „ Conflict-tolerant Model Versioning “, TU Wien, 2011. 56

Adaptable Model Versioning Overview 57

Adaptable Model Versioning Versioning Process Conflict Detection Operation-based Conflict Detection Conflict-tolerant State-based Resolution Operation Detection Merge V o V r1 V r2 58

Adaptable Model Versioning Versioning Process Conflict Detection Operation-based Conflict Detection Conflict-tolerant State-based Resolution Operation Detection Merge V o M Vo ● Vr1 M Vo ● Vr2 V r1 V r2 D Vo ● Vr1 D Vo ● Vr2 59

Adaptable Model Versioning Versioning Process Conflict Detection Operation-based Conflict Detection Conflict-tolerant State-based Resolution Operation Detection Merge V o M Vo ● Vr1 M Vo ● Vr2 V r1 V r2 D Vo ● Vr1 D Vo ● Vr2 C V1 ● Vr2 60

Adaptable Model Versioning Versioning Process Conflict Detection Operation-based Conflict Detection Conflict-tolerant State-based Resolution Operation Detection Merge V o M Vo ● Vr1 M Vo ● Vr2 V r1 V r2 D Vo ● Vr1 D Vo ● Vr2 C V1 ● Vr2 61 V m+oc

Adaptable Model Versioning Versioning Process Conflict Detection Operation-based Conflict Detection Conflict-tolerant State-based Resolution Operation Detection Merge V o M Vo ● Vr1 M Vo ● Vr2 V r1 V r2 D Vo ● Vr1 D Vo ● Vr2 C V1 ● Vr2 62 V m+oc+sc

Adaptable Model Versioning Versioning Process Conflict Detection Operation-based Conflict Detection Conflict-tolerant State-based Resolution Operation Detection Merge V o M Vo ● Vr1 M Vo ● Vr2 V r1 V r2 D Vo ● Vr1 D Vo ● Vr2 C V1 ● Vr2 63 V m

Adaptable Model Versioning Versioning Process: Step by step 64

Operation Detection Two approaches for obtaining applied operations  Model Differencing  Comparison of states of an artifact  Match function to find correspondence of two elements in compared artifacts necessary  Differences are converted in atomic operations  Editor and language independent  Composite operation detection difficult, but possible in many cases  Operation Recording  Records operation sequences  Recording of atomic operations ( add, update, delete )  Recording of composite operations possible if available in the editor  Cleansing to remove obsolete operations for more efficient merging  Strong editor dependence 65

Operation Detection Overview  Two-phase process  Phase 1 : Matching for finding correspondences between objects  Phase 2 : Fine-grained comparison of corresponding objects  Phase 3 : Detection of composite operation applications Phase 1 V V r1 M Vo ● Vr1 o Phase 2 D Vo ● Vr1 cop Phase 3 D Vo ● Vr1 66

Operation Detection: Phase 1 – Matching Goal  Match function is needed 1. Universally Unique ID (UUID) 2. Heuristics to compute similarity measures based on features of objects  Quality of operation detection depends on quality of the match 67

Operation Detection: Phase 1 – Matching Metamodel and Example Model Match Metamodel  Correspondences are described original * by a match model (weaving model) MatchModel Match 1 revised EObject  Links corresponding elements 1 (from Ecore) «Enumeration»  Marks unmatched elements 1 Unmatch Side object * - Original side:Side - Revised State Machine Model V o State Machine Model V r : Unmatch : Match : Match : Match : Match : Match : Unmatch side = Original side = Revised : MatchModel 68 Match Model

Operation Detection: Phase 1 – Matching Metamodel and Example Model Match Metamodel  Correspondences are described original * by a match model (weaving model) MatchModel Match 1 revised EObject  Links corresponding elements 1 (from Ecore) «Enumeration»  Marks unmatched elements 1 Unmatch Side object * - Original side:Side - Revised State Machine Model V o State Machine Model V r : StateMachine : StateMachine states states states states : SingleState : CompositeState : SingleState : CompositeState name = "Cooling" name = "Cooling" name = "Active" name = "Active" transitions states target target states states target : Transition : SingleState : SingleState : Transition : Transition : SingleState name = "switch" name = "Heating" name = "Idle" name = "switch" name = "switch" name = "Heating" transitions transitions : Unmatch : Match : Match : Match : Match : Match : Unmatch side = Original side = Revised : MatchModel 69 Match Model

Operation Detection: Phase 2 – Comparison  Deleted and inserted objects are explicitly marked by match model  But what is with structural feature changes?  Fine-grained operation types depend on the metamodeling features  E.g., Ecore offers ordered features, etc.  Supported operations  Insert Object ENamedElement name : String  Delete Object  Feature Update 0..* EClass EStructuralFeature  Insert Feature Value ordered : boolean lowerBound : int  Delete Feature Value 1..1 type upperBound : int  Insert Ordered Feature Value  Delete Ordered Feature Value EReference EAttribute containment : booelan type : EDataType  Feature Order Change  Move 70

Operation Detection: Phase 2 – Comparison Difference Metamodel * EObject DifferenceModel Change 1 (from Ecore) changed EObject Object value 1 (from Ecore) 1 EStructuralFeature 1 1 FeatureChange ObjectChange (from Ecore) containment object changed Feature 1 target Feature 1 source InsertObject DeleteObject FeatureUpdate ValueOrderChange index : EInteger Move InsertFeatureValue DeleteFeatureValue self.changedFeature self.changedFeature self.changedFeature.upperBound > 1 .upperBound = 1 .upperBound > 1 and self.changedFeature.ordered = true InsertOrderedFeatureValue DeleteOrderedFeatureValue index : EInteger index : EInteger self.changedFeature.ordered = true 71

Operation Detection: Phase 2 – Comparison Difference Model Example State Machine Model V o State Machine Model V r 72

Operation Detection: Phase 2 – Comparison Difference Model Example State Machine Model V o State Machine Model V r : StateMachine : StateMachine states states states states : SingleState : CompositeState : SingleState : CompositeState name = "Cooling" name = "Cooling" name = "Active" name = "Active" states transitions states states target target target : Transition : SingleState : SingleState : Transition : Transition : SingleState name = "switch" name = "Heating" name = "Idle" name = "switch" name = "switch" name = "Heating" transitions transitions value affectedObject value affectedObject affectedObject value affectedObject value object object : DeleteFeatureValue : DeleteFeatureValue : InsertFeatureValue : InsertFeatureValue source target featureOperation featureOperation feature : DeleteObject : Move feature : InsertObject feature feature Difference Model D V o ,V r : EClass : EReference : EReference type features name = "SinlgeState" name = "transitions" name = "states" containment = true containment = true ordered = false ordered = false lowerBound = 0 lowerBound = 0 : EClass features upperBound = -1 upperBound = -1 name = "StateMachine" 73 State Machine Metamodel

Operation Detection: Phase 3 Composite operation detection process Input Operation Operation Operation Specification Diff Model Operation D Vo ● Vr1/2 Specification Specification Specifications «foreach» «foreach» Diff Model Preprocessing Derive Precondition Derive Postcondition Binding Binding Operation Input Operation Operation Specification Signature Specification Precondition Postcondition Signature Binding Binding Evaluate Binding Evaluate Binding Preselection [invalid] [valid] [invalid] [valid] [no diff match] [diff matches] Valid Operation Operation Operation Operation Potential Precondition Specification Operation Specification Occurrence Operation Specification Binding Specification Occurrence 1 2 3 Refactoring Refactoring Operation cop Occurrence Occurrence D Vo ● Vr1/2 Occurrence 74

Operation Detection: Phase 3 Composite operation detection process Input Operation Where do operation specifications come from? Operation Operation Specification Diff Model Operation D Vo ● Vr1/2 Specification Specification Specifications «foreach» «foreach» Diff Model Preprocessing Derive Precondition Derive Postcondition Binding Binding Operation Input Operation Operation Specification Signature Specification Precondition Postcondition Signature Binding Binding Evaluate Binding Evaluate Binding Preselection [invalid] [valid] [invalid] [valid] [no diff match] [diff matches] Valid Operation Operation Operation Operation Potential Precondition Specification Operation Specification Occurrence Operation Specification Binding Specification Occurrence 1 2 3 Refactoring Refactoring Operation cop Occurrence Occurrence D Vo ● Vr1/2 Occurrence 75

Operation Specifications How to specify operation specifications  Operation Specifications  Define composite operations  Composite operations  Set of cohesive atomic operations  Applied in a transaction  To fulfill a common goal  Common goal should be respected during merge  Thus, they should be detected  Operation specifications are language-specific  A plethora of modeling languages exists  Each has its own composite operations  Infeasable for language engineers to pre-specify all of them  Allow modelers themselves to specify them  Operation specifications are model transformations  In particular, endogeneous in-place transformations 76

Operation Specifications How to specify operation specifications  Prerequisites for model transformation development  Experience in model transformation languages  Deep understanding of the involved metamodels  Common modelers are only aware of the concrete syntax  Model transformation languages are based on the abstract syntax 1 * examines Professor Student examiner examinee name name Concrete Syntax name:Property name:Property Professor:Class Student:Class examines:Assoc Abstract examinee:Property examiner:Property Syntax 77

Model Transformation by Demonstration (MTBD)  Goal of MTBD  Easing the specification of model transformations  Specification using the concrete syntax  Derive the general transformation automatically from a demonstration of these changes applied to an example model Operation Specification Preconditions Actions Postconditions Can also be used Can also be used for as selectors. computing target values.

MTBD Example: Introduce Composite State • Introduce Active hang_up • Change target of lift • Introduce new initial state lift Idle DialTone • Introduce transition initial to DialTone • Change source of one hang_up transition dial hang_up • Remove all other hang_up transtitions Dialing • Move states into Active dial Active lift Idle DialTone hang_up dial Dialing dial 79

MTBD Process Overview 1 Initial 2 Working Modeling Create initial model Copy initial model model model Revised 3 Performupdates model 5 4 State-based Imply conditions comparison Configuration & Generation Conditions Diff [implied] model 6 Edit conditions Operation Conditions 7 Specification Generate OSM [revised] Model Legend Refactoring 8 Wizard Generate specific automatic Wizard artifacts … manual 80

MTBD Process Step 1: Create Initial Model 1 Initial 2 Working Modeling Create initial model Copy initial model model model Revised 3 Performupdates model Model elements, which are… Required for execution 5 4 State-based Handled differently Imply conditions comparison Configuration & Generation Outside Conditions Outside start Diff [implied] model CompositeState start toFold toFold 6 Edit conditions IntoStart IntoStart JustInto toFold Operation JustInto Conditions 7 Specification Generate OSM [revised] Model Legend Refactoring 8 Wizard Generate specific automatic Wizard artifacts … manual 81

MTBD Process Step 2: Copy Initial Model 1 Initial 2 Working Modeling Create initial model Copy initial model model model Revised 3 Performupdates model Unique IDs preserve relationship 5 4 State-based Imply conditions comparison Configuration & Generation Conditions Diff [implied] model 6 Edit conditions Operation Conditions 7 Specification Generate OSM [revised] Model Legend Refactoring 8 Wizard Generate specific automatic Wizard artifacts … manual 82

MTBD Process Step 3: Perform updates 1 Initial 2 Working Modeling Create initial model Copy initial model model model Revised 3 Performupdates model 5 4 State-based Illustrate composite operation Imply conditions comparison Configuration & Generation Conditions Outside start Diff [implied] model CompositeState 6 Edit conditions IntoStart toFold Operation JustInto Conditions 7 Specification Generate OSM [revised] Model Legend Refactoring 8 Wizard Generate specific automatic Wizard artifacts … manual 83

MTBD Process Step 4: State-based Comparison 1 Initial 2 Working Modeling Create initial model Copy initial model model model Revised 3 Performupdates model 5 4 State-based Imply conditions comparison Configuration & Generation Conditions Diff [implied] model 6 Edit conditions State-based Comparison Operation  Inputs: Initial and Revised Model Conditions 7 Specification Generate OSM [revised]  No editor-specific change tracking Model  Any editor applicable Legend Refactoring 8 Wizard Generate specific automatic Wizard artifacts … manual 84

MTBD Process Step 5: Imply Conditions 1 Initial 2 Working Generic Condition Generation Modeling Create initial model Copy initial model model model  Initial model  preconditions Revised 3  Revised model  postconditions Performupdates model  Act as a basis for the next step 5 4 State-based Outside Imply conditions comparison Configuration & Generation toFold toFold start Conditions IntoStart JustInto Diff [implied] model  Outside : SingleState_0 6 Edit conditions  name = “Outside”  incoming->includes( #{Transition_1} ) Operation  … Conditions 7 Specification  IntoStart : SingleState_1 Generate OSM [revised]  toFold : Transition_1 Model  event = “toFold” Legend  target = #{SingleState_0} Refactoring 8 Wizard Generate specific  … automatic Wizard artifacts … manual 85

MTBD Process Step 5: Imply Conditions 1 Initial 2 Working Generic Condition Generation Modeling Create initial model Copy initial model model model  Initial model  preconditions Revised 3  Revised model  postconditions Performupdates model  Act as a basis for the next step 5 4 State-based Outside Imply conditions comparison Configuration & Generation == toFold toFold start Conditions IntoStart JustInto Diff [implied] model  … 6 Edit conditions  IntoStart : SingleState_1  toFold : Transition_1 Operation  event = “toFold” Conditions 7 Specification  target = #{SingleState_0} Generate OSM [revised]  … Model  JustInto : StingleState_2 Legend  toFold : Transition_2 Refactoring 8 Wizard Generate specific  event = #{Transition_1}.name automatic Wizard artifacts … manual 86

MTBD Process Step 6: Edit Conditions 1 Initial 2 Working Modeling Create initial model Copy initial model model model Revised 3 Performupdates model 5 4 State-based Configuration Imply conditions comparison Configuration & Generation  R elax (deactivate conditions)  E nforce (activate conditions) Conditions Diff [implied]  M odify (change conditions) model  A ugment iterations and user inputs 6 Edit conditions Default configuration: Relaxing Operation Conditions 7 Specification  String features and Generate OSM [revised] Model  Values which are empty and null Legend Refactoring 8 Wizard Generate specific automatic Wizard artifacts … manual 87

MTBD Process Step 7 and Step 8 1 Initial 2 Working Modeling Create initial model Copy initial model model model Revised 3 Performupdates model 5 4 State-based Imply conditions comparison Configuration & Generation Conditions Diff [implied] model 6 Edit conditions Operation Conditions 7 Specification Generate OSM [revised] Model Legend Refactoring 8 Wizard Generate specific automatic Wizard artifacts … manual 88

MTBD: Tooling  Eclipse Modeling Operations (EMO)  http://www.modelversioning.org/index.php?option=com_content&view=arti cle&id=68&Itemid=89 Diff Model & Annotations Initial Model Revised Model Preconditions Postconditions 89

Operation-based Conflict Detection Overview  Step 1: Atomic operation conflict detection  Does not regard composite operation  Step 2: Composite operation conflict detection  Checks for violated preconditions of applied composite operations  Input: Two difference models cop cop D Vo ● Vr1 D Vo ● Vr2  Output: Conflict model C V1 ● Vr2 90

Atomic Operation-based Conflict Detection Atomic Conflict Metamodel  Operation-based conflicts are described by a metamodel  Each conflict type is represented by a dedicated metaclass  Conflict patterns for detecting operation-based conflicts  Each concrete conflict type has conflict patterns attached * ConflictModel Conflict conflicts DeleteUse UpdateUpdate DeleteUpdate DeleteMove MoveMove move 2 move 1 Move update 2 update 1 FeatureChange use 1 1 1 DeleteObject delete delete 91

Atomic Operation-based Conflict Detection Conflict Pattern 1: Delete/Use Conflict  Delete/Use conflict occurs if  Modeler A deletes object o  Modeler B uses object o in a featureChange operation as value Example S1 S2 S2 S1 S1 Pattern du: DeleteUse delete use do: DeleteObject o: Object fc : FeatureChange object value 92

Atomic Operation-based Conflict Detection Conflict Pattern 2: Delete/Update Conflict  Delete/Update conflict occurs if Example S1  Modeler A deletes object o  Modeler B updates a feature f of object o S1_1 Pattern du: DeleteUpdate update delete fc : FeatureChange changed do: DeleteObject o: Object object Object There are several more patterns! G. Taentzer, C. Ermel, P. Langer, M. Wimmer: Conflict Detection for Model Versioning Based on Graph Modifications ; in: “Software and Systems Modeling (SoSym)", Springer, to appear in 2012. P. Langer: Adaptable Model Versioning based on Model Transformation By Demonstration ; 93 Reviewer: G. Kappel, J. Gray; E188 Institut für Softwaretechnik und Interaktive Systeme, 2011.

Composite Operation Conflict Detection  For each composite operation application,  check whether it is applicable at the opposite side V o V o cop D Vo ● Vr1 cop D Vo ● Vr2 V r2 V r2 V r1 V r1 cop 1..i cop 1..i 94

Composite Operation Conflict Detection  Example V r1 lift Idle Active V o Introduce hangup Composite DialTone lift Idle State dial DialTone dial hangup Dialing dial Dialing hangup Rename V r2 hangup lift Idle DialTone abort dial dial Dialing hangup 95

Composite Operation Conflict Detection  Example V r1 lift Idle cop D Vo ● Vr1 Active V o Introduce hangup Original Composite DialTone match lift Idle State dial SingleState_0 DialTone dial Transition_0 hangup Dialing SingleState_1 dial Transition_1 Precondition of Dialing composite SingleState_2 hangup operation is Rename V r2 Transition_2 violated! hangup lift Idle SingleState_0 DialTone Transition_0 abort dial SingleState_1 Transition_1.name = Transition_2.name dial Transition_1 Dialing SingleState_2 hangup 96 Transition_2

Conflict-tolerant Merge How to support developers when merging different versions?  Motivation  Only one modeler is responsible for conflict resolution  Final version does not reflect all intentions of the modelers  Conflicts are considered harmful  They should be subject of discussion  Merging conflicts is rejecting one of the conflicting operations  However, a merged model is helpful for deciding how to resolve conflicts  Goal  Conflict-tolerant model versioning system supporting a collaborative conflict resolution process  Challenge  Merge is not possible in case of conflicts!  How can a merge be accomplished in case of conflicts?  How can the conflicts be visualized for any modeling language? 97

Conflict-tolerant Merge Solution  General Approach 1. Conflict-tolerant merge rules  To avoid conflict resolution during check-in  To find a merge result irrespectively of conflicts 2. Conflict annotations  To avoid information loss  To enable distributing the responsibility of conflict resolution  To provide a basis for discussion 3. Conflict resolution model  To control the lifecycle of a conflict  To manage conflicts and resolutions 98

Conflict-tolerant Merge Rules Prioritize one change or omit both changes  To enable a merge irrespectively of conflicts  Omit both conflicting changes in case of …  Update-update: Use original value  Move-move: Use original container  Omit deletions out of two conflicting changes  Delete-update: Prioritize Update  Delete-use: Prioritize Use  Delete-move: Prioritize Move 99

Conflict-tolerant Merge Rules Example: Update-update Conflict V1  Update-update Conflict Employee bday Origin Version created by USER_A o1:Object f1 = x Update by USER_B Update by USER_C o1:Object o1:Object V1a V1b f1 = y f1 = z Employee Employee Merged Version birthday doB <<UpdateUpdate>> o1:Object --Involved Elements f1 = x Upd_feature= {f1} Upd_value ={<USER_B : y> , <USER_C : z>} --User-related Metadata User_upd= {USER_B, USER_C} Owner= USER_A --Time related Metadata V2 … Employee <<UpdateUpdate>> bday 100