Use Cases UML OOD Course Dr Solange Karsenty

  • Slides: 42
Download presentation
Use Cases - UML OOD Course Dr. Solange Karsenty

Use Cases - UML OOD Course Dr. Solange Karsenty

Why modeling techniques? • Specific languages to describe higher level concepts and abstractions. •

Why modeling techniques? • Specific languages to describe higher level concepts and abstractions. • Graphical representations help us in understanding, documenting and explaining a problem. • Writing down ideas in a structured way helps us to tackle complexity and multi-dimensionality of software. Þ Mastering one or several modeling techniques, one or several software development processes, and knowing the most important design patterns are prerequisites for successful (object-oriented) software development. START NOW! UML 2

Formal - Informal • Formal modeling techniques • e. g. Z, VDM • COOPN,

Formal - Informal • Formal modeling techniques • e. g. Z, VDM • COOPN, Petri-Nets – allow various kinds of checks – completeness is an issue – mainly used for core parts of a system • Semi-formal modeling techniques • e. g. Booch, UML • Informal modeling techniques • e. g. RDD, CRC, Storyboarding They all have their place! UML 3

Business Processes Using UML for modeling business processes: • at beginning of a software

Business Processes Using UML for modeling business processes: • at beginning of a software project for a clear basis • for business process reengineering Þ Same diagrams for different purposes, different abstraction levels, different domains. References for business process modeling: • from amazon web-page • from rational web-page Dorothea Beringer, 1999 UML 4

Other sources. . . There exist many other modeling techniques and development methods that

Other sources. . . There exist many other modeling techniques and development methods that have influenced UML, e. g. • • • OOSE (Jacobson) Fusion (HP, D. Coleman) FORAM (Ian Graham) OBA (Rubin et al. ) RDD (Wirfs et al. ) BON (Nerson et al. ) various scenario modeling techniques various statechart modeling techniques and extensions various dataflow and eventflow modeling techniques. . . Dorothea Beringer, 1999 UML 5

References for UML Official documents about UML from Rational: http: //www. rational. com/uml/documentation. html

References for UML Official documents about UML from Rational: http: //www. rational. com/uml/documentation. html • Object Constraint Language Specification (defines OCL, which is used to specify the well-formedness of the UML) • UML Notation Guide v 1. 1 • UML Semantics • UML Extension for Business Modeling • UML Quick Reference: http: //www. rational. com/uml/qr/ Books about UML: • web-pages of Rational • amazon. com UML for special applications (e. g. real-time systems): . . . Processes that use UML as modeling technique: . . . Dorothea Beringer, 1999 UML 6

Metamodel for UML Example: Metamodel for Relationships Dorothea Beringer, 1999 UML 7

Metamodel for UML Example: Metamodel for Relationships Dorothea Beringer, 1999 UML 7

Models in UML Models showing the static structure of a system: – class diagrams

Models in UML Models showing the static structure of a system: – class diagrams and object diagrams – implementation diagrams: component diagrams, deployment diagrams Models showing the dynamic behavior of a system: – use case model Þ external view of the system – activity diagrams Þ external/internal view of a system – interaction diagrams: sequence diagrams and collaboration diagrams Þ internal view of the system Models showing the dynamic behavior of a single class: – statecharts diagrams, activity diagrams Dorothea Beringer, 1999 UML 8

Identifying System Boundaries Inside the system: you have to create it Outside the system:

Identifying System Boundaries Inside the system: you have to create it Outside the system: you do not create it (it already exists), yet you have to worry about it • e. g. interfaces to humans, to other systems • actors are entities outside system boundaries that interact with system (r) • actors model roles, not persons! • use cases are started by actors (special case: use cases triggered by timing events) Defining boundaries is iterative, expect to redefine your use cases several times in first phases of project! Dorothea Beringer, 1999 UML 9

System Boundaries and Abstraction Levels System boundaries can be defined at several abstraction levels

System Boundaries and Abstraction Levels System boundaries can be defined at several abstraction levels (b: make order): • high level with no representatives • middle level taking into account who/what actually enters the information • lower level taking into account how data is actually entered • Actors and interactions between actors and system change with abstraction level! • Starting level depends on complexity of project! Dorothea Beringer, 1999 UML 10

