Difference between revisions of "HUB Use Cases"

From Metadata-Registry
Jump to: navigation, search
(OAI Server Use Cases)
(XC HUB Use Cases)
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==XC HUB Use Cases==
+
==== This page is no longer available ====
 
+
===User Roles===
+
 
+
+
 
+
====Human Actors====
+
 
+
*'''System Administrator'''
+
**Overall system administrator. Responsible for system-level software and hardware maintenance
+
 
+
*'''HUB Manager'''
+
**One or more persons responsible for the administrative tasks involved in the management of a HUB instance
+
**Authorizations: Service Administrator for all registered Services Editor for all Collections and Metadata [not sure about this one]
+
**Only role authorized to Delete Services, Users, and Collections
+
 
+
*'''Service Administrator'''
+
**One or more persons authorized to maintain one or more Service records. The user who registers a Service becomes the Service Administrator for that Service
+
**Authorizations:
+
***Service Administrator for all Services owned by that Agent
+
***Edit/Delete Service Records
+
***Designate other Registered Users as Service Contacts
+
***Register Contacts and designate them as: Service Administrators for that Agent or Technical Contacts for that Agent
+
 
+
*'''Service Primary Contact'''
+
**One or more persons acting on behalf of a Service, to whom notifications to the Service may be sent.
+
**Domain of email address must match the domain registered to that Service
+
 
+
*'''Service Technical Contact'''
+
**One or more persons acting on behalf of a service, to whom technical notifications to the Service may be sent.
+
 
+
*'''User'''
+
**A User is a visitor who has an intent to register a service. A User may assume an additional role while registering a service.
+
 
+
====Non-Human Actors====
+
 
+
*'''OAI Harvester'''
+
*'''OAI Server'''
+
*'''HUB Database'''
+
*'''Scheduler (Lenny)'''
+
----
+
 
+
===OAI Harvester Use Cases===
+
 
+
====Use Case 1/OH: OAI Validation succeeds====
+
 
+
====Use Case 2/OH: OAI Validation fails====
+
 
+
====Use Case 3/OH: Data Validation succeeds====
+
 
+
====Use Case 4/OH: Data Validation fails====
+
 
+
====Use Case 5/OH: A Harvest succeeds====
+
;Purpose:An XC project harvests a new record set successfully.
+
;Primary Actor:OAI Harvester
+
;Prerequisites:OAI Harvester must be registered as a service and passed a test validation
+
<b>Sequence</b>
+
#An OAI Harvest is initiated by human or automated process
+
#The harvest proceeds and finds no data errors
+
#Notification of successful harvest is posted to the administrative interface. Notifications include:
+
#* record counts
+
#* link to harvest log
+
#* link to csv file of harvested records
+
#Notification of successful harvest is posted in an email message to the HUB Manager and the Primary contact for the service. Notifications include:
+
#* record counts
+
#* link to harvest log
+
#* link to csv file of harvested records
+
#* link to helpdesk with embedded harvest information
+
;Result: HUB is updated successfully with new data.
+
 
+
====Use Case 6/OH: A Harvest fails for system reasons====
+
;Purpose:An XC project attempts to harvest a new record set but is unsuccessful.
+
;Primary Actor:OAI Harvester
+
;Prerequisites:OAI Harvester must be registered as a service and passed a test validation at some point
+
<b>Sequence</b>
+
#An OAI Harvest is initiated by human or automated process
+
#The harvest fails for reasons having to do with the data provider:
+
#* the server is down temporarily
+
#* the server address has changed and no notice was given to the HUB service registrar
+
#* the server software has changed and no longer complies with the OAI protocol. In this case the Harvester will initiate a test procedure (see Use Cases on server validation)
+
#Notification of an unsuccessful harvest is posted to the administrative interface. Notifications include:
+
#* indication of whether the server was available
+
#* indication of whether a validation test was initiated
+
#* results of the validation test
+
#Notification of successful harvest is posted in an email message to the HUB Manager and the Primary contact for the service. Notifications include:
+
#* indication of whether the server was available
+
#* indication of whether a validation test was initiated
+
#* results of the validation test
+
#* link to helpdesk with embedded harvest information
+
;Result: HUB is not updated with new data.
+
 
