Transcript Slide 1
An Introduction to Use Cases Presented to: Albany, NY Chapter February 2, 2010 Presented by: J. Timothy Collier Information Technologies Associates, Inc. February 2, 2010 Information Technologies Associates, Inc. 1 Some advice from the Board Stay away from statistics. Studies have shown that 86.4% of all statistics mentioned in a presentation are made up, and … The same studies have shown that 94.3% of studies mentioned on PowerPoint Slides never existed. And this slide is no exception … February 2, 2010 Information Technologies Associates, Inc. 2 Some advice from the Board Try not to put every word you going to say on the Power Point slides. Although this eliminates the need to memorize your talk, ultimately this makes your slides crowded, wordy, and boring. You will loose your audience’s attention before you even reach the bottom of your … February 2, 2010 Information Technologies Associates, Inc. 3 Some advice from the Board …(continued) … first slide. Also, please speel cheek your presentation to make it look more professional. Eschew Avoid making Obfuscation. confusing statements . February 2, 2010 Information Technologies Associates, Inc. 4 Before getting to Use Cases, themselves, let’s take a half step back. February 2, 2010 Information Technologies Associates, Inc. 5 What is it we’re trying to do? Working as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. Determine What it is the business is trying to do, write it down, give to somebody who can figure out How to do it. February 2, 2010 Information Technologies Associates, Inc. 6 System Development Life Cycle Plan Do Define Requirements Measure Analyze Check Act February 2, 2010 Improve Control Information Technologies Associates, Inc. Analysis Design Build Test Deploy 7 System Development Life Cycle Process Requirements WHAT Data Network Databases Network Use Cases Analysis Design Build HOW Test Deploy February 2, 2010 Programs Information Technologies Associates, Inc. 8 Business Systems Other business system Other business system Your business system Other business system Other business system February 2, 2010 Other business system Other business system Information Technologies Associates, Inc. 9 Business Process Start Start State Normal Stuff End End State Not so Normal Stuff February 2, 2010 Information Technologies Associates, Inc. 10 Questions to answer How to capture information about the external business systems? How to capture information about the processes? How to show the interrelationships between external business systems and the processes? How to capture enough information so that the technical team can build the thing? February 2, 2010 Information Technologies Associates, Inc. 11 Use Cases One way of answering all of the questions. Has been around since 1986. Improved communications between development teams and stakeholders. Help teams understand the value the system must produce. Describes how users will use the system. February 2, 2010 Information Technologies Associates, Inc. 12 Use Cases Gets away from the “pile of requirements” concept. Allows more definition of requirements than simple, declarative, “the system shall …” Reduces ambiguity. Attempts to capture the dynamics of a system in terms all stakeholders can easily understand. February 2, 2010 Information Technologies Associates, Inc. 13 Use Cases All models are wrong, but some are useful. (Statistician George E P Box, in "Science and statistics", Journal of the American Statistical Association 71:791-799) February 2, 2010 Information Technologies Associates, Inc. 14 Parts of a Use Case Model February 2, 2010 Information Technologies Associates, Inc. 15 Actors Actor February 2, 2010 An actor is a person or a thing that interacts with the process in question. Actors have names. Actors are external to the process. Actors play a role. Information Technologies Associates, Inc. 16 Use Case Check credit Use Case Enroll student Return deposit February 2, 2010 Represent things of value the system performs for the actor. Contains a verb. It is not a function. It is not a feature. It cannot be decomposed. Some writers feel it is a goal. Other writers feel it is a contract with the user. Information Technologies Associates, Inc. 17 Use Case Diagram Use Case Actor February 2, 2010 A pictorial representation of the actors, the relationships, and the use cases. Unified Modeling Language Standards exist for how to draw them. Tools exist for drawing them. MS Visio IBM Rational Software Modeler Sybase PowerDesigner Others But … Information Technologies Associates, Inc. 18 Use Case Diagram The diagram is arguably the least useful part of the use case. The words that describe the various pieces of the use case diagram are what is important. Conceivably, valid, useful, descriptive use cases can be written without diagramming them at all. February 2, 2010 Information Technologies Associates, Inc. 19 Unified Modeling Language UML defines how to draw use case models. UML does not define how to describe the pieces of a use case model. Regardless of how it is that you decide to write the specifications for Use Cases, you should be able to draw that using UML. February 2, 2010 Information Technologies Associates, Inc. 20 Use Case Model The complete set of actors, use cases, their relationships, and the complete descriptions are known as the use case model. February 2, 2010 Information Technologies Associates, Inc. 21 Business Systems Other business system Other business system Actor Actor Use Case Business Use Case Other business system Use Case Business Use Case Actor Use Case Business Use Case Your business system Use Case Business Use Case Use Case Business Use Case Actor Use Case Business Use Case Other business system Other business system Actor February 2, 2010 Other business system Actor Information Technologies Associates, Inc. 22 Actors Start out with names the business recognizes. New York State Office of the Attorney General General Electric Acme Industries IBM February 2, 2010 Information Technologies Associates, Inc. 23 Relationships Enroll student Admissions office Schedule Student for Class Relationship February 2, 2010 Information Technologies Associates, Inc. 24 Relationships Place local call Callee Caller Place Long Distance Call (Bittner, & Spence, 2003) February 2, 2010 Information Technologies Associates, Inc. 25 Actors It may be discovered that several actors share common behaviors. Generalize the actors. February 2, 2010 Information Technologies Associates, Inc. 26 Actors Eye Doctor Generalization Doctor Dentist Cardiologist February 2, 2010 Information Technologies Associates, Inc. 27 Actors General Electric Large Industrial Customer IBM Customer New York State Office of the Attorney General Governmental Customer New York State Education Department February 2, 2010 Information Technologies Associates, Inc. 28 Actors General Electric Request Material Safety Data Sheet Large Industrial Customer IBM Request Order Status Customer New York State Office of the Attorney General Governmental Customer New York State Education Department Send request for text book February 2, 2010 Information Technologies Associates, Inc. 29 Includes Relationship A Use Case Include relationship says that the behavior of another use case is contained in this use case. Implies the behavior of the included use case is inserted into the behavior of the including use case. February 2, 2010 Information Technologies Associates, Inc. 30 Includes Relationship Get Personnel Information Secure User <<Include>> Verify Identify <<Include>> Retreive Payroll Information Another Secure User February 2, 2010 Information Technologies Associates, Inc. 31 Extends Relationship This relationship specifies that the behavior of a use case may be extended by the behavior of another use case. Unlike a Use Case Include, the Use Case may or may not be extended by another use case. The extending use case may not be able to exist by itself; it provides a degree of modularity to the extended use case. February 2, 2010 Information Technologies Associates, Inc. 32 Extends Relationship Enter Student Demographic information <<Extend>> Admit student <<Extend>> Enter Student High School Information Admissions Office <<Extend>> Enter Prior College Attendance information February 2, 2010 Information Technologies Associates, Inc. 33 How to describe the use case model. Actors Stakeholder . Primary or Secondary Actor. System under design. Other systems. Internal actors. Roles versus Actors. Description. Responsibilities. Goals and objectives the actor has for the system. February 2, 2010 Information Technologies Associates, Inc. 34 Use Case Description Triggers. Activity Steps. Extension Points. Exceptions. Preconditions. Post Conditions. Processing Rules. February 2, 2010 Process Start Start State Normal Stuff End End State Not so Normal Stuff Information Technologies Associates, Inc. 35 Use Case Description Triggers. Activity Steps. Contains a text description of the normal sequence of actions associated with a use case. Number the steps to identify them. Example: 1. open a file, 2. give a new registration number and 3. write down medical treatment would be action steps for a use case called 'register patient' in a hospital. Extension Points. The arrival of an event into the use case that causes execution of the use case to begin. Contains a text description of actions that extend the normal sequence of actions. It opens up the use case to the possibility of extension (extend). Usually introduced with an if ....then. The step causing the extension is identified. Example: 2. if the patient already has a registration number, then retrieve his personal file. Exceptions. Signal raised in response to behavioral faults during system execution. Example. 3. Doctor fails to sign medical treatment form. Reject treatment Preconditions Post Conditions. Processing Rule A constraint that must be true when an operation is invoked. A constraint that must be true at the completion of an operation. A statement that guides how the use case is processed. It will many times consist of If … then statements. Example: If order amount > $1,000,000 then Set Discount to 15%, else, No discount is applied. February 2, 2010 Information Technologies Associates, Inc. 36 System Development Life Cycle Process WHAT HOW Requirements Requirements Use Cases WHAT Analysis Analysis Design Design Build HOW Test Build Deploy February 2, 2010 Process Data Network Business Use Case Test Deploy Programs Programs Databases Information Technologies Associates, Inc. Network 37 Different Levels of Use Cases High Level to Low Level To move from high level to low level, ask “How?” To move from low level to high level, ask “Why?” February 2, 2010 Information Technologies Associates, Inc. 38 Functional Use Cases Start with the Business Use Cases Ask the question, “How do I realize this use case?” The Actor will now have relationships with several, lower-level, use cases. Not really decomposition. February 2, 2010 Information Technologies Associates, Inc. 39 Functional Use Cases Everything that applies to business use cases applies to Functional Use Cases. The Activity Steps are much more detailed. Processing rules play a larger role. February 2, 2010 Information Technologies Associates, Inc. 40 Functional Use Cases While the business use case might be: Get Cash From Bank. The functional use cases might be: Locate an ATM. Identify ATM User. Verify account balance sufficient. Extract money from safe drawers. Assemble withdrawal. Disburse withdrawal. Update Account balance. February 2, 2010 Information Technologies Associates, Inc. 41 UML Stuff. Activity Diagrams Sequence Diagrams Collaboration Diagrams February 2, 2010 Information Technologies Associates, Inc. 42 Functional Use Cases Case_15 Case_16 Case_19 Case_18 Actor_16 Case_20 Case_17 Case_21 Actor_18 Case_22 Case_23 Case_27 Case_28 Case_25 Case_29 Actor_17 Case_24 Case_26 Case_30 Case_31 February 2, 2010 Information Technologies Associates, Inc. 43 Group Functional Use Cases Case_15 Case_18 Case_16 Case_19 Package_5 Actor_16 Case_17 Case_20 Package_1 Case_21 Actor_18 Case_22 Case_24 Case_27 Case_25 Case_28 Case_26 Case_29 Case_23 Package_2 Package_3 Actor_17 February 2, 2010 Information Technologies Associates, Inc. 44 Functional Use Cases Package_5 Actor_16 February 2, 2010 Information Technologies Associates, Inc. 45 Functional Use Cases <<Data Object>> Data Object 1 3: Message_3 1: Message_1 <<Boundary>> 2: Message_2 GUI <<Control>> Control Object 1 4: Message_4 Actor_16 <<Data Object>> 5: Message_5 Data Object 2 6: Message_6 <<Control>> Control Object 2 7: Message_7 <<Data object>> Data Object 3 February 2, 2010 Information Technologies Associates, Inc. 46 More Requirements Robustness Models. User Interface Design. Identifies boundary classes. Identifies control classes. Identifies data access classes. Based on the boundary classes discovered during Robustness Modeling. Other design considerations. February 2, 2010 Information Technologies Associates, Inc. 47 System Development Life Cycle Process WHAT Requirements Business Use Case Analysis Functional Use Case Design HOW February 2, 2010 Other Requirements UI Use Cases Build Component Creation Test Unit, Integration, System, User Acceptance Testing Deploy Programs Information Technologies Associates, Inc. 48 After the Requirements are defined, then what? What Requirements UAT Plan Quality Metrics User Acceptance Test February 2, 2010 How Design Module Design Integration Test Code / Unit Test Analysis Sys Test Plan System Test Int Test Plan Information Technologies Associates, Inc. 49 Agile Development Customer satisfaction by rapid, continuous delivery of useful software Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Even late changes in requirements are welcomed Close, daily cooperation between business people and developers Face-to-face conversation is the best form of communication (co-location) Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances February 2, 2010 Information Technologies Associates, Inc. 50 Use Cases Critical to understanding object oriented software processes. Valuable as part of the requirements activities. Improved communications between stakeholders and development teams. Build consensus about what the system must do. Provide a principle around which to structure project activities. February 2, 2010 Information Technologies Associates, Inc. 51 Use Cases Play an important role for: Stakeholders who demand value from the system Analysts who work with the requirements. Developers who apply use cases to design and develop the system Testers who verify that the system delivers the value demanded by the stakeholders. Technical writers who document how the system is used. User-experience professionals who help make the system easy to use. February 2, 2010 Information Technologies Associates, Inc. 52 The times are changing, but … Things are more like they are now than they ever were before. Dwight D. Eisenhower (1890-1969). 34th President of the US (1953 – 1961) February 2, 2010 Information Technologies Associates, Inc. 53 Questions? February 2, 2010 Information Technologies Associates, Inc. 54 Thank you Contact information: J. Timothy Collier Information Technologies Associates, Inc. PO Box 2220 Scotia, NY 12302 Email: [email protected] Telephone: 518.372.4327 February 2, 2010 Information Technologies Associates, Inc. 55 An Introduction to Use Cases Presented to: Albany, NY Chapter February 2, 2010 Presented by: J. Timothy Collier Information Technologies Associates, Inc. February 2, 2010 Information Technologies Associates, Inc. 56 Bibliography Bittner, K & Spence, I. (2003). Use case modeling. Boston, MA: Addison-Wesley. Brennan, K. (2007). The business analysis body of knowledge. Presentation at BusinessAnalystWorld, Toronto, March 26, 2007. Cockburn, A. (2001). Writing effective use cases. Boston, MA: Addison-Wesley. International Institute of Business Analysis. The guide to the business analysis body of knowledge™: Version 2.0 Framework. Downloaded from http://www.geneva.theiiba.org/download/BABOK20overview.pdf Jacobson, I, Christerson, M, Jonsson, P, & Övergaard, G. (1992). Object oriented software engineering: a use case driven approach. Reading, MA: Addison-Wesley. Object Management Group. (2007). OMG UML Unified Modeling Language (OMG UML), Superstructure, V2.1.2. Downloaded from http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ Rosenberg, D & Scott, K. (2000). Use case driven object modeling with UML: a practical approach. Boston, MA: Addison-Wesley. Zachman, J. (1987). A Framework for information systems architecture. IBM Systems Journal, 26(3), 276 - 292. February 2, 2010 Information Technologies Associates, Inc. 57