Formal Support for Model Evolution

Transcription

1 Formal Support for Model Evolution Tom Mens Software Engineering Lab University of Mons-Hainaut Belgium

2 Introduction - Model Evolution More and better tool support needed for model evolution Formalisms can be helpful for some of these tools Description logics Graph transformation Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 2

3 Model Inconsistency Management Using Description Logics joint work with Ragnhild Van Der Straeten Vrije Universiteit Brussel

4 Model Inconsistency Management Model consistency ensuring that all models/software artifacts are consistent internal consistency of each model mutual consistency between different models consistency maintenance is essential especially in the context of co-evolution where different models may evolve in parallel examples evolution of class diagrams, sequence diagrams and state diagrams evolution of design models and source code Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 4

5 Model Transformation Dimensions Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 5

6 Classification of Inconsistencies Specification specification conflicts Specification - instance conflicts Instance - instance conflicts Behavioural Invocation inconsistency Observation inconsistency Incompatible definition Invocation inconsistency Observation inconsistency Incompatible behaviour inconsistency Structural Dangling type reference Inherited association inconsistency Role specification missing Instance specification missing Disconnected model Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 6

7 Description Logics Decidable two-variable fragment of first-order predicate logics Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 7

8 Description Logics: TBox and ABox Terminological Knowledge (TBox) TBox reasoning Concept satisfiability Concept subsumption mechanism ABox Assertions a : C (a, b) : R ABox reasoning ABox satisfiability instantiation testing Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 8

9 DL versus FOL (1) [ESSLI02] Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 9

10 DL versus FOL (2) [ESSLI02] Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 10

11 Metamodel translation Direct correspondence of UML metamodel and DL concepts classes concepts associations roles attributes roles ore concrete domain attributes (primitive types) inheritance subsumption and transitive closure Manual translation of UML metamodel (define-primitive-role allattribute :domain classifier :range property :inverse owningclassifier :parent featuremembers) (implies-role redefinedattribute redefinitioncontext) (define-primitive-role ownedattribute :domain class :range property :inverse owningclass :parents(ownedmember allattribute)) (implies-role owningclass redefinedattribute) (implies property (and structuralfeature (some definedtype (or class primitivetype)))) (define-primitive-role ownedoperation :domain class :range operation :inverse ownedclass :parents(featuremembers ownedmember)) Automatic translation of UML models Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 11

12 Model translation Automatic translation of UML models Class diagrams (instance atm class) (instance printingatm class) (instance asciiprintingatm class) (instance gen1 generalization) (instance gen2 generalization) (instance controls association) (instance atmend property) (instance asciiend property) (related atm gen1 generalization) (related printingatm gen1 generalization) (related printingatm gen2 generalization) (related asciiprintingatm gen2 generalization) (related atm printingatm direct-superclass) (related printingatm asciiprintingatm direct-superclass) (related gen1 atm general) (related gen2 printingatm general) (related atm asciiend ownedattribute) Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 12

13 Model translation Automatic translation of UML models Sequence diagrams (define-concept m1 (and (all op checkifcashavailable) (exactly 1 op))) (define-concept m2 (and (all op ejectcard) (exactly 1 op)))) (define-concept m3 (and (all op dispensecash) (exactly 1 op))) (implies m1 (some r m2)) (implies m2 (some r m3)) (implies m3 (some r m4)) Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 13

14 Model translation Automatic translation of UML models State-transition diagrams (define-concept t1 (and (all op verifyaccount) (exactly 1 op))) (define-concept t2 (and (all op checkifcashavailable) (exactly 1 op))) (define-concept t3 (and (all op dispensecash) (exactly 1 op))) (define-concept t4 (and (all op ejectcard) (exactly 1 op))) (equivalent (and (some valid_pin) t1) (some r t2))) (equivalent t2 (some r t3)) (equivalent t3 (some r t4)) Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 14

15 Model Inconsistency Management Internal consistency of ATM 1.0 Refinement consistency between ATM 1.0 and its subclass CardChargingATM 1.1 Behavioural preservation between CardChargingATM versions 1.2 and 1.3 Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 15

16 Exemple Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 16

17 Model Inconsistency Management Internal consistency of ATM 1.0 class each sequence of the ATM sequence diagram is contained in the set of call sequences of the ATM state machine diagram Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 17

