Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
DSDP/MTJ/Modify Alert
Use-Case Specification: Modify Alert
1. BRIEF DESCRIPTION
The user modifies an existing alert to change, e.g. the text.
2. FLOW OF EVENTS
2.1 Basic Flow of Events
- B1. The user decides to edit the alert.
- B2. The user selects the alert from the Flow designer.
- B3. The user opens a property editor for the selected alert.
- a) The system shows a list of modifiable properties for the alert.
- B4. The user selects the property he wants to edit.
- a) The system opens an editor for the property.
- B5. The user gives a new value to the property.
- a) The system validates the new property value.
- b) The system updates the property to the flow.
- c) The system updates the flow according to the changes.
2.2 Alternative Flows
- Alternative flow 1: The code file cannot be opened
- A1. If the system cannot open the code file for editing, the user will be warned about the error and editing is cancelled.
- Alternative flow 2: The user gives an invalid value for the property
- A2. If the user gives an invalid value for the property, the system will warn the user about the error and the user will be asked to give a new value. The user can also cancel the editing.
- Alternative flow 3: Eclipse refactoring while the Flow designer is open
- A3. If the user performs Eclipse refactoring when the Flow designer is open, the system will inform the user that refactoring was performed and the components in the Flow designer have been updated accordingly.
- Alternative Flow 4: Eclipse refactoring while the Flow designer is closed
- A4. The user refactors code using Eclipse’s refactoring tool.
- a) The system updates the flow according to the refactoring.
- A5. The user opens the Flow designer. The flow is updated according to the refactored code.
- A4. The user refactors code using Eclipse’s refactoring tool.
3. SUBFLOWS
4. KEY SCENARIOS
5. PRECONDITIONS
5.1 Precondition 1: The flow designer is open and has at least one alert
The components in the flow can only be edited in the flow designer.
6. POSTCONDITIONS
6.1 Postcondition 1: The code is changed
The code is changed according to the changes made to the property
6.2 Postcondition 2: The Flow designer’s UI is updated
The flow designer’s UI is updated according to the changes made.
7. EXTENSION POINTS
8. SPECIAL REQUIREMENTS
9. ADDITIONAL INFORMATION
Comments:
Back to main DSDP-MTJ Use Cases