Actors: change-crew member.
Related use-cases:
Outline: the user shuts down and removes the unwanted camera. S/he connects the new camera, absorbs it into the DAS and tests it.Typical course of events:
User action | System response | |
---|---|---|
1. | Runs use case access DAS to get control. | Allows access to DAS computer and hence to cameras. |
2. | Gives the command udaseng. | Displays the entry page of the engineering GUI. Determines and lists the state of all known cameras. |
3. | Powers off and disconnects the unwanted camera. | Camera goes to the "disconnected" state. |
4.
|
Connects and powers on the replacement camera. | Nothing. System does not detect this change automatically. |
5. | Presses the "scan for cameras" button on the GUI. | Determines and lists the state of all known cameras. The newly-connected camera goes to the "unclaimed" state. |
6. | Selects the new camera in the GUI and presses the "Bring on-line" button. | Camera goes to the on-line state. |
7. | Works through the start CIA and ICS use case. | CIA detects the replacement camera and moves it to the "idle" state. The camera is now ready for an observer to use. |
8. | Works through the test camera use case. | As per subordinate use-case. |
Since the engineering interface is a GUI, the access to the DAS computer has to be through a graphics terminal. Telnet from a window on the system computer would be normal. The system response in stage 1, above, implies that that the DAS either polls frequently to check that the camera is still connected, or receives some asynchornous signal when the camera goes away. It's hard to see how a camera that's just been switched off at the mains can send a signal, so polling will be required.