Difference between revisions of "UML Activity Diagrams"
Line 7: | Line 7: | ||
These diagrams are revisions of the [[OAIS Activity Diagrams]] which, in turn, were derived from the [[OAIS Use Cases]] analysis. These revisions were based on a scenario analysis that tried to focus on the pragmatic steps necessary to accomplish each core OAIS function using existing technology and archival business processes. | These diagrams are revisions of the [[OAIS Activity Diagrams]] which, in turn, were derived from the [[OAIS Use Cases]] analysis. These revisions were based on a scenario analysis that tried to focus on the pragmatic steps necessary to accomplish each core OAIS function using existing technology and archival business processes. | ||
+ | |||
+ | Each activity is likely to generate some metadata and have one or more information entities as an input and output. However, these will be captured in a seperate metadata requirement analysis and information model. Likewise, each activity may be governed or restricted by one or more policy or procedures but these are also intentionally left out of the diagram for simplicity. Except where they are explicitly noted, these diagrams assume that there no errors in the activity flow, i.e. these are 'sunny-day' scenarios. | ||
Revision as of 23:47, 4 September 2009
Main Page > Requirements > UML Activity Diagrams
These Archivematica UML Activity Diagrams are the current baseline requirements for Archivematica.
The system documentation lists each numbered activity in these diagrams and provides instructions on how these requirements might be met using the current Archivematica release. Wherever possible, these activities are assigned to software or technical tools. If it is not possible to automate these functions in the current system iteration, the functions are incorporated into a manual procedure to be carried out by the end user. This ensures that the entire set of requirements are being carried out in the system, which is an integrated whole of software, people and procedures. The goal is to improve the level of automation and sophistication with each system iteration.
These diagrams are revisions of the OAIS Activity Diagrams which, in turn, were derived from the OAIS Use Cases analysis. These revisions were based on a scenario analysis that tried to focus on the pragmatic steps necessary to accomplish each core OAIS function using existing technology and archival business processes.
Each activity is likely to generate some metadata and have one or more information entities as an input and output. However, these will be captured in a seperate metadata requirement analysis and information model. Likewise, each activity may be governed or restricted by one or more policy or procedures but these are also intentionally left out of the diagram for simplicity. Except where they are explicitly noted, these diagrams assume that there no errors in the activity flow, i.e. these are 'sunny-day' scenarios.
Ingest
- AD1 Receive SIP (PDF) (OpenDocument) v1
- AD2 Audit SIP (PDF) (OpenDocument) v5
- AD3 Accept SIP for Ingest (PDF) (OpenDocument) v4
- AD4 Generate AIP (PDF) (OpenDocument) v2
- AD5 Transfer AIP to Archival Storage (PDF) (OpenDocument) v2
Archival Storage
- AD6 Receive AIP (PDF) (OpenDocument) v2
- AD7 Store AIP (PDF) (OpenDocument) v1
- AD8 Provide AIP (PDF) (OpenDocument) v1
- AD9 Recover AIP (PDF) (OpenDocument) v1
Data Management
- AD10 Update Database (PDF) (OpenDocument) v1
- AD11 Query Database (PDF) (OpenDocument) v1
Access
- AD12 Request DIP (PDF) (OpenDocument) v1
- AD13 Deliver DIP (PDF) (OpenDocument) v1
- AD14 Provide Assistance (PDF) (OpenDocument) v1
- AD15 Collect Feedback (PDF) (OpenDocument)
Administration
- AD16 Update Archival Information (PDF) (OpenDocument)
- AD17 Activate Requests (PDF) (OpenDocument)
- AD18 Monitor Data Submission Schedule (PDF) (OpenDocument)
- AD19 Negotiate Submission Agreement (PDF) (OpenDocument)