18 Model Inconsistency Management Internal consistency of ATM 1.0 class each sequence of the ATM sequence diagram is contained in the set of call sequences of the ATM state machine diagram Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 18

19 Model Inconsistency Management Refinement consistency behavioural consistency between class ATM 1.0 and its subclass CardChargingATM 1.1 each sequence of the ATM 1.0 sequence diagram should be contained in the set of sequences of the CardChargingATM 1.1 state machine diagram Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 19

20 Model Inconsistency Management Refinement consistency [Ebert&Engels 1997] Observation inheritance consistency each sequence of calls which is observable with respect to a subclass must result (under the projection of the methods known) in an observable sequence of its corresponding superclass. Invocation inheritance consistency any sequence of operations invocable on the superclass can also be invoked on the subclass. Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 20

21 Model Inconsistency Management Evolution consistency Refactoring of CardChargingATM version 1.2 to 1.3 should preserve behaviour Observation call preservation each sequence of calls which is observable with respect to a refactored class must result (under the projection of the methods known) in an observable sequence of its original class. Invocation call preservation any sequence of operations invocable on the original class can also be invoked on the refactored class. Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 21

22 Model Inconsistency Management Evolution consistency Refactoring state machine of CardChargingATM version 1.2 to CardChargingATM version 1.3 should preserve behaviour Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 22

23 Model Inconsistency Management Evolution consistency Refactoring state machine of CardChargingATM version 1.2 to CardChargingATM version 1.3 should preserve behaviour Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 23

24 Model Inconsistency Management Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 24

25 Model Refactoring Using Graph Transformation joint work with Gabi Taentzer Technical University of Berlin

26 Model Refactoring with Graph transformation Graph transformation theory offers many theoretical results that can help during analysis of model refactorings type graph, negative application conditions, parallel and sequential (in)dependence, confluence and critical pair analysis Graph transformation tools allow us to perform concrete experiments AGG (in collaboration with Berlin) Current focus Analysing dependencies between class diagram refactorings Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 26

27 Model Refactoring with Graph transformation Concrete Scenario: Suggest refactoring opportunities What are the alternatives of a selected refactoring? Which other refactorings need to be applied first in order to make the selected refactoring applicable? Which other refactorings are still applicable after applying the selected refactoring? Goal: Automate the detection of mutual exclusion relationships between refactorings sequential dependencies between refactorings Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 27

28 Model Refactoring with Graph transformation Example Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 28

29 Model Refactoring with Graph transformation Refactoring opportunities T1 Rename Method print in PrintServer to process T2 Rename Method save in FileServer to process T3 Create Superclass Server for PrintServer and FileServer T4 Pull Up Method accept from PrintServer and FileServer to Server T5 Move Method accept from PrintServer to Packet T6 Move Method accept from FileServer to Packet T7 Encapsulate Variable receiver in Packet T8 Add Parameter p of type Packet to method print in PrintServer T9 Add Parameter p of type Packet to method save in FileServer Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 29

30 Model Refactoring with Graph transformation T1 T2 T3 T4 T5 T6 T7 T8 T9 T1 >> T2 >> T3 T4 T5 T6 T7 T8 T9 Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 30

31 Model Refactoring with Graph transformation Approach: Use critical pair analysis in AGG T 1 and T 2 form a critical pair if they can both be applied to the same initial graph G but applying T 1 prohibits application of T 2 and/or vice versa T 1 G H 1 T 2 X T 2 H 2 T 1 X Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 31

32 Model Refactoring with Graph transformation Step 1: Express object-oriented metamodel as (attributed) type graph Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 32

33 Model Refactoring with Graph transformation Step 2: Express refactorings as (typed attributed) graph transformations Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 33

34 Model Refactoring with Graph transformation Step 3: Detect critical pairs between refactoring transformations Potential conflicts between refactorings Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 34

35 Model Refactoring with Graph transformation Step 4: Fine-tune critical pairs in context of concrete input graph Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 35

36 Model Refactoring with Graph transformation Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 36

37 Model Refactoring with Graph transformation Step 5: Perform sequential dependency analysis To identify dependencies between refactorings that are applicable Tom Mens, 18/4/2005, Dagstuhl, Transformation Techniques in Software Engineering 37