OBJECT ORIENTED ANALYSIS AND DESIGN OBJECT ORIENTED ANALYSIS
OBJECT ORIENTED ANALYSIS AND DESIGN
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 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
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 STATE CHART DIAGRAM COMPONENT DIAGRAM DEPLOYMENT DIAGRAM
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 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 user Modify user
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 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 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 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 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 � 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 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 +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() Example: Customer Account +Verifyuser() +Deposit() +Withdraw() +Getbalance()
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 y OR Wo rk For Bank Furnitur e
‘N’ Array Association: Person Grandparent Parent Child
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
Association: Person Aggregation: Player Having Car Team Player
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() 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: 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 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 1. Sequence diagram 2. collaboration diagram
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. 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 object : X -- : Y <Destroy >
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 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 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 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 : 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 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 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 � 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 Simple Action Calculate Total Transition- Represent direction of data flow
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 Pattern 3 Join View Score
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? 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 IDLE State Event Offhook ACTIVE Final State Onhook Transition
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 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 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 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 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: 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 & 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 Name Component
� Dependency DB UI relationship Update Dependency Relationship
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 � Association relationship DB Nod e Component name
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 � 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); } 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: 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; 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 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 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 a sale?
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
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 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 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 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 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, 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. . ) : 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. 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 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 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 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 : 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 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 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. 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 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 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 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 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 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 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. .
- Slides: 89