Difference between revisions of "OAIS Use Cases"
| Line 69: | Line 69: | ||
* One criticism of the ISO-OAIS is that it tends to blur the distinction between Actors and Functions. In many instances it uses the name of a function to describe an actor role. In our first iteration of use cases we will use the ISO-OAIS as literally as possible which means that some actors are named with the original ''verb/noun'' structure (e.g. 'Receive Submission', 'Coordinate Updates'). In a later iteration of the use cases we expect to rename these actors using an ''adjective/noun'' structure (e.g. Submission Receiver, Update Coordinator). | * One criticism of the ISO-OAIS is that it tends to blur the distinction between Actors and Functions. In many instances it uses the name of a function to describe an actor role. In our first iteration of use cases we will use the ISO-OAIS as literally as possible which means that some actors are named with the original ''verb/noun'' structure (e.g. 'Receive Submission', 'Coordinate Updates'). In a later iteration of the use cases we expect to rename these actors using an ''adjective/noun'' structure (e.g. Submission Receiver, Update Coordinator). | ||
| − | * | + | * We've adopted a naming convention for the actors. When referring to actors that come from different functional areas of the OAIS than the current use case, we give the full path to that actor. E.g., when referring to the Generate Report actor while describing an Access use case, we would call the actor Data Management>Gen rate Report. Actors within the functional area of the use case being described can be referred to by their short name. IN the scenario above, Generate DIP would still be just "Generate DIP" when describing an Access use case. |
| + | |||
| + | * Breaking down the sub-use cases for Access is turning out to be more complex than the diagram suggests. The crux of the problem is that there are two requesting actors (Consumer and Administration) each requesting a variety of things: query responses, report responses, assistance responses, and (finally) dissemination responses (DIPs). | ||
| + | |||
| + | One way to break down these use cases is to divide them by the type of object being requested, independent of who is requesting it. This leads to sub-cases that look like: | ||
| + | |||
| + | UC-6.1 Coordinate query request | ||
| + | .2 Coordinate report request | ||
| + | .3 Coordinate assistance request | ||
| + | .4 Coordinate dissemination request… | ||
| + | .n Deliver query response | ||
| + | .n+1 Deliver report response, etc. | ||
| + | |||
| + | The other way is to break it down by requesting actor: | ||
| + | UC-6.1 Coordinate Consumer request | ||
| + | UC-6.2 Coordinate Administration request, etc. | ||
| + | |||
| + | The problem in both cases seems to be that when further detailing the sub-cases, they each typically end up having multiple triggers and/or outcomes (E.g., triggered by request for query, OR request for report, OR request for DIP…; and successful outcome= delivery of result set, OR delivery of report, OR delivery of DIP, etc.) | ||
| + | |||
| + | If you have a generic sub-case UC-0.n, that has multiple triggers A, B and C, and multiple outcomes X, Y, and Z. then what you more likely have are three separate use cases. This seems particularly true if there is a correlation between the triggers and the outcomes: A--->X, B--->Y, C--->Z. When it comes down to translating these into actual requirements, it would be useful for clarity to minimize the number of triggers and/or successful outcomes for each sub-case. | ||
| + | |||
| + | This leads to the conclusion that the sub-cases should be sufficiently granular so as to minimize the triggers and/or outcomes for each sub-case. This would give something like: | ||
| + | |||
| + | UC-6.1 Coordinate Consumer query request... | ||
| + | .n Co-ordinate Consumer Dissemination request | ||
| + | .n+1 Co-ordinate Administration Dissemination request, etc. | ||
| + | |||
| + | Another way of handling it would be through lower level cases: | ||
| + | UC-6.1 Coordinate Consumer request | ||
| + | .1.1 Coordinate Consumer query request | ||
| + | .1.2 Co-ordinate Consumer report request, etc. | ||
| + | |||
| + | The first approach leads to a large number of cases at the UC-6.x level, many of which have similar content. This is somewhat redundant. | ||
| + | |||
| + | However, the lower level cases in the second approach should more properly be reserved for (for lack of a better term) "sub-routines" completely internal to a particular use case (E.g., authenticating a user might be described as a step within a use case -the authentication process might need to be broken down into sub-cases). In the access case, what we have are a number of more-or-less parallel threads that pass through many of the second level use cases in Access (Consumer makes a report request, report is obtained from Data Management, report is delivered to Consumer; Consumer makes dissemination request, AIP is obtained from Storage, DIP is generated, DIP is delivered to Consumer; etc.) | ||
| + | |||
| + | Therefore, redundancy (first approach) is preferred to trying to organize these threads in a third level of use case. | ||
Revision as of 16:57, 3 September 2009
Main Page > Requirements > OAIS Use Cases
Use Cases
Organization
The Use Cases are based on the same broad categories as the OAIS Functional Entities. Like the latter, use cases are organized into hierarchy with high-level scenarios broken down into more specific tests (sub- and sub-sub-cases).
To facilitate cross-references and links, each case has been assigned an alpha-numeric code: the alpha prefix designates its type (UC = use case), the number establishes its position in the hierarchy.
Template
The following template was created to capture each use case scenario:
Summary
- Number: UC-x.x.x, unique tracking number assigned to the use case.
- Name: descriptive name assigned to requirement.
- Context: links to higher-level cases, if applicable.
- Sub-Use Cases: links to lower-level cases, if applicable.
- Overview: brief description of the scenario.
- Actors: the main actor(s) involved in the scenario.
Description
- Preconditions: other use cases whose completion is a precondition for the current case.
- Trigger: the event that initiates the current case.
- Successful outcome: the outcomes of a successful resolution of the scenario.
- Steps: step-by-step breakdown describing the scenario as leading to a successful outcome.
- Exceptions: other possible variations, including unsuccessful outcomes ("Scenario B", "Scenario C" etc).
Documentation
- Citations: quotes from requirement sources explaining the need for a use case or describing one or more of its components
- Diagrams: work-flow or other diagrams illustrating the scenario.
Notes
- Notes: any additional information or issues related to the use case
Notes and Discussion
- in the case where the diagrams and the text in the reference model report don't match, the diagrams were taken as the authoritative representation of the OAIS model.
- One criticism of the ISO-OAIS is that it tends to blur the distinction between Actors and Functions. In many instances it uses the name of a function to describe an actor role. In our first iteration of use cases we will use the ISO-OAIS as literally as possible which means that some actors are named with the original verb/noun structure (e.g. 'Receive Submission', 'Coordinate Updates'). In a later iteration of the use cases we expect to rename these actors using an adjective/noun structure (e.g. Submission Receiver, Update Coordinator).
- We've adopted a naming convention for the actors. When referring to actors that come from different functional areas of the OAIS than the current use case, we give the full path to that actor. E.g., when referring to the Generate Report actor while describing an Access use case, we would call the actor Data Management>Gen rate Report. Actors within the functional area of the use case being described can be referred to by their short name. IN the scenario above, Generate DIP would still be just "Generate DIP" when describing an Access use case.
- Breaking down the sub-use cases for Access is turning out to be more complex than the diagram suggests. The crux of the problem is that there are two requesting actors (Consumer and Administration) each requesting a variety of things: query responses, report responses, assistance responses, and (finally) dissemination responses (DIPs).
One way to break down these use cases is to divide them by the type of object being requested, independent of who is requesting it. This leads to sub-cases that look like:
UC-6.1 Coordinate query request .2 Coordinate report request .3 Coordinate assistance request .4 Coordinate dissemination request… .n Deliver query response .n+1 Deliver report response, etc.
The other way is to break it down by requesting actor: UC-6.1 Coordinate Consumer request UC-6.2 Coordinate Administration request, etc.
The problem in both cases seems to be that when further detailing the sub-cases, they each typically end up having multiple triggers and/or outcomes (E.g., triggered by request for query, OR request for report, OR request for DIP…; and successful outcome= delivery of result set, OR delivery of report, OR delivery of DIP, etc.)
If you have a generic sub-case UC-0.n, that has multiple triggers A, B and C, and multiple outcomes X, Y, and Z. then what you more likely have are three separate use cases. This seems particularly true if there is a correlation between the triggers and the outcomes: A--->X, B--->Y, C--->Z. When it comes down to translating these into actual requirements, it would be useful for clarity to minimize the number of triggers and/or successful outcomes for each sub-case.
This leads to the conclusion that the sub-cases should be sufficiently granular so as to minimize the triggers and/or outcomes for each sub-case. This would give something like:
UC-6.1 Coordinate Consumer query request... .n Co-ordinate Consumer Dissemination request .n+1 Co-ordinate Administration Dissemination request, etc.
Another way of handling it would be through lower level cases: UC-6.1 Coordinate Consumer request .1.1 Coordinate Consumer query request .1.2 Co-ordinate Consumer report request, etc.
The first approach leads to a large number of cases at the UC-6.x level, many of which have similar content. This is somewhat redundant.
However, the lower level cases in the second approach should more properly be reserved for (for lack of a better term) "sub-routines" completely internal to a particular use case (E.g., authenticating a user might be described as a step within a use case -the authentication process might need to be broken down into sub-cases). In the access case, what we have are a number of more-or-less parallel threads that pass through many of the second level use cases in Access (Consumer makes a report request, report is obtained from Data Management, report is delivered to Consumer; Consumer makes dissemination request, AIP is obtained from Storage, DIP is generated, DIP is delivered to Consumer; etc.)
Therefore, redundancy (first approach) is preferred to trying to organize these threads in a third level of use case.