CS616 – Software Engineering II

Lecture 8

Part 4: Elaboration  - Iteration 2

Larman - Chapter 21

Iteration 2 Requirements

1.     Support for 3rd party external services

2.     Complex pricing rules

3.     Pluggable business rules

4.     Design to refresh a GUI window when dale total changes

Refinement of Analysis-oriented Artifacts in this iteration

·       Use-Case model -  none

·       Use-Case model : SSDs -  since NEXGEN communicates with external systems must update collaborations

·       Domain model – skip – move to design

·       Use-Case model : System Operation Contracts -  none

 

Larman - Chapter 22

GRASP: More Patterns for Assigning Responsibilities

 

1.     Polymorphism (Pattern)

Solution

When related alternatives or behaviors vary by type (class), assign responsibilities for the behavior using polymorphic operations

 

Problem

How to handle alternatives based on type? How to create pluggable components?

 

Example

NEXGEN – multiple 3rd party tax calculators

 

Figure– Polymorhism in adapting to different external tax calculators

NOTE: UML Notation for specifying interfaces ( a descriptor of operations without implementation), interface implementation, and “collection” return types.

 

 

Figure – UML notation for interfaces and return types

NOTE: A UML stereotype( a  mechanism to categorize an element in some way) is used to indicate an interface

2.     Pure Fabrication (Pattern)

Solution

Assign a highly cohesive set of responsibilies to an artificial or convenience class that does not represent a problem domain concept -  something made-up, to support high cohesion, low coupling, and reuse

 

Problem

What object should have the responsibility, when you do not want to violate high cohesion and low coupling, but solutions offered by Expert are not appropriate?

 

Example

·       Want to save Sale instances in a relational database.

·       Information Expert justifies assignement to Sale class itself

·       But:

o      Task requires large number of supporting database-oriented operations – none related to saleness

o      Sale class must be coupled to the relational database interface – increase coupling

o      Saving objects to a relational database is a very general task

·       Solution – create a new class that is solely responsible for saving objects into a persistent storage medium

 

3.     Indirection (Pattern)

Solution

·       Assign the responsibilities to an intermediate object to mediate between other components or services so that they are not directly couples.

·       intermediary creates an indirection between other components

 

Problem

·       Where to assign a responsibility to avoid direct coupling between two (or more) things?

·       How to de-couple objects so low coupling is supported and reuse potential remains high.

 

Example

·       TaxCalculatorAdapter – acts as intermediaries to external tax calculators

Figure - Indirection via the adapter.

4.     Protected Variations (Pattern)

Solution

·       Identify points of predicted variations or instability

·       Assign responsibilities to create a stable interface around them

 

Problem

How to design objects, subsystems, and systems so that the variations or instability in these elements does not have an undesirable impact on other elements.

 

Example

·       Previous tax calculator problem

·       Adding a level of indirection protects within the system from variations in external APIs.

 

Larman - Chapter 23

Designing Use-Case Realizations with GoF(Gang-of-Four) Design Patterns

1.     Adaptor (GoF)

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 adaptor object.

Figure - The Adapter Pattern

 

Figure - Using an Adapter Pattern

 

2.     Factory (GoF)

·       Fundamental design Principle: Design to maintain a separation of concerns

·       Factory (or Concrete Factory) Pattern – pure fabrication “factory” object defined to create objects

·       Advantages:

o      Separate the responsibility of complex object creation into cohesive helper objects

o      Hide complex creation logic

o      Allow introduction of performance-enhancing memory management strategies

 

Figure – Factory Pattern

NOTE: inclusion of detailed pseufocode

 

Context/Problem

Who should be responsible for creating objects when there are special considerations

 

Solution

Create a Pure Fabrication object called a factory that handles the creation

3.     Singleton (GoF)

·       Who creates the factory itself and how is it accessed?

·       Sometimes global visibility is needed through a single access point – Singleton

 

Context/Problem

Exactly one instance of a class is allowed – it is a “singleton.” Objects need a global, single point of access

Solution

Define a static method of the class that returns the singleton.

 

Figure - Singleton pattern in the ServicesFactory class

 

4.     Strategy (GoF)

Context/Problem

·       How to design for varying but related algorithms or policies?

·       How to design for the ability to change these algorithms and policies?

Solution

Define each algorithm/policy/strategy in a separate class, with a common interface

 

Figure – Pricing Strategy class

NOTE: Each getTotal method takes Sale as a parameter

5.     Composite (GoF) and Other Design Principles

Context/Problem

How to treat a group or composition structure of objects the same way (polymorphically) as a non-composite (atomic) object?

Solution

Define classes for composite and atomic objects so that they implement the same interface

 

Figure – Composite Pattern

 

6.     Façade (GoF)

Context/Problem

·       A common, unified interface to a disparate set of implementations or interfaces – such as within a subsystem – is required.

·       There may be undesirable coupling to many things in the subsystem, or the implementation of the subsystem may change

Solution

·       Define a single point of contact to the subsystem – a façade object that wraps the subsystem

·       The façade object presents a single unified interface and is responsible for collaborating with the subsystem components

 

7.     Observer/Publish-Subscribe/Delegation Event Model (GoF)

Context/Problem

·       Different kinds of subscriber objects are interested in the state changes or events of a publisher object, and want to react in their own unique way when the publisher generates an event

·       Publisher wants to maintain low coupling to the subscribers

 

Solution

·       Define a “subscriber” or “linstener” interface.

·       Subscribers implement this interface

·       Publisher can dynamically register subscribers who are interested in an event and notify them when the event occurs