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

▶
introduction to model versioning
SMART_READER_LITE
LIVE PREVIEW

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

Feb 07, 2024 237 likes •1.81k views

Introduction to Model Versioning SFM-12: MDE June 22, 2012 Petra Brosch, Gerti Kappel, Philip Langer, Martina Seidl, Konrad Wieland, and Manuel Wimmer Business Informatics Group Institute of Software Technology and Interactive Systems

slide-1
SLIDE 1 Business Informatics Group Institute of Software Technology and Interactive Systems Vienna University of Technology Favoritenstraße 9-11/188-3, 1040 Vienna, Austria phone: +43 (1) 58801-18804 (secretary), fax: +43 (1) 58801-18896
  • ffice@big.tuwien.ac.at, www.big.tuwien.ac.at

Introduction to Model Versioning

SFM-12: MDE

June 22, 2012 Petra Brosch, Gerti Kappel, Philip Langer, Martina Seidl, Konrad Wieland, and Manuel Wimmer

slide-2
SLIDE 2

Outline

2

  • Context of Model Versioning
  • Foundations of Model Versioning
  • Conflict Categorization
  • Adaptable Model Versioning
  • Future Challenges
slide-3
SLIDE 3

Evolution

Definition

  • Evolution in the broader sense taken from

http://www.merriam-webster.com/dictionary/evolution

  • A process of change in a certain direction
  • A process of continuous change from a lower, simpler, or worse to a

higher, more complex, or better state

  • Software Evolution
  • The process of changing a software system from its creation until its

shutdown.

3

slide-4
SLIDE 4

Software Evolution aka Software Aging

David Lorge Parnas: Software aging. In Proc. of the International Conference on Software Engineering (ICSE’94), pages 279–287. IEEE Computer Society Press, 1994.

4

slide-5
SLIDE 5

Software Evolution aka Software Maintenance

5

slide-6
SLIDE 6

Evolution

6

Is Software resistant to change? Of course, not!

  • Reasons for evolution
  • Technology Switch
  • Restructuring
  • Bug Fixing
  • Functionality Extension
  • Optimization
  • …
  • Bad news: A computer program that is used

will be modified, thus its entropy increases.

  • Silver Bullet?: Model-driven Software Engineering
  • Platform independent models
  • Generate code automatically
  • Are models resistant to change?
slide-7
SLIDE 7

Everything changes…

7

Evolution in Model-driven Software Engineering Model Requirements

fulfills

Platform

is_deployed

Change Change

instanceOf

Metamodel Change Model Change

slide-8
SLIDE 8

Evolution in Model-driven Software Engineering

8

Modeling Languages evolve too! Model Requirements

fulfills

Platform

is_deployed

Change Change

instanceOf

Metamodel Change Model Change

slide-9
SLIDE 9

Modeling Language Evolution

Metamodels are the central artefacts!

9

Metamodel

Textual Concrete Syntax Graphical Concrete Syntax Models Model 2 Model Transformations Model 2 Code Transformations OCL Constraints Inplace Transformations

slide-10
SLIDE 10

Co-Evolution

Consequence of Metamodel Evolution

  • Term “Co-Evolution” borrowed from Biology
  • Biological co-evolution is the change of a biological entity triggered by

the change of a related entity

  • One-to-one Relationships: Predator/Prey, Host/Symbiont, Host/Parasite, …
  • Diffuse Relationships: An entity evolves in response to a number of other

entities, each of which is also evolving in response to a set of entities

  • Co-Evolution in MDE
  • Co-evolution is the change of a model triggered by the change of a

related model

  • Current View
  • Relationship: r(a,b)
  • a → a’
  • b → b’ | r(a’,b’)
  • Challenge: Relationship Reconciliation
  • Current research focus is on one-to-one relationships

10

a a' b b' ∆ ∆

slide-11
SLIDE 11

Metamodel Evolution

Mainly models, i.e., instances of metamodels, are currently co-evolved!

11

Metamodel

Textual Concrete Syntax Graphical Concrete Syntax Models Model 2 Model Transformations Model 2 Code Transformations OCL Constraints Simulators

slide-12
SLIDE 12

Evolution in Model-driven Software Engineering

12

Platforms (Software and Hardware) evolve rapidly! Model Requirements

fulfills

Platform

is_deployed

Change Change

instanceOf

Metamodel Change Model Change

slide-13
SLIDE 13

Platforms evolve rapidly!

13

Plaforms are represented by metamodels

MMa MMb

Source Metamodel Target Metamodel

t1

Modeling Language Platform Deployment

t1 … Forward Transformation

slide-14
SLIDE 14

14 MMa MMb MMb‘

Platform Evolution

t1 t2

t1 … Forward Transformation t2, t3 … Migration Transformation

v1.0 v2.0

Metamodel/Transformation (Co-)Evolution

Platform evolution is reflected by target metamodel evolution

Target Metamodel

v3.0

MMb‘‘

t3

Source Metamodel

slide-15
SLIDE 15

15 MMa MMb MMb‘

Source Metamodel

Platform Evolution

t1 t2 v1.0 v2.0

Metamodel/Transformation (Co-)Evolution

Transformation chains for tackling platform evolution

Target Metamodel

v3.0

MMb‘‘

t3

t1 … Forward Transformation t2, t3 … Migration Transformation

slide-16
SLIDE 16

Evolution in Model-driven Software Engineering

16

Is modeling a one woman-show? Model Requirements

fulfills

Platform

is_deployed

Change Change

instanceOf

Metamodel Change Change

slide-17
SLIDE 17

Evolution in Model-driven Software Engineering

17

No, support for team-based development is needed! Model Requirements

fulfills

Platform

is_deployed

Change Change

instanceOf

Metamodel Change Change

slide-18
SLIDE 18

Support for Team-based Development of Models is Needed!

  • Recall some definitions of Software Engineering (SE)
  • SE is defined as the multi-person construction of multi-version software

– David Lorge Parnas, 1975

  • SE deals with the building of software systems that are so large or so complex that

they are built by teams of engineers – Carlo Ghezzi, Mehdi Jazayeri, and Dino Mandrioli , 2002

  • Assume we have four modelers (a, b, c, d)

18

∆a

Initial Model

ma m0 mb mc md

Revised Models Consolidated Model

m1

∆b ∆c ∆d

m1 := ma ⊕ mb ⊕ mc ⊕ md pre := parallelIndependent(∆d, ∆c, ∆b, ∆a)

slide-19
SLIDE 19

Evolution Scenarios at a Glance

  • Evolution
  • a → a’
  • Challenge: Realization & Understanding
  • Co-Evolution
  • Consistency Relationship: c(a, b)
  • a → a’
  • b → b’ | c(a’, b’)
  • Challenge: Consistency Reconciliation
  • Parallel Evolution
  • a → a1, a → a2
  • a1 ⊕ a2 → a’
  • Challenge: Conflict Detection & Resolution

19

a a' a a' b b' a a1 a2 a' ∆ ∆ ∆ ∆ ∆

slide-20
SLIDE 20

Outline

20

  • Context of Model Versioning
  • Foundations of Model Versioning
  • Conflict Categorization
  • Adaptable Model Versioning
  • Future Challenges
slide-21
SLIDE 21

Versioning

  • Software Configuration Management (SCM)
  • Originated from aerospace industries in the 1950s
  • Initiated by issues coming from inadequately documented engineering changes
  • Managing and controlling
  • Corrections
  • Extensions
  • Adaptations
  • Traceability throughout the system lifecycle
  • Complex software systems pose similar challenges as other systems

 Configuration Management for software in late 1970s  Software Configuration Management was born (with SCCS)

  • Versioning
  • “Maintaining a historical archive of a set of artifacts as they undergo

a series of changes”

  • Fundamental building block of SCM

21

Estublier, J., Leblang, D., van der Hoek, A., Conradi, R., Clemm, G., Tichy, W., & Wiborg-Weber, D. (2005). Impact of Software Engineering Research on the Practice of Software Configuration Management. ACM Transactions on Software Engineering and Methodology, 14(4), 383-430.
slide-22
SLIDE 22

History of Versioning Systems

22

Based on http://codicesoftware.blogspot.com/2010/11/version-control-timeline.html

local to central … central to distributed …

1972

sccs

discourage branching … everything is a branch …
slide-23
SLIDE 23

Versioning Paradigms

  • Pessimistic Versioning
  • Central repository for storing shared artifacts
  • No concurrent write access allowed (file locking)
  • Optimistic Versioning
  • Concurrent teamwork allowed
  • Version Merging necessary
  • Conflicts might occur when same unit of comparison is changed in different ways

Update-update, Delete-update

  • Conflicts have to be resolved manually

23

slide-24
SLIDE 24

Model Versioning

24

Overview on Optimistic Model Versioning

slide-25
SLIDE 25

Model Versioning

Is getting more and more important

  • Empirical study on versioning habits in practice

25

Wieland, K., Fitzpatrick, G., Kappel, G., Seidl, M., and Wimmer, M. (2012). Towards an Understanding of Requirements for Model Versioning Support. To appear in the International Journal of People-Oriented Programming, IGI Global.
slide-26
SLIDE 26

The Model Versioning Process Revised

26

V0 V0’ V0’’ V0’+V0’’

A A A A A A A A C C A A C

V1

A A
slide-27
SLIDE 27

Why not SVN with Unix diff?

27

slide-28
SLIDE 28

Design Dimensions of Versioning Systems

28

Artifact Representation Delta Identification

