INF 5120 Modellbasert Systemutvikling F 09 Service Design

INF 5120 Modellbasert Systemutvikling F 09: Service Design - GRASP Patterns, Design Patterns, SOA Patterns and Refactoring Forelesning 31. 03. 2008 Arne-Jørgen Berre ICT

Agenda Lectures and reading text (pensum) Patterns – history (Alexander) GRASP patterns (Lairman) Design Patterns (Gang of 4) SOA: Concepts, Technology and Design (Erl) SOA: Principles of Service Design (Erl) SOA: Design Patterns (Erl) Refactoring (Fowler) ICT

Lectures 1: 21/1: Introduction to MBSU, MDA, OO and Service/SOA modeling (AJB) 2: 28/1: Business Process Modeling (CIM) - with BPMN (AJB) 3: 4/2: Metamodeling and UML profiles, MDA technologies (EMF/GMF) – BPMN example (BRE) 4: 11/2: Language Engineering and DSL – SOA Example (BRE) 5: 18/2: Model transformations with ATL and QVT – and JEE (GO) 6: 25/2: SOA Architectures and UPMS (PIM) (AJB) 7: 3/3: Method Engineering and Service Modeling/SEMET (BRE) 8: 10/3: Code generation with MOFScript and other technologies (GO) EASTER 9 : 31/3: : Service Design and Patterns (AJB) 10: 7/4: PIM and Web Services teknologi (PSM) med WSDL/XML/BPEL (PSM) (BRE, GO) 11: 14/4: Model Driven Interoperability (BRE) 12: 21/4: Model Driven Interoperability and agent technologies (BRE, Ismar) 13: 28/4: Ontologies, Semantic web and Semantic Service Modeling (AJB) 14: 5/5: Aspect-oriented Programming and Modeling (ARS) 15: 26/5 Course summary Exam: June 2 nd, 2008… AJB – Arne J. Berre, BRE – Brian Elvesæter, GO – Gøran Olsen, ARS – Arnor Solberg ICT

SOA pattern literature web references www. soapatterns. com basis in: www. whatissoa. com www. soaprinciples. com www. soamethodology. com www. soaglossary. com www. soabooks. com www. soamag. com ICT

Patterns: From Analysis to Implementation Analysis Design Implementation Architecture Patterns (Macro Architecture) Analysis (Domain) Patterns Domain Framework Idioms (Language dependent patterns) Design Patterns (Micro Architecture) (OO) Reusable Components ICT

Patterns on various design levels SOA Design patterns * Module level patterns: Architecture Patterns Refactoring Collaboration level patterns: Design Patterns Object level patterns: GRASP ICT

Patterns Patterns - konsepter og prinsipper Basis GRASP patterns Analyse/Domene patterns Design patterns Arkitektur patterns System integrasjons patterns Refactoring Antipatterns ICT

Alexander - Patterns Christopher Alexander “A Pattern Language”, Oxford University Press, 1977 “The Timeless Way of Building”, 1979 • • A way to capture the essence of good architecture Each pattern describes a problem and its solution A pattern language is a group of interacting patterns Difficult in practice - The creative process is as important as the patterns ICT

What are patterns? "A solution to a problem in a context"? Insufficient, says the “Gang of Four” (GOF) What’s missing? 3 things: Recurrence Teaching (e. g. , implementation consequences, trade-offs, and variations) A name GOF: Patterns contain 4 essential elements pattern name problem solution consequences Christopher Alexander (as quoted in the GOF book): "Each pattern describes a problem which occurs over and over again. . . and then describes the core of [a] solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. " ICT 9

Pattern Description Template • • • Name Classification Rationale Applicability Description Diagram Steps/Process Implementation Variants Examples (incl code) Discussion Patterns are ideally described using Ooram (UML) role models !! (See later) ICT

Architectural patterns and style Architect Christopher Alexander “Quality without a name” – from The Timeless Way of Building, 1979 A Pattern Language: Towns, Buildings, Construction (Center for Environmental Structure Series) , 1977 Ref. SW Engineering later: Design patterns, analysis patterns, architectural patterns ICT