Using Use Case Diagrams • Use case diagrams are used to visualize, specify, construct,

Using Use Case Diagrams • Use case diagrams are used to visualize, specify, construct, and document the (intended) behavior of the system, during requirements capture and analysis. • Provide a way for developers, domain experts and end-users to Communicate. • Serve as basis for testing. • Use case diagrams contain use cases, actors, and their relationships. 11

Use Case name • Use cases specify desired behavior. • A use case is

Use Case name • Use cases specify desired behavior. • A use case is a description of a set of sequences of actions, including variants, a system performs to yield an observable result of value to an actor. • Each sequence represent an interaction of actors with the system. 12

Specifying the Behavior of a Use Case • Describing the flow of events within

Specifying the Behavior of a Use Case • Describing the flow of events within the use case. • Can be done in natural language, formal language or pseudo-code. • Includes: how and when the use case starts and ends; when the use case interacts with actors and what objects are exchanged; the basic flow and alternative flows of the behavior. 13

Actors name • An actor represents a set of roles that users of use

Actors name • An actor represents a set of roles that users of use case play when interacting with these use cases. • Actors can be human or automated systems. • Actors are entities which require help from the system to perform their task or are needed to execute the system’s functions. • Actors are not part of the system. 14

Use Cases and Actors • From the perspective of a given actor, a use

Use Cases and Actors • From the perspective of a given actor, a use case does something that is of value to the actor, such as calculate a result or change the state of an object. • The Actors define the environments in which the system lives 15

Example of Use Case Diagram registration student updating grades faculty output generating 16

Example of Use Case Diagram registration student updating grades faculty output generating 16

Relationships between Use Cases 1. Generalization - use cases that are specialized versions of

Relationships between Use Cases 1. Generalization - use cases that are specialized versions of other use cases. 2. Include - use cases that are included as parts of other use cases. Enable to factor common behavior. 3. Extend - use cases that extend the behavior of other core use cases. Enable to factor variants. http: //www. agilemodeling. com/essays/use. Case. Reuse. htm 17

1. Generalization • The child use case inherits the behavior and meaning of the

1. Generalization • The child use case inherits the behavior and meaning of the parent use case. • The child may add to or override the behavior of its parent child 18

More about Generalization registration non-graduate registration 19

More about Generalization registration non-graduate registration 19

2. Include base <<include>> included • The base use case explicitly incorporates the behavior

2. Include base <<include>> included • The base use case explicitly incorporates the behavior of another use case at a location specified in the base. • The included use case never stands alone. It only occurs as a part of some larger base that includes it. 20

More about Include • Enables to avoid describing the same flow of events several

More about Include • Enables to avoid describing the same flow of events several times by putting the common behavior in a use case of its own. updating grades <<include>> verifying student id output generating <<include>> 21

3. Extend base <<extend>> extending • The base use case implicitly incorporates the behavior

3. Extend base <<extend>> extending • The base use case implicitly incorporates the behavior of another use case at certain points called extension points. • The base use case may stand alone, but under certain conditions its behavior may be extended by the behavior of another use case. 22

More about Extend • Enables to model optional behavior or branching under conditions. Exam

More about Extend • Enables to model optional behavior or branching under conditions. Exam copy request <<extend>> Exam-grade appeal 23

Relationships between Actors • Generalization. student graduate student non-graduate student 24

Relationships between Actors • Generalization. student graduate student non-graduate student 24

Relationships between Use Cases and Actors • Actors may be connected to use cases

Relationships between Use Cases and Actors • Actors may be connected to use cases by associations, indicating that the actor and the use case communicate with one another using messages. updating grades faculty 25

Example cellular network user place phone call <<extend>> receive phone call <<extend>> place conference

Example cellular network user place phone call <<extend>> receive phone call <<extend>> place conference call receive additional call use scheduler Cellular Telephone 26

A More Complicate Example 27

A More Complicate Example 27

Use Case Description Each use case may include all or part of the following:

Use Case Description Each use case may include all or part of the following: § § § § Title or Reference Name - meaningful name of the UC Author/Date - the author and creation date Modification/Date - last modification and its date Purpose - specifies the goal to be achieved Overview - short description of the processes Cross References - requirements references Actors - agents participating Pre Conditions - must be true to allow execution Post Conditions - will be set when completes normally Normal flow of events - regular flow of activities Alternative flow of events - other flow of activities Exceptional flow of events - unusual situations Implementation issues - foreseen implementation problems 28

