Design Patterns Warranty

Management System

Agenda

OOAD UML
Thinking in Objects Design Patterns

ICONIX Process

Key Terms
Requirement Type
Functional Non-Functional

Difference between Analysis & Design

Analysis
Investigation of problem and requirement rather than a solution (Understanding requirement) Do the right thing

Design
Conceptual solution to a problem Do thing right

Difference between Architecture & Design

OOAD

Object Oriented Analysis (OOA)

A method of analysis that examines requirements from the perspective of the
classes and objects found in the vocabulary of the problem domain.

Object Oriented Design (OOD)

A method of design encompassing the process of object-oriented decomposition and a notation for depicting logical and physical as well as static and dynamic models of the system under design.

Object Oriented Decomposition

Process of breaking a system into parts, each of which represents some class or

object from the problem domain.

Responsibility driven design & reusability

Thinking in Objects
Difference between Class and Object

Object Oriented Principles

Abstraction essential characteristics of an object that distinguishes it from all other kinds of objects in the perspective of the viewer Encapsulation Modularity Hierarchy

Relationships Class level relationships vs Object level relationships

Class Level relationships Inheritance Object Relationships Association Aggregation

Thinking in Objects

Quality attributes Abstraction

Coupling
Strength of association from one object to other

Cohesion
Degree of connectivity between the elements of class or object

Static Model & Dynamic Model

UML

A general-purpose notational language for specifying and visualizing complex software, especially object-oriented systems Perspectives to Apply UML
Conceptual perspective the diagrams are interpreted as describing things in a situation of the real world or domain of interest. Specification (Software) perspective the diagrams describe software abstractions or components with specifications and interfaces, but no commitment to a particular implementation. Implementation (Software) perspective the diagrams describe software implementation in a particular technology.

UML vs. Thinking in Objects

Software Engineering Buzzwords and Relationships

Architecture API Application Programming Interface

Design

Frameworks

OOAD

S/w Engineering

SDK S/w Development Kit

UML

Programming Language

Design Patterns

***
OOAD UML - Design Patterns: Relationship

Class & Object relationships

Association Aggregation Composition Inheritance

10

Design Patterns

Pattern

A named description of a problem, solution, when to apply the

solution Named to well-known problem/solution pair that can be applied in

new context
Someone has already solved the problem

GOF Patterns - Authors

Erich Gamma Ralph Johnson Richard Helm John Vlissides
11

Design Patterns Guidelines

Patterns dont give you code, they give you general solutions to design problems Design patterns dont go directly into your code, they go into your BRAIN Design thinks about how to create flexible designs that are maintainable and that can cope with CHANGE CHANGE IS CONSTANT Design should Open for extension and close for modification A class should have only one responsibility Identify the aspects that vary and separate then from what stays the same Program for an Interface, not an implementation Favor composition over inheritance [Delegation vs Inheritance] Composition change behavior at Runtime Has a (Composition) vs. Is a (Inheritance) relation

12

Classification of Design Patterns

Creational Patterns deal with initializing and configuring classes and objects how am I going to create my objects? Structural Patterns deal with decoupling the interface and implementation of classes and objects how classes and objects are composed to build larger structures Behavioral Patterns deal with dynamic interactions among societies of classes and objects how to manage complex control flows (communications)

13

GOF design patterns

Purpose

Creational
Class

Structural
Adapter Adapter Bridge Composite Decorator Facade Flyweight Proxy

Behavioral
Interperter Chain of Responsibility Command Iterator Mediator Momento Observer State Strategy Vistor

Factory Method Abstract Factory Builder Prototype Singleton

Scope Object

14

GOF Creational Patterns

1.

Factory Method Pattern (Class)

2.

Abstract Factory Pattern

3.

Singleton Pattern

4.

Builder Pattern

5.

Prototype Pattern
15

1. Factory Method Pattern

Intent (Objective) -

Defines interface for creating an object, but lets

subclass decide which class to instantiate.

Factory method lets a class defer instantiation to subclass

Inheritance & abstract method

16

2. Abstract Factory Pattern

Intent (Objective) -

Provides an interface for creating families of related or dependent objects without specifying their concrete classes

Interface & Object type casting

17

3. Singleton Pattern

Intent (Objective) Ensures a class has only one instance, and provide a global point of access to it Private/protected constructor & static method javax.net.ServerSocketFactory

18

GOF Structural Patterns

1. 2. 3. 4. 5. 6. 7.

Adapter Pattern (Class) Faade Pattern Composite Pattern Bridge Pattern Decorator Pattern Proxy Pattern Flyweight
19

1. Adapter Pattern

Intent (Objective)

Converts the interface of a class into another

interface the client expects. Adapter lets classes work together that couldnt otherwise because of incompatible interfaces.

Composition

20

2. Faade Pattern

Intent (Objective) Provides a unified interface to a set of interfaces in a subsystem. Faade defines a higher level interface that makes the subsystem easier to use. Ex. Remote control

21

3. Composite Pattern

Intent (Objective) -

Allows you to compose objects into tree structures

to represent part-whole hierarchies.

Composite lets client treat individual objects and composition of objects uniformly. Menu MenuItem

22

4. Bridge

Intent (Objective) -

Decouple an abstraction from its implementation so that the two can

vary independently

TV and Remote control

23

GOF Behavioral Patterns

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

Observer Pattern (Class) Strategy Pattern Command Pattern State Pattern Template Method Pattern Iterator Pattern Mediator Pattern Memento Pattern Visitor Pattern Chain Of Responsibility Pattern Interpreter Pattern (Class)
24

1. Observer Pattern

Intent (Objective) Defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically. Ex. Button Action Listener, Mouse Listener

java.uitl.Observer, Observable
25

2. Strategy Pattern

Intent (Objective) Defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Change behavior at runtime.

Favor composition over inheritance

26

3. Template Method Pattern

Intent (Objective) Defines the skeleton of an algorithm in a method, deferring some steps to subclass. Template Method let subclass redefine certain steps of an algorithm without changing the algorithms structure.

Abstract class, Overriding

27

4. State Pattern

Intent (Objective) -

Allows an object to alter its behavior when it internal state

changes. The object will appear to change its class.

Account Active, Inactive, Suspend etc.,

28

5. Iterator Pattern

Intent (Objective) -

Provides a way to access the elements of an aggregate object

sequentially without exposing its underlying representation

java.util.Iterator, java.util.Collection <iterator>

29

6. Chain Of Responsibility

Intent (Objective)
Avoid coupling (decouples) the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it Allows you to add or remove responsibilities dynamically by changing the members or order of the chain

Linked List Data structure

30

ICONIX Process of transformation from Requirement - Code

31

Class Diagrams Map Out the Structure of the Code

32

Sequence Diagrams Help Us Allocate Operations (Behavior) to Classes

33

Robustness (Analysis) Diagrams Close the Gap Between Requirements and Detailed Design

34

Referencing Domain Objects by Name Removes Ambiguity from the Use Cases

35

The ICONIX ProcessA Streamlined Approach to UML Modeling

36

?
37

Thank You!