SOA Arkitekturprinsipper - Trygdeetaten ICT

Trends: The Waves of Client/Server Technology – towards SOA First Wave Second Wave ers v r e se S a b a are File Dat w p u Servers Gro itors n o M TP 1982 1986 1990 Third Wave Fourth Wave Fifth Wave MDA, Web Services, . Net Server-side Service-oriented Distributed componentsc Architecture Objects J 2 EE/EJB SOAP, XML OMG CORBA WSDL/WSFL COM+ COM/OLE Corba Comp Web/Internett 1994 Java 1998 1999 2000 2001 … 2005 P 2 P Agents, Grid FIPA Base Source: Client/Server Survival Guide, 1994, 1996 Robert Orfali, Dan Harkey OS/2 Edition, VNR Computer library + AJB update 2005 ICT

General Responsibility Assignment Software Patterns. Responsibility assignment. 1. knowing (answering) 2. or, doing Guidance and evaluation in mechanistic design. 1. Expert 2. Creator 3. Controller 4. Low Coupling 5. High Cohesion 6. Polymorphism 7. Pure Fabrication 8. Indirection 9. Don’t Talk to Strangers ICT

Controller What class should receive a system event message? Assign the responsibility for handling a system event message to one of these choices: 1 The business or “organization” (a façade controller). 2 or, The overall “system” or aggregate concept (a façade controller). 3 or, An artificial class representing the use case (a use case controller). ICT

Expert Most general purpose responsibility assignment principle? Assign a responsibility to the information expert—the class that has the information necessary to fulfill the responsibility. “That which knows, does” Who has the most data/information for solving the problem? ICT

Expert To “have the information” means, for example, the object may: know it as an attribute or object reference be able to derive it What is the motivation for Expert? Looking for task-owners that support encapsulation and low coupling. This reduces change impacts. ICT

High Cohesion How to design classes to increase the likelihood of reuse and not be overwhelmingly complex? Assign responsibilities so that cohesion remains high. ICT

Low Coupling How to create reusable components that are resilient to change? Assign responsibilities so that coupling remains low. ICT

Polymorphism How to handle alternatives based on type? When related alternatives or behaviors vary by type (class), assign responsibility for the behavior—using polymorphic operations—to the types for which the behavior vary. ICT

Applying Polymorphism ICT

Other GRASP Patterns Creator—who creates? Usually the aggregate or containing object. Pure Fabrication— “design” objects. Make it up when desperate. 1. Expert 2. Creator 3. Controller 4. Low Coupling 5. High Cohesion 6. Polymorphism 7. Pure Fabrication 8. Indirection 9. Don’t Talk to Strangers for more information. . . Indirection— “most problems in computer science …” Don’t Talk to Strangers— Law of Demeter ICT

Quick overview of Design Principles The Open-Closed Principle by Bertrand Meyer The Dependency Inversion Principle by Robert C. Martin The Liskov Substitution Principle by Barbara Liskov The Interface Segregation Principle by Robert C. Martin ICT

The Open-Closed Principle Software should be “open” for extension but “closed” to modification The goal is to design software that be easily extended without changing any of the existing code Inheritance and the development of abstract base classes play a big role in trying to fulfill this goal ICT

The Dependency Inversion Principle High-level modules should not depend on low-level modules. Both should depend on abstractions Abstractions should not depend on details. Details should depend on abstractions Button. Client Push. Button Lamp Button and Button. Client can now vary independently! ICT

The Liskov Substitution Principle Functions that use base class interfaces must not depend on or be confused by any derivatives of those interfaces A logical extension of the Open-Closed Principle All subclasses should implement the interface of the base class in a manner consistent with the intent of the base class ICT

The Interface Segregation Principle Clients should not be forced to depend on interfaces that they do not use The principle here is to avoid cluttering up an interface with things (functions, inheritance relationships) that the clients don’t need to use Take a clients’ perspective!! ICT

Patterns – Abstract Factory ICT

Design patterns Book Gamma/Helm/Johnson/Vlissides (Go. F): Design Patterns, 1995 R. Ryan: , D. Rosenstrauch: Design Patterns in Java, 1997 ICT

