swc - lecture 1.ppt

8/11/2019 SWC - Lecture 1.ppt

1/39

1

Software Construction

CNG 353

Lecture 1

Introduction


2/39

Course Goal & Objectives

Goal:To enable students to adopt OO andsoftware design patterns in their software

designs (advanced design).

Objectives:Discuss Basic Design Patterns.

Discuss Creational Design Patterns.

Discuss Collectional Design Patterns.

Discuss Structural Design Patterns.

Discuss Behavioral Design Patterns.

Discuss Concurrency Patterns. 2


3/39

Prerequisites

CNG 213 (Unofficial)- DS

CNG 351 (Unofficial)- DB

CNG 443 (Unofficial)- OO

3


4/39

Text Book

4

Partha Kuchana is an

enterprise systems

architect.

Steven John Metskeris a

researcher


5/39

Learning Outcomes

Ability to differentiate between different

OO design patterns and recognize the

contexts of their usage.

Ability to provide high quality reusable OO

system designs using different OO design

patterns.

5


6/39

Grading

Course Project: 40% Design

20% Implementation

Assignments: 10%

MD1: 10 %

Final: 20 %

6


7/39

What is a pattern?

Each pattern describes a problem which

occurs over and over again in our

environment, and then describes the core

of the solution to that problem, in such away that you can use this solution a million

times over, without ever doing it the same

way twice.

Charles Alexander7


8/39

Pattern Quotes

A pattern is an idea that has been useful in one

practical context and will probably be useful in

others

Martin Fowler A pattern is a three-part rule, which expresses a

relation between a certain context, a problem,

and a solution

Christopher Alexander


9/39

History

Christopher Alexander A Pattern Language: Towns, Buildings, Construction(1977)

A Timeless Way of Building(1979)

Gang of Four (Erich Gamma, Richard

Helm, Ralph Johnson, John Vlissides) Design Patterns(1995)

Buschmann et al Pattern Oriented Software Construction(1996)


10/39

Key Idea

A Software Pattern is:

A solution

To a problem

In a context

With consequences

A Software Pattern has a nameand a

vocabulary.


11/39

Elements of Design Patterns

Pattern Name

Increases design vocabulary, higher level of abstraction

Problem

When to apply the pattern

Problem and context, conditions for applicability of pattern

Solution

Relationships, responsibilities, and collaborations of design

elements

Not any concrete design or implementation, rather a template

Consequences

Results and trade-offs of applying the pattern

Space and time trade-offs, reusability, extensibility, portability


12/39

Benefits

Leverage a Proven Solution. Improves thinking about OO design

New designs

Existing designs Helps us realise the benefits of OO

Reuse of solutions to common problems

Cataloges Communication tool

Common vocabulary


13/39

Leverage a Proven Solution

The solution for a pattern has been designed,implemented and tested Reusing these solutions allows most of each of these

steps to be eliminated

If the implementation of a pattern is used, the design,implementation, and testing are minimal just toensure the proper behaviour exists

If the design of a pattern is used, the solution specific

to the problem must be implemented and tested, butneed not be redesigned


14/39

Provide a Common Vocabulary

Some patterns are very common

Documenting and cataloguing patterns allows

designers and architects to describe a solution using

patterns as part of the language Typically, this can make descriptions of solutions shorter

Architects and designers can more easily

communicate their designs to their developers


15/39

Design Patterns are NOT

Data structures that can be encoded in classes and

reused as is(i.e., linked lists, hash tables)

Complex domain-specific designs

(for an entire application or subsystem) If they are not familiar data structures or complex

domain-specific subsystems, what are they?

They are:

Descriptions of communicating objects and classes

that are customized to solve a general design problem

in a particular context.


16/39

Design patterns you have already

seen

Encapsulation (Data Hiding)

Subclassing (Inheritance) Iteration

Exceptions


17/39

Encapsulation pattern

Problem:Exposed fields are directly

manipulated from outside, leading to

undesirable dependences that prevent

changing the implementation.

Solution:Hide some components,

permitting only stylized access to the

object.


18/39

Exception pattern

Problem:Code is cluttered with error-

handling code.

Solution:Errors occurring in one part of

the code should often be handled

elsewhere. Use language structures for

throwing and catching exceptions.


19/39

Types of design patterns

Design patterns can be (roughly) grouped into three

categories:

Creational patterns Constructing objects

Structural patterns

Controlling the structure of a class, e.g. affecting theAPI or the data structure layout

Behavioral patterns

Deal with how the object behaves (duh!)


20/39

Specialised Fields Patterns

Real-time

Concurrency

Enterprise Messaging

Analysis


21/39

Refactoring to Patterns

Remove duplicate code

Simplify logic

