1 / 94

SE 430 Object Oriented Modeling

SE 430 Object Oriented Modeling. Dennis Mumaugh, Instructor dmumaugh@cdm.depaul.edu Office: CDM, Room 428 Office Hours: Thursday, 4:00 – 5:30. Administrivia. Comments and/or Feedback Email – make sure your email address on campus connection is correct!

alexandraw
Download Presentation

SE 430 Object Oriented Modeling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SE 430 Object Oriented Modeling Dennis Mumaugh, Instructor dmumaugh@cdm.depaul.edu Office: CDM, Room 428 Office Hours: Thursday, 4:00 – 5:30 SE 430: Lecture 3

  2. Administrivia • Comments and/or Feedback • Email – make sure your email address on campus connection is correct! • For documents to be submitted: be sure any embedded figures are JPEG. • Assignments: • You may use the solutions from the previous assignment(s) as a basis for work on your next assignment • Solutions for assignments will be posted the next day (evening) after they are due. SE 430: Lecture 3

  3. Assignment 2 Assignment 2 (Due September 29) Visitor Information Subsystem: SubsystemUse Cases and Use-case supplemental diagram. • Produce the use-case model for the Visitor Information subsystem • Deliverables: • Cover page • List of all actors, their goals and objectives • Identification of use cases • Brief descriptions of all use cases – see template • Ranking of use cases and basis of ranking • Use case diagram (all use cases – together). • Detailed use case: (Fully dressed or expanded) description of major use case • Use-Case Supplemental Diagram (system sequence diagram) • Glossary • Forms that you may elect to use are on the reading list page. SE 430: Lecture 3

  4. Term Project • Team Project Preliminary Description discusses the first deliverable. • Due (Due October 20) • Preliminary project description – Team Project – Preliminary Description.dochttp://condor.depaul.edu/dmumaugh/se430/assignments/Team Project – Preliminary Description.doc • List of primary use cases • Team Project • Due (Due November 17) • http://condor.depaul.edu/dmumaugh/se430/assignments/TeamProject.doc • See the course documents page • Team assignments are on the course documents page on D2L. SE 430: Lecture 3

  5. Projects • Some sort of personal productivity enhancer • Smart phone or iPad application • StarTrek™ Tri-corder • Field work support: GPS, pictures, documents, portable science lab • Smart shopper device • UPS delivery tracking or OTR Truck dispatch • Guide for the blind SE 430: Lecture 3

  6. Project Format of document • Make sure each page is numbered and has name of project and submission info • Use standard “business” report formats • Proofread your documents! • Check that the submission contains all that is asked for and in the correct (logical) order. • Maximum size of submission is 25 pages or less, preferably less! SE 430: Lecture 3

  7. Project Hints • Get organized ASAP and have some meetings. You have three weeks to decide on a project, develop requirements, use-cases and write-it up. • If possible, have some face to face meetings • There are collaboration groups for each team on D2L. • Email list for each team • Project collaboration site • Group drop outs: • Reduce scope of project. • Cover less use cases: max (<groupSize>-1, 2) • Notify me ASAP if a team member is not working or seems to have dropped out. • How (not) to lose in SE 430 • Read the paper and follow it. (Not!) • Make a schedule and follow it. Try to pace yourselves and keep making progress. SE 430: Lecture 3

  8. Project: Working in groups • Rotate responsibilities • Have a moderator and a recorder at each meeting • Moderator keeps meeting on track, keeps track of action items • Recorder keeps good notes • Allow contributions from all members • Project is a learning process as well as just a job • Need to make sure all are on board • Use the Amerindian tradition of the "Talking Stick" • Be careful not to overwhelm people. • Tell people if you feel you are • Being ignored • Not given enough work or too simple work. • Make a schedule of work and action items (deliverables, both internal and external) • Keep communicating. Answer your mail promptly. SE 430: Lecture 3

  9. SE 430 – Class 3 Topic: Use-Case Model • Concepts and Background • The Use-Case Model in the Unified Process • High level use cases • Use-Case Workflow • Use-Case Tasks and Artifacts • Use Case Diagrams • Ranking Use Cases • Detailed Use Cases • System Sequence Diagrams Reading: Arlow & Neustadt: Ch.'s 4 & 5 Class reading list SE 430: Lecture 3

  10. Thought for the Day "Never ask users what they want, or they'll tell you." SE 430: Lecture 3

  11. Last Time Topics: • Requirements Analysis • Defining Requirements • Problem Statement or Project Charter or Vision • Requirements Document • Formal list of what the product will do • Business and Domain Rules SE 430: Lecture 3

  12. Big Picture Today SE 430: Lecture 3

  13. Object-Oriented Modeling SE 430: Lecture 3

  14. What is a model? Paraphrased from Software Measurement and Estimation: A Practical Approach, L.M. Laird & M.C. Brennan, 2006 • A model is an abstraction which strips away unnecessary details, and views an entity from a particular perspective • This is another application of the just right principle: include just what you need for the problem at hand, no more, no less • Models allow us to: • Focus on the important parts of the entity • Ignore parts of the entity that are irrelevant • Hypothesize and reason about the entity SE 430: Lecture 3

  15. A fundamental modeling principle “Models are not right or wrong, they are more or less useful.” - Martin Fowler SE 430: Lecture 3

  16. Types of object-oriented analysis models • Requirements capture the needs and wants of various stakeholders and formalize them as user stories • Requirements represent a collective mental model of the system viewed from the stakeholders' perspective • Everydaymental model example: Thermostats of different sorts • The use-case model—use cases and system sequence diagrams— models the dynamic/behavioral/process-oriented aspects of the system • However, the use case diagram is a static diagram that models the static relationships among actors and use cases • The domain model—diagram and glossary—models the static/structural/logical aspects of the system • Domainprocesses are modeled in both the use case model and in the domain model SE 430: Lecture 3

  17. Domain processes: static and dynamic representations Domain processes are modeled statically in the domain model and dynamically in use cases SE 430: Lecture 3

  18. Visualizing O-O model relationships SE 430: Lecture 3

  19. Modeling system behavior SE 430: Lecture 3

  20. Modeling system behavior Typical ways of modeling system behavior • Scenarios or story boards • Use cases or user stories • (System) Sequence diagram: way of drawing a picture of a scenario • (Object) Interaction diagrams • Message sequence charts • Communication (Collaboration) Diagrams SE 430: Lecture 3

  21. Scenarios I would like a book of stamps, please. Here is $10. Thanks. Here are your stamps and your change. • A scenario is a little story • it is an outline of some expected sequence of events • A scenario is used to convey the fundamentals of “how things work” • It usually includes at least one actor • Each actor can make requests of the system or respond to system activity OK. Will that be all? Yes. That will be $9.80. SE 430: Lecture 3

  22. High-level system view System diagram Student My system Administrator Instructor Use case diagram Student My system register Administrator create new course delete offering Instructor • If we look at the system as a “black box”, we can identify some of the external users of the system (either humans or other computer systems) • The simplest “black box” diagram is a system diagram, which shows the outside actors • The use case diagram is more elaborate: it also shows the connections between “use cases” and actors SE 430: Lecture 3

  23. Sequence diagram Customer Postal clerk Ask for book of stamps Do you want anything else? No Respond with price Give money Give stamps and change • A sequence diagram is a way of drawing a picture of a scenario • Sequence diagrams are also sometimes called event trace diagrams, ladder diagrams, interaction diagrams, or fence post diagrams • Each vertical line describes an “actor” or a “system” in the scenario • The vertical axis represents time: time flows down the page SE 430: Lecture 3

  24. Iterative Development Use Cases • Decide and describe the functional requirements of the system • Bring agreement between the customer and software developer • Give a clear and consistent description of what the system should do. • Provide a basis for performing tests that verify the system delivers the functionality stated. • Trace the functional requirements into actual classes and operations in the system. SE 430: Lecture 3

  25. Use-Case Model I Concepts and Background The Use-Case Model in the Unified Process Use-Case Workflow Use-Case Tasks and Artifacts SE 430: Lecture 3

  26. Concepts and Background SE 430: Lecture 3

  27. Use Cases • A use case tells a story of actors using a system. • “Rent Videos” • A use-case is a sequence of actions a system performs that yields an observable result of value to a particular actor. • One artifact to express (especially) functional requirements. • Emphasizes thinking about the valuable objectives-oriented viewpoint of the users. SE 430: Lecture 3

  28. What is a use case? • Documents a set of interactions between a user (or actor) and a computer system. • Can be viewed as a necessary (but not sufficient) collection of requirements for those interactions. • Use cases: • Help to focus on achieving well-defined user goals. • Vary widely in their level of detail. • Capture use cases by: • Interviewing users. • Discussing their use of the system. • Naming (a form of abstraction) and describing each use of system. • Hint: Domain processes and events from the system context description are good sources for use cases. Also functional requirements. SE 430: Lecture 3

  29. Use cases • A use case is a concept that is related to scenarios: • A use case is a description of all the possible sequences of interactions among the system and one or more actors in response to some initial stimulus by one of the actors. (Rumbaugh) • A use case is a collection of possible sequences of interactions between the system under discussion and its external actors, related to a particular goal. (Cockburn) • In a use case, the system is considered as a black box SE 430: Lecture 3

  30. Use cases • Each actor is an external thing that interacts with the system • An actor can represent either a human user or another system • Actors have goals; they want to accomplish something • Use cases are often documented by drawing some scenarios • Use case analysis often considers both “sunny-day scenarios” and exceptional cases SE 430: Lecture 3

  31. User goals and system interactions • Recall:User goals are specific, but not detailed, descriptions of what user wants the system to do • A system interaction occurs when a user attempts to do something to achieve a goal • A single user goal may lead to several system interactions SE 430: Lecture 3

  32. Use cases and scenarios • The use case describes a set of interactions between the user and the system, possibly with several different outcomes. • A scenario describes a specific path through, and outcome of, a use case. • A use case represents a collection of scenarios: primary, plus zero or more alternates. • The primary scenario corresponds to the main system interactions, usually the ‘success’ scenario. • Alternate scenarios correspond to less frequent interactions and exceptions. • Different scenarios are analogous to alternatives in switch..case constructs. • The term interaction can refer to a single interaction or a set. Typically an actor has a set of interactions with the system. SE 430: Lecture 3

  33. From user goals to scenarios Goal/requirement space System behavior space SE 430: Lecture 3

  34. Another view User Goal … … yields Use case 2 maps to Scenario 1 Scenario 2 Scenario n composed of … Interaction 1 Interaction 2 Interaction n … SE 430: Lecture 3

  35. Use case format • Start with a simple use-case format and add additional features, if needed. • For each use case, provide: • Identification. short identification tag, e.g. UC001 • Name. Provide a (short) title • Description. brief description in a few sentences. Short narrative (2-3 sentences) describing use case and objectives • Actors. List the actors that interact with this use case. • Goals. What the actor wants to achieve. • Preconditions. Specify what conditions must be true before the use case starts. • Postconditions. Specify what conditions must be true when the use case ends. • Event Flow. Use a sequentially-numbered list of brief statements describing the steps of the use case. Start with “This use case begins when…” and end with “This use case ends when…”. SE 430: Lecture 3

  36. High-level use case: primary scenario Identification: UC003 Name:Artifact physical care requirements entry Description: Enter physical care requirements for a new artifact into the Artifact Tracking System (ATS) Actors: Artifact Tracking (AT) staff member (user); climate, fire, and security control subsystems Trigger: AT staff member wishes to enter all the climate, fire, and security control physical care requirements for a new artifact into the ATS Goals: see Trigger above Preconditions: • AT staff member must be logged into the ATS. • AT staff member must have entered the unique identification code assigned to the artifact. Incoming information: Climate, fire control, and security requirements for artifact Results: Artifact physical care requirements are entered into ATS Postconditions: • ATS (in collaboration with appropriate subsystems) confirms Museum can provide appropriate physical care for artifact. SE 430: Lecture 3

  37. High-level use case – basic form Event Flow: • This use case begins when the user selects ‘ArtifactPhysical Care’ from the ATS menus. • System displays a blank entry form for the artifact's climate control requirements. • User enters the artifact's climate control requirements into the form. • User selects ‘Continue’ to end climate control requirements entry. • System displays a blank entry form for the artifact's fire control requirements. • User enters the artifact's fire control requirements into the form. • User selects ‘Continue’ to end fire control requirements entry. • System displays a blank entry form for the artifact's security requirements. • User enters the artifact's security requirements into the form. • User selects ‘Continue’ to end security requirements entry. SE 430: Lecture 3

  38. High-level use case—basic form Event Flow: • User selects ‘Continue’ to end physical care requirements entry. • System presents the artifact's physical care requirements to the user for review. • This use case ends when the user selects ‘Accept’ for the displayed information. SE 430: Lecture 3

  39. Alternate event flow form with ‘repeat’ Event Flow: • This use case begins when the user selects ‘ArtifactPhysical Care’ from the ATS menus. • For each specific physical care requirement (climate, fire, security) repeat steps 3-5: • System displays a blank entry form for the artifact's specific physical care requirements. • User enters the artifact's specific physical care requirements into the form. • User selects ‘Continue’ to end specific physical care requirements entry. • User selects ‘Continue’ again to end all physical care requirements entry. • System presents the artifact's physical care requirements to the user for review. • This use case ends when the user selects ‘Accept’ for the displayed information. SE 430: Lecture 3

  40. Use case evolution • Storyboards represent an early form of use case. • Use cases were formalized in Ivar Jacobson's Objectory process and later popularized in Object-Oriented Software Engineering: A Use Case Driven Approach (1992). • Use cases were incorporated in UML at the very earliest stages: sometime around v. 0.9 or 1.0. • Use cases have been part of the Unified Process – “a use-case-driven process” – from its inception. • Schneider & Winters (Applying Use Cases: A Practical Guide), Cockburn (Writing Effective Use Cases), and others have helped make use cases more accessible. SE 430: Lecture 3

  41. Use cases in the software life cycle • First iteration of Elaboration: • About 80% of use cases captured. • About 10% detailed. • Why just 10%? About 10% of project use cases will be identified as highest-risk. • Subsequent iterations: • Most use cases captured. • About 80% detailed by end. • Why only 80%? About 20% of use cases will be minor variations on others or will be trivial. • Construction: • Use cases added or extended by recycling to Inception phase. SE 430: Lecture 3

  42. Use Case Workflow SE 430: Lecture 3

  43. Idealized use case workflow SE 430: Lecture 3

  44. UC workflow techniques and artifacts Start SE 430: Lecture 3

  45. Use Case Tasks & Artifacts SE 430: Lecture 3

  46. Find actors • Identifying actors is the most critical element in constructing the use-case model. • A use-case actor interacts with the system in a specific role • Candidate actors can come from several sources. • System context description can be a rich source of candidate actors. • Actors may take on more than one role, depending upon specific interaction. SE 430: Lecture 3

  47. Find actors • Minimize overlap of roles that different use-case actors play: • Combine overlapping roles into a single role for one actor • Example: Assign ‘Security Profile Administrator’ role and ‘Access Privileges Manager’ roles to a single Security Profile Manager actor, unless there is a good reason to keep them separate • Assign one or more overlapping roles to separate actors. • Example: A Museum Administrator may act in both system management and end user roles. Assign these very different roles to two different actors: System Manager and End User SE 430: Lecture 3

  48. Types of actors • Primary actors • The source of user goals. • Have goals satisfied through interactions with the system. • Example: ATS staff member has goals satisfied by ATS. • Supporting actors • Provide a service to the system. • Have interfacing requirements with the system. • Example: Climate, security, and fire control systems are supporting actors to the ATS, providing ATS with information. • Offstage actors • Have secondary (or more-removed) interaction with the system. • May have needs that the system satisfies. • Example: Visitor Information system is an off-stage actor to the ATS. ATS provides information to Visitor Information system. SE 430: Lecture 3

  49. Find use cases • There is no cookbook formula for finding use cases. • Good starting points for finding use cases: • Interviews with users. • Domain processes and events from system context description. • Interactions associated with various type of actors. • Functional Requirements. • Any other requirements. SE 430: Lecture 3

  50. Exercise: Identifying use cases • Suppose we want to develop an Automated Teller Machine. List some of the use cases for such a system: SE 430: Lecture 3

More Related