1. Object-Oriented Software Analysis and Design MISM/MSIT, CMU Dr. Rahmi MARASLI

2. Prerequisites  Knowledge of at least one object- oriented programming language  C++  Java  Smalltalk  … or your favorite O-O language!

3. Goals Learn O-O A&D methodology Understand why a methodology is useful for real software projects Learn UML Understand the roles and limitations of CASE tools Learn O-O design patterns Build something that illustrates the concepts

4. Books “Fundamentals of Object-Oriented Design in UML,” by Meilir Page-Jones (required) “Extreme Programming Explained,” by Kent Beck (required) Other books of interest (not required): “Applying UML and Patterns,” by Craig Larman “Design Patterns,” by E. Gamma, R. Helm, R. Johnson, and J. Vlissides “The Unified Modeling Language Reference Manual,” by J. Rumbaugh, I. Jacobson and G. Booch “Software Requirements,” by Karl Wiegers Course syllabus pointed to on Blackboard: www.cmu.edu/blackboard/ Use the Bb Discussion Forum for questions Email: rmarasli@andrew.cmu.edu My office: HbH 3021 My office hours: Mondays 4:45-5:15, or by appointment Everything is attached to the syllabus. Don’t look for assignments, etc. on Blackboard. Look at the syllabus!

5. Course Outline O-O A&D Requirements analysis Wiegers’ RA Larman’s RA Use Cases Conceptual Model Introduction Associations Attributes Generalization

6. Course Outline (cont) System Behavior System Sequence Diagrams Contracts State Diagrams Interaction Diagrams Collaboration Diagrams Design Patterns GRASP Patterns GoF Patterns

7. Course Outline (cont) Determining Visibility Design Class Diagrams Issues in System Design O-O Metrics Guest Lecturer (tentative) Extreme Programming Presentations

8. Object-Oriented Analysis and Design

9. What is Analysis and Design? Analysis emphasizes an investigation of the problem rather than how a solution is defined Design emphasizes a logical solution, how the system fulfills the requirements

10. Analysis and Design (cont) Division between A & D is fuzzy A & D activities exist on a continuum Some practitioners can classify an activity as analysis while others put it into design category More analysis oriented More design oriented -what -requirements -investigation of domain -understanding of problem -how -logical solution -understanding and description of solution

11. What is O-O A&D? The essence of O-O A&D is to consider a problem domain and logical solution from the perspective of objects (things, concepts, or entities) O-O Analysis emphasizes finding and describing the objects – or concepts- in the problem domain O-O Design emphasizes defining logical software objects (things, concepts, or entities) that have attributes and methods

12. Object vs. Function Oriented Analysis Library Info System O-O A&D Decompose by objects and concepts Structured A&D Decompose by functions and processes CatalogLibrarian BookLibrary System Record LoansAdd ResourceReport Fines

13. O-O A&D AnalysisDesign Requirements Analysis Use Cases Conceptual Model System Behavior Collaboration Diagrams Construction Class Design Diagrams Code & Test Larman 1998

14. Unified Modeling Language “A language for specifying, visualizing and constructing the artifacts of software system” [Booch, Jacobson, Rumbaugh] It is a notational system aimed at modeling systems using O-O concepts … not a methodology … not a process

15. Requirements Analysis

16. “Hello, Phil? We’re having a problem with the employee system you programmed for us. An employee just changed her name to Sparkle Starlight, and we can’t get the system to accept the name change. Can you help?” Phil in Systems Maria in HR “She married some guy named Starlight?”

17. Requirements Analysis “No, she didn’t get married, just changed her name. That’s the problem. It looks like we can change a name only if someone’s marital status changes.” Phil in Systems Maria in HR “Well, yeah, I never thought someone might just change her name. I don’t remember you telling me about this possibility when we talked about the system. That’s why you can get to the Change Name dialog box only from the Change Marital Status dialog box.”

18. Requirements Analysis “I assumed you knew that people could legally change their name anytime they like. We have to straighten this out by Friday, or Sparkle won’t be able to cash her paycheck. Can you fix the bug by then?” Phil in Systems Maria in HR “It’s not a bug! I never knew you needed this capability. I’m busy now. I can probably fix it by the end of the month. Next time, tell me these things earlier, and please write them down.”

19. Requirements Analysis “What am I going to tell Sparkle? She’s really going to be ticked if she can’t cash her check” Phil in Systems Maria in HR “Hey Maria, it’s not my fault. If you’d told me in the first place that you had to be able to change someone’s name at any time, this wouldn’t have happened. You can’t blame me for not reading your mind.”

20. Requirements Analysis “Yeah, well, this is the kind of thing that makes me hate computer systems. Call me as soon as it’s fixed, will you?” Phil in Systems Maria in HR

21. Some Obvious Problems Here Informal information gathering Implied functionality Erroneous or un-communicated assumptions Inadequately defined requirements A casual change process

22. Who Are The Stakeholders in a Software Project? Customers who fund or buy a product Users who use the product Requirements analysts Developers and testers Project managers Legal staff Manufacturing people Sales, marketing, field support, help desk, etc.

