CS 151 ObjectOriented Design August 29 Class Meeting

CS 151: Object-Oriented Design August 29 Class Meeting Department of Computer Science San Jose State University Spring 2012 Instructor: Ron Mak www. cs. sjsu. edu/~mak

Project Teams o Send as soon as possible to ron. mak@sjsu. edu n n n o Team name Team members (3 or 4 students per team) Team member email addresses First team assignment will be next week. SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 2

Key Points from Last Time o Developing Great Software can be a messy business! o Be willing to admit you made some bad design decisions and fix them. n The sooner the better! _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 3

A Good Design? Such a pretty diagram! From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006. SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 4

But It Doesn’t Scale! SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006. 5

A Much Better Design after Encapsulation SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006. 6

What Did We Encapsulate? o The original Guitar. Spec class n The varying properties of guitars. o o Rick decided to add the number of strings to the original set of guitar properties. The final Instrument. Spec class n The varying properties of all the different types of instruments. o o Guitar properties are different from trombone properties. Contains the properties in a hash map (hash table). _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 7

Application Development Big Picture SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 8

Analysis Precedes Design o Understand the problem. n o Gather requirements from the client. n n o Client: the person for whom you’re writing the software Talk to Rick! Ask him what he wants the software to do. Write a functional specification. n n o The application is no good if it doesn’t do what it’s supposed to do. Defines what the software is supposed to do, not how. Contains use cases. Understandable by both the client and the developers. The client may come up with new or modified requirements. Create and demo a mockup of the application. n The client may come up with new or modified requirements. SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 9

A Truly Messy Business If you thought software design was messy. . . analysis can be just as messy! o Clients often don’t know what they want. n o Eliciting requirements from a client is tough! n n n o “I’ll know it when I see it. ” Many iterations (multiple interviews with the client). Many show-and-tell sessions using application mock-ups. Many revisions to the functional specification. Of course, a client can change his mind during design. n Example: Rick decides to sell more types of instruments. SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 10

What is a Requirement? A requirement is a specific task that your software application must do in order to work correctly. This is actually the definition of a functional requirement. SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 11

Sources of Requirements o o o o Client End users Software developers Development managers Technology providers Stakeholders All can have conflicting ideas of what the application is supposed to do. All of them change their minds about the requirements. _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 12

Types of Requirements o Functional requirements n What the system shall be able to do or allow users to do. o o n o “The phone shall use GPS to determine the wearer’s location. ” “Users shall be able to choose either Option A or Option B. ” Describe the interactions between the system and its environment, independent of its implementation. Nonfunctional requirements n Usability, reliability, performance, supportability, etc. o o o n “The system must respond to the user within 15 seconds. ” “The system must run on Windows and Linux servers. ” “The new GUI should resemble the existing GUI. ” Constraints that the system must meet. _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 13

Requirements Must Have. . . o Completeness n o Consistency n o No two requirements can contradict each other. Clarity n o Are all system features described by requirements? Each requirement must be unambiguous. Correctness n n No errors in the requirements. Can each system function be traced to a requirement? _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 14

Requirements Must Have, cont’d o Realism n o Verifiability n o Can the system be implemented? Can the system be tested? Traceability n Can each requirement be traced to a system function? _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 15

Example Application: Automated Dog Door o Todd and Gina hire your programming team to develop a dog door with a remote button so they can open the door from their bedroom when their dog Fido wakes them up in the middle of the night. SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006. 16

Initial Requirements o o o Push the button on the remote and open the door. Push the button again to close the door. Do these requirements satisfy what Todd and Gina say they want? _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 17

Get More Requirements o Interview the clients. Ask probing questions. n How tall is Fido? o n How many buttons do you want on the remote? o n o The door must be at least 12” tall. Only one that toggles between opening and closing the door. Should the door close automatically after a while? Developers should do brainstorming. n Look at the problem from many points of view. _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 18

Stated and Implied Requirements o Stated by the client n n o Implied (what do you think? ) n n o The door should be able to be opened remotely. The door should close after dog goes out. The door should not close while the dog is going through it. The door should close automatically after a wait. Also implied n n The clients want the application soon. It must be cost-effective. _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 19

Test the Requirements with Use Cases SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006. 20

What is a Use Case? o A complete sequence of steps that provides value to one of the actors. n Actor: Someone or something that is not part of your system. o o o Describes something that your application must do. n A single goal of your application. o o Todd, Gina, Fido You’re building a software application to implement an automatic dog door, not simulations of people or dogs. Todd and Gina remotely let Fido out from their bedroom. Initiated by an actor. _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 21

Parts of a Use Case o Name n o Description n o Who’s involved? Preconditions n o One or two paragraphs describing the purpose and goal. Actors n o Verb-Noun (example: Let out the dog) What must be true before the use can start? Trigger n What initiates the sequence of steps? SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 22

Parts of a Use Case, cont’d o Primary sequence n o Postconditions n o n n Variations of the basic flow Alternate triggers Alternate postconditions Nonfunctional requirements n o What must be true when the use case ends successfully? Alternate sequences n o Most common sequence of steps Examples: performance, user interface Glossary SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 23

Example Alternate Sequence From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006. SJSU Dept. of Computer Science Fall 2013: August 29 6. Fido does his business. 6. 1 The door shuts automatically. 6. 2 Fido barks to be let back inside. 6. 3 Todd or Gina hears Fido barking (again). 6. 4 Todd or Gina presses the remote control button. 6. 5 The dog door opens (again). 7. Fido goes back inside. CS 151: Object-Oriented Design © R. Mak 24

Some Key Points for Success o The best way to get good requirements is to understand what the application is supposed to do. n o To be a successful developer, you must understand the application better than your client. n n o Make sure the application works the way the client wants it to work, not necessarily how you would want it to work. Know exactly what the application needs to do. Be able to anticipate problems. You won’t be successful if your application doesn’t do what the client wants. n Use cases are a tool to help you figure that out, before you start to do design. _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 25

The Only Thing that’s Constant. . . in Analysis and Design is CHANGE o o o Clients (and other stakeholders) change their minds about purpose and requirements. Market conditions change. The environment changes. SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 26

New Requirement: Bark Recognition SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006. 27

A Better Format Make sure the use cases make sense to you, the developers. SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006. 28

Did We Completely Analyze the Problem? Dog. Door. java Dog. Door. jav a The Perfect World Make sure your application will work in a real-world context. SJSU Dept. of Computer Science Fall 2013: August 29 The Real World CS 151: Object-Oriented Design © R. Mak From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006. 29

But Avoid. . . Paralysis by Analysis SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 30

Good Use Cases o Write your use cases in a way that makes sense to all stakeholders (client, developers, managers, . . . ). o Good use cases show that you’ve done your analysis well and that your application will work in a real-world context. _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 31

The Functional Specification o Clear problem statement n o Objectives n o o o What is the problem? What is your application supposed to accomplish? Functional requirements Nonfunctional requirements Use cases SJSU Dept. of Computer Science Fall 2013: August 29 Primary contents of a Functional Specification CS 151: Object-Oriented Design © R. Mak 32

In Future Episodes How do we go from analysis to design? So where do all those classes come from? Read Chapter 2 of the Horstmann book. Always bring your laptop to class for any potential online quizzes. SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 33