|
|
Another important step is to match up use cases with actors. The relationship between actors and use cases is potentially many-to-many, in that the same actor may initiate many different use cases, and a single use case may be relevant to many different actors. By cross-referencing actors with use cases, we ensure that
We didn't identify an actor who, in the final analysis, really has no use for the system after all.
Conversely, that we didn't specify a use case that nobody really cares about after all.
For each use case–actor combination, it's useful to determine whether the actor consumes information and/or provides information. Another way to view this aspect of a system is whether actors need write access to the system's information resources (providing) versus having read-only access (consuming).
If the number of actors and/or use cases isn't prohibitive, a simple table such as Table 9-1 can be used to summarize all of the preceding.
|
Initiating Actor → |
Student |
Faculty |
Billing System |
(Etc.) |
|---|---|---|---|---|
|
Use Cases(Below) |
||||
|
Register for a course |
Provides info |
N/A |
N/A | ?/td> |
|
Post final grades |
Consumes info |
Provides info |
N/A | ?/td> |
|
Request a transcript |
Consumes info |
Consumes info |
N/A | ?/td> |
|
Determine a student's course load |
Consumes info |
Consumes info |
Consumes info | ?/td> |
|
(Etc.) | ?/td> | ?/td> | ?/td> | ?/td> |
|
|