Example- Money Withdraw Use Case: Withdraw Money Author: ZB Date: 1 -OCT-2004 Purpose: To

Example- Money Withdraw Use Case: Withdraw Money Author: ZB Date: 1 -OCT-2004 Purpose: To withdraw some cash from user’s bank account Overview: The use case starts when the customer inserts his credit card into the system. The system requests the user PIN. The system validates the PIN. If the validation succeeded, the customer can choose the withdraw operation else alternative 1 – validation failure is executed. The customer enters the amount of cash to withdraw. The system checks the amount of cash in the user account, its credit limit. If the withdraw amount in the range between the current amount + credit limit the system dispense the cash and prints a withdraw receipt, else alternative 2 – amount exceeded is executed. • Cross References: R 1. 1, R 1. 2, R 7 • • • 29

Example- Money Withdraw (cont. ) • Actors: Customer • Pre Condition: – The ATM

Example- Money Withdraw (cont. ) • Actors: Customer • Pre Condition: – The ATM must be in a state ready to accept transactions – The ATM must have at least some cash on hand that it can dispense – The ATM must have enough paper to print a receipt for at least one transaction • Post Condition: – The current amount of cash in the user account is the amount before the withdraw minus the withdraw amount – A receipt was printed on the withdraw amount – The withdraw transaction was audit in the System log file 30

Example- Money Withdraw (cont. ) § Typical Course of events: Actor Actions System Actions

Example- Money Withdraw (cont. ) § Typical Course of events: Actor Actions System Actions 1. Begins when a Customer arrives at ATM 2. Customer inserts a Credit card into ATM 3. System verifies the customer ID and status 5. Customer chooses “Withdraw” operation 4. System asks for an operation type 7. Customer enters the cash amount 6. System asks for the withdraw amount 8. System checks if withdraw amount is legal 9. System dispenses the cash 10. System deduces the withdraw amount from account 11. System prints a receipt 13. Customer takes the cash and the receipt 12. System ejects the cash card 31

Example- Money Withdraw (cont. ) • Alternative flow of events: – Step 3: Customer

Example- Money Withdraw (cont. ) • Alternative flow of events: – Step 3: Customer authorization failed. Display an error message, cancel the transaction and eject the card. – Step 8: Customer has insufficient funds in its account. Display an error message, and go to step 6. – Step 8: Customer exceeds its legal amount. Display an error message, and go to step 6. • Exceptional flow of events: – Power failure in the process of the transaction before step 9, cancel the transaction and eject the card 32

Example- Money Withdraw (cont. ) § One method to identify use cases is actor-based:

Example- Money Withdraw (cont. ) § One method to identify use cases is actor-based: - Identify the actors related to a system or organization. - For each actor, identify the processes they initiate or participate in. § A second method to identify use cases is event-based: - Identify the external events that a system must respond to. - Relate the events to actors and use cases. § The following questions may be used to help identify the use cases for a system: - What are tasks of each actor ? Will any actor create, store, change, remove, or read information in the system ? What use cases will create, store, change, remove, or read this information ? Will any actor need to inform the system about sudden, external changes ? Does any actor need to be informed about certain occurrences in the system ? Can all functional requirements be performed by the use cases ? 33

Documenting Use Cases (1) Includes: – Preconditions – Postconditions – Flow of events or

Documenting Use Cases (1) Includes: – Preconditions – Postconditions – Flow of events or interactions (with conditionals, branching or loops) for basic functionality – and for alternatives and exceptions – Error conditions – Special (non-functional) requirement, e. g. time restrictions – Priority and development status In a use case we describe the behavior of the system as perceived from the outside, from the actor’s point of view. We describe how the system interacts with the outside world, not what it does internally! (d: improve previous use case, add alternative for cancel and for incorrect inputs) UML 34

