Model Inconsistency Management by means of Graph Transformation Dependency Analysis Tom Mens (tom.mens@umh.ac.be) Institut d Informatique Université de Mons-Hainaut Belgium
Acknowledgements This talk reports on joint work with Maja D Hondt LIFL, Université des Sciences et des Technologies de Lille Ragnhild Van Der Straeten Universität Paderborn / Vrije Universiteit Brussel Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 2
Challenge: Model-driven evolution Observation Model-driven software engineering approaches do not adequately address software evolution problems Need better support (tools, formalisms) for Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 3
Model inconsistency management Goal Specify model inconsistencies and their resolution strategies as graph transformation rules Use this formalisation to support the inconsistency management process Automate the detection of inconsistencies Interactively support the resolution of inconsistencies Analyse transformation dependencies to optimise this process Detect sequential dependencies between resolution rules Detect parallel conflicts between resolution rules that cannot be applied together Remove redundancy between resolution rules Provide optimal resolution strategies Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 4
Model inconsistency management Inconsistency management process inconsistency detection rules? inconsistency resolution rules? UML model detect inconsistencies in UML model select inconsistencies to be resolved choose inconsistency resolution strategy apply inconsistency resolutions annotate model with inconsistencies found modify model by selected resolution rules (may give rise to new inconsistencies) Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 5
Experiment Use AGG (version 1.4), a general-purpose graph transformation language specify the metamodel as a type graph specify the models as graphs detect model inconsistencies by means of graph transformation rules resolve model inconsistencies by means of graph transformation rules detect parallel conflicts and sequential dependencies between inconsistency resolutions by means of critical pair analysis Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 6
Step 1: Specify the metamodel AGG type graph Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 7
Example of a model inconsistency Dangling operation reference Using UML notation Using graph notation contains Class name= ATM isabstract=false Operation name= ejectcard visibility= public nuofpars=0 isabstract=false instanceof Operation name= retaincard visibility= public nuofpars=0 isabstract=false calls InstanceSpecification ConnectableElement represents Interaction LifeLine contains contains represents MessageEvent MessageOccurrenceSpecification Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 8
Step 2: Identify model inconsistencies Dangling Type Reference Classless Instance Abstract Object Abstract Operation Abstract State Machine Cyclic Composition Dangling Operation Reference Transition Without Operation An operation has one or more parameters whose types are not specified A model contains an instance specification that is not linked to a class A model contains an instance specification that is an instance of an abstract class that does not have any concrete subclasses. An abstract operation is defined in a concrete class. A state machine expresses the behaviour of an abstract class that does not have any concrete subclasses. A class contains at least one instance of its subclasses through a composition relationship that may lead to an infinite containment of instances of the affected classes. A state machine contains a transition that refers to an operation that does not belong to any class (or that belongs to a different class than the one whose behaviour is expressed by the state machine). A transition does not have a referred operation attached to it. Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 9
Example of a model inconsistency Dangling operation reference Using UML notation Using graph notation contains Class name= ATM isabstract=false Operation name= ejectcard visibility= public nuofpars=0 isabstract=false instanceof Operation name= retaincard visibility= public nuofpars=0 isabstract=false calls InstanceSpecification ConnectableElement represents Interaction LifeLine contains contains represents MessageEvent MessageOccurrenceSpecification Conflict description= dangling operation reference Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 10
Step 3: Detect model inconsistencies Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 11
Step 3: Detect model inconsistencies Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 12
Step 4: Identify inconsistency resolutions Dangling Type Reference Res1 Res2 Res3 Remove the parameter whose type is undefined. Assign an existing class as the type of the previously undefined parameter. Assign a new class as the type of the previously undefined parameter. Classless Instance Abstract Object Res1 Res2 Res3 Res1 Res2 Res3 Res4 Remove the instance specification. Link the instance specification to an existing class. Link the instance specification to a new class. Change the abstract class into a concrete one. Add a concrete descendant of the abstract class, and redirect the outgoing instance-of relation of the instance specification to this concrete descendant. Remove the instance specification. Add a concrete descendant class of the abstract class. Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 14
Step 5: Resolve model inconsistencies Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 15
Step 6: Detect parallel conflicts between resolution rules Some resolution rules cannot be jointly applied (parallel conflict!) Conflict graph can be generated in AGG by means of critical pair analysis Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 16
Step 6: Detect parallel conflicts Example of a critical pair representing a conflict situation Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 17
Step 7: Detect sequential dependencies Some resolution rules may give rise to new opportunities for applying other resolution rules Dependency graph generated by critical pair analysis Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 18
Step 7: Detect sequential dependencies Example of a critical pair representing a sequential dependency Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 19
Step 7: Detect sequential dependencies Some resolution rules may give rise to new model inconsistencies Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 20
Step 8: Refactor resolution rules Observation Different resolution rules for the same model inconsistency may be redundant Different resolution rules for a different model inconsistency may be redundant (even identical) Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 21
Step 8: Refactor resolution rules Dangling Type Reference Classless Instance redundancy Abstract Object Res1 Res2 Res3 Res1 Res2 Res3 Res1 Res2 Res3 Res4 Remove the parameter whose type is undefined. Assign an existing class as the type of the previously undefined parameter. Assign a new class as the type of the previously undefined parameter. Remove the instance specification. Link the instance specification to an existing class. Link the instance specification to a new class. Change the abstract class into a concrete one. Add a concrete descendant of the abstract class, and redirect the outgoing instance-of relation of the instance specification to this concrete descendant. Remove the instance specification. Add a concrete descendant class of the abstract class. Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 22
Step 8: Refactor resolution rules Dangling Type Reference redundancy Classless Instance redundancy Abstract Object Res1 Res2 Res3 Res1 Res2 Res3 Res1 Res2 Res3 Res4 Remove the parameter whose type is undefined. Assign an existing class as the type of the previously undefined parameter. Assign a new class as the type of the previously undefined parameter. Remove the instance specification. Link the instance specification to an existing class. Link the instance specification to a new class. Change the abstract class into a concrete one. Add a concrete descendant of the abstract class, and redirect the outgoing instance-of relation of the instance specification to this concrete descendant. Remove the instance specification. Add a concrete descendant class of the abstract class. Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 23
Step 8: Refactor resolution rules Goal (Future Work!) Detect redundancy automatically Based on the computed conflicts and dependencies between resolution rules Remove redundancy automatically Refactor the resolution rules Transform (i.e., refactor) the transformation rules - Transformations need to be first class models - Reflective transformation engine is needed Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 24
Tool Support Integrate ideas into a modeling tool Ongoing student project export UML models from MagicDraw into AGG, detect and resolve inconsistencies in AGG, and import back into MagicDraw Ongoing student project Add interface on top of AGG to provide interactive support for selecting and resolving inconsistencies based on detected conflicts and dependencies Future work Integrate current work into existing RACOON tool for model inconsistency management (based on description logics) Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 25
Discussion topics Optimality Expressiveness Completeness Compositionality Termination Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 26
Discussion topics Optimality Find an optimal way to resolve model inconsistencies How can we define optimality? Use heuristics and resolution strategies, locally as well as globally Avoid resolution rules that introduce too many new inconsistencies Prefer resolution rules that add new model elements over rules that remove model elements Take into account, and learn, resolution rules preferred by the user other strategies? Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 27
Discussion topics Expressiveness Can all model inconsistencies be expressed? Which types of model inconsistency can be expressed? Structural? Behavioural? Can all resolution rules be expressed? Completeness Are all possible ways to resolve a particular inconsistency covered by the resolution rules? Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 28
Discussion topics Compositionality How to define resolution strategies as a composition of primitive resolution rules? Using sequencing, branching, looping constructs Taking into account the computed dependency analysis Termination Given a set of resolution rules, can we prove that it will resolve all detected inconsistencies and terminate in a finite amount of time? Rely on termination results of graph transformation? Tom Mens, Atelier sur l évolution du logiciel, Nîmes, 21 Mars 2006 29