OBJECT ORIENTED ANALYSIS AND DESIGN OBJECT ORIENTED ANALYSIS

  • Slides: 89
Download presentation
OBJECT ORIENTED ANALYSIS AND DESIGN

OBJECT ORIENTED ANALYSIS AND DESIGN

OBJECT ORIENTED ANALYSIS AND DESIGN OBJECT ORIENTED ANALYSIS -Identification of domain model OBJECT ORIENTED

OBJECT ORIENTED ANALYSIS AND DESIGN OBJECT ORIENTED ANALYSIS -Identification of domain model OBJECT ORIENTED DESIGN -Construction of of domain model OBJECT ORIENTED PROGRAMMING -Implementation of domain model

UNIFIED MODELING LANGUAGE DEFINITION UML Defined as modeling language for specifying , constructing, visualizing

UNIFIED MODELING LANGUAGE DEFINITION UML Defined as modeling language for specifying , constructing, visualizing and documenting the real world object or system OBJECTIVE To show visual representation of real world system

MODEL 1. Static Model-Describe the object structure 2. Dynamic Model-Describe the object collaboration

MODEL 1. Static Model-Describe the object structure 2. Dynamic Model-Describe the object collaboration

UML DIAGRAMS 1. Use case Diagram 2. Class Diagram 3. Sequence Diagram 4. Collaboration

UML DIAGRAMS 1. Use case Diagram 2. Class Diagram 3. Sequence Diagram 4. Collaboration Diagram 5. Activity Diagram 6. State Chart Diagram 7. Component Diagram 8. Deployment Diagram

USECASE DIAGRAM CLASS DIAGRAM SEQUENCE DIAGRAM Requirement Documents USECASE COLLABORATIO N DIAGRAM ACTIVITY DIAGRAM

USECASE DIAGRAM CLASS DIAGRAM SEQUENCE DIAGRAM Requirement Documents USECASE COLLABORATIO N DIAGRAM ACTIVITY DIAGRAM STATE CHART DIAGRAM COMPONENT DIAGRAM DEPLOYMENT DIAGRAM

USECASE DIAGRAM USECASE-Usecase are functional Requirements. STEPS TO IDENTIFY THE USECASE: 1. Choose system

USECASE DIAGRAM USECASE-Usecase are functional Requirements. STEPS TO IDENTIFY THE USECASE: 1. Choose system boundary-define scope 2. Identify the actors 3. Identify the primary and secondary actors

4. Identify the goal of each actors Example: Goal of cashier-process a sale, cash

4. Identify the goal of each actors Example: Goal of cashier-process a sale, cash in, cash out Goal of admin-add the user, modify the user, delete the user 5. Finally Identify usecase Example: Usecase of cashier-process sale Usecase of admin-add user, modify user, delete user.

USECASE DIAGRAM � Used to represent relationship b/w actor and usecase Add user Delete

USECASE DIAGRAM � Used to represent relationship b/w actor and usecase Add user Delete user Modify user

NOTATION FOR USECASE DIAGRAM � System boundary-define scope of system � Usecase-Functional Req that

NOTATION FOR USECASE DIAGRAM � System boundary-define scope of system � Usecase-Functional Req that define what the system will do � Actors-Something with behavior S/m Boundary Usecase Name

RELATIONSHIP FOR USECASE DIAGRAM Usecase name 1. Association-Relationship b/w actor and usecase PAYMENT BY

RELATIONSHIP FOR USECASE DIAGRAM Usecase name 1. Association-Relationship b/w actor and usecase PAYMENT BY CASH PAYMENT BY CREDIT PAYMENT BY DEBIT 2. Generalization-Relationship b/w most gene most specific usecase

3. Include-Relationship b/w complex and simple usecase CHECKO UT de u l inc clude

3. Include-Relationship b/w complex and simple usecase CHECKO UT de u l inc clude in inclu de Scan rgitem Calculate rg total payment rg 4. Extend-Relationship b/w base and optional usecase Order food Eat food Pay for Food d Exten Order Wine Extend Drink Wine Pay for wine

USECASE DIAGRAM FOR ATM MACHINE System On System Perform Transaction osit Dep w Withdra

USECASE DIAGRAM FOR ATM MACHINE System On System Perform Transaction osit Dep w Withdra e Inc lud Off S/m Maintenance Add Cash Verify Account Maintain Customer Account Get Balance Bank

