introduction the chapter will address the following questions: what is the difference between...

Introduction

The chapter will address the following questions: What is the difference between entity, interface, and control

objects? What is the basic concept object responsibility and how it is

related to message sending between object types? What is the important of considering object reuse during systems

design? What are three activities involved in completing object design? How do you construct an Ideal Object Model Diagram, CRC Card,

and Object Interaction Diagram?

An Introduction to Object-Oriented Design

Design Objects The objects that represented actual data within the business

domain in which the user was interested in storing were called Entity Objects.

Objects which represent a means through which the user will interface with the system are called Interface Objects.

Objects that hold application or business rule logic are called Control Objects.

A system’s functionality is distributed across all three types of objects. This practice makes the maintenance, enhancement, and

abstraction of objects simpler and easier to manage.


Design Objects The three object types correlate well with the client-server model.

The client is responsible for the application logic (control objects) and presentation method (interface objects).

The server is responsible for the repository (entity objects).


Design Objects Interface Objects:

It is through interface objects that the users communicate with the system.

The responsibility of the interface object is two fold: • It translates the user’s input into information that the system can

understand and use to process the business event.

• It takes data pertaining to a business event and translates the data for appropriate presentation to the user.

Each actor or user needs its own interface object to communicate with the system.

• In some cases the user may need multiple interface objects.

Interface Object


Design Objects Entity Objects:

Entity objects usually correspond to items in real life and contain information known as attributes which describe the different instances of the entity.

They also encapsulate those behaviors that maintains its information or attributes.

An entity object is said to be persistent meaning the object typically outlives the execution of a use case (or program).

• An entity object exists between use case executions because the information about that entity object is typically stored in a database (allowing for later retrieval and manipulation).

Entity Object


Design Objects Control Objects:

Control objects contain behavior that does not naturally reside in either the interface or entity objects.

• Such behavior is related to the management of the interactions of objects to support the functionality of the use case.

Controller objects serve as the “traffic cop” containing the application logic or business rules of the event for managing or directing the interaction between the objects.

Controller objects allow the scenario to be more robust and simplifies the task of maintaining that process once it is implemented.

As a general rule of thumb, within a use case, a control object should be associated with one and only one actor.

Control Object


Object Responsibilities In object-oriented design it is important to recognize an object has

responsibility. An object responsibility is the obligation that an object has to

provide a service when requested and thus collaborating with other objects to satisfy the request if required.

Object responsibility is closely related to the concept of objects being able to send and/or respond to messages.


Object Reusability The number one driving force for developing systems using object

oriented technology is the ability to reuse objects. Study performed by EDS using two different technologies (one

traditional, one OO) to develop the same system. The results were impressive as indicated in the following table:PL/1 19 calendar months 152 person months 265,000 lines of

code

Smalltalk 3.5 calendar months 10.4 person months 22,000 lines of codes

In order to maximize the ability to reuse objects, objects have to be correctly designed within a good generalization/specialization hierarchy. The goal is to make objects general enough to be easily used in other

applications.

Object Reusability Many companies achieve their highest level of reuse by exploiting

object frameworks. An object framework is a set of related, interacting objects

that provide a well-defined set of services for a accomplishing a task.

By using object frameworks, developers can concentrate on developing the logic that is new or unique to the application, thus reducing the overall time required to build the entire system.


The Process of Object Design

Object oriented design includes the following activities: Refining the use case model to reflect the implementation

environment Modeling object interactions and behavior that support the use

case scenario Updating the object model to reflect the implementation

environment


Refining the Use Case Model to Reflect the Implementation Environment

The use cases will be refined to include details of how the actor (or user) will actually interface with the system and how the system will respond to that stimulus to process the business event.

Refining the use cases is essential because they will be: The basis upon which subsequent user manuals and test scripts

are developed during systems implementation. Will be used by programmers to construct application

programs during systems implementation. May discover new use cases.



To simplify a use case, extract complex steps into its own use case called an extension use case. An extension use case extends the functionality of the original

use case. • An extension use case can only be invoked by the use case it is

extending. It may be discovered that two or more use cases perform steps of

identical functionality. • It is best to extract these common steps into its own separate use

case called an abstract use case that can be “called” by other use cases.

• An abstract use case represents a form of “reuse”.

