4-1 © Prentice Hall, 2007 Topic 4: Structuring Systems Requirements: Use Case Description and Diagrams Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A. Hoffer

Topic 4 2 © Prentice Hall, 2007 Chapter Objectives Af ter studying this chapter you should be able to: – Understand how to structure requirements with use case diagrams. – Explain the basics of use case construction using UML standards. – Construct use case diagrams. – Write text-based use cases.

Topic 4 3 © Prentice Hall, 2007

Topic 4 4 © Prentice Hall, 2007 What Is Requirements Structuring? The process of analyzing, organizing, and modeling the requirements obtained via interviews, questionnaires, observation, and document analysis Relevant UML models include use cases, class diagrams, interaction diagrams, and activity or statechart diagrams

Topic 4 5 © Prentice Hall, 2007 Use Case Deliverables Use case diagrams Written descriptions of use-case contents

Topic 4 6 © Prentice Hall, 2007

Topic 4 7 © Prentice Hall, 2007 UML Use Case Diagram Symbols Use Case Actor Boundary Connection Include relationship Extend relationship >

Topic 4 8 © Prentice Hall, 2007 What Is a Use Case? A depiction of a system’s behavior or functionality under various conditions as the system responds to requests from users Full functioning for a specific business purpose

Topic 4 9 © Prentice Hall, 2007 What Is an Actor? An external entity that interacts with the system Most actors represent user roles, but actors can also be external systems. An actor is a role, not a specific user; one user may play many roles, and an actor may represent many users.

Topic 4 10 © Prentice Hall, 2007 What Is a Boundary? The dividing line between the system and its environment - Use cases are within the boundary. - Actors are outside of the boundary.

Topic 4 11 © Prentice Hall, 2007 What Is a Connection? An association between an actor and a use case Depicts a usage relationship Connection does not indicate data flow

Topic 4 12 © Prentice Hall, 2007 What Is an > Relationship? A connection between two use cases Indicates a use case that is used (invoked) by another use case Links to general purpose functions, used by many other use cases

Topic 4 13 © Prentice Hall, 2007

Topic 4 14 © Prentice Hall, 2007 What Is an > Relationship? A connection between two use cases Extends a use case by adding new behavior or actions Specialized use case extends the general use case

Topic 4 15 © Prentice Hall, 2007 What Is a Stereotype A construct that extends the UML vocabulary Adds new meanings to existing entities Depicted with > delimiters > and > are stereotypes

Topic 4 16 © Prentice Hall, 2007 Use Case Diagram in MS Visio

Topic 4 17 © Prentice Hall, 2007

Topic 4 18 © Prentice Hall, 2007 Include vs. Extend Use > if you want to model an extension to, or a variation of, a complete use case that exists in its own right Use > if you want to factor the common behavior among two or more use cases into a single generalized use case

Topic 4 19 © Prentice Hall, 2007 Actors can be grouped in generalization categories.

Topic 4 20 © Prentice Hall, 2007 Written Use Cases Document containing detailed specifications for a use case Contents can be written as simple text or in a specified format

Topic 4 21 © Prentice Hall, 2007

Topic 4 22 © Prentice Hall, 2007 Level of Use Case Refers to degree of detail in the use case description Five suggested levels (Cockburn) 1. White – as seen from clouds 2. Kite – “birds-eye view” 3. Blue – sea-level view 4. Fish – below sea-level 5. Black – bottom of the sea summary detail

Topic 4 23 © Prentice Hall, 2007 summary detail

Topic 4 24 © Prentice Hall, 2007 Sample Format for Written Use Case Title – descriptive name, matches name in use case diagram Primary actor – usually a user role Stakeholders – any group or individual with an interest in the function of the use case

Topic 4 25 © Prentice Hall, 2007 Sample Format for Written Use Case (Continued) Precondition – conditions that must be satisfied in order to execute the use case Minimal guarantee – outputs that can be expected if the service attempt failed Success guarantee – outputs that can be expected if the service succeeds

Topic 4 26 © Prentice Hall, 2007 Sample Format for Written Use Case (Continued) Trigger – an event or action that initiates the use case Main success scenario – description of sequence of interactions between actor and use case during the use case execution Extensions – detailed description of how errors are dealt with

Topic 4 27 © Prentice Hall, 2007 A sample written use case at kite level

Topic 4 28 © Prentice Hall, 2007 Use case at sea level Corresponds with Step 1 of kite-level use case

Topic 4 29 © Prentice Hall, 2007 Use case at sea level Corresponds with Step 2 of kite-level use case

Topic 4 30 © Prentice Hall, 2007 Guidelines for Good Use Cases Choose a good name Illustrate a complete behavior Identify a completable behavior Provide “inverse” use cases Limit each use case to one behavior Represent the actor’s point of view

Topic 4 31 © Prentice Hall, 2007 Recap Af ter studying this chapter we learned to: – Understand how to structure requirements with use case diagrams. – Explain the basics of use case construction using UML standards. – Construct use case diagrams. – Write text-based use cases.