Graph-based artifact representation State-based delta identification Text-based artifact representation State-based delta identification Graph-based artifact representation Operation-based delta identification Text-based artifact representation Operation-based delta identification

State-based Operation-based Text-based Graph-based

slide-29
SLIDE 29

Text-based Merging

Example

29

Text-based Representation Version 0 Version 1

Version 2

1: class Human { 2: string[1..1] name 3: } 4: class Vehicle { 5: integer[0..1] carNo 6: } 1: class Person { 2: string[1..1] name 3: Vehicle[0..*] owns 4: } 5: class Vehicle { 6: integer[1..1] carNo 7: } 1: class Human { 2: string[1..1] name 3: } 4: class Car { 5: integer[0..1] regId 6: } Grammar Class:= "class" name=ID "{" (references+=Reference)* (attribute+=Attribute)* "}"; Reference:= target=[Class] "[" lower=BOUND ".." upper=BOUND "]" name=ID; Attribute:= type=ID "[" lower=BOUND ".." upper=CARD "]" name=ID; terminal ID:= ('a'..'z'|'A'..'Z'|'_')+; terminal BOUND:= (('0'..'9')+)|('*');
slide-30
SLIDE 30

Text-based and State-based Merging

30

Version 0 Version 1

Version 2

1: class Human { 2: string[1..1] name 3: } 4: class Vehicle { 5: integer[0..1] carNo 6: } 1: class Person { 2: string[1..1] name 3: Vehicle[0..*] owns 4: } 5: class Vehicle { 6: integer[1..1] carNo 7: } 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 { 6: <<UP/UP>> 7: } a: integer[1..1] carNo b: integer[0..1] regId c: integer[1..1] regId
slide-31
SLIDE 31

Text-based and Operation-based Merging

31

Version 0 Version 1

Version 2

1: class Human { 2: string[1..1] name 3: } 4: class Vehicle { 5: integer[0..1] carNo 6: } 1: class Person { 2: string[1..1] name 3: Vehicle[0..*] owns 4: } 5: class Vehicle { 6: integer[1..1] carNo 7: } 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: Car[0..*] owns 4: } 5: class Car { 6: <<UP/UP>> 7: } a: integer[1..1] carNo b: integer[0..1] regId c: integer[1..1] regId Rename-Op: change Class.name; update Property.type pre@Class.name with post@Class.name;
slide-32
SLIDE 32

Graph-based Merging

Example

32

Human : Class Vehicle : Class name : Attribute type = string lower = 1 upper = 1
  • wns : Reference
lower = 0 upper = * Graph-based Representation Version 2 Legend <NodeName> : <Type> <attributeName> = <value> Containment Edge Edge carNo : Attribute type = integer lower = 0 upper = 1 Person : Class Vehicle : Class carNo : Attribute type = integer lower = 1 upper = 1 Human : Class Car : Class name : Attribute type = string lower = 1 upper = 1 regId : Attribute type = integer lower = 0 upper = 1 name : Attribute type = string lower = 1 upper = 1 Version 1
slide-33
SLIDE 33

Graph-based and State-based Merging

33

Heuristic-based Matching

Human : Class Vehicle : Class name : Attribute type = string lower = 1 upper = 1
  • wns : Reference
lower = 0 upper = * Version 2 carNo : Attribute type = integer lower = 0 upper = 1 Person : Class Vehicle : Class carNo : Attribute type = integer lower = 1 upper = 1 Human : Class Car : Class name : Attribute type = string lower = 1 upper = 1 regId : Attribute type = integer lower = 0 upper = 1 name : Attribute type = string lower = 1 upper = 1 Version 1 Version 0
  • wns : Reference
lower = 0 upper = * Person : Class name : Attribute type = string lower = 1 upper = 1 Version 3 Car : Class regId : Attribute type = integer lower = 0 upper = 1 carNo : Attribute type = integer lower = 1 upper = 1 <<DEL/UP>>
slide-34
SLIDE 34

Graph-based and State-based Merging

34

Match Model based on Heuristic (Name + Structure Equivalence)

Human : Class Vehicle : Class name : Attribute type = string lower = 1 upper = 1
  • wns : Reference
lower = 0 upper = * Version 2 carNo : Attribute type = integer lower = 0 upper = 1 Person : Class Vehicle : Class carNo : Attribute type = integer lower = 1 upper = 1 Human : Class Car : Class name : Attribute type = string lower = 1 upper = 1 regId : Attribute type = integer lower = 0 upper = 1 name : Attribute type = string lower = 1 upper = 1 Version 1 Version 0
slide-35
SLIDE 35

Graph-based and State-based Merging

35

Match Model + Diff Model

Human : Class Vehicle : Class name : Attribute type = string lower = 1 upper = 1
  • wns : Reference
lower = 0 upper = * Version 2 carNo : Attribute type = integer lower = 0 upper = 1 Person : Class Vehicle : Class carNo : Attribute type = integer lower = 1 upper = 1 Human : Class Car : Class name : Attribute type = string lower = 1 upper = 1 regId : Attribute type = integer lower = 0 upper = 1 name : Attribute type = string lower = 1 upper = 1 Version 1 Version 0 remove(Vehicle:Class, carNo:Attribute)
slide-36
SLIDE 36

Graph-based and State-based Merging

36

ID-based Matching

Human : Class Vehicle : Class name : Attribute type = string lower = 1 upper = 1
  • wns : Reference
lower = 0 upper = * Version 2 carNo : Attribute type = integer lower = 0 upper = 1 Person : Class Vehicle : Class carNo : Attribute type = integer lower = 1 upper = 1 Human : Class Car : Class name : Attribute type = string lower = 1 upper = 1 regId : Attribute type = integer lower = 0 upper = 1 name : Attribute type = string lower = 1 upper = 1 Version 1 Version 0
  • wns : Reference
lower = 0 upper = * Person : Class Car : Class regId : Attribute type = integer lower = 1 upper = 1 name : Attribute type = string lower = 1 upper = 1 Version 3

1 2 3 4 1 2 3 4 5 1 2 3 4 1 2 3 4 5

slide-37
SLIDE 37

State-based Merge Algorithm (agnostic of representation & match and diff realization)

37

Design Decisions

  • Matching (hasMatch)
  • By Equivalence
  • By ID
  • By Heuristics
  • Comparison (diff)
  • Element granularity
  • Feature granularity
  • Consolidation (remove/add)
  • Take element from

either V1 or V2

  • Evolve original element (V0)

 towards operation-based merging

for each n0 ∊ V0 n1 := match(n0 in V1) n2 := match(n0 in V2) if hasMatch(n0 in V1) && hasMatch(n0 in V2) if diff(n0, n1) && not diff(n0, n2) -> use n1 if not diff(n0, n1) && diff(n0, n2) -> use n2 if diff(n0, n1) && diff(n0, n2)
  • > raise update/update conflict
if not diff(n0, n1) && not diff(n0, n2) -> use n0 end if if hasMatch(n0 in V1) && not hasMatch(n0 in V2) if diff(n0, n1) -> raise delete/update conflict if not diff(n0, n1) -> remove n0 end if if not hasMatch(n0 in V1) && hasMatch(n0 in V2) if diff(n0, n2) -> raise delete/update conflict if not diff(n0, n2) -> remove n0 end if if not hasMatch(n0 in V1) && not hasMatch(n0 in V2)
  • > remove n0
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
slide-38
SLIDE 38

Outline

38

  • Context of Model Versioning
  • Foundations of Model Versioning
  • Conflict Categorization
  • Adaptable Model Versioning
  • Future Challenges
slide-39
SLIDE 39

Conflict Examples

Contradicting Change

39

Person Person getName()

?

Person

slide-40
SLIDE 40

Conflict Examples

Equivalent Change

40

Person Employee Person Employee Person Employee Person

slide-41
SLIDE 41

Conflict Examples

Equivalent Change

41 Employee Person Employee Person Employee Person

Employee Person Employee Person Employee Person

Class

superClass

Generalization

subClasses UML Metamodel V2 1..1 1..* name:String

Class

superClasses 0..* UML Metamodel V1 name:String name=“Person“

c1:Class

name=“Employee“

c2:Class

name=“Employee“

c3:Class

name=“Person“

c1:Class

Sally Harry name=“Person“

c1:Class

name=“Employee“

c2:Class g1:Generalization

name=“Person“

c1:Class

name=“Employee“

c3:Class g2:Generalization

Sally Harry

Metamodel Model (AS) Model (CS)

  • 1, o2 | o1.id = o2.id
  • 1 ∈ Class, o2 ∈ Class | o1.name = o2.name
slide-42
SLIDE 42

Car Engine

has 1

*

Car Engine

has 1

Conflict Examples

Syntactic Inconsistency

42

Car Engine

has

Car Engine

has

*

1

slide-43
SLIDE 43

Conflict Categorization

43

  • What is the reason for a conflict?
  • Contradicting operations
  • One operation cannot be applied after the other
  • The order in which the operations are applied

affect the merge result Operation-based conflicts The set of applied operations and a specification

  • f the characteristics of the operations is required,

but no language specific knowledge

  • Inconsistent resulting state
  • Inconsistent regarding abstract syntax rules
  • Inconsistent regarding the semantics

State-based conflicts A merged state and consistency rules are required

Contradicting Operations Inconsistent State Parallel Dependence Non- Commutativity Syntactic Inconsistency Semantic Inconsistency Vo Vr1 Vr2 m2 m1 m1 m2 Vm Vo Vr1 Vr2 m2 m1 m1 m2 Vm Vo Vr1 Vr2 m2 m1 m1 m2 Vm' Vm'' ≠
slide-44
SLIDE 44

