up previous next contents
Up: Use Cases Previous: Search/List ACME Jobs Next: Save a ACME Job   Contents


Open a ACME Job

This use case describes the process of an external user opening a ACME job.

This use case needs to be refactored and made more readable.

Specific problems:

  1. Users can have multiple ACME sessions open per PC
  2. Users can be logged into more than one PC

Notes

  1. This use case is complicated and may need to be refactored to be more readable
  2. A Job module (such as Job Information/Characteristics) may be locked by another user
  3. A Job may be opened by another user, but no modules may be currently locked by that user

Actors

  1. External User
  2. Administrator

Pre-Conditions

  1. The ACME Editor is actively running when the use case begins
  2. There may only be one ACME Editor open, or there may be multiple Editors open.
  3. The user may have a job already open in the current Editor, or not.
  4. In a networked environment, another user may have the job open
  5. Security may be enabled or disabled

Basic Path - No job is open in the ACME Editor

  1. The user is in the ACME Editor, but does not have a job open in the Editor
  2. The user selects an option to open a job
  3. The system invokes the List Jobs use case to let the user select a job to open
  4. The user selects a job to open
    1. If the Job Characteristics module in the job is locked by another user:
      1. The system warns the user that the module is locked by another user (and provides that user's name)
      2. The system opens the job in the current editor in read-only mode
    2. Else, if another user is in the job but has no modules locked:
      1. The system warns the user which other users are editing this job at this time
      2. The system opens the job in the current editor
    3. Else (if the job is not currently opened by another user)
      1. The system opens the job in the current editor
      2. The system records a note that this user opened the job at this date/time
      3. The system records a note that the user is currently editing the job
    4. In any case
      1. The ACME Editor is displayed
      2. The ACME Navigator is displayed with it's options enabled
  5. When the user selects the Edit Job (i.e., "job characteristics") option
    1. If the user has write permission in this functional area
      1. If the module is not locked by another user
        1. The system locks the job at the Edit Job level
        2. The user modifies the job information as desired
        3. When the user selects an option to save and close the Job Characteristics, the Job Characteristics module lock is released
    2. Else, if the user has read-only permission in this area
      1. The system opens to the Edit Job information in read-only mode
    3. Else, if the user has "hidden" access to job information, they are not allowed to open the Job Characteristics screen
      1. Either the Job Information button is deactivated, or the permission takes effect when the user clicks the button

Post-Conditions

  1. A new job is opened in the current ACME Editor
  2. The system is aware that this user is currently editing this job
  3. If the user has Edit permission on the Job Information, and the user is in the Edit Job Information module, the system will maintain information to know that this user has this module locked

Alternative Path #1, There is already a "clean" job open in the ACME Editor

  1. The user has a clean job open in an Editor, and the selects an option to open a job
  2. The system invokes the List Jobs use case to let the user select a job to open
  3. The user selects an option to open the selected job
  4. The system detects that the job is currently being edited by another user
  5. The system prompts that "Note: The following users also have the job open: [list users]. Continue opening, or Cancel?"
    1. If the user select Cancel, the job-open process is stopped at this point
    2. Else, if the user selects "Continue opening"
      1. Continue with the rest of this use case (but with the job in "read-only" mode)
  6. The system prompts the user - "Open job in current Editor? Open a new Editor frame? Cancel?"
    1. If the user selects Cancel, the Job Open operation is stopped, and system displays the current ACME Editor in the state just prior to the start of the Job Open scenario
    2. Else, If the user selects "Open job in current Editor"
      1. The old/current (clean) job in the Editor is closed
      2. The new job is opened in the current Editor
    3. Else, if the user selects "Open job in a new Editor frame"
      1. The system invokes the "Open Job in New Editor" sub use case
    4. The system records a note that this user opened the job at this date/time
  7. If the user has Edit permission on the Job Information, and the user is in the Edit Job Information module, the system will maintain information to know that this user has this module locked

Post-Conditions

  1. A new job is opened in the current ACME Editor or in a new ACME Editor frame

Alternative Path #2, Already a "dirty" job open in the ACME Editor

TODO - AL - MAY NEED TO RE-WORD THIS BELOW HERE

  1. The user is in the ACME Editor, and has a dirty job open in the Editor
  2. The user selects an option to open a job
  3. The system invokes the List Jobs use case to let the user select a job to open
  4. If the job is currently locked by another user
    1. The system prompts "The job is open by another user; Open Read-Only, or Cancel?"
    2. If the user select Cancel, the job-open process is stopped at this point
    3. Else, if the user selects "Open Read Only"
      1. Continue with the rest of this use case (but with the job in "read-only" mode)
  5. If the job is not currently locked by another user
    1. The system prompts the user - "Open job in current Editor? Open a new Editor frame? Cancel?"
    2. If the user selects "Cancel"
      1. The Job Open operation is stopped
    3. Else, If the user selects "Open job in current Editor"
      1. The system tells the user that "The current job has been modified; save, discard, or cancel?"
      2. If the user selects "Cancel"
        1. The Open Job operation is cancelled
        2. The user is returned to their previous job
      3. If the user selects "Discard current job"
        1. The system discards the changes to the current job
        2. The system opens the new desired job in the current Editor
      4. If the user selects "Save"
        1. The current job is saved
        2. The system opens the new desired job in the current frame
        3. The system creates an informational lock at the job level indicating that the job is now opened by this user
        4. The user begins working with the job ...
    4. Else, if the user selects "Open job in a new Editor frame"
      1. The system invokes the "Open Job in New Editor" sub use case
    5. The system records a note that this user opened the job at this date/time
    6. The system locks the job so that no other user can edit it at this time

Post-Conditions

  1. The job open in ACME before the "Job Open" use case may or may not be saved to the database
  2. A job is retrieved from the database and is opened in the current ACME Editor or in a new ACME Editor
  3. A job-level informational lock is obtained on the newly opened job

Sub Use Case: Open Job in New Editor

  1. The system creates a new Editor frame
  2. The system opens the desired job in that new frame
  3. The system displays the new frame in the foreground, in front of the previous ACME Editor frame

"Used" Use Cases

  1. Search/List ACME Jobs

Other Requirements

  1. When a user selects a job to open, if that job is already open in a different ACME Editor frame, bring that job to the foreground
  2. The system shall record a "last maintained by" user id field at the job level any time a user saves information in any module
    1. This will include the user id and and timestamp
    2. If security is not enabled, the user id of the Unknown User will be stored in the "last maintained by" field
  3. The system shall record a "last maintained by" user id field at the module level any time a user saves information in a module
    1. This will include the user id and and timestamp
    2. If security is not enabled, the user id of the Unknown User will be stored in the "last maintained by" field
  4. Recent file list
    1. The system will display a list of the user's most recently opened 10 jobs
    2. A job will be added to the list any time it is opened into the ACME Editor
    3. This list will appear under the Job menu, in a manner similar to the file history in Microsoft Word
    4. In the Job menu, the job list will only show the job short description
    5. This list will be stored on the user's computer, in a data file under the user's home directory
    6. Jobs will appear once and only once in the list
      1. i.e., if the job has been opened three consecutive times, it should only appear once in the list
    7. The job list cannot be modified by the user
    8. Note: This job list may get out of sync with jobs that are actually in the database, and this must be accounted for
    9. This requirement is not documented in the scenarios above
      1. The behavior when a job in this list is accessed should be the same as the "Open Job Scenario"

Issues

  1. If the user has a job open on one PC, then moves to another PC, they may have the Job Information module locked from the first PC. How is this handled on the second PC?
    1. Per our discussion of 2004-01-27, this will be handled in "the most simple" manner (TBD)