What are patterns? "A solution to a problem in a context"? Insufficient, says the “Gang of Four” (GOF) What’s missing? 3 things: Recurrence Teaching (e. g. , implementation consequences, trade-offs, and variations) A name GOF: Patterns contain 4 essential elements pattern name problem solution consequences Christopher Alexander (as quoted in the GOF book): "Each pattern describes a problem which occurs over and over again. . . and then describes the core of [a] solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. " ICT 30

Design Pattern A design pattern describes a basic scheme for structuring subsystems and components of a software architecture as well as their relationships. It identifies, names, and abstracts a common structural or functional principle by describing its different parts, their collaboration and responsibilities. ICT

GOF (Gang of Four) 23 Patterns Creational Patterns (5) Abstract Factory, Factory Builder, Factory Method, Prototype, Singleton Structural Patterns (7) Adapter, Bridge, Composite Decorator, Façade, Flyweight, Proxy Behavioural Patterns (11) Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer State, Strategy, Template method, Visitor ICT

Skylight Spelunker “Skylight Spelunker” is a Java framework for a file browser similar in appearance to the “Windows Explorer” included with Windows 98. Spelunker has two views: Disks and folders in tree structure (Folder. View - Left pane) All contents of selected folder (Contents. View - Right pane) Spelunker provides support for : Multiple ways of arranging Contents. View icons Accessing network drives as well as local Deleting, renaming and viewing disk contents ICT 33

Windows Explorer Screen Shot Folder. View Contents. View ICT 34

Patterns in Spelunker example Composite used to model the file tree data structure Strategy used to layout the file and folder icons in Contents. View Observer used to re-display Folder. Views and Contents. Views after user requests Proxy and State used to model password-protected network disk drives Command used to carry out user requests ICT 35

The “Composite” pattern Problem What is the best way to model the Spelunker file tree? The Spelunker file tree is a classic tree structure. Thus we need a leaf class (File) and a tree class (Folder) which contains pointers to the Files and Folders in it. However, there are many operations that are relevant to both a File and a Folder (e. g. , get. Size()). The user doesn’t treat Files and Folders differently, so why should calling modules have to? The design would be less complex and more flexible if the calling module could initiate operations on a target object, without knowing whether the target was a File or a Folder. File and Folder should share a common interface. ICT 36

The “Composite” pattern How the pattern solves the problem Intent “Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. ” [GHJV 94] Explanation The Composite pattern works by having leaf and tree objects share a common interface. Create an abstract base class (or interface) that represents both File and Folder. Files and Folders need to provide implementations for the same operations, but they can implement them differently. E. g. , leaves usually handle an operation directly, while trees usually forward the operation to its children (and/or perform additional work before or after forwarding) ICT 37

The “Composite” pattern How the pattern solves the problem, cont. Gang of Four UML [GHJV 94] Component Client Operation( ) Add(Component) Remove(Component) Get. Child(int) Leaf Operation( ) children Composite Operation( ) Add(Component) Remove(Component) Get. Child(int) for all g in children g. Operation(); ICT 38

The “Composite” pattern Use of the pattern in Spelunker Both File and Folder share a common interface: Node. Spelunker UML Node Resource Tree children get. Size( ) File get. Size( ) Folder size = total of size of each child get. Size() get. Contents() ICT 39

The “Composite” pattern Use of the pattern in Spelunker, cont. Code examples public class File extends Node { private long size = 0; } public long get. Size() { return size; } public class Folder extends Node { private Vector contents; public long get. Size() { long size = 0; } } if (contents != null) { Enumeration e = contents. elements(); while (e. has. More. Elements()) { size += ((Node)e. next. Element()). get. Size(); } } return size; ICT 40

The “Strategy” pattern Problem The way in which the icons are arranged varies according to user preference - the user may choose an iconic view only, or a short/long detail view. Including the algorithms to arrange the icons as methods in Contents. View would make it cumbersome to add new icon arrangement algorithms to Contents. View; Contents. View would have to be subclassed and some implementation details might have to be unnecessarily exposed. A switch statement would most likely be used to choose the correct arrangement algorithm. ICT 41