Generate OrderError Report

Send OrderRejection Notice

Calculate Subtotal& Sales Tax

Submit PropostionOrder

Generate WarehousePicking Ticket

uses uses

extends extends

Extension Use Cases

Abstract Use Cases



Step 1 - Transforming the “Analysis Use Cases to “Design” Use Cases: In this step, each use case (which was created in analysis) is

refined to reflect the physical aspects of the implementation environment for the new system.

Keep the original analysis use cases separate from the refined design use cases to allow maximum flexibility in reusing use cases for variations of different physical implementations.

DESIGN USE CASEAuthor:__K. Dittman Date:__10/17/96_USE CASE NAME: Submit Promotion OrderACTOR: Club Member - System user: Promotion Order SpecialistDESCRIPTION: Describes the process when a club member submits a promotion order to either indicate the

products they are interested in ordering or declining to order during this promotion.NORMAL COURSE: The main window is currently displayed on the screen waiting for the promotion order

specialist to select a menu option.1. When a promotion order is received from the club member, this use case is initiated when

the promotion order specialist selects the option “Process Promotion Order”, displaying awindow requesting the club member’s NUMBER to be entered.

2. The promotion order specialist enters the MEMBER NUMBER. The system verifies thatthe number is valid and if it is, displays three windows. The first window contains the clubmember’s personal information including: NAME, STATUS, STREET ADDRESS, P. O.BOX, CITY, STATE, ZIP, DAYTIME PHONE NUMBER, DATE OF LAST ORDER,BALANCE DUE, and BONUS BALANCE. The second window contains the promotionorder header record information that was created when the promotion was sent to the clubmember. The second window contains: ORDER NUMBER, ORDER CREATION DATE,ORDER AUTOMATIC FILL DATE, SUB-TOTAL COST, SALES TAX, and ORDERSTATUS. The third window contains the individual ordered products. This is a multi-linedwindow with the first order line containing the selection of the month information. Thisrecord was also created when the promotion was sent to the club member. The thirdwindow contains: PRODUCT NUMBER, PRODUCT NAME, QUANTITY AVAILABLE,QUANTITY ORDERED, QUANTITY BACKORDERED, SUGGESTED UNIT PRICE,PURCHASED UNIT PRICE, EXTENDED COST, CREDITS EARNED, and ORDEREDPRODUCT STATUS.

3. The promotion order specialist checks to see if the club member has made any address orphone number changes on the promotion order.If no changes have been made, the promotion order specialist checks the promotion orderto see if any products are being ordered.If products are being ordered, the promotion order specialist positions the cursor in theordered product window.

4. The promotion order specialist checks the promotion order to see if the club member hasaccepted or declined the selection of the month. If accepted, the promotion order specialistchecks quantity ordered to see if it is greater than one. If so, the promotion order specialistedits the QUANTITY ORDERED field to reflect the new quantity. The system calculatesthe new EXTENDED COST by multiplying the PURCHASED UNIT PRICE times theQUANTITY ORDERED and then advances the cursor to the next line.

5. The promotion order specialist checks the promotion order to see if the club member hasordered additional products. If so, the promotion order specialist enters the PRODUCTNUMBER of the next item being ordered. The system displays the PRODUCT NAME,QUANTITY AVAILABLE, and the SUGGESTED UNIT PRICE. The promotion orderspecialist enters the QUANTITY ORDERED, and the PURCHASE UNIT PRICE. Thesystem calculates the new EXTENDED COST by multiplying the PURCHASE UNITPRICE times the QUANTITY ORDERED. It also updates the ORDERED PRODUCTSTATUS field to be “open”, and then advances the cursor to the next line.This step is repeated until all ordered products have been input.

6. Once all ordered products have been entered into the system, the promotion order specialistcommits the order.Invoke extension use case Calculate Subtotal and Sales Tax.The system checks the club member’s STATUS. If the club member is in good standing,invoke extension use case Generate Warehouse Picking Ticket.The picking ticket will be routed to the warehouse and printed on their printer(HP.PRT.20195).For each product ordered, the system reduces the QUANTITY AVAILBLE by theQUANTITY ORDERED and saves the changes.

7. Once the order has been committed, the system will prompt the user if they want to processa new order or cancel the transaction.

1

2

3

5

ALTERNATECOURSE:

2. If the MEMBER NUMBER is invalid, the system displays a window with the errormessage “Member Number Not on File”. The promotion order specialist can then re-enterthe number or cancel the transaction.

3a. If the club member indicates an address or telephone number change on the promotionorder, the promotion order specialist selects the option to update the club member’spersonal information. The personal information window is activated for update. Thepromotion order specialist updates the required fields and saves the changes.

3b. If the club member is not ordering product at this time, the promotion order specialistclicks the button “Order Declined”. The system modifies the ORDER STATUS field tohave a status of “closed” and modifies the ORDERED PRODUCT STATUS field (for theselection of the month) to have a status of “rejected”. The changes are saved and then thesystem prompts the user to process a new order or cancel the transaction.

4. If the club member is not ordering the selection of the month, the promotion orderspecialist clicks the button “Selection of the Month Declined”. The system modifies theORDERED PRODUCT STATUS field (for the selection of the month) to have a status of“rejected”. The cursor is then advanced to the next line.

5a. If no additional products are being ordered, proceed to step 6 of the normal course.5b. If the PRODUCT NUMBER or QUANTITY ORDERED is not valid, the system hi-lights

the fields indicating those fields have invalid entries. The promotion order specialist eithercorrects the entries or advances to the next line. In a later step an error report will begenerated for any invalid entries.

6a. If the club members status is not acceptable, invoke abstract use case Send Order RejectionNotice. The system modifies the ORDER STATUS field to have a status of “on holdpending payment”. The changes are saved and the system prompts the user to process anew order or cancel the transaction.

6b. If the QUANTITY ORDERED is greater than the QUANTITY AVAILBLE, the NUMBERTO BE PICKED will be set to the QUANTITY AVAILBLE. The system will reduce theQUANTITY AVAILABLE to zero(if it is not already) and update QUANTITYBACKORDERED to be equal to the QUANTITY ORDERED minus the NUMBER TO BEPICKED.

6c. If there are invalid product numbers or quantity ordered entries, invoke abstract use caseGenerate Order Error Report.

PRE-CONDITION: Use case Send Club Promotion has been processed.

Use case User Logs In has been processed.

POST-CONDITION: Promotion order has been recorded and the Picking Ticket has been routed to the Warehouse.

ASSUMPTIONS:

4

5



Step 2 - Updating the Use Case Model Diagram and Other Documentation to Reflect Any New Use Cases: In this step the use case model diagram, the use case

dependency diagram, and the actor and use case glossaries should be updated to reflect any new information introduced in step 1.

• It is very important to keep documentation accurate and current.


Modeling Object Interactions and Behaviors that Support the Use Case Scenario

In this activity we want to identify and categorize the design objects required by the functionality that was specified in each use case, and identify the object interactions, their responsibilities, and their behaviors.

Step 1 - Identify and Classify Use Case Design Objects: In this step we examine each design use case to identify and

classify the types of objects (interface, control, and entity) required by the logic of the use case or business scenario.

INTERFACE OBJECTS CONTROLLER OBJECTS ENTITY OBJECTSMember Services Main Window Order Processor MEMBEROrder Processing Window Ticket Generator PRODUCTPicking Ticket Printer MEMBER ORDER

MEMBER ORDERED PRODUCT

1 2 3



Step 2 - Identify Object Attributes: During both analysis and design, object attributes may be

discovered. In this step we examine each use case for additional attributes

which hasn’t been previously identified, and update our object association diagram to include attributes.

MEMBER

Member NumberMember NameMember StatusMember Street AddressMember P.O. Box NumberMember CityMember StateMember Zip CpdeMember Daytime Phone NumberDate Of Last OrderMember Balance DueMember Bonus Balance

persistent


Quantity OrderedQuantity ShippedQuantity BackorderedPurchased Unit PriceExtended CostCredits EarnedOrdered Product Status

persistent

MEMBER ORDER

Order NumberOrder Creation DateOrder Automatic Fill DateOrder Sub-total CostOrder Sales TaxOrder Status

persistent

PRODUCT

Product NumberQuantity AvailableProduct NameSuggested Unit Price

persistent

1+

sells

sold as

placed



Step 3 - Model High-Level Object Interactions for a Use Case In this step an Ideal Object Model Diagram is created to