Conflict Categorization

44

Which information/knowledge is required for detection?

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

Generic information

  • n operations

Modeling Language Dependent Extra Knowledge necessary

slide-45
SLIDE 45

Contradicting Operations: Update/Update

45

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

*

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

Equivalent Operations: Add/Add

46

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

Equivalent Operations: Delete/Delete

47

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

Redundancy: Language Knowledge

48

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

Redundancy: Language Knowledge

49

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

Redundancy: Domain Knowledge

50

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

Metamodel Violation

51

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

Operation Contract Violation

52

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

Common Knowledge Violation

53

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

User-defined Knowledge Violation

54

:A CM turnOn() makeCoffee() ON ON :A CM turnOn() makeCoffee() ON OFF turnOff() :A CM turnOn() makeCoffee() ON makeTea() ON V
  • Vr1
Vr2
slide-55
SLIDE 55

Outline

55

  • Context of Model Versioning
  • Foundations of Model Versioning
  • Conflict Categorization
  • Adaptable Model Versioning
  • Future Challenges
slide-56
SLIDE 56

AMOR: Adaptable Model Versioning

56

Overview

  • FFG FIT-IT Semantic Systems Project
  • 2009 – 2011
  • Collaborating parties
  • Vienna University of Technology
  • 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.

www.modelversioning.org

slide-57
SLIDE 57

Adaptable Model Versioning

57

Overview

slide-58
SLIDE 58

Adaptable Model Versioning

58

Versioning Process Resolution Operation Detection Operation-based Conflict Detection Conflict-tolerant Merge State-based Conflict Detection

V

  • Vr1

Vr2

slide-59
SLIDE 59

Adaptable Model Versioning

59

Versioning Process Resolution Operation Detection Operation-based Conflict Detection Conflict-tolerant Merge State-based Conflict Detection

V

  • Vr1

Vr2

MVo●Vr1 DVo●Vr1 MVo●Vr2 DVo●Vr2

slide-60
SLIDE 60

Adaptable Model Versioning

60

Versioning Process Resolution Operation Detection Operation-based Conflict Detection Conflict-tolerant Merge State-based Conflict Detection

V

  • Vr1

Vr2

MVo●Vr1 DVo●Vr1 MVo●Vr2 DVo●Vr2 CV1●Vr2

slide-61
SLIDE 61

Adaptable Model Versioning

61

Versioning Process Resolution Operation Detection Operation-based Conflict Detection Conflict-tolerant Merge State-based Conflict Detection

V

  • Vr1

Vr2

MVo●Vr1 DVo●Vr1 MVo●Vr2 DVo●Vr2 CV1●Vr2

Vm+oc

slide-62
SLIDE 62

Adaptable Model Versioning

62

Versioning Process Resolution Operation Detection Operation-based Conflict Detection Conflict-tolerant Merge State-based Conflict Detection

V

  • Vr1

Vr2

MVo●Vr1 DVo●Vr1 MVo●Vr2 DVo●Vr2 CV1●Vr2

Vm+oc+sc

slide-63
SLIDE 63

Adaptable Model Versioning

63

Versioning Process Resolution Operation Detection Operation-based Conflict Detection Conflict-tolerant Merge State-based Conflict Detection

V

  • Vr1

Vr2

MVo●Vr1 DVo●Vr1 MVo●Vr2 DVo●Vr2 CV1●Vr2

Vm

slide-64
SLIDE 64

Adaptable Model Versioning

64

Versioning Process: Step by step

slide-65
SLIDE 65

Operation Detection

65

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
slide-66
SLIDE 66

Operation Detection

66

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

V

  • Vr1

DVo●Vr1

Phase 2

MVo●Vr1

Phase 1 Phase 3

DVo●Vr1

cop
slide-67
SLIDE 67

Operation Detection: Phase 1 – Matching

67

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
slide-68
SLIDE 68

Operation Detection: Phase 1 – Matching

68

Metamodel and Example Model

  • Correspondences are described

by a match model (weaving model)

  • Links corresponding elements
  • Marks unmatched elements
MatchModel Match Unmatch side:Side * * EObject (from Ecore) 1 1 1
  • riginal
revised
  • bject
«Enumeration» Side
  • Original
  • Revised

Match Metamodel

State Machine Model Vr

: Match

Match Model State Machine Model Vo

: Unmatch side = Revised : Unmatch side = Original : Match : Match : Match : Match : MatchModel
slide-69
SLIDE 69

Operation Detection: Phase 1 – Matching

69

Metamodel and Example Model

  • Correspondences are described

by a match model (weaving model)

  • Links corresponding elements
  • Marks unmatched elements
MatchModel Match Unmatch side:Side * * EObject (from Ecore) 1 1 1
  • riginal
revised
  • bject
«Enumeration» Side
  • Original
  • Revised

Match Metamodel

State Machine Model Vr

: Match

Match Model State Machine Model Vo

: Unmatch side = Revised : Unmatch side = Original : Match : Match : Match : Match : MatchModel : StateMachine : CompositeState name = "Active" : SingleState name = "Cooling" : SingleState name = "Heating" : SingleState name = "Idle" : Transition name = "switch" states states states states transitions target : StateMachine : CompositeState name = "Active" : SingleState name = "Cooling" : SingleState name = "Heating" : Transition name = "switch" states states states transitions target : Transition name = "switch" transitions target
slide-70
SLIDE 70

Operation Detection: Phase 2 – Comparison

70

  • 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
  • Delete Object
  • Feature Update
  • Insert Feature Value
  • Delete Feature Value
  • Insert Ordered Feature Value
  • Delete Ordered Feature Value
  • Feature Order Change
  • Move
type EClass
  • rdered : boolean
lowerBound : int upperBound : int EStructuralFeature type : EDataType EAttribute containment : booelan EReference 0..* 1..1 name : String ENamedElement
slide-71
SLIDE 71

Operation Detection: Phase 2 – Comparison

71

Difference Metamodel

DifferenceModel FeatureChange ObjectChange * containment Feature EStructuralFeature (from Ecore) InsertObject DeleteObject EObject (from Ecore) changed Feature changed Object value
  • bject
1 1 1 1 1 Change FeatureUpdate InsertFeatureValue DeleteFeatureValue ValueOrderChange index : EInteger DeleteOrderedFeatureValue self.changedFeature.ordered = true index : EInteger self.changedFeature .upperBound = 1 InsertOrderedFeatureValue index : EInteger self.changedFeature.upperBound > 1 and self.changedFeature.ordered = true self.changedFeature .upperBound > 1 Move 1 target source 1 EObject (from Ecore)
slide-72
SLIDE 72

Operation Detection: Phase 2 – Comparison

72

Difference Model Example State Machine Model Vr State Machine Model Vo

slide-73
SLIDE 73

Operation Detection: Phase 2 – Comparison

73

Difference Model Example State Machine Model Vr State Machine Model Vo

: StateMachine : CompositeState name = "Active" : SingleState name = "Cooling" : SingleState name = "Heating" : SingleState name = "Idle" : Transition name = "switch" states states states states transitions target : StateMachine : CompositeState name = "Active" : SingleState name = "Cooling" : SingleState name = "Heating" : Transition name = "switch" states states states transitions target : Transition name = "switch" transitions target

Difference Model DVo,Vr

: InsertFeatureValue : DeleteFeatureValue : Move source target : DeleteFeatureValue : DeleteObject : InsertFeatureValue : InsertObject featureOperation featureOperation value affectedObject affectedObject affectedObject value value value affectedObject : EReference name = "states" containment = true
  • rdered = false
lowerBound = 0 upperBound = -1 : EReference name = "transitions" containment = true
  • rdered = false
lowerBound = 0 upperBound = -1

State Machine Metamodel

: EClass name = "StateMachine" : EClass name = "SinlgeState" feature feature feature feature features features type
  • bject
  • bject
slide-74
SLIDE 74 Operation Specification Operation Specification Operation Specification Input Diff Model Operation Specification Operation Specification Operation Signature Input Signature Preselection Operation Specification Operation Specification Potential Operation Occurrence [diff matches] [no diff match] Derive Precondition Binding Precondition Binding Evaluate Binding Operation Specification Operation Specification Valid Precondition Binding [invalid] Derive Postcondition Binding Postcondition Binding [invalid] [valid] [valid] Refactoring Occurrence Refactoring Occurrence Operation Occurrence «foreach» «foreach» Operation Occurrence Evaluate Binding Diff Model Preprocessing

1 2 3

Operation Detection: Phase 3

74

Composite operation detection process

Operation Specifications

DVo●Vr1/2 DVo●Vr1/2

cop
slide-75
SLIDE 75 Operation Specification Operation Specification Operation Specification Input Diff Model Operation Specification Operation Specification Operation Signature Input Signature Preselection Operation Specification Operation Specification Potential Operation Occurrence [diff matches] [no diff match] Derive Precondition Binding Precondition Binding Evaluate Binding Operation Specification Operation Specification Valid Precondition Binding [invalid] Derive Postcondition Binding Postcondition Binding [invalid] [valid] [valid] Refactoring Occurrence Refactoring Occurrence Operation Occurrence «foreach» «foreach» Operation Occurrence Evaluate Binding Diff Model Preprocessing

1 2 3

Operation Detection: Phase 3

75

Composite operation detection process

Operation Specifications

DVo●Vr1/2 DVo●Vr1/2

cop

Where do operation specifications come from?

slide-76
SLIDE 76

Operation Specifications

76

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
slide-77
SLIDE 77