Communicate intention Increase flexibility


22/39

Purpose

Creational Structural Behavioral

Scope Class Factory Method Adapter (class) Interpreter

Template MethodObject Abstract Factory

Builder

Prototype

Singleton

Adapter (object)

Bridge

Composite

Decorator

Facade

FlyweightProxy

Chain of

Responsibility

Command

Iterator

Mediator

MementoObserver

State

Strategy

Visitor

Defer object creation to

another class

Defer object creation to

another object

Describe algorithms and

flow control

Describe ways to

assemble objects

Design Pattern Space


23/39

25

How Design Patterns Solve Design

Problems

Finding Appropriate Objects

Determining Object Granularity

Specifying Object Interfaces

Specifying Object Implementations

Putting Reuse Mechanisms to Work

Relating Run-Time and Compile-Time

Structures

Designing for Change


24/39

How Design Patterns Solve

Design Problems Finding Appropriate Objects

Decomposing a system into objects is the hard part

OO-designs often end up with classes with no counterparts in

real world (low-level classes like arrays)

Strict modeling of the real world leads to a system that reflectstodays realities but not necessarily tomorrows

Design patterns identify less-obvious abstractions

Determining Object Granularity

Objects can vary tremendously in size and number

Facade patterndescribes how to represent subsystems as

objects

Flyweight patterndescribes how to support huge numbers of

objects


25/39

Specifying Object Interfaces

Interface:

Set of all signatures defined by an objects operations

Any request matching a signature in the objects interface may besent to the object

Interfaces may contain other interfaces as subsets

Type:

Denotes a particular interfaces

An object may have many types

Widely different object may share a type

Objects of the same type need only share parts of theirinterfaces

A subtypecontains the interface of its supertype

Dynamic binding, polymorphism


26/39

Program to an interface,

not an implementation- Manipulate objects solely in terms of interfaces

defined by abstract classes!

Benefits:

1. Clients remain unaware of the specific types of objects they use.2. Clients remain unaware of the classes that implement the

objects.

Clients only know about abstract class(es) defining the interface

- Do not declare variables to be instances of particular concreteclasses

- Use creational patterns to create actual objects.


27/39

Favor object composition

over class inheritance

White-boxreuse:

Reuse by subclassing (class inheritance)

Internals of parent classes are often visible to

subclasses

works statically, compile-time approach

Inheritance breaks encapsulation

Black-boxreuse:

Reuse by object composition Requires objects to have well-defined interfaces

No internal details of objects are visible


28/39

Designing for Change

Causes for Redesign (I) Creating an object by specifying a class explicitly

Commits to a particular implementation instead of an

interface

Can complicate future changes

Create objects indirectly

Patterns: Abstract Factory, Factory Method, Prototype

Dependence on specific operations

Commits to one way of satisfying a request Compile-time and runtime modifications to request

handling can be simplified by avoiding hard-coded

requests

Patterns: Chain of Responsibility, Command


29/39

Causes for Redesign (II) Dependence on hardware and software platform

External OS-APIs vary

Design system to limit platform dependencies

Patterns: Abstract Factory, Bridge

Dependence on object representations orimplementations

Clients that know how an object is represented,

stored, located, or implemented might need to be

changed when object changes Hide information from clients to avoid cascading

changes

Patterns: Abstract factory, Bridge, Memento, Proxy


30/39

Causes for Redesign (III)

Algorithmic dependencies Algorithms are often extended, optimized, and

replaced during development and reuses

Algorithms that are likely to change should be isolated

Patterns: Builder, Iterator, Strategy, TemplateMethod, Visitor

Tight coupling

Leads to monolithic systems

Tightly coupled classes are hard to reuse in isolation Patterns: Abstract Factory, Bridge, Chain of

Responsibility, Command, Facade, Mediator,

Observer


31/39

Causes for Redesign (IV) Extending functionality by subclassing

Requires in-depth understanding of the parent class

Overriding one operation might require overriding

another

Can lead to an explosion of classes (for simpleextensions)

Patterns: Bridge, Chain of Responsibility, Composite,

Decorator, Observer, Strategy

Inability to alter classes conveniently Sources not available

Change might require modifying lots of existing

classes

Patterns: Adapter, Decorator, Visitor


32/39


33/39

List of GoF Design Patterns

Creational Patterns

Abstract Factory

Builder

Factory Method

Prototype

Singleton

Structural Patterns Adapter

Bridge

Composite

Decorator Facade

Flyweight

Proxy

Behavioral Patterns

Chain of Responsibility

Command

Interpreter

Iterator

Mediator

Memento

Observer

State

Strategy

Template Method

Visitor


34/39

Antipatterns

