mirror of
https://github.com/jackyzha0/quartz.git
synced 2025-12-24 13:24:05 -06:00
114 lines
3.2 KiB
Markdown
114 lines
3.2 KiB
Markdown
---
|
|
title: "use-case-diagrams"
|
|
tags:
|
|
- info201
|
|
---
|
|
|
|
- specifies the participants (actors) and the relationships between them
|
|
- high level view of what a system does (not how) and who uses it
|
|
- represent users perspective of a system
|
|
- used mainly in requirements specification and early system dev
|
|
- effectively a todo list
|
|
|
|
## 1 pros
|
|
+ informal,flexible, easy to construct
|
|
+ easily understood
|
|
+ improve communication between users and developers
|
|
+ can be used to confirm requirements
|
|
+ provide overview
|
|
+ link analysis to design
|
|
+ can be used to inform subsequent dev tasks
|
|
+ derive test cases
|
|
+ prioritise imlementation tasks
|
|
+ help clarify new feature requests or bug reports
|
|
|
|
## 2 Notation
|
|
|
|
### 2.1 Actor
|
|
- roles that people have when interacting with the system
|
|
- external systems or hardware that are essential to system operation
|
|
|
|
|
|
|
|
### 2.2 Use case
|
|
- discrete unit of system functionality
|
|
- activity from perpective of an actor
|
|
- can be abstract or focused
|
|
- say nothing about flow or behaviour
|
|
- map to ⇒ menu items, forms, reports, etc
|
|
|
|
|
|
|
|
### 2.3 Association
|
|
- relationship (interaction) between actor and use casel
|
|
- actor can be associated with more than one use case
|
|
- use case can be associated with more than one actor
|
|
|
|
|
|
|
|
### 2.4 Specialisation/generalisation
|
|
- actors and use cases can be orgainsed into special/general hierachies
|
|
- acotrs can be specialisations of another actor
|
|
- same for use cases
|
|
- mutually exclusive
|
|
- similar to inheritance
|
|
|
|
|
|
|
|
### 2.5 Dependency
|
|
- occur between use cases
|
|
- one case extends the behaviour of another
|
|
- one case includes the behabiour of another
|
|
- one case requires the behaviour of another
|
|
- read in direction of arrow
|
|
- indicate opportunities for reuse of functionality
|
|
|
|
|
|
|
|
#### 2.5.1 Extends dependency
|
|
- use cases can have optional, subordinate tasks
|
|
- useful with specialised actors
|
|
|
|
|
|
|
|
#### 2.5.2 Includes dependency
|
|
- use cases that have mandatory, subordinate tasks
|
|
- does not indicate sequence, only that they must happen
|
|
|
|
|
|
|
|
#### 2.5.3 Requires dependency
|
|
- mandatory, _independent_ tasks, that must be completed first
|
|
- forces sequence
|
|
- use sparingly
|
|
|
|
|
|
|
|
## 3 development of use case diagrams
|
|
organise related use case diagrms itno use case model
|
|
- have have multiple levels of detail
|
|
- group related diagrams into packages
|
|
|
|
### 3.1 example methods
|
|
- user goal technique ⇒ simple
|
|
- event decompositition technique ⇒ more comprehensive
|
|
|
|
### 3.2 top down
|
|
identify actors ⇒ identify use cases ⇒ detail use cases
|
|
- who will enter and/or recience information
|
|
- what other systems will interact with the system
|
|
- prioritise use cases
|
|
- further develop use case, starting with highest priority
|
|
- structure overall use case model
|
|
|
|
> **avoid specifying the sequence**
|
|
|
|
### 3.3 bottom up
|
|
create scenario ⇒ generalise scenario ⇒ organise use case model
|
|
|
|
## 4 Examples
|
|
|
|
|
|
|
|
|