SE 430 Object Oriented Modeling Dennis Mumaugh Instructor

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

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. September 22, 2016 SE 430: Lecture 3 2 of 94

Assignment 2 (Due September 29) Visitor Information Subsystem: Subsystem Use 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. September 22, 2016 SE 430: Lecture 3 3 of 94

Term Project § Team Project Preliminary Description discusses the first deliverable. Due (Due October 20) Ø Preliminary project description – Team Project – Preliminary Description. doc http: //condor. depaul. edu/dmumaugh/se 430/assignments/Team Project – Preliminary Description. doc Ø List of primary use cases § Team Project Ø Due (Due November 17) Ø http: //condor. depaul. edu/dmumaugh/se 430/assignments/Team. Proje ct. doc § See the course documents page Ø Team assignments are on the course documents page on D 2 L. Ø September 22, 2016 SE 430: Lecture 3 4 of 94

Projects § Some sort of personal productivity enhancer Ø Smart phone or i. Pad application § Star. Trek™ 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 September 22, 2016 SE 430: Lecture 3 5 of 94

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! September 22, 2016 SE 430: Lecture 3 6 of 94

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 D 2 L. Ø Email list for each team Ø Project collaboration site Group drop outs: Ø Reduce scope of project. Ø Cover less use cases: max (<group. Size>-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. September 22, 2016 SE 430: Lecture 3 7 of 94

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. September 22, 2016 SE 430: Lecture 3 8 of 94

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 September 22, 2016 SE 430: Lecture 3 9 of 94

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

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 September 22, 2016 SE 430: Lecture 3 11 of 94

Big Picture Today September 22, 2016 SE 430: Lecture 3 12 of 94

Object-Oriented Modeling September 22, 2016 SE 430: Lecture 3 13 of 94

What is a model? § 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 Paraphrased from Software Measurement and Estimation: A Practical Approach, L. M. Laird & M. C. Brennan, 2006 September 22, 2016 SE 430: Lecture 3 14 of 94

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

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 ‣ Everyday mental 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 § Domain processes are modeled in both the use case model and in the domain model September 22, 2016 SE 430: Lecture 3 16 of 94

Domain processes: static and dynamic representations Domain processes are modeled statically in the domain model and dynamically in use cases September 22, 2016 SE 430: Lecture 3 17 of 94

Visualizing O-O model relationships September 22, 2016 SE 430: Lecture 3 18 of 94

Modeling system behavior September 22, 2016 SE 430: Lecture 3 19 of 94

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 September 22, 2016 SE 430: Lecture 3 20 of 94

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

High-level system view § 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 September 22, 2016 System diagram Student My system Administrator Instructor Use case diagram Student Administrator My system register create new course Instructor SE 430: Lecture 3 delete offering 22 of 94

Sequence diagram § 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 Customer Postal clerk Ask for book of stamps Do you want anything else? No Respond with price Give money Give stamps and change September 22, 2016 SE 430: Lecture 3 23 of 94

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. September 22, 2016 SE 430: Lecture 3 24 of 94

Use-Case Model I Concepts and Background Ø The Use-Case Model in the Unified Process Ø Use-Case Workflow Ø Use-Case Tasks and Artifacts Ø September 22, 2016 SE 430: Lecture 3 25 of 94

Concepts and Background September 22, 2016 SE 430: Lecture 3 26 of 94

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 objectivesoriented viewpoint of the users. September 22, 2016 SE 430: Lecture 3 27 of 94

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. September 22, 2016 SE 430: Lecture 3 28 of 94

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 September 22, 2016 SE 430: Lecture 3 29 of 94

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 September 22, 2016 SE 430: Lecture 3 30 of 94

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 September 22, 2016 SE 430: Lecture 3 31 of 94

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. September 22, 2016 SE 430: Lecture 3 32 of 94

From user goals to scenarios Goal/requirement space September 22, 2016 System behavior space SE 430: Lecture 3 33 of 94

Another view … … User Goal maps to Use case 2 Scenario 1 Interaction 1 September 22, 2016 Scenario 2 Interaction 2 yields … … SE 430: Lecture 3 Scenario n composed of Interaction n 34 of 94

Use case format § Start with a simple use-case format and additional features, if needed. § For each use case, provide: Ø Identification. short identification tag, e. g. UC 001 Ø Name. Provide a (short) title Ø Description. brief description in a few sentences. Short narrative (23 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…”. September 22, 2016 SE 430: Lecture 3 35 of 94

High-level use case: primary scenario Identification: UC 003 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. September 22, 2016 SE 430: Lecture 3 36 of 94

High-level use case – basic form Event Flow: 1. This use case begins when the user selects ‘Artifact Physical Care’ from the ATS menus. 2. System displays a blank entry form for the artifact's climate control requirements. 3. User enters the artifact's climate control requirements into the form. 4. User selects ‘Continue’ to end climate control requirements entry. 5. System displays a blank entry form for the artifact's fire control requirements. 6. User enters the artifact's fire control requirements into the form. 7. User selects ‘Continue’ to end fire control requirements entry. 8. System displays a blank entry form for the artifact's security requirements. 9. User enters the artifact's security requirements into the form. 10. User selects ‘Continue’ to end security requirements entry. September 22, 2016 SE 430: Lecture 3 37 of 94

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

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

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-casedriven 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. September 22, 2016 SE 430: Lecture 3 40 of 94

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. September 22, 2016 SE 430: Lecture 3 41 of 94

Use Case Workflow September 22, 2016 SE 430: Lecture 3 42 of 94

Idealized use case workflow September 22, 2016 SE 430: Lecture 3 43 of 94

UC workflow techniques and artifacts Start September 22, 2016 SE 430: Lecture 3 44 of 94

Use Case Tasks & Artifacts September 22, 2016 SE 430: Lecture 3 45 of 94

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. September 22, 2016 SE 430: Lecture 3 46 of 94

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 September 22, 2016 SE 430: Lecture 3 47 of 94

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 provides information to Visitor Information system. Ø September 22, 2016 SE 430: Lecture 3 48 of 94

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. September 22, 2016 SE 430: Lecture 3 49 of 94

Exercise: Identifying use cases § Suppose we want to develop an Automated Teller Machine. List some of the use cases for such a system: Ø Ø Ø September 22, 2016 SE 430: Lecture 3 50 of 94

Exercise: Identifying use cases § Suppose we want to develop an Automated Teller Machine. List some of the use cases for such a system: Ø Ø Ø Get instant cash Transfer money Get money from checking Balance check Deposit cash or checks September 22, 2016 SE 430: Lecture 3 51 of 94

Use case formats § Brief Ø Ø Same as high-level with no steps, but a two to three sentence description. See sample form (see notes). § High-level Ø Ø Very terse summary—perhaps 5 -6 steps in event flow. Usually two or three sentences describing the objective. Covers only the primary scenario with minimal detail. Roughly equivalent to the Agile‘stories. ’ See sample form (see notes). § Casual Ø Ø Ø More detailed format—perhaps 10 -20 steps in event flow. Include actors and possibly pre- and post-conditions. May cover important scenarios other than primary. September 22, 2016 SE 430: Lecture 3 52 of 94

Use case formats § Fully-dressed (detailed) or expanded or extended Lengthy and detailed—perhaps > 15 -20 steps in event flow. Ø Covers most scenarios. Ø Can be trimmed to suit phase and priority of use case. § Or, see my sample forms: http: //condor. depaul. edu/dmumaugh/readings/SE 430 readings. html [Project Forms and Documents] Ø September 22, 2016 SE 430: Lecture 3 53 of 94

Variations on a Theme § Many different use case formats. Cockburn had over 37 variations. § Use whatever provides the most information at the level of detail appropriate § The reading list has a couple of forms that might be useful. September 22, 2016 SE 430: Lecture 3 54 of 94

Describing the Use-case Model As a Whole § We need some way to summarize and track the various actors and use cases and their relationships § Full use-case model consists of: 1. Use-case (prose) descriptions, at various appropriate levels of detail 2. Glossary which contains definitions and descriptions of items in the use-case model 3. Visual model in the form of a use-case diagram 4. Select system sequence diagrams September 22, 2016 SE 430: Lecture 3 55 of 94

Glossary A glossary is part of the use-case model § Consists of all the terms and phrases listed in the requirements document § List of actors and their goals § List of use-cases (name and description) § Any new terms and phrases introduced September 22, 2016 SE 430: Lecture 3 56 of 94

Use-case diagram § Static, summary illustration of § § § use-case structure. Stick-people icons are actors that use the system, linked to particular use case(s). Rectangles represent external system actors that interact with the use case. Ellipses indicate use cases themselves. «extends» link » specialization «uses» link » aggregation «include» is same as «uses» September 22, 2016 SE 430: Lecture 3 57 of 94

ATS sample use-case diagram Create new artifact description Enter artifact physical description << actor>> Climate Control Subsystem ATS Staff Member Enter artifact physical care requirements Save and publish new artifact description September 22, 2016 SE 430: Lecture 3 << actor>> Fire Control Subsystem << actor >> Security Control Subsystem 58 of 94

Sidebar: Identifying the system boundary § Like most analysis and design concepts, system and system boundary may vary with the level of abstraction. § The system represents the software and hardware elements which are the current focus of attention. Ø Example: In the Museum Automation Problem, each individual subsystem—climate, security, Visitor Information—can be considered ‘the system’ during its analysis and design. § The system boundary represents the division between the system itself, including software and hardware, and the actors: primary, supporting, and off-stage. § Defining the scope of the system during the requirements effort can help delineate the system boundary. September 22, 2016 SE 430: Lecture 3 59 of 94

Detailed use cases § Highest-priority use cases require early attention to detail. § Identify the use cases scheduled for the first iteration of development, generally about 10% of total. § For each first-iteration use case, write a detailed (fullydressed) use case. § Because these use cases are being detailed at an early stage, they may require refinement in later iterations. § Avoid getting involved in detailed UI design issues at this stage: write use cases in an essential (mostly UI-free) style. September 22, 2016 SE 430: Lecture 3 60 of 94

Sidebar: essential style § Keep UI specifics out of the use cases and focus on the actor’s intent during the interaction § The UI is a part of the system that is expected to change substantially over the course of development § Early specification of UI details can solidify issues that are best left flexible at this point § So: Ø Ø Ø Postpone specific UI descriptions and interactions until later in design and even then, confine them to a ‘look & feel’ artifact It’s OK to use general UI terminology and user actions: displays, menus, buttons; selects, enters, confirms Avoid specific UI widgets (e. g. radio buttons, pop-up menu, dropdown menu) or user interaction descriptions (scrolls, highlights, drags) September 22, 2016 SE 430: Lecture 3 61 of 94

Detailed use-case format § Start with a simple use-case format and additional features, if needed. § Suggested detailed use-case elements: Ø Identification – use-case ID (Number) Ø Name Ø Narrative description (two to three sentences) Ø Actors (primary, supporting, off-stage), goals and roles. Ø Preconditions and postconditions. Ø Main (primary) scenario event flow. Ø Extensions (alternate scenarios) event flows. Ø Special requirements (attributes and constraints identified in requirements document). Ø Technology and data variations list (from supplementary, nonfunctional requirements). Ø Frequency of occurrence of use case Ø Open issues related to the use case September 22, 2016 SE 430: Lecture 3 62 of 94

Structuring the use-case § Follow a consistent structure for all detailed use cases. § Always use “This use case begins when…” and “This use case ends § § when…” stylistic ‘bookends’. The primary scenario should be the one most readily traced through the use case. Defer exceptional conditions and branches to alternative scenarios. Alternative scenarios (a. k. a. extensions) should follow the primary scenario in the text. Alternative scenarios are identified by the step number in the primary scenario plus a letter. Ø Example: Three alternative scenarios that begin at step 6 in a primary scenario would be labeled 6 a, 6 b, and 6 c. September 22, 2016 SE 430: Lecture 3 63 of 94

Detailed use case example: header Identification: UC 003 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. September 22, 2016 SE 430: Lecture 3 64 of 94

Use case example with alternate scenario Event Flow: 1. This use case begins when the user selects ‘Artifact Physical Care’ from the ATS menus. 2. System displays a blank entry form for the artifact's climate requirements. 3. User enters the artifact’s climate requirements. 4. User selects ‘Continue’ to end climate requirements entry. 5. System displays a blank entry form for the artifact's fire requirements. 6. … 5 a. Museum facilities cannot support climate requirements of artifact: 1. System informs user that Museum cannot support climate requirements of artifact. 2. System specifies requirement(s) that cannot be met. 3. System displays climate control system modification request form. 4. User enters the climate requirements for the artifact. 5. User selects ‘Submit’ to submit modification request to facilities staff. 6. Continue event flow with step 5. September 22, 2016 SE 430: Lecture 3 65 of 94

Example: additional elements Special requirements: All entered physical care requirements must be verified against minimal generic requirements for the type of artifact Technology and data variations list: System must support both artifacts that are part of the Museum's permanent collection and those that are on temporary loan from other sources Frequency of occurrence: Variable. Very high during initial set-up; high during arrival of visiting exhibitions; low otherwise Open issues: Must identify minimal lists of requirements for each of the areas (climate, fire, and security) September 22, 2016 SE 430: Lecture 3 66 of 94

Prioritize use cases § Planning in an iterative and incremental process is risk§ § driven. Schedule analysis, design, and implementation of use cases representing core system (required vs. desirable or optional) functionality and high-risk use cases for early iterations Conversely, schedule development of non-corefunctionality and low-risk use cases for later iterations. Need to balance risk and functionality factors. At this stage, consider priority based on: Ø Ø Proportion of contribution to overall system functionality. Technological, skills, and dependency risks. September 22, 2016 SE 430: Lecture 3 67 of 94

Risk factors § Requirements risks Have you properly identified requirements for system? Ø Have you reviewed project scope? Ø Can you effectively set functional requirements priorities? § Technological risks Ø Are you using a new, untested technology? § Dependency risks Ø Are you depending on a third-party product? § Skills risks Ø Are you planning to do something with which you are completely unfamiliar? Ø Do you have the right staff with the necessary skills? Ø September 22, 2016 SE 430: Lecture 3 68 of 94

Ranking (or Prioritizing) Use Cases Project managers use case versions for development cycles § Time-box development cycles have a fixed time frame. § Complex use cases may require multiple development cycles to be fully implemented. § Create simplified versions of the complex use case that can be developed within each subsequent time-box. September 22, 2016 SE 430: Lecture 3 69 of 94

Ranking Use Cases Setting Priorities – Rank Order use cases § Many factors may be need to be considered when ranking or prioritizing use cases: A. Impact on the architectural design B. Information and insight regarding the design Risky, time-critical, or complex functions New or risky technology. Represent line-of-business processes Directly support increased revenue or decreased costs. C. D. E. F. September 22, 2016 SE 430: Lecture 3 70 of 94

Ranking Use Cases Use Case Buy Items Add New Users Start Up September 22, 2016 A 5 3 3 B 3 3 2 SE 430: Lecture 3 C 2 2 2 D 0 0 0 E 5 2 2 F 3 2 2 Sum 18 12 11 71 of 94

Ranking Use Cases It is also possible to do simpler classifications – high, medium, low Rank Use Case Justification High Buy Items Scores on most increased ranking criteria Medium Add New Users Log In Refund Items Affects Security Domain Important process affects Accounting Low Cash Out Start Up Shut Down Minimal effect on architecture Definition is dependent on other use cases Minimal effect on architecture September 22, 2016 SE 430: Lecture 3 72 of 94

Practical tips § Pick a set of use cases that maximizes system coverage Ø write two or three of the most common simple transactions first; most common or “sunny day” Ø it is easy to get carried away generating too many use cases, so try to create more “abstract” scenarios when three or more scenarios look very similar § Keep a list of Actors/Roles/Goals/Use Cases § After all use cases are developed, refactor for common elements September 22, 2016 SE 430: Lecture 3 73 of 94

Practical tips § Beware of analysis paralysis Ø Ø inability to write any scenarios, or creating too many detailed scenarios § Techniques to get out of analysis paralysis: Ø Ø write two or three of the most common simple transactions first it is easy to get carried away generating too many use cases, so try to create more “abstract” scenarios when three or more scenarios look very similar be cautious of generating more than 30 use cases to cover the fundamental system actions additional use cases for unusual events should be chosen with care and kept to a manageable number September 22, 2016 SE 430: Lecture 3 74 of 94

Concepts § In writing use cases, start to identify potential classes, objects, and sub-systems § Use cases are used to generate the conceptual (domain) model Ø Ø Nouns become “concepts” or classes/objects Verbs become “actions” or methods § Start each use case name with a verb. § Start sentence 1 with “<Actor> does <event>” § All systems have a Start Up and Shut Down use case (perhaps trivial). September 22, 2016 SE 430: Lecture 3 75 of 94

System testing § One big reason for writing use cases: they really help when it is time to test the entire system Ø Ø both sunny day cases and exception behavior can be extracted from the use case descriptions the use cases define what behavior is inside the system and what behavior depends on the external actors § Since use cases treat the system as a black box, there is a great deal of design freedom, but the external behavior must be correct September 22, 2016 SE 430: Lecture 3 76 of 94

Use Case Diagram § A way to conceive and illustrate the use cases. § Usually created during the initial use case analysis. September 22, 2016 SE 430: Lecture 3 77 of 94

Diagram of Sample Use Case September 22, 2016 SE 430: Lecture 3 78 of 94

Use-Case Model II Use case workflow tasks and artifacts System Sequence Diagrams September 22, 2016 SE 430: Lecture 3 79 of 94

Use case workflow tasks and artifacts Next September 22, 2016 SE 430: Lecture 3 80 of 94

Additional techniques and artifacts Next Statecharts discussed in context of object behavior. September 22, 2016 SE 430: Lecture 3 81 of 94

System Sequence Diagrams September 22, 2016 SE 430: Lecture 3 82 of 94

Use Cases and System Sequence Diagrams § A use case is a prose description of an actor/system interaction. § Use case diagram is a visual summary of: Ø Ø Ø All significant use cases. All significant actors. Relations among actors and use cases. § A System sequence diagram (SSD) is a visual summary of the individual use cases. § For ease of understanding, each use-case scenario corresponds to a separate system sequence diagram. September 22, 2016 SE 430: Lecture 3 83 of 94

Characteristics of System Sequence Diagrams § System sequence diagrams are a special case of the more § § § -general UML sequence diagram. Captures the sequencing of messages and data exchanged between an actor and the system. Provides about the same level of detail as use-case prose description. Usually deals with primary actors and system, but can include other actors as well. Provides a more formal notation for expressing the interaction. Concerned only with external behavior: the system is treated as a black box. September 22, 2016 SE 430: Lecture 3 84 of 94

System Sequence Diagram September 22, 2016 SE 430: Lecture 3 85 of 94

System Sequence Diagram Notation . Note that software participants cannot perform operations on human 22, actors! September 2016 SE 430: Lecture 3 86 of 94

Sequence Diagrams Messages are indicated by a solid line with an arrow. Arrow Meaning Arrow head style UML 2. 0 Synchronous Transfer control and wait for answer. (sequential operations) Return September 22, 2016 Returns a value to the caller (optional) SE 430: Lecture 3 87 of 94

Artifact Tracking use case 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 Preconditions: 1. AT staff member must be logged into the ATS. 2. 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. September 22, 2016 SE 430: Lecture 3 88 of 94

Artifact Tracking use case Event Flow: 1. The use case begins when the user selects to begin the ‘Physical care entry’ process for an artifact in ATS. 2. For each specific physical care requirement (climate, fire, security) repeat steps 3 -5: 3. System displays a blank entry form for the artifact's specific physical care requirements. 4. User enters the artifact's specific physical care requirements into the form. 5. User selects ‘Continue’ to end specific physical care requirements entry. 6. User selects ‘Continue’ again to end all physical care requirements entry. 7. System presents the artifact's physical care requirements to the user for review. 8. The use case ends when the user selects ‘Accept’ for the displayed information. September 22, 2016 SE 430: Lecture 3 89 of 94

Use-case system sequence diagram <<actor>> Control Subsystem ATS User select('Physical Care Entry') loop [for each physical care category] physical. Care. Requirements. Entry. Form enter(physical. Care. Requirements) select('Continue') confirm(specific requirement) confirmation requirements. Confirmation. Form select('Accept') September 22, 2016 SE 430: Lecture 3 90 of 94

SSD – With Use Case September 22, 2016 SE 430: Lecture 3 91 of 94

Summary § OO analysis starts with the following “requirements-oriented” data: Ø Ø Ø problem statement list of text inputs set of use cases § A Use-case is a major distinct, complete, end-to-end process of using a system. Ø Not usually one step, but a complete story. § Use cases tell a story of actors using a system. Examples » Rent Videos » Return Videos » Pay Fines A use-case is a sequence of actions a system performs that yields an observable result of value to a particular actor. Ø September 22, 2016 SE 430: Lecture 3 92 of 94

Summary § A use-case is one artifact to express (especially) functional requirements. § Use-cases emphasize thinking about the valuable, objectives-oriented § § § viewpoint of the users. They illustrate functional requirements, by the stories they tell. Use-cases are valuable for: Ø providing a good overview of the system to be developed Ø defining the system boundary Ø helping to generate the test suites Complementary with a feature requirement list. Choose use-cases carefully since they are the requirements for the entire system and the foundation for the OO analysis process Forms a contract (see Design by Contract) September 22, 2016 SE 430: Lecture 3 93 of 94

Next Class Topic: Static Structure: Requirements Traceability; Building a Beginning Conceptual Model: Class Diagram; CRC Cards; Domain model basic principles; Domain model associations; Domain model attributes; System Glossary. Reading: Arlow & Neustadt: Ch. 's 6 -9 Driving Design: The Problem Domain Tracing Your Design Using CRC Cards Assignment 2 – Due September 29, 2016 September 22, 2016 SE 430: Lecture 3 94 of 94