The “Strategy” pattern How the pattern solves the problem Intent “Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. ” [GHJV 94] Explanation The algorithms for arranging the icons are encapsulated into a separate interface. The correct arrangement algorithm is chosen polymorphically. Contents. View neither knows nor cares which arrangement is presently in use. ICT 42

The “Strategy” pattern How the pattern solves the problem, cont. Gang of Four UML [GHJV 94] strategy Context. Interface() Concrete. Strategy. A Algorithm. Interface() Strategy Algorithm. Interface() Concrete. Strategy. B Concrete. Strategy. C Algorithm. Interface() ICT 43

The “Strategy” pattern Use of the pattern in Spelunker Contents. View delegates the task of arranging the icons to View. Manager. Spelunker UML Contents. View update. Visible. Nodes() strategy View. Manager update. Visible. Nodes() Icon. View. Manager update. Visible. Nodes() List. View. Manager update. Visible. Nodes() ICT 44

The “Strategy” pattern Use of the pattern in Spelunker, cont. Code examples public interface View. Manager { public void update. Visible. Nodes(Folder active. Folder); } public class Contents. View extends Resource. Tree. View { private View. Manager view. Manager; public void show. Icon. View() { view. Manager = new Icon. View. Manager(this); } public void show. List. View(boolean show. Detail) { view. Manager = new List. View. Manager(this, show. Detail); } public void update. Visible. Nodes(Folder active. Folder) { view. Manager. update. Visible. Nodes(active. Folder); } } ICT 45

The “Observer” pattern Problem What is the best way to keep all views of the file tree in sync? We need to be able to re-draw the display window after the user modifies a file/folder (e. g. , when user clicks on a folder to select it) However, there may be several windows and panes that display the same file/folder. We need to re-draw all of them. To do this, the tree needs to keep a list of all of its views, and notify each one after a modification is done. However, the tree and view objects might: have little other relationship besides this notification need to have their code modified independently need to be reused separately So it would be preferable not to make them too tightly coupled to each other. ICT 46

The “Observer” pattern How the pattern solves the problem Intent “Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. ” [GHJV 94] Explanation The Observer pattern works by defining an abstract class (or interface) with a single method signature. The method will be used as a mechanism for “observer” objects to be notified of changes in their “subject”. Concrete observer sub-classes will each provide their own implementation of what to do when the notification occurs. The subject can notify each observer the same way, without caring which specific sub-class of observer the object actually is. ICT 47

The “Observer” pattern How the pattern solves the problem, cont. Gang of Four UML [GHJV 94] Observer Subject Attach(Observer) Detach(Observer) Notify( ) Update( ) observers Concrete. Subject. State Get. State( ) return Subject. State Concrete. Observer. State subject Update( ) Observer. State = subject. Get. State() for all o in observers o. update(); ICT 48

The “Observer” pattern Use of the pattern in Spelunker Resource. Tree notifies all Resource. Tree. Views whenever its state is modified. Spelunker UML Resource. Tree. Observer resource. Tree. Changed(Folder) observers Resource. Tree. View active. Folder Attach. Observer(Resource. Tree. Observer) Detach. Observer(Resource. Tree. Observer) Notify. Observers( ) resource. Tree. Changed( Folder active. Folder) subject Enumeration e = observers. elements(); while (e. has. More. Elements()) { Resource. Tree. Observer o = (Resource. Tree. Observer)e. next. Element(); o. resource. Tree. Changed(active. Folder); } update. Visible. Nodes(active. Folder); repaint(); ICT 49

The “Observer” pattern Use of the pattern in Spelunker, cont. Code examples public class Resource. Tree { private Vector observers; public void set. Active. Folder(Folder folder) { if (active. Folder != folder) { active. Folder = folder; notify. Observers(); } } } public void notify. Observers() { Enumeration e = observers. elements(); while (e. has. More. Elements()) { ((Resource. Tree. Observer)e. next. Element()). resource. Tree. Changed(active. Folder); } } public abstract class Resource. Tree. View extends Panel implements Resource. Tree. Observer { } public void resource. Tree. Changed(Folder active. Folder) { update. Visible. Nodes(active. Folder); repaint(); } ICT 50

