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
Recommend
More recommend