nd te Order Food Order Wine. Con form order Ex Re or cei de

nd te Order Food Order Wine. Con form order Ex Re or cei de ve r USECASE DIAGRAM FOR RESTAURENT MODEL nd jkl Ac Pa cep ym t en t Cook Food Drink Wine Serve Wine nd te Pay for Food Ex Receipt for payment Ex te Eat Food Ex te nd Serve food Pay for wine

UML CLASS DIAGRAM: � Main objective is to define static structure of system �

UML CLASS DIAGRAM: � Main objective is to define static structure of system � Used to represent set of class, Attributes, Operation, Interface, association, Multiplicity and Relationship. STEPS TO CREATE CLASS DIAGRAM: 1. Create Domain model-Visual Rep of Conceptual Classes -Find Conceptual Classes -Add attributes and Operation -Identify Association and Multiplicity 2. Redefine domain model-With class diagram relationship

MODEL CREATE DOMAIN Conceptual class-Collection of similar object Attributes-Logical data values Class sample Public

MODEL CREATE DOMAIN Conceptual class-Collection of similar object Attributes-Logical data values Class sample Public static void Main() { { Public int Sample obj 1=new x=10; sample(); Public int Int s=obj 1. add(); y=20; Console. writeline(“sum=“ Public int +s); add() } { Return(x+y); } Syntax- visibility name attributes name: datatype UML Notation for Class Name List of Attributes List of Operation

Example for attributes: Customer +Fname: str +Lname: str +Add: str Pinno: numeri c Account

Example for attributes: Customer +Fname: str +Lname: str +Add: str Pinno: numeri c Account +Acc. no: num eric +Acc. type: str Transaction +Trans. Id: numeri c +Trans. type: str +Trans. date: date +Trans. time: time +Trans. amount: fl oat +Balance: float ATMMachine. Id: numer ic Address: str

Operation: Are events, Responsible for managing the value of attributes Syntax- Access modifier mathodname()

Operation: Are events, Responsible for managing the value of attributes Syntax- Access modifier mathodname() Example: Customer Account +Verifyuser() +Deposit() +Withdraw() +Getbalance()

Association: Class A sam Class B Work For Employe e Compan Employer y Binary

Association: Class A sam Class B Work For Employe e Compan Employer y Binary Association OR Association ‘N’ Array Association

Binary Association: Contains House � OR Assocation: rk o W Employe e For Compan

Binary Association: Contains House � OR Assocation: rk o W Employe e For Compan y OR Wo rk For Bank Furnitur e

‘N’ Array Association: Person Grandparent Parent Child

‘N’ Array Association: Person Grandparent Parent Child

Multiplicity- Range of association One to One(1… 1) One to Many(1…. *) Many to

Multiplicity- Range of association One to One(1… 1) One to Many(1…. *) Many to Many(*…. . *) Multiplicity Husban d 1 1 Father 1 * Brother * * Wife Son Sister

REDEFINE DOMAIN MODEL Relationship ASSOCIATION AGGREGATION COMPOSITION GENERALIZATION DEPENDENCY Association Aggregation Composition Generalization Dependency

REDEFINE DOMAIN MODEL Relationship ASSOCIATION AGGREGATION COMPOSITION GENERALIZATION DEPENDENCY Association Aggregation Composition Generalization Dependency

Association: Person Aggregation: Player Having Car Team Player

Association: Person Aggregation: Player Having Car Team Player

Car Composition: 2, 4 4 Wheel Generalization: Bus 5, 10 1 Engin e Light

Car Composition: 2, 4 4 Wheel Generalization: Bus 5, 10 1 Engin e Light Door Vehicle Car Truck

Dependence : Account no: Number Account Type: String Balance: Float Depends On Withdraw() Deposit()

Dependence : Account no: Number Account Type: String Balance: Float Depends On Withdraw() Deposit() Balance. Enq() Transaction Trans. ID: Numaric Trans. Date: Date Trans. Time: Time Trans. Amount: Float Current. Bal: Float Get. Trans. History()

DOMAIN MODEL FOR BANKING SYSTEM Atm. Machine Bank Address: str State: str Customer Fname:

DOMAIN MODEL FOR BANKING SYSTEM Atm. Machine Bank Address: str State: str Customer Fname: str Lname: str Pinno: numeri c 1 has 1, 2 Verify. User() Account Acc. no: str Balance: flo at Deposit() Withdraw() Getbalane() Checking. Accou nt Acc. type: Check ing 1 * Has Saving. Account Acc. Type: savi ng Transaction Trans. Id: str Trans. Date: date Trans. Time: time Trans. Type: str Trans. Amount: fl oat

Registe r Ca p on ture d Get. Price Get. Sub. Total() contain Sale

Registe r Ca p on ture d Get. Price Get. Sub. Total() contain Sale Date: date Time: time Get. Total() Paidby Cashpayme nt Amount Item. Name: str Item. Id: numeri c Quantity: nume ric Sto in cke d Sale. Line. Itemname: str Itemid: numeri c Quantity: nume ric Price: float Record sa le of Procuct Descriptio n Item. Price Item. Id Describedby DOMAIN MODEL FOR PROCESS SALE Store Name: str Add: str Payment Amount: flo at Credit. Payment credit. No: nume ric Debit. Payment Debit. No: nume ric

UML INTERACTION DIAGRAM Used to describe how group of object collaborated to achieve goal

UML INTERACTION DIAGRAM Used to describe how group of object collaborated to achieve goal UML Interaction diagram 1. Sequence diagram 2. collaboration diagram

SEQUENCE DIAGRAM � Used to describe how sequence of message exchange b/w two objects

SEQUENCE DIAGRAM � Used to describe how sequence of message exchange b/w two objects SEQUENCE DIAGRAM FOR TELEPHONE CALL Exchan ge : X : Y Lift the Receiver Receive Dial Tone Dial No Invalid No <Excepti on> Invalid No Send Ring Tone Lift the Receiver Object X and Y Exchange the Information

BASIC NOTATION FOR SEQUENCE DIAGRAM: 1. Lifeline-represent scope : User Lifeline Box Lifeline 2.

BASIC NOTATION FOR SEQUENCE DIAGRAM: 1. Lifeline-represent scope : User Lifeline Box Lifeline 2. Lifeline Box-represent set of objects 3. Message-represent flow of events : Y : X Name Message

4. Message to self-object to itself : x Message to Self 5. Object Destruction-remove

4. Message to self-object to itself : x Message to Self 5. Object Destruction-remove object : X -- : Y <Destroy >

6. Looping Cashie r Loo p Enter Item(Item Id, Quantity) Display Description and Total

6. Looping Cashie r Loo p Enter Item(Item Id, Quantity) Display Description and Total System

SEQUENCE DIAGRAM FOR PROCESS SALE Scenario for process sale: 1. Customer waiting for checkout

SEQUENCE DIAGRAM FOR PROCESS SALE Scenario for process sale: 1. Customer waiting for checkout with items 2. Cashier starts a new sale 3. System displays data entry sheet 4. Cashier enters item details 5. System records item and display item description, running cost 6. Cashier repeat the step 4&5 until complete the process 7. Once all the item have been entered , the cashier end the sale 8. System display total cost with tax 9. Cashier request customer to pay the amount 10. Customer pays amount for item 11. Cashier handle payment 12. System dispatch receipt for payment 13. Cashier dispatch change& receipt to the customer

: Custome r Wait for Checkout : Cashie r : System Make new sale

: Custome r Wait for Checkout : Cashie r : System Make new sale Data Entry Sheet Enter Item(Id, Quantity) Description, Total End Sale Loop Request Payment Make Payment Total Cost with Tax Handle Payment Dispatch Receipt Dispatch Change&Receipt. Complete Process sale

COLLABORATION DIAGRAM � Used to represent object interaction in a n/w format Sequence of

COLLABORATION DIAGRAM � Used to represent object interaction in a n/w format Sequence of Direction of data message : A Association link 1: message 1 2: message 2 flow : B Message Name

Notation for collaboration diagram: Link- connection or navigation path b/w two object Link :

Notation for collaboration diagram: Link- connection or navigation path b/w two object Link : A : B Message-Represent behavior of system : User 1. Enter name & pwd 4: Valid User : DB : Window 2. Verify with DB 3: Self Checking

COLLABORATRION DIAGRAM FOR PROCESS SALE : Customer 1: WAIT FOR CHECK OUT 8: REQUEST

COLLABORATRION DIAGRAM FOR PROCESS SALE : Customer 1: WAIT FOR CHECK OUT 8: REQUEST PAYMENT CHANGE & 12: DISPATCH RECEIPT 9: MAKE PAYMENT : Cashier 2: MAKE NEW SALE 3: DATA SHEET 4: ENTERITEM(ID, QUANT ITY) 5: DESCRIPTION AND COSTSALE 6: END 7: TOTAL COST+TAX 10: HANDLE PAYMENT : System 11: DISPATCH RECEIPT

DIFFERENCE B/W SEQUENCE AND COLLABORATION SEQUENCE DIGRAM COLLABORATION DIAGRAM Clearly identify the sequence of

DIFFERENCE B/W SEQUENCE AND COLLABORATION SEQUENCE DIGRAM COLLABORATION DIAGRAM Clearly identify the sequence of message More difficult to identify the sequence of message Space consume Space Economical

ACTIVITY DIAGRAM � Graphical representation of data flow from one activity to another activity

ACTIVITY DIAGRAM � Graphical representation of data flow from one activity to another activity � Commonly contain, 1. Action State- atomic state 2. Activity State- composite state 3. Transition- Represent direction of data flow 4. Branching-decesion making purpose 5. Fork –division purpose 6. Join-synchronization purpose

Action State- atomic state Search Simple Action state Activity State- composite Calculate Percentage Delete

Action State- atomic state Search Simple Action state Activity State- composite Calculate Percentage Delete Simple Action Calculate Total Transition- Represent direction of data flow

Branching- decision making purpose Initial State Action State Enter user name & pwd Verify

Branching- decision making purpose Initial State Action State Enter user name & pwd Verify Branching If Valid Transition True False Next Activity Final State Re-Enter Username & Pwd

Fork and Join– division & synchronization purpose Select Pattern Fork Pattern 1 Pattern 2

Fork and Join– division & synchronization purpose Select Pattern Fork Pattern 1 Pattern 2 Pattern 3 Join View Score

ACTIVITY DIAGRAM FOR ONLINE QUIZ Get username and password No verify Invalid password Yes

ACTIVITY DIAGRAM FOR ONLINE QUIZ Get username and password No verify Invalid password Yes Select pattern Pattern 1 Pattern 2 Pattern 3 Ans the questions View Score

Activity Diagram for telephone Call Is the No. Valid ? Is the No. Busy?

Activity Diagram for telephone Call Is the No. Valid ? Is the No. Busy? Is the User busy? Lift Receiver receive Dial tone Dial Number No Yes No Send Ring tone Yes No Lift Receiver Connect C & R Redial No.

STATECHART DIAGRAM � Graphical representation of object state, transition, event & action Initial State

STATECHART DIAGRAM � Graphical representation of object state, transition, event & action Initial State IDLE State Event Offhook ACTIVE Final State Onhook Transition

OBJECT STATE Object state- situation of object Name of the Component Idle Lift Receiver/Hear

OBJECT STATE Object state- situation of object Name of the Component Idle Lift Receiver/Hear Dial Tone Event Internal Transaction Action or Activity

Object state types 1. Initial- Starting point of Execution 2. idle- Waiting for user

Object state types 1. Initial- Starting point of Execution 2. idle- Waiting for user command 3. active- Perform action response to event 4. final- Ending point of execution 5. Nested state

Transaction Key ON Initial State Idle Active Key OFF Event Lift Receiver/Hear Dial Tone

Transaction Key ON Initial State Idle Active Key OFF Event Lift Receiver/Hear Dial Tone ali Dial Entry/No. append (n) . V Idle d( ) Validate No No Nested State: Final

TRANSITION Transition: Relationship b/w two object state when event occurs, object transition from one

TRANSITION Transition: Relationship b/w two object state when event occurs, object transition from one state to another state. Transition Simple Transition Complex Transition

1. simple transition-relationship b/w two object state Idle Active 2. complex transition- relationship b/w

1. simple transition-relationship b/w two object state Idle Active 2. complex transition- relationship b/w two or more object state A 1 A 2 A B A 3 A 4

EVENT-command given by the user 1. internal event-event that pass among the object Example:

EVENT-command given by the user 1. internal event-event that pass among the object Example: obj. add(10, 200); 2. external event-event that pass b/w user and system Example: user interact with atm machine 3. time event-event occurs based on time When Time=11 am Idle Active ACTION-changes in object state in response to

IMPLEMENTATIOM DIAGRAM � Used to represent implementation of software structure, such as source code

IMPLEMENTATIOM DIAGRAM � Used to represent implementation of software structure, such as source code & node structure � Source code- physical or re-usable components � Node structure- runtime processing element Implementation diagram: 1. Component diagram 2. Deployment diagram

COMPONENT DIAGRAM � Show implementation of module or component with dependency relationship Login Component

COMPONENT DIAGRAM � Show implementation of module or component with dependency relationship Login Component Name Component

� Dependency DB UI relationship Update Dependency Relationship

� Dependency DB UI relationship Update Dependency Relationship

COMPONENT DIAGRAM FOR ONLINE TICKET RESERVATION SYSTEM Update DB Login Status Reserv e Canc

COMPONENT DIAGRAM FOR ONLINE TICKET RESERVATION SYSTEM Update DB Login Status Reserv e Canc el

DEPLOYMENT DIAGRAM � Show implementation of node or runtime processing element with association relationship

DEPLOYMENT DIAGRAM � Show implementation of node or runtime processing element with association relationship � Association relationship DB Nod e Component name

DEPLOYMENT DIAGRAM FOR ONLINE TICKET RESERVATION SYSTEM Node 1: ADMINPC Database(Web Storage) DB Dependency

DEPLOYMENT DIAGRAM FOR ONLINE TICKET RESERVATION SYSTEM Node 1: ADMINPC Database(Web Storage) DB Dependency Relationship Association Relationship L S Node 2: USERPC R UI(Web Page)

MAPPING DESIGN TO CODE � Mapping nothing but design logic converted into code �

MAPPING DESIGN TO CODE � Mapping nothing but design logic converted into code � Main objective is logical implementation of conceptual classes using programming language

Class operation { Public int x=20; Public int y=10; Public int add() { Return(x+y);

Class operation { Public int x=20; Public int y=10; Public int add() { Return(x+y); } Public int sub() { Return(x-y); } Public int mul () { Return(x*y); } IMPLEMENTATION OF CONCEPTUAL CLASS(OPERATION) USING C#. NET Public int div() { Return(x/y); } Public static void Main() { Operation obj 1=new operation(); Console. writeline(“sum=“+(obj 1. add())); Console. writeline(“sub=“+(obj 1. sub())); Console. writeline(“sum=“+(obj 1. mul())); Console. writeline(“sum=“+(obj 1. div()));

IMPLEMENTATION OF BANKING DOMAIN MODEL USING C#. NET Atm. Machine Bank Address: str State:

IMPLEMENTATION OF BANKING DOMAIN MODEL USING C#. NET Atm. Machine Bank Address: str State: str Customer Fname: str Lname: str Pinno: numeri c 1 has 1, 2 Verify. User() Account Acc. no: str Balance: flo at Deposit() Withdraw() Getbalane() Checking. Accou nt Acc. type: Check ing 1 * Has Saving. Account Acc. Type: savi ng Transaction Trans. Id: str Trans. Date: date Trans. Time: time Trans. Type: str Trans. Amount: fl oat

IMPLEMENTATION OF BANKING DOMAIN MODEL Class customer { Public string firstname; Public string lastname;

IMPLEMENTATION OF BANKING DOMAIN MODEL Class customer { Public string firstname; Public string lastname; Public int pinno=101; Public int verifyuser(int x) { If (pinno=x) { Console. writeline(“valid user”)’ Else Console. writeline(“Invalid user”)’ } } Public static void Main() { Customer obj 1=new customer(); Obj 1. verifyuser(101); } }

Designing objects with responsibilities List of patterns 1. Creater pattern 2. Information expert pattern

Designing objects with responsibilities List of patterns 1. Creater pattern 2. Information expert pattern 3. Low coupling pattern 4. High cohesion pattern 5. Controller pattern 6. Adapter pattern 7. Singleton 8. Factory pattern 9. Observer pattern

Responsibilities q Responsibility defined as behavior of an object q There are two types

Responsibilities q Responsibility defined as behavior of an object q There are two types of responsibility 1. Doing 2. Knowing Doing something itself, such as n. Creating an object n Invoking or Initiating class member using object n. Controlling and coordinating activities in other objects n Knowing about object encapsulated data n Knowing about related objects n knowing about object it can derive n

Assigning responsibilities: example � Who should be responsible for knowing the grand total of

Assigning responsibilities: example � Who should be responsible for knowing the grand total of a sale?

Assigning responsibilities: example Class Sale Responsibility knows sale total Sale. Line. Item knows line

Assigning responsibilities: example Class Sale Responsibility knows sale total Sale. Line. Item knows line item total Product. Desc knows product ription price

patterns Patterns help us assign responsibilities

patterns Patterns help us assign responsibilities

The pattern concept � � � A pattern defined as description of general solution

The pattern concept � � � A pattern defined as description of general solution to a commonly occurring problem in object and class. Object-oriented design patterns typically show relationships and interactions between classes or objects. Main objective of pattern is to assign responsibilities to classes and objects.

Groups of patterns � GRASP (General Responsibility Assignment Software Patterns (or Principles). ◦ 9

Groups of patterns � GRASP (General Responsibility Assignment Software Patterns (or Principles). ◦ 9 the most useful patterns � Go. F GOF (Gang-of-Four Patterns) ◦ 23 patterns Behavioral Patterns n n n GRASP n n n n n Information Expert Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations. Structural patterns Chain of responsibility n Command Creational patternsn Interpreter n Abstract factory n Iterator n Builder n Mediator n Factory method n Memento n Prototype Observer n n Singleton State n Strategy Template method Visitor Adapter Bridge Composite Decorator Facade Flyweight Proxy

pattern template � Name Every pattern should have a descriptive and unique name that

pattern template � Name Every pattern should have a descriptive and unique name that helps in identifying and referring to it. � Problem Describe general problem occur in class and object � Solution Describe general solution for commonly occurring problem in object and class. � Intent Describes goal and purpose � Collaboration Describe list object, class and their collaboration.

pattern template � Consequences: Describes the results, side effects � Implementation: Describes the implementation

pattern template � Consequences: Describes the results, side effects � Implementation: Describes the implementation of the pattern procedure for this implementation techniques used in implementing this pattern solution for the pattern � Sample Code: Describe how this pattern can be used in a programming language.

GRASP: The Creator pattern § Creator pattern: Goal: find the creator of objects of

GRASP: The Creator pattern § Creator pattern: Goal: find the creator of objects of a class Guideline: look for relationships like contains, records etc. § Pattern Name: Creator § Problem: Who creates object X? § Solution: A is a creator of B objects, if one of the condition is true § A contains B objects § A records B objects

GRASP: The Creator example : Student. Reg records 1: create (first. Name, last. Name,

GRASP: The Creator example : Student. Reg records 1: create (first. Name, last. Name, pnr, …) s 1: Student § Student. Reg object keeps records of all students object, so object A create object B.

GRASP: The Creator example : House Contains 1: creates(table, chair etc. . ) :

GRASP: The Creator example : House Contains 1: creates(table, chair etc. . ) : Furniture q House object A contains furniture object B, so object A creates object B

Another Creator example § Which class should be responsible for creating a new Sales.

Another Creator example § Which class should be responsible for creating a new Sales. Line. Item? Sale date time Contains 1 make. Line. Iteml() 1. . * Sales Product. Spec Described-by Line. Item description 1 * price quantity item. ID : Sale 1. create(qty) : Sales. Line. Item

GRASP: Information Expert Pattern � Pattern Name: Information Expert � Problem: What is a

GRASP: Information Expert Pattern � Pattern Name: Information Expert � Problem: What is a basic principle to assign responsibilities to Objects? � Solution: Assign a responsibility to the class that has the needed to fulfill it.

GRASP: Information Expert example § Which classes are responsible for evaluating the total of

GRASP: Information Expert example § Which classes are responsible for evaluating the total of a sale, the subtotal of a Sales. Line. Item, the price of a product? Sale date time Contains 1 t: =get. Total() 1. . * Sales Product. Spec Described-by Line. Item description 1 * price quantity item. ID : Sale 1*: st: =get. Subtotal() * : Sales. Line. Item 1. 1: p: =get. Price() : Product. Spec

GRASP: The Low Coupling pattern § Pattern Name: Low Coupling § Problem: How to

GRASP: The Low Coupling pattern § Pattern Name: Low Coupling § Problem: How to reduce the impact of change or degree of interconnection b/w components § Solution: Remove unnecessary dependency links b/w components � Coupling describes the degree of interconnection between design components � It is reflected by the number of links an object has and by the degree of interaction the object has with other objects � Coupling should be kept to a minimum

EXAMPLE FOR LOW COUPLING : Custome Wait for r Checkout : Cashie r :

EXAMPLE FOR LOW COUPLING : Custome Wait for r Checkout : Cashie r : System Make new sale Data Entry Sheet Enter Item(Id, Quantity) Description, Total End Sale Loop Request Payment Make Payment Total Cost with Tax Handle Payment Dispatch Receipt Dispatch Change&Receipt. Complete Process sale

: Customer 1: WAIT FOR CHECK OUT 8: REQUEST PAYMENT CHANGE & 12: DISPATCH

: Customer 1: WAIT FOR CHECK OUT 8: REQUEST PAYMENT CHANGE & 12: DISPATCH RECEIPT 9: MAKE PAYMENT : Cashier 2: MAKE NEW SALE 3: DATA SHEET 4: ENTERITEM(ID, QUANT ITY) 5: DESCRIPTION AND COSTSALE 6: END 7: TOTAL COST+TAX 10: HANDLE PAYMENT : System 11: DISPATCH RECEIPT

GRASP: The Controller pattern § Controller pattern: Every system should have a controller or

GRASP: The Controller pattern § Controller pattern: Every system should have a controller or handler A controller is class whose job is to control and coordinate the system events. § Pattern Name: Controller § Problem: Who should be responsible for handling an input system event? § Solution: Assign the responsibility to Handler, Controller or coordinator class.

Controller example § Who should be responsible of handling external system events (e. g.

Controller example § Who should be responsible of handling external system events (e. g. enter. Item)? Which of the following interaction diagrams is preferred? enter. Item(it, qty) n n : Sale : Process. Sale. Handler Every system should have a controller or handler A controller is class whose job is to control and coordinate the system events.

GRASP: The High Cohesion pattern § Pattern Name: High Cohesion Problem: How to Increase

GRASP: The High Cohesion pattern § Pattern Name: High Cohesion Problem: How to Increase the degree of Interconnection with in the same components. Solution: Increase the no of link or reference with in the same components � Cohesion is a measure of the degree to which an element contributes to a single purpose � The concepts of coupling and cohesion are not mutually exclusive but actually support each other

play. Game() : Monopoly. Game do. A The Cohesion example § Benefits of less

play. Game() : Monopoly. Game do. A The Cohesion example § Benefits of less coupling and high cohesion: Easy maintenance. Classes easy to understand, Software reuse do. B do. C play. Game() : Monopoly. Game : ? ? do. A do. B do. C : ? ?

Go. F: Singleton pattern Singleton: The Singleton pattern ensures that a class has only

Go. F: Singleton pattern Singleton: The Singleton pattern ensures that a class has only one instance and provides a global access to § Pattern Name: Singleton § Problem: How to create single object with global access. § Solution: Inherit the one class from another class and create object for derived class.

Singleton example access Class base { Public int add() { Return(x+y); } Public int

Singleton example access Class base { Public int add() { Return(x+y); } Public int sub() { Return (x-y); } } Class with single instance provide global Class derived: base { Public int mul() { Return (x*y); } Public int div() { Return (x/y); } } Public static void Main() { derived obj 1=new derived(); Console. writeline(“sum=“+(obj 1. add(1 0, 20)); Console. writeline(“sum=“+(obj 1. sub(1 0, 20)); Console. writeline(“sum=“+(obj 1. mul(1 0, 20)); Console. writeline(“sum=“+(obj 1. div(1 0, 20)); ]

Go. F: Strategy § Name: Strategy § Problem: How to design for Related system/algorithms/strategy

Go. F: Strategy § Name: Strategy § Problem: How to design for Related system/algorithms/strategy with change adaptation? § Solution: Design each system/algorithm/policy/strategy in a separate class, with a common interface.

strategy pattern example system Algorithm. Interfac e() Derivedsystem 1 Algorithm. Interfac e() Derivedsystem 2

strategy pattern example system Algorithm. Interfac e() Derivedsystem 1 Algorithm. Interfac e() Derivedsystem 2 Algorithm. Interfa ce() Derivedsystem 3 Algorithm. Interfa ce() q If any changes made in base class that will be reflected in derived class, b’coz we have common interface.

Thank you. .

Thank you. .