Operation Specifications

77

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
Concrete Syntax Abstract Syntax Student 1 examiner

*

examinee Professor name Professor:Class name:Property name:Property name Student:Class examiner:Property examinee:Property examines examines:Assoc
slide-78
SLIDE 78

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

Preconditions Actions Postconditions Operation Specification

Can also be used as selectors. Can also be used for computing target values.

slide-79
SLIDE 79

MTBD Example: Introduce Composite State

79

Idle DialTone Dialing lift dial dial hang_up hang_up Active Idle DialTone lift dial dial hang_up Dialing
  • Introduce Active
  • Change target of lift
  • Introduce new initial state
  • Introduce transition initial to DialTone
  • Change source of one hang_up transition
  • Remove all other hang_up transtitions
  • Move states into Active
slide-80
SLIDE 80

MTBD Process

80

Overview

Wizard Initial model Working model Create initial model Copy initial model Performupdates State-based comparison Diff model Imply conditions Edit conditions Conditions

[implied]

Generate OSM Operation Specification Model Revised model Conditions

[revised]

Generate specific artifacts Refactoring Wizard

Modeling Configuration & Generation

… 1 2 3 5 4 6 7 8

automatic manual

Legend

slide-81
SLIDE 81

MTBD Process

81

Step 1: Create Initial Model

Wizard Initial model Working model Create initial model Copy initial model Performupdates State-based comparison Diff model Imply conditions Edit conditions Conditions

[implied]

Generate OSM Operation Specification Model Revised model Conditions

[revised]

Generate specific artifacts Refactoring Wizard

Modeling Configuration & Generation

… 1 2 3 5 4 6 7 8

automatic manual

Legend

Outside IntoStart JustInto toFold toFold start Outside CompositeState IntoStart JustInto toFold start

Model elements, which are… Required for execution Handled differently

slide-82
SLIDE 82

MTBD Process

82

Step 2: Copy Initial Model

Wizard Initial model Working model Create initial model Copy initial model Performupdates State-based comparison Diff model Imply conditions Edit conditions Conditions

[implied]

Generate OSM Operation Specification Model Revised model Conditions

[revised]

Generate specific artifacts Refactoring Wizard

Modeling Configuration & Generation

… 1 2 3 5 4 6 7 8

automatic manual

Legend

Unique IDs preserve relationship

slide-83
SLIDE 83

MTBD Process

83

Step 3: Perform updates

Wizard Initial model Working model Create initial model Copy initial model Performupdates State-based comparison Diff model Imply conditions Edit conditions Conditions

[implied]

Generate OSM Operation Specification Model Revised model Conditions

[revised]

Generate specific artifacts Refactoring Wizard

Modeling Configuration & Generation

… 1 2 3 5 4 6 7 8

automatic manual

Legend

Outside CompositeState IntoStart JustInto toFold start

Illustrate composite operation

slide-84
SLIDE 84

MTBD Process

84

Step 4: State-based Comparison

Wizard Initial model Working model Create initial model Copy initial model Performupdates State-based comparison Diff model Imply conditions Edit conditions Conditions

[implied]

Generate OSM Operation Specification Model Revised model Conditions

[revised]

Generate specific artifacts Refactoring Wizard

Modeling Configuration & Generation

… 1 2 3 5 4 6 7 8

automatic manual

Legend

State-based Comparison

  • Inputs: Initial and Revised Model
  • No editor-specific change tracking
  • Any editor applicable
slide-85
SLIDE 85

MTBD Process

85

Step 5: Imply Conditions

Wizard Initial model Working model Create initial model Copy initial model Performupdates State-based comparison Diff model Imply conditions Edit conditions Conditions

[implied]

Generate OSM Operation Specification Model Revised model Conditions

[revised]

Generate specific artifacts Refactoring Wizard

Modeling Configuration & Generation

… 1 2 3 5 4 6 7 8

automatic manual

Legend

Generic Condition Generation

  • Initial model  preconditions
  • Revised model  postconditions
  • Act as a basis for the next step
