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

• 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?

• 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

• 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?

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

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

Creational Patterns

• Factory

• Abstract Factory

• Builder

• Prototype

• Singleton

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

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

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

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

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

• 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

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-patterns/

• http://www.patterndepot.com/put/8/JavaPatterns.htm

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)

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

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

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

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?

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

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?

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

Other topics

• Patterns and their effects

• Frameworks and their effects

Non Programmer Roles

• Systems Analyst

• Requirements Engineer

• Use-case engineer

• Software analyst

• Design Engineer

• Architect

• Component Engineer

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