use case model. c-s 5462 use case model describes what the user expects the system to do...
TRANSCRIPT
![Page 1: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/1.jpg)
Use Case ModelUse Case Model
![Page 2: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/2.jpg)
C-S 546 2
Use case model
• describes what the user expects the system to do– functional requirements
• may describe only the functionalities that are visible to the user– requirements view
• may include additional functionalities to elaborate those in the previous step– design view
• consists of use case diagrams and textual descriptions
![Page 3: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/3.jpg)
C-S 546 3
Elements of a Use Case diagram
actor
Use case Use case
Use case Use case
associa
tion
association
generalization
dependency
dependency
System
actor
![Page 4: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/4.jpg)
C-S 546 4
Definitions• System
– a black box that describes the system or subsystem that is modeled
– example: ATM system, account verification subsystem– represented optionally as a rectangle in the use case diagram,
but generally not shown
• Actor– a role played by an external entity that interacts with the
system– One object may play multiple roles in a context in which case
there will be multiple actors• example: bank manager as a customer
![Page 5: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/5.jpg)
C-S 546 5
Definitions (continued)
• Primary actor– an actor who initiates the major, main or important use
cases in the system– example : a customer in a banking system
• Secondary actor– an actor who is involved with one or more use cases but
does not initiate the use cases– example : database
• The concepts of primary and secondary actors will be useful in ranking the roles played by the actors
![Page 6: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/6.jpg)
C-S 546 6
Definitions (continued)
• Generalization between actors– one actor can be a specialization of another
actor– based on the same concept as the specialization
relationship between classes– example : preferred customer in a bank is a
specialization of a customer
![Page 7: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/7.jpg)
C-S 546 7
Definitions (continued)
• Use case– an important functionality to be implemented
and is visible to the actors– an interacting behavior between an actor and
the system• Must yield an observable result to the actor
– example: “deposit” in a banking system
![Page 8: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/8.jpg)
C-S 546 8
Definitions (continued)
• Association– an interaction between an actor and a use case– represented by an arrow between an actor and a
use case– unidirectional associations must be represented
by arrows• direction of arrow indicate information flow
– bi-directional associations can be represented by double-sided arrows or straight lines
![Page 9: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/9.jpg)
C-S 546 9
Definitions (continued)
• Generalization between use cases– based on the same concept as generalization
between classes; uses the same symbol– one use case can be designated as a
specialization of another use case– example: “withdraw with overdraft protection”
is a specialization of “withdraw”
![Page 10: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/10.jpg)
C-S 546 10
Definitions (continued)
• “include” dependency– one use case may include another use case
– if use case A includes a use case B, B must be implemented in order to implement A
– based on the same concept as modular programming
– represented as a dashed arrow from A to B with a label “<<include>>”
– example : “withdraw” includes “update account”
![Page 11: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/11.jpg)
C-S 546 11
Definitions (continued)• “extend” dependency
– one use case may be extended by another use case– if use case A is extended by a use case B, then both A and B
can be independently implemented and used• A will occasionally use B depending on some constraints
– based on the same concept as modular programming– represented as a dashed arrow from B to A with a label
“<<extend>>”• Notice that the arrow is reversed
– example : “withdraw” is extended by “check for privileged customer”
![Page 12: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/12.jpg)
C-S 546 12
Constraints in a Use Case model
• every use case must be connected to an actor or be included in another use case or extends another use case
• every use case connected to an actor must return an observable result to the actor– may be data or confirmation of termination of
an action
![Page 13: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/13.jpg)
C-S 546 13
How to find actors?
• those that interact with the system (provide input, observe results, provide control information, …)– primary actors
• those that are used by the system but external to the system– secondary actors such as data stores
• information about actors can be found in the problem description
• generally, users of the system are primary actors
![Page 14: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/14.jpg)
C-S 546 14
How to find use cases?
• every requirement is a use case
• every functionality that supports the implementation of a requirement is a use case– design issue– found when the first (abstract) use case model
is refined to express a design
![Page 15: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/15.jpg)
C-S 546 15
How to find use case relationships?
• extracted from the application domain• must be justifiable from the application domain or
from the designer’s choice• examples
– “withdraw” includes “update account” is justifiable from application domain
– “withdraw” is extended by “withdraw with overdraft protection” is a designer’s choice
• designer can always implement two different versions of withdrawals
![Page 16: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/16.jpg)
C-S 546 16
Use case narrative
• not part of UML notation • textual descriptions of a use case
– important for design and implementation of use case
• most OO tools provide a mechanism to add use case narratives– see Rational Rose for example
• may include additional information and constraints on the use cases– pre and post-conditions
![Page 17: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/17.jpg)
C-S 546 17
Use case instance
• a particular situation of a use case• generally described using an activity diagram (to
be discussed later)– shows the algorithmic version of a use case
• there can be several instances of the same use case, each having a different result
• examples– Successful withdrawal– “withdraw” denied because of insufficient balance– “withdraw” denied because of overdraft violation
![Page 18: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/18.jpg)
C-S 546 18
Case Study - ATM
• Model only the transactions• Customer accounts assumed to exist
– Opening and closing of accounts is handled by another portion of the system
• Include operations “deposit”, withdraw”, “check balance”, “transfer”
• If balance is zero or less than the amount to be withdrawn, then withdrawal should fail
![Page 19: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/19.jpg)
C-S 546 19
Deposit
Withdraw
Check balance
Transfer Database
customer
Login
Logout
All dependency relationships are of type <<include>>
![Page 20: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/20.jpg)
C-S 546 20
Use case narratives - ATM• Deposit
– Using this functionality, a user will be able to add some money to his/her account
– Account identification and amount to be deposited must be input– Upon completion, the balance in the account will be updated to
include the additional amount
• Check balance – A user can check the balance in an account using this
functionality– Account identification must be input and the balance in the
account will be output– The account remains unchanged upon completion
![Page 21: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/21.jpg)
C-S 546 21
Use case narratives – ATM (continued)
• Write the narratives for “withdraw” and “transfer”
• The narratives more or less reflect the requirements as written in a requirements document
• A requirements document may also be referred with a cross reference in each requirement pointing to the appropriate use case in the use case diagram
![Page 22: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/22.jpg)
C-S 546 22
Use case instance – “deposit”
Deposit (ACCOUNT_IDENTIFIER acct, MONEY amount) {
if (validate_account (acct)) {
account = retrieve_account (acct);
account.balance = account.balance + amount;
write_account (account); // update the database
}
else display (“Invalid account identifier”);
}
![Page 23: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/23.jpg)
C-S 546 23
Deposit
Withdraw
Check balance
Transfer Database
customer
Login
Logout Validate account
Update account
All dependency relationships are of type <<include>>
Use case diagram for ATM - revisited
![Page 24: Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities](https://reader036.vdocument.in/reader036/viewer/2022062313/56649cc45503460f9498dbba/html5/thumbnails/24.jpg)
C-S 546 24
ATM - Exercises
• Write the narratives for the revised version of ATM use case diagram
• Enhance the diagram to include the following:– A manager can open an account– A manager can close an account– An account may come with overdraft protection
during withdrawal