OAIS Use Cases - Revision history

Evelyn McLellan at 23:17, 3 September 2009

2009-09-03T23:17:14Z

Peter at 22:28, 3 September 2009

2009-09-03T22:28:53Z

Peter at 22:28, 3 September 2009

2009-09-03T22:28:35Z

Peter: /* Notes and Discussion */

2009-09-03T22:00:13Z

Notes and Discussion

Peter: /* Notes and Discussion */

2009-09-03T21:59:48Z

Notes and Discussion

Peter: /* Notes and Discussion */

2009-09-03T21:59:16Z

Notes and Discussion

Peter: /* Notes and Discussion */

2009-09-03T21:57:26Z

Notes and Discussion

Peter at 21:49, 3 September 2009

2009-09-03T21:49:07Z

Peter at 21:48, 3 September 2009

2009-09-03T21:48:24Z

Peter: Created page with 'Main Page > Requirements > OAIS Use Cases =Use Cases= UC-1 Ingest UC-2 Archival Storage UC-3 Data management [[UC-4|UC-4 Administratio…'

2009-09-03T21:40:37Z

Created page with 'Main Page > Requirements > OAIS Use Cases =Use Cases= *UC-1 Ingest *UC-2 Archival Storage *UC-3 Data management *[[UC-4|UC-4 Administratio…'

New page

[[Main Page]] > [[Requirements]] > OAIS Use Cases

=Use Cases=

*[[UC-1|UC-1 Ingest]]

*[[UC-2|UC-2 Archival Storage]]

*[[UC-3|UC-3 Data management]]

*[[UC-4|UC-4 Administration]]

*[[UC-5|UC-5 Preservation Planning]]

*[[UC-6|UC-6 Access]]

=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.

← Older revision		Revision as of 23:17, 3 September 2009
Line 19:		Line 19:

	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.		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.
		+
		+	See [[Glossary]] for definitions of terms used in the use cases.

	=Template=		=Template=

← Older revision		Revision as of 22:28, 3 September 2009
Line 1:		Line 1:
	[[Main Page]] > [[Requirements]] > OAIS Use Cases		[[Main Page]] > [[Requirements]] > OAIS Use Cases

−	~~=Use Cases=~~

	*[[UC-1\|UC-1 Ingest]]		*[[UC-1\|UC-1 Ingest]]

@@ Line 74: / Line 74: @@
 **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
+***6.2      Coordinate report request
-***.3      Coordinate assistance request
+***6.3      Coordinate assistance request
-***.4      Coordinate dissemination request…
+***6.4      Coordinate dissemination request…
-***.n      Deliver query response
+***6.n      Deliver query response
-***.n+1    Deliver report response, etc.
+***6.n+1    Deliver report response, etc.
 **The other way is to break it down by requesting actor:
 ***UC-6.1 Coordinate Consumer request
@@ Line 85: / Line 85: @@
 **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
+***6.n      Co-ordinate Consumer Dissemination request
-***.n+1    Co-ordinate Administration Dissemination request, etc.
+***6.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

@@ Line 72: / Line 72: @@
 * 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
@@ Line 81: / Line 79: @@
 ***.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
 ***6.1.1    Coordinate Consumer query request
 ***6.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.

@@ Line 73: / Line 73: @@
 * 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:
+**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
+***UC-6.1  Coordinate query request
-.2      Coordinate report request
+***.2      Coordinate report request
-.3      Coordinate assistance request
+***.3      Coordinate assistance request
-.4      Coordinate dissemination request…
+***.4      Coordinate dissemination request…
-.n      Deliver query response
+***.n      Deliver query response
-.n+1    Deliver report response, etc.
+***.n+1    Deliver report response, etc.
-The other way is to break it down by requesting actor:
+**The other way is to break it down by requesting actor:
-UC-6.1 Coordinate Consumer request
+***UC-6.1 Coordinate Consumer request
-UC-6.2 Coordinate Administration request, etc.
+***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.)
+**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.
-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:
-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...
-UC-6.1  Coordinate Consumer query request...
+**Another way of handling it would be through lower level cases:
-.n      Co-ordinate Consumer Dissemination request
+***UC-6.1  Coordinate Consumer request
-.n+1    Co-ordinate Administration Dissemination request, etc.
+***6.1.1    Coordinate Consumer query request
-Another way of handling it would be through lower level cases:
+**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.)
-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.
+**Therefore, redundancy (first approach) is preferred to trying to organize these threads in a third level of use case.

← Older revision		Revision as of 21:57, 3 September 2009
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.

← Older revision		Revision as of 21:49, 3 September 2009
Line 21:		Line 21:

	=Template=		=Template=
−
−	~~== Use Case Template ==~~

	The following template was created to capture each use case scenario:		The following template was created to capture each use case scenario:

← Older revision		Revision as of 21:48, 3 September 2009
Line 19:		Line 19:

	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.		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=
		+
		+	== Use Case 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).
		+
		+	*

OAIS Use Cases - Revision history

Evelyn McLellan at 23:17, 3 September 2009

Peter at 22:28, 3 September 2009

Peter at 22:28, 3 September 2009

Peter: /* Notes and Discussion */

Peter: /* Notes and Discussion */

Peter: /* Notes and Discussion */

Peter: /* Notes and Discussion */

Peter at 21:49, 3 September 2009

Peter at 21:48, 3 September 2009

Peter: Created page with 'Main Page > Requirements > OAIS Use Cases =Use Cases= *UC-1 Ingest *UC-2 Archival Storage *UC-3 Data management *[[UC-4|UC-4 Administratio…'

Peter: Created page with 'Main Page > Requirements > OAIS Use Cases =Use Cases= UC-1 Ingest UC-2 Archival Storage UC-3 Data management [[UC-4|UC-4 Administratio…'