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)


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



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



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)


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



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?



·       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)


·       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



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



·       TaxCalculatorAdapter – acts as intermediaries to external tax calculators

Figure - Indirection via the adapter.

4.     Protected Variations (Pattern)


·       Identify points of predicted variations or instability

·       Assign responsibilities to create a stable interface around them



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.



·       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)


How to resolve incompatible interfaces or provide a stable interface to similar components with different interfaces



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



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



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



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


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


Figure - Singleton pattern in the ServicesFactory class


4.     Strategy (GoF)


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

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


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


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


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


Figure – Composite Pattern


6.     Façade (GoF)


·       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


·       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)


·       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



·       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