Architectural Analysis With Patterns

1
Architectural AnalysisWith Patterns

• ????? ??
• ???? ????

2
Agenda

• Case-Study NextGen POS System
• Description
• Requirements
• Domain-Model

• Architectural Analysis?
• POSs Architectural Factors
• Handling POS Requirements with Patterns

3
Case-Study POS System

• Description
• POS - Point Of Sale System.
• Purpose record sales and handle payments.
• Hardware computer and bar code scanner.
• Interface to third-party services tax
  calculator, inventory control, Accounting
• Must Be relatively fault-tolerant.
• Commercial we will sell POS to different
  clients.
• Functions Process Sale

4
Case-Study POS System

• Requirements Process Sale (Use-Case Model)

5
Case-Study POS System

• Domain Model

6
Case-Study POS System

• DCD

7
Case-Study POS System

• Interaction diagram for Start Up

8
Case-Study POS System

• Interaction diagram for Enter Item

9
Agenda

• POS Example
• Architectural Analysis?
• Definition
• Motivation

• POSs Architectural Factors
• Handling POS Requirements with Patterns

10
Architectural Analysis?

• Definition
• The definition is concerned with the
  identification and resolution of the systems
  non-functional requirements. For example
• Reliability
• Fault-Tolerance
• Quality
• Adaptability

• Architectural Design Analysis will be under 3
  Principles
• Low Coupling
• High Cohesion
• Protected Variation

• We built a Factor Table to show all the
  architectural factors together to understand the
  influence, priorities and the variability of them.

11
Architectural Analysis?

• Definition cont.
• Where we found the factors? Use-Cases are the
  source of the software requirements
• Special Requirements
• Technology Variations
• Open Issues

12
Architectural Analysis?

• Motivation
• How do reliability and fault-tolerance
  requirements affect the design?

• How does distribution of services affect the
  quality requirements and functional requirements?

• How do the adaptability and configurability
  requirements affect the design?

13
Agenda

• POS Example
• Architectural Analysis?
• POSs Architectural Factors
• Identify Analyze
• Analyze alternatives create solutions

• Handling POS Requirements with Patterns

14
POSs Architectural Factors

• 1. Identify Analyze the non-functional
  requirements
• Use-Case example

15
POSs Architectural Factors

• 2. Analyze alternatives create solutions
• Factor Table example

16
POSs Architectural Factors
Factors summary

• Adaptability Support many and changeable
  third-party services (tax calculator, credit
  authorization, inventory, accounting).

• 2. Reliability
• Robust recovery from remote service failure (tax
  calculator, inventory).
• Robust recovery from remote product database
  failure (description and prices).

17
Agenda

• POS Example
• Architectural Analysis?
• POSs Architectural Factors

• Handling POS Requirements with Patterns
• Factor 1 Adaptability
• Factor 2 Reliability

18
Handling POS Requirements with Patterns
Factor 1 Adaptability
Support many and changeable third-party services

• Problem
• The NextGen POS system needs to support several
  kinds of external third-party services such as
• tax calculators
• credit authorization
• inventory systems
• accounting systems

Can you think of a solution?
19
Handling POS Requirements with Patterns
Factor 1 Adaptability
Support many and changeable third-party services

• Solution Adapter Pattern
• We add a level of indirection with objects that
  adapt the varying external interfaces

Adapter Pattern Context / Problem How to resolve
incompatible interfaces, or provide a stable
interface to similar components with different
interfaces? Solution Convert the original
interface of a component into another interface,
through an intermediate adapter object.
20
Handling POS Requirements with Patterns
Factor 1 Adaptability
Support many and changeable third-party services
Solution Adapter Pattern
21
Handling POS Requirements with Patterns
POS System with Adapter Pattern
Is it correct?
22
Handling POS Requirements with Patterns
Factor 1 Adaptability
Support many and changeable third-party services
Adapter raises a new problems in the design

• who creates the adapters?
• How to determine which class of adapter to
  create?
• For example TaxMaster-Adapter or
  GoodAsGoldTaxProAdapter?

Explanation

• The domain layer of software objects emphasizes
  application logic responsibilities.
• A different group of objects is responsible for
  the concern of connectivity to external systems.
• So, choosing a domain object (Register) to create
  the adapters does not support the goal of a
  separation of concerns, and lowers its cohesion.

