Design Patterns

1
Design Patterns

• Standardized
• Recurring model
• Fits in many location
• Opposite of customization
• Fundamental types of pattern
• Choose and use as desired and befitting
• Adapt the pattern to your application

2

• Loop pattern
• Initialize loop parameter values and loop variant
• Loop
• if (check condition)
• statements
• else
• quit/exit Loop
• change loop variant
• continue Loop
• Is syntax diagram a pattern?

3

• This is an algorithmic code pattern for iteration
• You need to know what the loop parameters are,
  their initial values, and how they should be
  initialized
• You need to know the condition to be checked
• Obviously, the statements to be executed when the
  condition is true
• Precisely how the loop variant is to be changed
  for your application

4

• Definite iteration
• Going from 0 to N
• Going from M to N by step k
• Indefinite iteration
• How to obtain loop variant?
• How to validate loop variant?
• We have a pattern for definite iteration and
  another for indefinite iteration
• How about a pattern for linear search?
• How about pattern for search in a 2-D array?

5
Why we use Design Patterns

• We use patterns to make the design and
  implementation flexible
• Flexible w.r.t. requirements
• Flexible w.r.t. to inputs
• Flexible w.r.t. to implementation move things
  around an plug in components

6
Fundamental types of Design Patterns

• Creational
• Structural
• Behavioral
• One may find patterns pertinent to domains that
  you may not find in other domains
• Patterns for dynamic behavior may also be
  identified

7
Creational Patterns

• Factory
• Abstract Factory
• Builder
• Prototype
• Singleton

8
The Factory Pattern

• Constructor creates an object of a particular
  class
• Similar objects based on input values are to be
  created then you can have different class and the
  driver parses the input and uses the appropriate
  constructor
• A factory pattern streamlines this

9
The Abstract Factory Pattern

• Level higher in abstraction to the factory
  pattern
• In some cases it actually returns a Factory for
  that group of classes
• Example
• Type of garden
• Types of plants in the garden
• Investment example

10
The Builder Pattern

• Configurable system configuration file (XML
  files)
• Assembles objects to make a new object or system
• Based on the data in the config. File
• Uses a factories to build objects
• Separates construction from representation

11
The Prototype Pattern

• Copies or clones an existing class
• Used when creating a new instance is expensive
• Use java clone() method
• Classes have to implement cloneable

12
The Singleton Pattern

• Is a pattern that insures there is one and only
  one instance of an object
• Globally accessible object
• Final class with static methods
• Constructor is privatized
• Avoids global variables
• getInstance() method returns reference to this
  object

13

• Maintain a registry of singletons
• Pass singletons to other objects
• Type checking may be needed on singletons if
  using a registry
• How to adapt singletons for X instances

14
More info and examples

• http//www.fluffycat.com/java/patterns.html
• http//www.dofactory.com/Patterns/Patterns.aspx
• http//c2.com/cgi/wiki?DesignPatterns
• http//channah.com/portfolio/talk/Paper/GoF-patter
  ns/
• http//www.patterndepot.com/put/8/JavaPatterns.htm

15
Structural Patterns

• Adapter
• Adapt a user familiar interface to an available
  class interface
• Composite
• A mechanism to camouflage the distinction between
  like items with different constraints
• Proxy
• An intermediary assisting until the actual is
  available
• Flyweight
• A mechanism to avoid having many classes
  differing only by a few parameters a sharable
  instance of a class
• Façade
• A simplified interface to the generic system, as
  the system evolves
• Bridge
• A class that integrates interface to
  implementation
• Decorator
• A class with possible decorators (rather than
  derived classes)

16
Behavioral Pattern

• Observer or listener class
• Mediator communication interface (stub?)
• Chain of Responsibility chain of mediators
• Template abstract definition of an algorithm
• Interpreter appears like a language construct
• Strategy a mechanism to choose algorithm by the
  driver
• Visitor driver on multiple instance of a class
  (non-object oriented approach used for
  efficiency)
• State class retains its state and switches its
  choice of class
• Command traps and forwards the command to a
  specific class
• Iterator a mechanism to move through a
  collection through an interface

17
Framework

• Domain oriented design
• Can take this design (as a whole) and utilize it
  for multiple applications
• Service industry
• Distribution industry
• Health care industry
• Manufacturing
• Marketing
• Embedded Controls
• Aircraft controls
• Chiller controls

18
Summary

• What is UML?
• What is it unifying?
• What is the fundamental premise of UML?
• Define system Architecture.
• List the views of a system
• What is UP?
• Describe the axioms of UP.
• List the phases and workflows prescribed in UP

19
Summary (cont.)

• Who is responsible for the inception Phase?
• Who is responsible for other phases?
• Do we have to do all the workflows for every
  requirement?
• How are testing benchmarks to be developed?
• What would make systems developed using UML and
  UP obsolete?

20
Summary (Cont.)

• Argue for and against maintaining legacy systems.
• What is meant by a Quality Product?
• What is a Quality Process?
• Is UML/UP applicable to areas other than software
  development?
• Suggest some applications

21
Summary (Cont.)

• What is not covered in the UP?
• When can we consider the software a success?
• Who is responsible for the ultimate success or
  the failure of the software?
• When can we consider the software development
  process a success?

22
Not covered

• Human Factors
• Timeliness
• Judgments and Evaluations
• Sufficiency, Completeness, Soundness
• Effect of culture
• Technical Factors
• Choice of tools may affect product
• Unknown exceptions in the domain
• Technical issues intentionally/unintentionally
  ignored

23
Other topics

• Patterns and their effects
• Frameworks and their effects

24
Non Programmer Roles

• Systems Analyst
• Requirements Engineer
• Use-case engineer
• Software analyst
• Design Engineer
• Architect
• Component Engineer

25
Overall Experience

• Adoption of UP and UML
• Experience in large scale software Analysis and
  Design
• Experience in inter-group and intra-group
  discussions
• Multiple projects assist in revisiting analysis
  and design
• Development from other team deliverables
• Communication - oral and written
• Opportunity to contribute and assimilate from
  other projects
• First hand view of commonality among various
  software
• Non Programmer roles