Difference between revisions of "UML Activity Diagrams"
| Line 1: | Line 1: | ||
[[Main Page]] > [[Requirements]] > UML Activity Diagrams | [[Main Page]] > [[Requirements]] > UML Activity Diagrams | ||
| + | <div style="padding: 10px 10px; border: 1px solid black; background-color: #F79086;">This page is no longer being maintained and may contain inaccurate information. Please see the [https://www.archivematica.org/docs/latest/ Archivematica documentation] for up-to-date information.</div><p> | ||
These Archivematica [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML] Activity Diagrams are the baseline requirements for Archivematica. | These Archivematica [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML] Activity Diagrams are the baseline requirements for Archivematica. | ||
Latest revision as of 16:36, 11 February 2020
Main Page > Requirements > UML Activity Diagrams
These Archivematica UML Activity Diagrams are the baseline requirements for Archivematica.
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 separate 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[edit]
- AD1 Receive SIP (PDF) (OpenDocument)
- AD2 Audit SIP (PDF) (OpenDocument)
- AD3 Accept SIP for Ingest (PDF) (OpenDocument)
- AD4 Generate AIP (PDF) (OpenDocument)
- AD5 Transfer AIP to Archival Storage (PDF) (OpenDocument)
Archival Storage[edit]
- AD6 Receive AIP (PDF) (OpenDocument)
- AD7 Store AIP (PDF) (OpenDocument)
- AD8 Provide AIP (PDF) (OpenDocument)
- AD9 Recover AIP (PDF) (OpenDocument)
Data Management[edit]
- AD10 Update Database (PDF) (OpenDocument)
- AD11 Query Database (PDF) (OpenDocument)
Access[edit]
- AD12 Request DIP (PDF) (OpenDocument)
- AD13 Deliver DIP (PDF) (OpenDocument)
- AD14 Provide Assistance (PDF) (OpenDocument)
- AD15 Collect Feedback (PDF) (OpenDocument)
Administration[edit]
- AD16 Update Archival Information (PDF) (OpenDocument)
- AD17 Activate Requests (PDF) (OpenDocument)
- AD18 Monitor Data Submission Schedule (PDF) (OpenDocument)
- AD19 Negotiate Submission Agreement (PDF) (OpenDocument)