Egon Borger (Pisa) Capturing Design Pattern Abstractions by ASMs Universita di Pisa, Dipartimento di Informatica, I-56127 Pisa, Italy boerger@di.unipi.it visiting SAP Research, Karlsruhe, Germany egon.boerger@sap.com Copyright c 2005 Egon Borger, Dipartimento di Informatica, Universita di Pisa, Pisa, Italy. 1
Goal Overall goal: identify high-level modeling patterns { with concrete instantiations supported by the ASM renement method First experiment: model characteristic object-oriented design patterns by ASMs { lifting them where possible from the programming-centric to a modeling view Reference: E. Gamma, R. Helm, R. Johnson, J. Vlissides Addison-Wesley, 1994 etc. Design Patterns Copyright c 2005 Egon Borger, Dipartimento di Informatica, Universita di Pisa, Pisa, Italy. 2
Traditional classication of design patterns by purpose: { structural patterns concerning composition of classes and objects { creational patterns concerning creation of objects at class instantiation { behavioral patterns concerning interaction of classes and objects (ow of control, actions, communication and cooperation) by scope: { class patterns dealing with static (compile-time relevant) composition of (sub)classes (inheritance, accessibility, use relations) { object patterns dealing with dynamic composition of run-time objects Copyright c 2005 Egon Borger, Dipartimento di Informatica, Universita di Pisa, Pisa, Italy. 3
Classication of patterns by their abstraction mechanism Renement of abstract (sub)machines or operations by a more detailed machine, which may be an implementation { Examples: Template Method, Memento, Observer, Iterator Parameterization of (sub)machines or operations by implicit arguments for the current agent (class instance) { Structural examples: Bridge, Proxy, ObjectAdapter, Decorator { Behavioral examples: Strategy, Visitor, State Run-time association of agents to actions { Examples: Chain of Responsibility, Command Copyright c 2005 Egon Borger, Dipartimento di Informatica, Universita di Pisa, Pisa, Italy. 4
Iterator Pattern: Specic Machine Renements `provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation'[ghjv94:pg.257] Iterator `denes an interface for accessing and traversing elements' { curritem:aggregateitem location with values in underlying AggregateItem structure, to `keep track of the current position in the traversal of the aggregate' { First, Next yielding values in AggregateItem functions (operations, machines) on underlying AggregateItem structure, possibly with additional parameters optionally also Previous, SkipTo(Condition), etc. { IsDone predicate For the sake of generality permit renements of First, Next, IsDone to also use runtime parameters, selection mechanisms, etc. Copyright c 2005 Egon Borger, Dipartimento di Informatica, Universita di Pisa, Pisa, Italy. 5
Template Method: Specic Renements of Submachines `Dene the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redene certain steps of an algorithm without changing the algorithm's structure.'[ghjv94:pg.325] AbstractClass, standing for an `Application', with a TemplateMethod (`the skeleton of an algorithm') { This method may call operations dened in AbstractClass or other classes and some abstract PrimitiveOperations ConcreteClass, an AbstractClass subclass standing for an individual `MyApplication': implements the PrimitiveOperations `to carry out subclass-specic steps of the algorithm' The ASM Method shifts the object-oriented subclassing and inheritance paradigm to the more general and mathematically accurate ASM renement concept. Copyright c 2005 Egon Borger, Dipartimento di Informatica, Universita di Pisa, Pisa, Italy. 6
Memento: Rening Submachines for Hiding Purposes `Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.'[ghjv94:pg.283] Memento with state recording submachines SetState, GetState, which `may store as much or as little of the originator's internal state as necessary at its originator's discretion' (up to renement!) Originator with location currstate and machines CreateMemento and SetMemento implemented importing Memento operations: CreateMemento = let m = New (Memento) in m :SetState (currstate ) Return m SetMemento(memento ) = originatorstate := memento :GetState Copyright c 2005 Egon Borger, Dipartimento di Informatica, Universita di Pisa, Pisa, Italy. 7
Observer Pattern: Multiple Renements of a Subject View `dene a one-to-many dependency between objects so that when one object changes state, all its dependents are notied and updated automatically'[ghjv94:pg.293] Subject with 3 interfaces manipulating location observers Attach(o) = (o 2 observers ) := true Detach(o) = (o 2 observers ) := false Notify = forall o 2 observers o :Update { ConcreteSubject with interfaces manipulating loc subjectstate GetState = Return subject State SetState(s) = subjectstate := Modify(subject State ; s) Observer with Update interface { ConcreteObserver Observer subclass with locations subject:concretesubject and observerstate and Update renement Update = observerstate := self :View (subject :GetState) Copyright c 2005 Egon Borger, Dipartimento di Informatica, Universita di Pisa, Pisa, Italy. 8
Bridge Pattern: Dynamic Choice of Parameterized Machines `decouple an abstraction from its implementation so that the two can vary independently'[ghjv94:pg.151] oering runtime choice between dierent renements Abstraction with interface Operation and location imp, parameter for the currently chosen delegator (instance of Implementor) Implementor with interface OperationImp which { is to be rened in machines ConcreteImplementor : Operation = imp.operationimp so that via updates of imp, dierent implementations of xed interface are run-time congurable/assignable { `doesn't have to correspond exactly to Abstraction's interface... Typically the Implementor interface provides only primitive operations, and Abstraction denes higher-level operations based on these primitives'[ghjv94:pg.154] Copyright c 2005 Egon Borger, Dipartimento di Informatica, Universita di Pisa, Pisa, Italy. 9
Proxy Pattern: Placeholder for To-Be-Provided Machine `provide a surrogate or placeholder for another object to control access to it'[ghjv94:pg.207] Subject with interface Request imported by two subclasses: { RealSubject { Proxy with: location realsubject:realsubject parameter for `the real object that the proxy represents' renement of Request `so that a Proxy (read: self ) can be used anywhere a RealSubject is expected'[ghjv94:pg.210] Easily extended for self.request = realsubject.request { RemoteProxy : SEND Request TO realsubject IN addrspace { VirtualProxy : postponed access via CACHE(realSubject,Request) { ProtectionProxy : checking permission to access realsubject.request Copyright c 2005 Egon Borger, Dipartimento di Informatica, Universita di Pisa, Pisa, Italy. 10
Decorator Pattern: Parameterization for Multiple Extensions `attach additional responsibilities to an object dynamically' as `a exible alternative to subclassing for extending functionality'[ghjv94:pg.175] Component with interface Operation, subclass ConcreteComponent `denes an object to which additional responsibilities can be attached' Decorator : Component subclass with location component ConcreteDecorator subclasses of Decorator where new behavior is added to calls of Operation = component.operation Every subclass ConcreteDecorator provides a new machine AddedBehavior to rene the ConcreteComponent Operation: self :Operation = fcomponent :Operation ; self :Added Behavior g Strategy pattern with same Operation = strategy.operation switching among implementations in multiple ConcreteComponent State pattern with similar Request = currstate.operation to alter upon internal state change the behavior Request'ed by clients Copyright c 2005 Egon Borger, Dipartimento di Informatica, Universita di Pisa, Pisa, Italy. 11
Responsibility Pattern: Runtime Determination of Agents `avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request'[ghjv94:pg.223] AbstractHandler with interface HandleRequest ConcreteHandler AbstractHandler subclass rening HandleRequest by associating any request m to an agent which is chosen out of a set of given implementations that can handle m HandleRequest (m) = choose a 2 CanHandle (m) a :m Copyright c 2005 Egon Borger, Dipartimento di Informatica, Universita di Pisa, Pisa, Italy. 12
Chain of Responsibility Pattern `the handler should be ascertained automatically...chain the receiving objects and pass the request along the chain until an object handles it'[ghjv94] HandleRequest (self ; m) = if CanHandle (m) then self :m else HandleRequest (self :successor ; m) To ascertain the handler really automatically, it remains to specify the initial agent self a termination criterion for passing HandleRequest along the successor chain whether successor is static or dynamic Copyright c 2005 Egon Borger, Dipartimento di Informatica, Universita di Pisa, Pisa, Italy. 13
Some Questions and Problems for Future Investigation model more complex not oo-programming-centric patterns, e.g. { J2EE Core Patterns (Alur et al., Prentice Hall 2003) { Patterns of Enterprise Application Architecture (Fowler et al., Addison-Wesley 2004) { Enterprise Integration Patterns (Hohpe & Woolf, Addison-Wesley 2004) { Workow Patterns (Aalst et al., Distributed and Parallel Databases 2003) { WS-CDL Service Interaction Patterns (Barros et al. 2005) investigate whether ASM pattern modeling can help to distinguish useful pattern combinations from less useful ones dene genuine modeling-patterns and their renement Copyright c 2005 Egon Borger, Dipartimento di Informatica, Universita di Pisa, Pisa, Italy. 14