A Declarative Evolution Framework for ObjectOriented Design Patterns

A Declarative Evolution Framework for Object-Oriented Design Patterns Tom Mens Tom Tourwé {tom. mens | tom. tourwe}@vub. ac. be Programming Technology Lab Vrije Universiteit Brussel

Overview Ø Introduction to design patterns Ø Specification of design patterns and their instances Ø Evolution of design pattern instances Ø Evolution conflicts Ø Tool support Ø Conclusion Ø Future work ICSM 2001, Firenze, November 2001 © Programming Technology Lab 2

Design patterns Ø Offer successful and proven solutions for a design problem that occurs over and over again Ø Improve understandability, maintainability, extensibility, reusability, etc. Ø Are used in most object-oriented frameworks Ø Gain increasing popularity Ø Impose specific structure on implementation Ø Define hot spots of an object-oriented framework Ø Dictate relationships and collaborations between a set of classes/methods ICSM 2001, Firenze, November 2001 © Programming Technology Lab 3

Example: Observer instance in MVC Model View dependents changed update Pluggable. List. View. Of. Many Pluggable. List. View. By. Item update ICSM 2001, Firenze, November 2001 © Programming Technology Lab 4

Pattern specification and constraint definition Use declarative meta programming pattern. Instance(MVC, Observer. DP). declarative role(MVC, observer, [View]). role(MVC, concrete. Observer, [Pluggable. List. View. By. Item]). specification of the design pattern role(MVC, concrete. Observer, [Pluggable. List. View. Of. Many). instance role(MVC, subject, [Model]). role(MVC, update. Method, [#update]). role(MVC, change. Method, [#changed]) pattern. Constraint(? instance, Observer. DP) if role(? instance, subject, ? subject), role(? instance, change. Method, ? changeselector), role(? instance, update. Method, ? updateselector), concrete. Method(? subject, ? changeselector), calls(? subject, ? changeselector, ? updateselector) ICSM 2001, Firenze, November 2001 © Programming Technology Lab declarative constraint imposed by the design pattern on every instance 5

Automated transformations Ø Refactorings Ø High-level structural transformations that can be applied to a framework in a behavior-preserving way Ø E. g. , extract. Superclass, add. Parameter Ø Design Pattern Refactorings Ø Refactorings specific for a particular design pattern Ø Are composed of a number of ordinary refactorings Ø Applied to design pattern instances Ø Make sure the constraints imposed by the pattern are adhered to Ø E. g. , add. Concrete. Observer, add. Update. Method Ø All refactorings are specified declaratively ICSM 2001, Firenze, November 2001 © Programming Technology Lab 6

Example evolutions View Model update: a. Symbol changed: Pluggable. List. View. Of. Many extract. Superclass refactoring Pluggable. List. View. By. Item Pluggable. List add. Change. Method design pattern refactoring update: a. Symbol update role(MVC, change. Method, Pluggable. List. View. Of. Many [#changed: ]). role(MVC, update. Method, [#update: ]). ICSM 2001, Firenze, November 2001 update: a. Symbol Pluggable. List. View. By. Item © Programming Technology Lab 7

Evolution conflicts Ø Changes to the software Ø Applied manually Ø insufficient knowledge of design patterns (instances) can lead to violation of constraints Ø Via automated (design pattern) refactorings Ø problems when changes by different developers must be merged Ø Structural merge conflicts Ø Behavioural merge conflicts Ø All conflicts can be detected using a declarative approach ICSM 2001, Firenze, November 2001 © Programming Technology Lab 8

Structural merge conflict View Model update: a. Symbol changed: update and update: are implemented differently! Pluggable. List update Pluggable. List. View. Of. Many update: a. Symbol ICSM 2001, Firenze, November 2001 Pluggable. List. View. By. Item update: a. Symbol © Programming Technology Lab 9

Constraint violations View Model update: a. Symbol changed: QSOULPluggable. List. View update Pluggable. List update: a. Symbol Problems with QSOULPluggable. List. View (1) it does not implement update: (2) it is no subclass of Pluggable. List. View. Of. Many ICSM 2001, Firenze, November 2001 © Programming Technology Lab Pluggable. List. View. By. Item 10

Declarative conflict detection Ø Explicitly log all refactorings applied and the software entities they work on Ø Compare them one by one Ø Different changes to one and the same software entity may lead to a conflict extract. Superclass add. Change. Method View Pluggable. List. View PLVBy. Item PLVOf. Many update View ICSM 2001, Firenze, November 2001 PLVBy. Item PLVOf. Many update: changed: © Programming Technology Lab same hierarchy same role 11

Tool Support Ø Specification facilities Ø User-friendly interface on top of declarative medium Ø Browsing facilities Ø All software entities (classes/methods/…) that participate in a given DP instance Ø All DP instances in which a given software entity (class/method/…) participates Ø Support for evolution and merging Ø Offer list of refactorings that can be applied Ø Provide warnings for possible conflicts Ø Suggest solutions where possible ICSM 2001, Firenze, November 2001 © Programming Technology Lab 12

Tool Support ICSM 2001, Firenze, November 2001 © Programming Technology Lab 13

Conclusion Ø Automated support for software evolution Ø Through disciplined evolution of design pattern instances used in the framework Ø Via explicit declarative specification and automated transformation of those instances Ø Detection of evolution conflicts Ø Structural & behavioural conflicts; constraint violation Ø Using explicit high-level knowledge of the design and its evolution ICSM 2001, Firenze, November 2001 © Programming Technology Lab 14

Future Work Ø Extensive validation on industrial cases Ø Tool support & integration in existing IDEs Ø Scalability of the approach Ø Allow for different design pattern variants Ø Many design patterns exist & new ones are constantly discovered Ø Metapatterns as an abstraction of design patterns Ø Formal basis for conflict detection Ø Define conditions under which particular conflicts occur Ø Requires formalisation of metapatterns ICSM 2001, Firenze, November 2001 © Programming Technology Lab 15