model the interactions of the design objects involved in each use case.

An ideal object model diagram includes symbols to represent actors, interface, control and entity objects, and arrows which represent messages or communication between the objects.

PROMOTIONORDER

SPECIALIST

WAREHOUSE

CLUB MEMBER

Picking Ticket Printer

Order ProcessingWindow

PRODUCT ONORDER

MEMBER ORDER

Main Window

Ticket Generator

MEMBER

PRODUCT

Order Processor

SUBMIT PROMOTION ORDERIDEAL OBJECT DIAGRAM

1 2

3



Step 4 - Identify Object Behaviors and Responsibilities This step involves the following tasks:

• Analyze the use cases to identify required system behaviors.

• Associate behaviors and responsibilities with objects.

• Examine object model for additional behaviors

• Verify classifications Our first task in identifying the object behaviors and

responsibilities is accomplished by examining each use case description to identify all action verb phrases.

• Action verb phrases suggest behaviors that are required to complete a use case scenario.

DESIGN USE CASEAuthor:__K. Dittman Date:__10/17/96_USE CASE NAME: Submit Promotion OrderACTOR: Club Member - System user: Promotion Order SpecialistDESCRIPTION: Describes the process when a club member submits a promotion order to either indicate the

products they are interested in ordering or declining to order during this promotion.NORMAL COURSE: The main window is currently displayed on the screen waiting for the promotion order

specialist to select a menu option.1. When a promotion order is received from the club member, this use case is initiated when

the promotion order specialist selects the option “Process Promotion Order”, displaying awindow requesting the club member’s NUMBER to be entered.

2. The promotion order specialist enters the MEMBER NUMBER. The system verifies thatthe number is valid and if it is, displays three windows. The first window contains the clubmember’s personal information including: NAME, STATUS, STREET ADDRESS, P. O.BOX, CITY, STATE, ZIP, DAYTIME PHONE NUMBER, DATE OF LAST ORDER,BALANCE DUE, and BONUS BALANCE. The second window contains the promotionorder header record information that was created when the promotion was sent to the clubmember. The second window contains: ORDER NUMBER, ORDER CREATION DATE,ORDER AUTOMATIC FILL DATE, SUB-TOTAL COST, SALES TAX, and ORDERSTATUS. The third window contains the individual ordered products. This is a multi-linedwindow with the first order line containing the selection of the month information. Thisrecord was also created when the promotion was sent to the club member. The thirdwindow contains: PRODUCT NUMBER, PRODUCT NAME, QUANTITY AVAILABLE,QUANTITY ORDERED, QUANTITY BACKORDERED, SUGGESTED UNIT PRICE,PURCHASED UNIT PRICE, EXTENDED COST, CREDITS EARNED, and ORDEREDPRODUCT STATUS.

3. The promotion order specialist checks to see if the club member has made any address orphone number changes on the promotion order.If no changes have been made, the promotion order specialist checks the promotion orderto see if any products are being ordered.If products are being ordered, the promotion order specialist positions the cursor in theordered product window.

4. The promotion order specialist checks the promotion order to see if the club member hasaccepted or declined the selection of the month. If accepted, the promotion order specialistchecks quantity ordered to see if it is greater than one. If so, the promotion order specialistedits the QUANTITY ORDERED field to reflect the new quantity. The system calculatesthe new EXTENDED COST by multiplying the PURCHASED UNIT PRICE times theQUANTITY ORDERED and then advances the cursor to the next line.

5. The promotion order specialist checks the promotion order to see if the club member hasordered additional products. If so, the promotion order specialist enters the PRODUCTNUMBER of the next item being ordered. The system displays the PRODUCT NAME,QUANTITY AVAILABLE, and the SUGGESTED UNIT PRICE. The promotion orderspecialist enters the QUANTITY ORDERED, and the PURCHASE UNIT PRICE. Thesystem calculates the new EXTENDED COST by multiplying the PURCHASE UNITPRICE times the QUANTITY ORDERED. It also updates the ORDERED PRODUCTSTATUS field to be “open”, and then advances the cursor to the next line.This step is repeated until all ordered products have been input.

