The Object-Oriented Design Process

Transcription

1 The Object-Oriented Design Process Part 1: Techniques & Tools OOdesignProcess 1

2 Program development 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 OOdesignProcess 2

3 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:

4 Program development As noted on the previous slide, process steps feed back into previous steps Less a cycle than a spiral Source:

5 Program development 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 OOdesignProcess 5

6 Example: voice messaging system 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 OOdesignProcess 6

7 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

8 Use cases 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 OOdesignProcess 8

9 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

10 Use cases in voice mail example 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 OOdesignProcess 10

11 Example: use case for reach an extension 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. OOdesignProcess 11

12 Use case variants Scenarios that could deliver a valuable outcome could also fail to do so Use cases include variants to describe these situations OOdesignProcess 12

13 Example: use case for reach an extension 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. OOdesignProcess 13

14 Object-oriented design 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 OOdesignProcess 14

15 Design Phase 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 OOdesignProcess 15

16 Objects & classes 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 OOdesignProcess 16

17 Objects & classes 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 OOdesignProcess 17

18 Purposes of design phase Gather information as foundation for implementation phase Reduce time required for implementation and testing If done correctly, should be most timeconsuming phase OOdesignProcess 18

19 Results of design phase Text descriptions of classes/responsibilities Diagrams depicting: relationships between classes usage scenarios changes in class state OOdesignProcess 19

20 Identifying classes 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 OOdesignProcess 20

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 21

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 22

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. 23

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 24

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

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 26

27 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

28 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 transaction withdrawal PINcode communication account deposit balance inquiry ATM keypad 29

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 30

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 31

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 32

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 33

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 34

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 35

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 36