The Object-Oriented Design Process

OOdesignProcess 1

Part 1: Techniques & Tools

Program development

OOdesignProcess 2

• In theory, 3 phase development process: – Analysis: figure out the problem – Design: develop the solution – Implementation: write & test code

Illustration at left is a (naïve) depiction of C++ development process; actually, it’s just the last phase of the process described above Source: w3processing.com

Program development • In reality, process is not linear

– Implementation experience often leads to design modifications

– New requirements lead to additional analysis/design

Although closer to reality, still a naïve view. The cycle isn’t this pretty Source: www.utdcom.com

Program development • As noted on the previous slide, process steps feed

back into previous steps • Less a cycle than a spiral

Source: http://www.sdmsystems.com/

Program development

OOdesignProcess 5

• OO design process facilitates evolutionary software development: – Problem domain, represented by objects and classes, is

relatively stable – Methods within domain can be changed/improved as

necessary – With a good specification, can continuously improve

implementation without breaking anything

Example: voice messaging system

OOdesignProcess 6

• Your textbook uses the example of a simple voice mail system, which can do the following: – Receive voice messages as input – Store messages – Retrieve (and play back) messages – Delete messages

• In addition to the tasks above, the system is also capable of recording, storing, and playing back an outgoing message, and has passcode protection to ensure that only an authorized user can access his/her own “mailbox”

Analysis Phase

• In the analysis phase, we progress from a vague understanding of the problem to a precise description of tasks for the software to carry out

• Goal of this phase is functional specification: a precise description of what the software should do

OOdesignProcess 7

Use cases

OOdesignProcess 8

• One form of functional specification • Describe intended behavior of system from user

standpoint • Enumerate all tasks system does for user (one use

case for each task) • Describe what needs to be done, not how;

algorithm selection occurs in implementation phase, use cases are analysis tools

Use cases

• Each use case is concerned with a specific scenario in which the system interacts with people or entities outside the system (users, for example)

• The user or entity is called an actor • The use case describes the steps necessary

to bring the scenario to a completion point that is of some value to one of the actors

OOdesignProcess 9

Use cases in voice mail example

OOdesignProcess 10

• The set of use cases in the voice messaging system might include the following scenarios: – Reaching an extension – Leaving a message – Logging in – Retrieving messages – Changing the greeting – Changing the passcode

Example: use case for “reach an extension”

OOdesignProcess 11

1. User dials main number for voice mail system

2. Voice mail system speaks a prompt: “Enter mailbox number followed by a #.”

3. User keys in recipient’s extension number 4. Voice mail system speaks another prompt:

“You have reached mailbox xxxx. Please leave a message now.”

Use case variants

OOdesignProcess 12

• Scenarios that could deliver a valuable outcome could also fail to do so

• Use cases include variants to describe these situations

Example: use case for “reach an extension”

OOdesignProcess 13

1. User dials main number for voice mail system 2. Voice mail system speaks a prompt: “Enter mailbox

number followed by a #.” 3. User keys in recipient’s extension number 4. Voice mail system speaks another prompt: “You have

reached mailbox xxxx. Please leave a message now.” Variation #1: 1. In step 3, user enters an invalid extension 2. Voice mail system speaks prompt: “You have typed an

invalid mail box number.” 3. Resume operation at step 2.

Object-oriented design

OOdesignProcess 14

• Two questions, initially: – What are the players interacting in the system? – How should these players be represented?

• Answer to first question is the set of objects • Answer to second question is the set of

classes that describe the objects

Design Phase

OOdesignProcess 15

• In this phase, the program designer structures tasks identified in analysis phase into a set of interrelated classes

• Major goals of design phase: – Identify classes – Identify class responsibilities – Identify relationships between classes

• Again, these are goals, not steps; identification of one aspect of a class may lead to changes in, discovery of, others

Objects & classes

OOdesignProcess 16

• Objects: entities that interact in a computer program; properties include: – state: collection of information held by object – behavior: operations supported by object – identity: unique characteristic that differentiates

two objects with identical state & behavior • Class: describes properties of related objects

Objects & classes

OOdesignProcess 17

• Class definition describes what an object is; includes: – operations allowed on the object – possible states of the object

• Objects formed using a particular class definition are said to be instances of the class

Purposes of design phase

OOdesignProcess 18

• Gather information as foundation for implementation phase

• Reduce time required for implementation and testing

• If done correctly, should be most time- consuming phase

Results of design phase

OOdesignProcess 19

• Text descriptions of classes/responsibilities • Diagrams depicting:

– relationships between classes – usage scenarios – changes in class state