6. Once all ordered products have been entered into the system, the promotion order specialistcommits the order.Invoke extension use case Calculate Subtotal and Sales Tax.The system checks the club member’s STATUS. If the club member is in good standing,invoke extension use case Generate Warehouse Picking Ticket.The picking ticket will be routed to the warehouse and printed on their printer(HP.PRT.20195).For each product ordered, the system reduces the QUANTITY AVAILBLE by theQUANTITY ORDERED and saves the changes.

7. Once the order has been committed, the system will prompt the user if they want to processa new order or cancel the transaction.

ALTERNATECOURSE:

2. If the MEMBER NUMBER is invalid, the system displays a window with the errormessage “Member Number Not on File”. The promotion order specialist can then re-enterthe number or cancel the transaction.

3a. If the club member indicates an address or telephone number change on the promotionorder, the promotion order specialist selects the option to update the club member’spersonal information. The personal information window is activated for update. Thepromotion order specialist updates the required fields and saves the changes.

3b. If the club member is not ordering product at this time, the promotion order specialistclicks the button “Order Declined”. The system modifies the ORDER STATUS field tohave a status of “closed” and modifies the ORDERED PRODUCT STATUS field (for theselection of the month) to have a status of “rejected”. The changes are saved and then thesystem prompts the user to process a new order or cancel the transaction.

4. If the club member is not ordering the selection of the month, the promotion orderspecialist clicks the button “Selection of the Month Declined”. The system modifies theORDERED PRODUCT STATUS field (for the selection of the month) to have a status of“rejected”. The cursor is then advanced to the next line.

5a. If no additional products are being ordered, proceed to step 6 of the normal course.5b. If the PRODUCT NUMBER or QUANTITY ORDERED is not valid, the system hi-lights

the fields indicating those fields have invalid entries. The promotion order specialist eithercorrects the entries or advances to the next line. In a later step an error report will begenerated for any invalid entries.

6a. If the club members status is not acceptable, invoke abstract use case Send Order RejectionNotice. The system modifies the ORDER STATUS field to have a status of “on holdpending payment”. The changes are saved and the system prompts the user to process anew order or cancel the transaction.

6b. If the QUANTITY ORDERED is greater than the QUANTITY AVAILBLE, the NUMBERTO BE PICKED will be set to the QUANTITY AVAILBLE. The system will reduce theQUANTITY AVAILABLE to zero(if it is not already) and update QUANTITYBACKORDERED to be equal to the QUANTITY ORDERED minus the NUMBER TO BEPICKED.

6c. If there are invalid product numbers or quantity ordered entries, invoke abstract use caseGenerate Order Error Report.

PRE-CONDITION: Use case Send Club Promotion has been processed.

Use case User Logs In has been processed.

POST-CONDITION: Promotion order has been recorded and the Picking Ticket has been routed to the Warehouse.

ASSUMPTIONS:



Step 4 - Identify Object Behaviors and Responsibilities Once the behaviors have been identified, we must determine if

the behaviors are manual or will they be automated. If they are to be automated, they must be associated with the

appropriate object type that will have the responsibility of carrying out that behavior.

Behavior Automated/Manual Object TypeProcess promotion order Manual/Automated ControlSend promotion order ManualSelect system option ManualDisplay window Automated InterfaceEnter member number ManualVerify member number Automated EntityReport member information Automated EntityReport member orderinformation

Automated Entity

Check order for changes ManualCheck order for products beingordered

Manual

Position cursor Manual/Automated InterfaceCheck order for selection of themonth

Manual

Check quantity ordered ManualEnter quantity ordered ManualCalculate extended cost Automated EntityEnter product number ManualReport product information Automated EntityUpdate ordered product status Automated EntityCommit order ManualVerify member status Automated EntityProcess picking ticket Automated ControlRoute picking ticket towarehouse

Automated Interface

Print picking ticket Automated InterfacePrompt User Automated InterfaceCancel transaction Automated Control

Behavior Object TypeProcess promotion order ControlProcess picking ticket ControlCancel transaction ControlVerify member number EntityReport member information EntityReport member order information EntityCalculate extended cost EntityReport product information EntityUpdate ordered product status EntityVerify member status EntityDisplay window InterfacePosition cursor InterfaceRoute picking ticket to warehouse InterfacePrint picking ticket InterfacePrompt User Interface



Step 4 - Identify Object Behaviors and Responsibilities Our third task is aimed toward identifying all behaviors that

