SE 430 Object Oriented Modeling

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