CS 151: Object-Oriented Design August 29 Class Meeting Department of Computer Science San Jose State University Spring 2012 Instructor: Ron Mak

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

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

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

SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 5 But It Doesn’t Scale! 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 6 A Much Better Design after Encapsulation 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 7 What Did We Encapsulate?  The original GuitarSpec class The varying properties of guitars.  Rick decided to add the number of strings to the original set of guitar properties.  The final InstrumentSpec class The varying properties of all the different types of instruments.  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 8 Application Development Big Picture

SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 9 Analysis Precedes Design  Understand the problem. The application is no good if it doesn’t do what it’s supposed to do.  Gather requirements from the client. 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. 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. 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 10 A Truly Messy Business  Clients often don’t know what they want. “I’ll know it when I see it.”  Eliciting requirements from a client is tough! 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. Example: Rick decides to sell more types of instruments. If you thought software design was messy analysis can be just as messy!

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

SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 13 Types of Requirements  Functional requirements What the system shall be able to do or allow users to do.  “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 Usability, reliability, performance, supportability, etc.  “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 14 Requirements Must Have...  Completeness Are all system features described by requirements?  Consistency No two requirements can contradict each other.  Clarity Each requirement must be unambiguous.  Correctness 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 15 Requirements Must Have, cont’d  Realism Can the system be implemented?  Verifiability Can the system be tested?  Traceability 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 16 Example Application: Automated Dog Door  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. 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 17 Initial Requirements  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 18 Get More Requirements  Interview the clients. Ask probing questions. How tall is Fido?  The door must be at least 12” tall. How many buttons do you want on the remote?  Only one that toggles between opening and closing the door. Should the door close automatically after a while?  Developers should do brainstorming. 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 19 Stated and Implied Requirements  Stated by the client The door should be able to be opened remotely. The door should close after dog goes out.  Implied (what do you think?) The door should not close while the dog is going through it. The door should close automatically after a wait.  Also implied 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 20 Test the Requirements with Use Cases 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 21 What is a Use Case?  A complete sequence of steps that provides value to one of the actors. Actor: Someone or something that is not part of your system.  Todd, Gina, Fido  You’re building a software application to implement an automatic dog door, not simulations of people or dogs.  Describes something that your application must do. A single goal of your application.  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 22 Parts of a Use Case  Name Verb-Noun (example: Let out the dog)  Description One or two paragraphs describing the purpose and goal.  Actors Who’s involved?  Preconditions What must be true before the use case can start?  Trigger What initiates the sequence of steps?

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

SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 24 Example Alternate Sequence 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. 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 25 Some Key Points for Success  The best way to get good requirements is to understand what the application is supposed to do. Make sure the application works the way the client wants it to work, not necessarily how you would want it to work.  To be a successful developer, you must understand the application better than your client. 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. 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 26 The Only Thing that’s Constant in Analysis and Design is CHANGE  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 27 New Requirement: Bark Recognition 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 28 A Better Format Make sure the use cases make sense to you, the developers. 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 29 Did We Completely Analyze the Problem? The Real World DogDoor.java The Perfect World DogDoor.java Make sure your application will work in a real-world context. 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 30 But Avoid... Paralysis by Analysis

SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 31 Good Use Cases  Write your use cases in a way that makes sense to all stakeholders (client, developers, managers,...).  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 32 The Functional Specification  Clear problem statement What is the problem?  Objectives What is your application supposed to accomplish?  Functional requirements  Nonfunctional requirements  Use cases Primary contents of a Functional Specification

SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 33 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.