Skip to main content

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.

Jump to: navigation, search

DSDP/MTJ/Add Screen

< DSDP‎ | MTJ

Use-Case Specification: Add Screen


1. BRIEF DESCRIPTION

An application’s user interface must have at least one screen. The screen is the container that contains the actual user interface components. There are several types of screens that can be added to the flow.


2. FLOW OF EVENTS

2.1 Basic Flow of Events

B1. The user decides to add a new screen to the flow.
a) The system shows the available components according to the UI toolkit being used.
B2. The user selects a component.
B3. The user adds a new screen to the flow.
a) The screen component placement is enabled, which allows the user to select a location for the component within the flow.
B4. The user selects the placement of the new screen within the flow.
B5. The system asks for the name of the component from the user.
a) The system generates the code for the new class with default properties.
b) The system redraws the flow with the added component.
c) The system opens the properties view for the added screen.

2.2 Alternative Flows

Alternative flow 1: The user adds a new screen to the code.
A1. The user adds a new screen to the code and saves the file.
a) The system adds the new screen to the flow designer’s resource tree.
A2. The user opens the Flow designer.
A3. The user selects the new screen component from the resource tree.
A4. The user adds the component to the flow.
a) The system verifies that the component belongs to the correct toolkit.
b) The system redraws the flow with the added component.
c) The system opens the properties view for the added screen.
Alternative flow 2: Improper screen component placement by the user
A5. If the user tries to place the new screen component over an existing component or outside the given area, the system will show visual indicator and denies the placement.
Alternative flow 3: The user gives an invalid name for the new component.
A6. If the user gives an invalid name for the component, then the user will be informed of the error and the component’s name will be asked for again. The user has possibility to cancel the naming but then the creation of the component will also be cancelled.


3. SUBFLOWS


4. KEY SCENARIOS


5. PRECONDITIONS

5.1 Precondition 1: Flow designer is open and a new flow is created

In order to add new screens to the flow, there must be a flow open. The flow can, however, contain other screens.


6. POSTCONDITIONS

6.1 Postcondition 1: The new screen is available in the flow The new screen is available and accessible in the flow with a valid name. The new screen is added to the screen component hierarchy. A code file is created for the new screen component.


7. EXTENSION POINTS


8. SPECIAL REQUIREMENTS


9. ADDITIONAL INFORMATION



Comments:


Back to main DSDP-MTJ Use Cases

Back to the top