<< Page 1 Page 3 >>


2 Use Case Documentation

When defining primary uses cases, it is not needed to capture "every detail of the use cases". Thus, use cases are used primarily to capture the high level user-functional requirements of a system. Keeping this definition in mind, we design our use-case-model not primarily as a design-concept, but rather as an auxiliary means for communicating with the customer. The primary use-cases reflect the basic functionality of the ADS.

Actors

In our project we identified the following actors:

InternetUser

The InternetUser is interested in viewing the data and museums. He ist the one visiting the webpage of the ADS and using the ADS for display-purposes

Designer

A Designer creates Virtual Museums. He can arrange floors, room and vitrinas, but is not necessarily able to enter data. Furthermore, a Designer is able to create publications, such as a CD-Rom or a catalogue.

DataCollector

A DataCollector is able to enter data concerning artefacts, graves and settlements into the system. DataCollectors (as they are generalized by Designers) can create and modify virtual museums.

Scientific DataCollector

A Scientific DataCollector is able to enter data concerning artefacts, graves and settlements. Furthermore, a Scientific DataCollector is able to add scientific documentation. Scientific Data Collectors (as they are generalized by DataCollectors) can create and modify Virtual Museums.

Administrator

An administrator has all the rights of the other groups, i.e. he is able to enter data, scientific, etc. Furthermore he has the privilege to edit rights and groups.

Database

Took into consideration to be an actor, because it is not part of the system but interacts closely with it.

Use Cases

We identified the following use cases:

Detailed Use Case Description

Here is an example for a detailed use case description of the use case Enter Data:

Actors

Data Collectors (and thus also Scientific DataCollectors as they are generalized by DataCollectors, and Administrators as they are generalized by Scientific DataCollectors)

Priority

Priority: 1 Reason: Entering Data is an essential part of the system.

Status

Filled

Preconditions

User has correctly logged on to the system. See use case ''Authenticate''.

Postconditions

Data is stored in the database or use-case fails or is cancelled. In any case the actor will be presented with the normal logged-in screen.

Extension Points

none

"Used" Use Cases

Use Case Authentication Use Case Search

Flow of Events

Primary Scenario
The actor selects ''Enter Data''
  1. if (Actor wants to enter data based on an already existing object)
    1. Actor searches for object using the use case ''Search'' (this means by name or by inventary-number).
    2. if (Actor accepts an object and wants to add a new one based on this existing one)
      • Copy data to editing-/entering-mask
      • Give object new inventary-number
    3. if (Actor accepts an object and wants to edit the existing data) Copy data to editing-/entering-mask

  2. if (Actor wants to enter completely new data)
    1. Actor decides if the new object is an artefact, a settlement or a grave
    2. Empty editing-/entering-mask is opened


  3. Actor enters data into and/or edits already existing data in the user-interface

  4. Actor presses submit-button

  5. Consistency-checks (as no inventary-number or file-names may occur twice in the system, ...)

  6. if (Consistency-Error)
    Give error-message and - according to the error - go back to editing-/entering-mask (inventary-number) or prompt the actor to

  7. System submits data to the database

  8. Data is stored

  9. Multimedia files are stored using the filesystem

  10. A confirmation is displayed
Secondary Scenario
The actor can cancel the process at any time when interacting with the system using the use case ''Enter Data''. The use case will end at this point and the system will display the standard-screen for logged-in actors.\newline As the use case ''Search'' is integrated into ''Enter Data'', cancelling the process of adding data while performing a search will be dealt by the cancel-options of ''Enter Data'' and therefore lead to the same result as just mentioned above.

Activity Diagram

The Activity Diagram for the use case Enter Data can be seen here.

User Interface

What the User Interface for Enter Data will look like can be seen in the following story boards:

Storyboard 1    Storyboard 2

<< Page 1 Page 3 >>