can be associated with an object type, and to identify collaborations amongst those objects.

• A popular tool for documenting the behaviors and collaborations for an object is the Class Responsibility Collaboration (CRC) Card.

• A CRC card contains all use case behaviors and responsibilities that have been associated with a specific object type.

Object Name: Member OrderSub Object:Super Object

Behaviors and Responsibilities CollaboratorsReport order information Member Ordered ProductCalculate sub-total costCalculate sales taxUpdate order statusCreate ordered ProductDelete ordered Product



Step 4 - Identify Object Behaviors and Responsibilities Analysis of the use case scenarios may not reveal all behaviors

for any given object type. By examining the object model, you may find additional

behaviors (not mentioned in the use case scenarios) that need to be assigned to an object type.

• Analyze the relationships between any two objects.

– How are those relationships created or deleted?

– Which object should be assigned that responsibility?

– As a general rule, the object that controls the relationship should be responsible for creating or deleting the relationship.



Step 4 - Identify Object Behaviors and Responsibilities There are four “implicit” behaviors that can be associated with

any object class. Those include the ability to: • create new instances,

• change its data or attributes,

• delete instances,

• and display information about the object class.



Step 4 - Identify Object Behaviors and Responsibilities While examining the use cases to identify and associate

behaviors with object types, we also focus on identifying the collaboration or cooperation that is necessary between object types.

• If an object needs another object’s attribute to accomplish a behavior, the collaborating object needs to have a behavior or method to provide that attribute.

Identifying the collaboration of object types is necessary to ensure that all use case objects work in harmony to complete the processing required for the business event.



Step 4 - Identify Object Behaviors and Responsibilities The last task is verify the results from the previous tasks.

• This consists of conducting walkthroughs with the appropriate users.

• One verification approach that is commonly used is role playing.

– In role playing, the use case scenarios are acted out by the participants.

– The participants may assume the role of an actor or an object type that collaborate to process a hypothetical business event.

– Message sending is simulated by using an item such as a ball that is passed (or sometimes thrown) between the participants.



Step 5 - Model Detailed Object Interactions for a Use Case In this step a detailed model will be constructed of how the

objects will interact with each other to provide the functionality specified in each design use case.

• This model is called an interaction diagram.

– Interaction diagrams show us in great detail how the objects interact with each other over time

SystemBorder

Customer selects “process promotionorder” option

Do until no more member orders

Customer enters member number

If member number valid

Get current promtion order header

Do until no more ordered products

Get ordered product information Get product information

Display order

Else

Display error message

Clear Message

Endif

MainWindow

OrderProcesser

OrderProcessing

Window

StartStart orderprocess

Request member number

isMember

Member MemberOrder

reportOrder

MemberOrderedProduct

Product

Validate membernumber

Display order

Display error message

reportProduct

reportOrderedProduct

Clear

New member number


Updating the Object Model to Reflect the Implementation Environment

In this activity the object model is refined to include the behaviors or implementation methods it needs to possess. Each behavior or method is given a unique name.

• Normally these names reflect the programming language used to develop the system.

MEMBER

Member NumberMember NameMember StatusMember Street AddressMember P.O. Box NumberMember CityMember StateMember Zip CpdeMember Daytime Phone NumberDate Of Last OrderMember Balance DueMember Bonus Balance

isMemberreportMemberreportStatus

persistent


Quantity OrderedQuantity ShippedQuantity BackorderedPurchased Unit PriceExtended CostCredits EarnedOrdered Product Status

setStatuscalculateQuantityBackorderedcalculateExtendedCostreportOrderedProduct

persistent

MEMBER ORDER

Order NumberOrder Creation DateOrder Automatic Fill DateOrder Sub-total CostOrder Sales TaxOrder Status

reportOrdersetStatusCalculateSalesTaxcalculateSubtotal

persistent

PRODUCT

Product NumberQuantity AvailableProduct NameSuggested Unit Price

reportProductcalculateQuantityAvailable

persistent

1+

sells

sold as

placed

Summary

Introduction An Introduction to Object-Oriented

Design The Process of Object Design

introduction the chapter will address the following questions: what is the difference between...

Documents

types of objects

controller objects

interactions of objects

repository entity objects

multiple interface objects

object design

abstraction of objects

object types