+
====Use Case /OH: A Harvest fails (or fails partially) for data reasons====
+
;Purpose:An XC project attempts to harvest a new record set but is only partially successful.
+
;Primary Actor:OAI Harvester
+
;Prerequisites:OAI Harvester must be registered as a service and passed a test validation at some point
+
<b>Sequence</b>
+
#An OAI Harvest is initiated by human or automated process
+
#The harvest proceeds and finds data errors
+
#Notification of a partially successful harvest is posted to the administrative interface. Notifications include:
+
#* record counts (successes and errors)
+
#* link to harvest log with data errors
+
#* link to csv file of successfully harvested records
+
#Notification of partially successful harvest is posted in an email message to the HUB Manager and the Primary contact for the service. Notifications include:
+
#* record counts (successes and errors)
+
#* link to harvest log with data errors
+
#* link to csv file of successfully harvested records
+
#* link to helpdesk with embedded harvest and log information
+
;Result: HUB is updated successfully with new data; records with data errors not included.
+
----
+
 
+
===OAI Server Use Cases===
+
 
+
 
+
 
+
----
+
 
+
===Service Registry Use Cases===
+
 
+
====Use Case 1/SR: A User wishes to register a Service====
+
;Purpose:An XC project has a service that they wish to register.
+
;Primary Actor:User
+
;Prerequisites:User must be associated with the organization providing the service
+
<b>Sequence</b>
+
#User accesses the Service Registry and initiates Registration in one of two ways:
+
#* by entering the URI of the OAI server for the service
+
#* by entering basic information about the organization providing the service -- Name, address, phone, domain (if available), URL, description. User may then enter self (and may designate others in addition) as Primary Contact or Technical Contact by including name and email. If User is neither Primary nor Technical Contact, another role may be entered.
+
#User submits form and Registry sends confirmation email to all contact(s) as well as the Hub Manager.
+
#User and contact(s) respond to confirmation email, verifying email address(es)
+
#Registry notifies HUB Manager(s) that Service has been added
+
;Result: Service is registered. User is now a Registered User and an organization contact associated with the registered service.
+
 
+
====Use Case 2/SR: A Contact wishes to modify a Service registration====
+
;Purpose:An XC project has service registration that they wish to modify.
+
;Primary Actor:Primary Contact or Technical Contact
+
;Prerequisites:Primary Contact or Technical Contact must be associated with the organization providing the service within the service registration.
+
<b>Sequence</b>
+
#Contact accesses the Service Registry and chooses to edit the service registration:
+
#* if the OAI server address has changed, the harvester will initiate a test harvest to:
+
#** refresh the information provided by the server
+
#** test the server conformance with OAI (given that more than the server address might have changed behind the scenes)
+
#* if contact details for registered contacts are changed (or new contacts are designated) the verification of email addresses will be done for any new or changed addresses.
+
#Contact submits form and Registry sends confirmation email to all contact(s) as well as the Hub Manager.
+
#Contact(s) respond to confirmation email, verifying email address(es)
+
#Registry notifies HUB Manager(s) that Service registration has changed
+
;Result: Service registration is updated.
+
 
+
====Use Case 3/SR: A HUB Manager wishes to modify a Service registration====
+
;Purpose:An HUB Manager wishes to modify a service registration.
+
;Primary Actor:HUB Manager
+
;Prerequisites:In general it is preferable for a Primary Contact or Technical Contact to modify a service registration, but in some cases (when the registered Primary Contact and/or Technical Contact are no longer associated with the service organization, or when those contacts will not make the modifications themselves).
+
<b>Sequence</b>
+
#HUB Manager accesses the Service Registry and chooses to edit the service registration:
+
#* if the OAI server address has changed, the harvester will initiate a test harvest to:
+
#** refresh the information provided by the server
+
#** test the server conformance with OAI (given that more than the server address might have changed behind the scenes)
+
#* if contact details for registered contacts are changed (or new contacts are designated) the verification of email addresses will be done for any new or changed addresses.
+
#HUB Manager submits form and Registry sends confirmation email to all contact(s) as well as the Hub Manager.
+
#Contact(s) respond to confirmation email, verifying email address(es)
+
#Registry notifies HUB Manager(s) that Service registration has changed
+
;Result: Service registration is updated.
+

Latest revision as of 13:54, 4 April 2008

This page is no longer available