Primary and Secondary Scenarios • Scenario: one particular path through the use case (one

Primary and Secondary Scenarios • Scenario: one particular path through the use case (one instance of the use case) • Primary Scenario: normal path where all goes well, or most likely path • Secondary Scenarios: other paths – alternative scenarios: other regular paths (b) – exceptional scenarios: for handling errors (b) Questions for finding secondary scenarios: • other actions that can be taken at this point? • something that could go wrong at this point? • some behavior that can happen any time during the primary scenario, e. g. cancel or restart? UML 35

Documenting Use Cases (2) Structuring the description: • one complete description/diagram per scenario •

Documenting Use Cases (2) Structuring the description: • one complete description/diagram per scenario • complete description of the primary scenario, separate descriptions for seconday scenarios (e. g. in alternative path and exception path sections) only containing deltas to basic description • all in one text or diagram inclusive alternatives and exceptions How to describe the flow of events in a use case: • plain text (b) • numbered steps • pseudo code (good for some special cases, normally gets too detailed and too unreadable) (b) • activity diagrams • interaction diagrams (showing interactions between system and actors) with pseudo code, bracket code or text to the left hand side UML 36

Documenting Use Cases (3) How detailed? • depends on phase in project (inception, elaboration,

Documenting Use Cases (3) How detailed? • depends on phase in project (inception, elaboration, construction) • depends on importance and complexity of scenario (compromise: primary scenario detailed with steps and/or diagrams, secondary scenarios only plain text description) • not too detailed: capturing requirements means not constructing the system in plain text! • define and remember the goal for which you make use cases: who creates them or uses them for what? Reader of the use cases • determine modeling technique, level of detail • who could they be? (b, r) • they determine if use case descriptions are well done, not you! Correctness, completeness • walk-throughs, reviews, observation, . . . UML 37

Use Cases: Activity Diagrams (1) Activity diagrams are part of the dynamic diagrams of

Use Cases: Activity Diagrams (1) Activity diagrams are part of the dynamic diagrams of UML, and can also be used for documenting use cases: start of the use case Check validity claim [claim valid] step 1 end of the use case a step in the use case (represented as a state containing actions), or several steps that are detailed in a separate diagram transition between steps condition on the transitions decision with decision point 2] [condition 1] [condition step 3 step 2 UML 38

Use Cases: Activity Diagrams (2) step a parallel steps step b step c step

Use Cases: Activity Diagrams (2) step a parallel steps step b step c step d Drawbacks: Activity diagrams contain more model elements not shown here as these are not relevant when representing use cases. • space for describing steps is limited on diagram • no representations of uses and extends relationships (unless you invent one and add it to the notation) • diagrams can get too complex ==> decide for each use case if textual description, activity diagram or a combination is appropriate (b: make activity diagram) UML 39

Interfaces at System Boundary It may be helpful to further document the interfaces at

Interfaces at System Boundary It may be helpful to further document the interfaces at the system boundaries given by the use cases, e. g, by: • Storyboarding (for graphical user interfaces) • just handwritten pictures showing the different screens (b) • maybe diagram showing the sequence of the screens • or user interface prototype (check motivation!!!) • Protocol definition (for system interfaces) • e. g. when exchanging XML messages, define these messages • Interaction diagrams on different abstraction levels (b) • • between actors and system, use asynchronous events description to the left with structured English or brackets for different paths ATTENTION: different abstraction levels! UML 40

Use Cases are good for. . . • • • figuring out problem statement

Use Cases are good for. . . • • • figuring out problem statement (iterative process!) figuring out system boundaries discussing requirements with end users specifying external behavior of system, functional requirements for system developers (tension with previous point!) starting point for design(class diagrams, interaction diagrams) splitting up more detailed analysis of requirements along use cases splitting up construction iterations along use cases derive test cases, derive user documentation reuse, architecture (see books) project size and cost estimation (see book of G. Schneider) …… ==> many similar techniques are known and have been used for a long time in many successful software development projects! UML 41

Books on Use Cases • Many books, often showing application of use cases for

Books on Use Cases • Many books, often showing application of use cases for a specific domain, e. g. telecommunication, process control systems, information systems, …. • Good general books on use cases: • Applying Use Cases, by G. Schneider: short, easy to read in one evening, guide about creating and documenting use cases, also contains how to define architecture based on use cases and do cost estimation based on use cases; get that book before you start your next software project! • Software Reuse, by Jacobson, Griss and Jonsson: good book about how to create complex and reusable software systems and architectures, shows how use cases are used for that; get that book after you have used use cases for the first time so you get more needed in-depth knowledge UML 42