OO Methodology Elaboration Iteration 3 – Part 3 - More Design Patterns -

2 Table of Contents Iteration 1 –Use-Case Model –Process Sale Use Case –Domain Model –Design Model Iteration 2 –GRASP: More Patterns for Assigning Responsibilities –Designing Use-Case Realizations with GoF Design Patterns Iteration 3 –Related Use Cases –Modeling Generalization –Refining the Domain Model –Adding New SSDs and Contracts –Modeling Behavior in Statechart Diagrams –Designing the Logical Architecture with Patterns –Organizing the Design and Implementation Model Packages –Introduction to Architectural Analysis and the SAD –Designing More Use-Case Realization with Paterns –Designing a Persistence Framework with Patterns

3 Iteration 3 Requirements Provide failover to local services when the remote services cannot be accessed. Provide support for POS device handling, such as the cash drawer and coin dispenser Handle credit payment authorization Support for persistent objects

4 Failover to Local Services Requirements –Robust recovery from remote service failure(e.g. inventory) –Robust recovery from remote product database failure Using Local Cache –to improve recoverability –to improve performance –cache-first, remote-second Implemented by using Factory and Adapter 1.The ServiceFactory will always return an adapter to a local product information service 2.The local products adapter is not really an adapter to another component. It implement the responsibilities of the local service 3.The local service is initialized to a reference to a second adapter to the true product service 4.If the local service finds the data in its cache, it returns it; otherwise, it forwards the request to the adapter for the external service Levels of Cache –In-memory ProductCatalog maintains some ProductSpecification objects –Local product service maintains a larger persistent cache to support fault-tolerance

5 Failover to Local Services Adapters for Product Information –the new local service object is inserted without affecting the design of the ProductCatalog object

6 Failover to Local Services Initialization of the product information service –Using Factory and Adapter

7 Failover to Local Services Starting collaboration with the product service –in-memory cache

8 Failover to Local Services Continuing the collaboration for the product information –If the local product service does not the product in its persistent cache, it collaborates with the adapter to the external service New external services do not affect the design –only the factory’s configuration of the remote service needs to change

9 Failover to Local Services Active objects –Since products prices change quickly, the cache can contains stale data –One solution is to add a remote service operation that answers today’s current change, and the LocalProduct object queries it every n minutes and updates its cache –one approach is to make LocalProduct active object

10 Failover to Local Services with a Proxy Problem –External service should be tried first, and a local version second –e.g. consider the posting of sales to the accounting service Proxy Pattern –Context/Problem Direct access to a real subject object is not desired or possible. –Solution Add a level of indirection with a surrogate proxy that implements the same interface as the subject object and is responsible for controlling or enhancing access to it

11 Failover to Local Services with a Proxy External accounting service access 1.Send a postSale message to the redirection proxy 2.if the proxy fails to contact with the external service, then it redirects the postSale to a local service

12 Accessing External Physical Devices with Adapters Requirements –to interact with physical devices (cash drawer, coin dispenser,etc.) –NextGen POS must work with a variety of POS equipment(IBM, Epson, NCR, etc) Some Investigations –there is an industry standard, UnifedPOS –there is a Java mapping of the Unified POS, JavaPOS –the major manufacturers of POS equipment provide JavaPOS implementations Adapter Device Driver Device JNI JavaPOS

13 Abstract Factory Context –There are families of classes (cashDrawer+CoinDispenser+...) –Each family implements the same interfaces Solution –Define a factory interface(the abstract factory). –Define a concrete factory class for each family

14 Abstract Factory Abstract Class Factory –Abstract factory using Singleton pattern, reads from a system property to decide which of its subclass factories to create

15 Handling Payments with Polymorphism Do It Myself –I do those things that are normally done to the actual object that I,m an abstraction of. Circle objects draw themselves Square objects draw themselves Text objects spell-check themselves –Do It Myself and Information Expert usually lead to the same choice –Do It Myself and Polymorphism usually lead to the same choice To handle multiple payment types –including authorization and accounting steps –different kinds of payments in different ways

16 Handling Payments with Polymorphism Creating a CreditPayment

17 Handling Payments with Polymorphism Creating a CheckPayment

18 Handling Payments with Polymorphism Credit Payment Authorization –payment authorization protocols involve merchant ID and POS terminal ID

19 Handling Payments with Polymorphism Credit Payment Authorization (cont’) –adapter implementations protect the upper layers of the system against all variations in payment authorization( format, protocol etc.)

20 Handling Payments with Polymorphism Credit Payment Authorization (cont’)