23. What Is a Requirement, Exactly? IEEE Standard Glossary of Software Engineering Terminology: A condition or capability needed by a user to solve a problem or achieve an objective A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document But isn’t a “user” really a “stakeholder”?

24. Requirements A description of needs and desires for a product Primary goal To identify and document what is really needed, in a form that clearly communicates to both client and to development members (and to all other stakeholders)

25. Wiegers’ Diagram Vision and Scope Document Use Case Document Business Requirements User Requirements Business Rules Quality Attributes Systems Requirements Functional Requirements External Interfaces Constraints Software Requirements Specification Functional Nonfunctional

26. Business Requirements High-level objectives of the organization These are at the top-most level of the “requirements chain” These come from the funding sponsor, or the customer, or marketing

27. Business Requirements (cont) We must have these before any other (e.g., user and functional) requirements These must show how the project will achieve business objectives These are the basis for determining product features and proposed releases These should be very public Record these in a “Vision and Scope” document

28. User Requirements User tasks that the user must be able to perform These can be described by use cases, or scenario descriptions, or event-response tables or… Ex: “Make a reservation with the airline” Record these in a “Use Case” document

29. System Requirements These are for “systems,” i.e., things that contain subsystems Subsystems may be hardware or software or both People are part of a system, too Example: Airline reservation system Software subsystems: dbase manager, graphical UI, communication system, etc. Hardware subsystems: Mainframes, access terminals, communication infrastructure, etc. People: Travel agents, etc.

30. Functional Requirements Software functionality that developers must build to enable users to achieve their tasks Traditional “shall” statements: “The system shall record the sale transaction in the global database” “The system shall provide the user with the opportunity to edit her comment text” “Upon identifying a misspelled word, the program shall present a list of possible alternative words/spellings”

31. Business Rules Not really software requirements, but facts and constraints that must be respected Corporate policies, government regulations, industry standards, accounting practices, etc. “Sales tax is not collected on shipping charges” “Non-refundable tickets incur a fee when the purchaser changes an itinerary.”

32. Quality Attributes Availability Measure of planned uptime during which system is available for use and fully functional Reliability Probability of system running without a failure for a specified period of time Robustness How system functions when confronted with unexpected operating conditions

33. Quality Attributes (cont) Interoperability How easily it is to exchange data or services with other systems Flexibility How easy it is to add new capabilities to product Integrity Blocking unauthorized access to system functions, preventing information loss, … etc.

34. Quality Attributes (cont) Usability Ease of use, user friendliness Efficiency How well system utilizes system processor, disk, memory bandwidth, etc. resources Maintainability How easy it is to fix a bug or modify software Portability How easy it is to migrate a piece of software to a new environment

35. Quality Attributes (cont) Reusability How easy it is to use part of software in other applications Testability How easy it is to verify system functionality etc.

36. External Interfaces Most computer programs do not stand alone; they must co-exist: Are there external data inputs? Are there external outputs? How should local errors be explained? How does external data affect my user interfaces? … etc.

37. Constraints These are choices available to developer for design and construction of product “Our servers are brand XXX, and run YYY software” “We are an open source shop” “All our HTML must be interpretable by IE v. xxx, we don’t care about Netscape” “All of our numerical output must be correct to within +- 10e-22”

38. Features vs. Requirements A “feature” is a set of logically related functional requirements It provides capability to a user and enables satisfaction of a business objective Examples: It’s easy to add clip art to your presentation! All of last year’s messages from XXX can be displayed instantly! Our “Web-Link” technology discovers the identity of selected clients in your database!

39. What Requirements Are Not Design or implementation details Project planning information Testing strategies or details Other project requirements like Development environment Budget limitations Training

40. A Standard Graph 120 100 80 60 40 20 0 Relative Cost to Correct a Defect Development Phase Requirements DesignCodeTestOperation Grady 1999

41. Common Problems Insufficient user involvement Creeping user requirements Ambiguous requirements Gold plating Minimal specification Overlooked user classes Inaccurate planning

42. Example: Chess Playing Build a system to play chess with the user Provide a visual display of the chess board and the chess pieces Provide a simple means for the user to move her chess pieces Both the system and the user will be restricted to legal moves. The system will recognize when a player has won

43. Functional Requirements Establish essential behaviors for any correct implementation (legal moves, etc.) True for every implementation, on every machine, in every language, in any operating environment But there is more...

44. Nonfunctional Requirements Operational properties of the delivered system Response time, ease of use, “ilities” Difficult to describe logically Difficult to check in advance of an implementation Every bit as important as functional requirements

45. Vision & Scope Document Business Requirements Vision of the Solution Scope and Limitations Business Context Wiegers 2003

46. Vision & Scope (cont) Vision describes, in business terms, what the product is about, and where it might go Scope describes “what’s in and what’s out” Vision has nothing to do with features; it should be stable, and change slowly, but it may imply several “releases”

47. Another Dopey Diagram Product Vision Project Scope for Release 1 Project Scope for Release 2 Project Scope for Release n … Releases are determined by schedule, budget, resource and quality constraints