An antipatternis a patternthat may becommonly used but is ineffective and/or

counterproductive in practice.

Examples

Big Ball Of Mud

Copy and Paste Programming Magic Container

Tower of Voodoo


35/39

Project management anti-patterns

Avalanche: An inappropriate mashup of the Waterfall modelandAgile Development

techniques

Death march: Everyone knows that the project is going to be a disasterexcept the

CEOso the truth is hidden to prevent immediate cancellation of the project -

(although the CEO often knows and does it anyway to maximize profit). However, the

truth remains hidden and the project is artificially kept alive until the Day Zero finally

comes ("Big Bang"). Alternative definition: Employees are pressured to work late

nights and weekends on a project with an unreasonable deadline.

Groupthink: During groupthink, members of the group avoid promoting viewpoints

outside the comfort zone of consensus thinking

Overengineering: Spending resources making a project more robust and complex

than is needed

Smoke and mirrors: Demonstrating unimplemented functions as if they were already

implemented

Software bloat: Allowing successive versions of a system to demand ever more

resources

Waterfall model: An older method of software development that inadequately deals

with unanticipated change

37
http://en.wikipedia.org/wiki/Avalanche_modelhttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Agile_Software_Developmenthttp://en.wikipedia.org/wiki/Death_march_(software_development)http://en.wikipedia.org/wiki/Groupthinkhttp://en.wikipedia.org/wiki/Overengineeringhttp://en.wikipedia.org/wiki/Smoke_and_mirrorshttp://en.wikipedia.org/wiki/Software_bloathttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Software_bloathttp://en.wikipedia.org/wiki/Smoke_and_mirrorshttp://en.wikipedia.org/wiki/Overengineeringhttp://en.wikipedia.org/wiki/Groupthinkhttp://en.wikipedia.org/wiki/Death_march_(software_development)http://en.wikipedia.org/wiki/Agile_Software_Developmenthttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Avalanche_model


36/39

Software design anti-patterns Abstraction inversion: Not exposing implemented functionality required by users, so

that they re-implement it using higher level functions

Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and

design(OOAD)) without specifying its viewpoint

Big ball of mud: A system with no recognizable structure

Database-as-IPC: Using a database as the message queue for routine interprocess

communicationwhere a much more lightweight mechanism would be suitable

Gold plating: Continuing to work on a task or project well past the point at which extra

effort is adding value

Inner-platform effect: A system so customizable as to become a poor replica of the

software development platform

Input kludge: Failing to specify and implement the handling of possibly invalid input

Interface bloat: Making an interface so powerful that it is extremely difficult to

implement

Magic pushbutton: Coding implementationlogic directly within interfacecode, without

using abstraction

Race hazard: Failing to see the consequence of different orders of events

Stovepipe system: A barely maintainable assemblage of ill-related components

38
http://en.wikipedia.org/wiki/Abstraction_inversionhttp://en.wikipedia.org/wiki/Ambiguous_viewpointhttp://en.wikipedia.org/wiki/Object-oriented_analysis_and_designhttp://en.wikipedia.org/wiki/Object-oriented_analysis_and_designhttp://en.wikipedia.org/wiki/Big_ball_of_mudhttp://en.wikipedia.org/wiki/Database-as-IPChttp://en.wikipedia.org/wiki/Inter-process_communicationhttp://en.wikipedia.org/wiki/Inter-process_communicationhttp://en.wikipedia.org/wiki/Gold_plating_(analogy)http://en.wikipedia.org/wiki/Inner-platform_effecthttp://en.wikipedia.org/wiki/Input_kludgehttp://en.wikipedia.org/wiki/Interface_bloathttp://en.wikipedia.org/wiki/Magic_pushbuttonhttp://en.wikipedia.org/wiki/Implementationhttp://en.wikipedia.org/wiki/Interface_(computer_science)http://en.wikipedia.org/wiki/Abstraction_(computer_science)http://en.wikipedia.org/wiki/Race_hazardhttp://en.wikipedia.org/wiki/Stovepipe_systemhttp://en.wikipedia.org/wiki/Stovepipe_systemhttp://en.wikipedia.org/wiki/Race_hazardhttp://en.wikipedia.org/wiki/Abstraction_(computer_science)http://en.wikipedia.org/wiki/Interface_(computer_science)http://en.wikipedia.org/wiki/Implementationhttp://en.wikipedia.org/wiki/Magic_pushbuttonhttp://en.wikipedia.org/wiki/Interface_bloathttp://en.wikipedia.org/wiki/Input_kludgehttp://en.wikipedia.org/wiki/Inner-platform_effecthttp://en.wikipedia.org/wiki/Inner-platform_effecthttp://en.wikipedia.org/wiki/Inner-platform_effecthttp://en.wikipedia.org/wiki/Gold_plating_(analogy)http://en.wikipedia.org/wiki/Inter-process_communicationhttp://en.wikipedia.org/wiki/Inter-process_communicationhttp://en.wikipedia.org/wiki/Inter-process_communicationhttp://en.wikipedia.org/wiki/Database-as-IPChttp://en.wikipedia.org/wiki/Database-as-IPChttp://en.wikipedia.org/wiki/Database-as-IPChttp://en.wikipedia.org/wiki/Database-as-IPChttp://en.wikipedia.org/wiki/Database-as-IPChttp://en.wikipedia.org/wiki/Big_ball_of_mudhttp://en.wikipedia.org/wiki/Object-oriented_analysis_and_designhttp://en.wikipedia.org/wiki/Object-oriented_analysis_and_designhttp://en.wikipedia.org/wiki/Object-oriented_analysis_and_designhttp://en.wikipedia.org/wiki/Object-oriented_analysis_and_designhttp://en.wikipedia.org/wiki/Ambiguous_viewpointhttp://en.wikipedia.org/wiki/Abstraction_inversion