The “Proxy” pattern Problem Network drives might require the user to login before the drive can be accessed - however, the protocol for accessing a network drive when logged in might not differ from accessing a local drive. Local. Drive should not contain network code - this code should be moved to a separate class, i. e. Network. Drive. Creating Network. Drive as a subclass of Local. Drive would be complicated and unwieldy - we would have to check access everytime a drive operation was requested. Creating Network. Drive as a subclass of Folder would force us to duplicate all drive access operations already in Local. Drive. ICT 51

The “Proxy” pattern How the pattern solves the problem Intent “Provide a surrogate or placeholder for another object to control access to it. ” [GHJV 94] “A Protection Proxy controls access to the original object. Protection Proxies are useful when objects should have different access rights. ” [GHJV 94] Explanation The network protocols necessary for logging in and out are moved into a subclass of Folder called Network. Drive contains the code necessary for logging in and out of a network drive. After logging in, Network. Drive delegates drive access requests to Local. Drive (indirectly through Connection. State). ICT 52

The “Proxy” pattern How the pattern solves the problem, cont. Gang of Four UML [GHJV 94] Subject Request() Real. Subject Request() real. Subject Proxy Request() . . . Real. Subject->Request(); . . . ICT 53

The “Proxy” pattern Use of the pattern in Spelunker Network. Drive acts as a Proxy for a remote Local. Drive. Spelunker UML Folder get. Contents() Note: Network. Drive delegates to Local. Drive indirectly through Connection. Opened. State. Local. Drive get. Contents() real. Subject Network. Drive get. Contents() . . . local. Drive. get. Contents(); . . . ICT 54

The “Proxy” pattern Use of the pattern in Spelunker, cont. Code examples public class Network. Drive extends Folder { private Connection. State connection. State; } public Vector get. Contents(Folder folder) { return connection. State. get. Contents(folder); } public class Connection. Opened. State extends Object implements Connection. State { private Local. Drive local. Drive; } public Vector get. Contents(Folder folder) { return local. Drive. get. Contents(folder); } ICT 55

The “State” pattern Problem What is the best way to perform password-protection processing on network drives? Network drives need to act differently depending on whether the user has logged in or not; e. g. , the user cannot examine or modify a network drive until they log in. This can be accomplished by checking a condition before executing each operation; e. g. , “if (logged. In())”. But this is ugly code, as well as being inefficient and repetitive. This is also difficult to extend: what if we need to implement another set of checks for another condition; e. g. , “if (!disconnected())”? The design would be less complex and more flexible if we could isolate in one location all behavior related to a particular state of the object. ICT 56

The “State” pattern How the pattern solves the problem Intent “Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. ” [GHJV 94] Explanation The State pattern works by creating an abstract class (or interface) with method signatures for every state-dependent operation in the main object, and concrete sub-classes that provide implementations for these methods. The main object then delegates each of these operations to the state object it is currently using. Each state class can implement each operation in its own way (e. g. , perform unique processing, disallow the operation, throw an exception, etc. ). The main object can change its behavior by changing the state object it is using. This is a very clean design - and also extendible: we can simply add new state classes to additional behavior, without modifying. ICT the original object. 57

The “State” pattern How the pattern solves the problem, cont. Gang of Four UML [GHJV 94] Context Request( ) state. Handle. Request() State state Handle. Request( ) Concrete. State. A Handle. Request( ) Concrete. State. B Handle. Request( ) ICT 58

The “State” pattern Use of the pattern in Spelunker The Network. Drive delegates operations to its Connection. State. Spelunker UML Network. Drive Connection. State change. State(Connection. State) get. Contents() return connection. State. get. Contents() state get. Contents( ) Connection. Opened. State get. Contents( ) Connection. Closed. State get. Contents( ) ICT 59