23
Handling POS Requirements with Patterns
Factor 1 Adaptability
Support many and changeable third-party services
Solution Factory Pattern
Factory Pattern Context I Problem Who should be
responsible for creating objects when there are
special considerations, such as complex creation
logic, a desire to separate the creation
responsibilities for better cohesion, and so
forth? Solution Create a Pure Fabrication object
called a Factory that handles the
creation. Factories are often accessed with the
Singleton pattern.
24
Handling POS Requirements with Patterns
Factor 1 Adaptability
Support many and changeable third-party services
Solution Factory Pattern
25
Handling POS Requirements with Patterns
POS System with Adapter Factory Pattern
26
Handling POS Requirements with Patterns
Factor 2 Reliability
Failover to Local Services

• Required
• Robust recovery from remote service failure (tax
  calculator, inventory, accounting)
• Robust recovery from remote product (descriptions
  and prices) database failure

27
Handling POS Requirements with Patterns
Factor 2 Reliability
Failover to Local Services

• Solution
• Local Cache reliability persisted on the local
  hard disk in a simple file of the
  ProductSpecification Object.
• The meaning is that the Local Cache should always
  look for a Cache Hit before attempting a remote
  access.

Can you think of Patterns?
This can be achieved with Adapter Factory
Patterns
28
Handling POS Requirements with Patterns
Factor 2 Reliability
Failover to Local Services
Solution Adapter Factory Patterns

• 1. Insert a local service in front of the
  external service.

2. The ServiceFactory will always return an
Adapter to a local product information service.
3. The local Products Adapter is not really an
Adapter to another component. It will itself
implement the responsibilities of the local
service.
4. The local service is initialized to a
reference to a second Adapter to the true remote
product service.
5. 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.
29
Handling POS Requirements with Patterns
Factor 2 Reliability
Failover to Local Services
Solution Adapter Factory Patterns Cont.

• Two levels of client-side cache
• The in-memory ProductCatalog Object will maintain
  an in-memory collection of some
  ProductSpecification Objects that have been
  retrieved from the product information service.
• The local products service will maintain a larger
  persistent cache that maintains some quantity of
  product information, this important for fault
  tolerance, so even if the POS application crashes
  and the in memory cache of the ProductCatalog
  object is lost, the persistent cache remains.

30
Handling POS Requirements with Patterns
Factor 2 Reliability
Failover to Local Services
Solution Adapter Factory Patterns

• Adapter for Product Information

31
Handling POS Requirements with Patterns
POS System with Adapter Factory Pattern
32
Handling POS Requirements with Patterns
Factor 2 Reliability
Failover to Local Services
Solution Adapter Factory Patterns

• Initialization of the Product Information service

33
Handling POS Requirements with Patterns
Something to think about.
Is this design appropriate for all services?
Does the local service is always tried first?
Example EIS for Store-Manager
No, sometimes the external service should be
tried first, and a local version second.
34
Handling POS Requirements with Patterns
Factor 2 Reliability
Failover to Local Services
Problem

• Consider the posting of sales to the accounting
  service.
• Business wants them posted as soon as possible,
  for real-time tracking of store and register
  activity.

Can you think of Patterns?
This can be achieved with Proxy Design Pattern
35
Handling POS Requirements with Patterns
Factor 2 Reliability
Failover to Local Services with a Proxy
Solution Proxy Pattern
Proxy Pattern Context / Problem Direct access to
a real subject object is not desired or possible.
What to do? Solution Add a level of indirection
with a surrogate proxy object that implements the
same interface as the subject object, and is
responsibility for controlling or enhancing
access to it.
36
Handling POS Requirements with Patterns
Factor 2 Reliability
Failover to Local Services with a Proxy
Solution Proxy Pattern

• Proxy
• Object that implements the same interface as the
  subject object
• Holds a reference to the real subject
• Used to control access to the real subject
• In the NextGen POS well use the Redirection
  Proxy variant (also known as Failover Proxy).

37
Handling POS Requirements with Patterns
Factor 2 Reliability
Failover to Local Services with a Proxy
Solution Proxy Pattern

• General Structure of the Proxy Pattern

38
Handling POS Requirements with Patterns
Factor 2 Reliability
Failover to Local Services with a Proxy
Solution Proxy Pattern

• Add a Redirection Proxy to the NextGen for
  external accounting service.
• The Redirection Proxy is used as follows
• Send a postSale message to the Redirection Proxy,
  treating it as thought it was the actual external
  accounting service.
• If the Redirection Proxy fails to make contact
  with the external service, then it redirects the
  postSale message to a local service, which
  locally stores the sales for forwarding to the
  accounting service, when it is active.

39
Handling POS Requirements with Patterns
Factor 2 Reliability
Failover to Local Services with a Proxy
Solution Proxy Pattern General Structure of
the Proxy Pattern
40
Handling POS Requirements with Patterns
The End