Outside IntoStart JustInto toFold toFold start
  • Outside : SingleState_0
  • name = “Outside”
  • incoming->includes(#{Transition_1})
  • …
  • IntoStart : SingleState_1
  • toFold : Transition_1
  • event = “toFold”
  • target = #{SingleState_0}
  • …
slide-86
SLIDE 86

MTBD Process

86

Step 5: Imply Conditions

Wizard Initial model Working model Create initial model Copy initial model Performupdates State-based comparison Diff model Imply conditions Edit conditions Conditions

[implied]

Generate OSM Operation Specification Model Revised model Conditions

[revised]

Generate specific artifacts Refactoring Wizard

Modeling Configuration & Generation

… 1 2 3 5 4 6 7 8

automatic manual

Legend

Generic Condition Generation

  • Initial model  preconditions
  • Revised model  postconditions
  • Act as a basis for the next step
Outside IntoStart JustInto toFold toFold start
  • …
  • IntoStart : SingleState_1
  • toFold : Transition_1
  • event = “toFold”
  • target = #{SingleState_0}
  • …
  • JustInto : StingleState_2
  • toFold : Transition_2
  • event = #{Transition_1}.name
==
slide-87
SLIDE 87

MTBD Process

87

Step 6: Edit Conditions

Wizard Initial model Working model Create initial model Copy initial model Performupdates State-based comparison Diff model Imply conditions Edit conditions Conditions

[implied]

Generate OSM Operation Specification Model Revised model Conditions

[revised]

Generate specific artifacts Refactoring Wizard

Modeling Configuration & Generation

… 1 2 3 5 4 6 7 8

automatic manual

Legend

Configuration

  • Relax (deactivate conditions)
  • Enforce (activate conditions)
  • Modify (change conditions)
  • Augment iterations and user inputs

Default configuration: Relaxing

  • String features and
  • Values which are empty and null
slide-88
SLIDE 88

MTBD Process

88

Step 7 and Step 8

Wizard Initial model Working model Create initial model Copy initial model Performupdates State-based comparison Diff model Imply conditions Edit conditions Conditions

[implied]

Generate OSM Operation Specification Model Revised model Conditions

[revised]

Generate specific artifacts Refactoring Wizard

Modeling Configuration & Generation

… 1 2 3 5 4 6 7 8

automatic manual

Legend

slide-89
SLIDE 89

MTBD: Tooling

  • Eclipse Modeling Operations (EMO)
  • http://www.modelversioning.org/index.php?option=com_content&view=arti

cle&id=68&Itemid=89

89

Initial Model Revised Model Preconditions Postconditions Diff Model & Annotations
slide-90
SLIDE 90

Operation-based Conflict Detection

90

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
  • Output: Conflict model

DVo●Vr1 DVo●Vr2 CV1●Vr2

cop cop
slide-91
SLIDE 91

Atomic Operation-based Conflict Detection

91

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 * FeatureChange DeleteUpdate UpdateUpdate 2 conflicts DeleteMove MoveMove DeleteObject Move 1 1 1 1 1 delete delete use move update update move 2 DeleteUse
slide-92
SLIDE 92

Atomic Operation-based Conflict Detection

92

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
do: DeleteObject
  • : Object
  • bject
value fc : FeatureChange du: DeleteUse delete use

S1 S2 S1 S1 S2 Example Pattern

slide-93
SLIDE 93

Atomic Operation-based Conflict Detection

93

Conflict Pattern 2: Delete/Update Conflict

  • Delete/Update conflict occurs if
  • Modeler A deletes object o
  • Modeler B updates a feature f of object o

There are several more patterns!

do: DeleteObject fc : FeatureChange
  • : Object
  • bject
changed Object du: DeleteUpdate delete update

Pattern S1_1 Example S1

  • 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;
Reviewer: G. Kappel, J. Gray; E188 Institut für Softwaretechnik und Interaktive Systeme, 2011.
slide-94
SLIDE 94

Composite Operation Conflict Detection

94

  • For each composite operation application,
  • check whether it is applicable at the opposite side
Vo Vr1 Vr2

DVo●Vr1

cop

cop1..i

Vo Vr1 Vr2

DVo●Vr2

cop

cop1..i

slide-95
SLIDE 95

Composite Operation Conflict Detection

95

  • Example
Idle DialTone Dialing hangup lift hangup dial Vo Vr2 Idle DialTone Dialing abort lift hangup dial dial Idle DialTone Dialing hangup lift dial Active dial Vr1

Introduce Composite State Rename hangup

slide-96
SLIDE 96

Composite Operation Conflict Detection

96

  • Example
Idle DialTone Dialing hangup lift hangup dial Vo Vr2 Idle DialTone Dialing abort lift hangup dial dial Idle DialTone Dialing hangup lift dial Active dial Vr1

Introduce Composite State

SingleState_0 Transition_1 Transition_2 Transition_0 SingleState_1 SingleState_2 Original match SingleState_0 Transition_1 Transition_2 Transition_0 SingleState_1 SingleState_2

Precondition of composite

  • peration is

violated!

Transition_1.name = Transition_2.name

DVo●Vr1

cop

Rename hangup

slide-97
SLIDE 97

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

slide-98
SLIDE 98

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

slide-99
SLIDE 99

Conflict-tolerant Merge Rules

99

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
slide-100
SLIDE 100

Conflict-tolerant Merge Rules

100

Example: Update-update Conflict

  • Update-update Conflict
f1 = x
  • 1:Object
f1 = y f1 = x <<UpdateUpdate>>
  • -Involved Elements
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
… Origin Version created by USER_A Merged Version Update by USER_B
  • 1:Object
  • 1:Object
Update by USER_C f1 = z
  • 1:Object
Employee bday V1 Employee birthday V1a Employee doB V1b Employee bday V2 <<UpdateUpdate>>
slide-101
SLIDE 101

Conflict-tolerant Merge Rules

101

Example: Delete-update Conflict

  • Delete-update Conflict
f1 = x
  • 1:Object
f1 = y f1 = y <<DeleteUpdate>>
  • -Involved Elements
Upd_feature = {f1} Upd_value = {y} Old_value ={x}
  • -User-related Metadata
User_del = USER_C User_upd = USER_B Owner = USER_A
  • -Time related Metadata
… Origin Version created by USER_A Merged Version Update by USER_B
  • 1:Object
  • 1:Object
Delete by USER_C Car color V2 <<DeleteUpdate>> Car color V1a V1b Car V1
slide-102
SLIDE 102

Conflict Annotations

102

Using Annotations in the Merged Model for Marking Conflicts

  • Annotate conflicts in the merged model
  • For visualizing conflicts
  • For providing a basis for resolution

 On top of the concrete syntax of the merged model

  • Annotations can be stored across revisions
  • Allows to tolerate conflicts for a while
  • Enables distributing them among team members
  • Lightweight annotations using profiles (cf. UML Profiles)
  • Model elements are annotated by stereotypes in concrete syntax
  • Tagged values comprise additional conflict information
slide-103
SLIDE 103

Conflict Annotations

103

Profile for Merge Conflicts

Model children container rootElement 1 0..1 * Change affectedElement 1 * changedBy Conflict Violation UpdateUpdate DeleteUpdate Annotation annotations * DeleteUse DeleteMove Warning MoveUpdate Update Delete Insert Move MetaInfo * metaInfo ModelElement * Use MoveMove UseUpdate UseMove
slide-104
SLIDE 104

Conflict Annotations

104

Example Apply conflict-tolerant merge rules Annotate conflicts (i.e., apply conflict profile)

slide-105
SLIDE 105

Conflict Annotations

105

Applied Conflict Profile

slide-106
SLIDE 106

Conflict Annotations

106

Applied Conflict Profile

  • How can profiles be applied to non-UML models?

EMF Profiles

slide-107
SLIDE 107

Overall Goal of EMF Profiles

107

  • UML Profiles: A Short Reminder
  • Lightweight Language Extension Mechanism of the UML
  • A Profile consists of Stereotypes
  • Stereotypes extend base classes
  • And may introduce “tagged values”
  • Profiles are applied to UML models
  • By applying stereotypes to instances of their base classes
  • Specifying concrete values for their defined “tagged values”

“Adopt the notion of UML Profiles to DSMLs residing in EMF”

slide-108
SLIDE 108

UML Profiles: A Short Introduction

108

Profile specification Profile application

«profile» EJB

«enumeration» StateKind stateless stateful

UserModel

«apply» «SessionBean» Customer state=stateless Component «stereotype» Bean «stereotype» EntityBean «stereotype» SessionBean state: StateKind «metaclass»

slide-109
SLIDE 109

Motivation

  • Overall goal
  • “Adopt the notion of UML Profiles to DSMLs residing in EMF”
  • Is combination of profiles with DSMLs a contradiction?
  • Many debates on Pros and Cons of adopting UML Profiles or DSMLs

109

slide-110
SLIDE 110

UML Profiles vs DSMLs

110

Reuse UML’s language concepts and existing UML editors! Create a lean language that is straight to the point! You’ll end up with an overloaded and imprecise language! You’ll have to create the whole infrastructure by yourself!

slide-111
SLIDE 111

UML Profiles vs DSMLs

111

These debates concern adopting either UML Profiles or DSMLs for creating new languages. What about extending existing languages?

It’s your language… just extend your metamodel.

slide-112
SLIDE 112

Motivating Scenario

112

Data Modeling Language

Meta model Concrete Syntax Editor

… generates Ruby on Rails. … generates JavaServer Faces. … generates DB Schema.

I want to additionally specify “Finder SQL” statements! I want to additionally specify the bean scope! Leave it as it is! If you introduce every imaginable feature that I don’t need, I could have used UML in the first place.

slide-113
SLIDE 113

Motivating Scenario

113

Data Modeling Language

Meta model Concrete Syntax Editor

… generates Ruby on Rails. … generates JavaServer Faces. … generates DB Schema.

I want to additionally specify “Finder SQL” statements! I want to additionally specify the bean scope! Leave it as it is! If you introduce every imaginable feature that I don’t need, I could have used UML in the first place.

You need a lightweight extension mechanism: Profiles! Other scenarios

  • No influence on the metamodel
  • “Concern-specific” annotations

I can’t address all your requirements!

slide-114
SLIDE 114

Benefits of Profiles for DSMLs

  • Lightweight language extension
  • Introduce additional features
  • No need for changing the metamodel and the modeling infrastructure
  • Dynamic model extension
  • Existing models can be extended; even by multiple profiles and stereotypes
  • Profile applications are separated from the models ( no model pollution)
  • Preventing metamodel pollution
  • Metamodels represent only information coming from the modeling domain
  • Concern-specific information is defined in a profile
  • Model-based representation
  • Profile applications are well-defined ( they can be validated)
  • Profile applications are just additional models ( reuse existing

frameworks)

114

slide-115
SLIDE 115

The Challenge

115

Okay, so let’s use profiles! But wait, that’s not so easy with EMF!

M3 UML

Core Profiles

«import»

M2 M1

UML aProfile

«instanceOf» «instanceOf» «instanceOf» «instanceOf»

aUML Model aProfile Application

«extend» «extend»

EMF

Ecore Profile MM

«instanceOf»

aProfile

«instanceOf»

aProfile Application

«instanceOf»
slide-116
SLIDE 116

Solution: Metalevel Lifting by Inheritance

116

M3 M2 M1

Profile Definition Metalevel Lifting by Inheritance

Ecore Profile MM

« instanceOf »

aProfile

« instanceOf »
slide-117
SLIDE 117

Solution: Metalevel Lifting by Inheritance

117

M3 M2 M1

Profile Definition Metalevel Lifting by Inheritance

Ecore Profile MM

« instanceOf »

aProfile

« instanceOf » « inheritsFrom »
slide-118
SLIDE 118

Solution*: Metalevel Lifting by Inheritance

118

M3 M2 M1

Profile Definition Metalevel Lifting by Inheritance

Ecore Profile MM

« instanceOf »

aProfile

« instanceOf »

aProfile Application

« inheritsFrom » « instanceOf »

* There is an alternative solution as well (i.e., transformation to a model at M2).

slide-119
SLIDE 119

EMF Profile Metamodel

119

Profile iconPath : EString Stereotype Profile Ecore abstract: EBoolean eSuperTypes : EClass … EClass nsURI : EString eClassifiers : EClassifier … EPackage base 1 base 0..* Standard EMF Profile ProfileApplication ProfileApplication 0..* appliedTo : EObject StereotypeApplication stereotype Applications «import»
slide-120
SLIDE 120

EMF Profile Metamodel and its Instantiation

120

Profile iconPath : EString Stereotype Profile Ecore abstract: EBoolean eSuperTypes : EClass … EClass nsURI : EString eClassifiers : EClassifier … EPackage base 1 base 0..* Standard EMF Profile ProfileApplication ProfileApplication 0..* appliedTo : EObject StereotypeApplication : Stereotype : EAttribute name=“isStateful” eAttributes

A Profile Specification

: Profile eClassifiers : EClass base name=“Entity” stereotype Applications name=“SessionBean” «import»
slide-121
SLIDE 121

EMF Profile Metamodel and its Instantiation

121

Profile iconPath : EString Stereotype Profile Ecore abstract: EBoolean eSuperTypes : EClass … EClass nsURI : EString eClassifiers : EClassifier … EPackage base 1 base 0..* Standard EMF Profile ProfileApplication ProfileApplication 0..* appliedTo : EObject StereotypeApplication : Stereotype : EAttribute name=“isStateful” eAttributes

A Profile Specification

eSuperTypes name=“SessionBean” «onSave» : Profile eClassifiers : EClass base name=“Entity” stereotype Applications «import»
slide-122
SLIDE 122

122

EMF Profile Metamodel and its Instantiation

Profile iconPath : EString Stereotype Profile Ecore abstract: EBoolean eSuperTypes : EClass … EClass nsURI : EString eClassifiers : EClassifier … EPackage base 1 base 0..* Standard EMF Profile ProfileApplication ProfileApplication 0..* appliedTo : EObject StereotypeApplication : Profile : Stereotype : EAttribute name=“isStateful” eClassifiers eAttributes

A Profile Specification

eSuperTypes name=“SessionBean” : EClass base

A Profile Application

: ProfileApplication : SessionBean name=“Entity” : Entity appliedTo stereotype Applications stereotype Applications isStateful=true «instanceOf» «instanceOf» «instanceOf» «import» «instanceOf» «instanceOf» «instanceOf»
slide-123
SLIDE 123

123

EMF Profile Metamodel and its Instantiation

Profile iconPath : EString Stereotype Profile Ecore abstract: EBoolean eSuperTypes : EClass … EClass nsURI : EString eClassifiers : EClassifier … EPackage base 1 base 0..* Standard EMF Profile ProfileApplication ProfileApplication 0..* appliedTo : EObject StereotypeApplication : Profile : Stereotype : EAttribute name=“isStateful” eClassifiers eAttributes

A Profile Specification

eSuperTypes name=“SessionBean” : EClass base

A Profile Application

: ProfileApplication : SessionBean name=“Entity” : Entity appliedTo stereotype Applications stereotype Applications isStateful=true «instanceOf» «instanceOf» «instanceOf» «import» «instanceOf»

M3 M3 M2 M2 M2 M1 M1

«instanceOf» «instanceOf»

M1

slide-124
SLIDE 124

124

EMF Profile Metamodel and its Instantiation

Profile iconPath : EString Stereotype Profile Ecore abstract: EBoolean eSuperTypes : EClass … EClass nsURI : EString eClassifiers : EClassifier … EPackage base 1 base 0..* Standard EMF Profile ProfileApplication ProfileApplication 0..* appliedTo : EObject StereotypeApplication : Profile : Stereotype : EAttribute name=“isStateful” eClassifiers eAttributes

A Profile Specification

eSuperTypes name=“SessionBean” : EClass base

A Profile Application

: ProfileApplication : SessionBean name=“Entity” : Entity appliedTo stereotype Applications stereotype Applications isStateful=true «instanceOf» «instanceOf» «instanceOf» «import» «instanceOf»

M3 M3 M2 M2 M2 M1 M1 M1/2 M2/3

«instanceOf» «instanceOf»

M1

slide-125
SLIDE 125

Example: EJB Profile Specification

125

slide-126
SLIDE 126

Example: EJB Profile Application

126

slide-127
SLIDE 127

From UML Profiles to EMF Profiles and Beyond

  • UML Profiles can be specified for UML only

 No need for further reuse of profiles for other languages

  • EMF Profiles can be specified for every Ecore-based language

 Reuse a profile for more than one language

  • Generic Profiles
  • Reuse a profile for several “user-selected” DSMLs
  • Meta Profiles
  • Reuse a profile for all DSMLs

127

slide-128
SLIDE 128

Generic Profiles

  • Reuse a profile for several “user-selected” DSMLs
  • Extend generic types instead of concrete types
  • Bind generic types to concrete types to apply a profile
  • Use OCL to further restrict valid bindings

128

name : EString «generictype» Container «stereotype» EntityBean isUserManaged : EBoolean «stereotype» IDAttribute «stereotype» SessionBean isStateful : EBoolean «generictype» Property <<profile>> EJB Container, Property ER «bind» <Container->Entity, Property->Attribute> Entity Attribute 0..* name : String name : String ER Entity Attribute 0..* name : String name : String ER Entity Attribute 0..* name : String name : String
slide-129
SLIDE 129

Meta Profiles

  • Reuse a profile for all DSMLs (at once)
  • Each “Meta Stereotype” may be applied to every base type
  • Useful for general annotations
  • E.g., Conflict Profile
<<meta-stereotype>> Conflict <<meta-profile>> Conflict Profile <<meta-metaclass>> EClass <<meta-stereotype>> DeleteUpdate … <<meta-stereotype>> … …

129

slide-130
SLIDE 130

Implementation

  • Based on the Eclipse Modeling Framework
  • Supports extending every Ecore-based DSML
  • Uses the Decoration Service to show icons in GMF editors
  • Open Source (EPL 1.0)
  • http://code.google.com/a/eclipselabs.org/p/emf-profiles/
  • Try EMF Profiles!
  • Eclipse Update Site

http://www.modelversioning.org/emf-profiles-updatesite/

  • Contact us and get involved!
  • http://groups.google.com/group/emf-profiles

130

slide-131
SLIDE 131

State-based Conflict Detection

131

Validate of the Result from Conflict-tolerant Merging

  • General well-formedness rules are covered by conflict patterns already
  • Unique container
  • No cyclic containments
  • But, language-specific validation rules need to be checked
  • Lower/upper bound of multi-valued features
  • Additional OCL Constraints
  • Therefore, after conflict-tolerant merging,

the resulting state is validated

  • If a constraint is invalid

 New state-based conflict annotation

  • Reuse EMF validation framework
  • Annotate context elements of reported errors/warnings
slide-132
SLIDE 132

Resolution

132

  • Dedicated conflict resolution view
  • Based on the conflict-tolerant merge result and the conflicts annotations
  • Allows to…
  • … resolve conflicts manually (e.g., use this change or that change)
  • … resolve conflicts by predefined resolution rules
  • Resolutions can be attached to a conflict annotation
  • Lifecycle of a conflict
  • Conflicts have a state (e.g., open or resolved)
  • Cf. next slide
slide-133
SLIDE 133

Resolution

133

Conflict Resolution Model: The Lifecycle of Conflicts

Model children container rootElement 1 0..1 * Change affectedElement 1 * changedBy Annotation annotations * MetaInfo * metaInfo ModelElement * prioritizedChange 0..* conflictingChange 2..* 0..* 0..1 Diff 0..1 XOR customResolution 1..* proposed Resolution Resolution proposed Resolution User assignedTo state : ConflictState
  • pen
resolution proposed deferred reopen resolved assigned Modeler takes possession Ownership is changed Accept resolution Reject resolution Modeler elaborates resolution Modeler deferes working
  • n the conflict
Modeler elaborates resolution Conflict Lifecycle Conflict
slide-134
SLIDE 134

Example: Conflict-tolerant Merging Improves the Result

134

Issues of Current Versioning/Resolution Protocol

Car Employee type name bday V1 Alice Car Employee carType color name birthday V1a Harry Car Employee name doB V1c

*

type engine Joe Employee name birthday carType color V2 Sally Employee name bday type V1b Sally Model stored in the Repository

Car as part of

  • ne

Employee One class for efficient querying One car for several employees

Delete/Update Conflict!

1 1 1
slide-135
SLIDE 135

Example: Conflict-tolerant Merging Improves the Result

135

Issues of Current Versioning/Resolution Protocol

Car Employee type name bday V1 Alice Car Employee carType color name birthday V1a Harry Car Employee name doB V1c

*

type engine Joe Employee name birthday carType color V2 Sally Employee name bday type V1b Sally Car Employee name doB color V3

*

engine Joe carType

Delete/Update Conflict! Update/Update Conflict!

1 1 1 1 Model stored in the Repository
slide-136
SLIDE 136

Example: Conflict-tolerant Merging Improves the Result

Result of Conflict-tolerant Merge

Car Employee type name bday V1 Alice Car Employee carType color name birthday V1a Harry Car Employee name doB V1c

*

type engine Joe Employee name bday type V1b Sally Car Employee color name birthday carType V2 Car Employee name bday carType V3

*

color engine

1 2 1 2 6 4 5

Delete/Update Delete/Update Violation Delete/Update Update/Update Model stored in the Repository 1 1 1 1 1

3

Move/Update Warning

3

136

slide-137
SLIDE 137

Example: Conflict-tolerant Merging Improves the Result

Collaborative Resolution based on Conflict-tolerant Merge

Car Employee name doB

*

color engine

1 2 6 4

Delete/Update Delete/Update Violation Delete/Update Update/Update bday

Result of Standard Versioning Process

Sally Joe Harry Alice carType 5

3

Move/Update Warning birthday Car Employee name doB color V3

*

engine Joe 1

137

slide-138
SLIDE 138

Semi-Automated Resolution

138

  • Conflict Resolution Recommender
  • For increasing efficiency and avoiding errors
  • Conflict Resolution Patterns
  • Preconditions defined for
  • the merged model
  • the applied changes
  • the annotated conflicts
  • Actions
  • Operations to be applied to resolve the conflict
  • Formally defined using graph transformation systems
slide-139
SLIDE 139

Example: Resolution Recommender

139 Pull Up Field Add class “SoccerM”

Event Concert artist Exhibition artist Event artist Concert Exhibition Event Concert artist Exhibition artist Event artist Concert Exhibition SoccerM SoccerM

The preconditions

  • f the refactoring

“Pull Up Field” are violated! AddForbid(SoccerM)

slide-140
SLIDE 140

Example: Resolution Recommender

140

Event artist Concert Exhibition SoccerM

The preconditions

  • f the refactoring

“Pull Up Field” are violated! AddForbid(SoccerM) Resolve AddForbid(SoccerM) by introducing intermediate class?

Event #UserInput artist SoccerM Concert Exhibition Conflict Resolution Patterns
slide-141
SLIDE 141

Outline

141

  • Context of Model Versioning
  • Foundations of Model Versioning
  • Conflict Categorization
  • Adaptable Model Versioning
  • Future Challenges
slide-142
SLIDE 142

Future Challenges

142

Consistency-aware Versioning

  • Consistency rules, e.g.
  • Metamodel
  • OCL Constraints
  • Requirement documents
  • Additional models
  • Merged model violates consistency rules

even if both versions are consistent  Trace back to the relevant changes causing the violation

V0 V1 V2 :A :B t t+1 :A :B t t+1 :A :B t t+1 :A :B t t+1 V3 Lopez-Herrejon, R.E., & Egyed, A. (2010). Detecting Inconsistencies in Multi-View Models with Variability.
  • Proc. of the European Conference on Modelling Foundations and Applications (ECMFA), Springer, 217-232.
slide-143
SLIDE 143

Future Challenges

143

Intention-aware Versioning

  • Merged version should incorporate all

intentions of each modeler  Treat composite operations such as model refactorings as first-class entities  Going beyond composite operations: E.g., a set of operations has been applied in order to fix a bug… is the bug still fixed after merging?  Other ways to capture and respect the intention?

V0 V1 V2 Assistent Professor Researcher getLectures() Assistent getLectures() Professor getLectures() Researcher ProjectAss Assistent Professor Researcher getLectures() getLectures() Dig, D., Manzoor, K., Johnson, R., & Nguyen, T.N. (2007). Refactoring-aware Configuration Management for Object-oriented Programs. Proc. of the 29th International Conference on Software Engineering (ICSE), IEEE Computer Society, 427-436.
slide-144
SLIDE 144

Future Challenges

144

Semantics-aware Versioning

  • Model differencing only on syntactic level

 Formal definition of the modeling language’s semantics  Mapping between modeling language and semantic domain  Including intra-model dependencies

V0 V1 V2 A1 A2 B A1 A2 B A1 A2 B

Different syntax, equal semantics

Nejati, S., Sabetzadeh, M., Chechik, M., Easterbrook, S., & Zave, P. (2007). Matching and Merging of Statecharts
  • Specifications. Proc. of the 29th International Conference on Software Engineering (ICSE), IEEE, 54-64.
Maoz, S., Ringert, J.O., & Rumpe, B. (2010). A Manifesto for Semantic Model Differencing. Proc. of the International Workshop on Models and Evolution (ME2010) @ MoDELS’10.
slide-145
SLIDE 145

Future Challenges

145

Conflict Dependencies

  • Dependencies between a sequence of changes
  • Leading to dependencies between conflicts

 Efficient detection between more complex changes like refactorings

  • r violations

 Optimal order for resolving conflicts

Delete(z) Add(x) Move(y x) Update(z) Delete(y)

d d i d…dependent i…independent c…conflicting c c Koegel M, Herrmannsdoerfer M, Wesendonk O., & Helming J. (2010). Operation-based Conflict Detection on
  • Models. Proc. of the International Workshop on Model Comparison in Practice (IWMCP) @ TOOLS’10.
Küster, J., Gerth, C., & Engels, G. (2009). Dependent and Conflicting Change Operations of Process Models. Proceeding of the Conference on Model Driven Architecture - Foundations and Applications, vol. 5562 of LNCS, Springer, 158-173.
slide-146
SLIDE 146

Future Challenges

146

Diagram Versioning

  • Co-evolution of diagram layout information with the model
  • Existing approaches neglect the nature of 2D diagram layout

 Which concurrently performed layout change is in fact a contradicting change of the layout (more fuzziness required than for models)?  Respect the preservation of mental map when merging diagram changes!

Ohst, D., Welle, M. & Kelter, U. (2003). Differences Between Versions of UML Diagrams. Proc. of the 9th European Software Engineering Conference, ACM, 227-236. Mehra, A., Grundy J.C., & Hosking, J.G. (2005). A Generic Approach to Supporting Diagram Differencing and Merging for Collaborative Design. Proc. of the 20th International Conference on Automated Software Engineering, ACM, 204-213.
slide-147
SLIDE 147

Future Challenges

147

  • Pessimistic versioning and Synchronous modeling not always desirable

 Avoid conflicts through awareness

 Notification when modelers work on the same model fragment(!)

 Model partitioning

 How to separate a model?  Find appropriate mechanisms for separation of concerns techniques

Avoiding Conflicts

slide-148
SLIDE 148

Future Challenges

148

Model/Code Versioning

  • Roundtrip Engineering
  • Synchronizing models and code
  • Problem of inconsistencies when changing models and code in parallel
  • Especially when changes are not on the same granularity level
  • Using models for versioning large code repositories
  • In case several conflicts between different versions occur
Estublier, J., Leveque, T., & Vega, G. (2010). Evolution Control in MDE Projects: Controlling Model and Code Co-evolution. Proc. of the Conference on Fundamentals of Software Engineering (FASE), Springer, 431-438.
slide-149
SLIDE 149

149

slide-150
SLIDE 150

The AMOR Team

150

  • Gerti Kappel
  • Martina Seidl
  • Manuel Wimmer
  • Petra Brosch
  • Philip Langer
  • Konrad Wieland
slide-151
SLIDE 151

These Slides are Based on the Following Papers (1/2)

151

  • P. Brosch:
Conflict Resolution in Model Versioning; Reviewer: G. Kappel, A. Pierantonio; E188 Institut für Softwaretechnik und Interaktive Systeme, to appear 2012.
  • P. Brosch, P. Langer, M. Seidl, K. Wieland, M. Wimmer, G. Kappel:
The Past, Present, and Future of Model Versioning; in: "Emerging Technologies for the Evolution and Maintenance of Software Models", IGI Global, 2011, ISBN: 9781613504383, 410 - 443.
  • P. Brosch, G. Kappel, M. Seidl, K. Wieland, M. Wimmer, H. Kargl, P. Langer: Adaptable Model Versioning in Action.
  • Proc. of the Modellierung, GI, 221-236.
  • P. Brosch, H. Kargl, P. Langer, M. Seidl, K. Wieland, M. Wimmer, G. Kappel:
Conflicts as First-Class Entities: A UML Profile for Model Versioning; in: "Models in Software Engineering - Workshops and Symposia at MODELS 2010, Reports and Revised Selected Papers", Lecture Notes in Computer Science Volume 6627, Springer, 2011, ISBN: 978-3-642-21209-3, 184 - 193
  • P. Brosch, P. Langer, M. Seidl, K. Wieland, M. Wimmer, G. Kappel:
Concurrent Modeling in Early Phases of the Software Development Life Cycle. Proc. of the 16th Collaboration Researchers' International Working Group Conference on Collaboration and Technology (CRIWG), Springer, 129-144.
  • G. Kappel, P. Langer, W. Retschitzegger, W. Schwinger, M. Wimmer:
Model Transformation By-Example: A Survey of the First Wave; in: "Conceptual Modelling and Its Theoretical Foundations", Springer LNCS, Berlin / Heidelberg, 2012, (invited), ISBN: 978-3-642-28278-2, 197 - 215.
  • P. Brosch, P. Langer, M. Seidl, K. Wieland, M. Wimmer, G. Kappel, W. Retschitzegger, W. Schwinger:
An Example Is Worth a Thousand Words: Composite Operation Modeling By-Example; 12th International Conference
  • n Model Driven Engineering Languages and Systems (MoDELS'09), Denver, USA; in: "Proc. of the 12th International
Conference on Model Driven Engineering Languages and Systems (MoDELS'09)", Springer, LNCS 5795 (2009), ISBN: 978-3-642-04424-3; 271 - 285.
slide-152
SLIDE 152

These Slides are Based on the Following Papers (2/2)

152

  • P. Langer:
Adaptable Model Versioning based on Model Transformation By Demonstration; Reviewer: G. Kappel, J. Gray; E188 Institut für Softwaretechnik und Interaktive Systeme, 2011.
  • P. Langer, M. Wimmer, G. Kappel:
Model-to-Model Transformations By Demonstration; in: "Proc. of the 3rd International Conference on Model Transformation (ICMT 2010)", Springer, LNCS 6142, 2010, ISBN: 978-3-642-13687-0, 153 - 167.
  • P. Langer, K. Wieland, M. Wimmer, J. Cabot:
From UML Profiles to EMF Profiles and Beyond; 49th International Conference on Objects, Models, Components, Patterns (TOOLS) 2011, Zürich; in: "Proc. of the 49th International Conference on Objects, Models, Components, Patterns (TOOLS) 2011", Springer, LNCS 6705 (2011), 52 - 67.
  • B. Meyers, M. Wimmer, A. Cicchetti, J. Sprinkle:
A generic in-place transformation-based approach to structured model co-evolution; in: "Proc. of the 4th International Workshop on Multi-Paradigm Modeling (MPM'10) @ MoDELS'10", 2010, 13 pages.
  • 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.
  • K. Wieland:
Conflict-tolerant Model Versioning; Reviewer: G. Kappel, G. Fitzpatrich; E188 Institut für Softwaretechnik und Interaktive Systeme, 2011.
  • M. Wimmer, A. Kusel, J. Schönböck, W. Retschitzegger, W. Schwinger, G. Kappel:
On using Inplace Transformations for Model Co-evolution; in: "Proc. of the 2nd International Workshop on Model Transformation with ATL (MtATL 2010)", INRIA & Ecole des Mines de Nantes, 2010, 14 pages.
slide-153
SLIDE 153

References and Further Reading (1/4)

153

  • Alanen, M., & Porres, I. (2003). Difference and Union of Models. Proc. of the Conference on the Unified Modeling Language
(UML), volume 2863 of LNCS, Springer, 2-17.
  • Altmanninger K., Seidl M., & Wimmer, M. (2009). A Survey on Model Versioning Approaches. International Journal of Web
Information Systems, 5(3), 271-304.
  • Apiwattanapong, T., Orso, A., & Harrold, M.J. (2007). JDiff: A differencing technique and tool for object-oriented programs.
Automated Software Engineering, 14(1), 3-36.
  • Balzer, R. (1989). Tolerating Inconsistency. Proc. of the 5th Int. Software Process Workshop (ISPW), IEEE Computer Society, 41-
42.
  • Barrett, S., Chalin, P., & Butler, G. (2008). Model Merging Falls Short of Software Engineering Needs. Proc. of the 2nd Workshop
  • n Model-Driven Software Evolution @ MoDELS’08.
  • Chikofsky, E., & Cross, J.H. (1990). Reverse Engineering and Design Recovery: A Taxonomy. IEEE Software, 7, 13-17.
  • Cicchetti, A., Ruscio, D.D., & Pierantonio, A. (2008). Managing Model Conflicts in Distributed Development. Proc. of the 11th
International Conference on Model Driven Engineering Languages and Systems (MoDELS), volume 5301 of LNCS, Springer, 311- 325.
  • Conradi, R., & Westfechtel, B. (1998). Version Models for Software Configuration Management. ACM Computing Surveys, 30(2),
232-282.
  • De Lucia A., Fasano F., Oliveto R., & Tortora G. (2006). ADAMS: ADvanced Artefact Management System. Proc. of the 10th
European Conference on Software Maintenance and Reengineering, IEEE, 349-350.
  • Dewan, P., & Hegde, R. (2007). Semi-synchronous conflict detection and resolution in asynchronous software development. Proc.
  • f the 10th European Conference on Computer-Supported Cooperative Work, Springer, 159–178.
  • Dewan, P., & Riedl, J. (1993). Toward Computer-Supported Concurrent Software Engineering. IEEE Computer, 26(1), 17–27.
  • Dig, D., Manzoor, K., Johnson, R., & Nguyen, T.N. (2007). Refactoring-aware Configuration Management for Object-oriented
  • Programs. Proc. of the 29th International Conference on Software Engineering (ICSE), IEEE Computer Society, 427-436.
  • Dig, D., Manzoor, K., Johnson, R., & Nguyen, T.N. (2008). Effective Software Merging in the Presence of Object-Oriented
  • Refactorings. IEEE Transactions on Software Engineering, 34(2), 321-335.
slide-154
SLIDE 154

References and Further Reading (2/4)

154

  • Edwards, W.K. (1997). Flexible Conflict Detection and Management in Collaborative Applications. Proc. of the ACM Symposium
  • n User Interface Software and Technology, 139-148.
  • Estublier, J., Leblang, D., van der Hoek, A., Conradi, R., Clemm, G., Tichy, W., & Wiborg-Weber, D. (2005). Impact of Software
Engineering Research on the Practice of Software Configuration Management. ACM Transactions on Software Engineering and Methodology, 14(4), 383-430.
  • Estublier, J., Leveque, T., & Vega, G. (2010). Evolution Control in MDE Projects: Controlling Model and Code Co-evolution. Proc.
  • f the Conference on Fundamentals of Software Engineering (FASE), Springer, 431-438.
  • Finkelstein, A., Gabbay, D.M., Hunter, A., Kramer, J., & Nuseibeh, B. (1994). Inconsistency Handling in Multiperspective
  • Specifications. IEEE Trans. on Software Engineering, 20(8), 569-578.
  • Ghezzi, C., Jazayeri, M., & Mandrioli, D. (2002). Fundamentals of Software Engineering. Prentice Hall PTR, 2002.
  • Harel, D., & Rumpe, B. (2004). Meaningful Modeling: What's the Semantics of "Semantics"?. Computer, 37(10), IEEE, 64-72.
  • Herrmannsdoerfer, M., Benz, S., and Juergens, E. (2009). COPE - Automating Coupled Evolution of Metamodels and Models. In
  • Proc. of the 23rd European Conference on Object-Oriented Programming (ECOOP'09), pages 52-76. Springer-Verlag.
  • Hunt, J.W., & McIllroy, M.D. (1976). An Algorithm for Differential File Comparison. Technical Report 41, AT&T Bell Laboratories
Inc.
  • Khuller, S., & Raghavachari, B. (1999). Graph and network algorithms. ACM Computing Surveys, 28(1), 43-45.
  • Kim, M., & Notkin, D. (2006). Program Element Matching for Multi-version Program Analyses. Proc. of the 2006 International
Workshop on Mining Software Repositories (MSR '06), ACM.
  • Koegel M, Herrmannsdoerfer M, Wesendonk O., & Helming J. (2010). Operation-based Conflict Detection on Models. Proc. of the
International Workshop on Model Comparison in Practice (IWMCP) @ TOOLS’10.
  • Kolovos, D.S., Ruscio, D.D., Pierantonio, A. & Paige R.F. (2009). Different Models for Model Matching: An Analysis of Approaches
to Support Model Differencing. Proc. of the International Workshop on Comparison and Versioning of Software Models, IEEE.
  • Küster, J., Gerth, C., & Engels, G. (2009). Dependent and Conflicting Change Operations of Process Models. Proceeding of the
Conference on Model Driven Architecture - Foundations and Applications (MDAFA), volume 5562 of LNCS, Springer, 158-173.
  • Lin, Y., Gray, J. & Jouault F. (2007). DSMDiff: A Differentiation Tool for Domain-specific Models. European Journal on Information
Systems, 6, 349-361.
slide-155
SLIDE 155

References and Further Reading (3/4)

155

  • Lippe, E., & Florijn, G. (1991). Implementation Techniques for Integral Version Management. Proc. of the European Conference on
Object Oriented Programming (ECOOP), 342-359.
  • Lippe, E., & van Oosterom, N. (1992). Operation-based Merging. Proc. of the 5th ACM SIGSOFT Symposium on Software
Development Environments (SDE), ACM, 78-87.
  • Lopez-Herrejon, R.E., & Egyed, A. (2010). Detecting Inconsistencies in Multi-View Models with Variability. Proc. of the European
Conference on Modelling Foundations and Applications (ECMFA), Springer, 217-232.
  • Lucia, A., Fasano, F., Scanniello, G. & Tortora, G. (2009). Concurrent Fine-Grained Versioning of UML Models. Proc. of the
European Conference on Software Maintenance and Reengineering, IEEE, 89-98.
  • Maoz, S., Ringert, J.O., & Rumpe, B. (2010). A Manifesto for Semantic Model Differencing. Proc. of the International Workshop on
Models and Evolution (ME2010) @ MoDELS’10.
  • Mehra, A., Grundy J.C., & Hosking, J.G. (2005). A Generic Approach to Supporting Diagram Differencing and Merging for
Collaborative Design. Proc. of the 20th IEEE/ACM International Conference on Automated Software Engineering (ASE), ACM, 204-213.
  • Mens, T. (2002). A State-of-the-Art Survey on Software Merging. IEEE Transactions on Software Engineering, 28(5), 449-462.
  • Mens, T. (2008). Introduction and Roadmap: History and Challenges of Software Evolution. In Software Evolution, Springer, 1-11.
  • Misue, K., Eades, P., Lai, W., & Sugiyama, K. (1995). Layout Adjustment and the Mental Map. Journal of Visual Languages &
Computing, 6(2), 183-210.
  • Murta, L., Corrêa, C., Prudêncio, J.G., & Werner, C. (2008). Towards Odyssey-VCS 2: Improvements over a UML-based version
control system. Proc. of the International Workshop on Comparison and Versioning of Software Models (CVSM) @ ICSE’08, ACM, 25–30.
  • Nejati, S., Sabetzadeh, M., Chechik, M., Easterbrook, S., & Zave, P. (2007). Matching and Merging of Statecharts Specifications.
  • Proc. of the 29th International Conference on Software Engineering (ICSE), IEEE, 54-64.
  • Nuseibeh, B., Easterbrook, S.M., & Russo, A. (2001). Making Inconsistency Respectable in Software Development. Journal of
Systems and Software, 58(2), 171-180.
  • Oda, T. & Saeki, M. (2005). Generative Technique of Version Control Systems for Software Diagrams. Proc. of the 21st IEEE
International Conference on Software Maintenance (ICSM), IEEE Computer Society, 515-524.
  • Ohst, D., Welle, M. & Kelter, U. (2003). Differences Between Versions of UML Diagrams. Proc. of the 9th European Software
Engineering Conference, ACM, 227-236.
  • Oliveira H., Murta L. & Werner C. (2005). Odyssey-VCS: A Flexible Version Control System for UML Model Elements. Proc. of the
12th International Workshop on Software Configuration Management, ACM, 1-16.
slide-156
SLIDE 156

References and Further Reading (4/4)

156

  • Reiter, T., Altmanninger, K., Kotsis, G., Schwinger, W., & Bergmayr, A. (2007). Models in Conflict - Detection of Semantic Conflicts
in Model-based Development. Proc. of the 3rd International Workshop on Model-Driven Enterprise Information Systems (MDEIS) @ ICEIS’07, 29-40.
  • Schmidt, D.C. (2006). Guest Editor's Introduction: Model-Driven Engineering. IEEE Computer, 39(2), 25-31.
  • Schneider, C., Zündorf, A. & Niere, J. (2004). CoObRA - A Small Step for Development Tools to Collaborative Environments. In
  • Proc. of the Workshop on Directions in Software Engineering Environments.
  • Schwanke, R.W., & Kaiser, G.E. (1988). Living With Inconsistency in Large Systems. Proc. of the Workshop on Software Version
and Configuration Control, pp. 98-118.
  • Sun, Y., White, J., and Gray, J. (2009). “Model Transformation by Demonstration,” International Conference on Model Driven
Engineering Languages and Systems (MoDELS), Springer-Verlag LNCS 5795, Denver, CO, October 2009, pp. 712-726.
  • Tichy, W.F. (1988). Tools for software configuration management. Proc. of the International Workshop on Software Version and
Configuration Control, J. F. H. Winkler, Ed., Teubner Verlag, 1–20.
  • UML 2.3 Standard (2010), OMG Unified Modeling Language (OMG UML) Superstructure, Version 2.3,
http://www.omg.org/spec/UML/2.3/
  • Westfechtel, B. (1991). Structure-Oriented Merging of Revisions of Software Documents. Proc. of the Third International Workshop
Software Configuration Management (SCM), 68-79.
  • Westfechtel, B. (2010). A Formal Approach to Three-Way Merging of EMF Models. Proc. of the 1st International Workshop on
Model Comparison in Practice (IWMCP), ACM, 31-41.