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- ons, 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 of 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 operations 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 specifies actual kind of the kind 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 or 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 our 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!
Recommend
More recommend