37/39

Object-oriented design anti-patterns Anemic Domain Model: The use of domain modelwithout any business logic. The

domain model's objects cannot guarantee their correctness at any moment, because

their validation and mutation logic is placed somewhere outside (most likely inmultiple places).

BaseBean: Inheriting functionality from a utility classrather than delegating to it

Call super: Requiring subclasses to call a superclass's overridden method

Circle-ellipse problem: Subtypingvariable-types on the basis of value-subtypes

Circular dependency: Introducing unnecessary direct or indirect mutual dependencies

between objects or software modules Constant interface: Using interfaces to define constants

God object: Concentrating too many functions in a single part of the design (class)

Object cesspool: Reusing objects whose state does not conform to the (possibly

implicit) contract for re-use

Object orgy: Failing to properly encapsulate objects permitting unrestricted access to

their internals Poltergeists: Objects whose sole purpose is to pass information to another object

Sequential coupling: A class that requires its methods to be called in a particular

order

Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to

excessive fragmentation

39
http://en.wikipedia.org/wiki/Anemic_Domain_Modelhttp://en.wikipedia.org/wiki/Domain_modelhttp://en.wikipedia.org/wiki/Business_logichttp://en.wikipedia.org/wiki/BaseBeanhttp://en.wikipedia.org/wiki/Utility_classhttp://en.wikipedia.org/wiki/Call_superhttp://en.wikipedia.org/wiki/Circle-ellipse_problemhttp://en.wikipedia.org/wiki/Subtypehttp://en.wikipedia.org/wiki/Circular_dependencyhttp://en.wikipedia.org/wiki/Constant_interfacehttp://en.wikipedia.org/wiki/God_objecthttp://en.wikipedia.org/wiki/Object_cesspoolhttp://en.wikipedia.org/wiki/Object_orgyhttp://en.wikipedia.org/wiki/Poltergeist_(computer_science)http://en.wikipedia.org/wiki/Sequential_couplinghttp://en.wikipedia.org/wiki/Yo-yo_problemhttp://en.wikipedia.org/wiki/Yo-yo_problemhttp://en.wikipedia.org/wiki/Yo-yo_problemhttp://en.wikipedia.org/wiki/Yo-yo_problemhttp://en.wikipedia.org/wiki/Sequential_couplinghttp://en.wikipedia.org/wiki/Poltergeist_(computer_science)http://en.wikipedia.org/wiki/Object_orgyhttp://en.wikipedia.org/wiki/Object_cesspoolhttp://en.wikipedia.org/wiki/God_objecthttp://en.wikipedia.org/wiki/Constant_interfacehttp://en.wikipedia.org/wiki/Circular_dependencyhttp://en.wikipedia.org/wiki/Subtypehttp://en.wikipedia.org/wiki/Circle-ellipse_problemhttp://en.wikipedia.org/wiki/Circle-ellipse_problemhttp://en.wikipedia.org/wiki/Circle-ellipse_problemhttp://en.wikipedia.org/wiki/Call_superhttp://en.wikipedia.org/wiki/Utility_classhttp://en.wikipedia.org/wiki/BaseBeanhttp://en.wikipedia.org/wiki/Business_logichttp://en.wikipedia.org/wiki/Domain_modelhttp://en.wikipedia.org/wiki/Anemic_Domain_Model


38/39

Deprecated Patterns

Factory Method

Bridge

Flyweight

Interpreter


39/39

Your project

User and system requirements

Use Cases

System Architecture Diagrams Class Diagrams

41

swc - lecture 1.ppt

Documents