This is the fourth of several use cases in support of CRUD for topics and queues. Comments are welcome.

USE CASE 4: Update a Destination

Basic Description
An administrator uses the system to update a destination which already exists within a JBoss server.

Preconditions
It is assumed that the user has already authenticated to the system and has been successfully authorized. It is also assumed that the Use 1 will already have been executed and the user has a list of destinations from which to choose.

Goal
A destination is successfully updated.

Basic flow of events
1. The user indicates to the system that they wish to update a particular destination.
2. The system displays a list of attributes of the destination for update.
3. The user updates some attributes and indicates to the system to update the destination with the given settings.
4. The system takes the information entered by the user, validates it and updates the existing destination.
5. The system indicates to the user that the destination was successfully updated.
6. The use case ends.


Alternate flows
A4.1: Information validation fails, destination not updated
During step 4) of the Basic Flow:
1. The system finds a problem with the information the user submitted.
2. The system displays the information the user submitted and indicates to the user which piece(s) of information caused the problem.
3. The use case ends leaving the destination unchanged.
A4.2: Information validation fails, user fixes problem
After step 2) of Alternative Flow A4.1:
1. The user updates the pieces of information which the system indicated had caused the problem and indicates to the system to update the destination.
2. The system takes the information entered by the user, validates it and updates the destination.
3. The system indicates to the user that the destination was successfully updated.
4. The use case ends.

A4.3: User cancels update
During step 3) of the Basic Flow:
1. The user indicates to the system that they want to cancel the update of the destination.
2. The system does not attempt to update the destination. The system displays the page the user was on before attempting to update the destination.
3. The use case ends leaving the destination unchanged.


Special Requirements
1. Different attributes are displayed for update depending upon the type of the destination being updated, i.e. queue or topic. The precise breakdown of attributes by type is listed in the reference documents - queue_elements.xls and topic_elements.xls).
2. A destination updated through the system must persist across restarts of the JBoss server.