The “State” pattern Use of the pattern in Spelunker, cont. Code examples public class Connection. Closed. State implements Connection. State { public void login() { Local. Drive local. Drive = null; // login and initiate local. Drive } } network. Drive. change. State(new Connection. Opened. State(network. Drive, local. Drive)); public Vector get. Contents(Folder folder) { login(); return network. Drive. get. Contents(folder); } public class Connection. Opened. State implements Connection. State { public void login() { // display error } } public Vector get. Contents(Folder folder) { return local. Drive. get. Contents(folder); } ICT 60

The “Command” pattern Problem A request might need access to any number of classes. The initiator of the request should not be tightly coupled to these classes. Requests should be storable to support undoable operations; therefore, requests must be accessible through some common interface. How do we implement requests without coupling them to the initiator or target, or requiring the initiator to know the implementation details of the request ? Implementing the code for all requests in one class would centralize the application and make it difficult to create new requests. ICT 61

The “Command” pattern How the pattern solves the problem Intent “Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. ” [GHJV 94] Explanation Places the implementation of a request into a separate class. Initiators of the request do not know any implementation details of the request - they simply fire it off by calling the execute() method. The targets of the request do not need to know anything about the request. All requests are accessible through a common interface. The correct implementation is chosen polymorphically. ICT 62

The “Command” pattern How the pattern solves the problem, cont. Gang of Four UML [GHJV 94] Invoker Client Command Execute() Receiver Action() receiver Concrete. Command Execute() state receiver->Action(); ICT 63

The “Command” pattern Use of the pattern in Spelunker Used to implement user operations on files and folders. Spelunker UML Skylight Spelunker Command. Button Command execute() Contents. View get. Selected. Nodes() receiver Delete. Command execute() . . . Vector selected. Nodes = contents. View. get. Selected. Nodes(); . . . if (!node. delete. Node(node)) {. . . ICT 64

The “Command” pattern Use of the pattern in Spelunker, cont. Code examples public abstract class Command extends Object { public abstract void execute(); } public class Delete. Command extends Command { private Contents. View contents. View; private Resource. Tree resource. Tree; public void execute() { (code for retrieving all selected Nodes from Contents. View and deleting them) } } public class Command. Button extends Button { private Command command; public Command. Button(String label, Command command) { super(label); this. command = command; } } public boolean action(Event e, Object what) { command. execute(); return super. action(e, what); } ICT 65

Principles of Service Design Design principles Standardised Service Contracts Service Loose Coupling Service Abstraction Service Reusability Service Autonomy Service Statelessness Service Discoverability Service Composability ICT

ICT

Service Benefits Increased Intrinsic Interoperability Increased Federation Increased Vendor Diversity Options Increased Business and Technology Alignment Increased ROI Increased Organisational Agility Reduced IT Burden ICT

ICT

ICT

Service-Orientation and Object. Orientation (T. Erl) Service-Orientation and Object-Orientation Part I: A Comparison of Goals and Concepts http: //www. soamag. com/I 15/0208 -4. asp Service-Orientation and Object-Orientation Part II: A Comparison of Design Principles http: //www. soamag. com/I 16/0308 -4. asp ICT

ICT

ICT

ICT

ICT

ICT

SOA Design Patterns (Erl) http: //www. soapatterns. org ICT

SOA patterns ICT

ICT

ICT

Vendor-agnostic context pattern ICT

ICT

Refactoring - Improving the design of existing code 1. Refactoring - a first example 2. Principles in refactoring 3. Bad Smells in Code 4. Building Tests 5. Toward a catolog of refactorings 6. Composing Methods 7. Moving Features between objects 8. Organizing data 9. Simplifying Conditional Expressions 10. Making Method calls simpler 11. Dealing with Generalization 12. Big Refactorings 13. Refactoring, Reuse and Reality 14. Refactoring tools M. Fowler, with K. Beck, J. Brant, W. Opdyke, D. Roberts, Addison-Wesley, August 1999 Refactoring: Improving the design of existing code ICT

Refactoring - What and Why ? Refactoring is the process of changing a software system in such a way that it does not alter the external behaviour of the code yet improves its internal structure. Improving to make it easier to understand cheaper to modify ICT