Comparing State Machines Udo Kelter , Maik Schmidt Software - - PowerPoint PPT Presentation

Comparing State Machines

Udo Kelter, Maik Schmidt Software Engineering Group University of Siegen, Germany

{kelter, mschmidt}@informatik.uni-siegen.de

17.05.2008

Introduction / Difference / Merge Tools for Models 2

1 Introduction

1.1 Difference / Merge Tools for Models

Main tasks and related issues:

• 1. compare models, compute a difference

→ should consider document-type-specific semantics → ideally: consider user-defined preferences

• 2. display a difference

→ chose external representation of a difference

• 3. merge models interactively, based on a displayed difference

→ detect conflicts

Introduction / State Models 3

1.2 State Models

• conceptually based on a finite state automaton
• additional (UML-) concepts such as nested states oder regi-
• ns, history states, flow control features etc.
• domain-/vendor-specific models: Matlab/Simulink, ASCET

significant overlap with UML activity diagrams Reference in this talk: UML2 State Machines

Introduction / Intricacies With Differencing State Models 4

1.3 Intricacies With Differencing State Mo- dels

• 1. complex structure of state models

→ sub-optimal design of the standard meta-models → Part 3 of this talk

• 2. non-uniqueness of a difference

→ finding a good (an “optimal”) difference between two state models is a more significant problem → Part 4 of this talk

Background / Displaying Differences 5

2 Background

2.1 Displaying Differences

Basic approaches of how to display a difference between two graph-structured diagrams:

• 1. complete differences
• a. parallel (side by side) display of complete diagrams
• b. use unified, “pre-merged” diagram (common parts once)
• 2. local differences
• complete difference split up into local differences
• display one local difference at a time

Background / Informal Definitions of a Difference 6

2.2 Informal Definitions of a Difference

• 1. a difference is a good, easily understandable description of

how two documents differ i.e. why and how they are not identical

• 2. a difference is the output of a differencing tool

(such as UNIX diff), considered on a conceptual level

Formal Definitions of a Difference / Set-oriented Approach 7

2.3 Formal Definitions of a Difference

2.3.1 Set-oriented Approach

• assumption: a model (or diagram) is considered as a set of

identifiable model elements.

• conceptual basis of parallel display and unified display

A symmetric difference consists of

• 1. a set of correspondences

(for the common parts)

• 2. two inserting transformations

(for the specific parts)

Formal Definitions of a Difference / Set-oriented Approach 8

correspondence: a pair of model elements, one from each mo- del, which are considered as corresponding (“the same”) “common parts” of the diagrams: model elements involved in a correspondence “specific parts”: the remaining model elements inserting transformation: sequence of edit steps which crea- te the specific parts of a diagram on the basis of the common parts edit data type: an abstract data type (or interface) which defines the operations used in inserting transformations

Formal Definitions of a Difference / Transformational Approach 9

2.3.2 Transformational Approach An asymmetric difference is a transformation from D1 to D2, in which abritrary edit operations are admitted. can make use of complex edit operations, notably moving of (groups of) diagram elements; pros and cons:

• shorter (“better”) transformations, compared with converted

symmetric difference

• more difficult to optimize
• can only be displayed textually or using local differences

(1 editing step = 1 local difference)

Background / Edit Operations and the Representations of Models 10

2.4 Edit Operations and the Representations

• f Models

Assumption: models / diagrams considered as a typed abstract syntax graph, based on a metamodel (defined by the UML, ...., MDD frame- works, ..), which consists of:

• metaclasses and metaassociations: define the types of nodes

and edges of the ASG

• context-sensitive OCL constraints

Background / Edit Operations and the Representations of Models 11

typical approach: the edit data type = elementary graph ope- rations in the abstract syntax graph works fine in 95% of the cases, however ...

• some details of metamodels are questionable and lead to
• perations do not make sense
• elementary graph operations can lead to intermediate incor-

rect states

Metamodel-Related Issues / Pseudo States 12

3 Metamodel-Related Issues

3.1 Pseudo States

UML pseudo state types: initial, deep / shallow history, join, fork, junction, choice, entry point, exit point, terminate, and final are modelled as:

• one metaobject type for final states
• one metaobject type for all other pseudo states,

enumeration attribute kind specifies actual kind of the pseudo state type

Metamodel-Related Issues / Pseudo States 13

Metamodel-Related Issues / Pseudo States 14

a difference computation can find

• two corresponding pseudo states
• with different values in kind → attribute change
• actually a conversion

Problems:

• 1. some display formats cannot display both state symbols
• 2. different syntactical constraints for different pseudo states

any model would break some of the constraints, either before

• r after a conversion!

→ edit data type must assume a very reduced level of cor- rectness of the models

• 3. most conversions are not useful for explaining the difference

Metamodel-Related Issues / Pseudo States 15

Metamodel-Related Issues / Pseudo States 16

3.2 External and Local Transitions

Transitions are modeled by one object type (Transition) with enumeration attribute kind (external, internal, local) how to “interpret” modifications of these attributes? (= con- versions of transitions)

• as a side-effect of a change of the target state of a transition

with complex triggers (same state → other state, or vice versa)

• other reasonable edit manoeuvres

→ complex edit operations (1 user command) = several elemen- tary changes

Optimization of Differences / Non-Uniqeness of Differences 17

Problems:

• most display formats cannot handle complex edit operations
• drastically changed graphical representation

Conclusions:

• the edit data type should rather not contain conversions of

transitions

• i.e. difference must not contain a correspondence between

two transitions with different values in the attribute kind

Optimization of Differences / Non-Uniqeness of Differences 18

4 Optimization of Differences

4.1 Non-Uniqeness of Differences

at the risk of boring you to death: (similarity-based) differences between models / diagrams are not unique easiest example: duplicated model elements → alternatives for forming correspondences further alternatives for forming inserting transformations choose the best difference → optimization problem

Optimization of Differences / Block Moves Between Regions 19

4.2 Block Moves Between Regions

Optimization of Differences / Block Moves Between Regions 20

similar cases in all diagram types with nested block structures block moves are a much better understandable than deletions and insertions, however:

• they are complex operations

→ asymmetric difference → restricted choice of display formats (local differences)

• connections into the environment can be changed

should be considered as explicitly deleted / inserted

Optimization of Differences / Modifications Of The Flow Structure 21

4.3 Modifications Of The Flow Structure

Alternative differences:

• 1. delete t1, t2, choice state;

create t3;

• 2. move source end of t2

from choice state to s1; delete t1, and choice state;

• 3. move target end of t1

from choice state to s2; delete t2, and choice state;

Optimization of Differences / Modifications Of The Flow Structure 22

... more complex examples with transition paths Which difference is the best one? depends on:

• working context
• the taste of developers
• ur experience: mostly case 3 (treats outgoing transitions as

more relevant for a node) Anyway: users should have the choice, tool should offer alter- natives

Optimization of Differences / Assessing and Optimizing Differences 23

4.4 Assessing and Optimizing Differences

A more theoretical approach:

• define a quality measure for differences (more correspon-

dences are better ...)

• construct all non-trivially different differences (“candida-

tes”), compute the quality of each, choose the best one Deficiencies:

• large set of candidates → significant workload
• quality measure can only approximate user’s taste and pre-

ferences

Optimization of Differences / Assessing and Optimizing Differences 24

A pragmatic approach:

• no explicit construction of candidates

use “biased similarity specifications” to improve quality

• support user feedback, enable users to correct differences /

specify presettings: – negative: wrong correspondences – positive: desired correspondences this feature is a must for merge tools!

Summary and Conclusion 25

5 Summary and Conclusion

Subject of this paper: difference and merge tools for state ma- chines etc.; computation and display of differences The messages:

• 1. different forms of display use different notions of a difference
• 2. the edit data type can mostly be based on elementary graph
• perations on the abstract syntax graph, but not always
• 3. parts of the UML metamodels are inappropriate
• 4. optimization of differences (e.g. using move operations) and

support of user preferences are a problem

• 5. efficient optimization via biased similarities

Summary and Conclusion 26

Thank you for your attention & patience! – any questions??