INF5120 Modellbasert Systemutvikling

1. INF5120Modellbasert Systemutvikling F08: Service Modeling and SOA and Service Design - GRASP Patterns, Design Patterns, SOA Patterns and Refactoring  Forelesning 15.03.2010 Arne-Jørgen Berre

2. Agenda • Service Innovation/Service Design • Service Modeling (IBM, Model Driven solutions) • 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) 

3. Service Innovation/Service Design • AT-ONE project • See www.service-innovation.org

5. SoaML metodikk – IBM (SOMA) • Part 1. Service Identification • Part 2. Service specification • Part 3. Service realization • Part 4. Service composition • Part 5. Service implementation • See the 5 articles on the INF5120 website

6. Enterprise SoaML – (Model Driven Solutions) • Enterprise SoaML – Business value • SoaML for the Business architects and stakeholders • SoaML for the Systems architect • SoaML for the Services developer • See the article on the INF5120 website

7. WARM – Work Analysis Refinement Method (from COMET) • Annotate processes/tasks (in BPMN/UML Actvity diagrams) as being in one of the following three categories: (Standard in BPMN 2.0) • Manual (No IT support) • Tool supported (User interacts with an IT tool – modeled as a use case – for further analysis) • Automated (Can potentially be fully IT implemented) • Can be done as tagged values, annotations, comments or stereotypes

8. UP Analysis – Unified Process (Architecture/Service) Analysis • Group use cases for tool supported tasks from WARM per tool/application for each role • For each use case – do an architectural analysis – (consider to use CRC simulation, ref. lecture 1) and identify the potential use and interaction between the following three types of components/services • Boundary services (User interface services) • Control services (Functional services) • Entity services (Persistent/Data services)

9. Various service identification approaches(POSI, Msc.thesis UiO, 2008, Geir Anders Nilsen)

10. Archimate principal approach

11. 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

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

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

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

15. 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

16. 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."

17. 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)

18. 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

19. SOA Arkitekturprinsipper - Trygdeetaten

20. Trends: The Waves of Client/Server Technology – towards SOA Second Wave First Wave Third Wave Fourth Wave Fifth Wave MDA, Web Services, .Net Service-oriented Architecture SOAP, XML WSDL/WSFL Server-side componentsc Distributed Objects Database Servers File Servers Groupware J2EE/EJB COM+ Corba Comp OMG CORBA COM/OLE Web/Internett Java TP Monitors 1982 1986 1990 1994 1998 1999 2000 2001 … 2005 P2P Grid Base Source: Client/Server Survival Guide, 1994, 1996 Robert Orfali, Dan Harkey OS/2 Edition, VNR Computer library + AJB update 2005 Agents, FIPA

21. GRASP 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

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

23. Expert GRASP • 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?

24. 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.

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

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

27. GRASP 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.

28. Applying Polymorphism

29. GRASP Other GRASP Patterns • 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... • Creator—who creates? Usually the aggregate or containing object. • Pure Fabrication— “design” objects. Make it up when desperate. • Indirection— “most problems in computer science …” • Don’t Talk to Strangers—Law of Demeter

30. 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

31. 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

32. Button PushButton 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 ButtonClient Lamp Button and ButtonClient can now vary independently!

33. 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

34. 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!!

35. Patterns – Abstract Factory

36. Design patterns BookGamma/Helm/Johnson/Vlissides (GoF): Design Patterns, 1995 R. Ryan:, D. Rosenstrauch:Design Patterns in Java, 1997

37. 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."

38. 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.

39. GOF (Gang of Four) 23 Patterns • Creational Patterns (5) • Abstract 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

40. 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 (FolderView - Left pane) • All contents of selected folder (ContentsView - Right pane) • Spelunker provides support for : • Multiple ways of arranging ContentsView icons • Accessing network drives as well as local • Deleting, renaming and viewing disk contents

41. ContentsView FolderView Windows Explorer Screen Shot

42. Patterns in Spelunker example • Composite • used to model the file tree data structure • Strategy • used to layout the file and folder icons in ContentsView • Observer • used to re-display FolderViews and ContentsViews after user requests • Proxy and State • used to model password-protected network disk drives • Command • used to carry out user requests

43. 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., getSize()). • 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.

44. 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.” [GHJV94] • 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)

45. Component Client Operation( ) children Add(Component) Remove(Component) GetChild(int) Leaf Composite Operation( ) for all g in children g.Operation(); Operation( ) Add(Component) Remove(Component) GetChild(int) The “Composite” pattern • How the pattern solves the problem, cont. • Gang of Four UML [GHJV94]

46. Node Resource Tree children getSize( ) File Folder getSize( ) size = total of size of each child getSize() getContents() The “Composite” pattern • Use of the pattern in Spelunker • Both File and Folder share a common interface: Node. • Spelunker UML

47. The “Composite” pattern • Use of the pattern in Spelunker, cont. • Code examples public class File extends Node { private long size = 0; public long getSize() { return size; } } public class Folder extends Node { private Vector contents; public long getSize() { long size = 0; if (contents != null) { Enumeration e = contents.elements(); while (e.hasMoreElements()) { size += ((Node)e.nextElement()).getSize(); } } return size; } }

48. 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 ContentsView would make it cumbersome to add new icon arrangement algorithms to ContentsView; ContentsView 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.

49. 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.” [GHJV94] • Explanation • The algorithms for arranging the icons are encapsulated into a separate interface. • The correct arrangement algorithm is chosen polymorphically. • ContentsView neither knows nor cares which arrangement is presently in use.

50. strategy Context Strategy ContextInterface() AlgorithmInterface() ConcreteStrategyA ConcreteStrategyB ConcreteStrategyC AlgorithmInterface() AlgorithmInterface() AlgorithmInterface() The “Strategy” pattern • How the pattern solves the problem, cont. • Gang of Four UML [GHJV94]