Identifying classes

OOdesignProcess 20

• One of the major tasks of the design phase is finding the classes in a problem

• Need to examine functional specification to find objects, then develop classes to describe them

21

Finding classes • Carefully read requirements specification

or description of design goals • Discuss what the system should do:

• expected inputs • desired responses

• Look for noun phrases (nouns, nouns modified by adjectives) in spec

• Note that the spec usually includes use cases as well

22

Finding Classes • Having identified nouns, change plural

nouns to singular form & make preliminary list

• 3 categories will emerge from this list: • obvious classes • obvious nonsense • not sure

• Your candidate classes will emerge from the first & last categories

• On the next few slides, we’ll apply these ideas to the ATM description

23

Nouns & noun phrases An automatic teller machine (ATM) performs various financial transactions (deposits, withdrawals, and balance inquiries) in response to user requests. The user is able to use the machine if the 4-digit PIN code s/he types in to the ATM keypad matches the code embedded in the magnetic strip on his/her card, which is read by the machine. If the user enters an invalid code, an error message is displayed, and the user is given another chance to enter the code correctly; a second incorrect code results in the user’s card being retained by the machine. Once a valid code is entered, the user may access his/her account for transactions. When a balance inquiry is requested, the machine prints the information on a receipt. When a deposit is requested, the machine receives the deposit envelope and the amount specified is added to the user’s account balance. When a withdrawal is requested, the account balance is checked to ensure that sufficient funds are available, and, if so, the machine dispenses cash and the account is debited by the withdrawal amount.

24

Initial elimination phase

• Distill redundant terms down to the single term that best describes the concept

• Eliminate noun phrases that describe things outside the system

• Eliminate nouns that are standins for verbs

25

Narrowed list

ATM account transaction amount specified deposit information withdrawal balance balance inquiry PINcode ATM keypad error message user request

26

Choosing candidate classes

• Model physical objects: ATM, keypad • Model conceptual entities that form a

cohesive abstraction • “Error message,” “user request” and

“information” are terms that suggest communication between the machine and the user

• This suggests some sort of Communication class, which can be used to accept requests and convey information

Choosing candidate classes

• Model categories of classes as individual, specific classes - don’t try to set up super/subclass relationships at this stage • Several transaction types – e.g. deposit and

withdrawal – each deserve to be considered separate classes

• Transaction could also be a class unto itself

Choosing candidate classes

• Model values of attributes, not attributes themselves • “Amount specified” is an attribute of

deposit and withdrawal transactions • “Balance” is an attribute of account

29

Second revised class list

ATM account transaction deposit withdrawal balance inquiry PINcode ATM keypad communication

30

Identifying missing classes

• Once identified, extending categories can help in finding missing classes

• For example, the Communication class, we can identify subclasses Message, which just provides information to the user, and Menu, which provides information and waits for a response

31

Identifying missing classes

• Classes may be found by looking at descriptions of existing classes - for example, keypad is described as “a group of keys” - but what is a key?

• Classes may be missing because the spec was imprecise - for example, our spec doesn’t mention a display device, but such a device is clearly necessary

32

CRC cards

• Design tool & method for discovering classes, responsibilities, & relationships

• Record on note card: • class name & purpose • general responsibilities • name(s) of class(es) this class depends on to

fulfill its responsibilities

33

Why use cards?

• Could record this information using paper, whiteboard, etc.

• Advantages of cards: • portable: can easily group & rearrange cards to

illustrate/discover relationships between classes

• disposable: easily modified or discarded as design changes

34

Example CRC card for ATM

Class: ATM (performs financial services for a bank customer) Responsibilities Collaborations • create & initialize Transaction transactions • display greeting User Message • display main menu Menu • tell cancel key Cancel Key to reset • check for a cancel Cancel Key • eject receipt Receipt Printer • eject bank card Bank Card Reader

Don’t have to list collaborators on same line as responsibilities - but doesn’t hurt to do so This class is unusual for two reasons:

• large # of responsibilities

• fulfills all responsibilities via collaboration

35

More ATM examples Class: Account (represents account in bank database) Responsibilities Collaborations • Know account balance • Accept deposits • Accept withdrawals

Class: Transaction (performs financial service & updates account) Responsibilities Collaborations • Execute financial transaction • Gather information Menu, Form, User Message • Remember data relevant to transaction • Commit transaction Account to database • Check to see if cancel key Cancel Key has been pressed

36

Some notes on CRC cards

• Cards are meant to be transitory tools for proposing designs

• Meant as discovery tool, not archival information

• For design documentation, use UML diagrams accompanied by explanatory text