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/Flow Designer

< DSDP‎ | MTJ

General Comments:

Create New Flow

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

The user creates a new flow in the flow designer.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to create a new flow.
B2. The user selects the New Flow –feature.
a) The system starts the New Flow –wizard.
B3. The user selects the application model.
B4. The user selects the UI toolkit.
B5. The user inputs the class and package name for the application start-up point class (e.g. MIDlet).
B6. The user closes the wizard.
a) The system creates the code according to user’s selections.
b) The system creates a new flow window.
c) The system adds an application start to the flow.
d) The system adds an application end to the flow.

Alternative Flows

Alternative flow 1: The user uses an existing class as the start-up and ending point
A1. The user creates a new flow with the wizard.
A2. The user deselects the choice to create a new application start-up and ending point class from the wizard.
A3. The user closes the wizard.
a) The system creates the flow without an application start-up and ending point.
A4. The user adds an existing class to the wizard that is suitable for the start-up and ending point.
a) The system recognises that the added class is a start-up and ending class and visualises it accordingly within the flow.
Alternative Flow 2: The user does not give a package name
A5. If the user leaves the package name empty, the class is created according to the default package.
Alternative Flow 3: The user gives an invalid name for the class
A6. The user enters a name for the application start-up point class.
a) The system notifies the user and asks for a new name until the user has provided a valid name for the class. The user can cancel the wizard if he wants.
Alternative Flow 4: The user creates a flow during project creation
A7. The user creates a new project with MTJ’s wizard.
A8. The user requests the wizard to also create a new Flow Diagram.
a) The system starts the New Flow Diagram wizard after project is created.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The user has an open project


POSTCONDITIONS

Postcondition 1: A new flow with the application’s start-up and ending points is created

The flow created will contain application start-up and end in the flow designer.

Postcondition 2: The code associated with the flow is created

The code is created for the MIDlet and the commandhandler.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Add Application Start

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

The user can add an application start to the flow as the initial state of the application.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to add an application start.
a) The system shows the application start types available for the flow’s current UI toolkit.
B2. The user selects the application start component from the component list.
B3. The user places the application start within the flow.
a) The system queries mandatory properties (e.g. name) for the application start component.
B4. The user inputs and accepts the mandatory properties for the application start component.
a) The system creates the base class for the application model (e.g. MIDlet) and the required methods for it.
b) The system adds the application start component to the flow.

Alternative Flows

Alternative flow 1: The flow already contains an application start component
A1. If the flow already contains an application start component, the user will be warned about the situation and adding a new application start component is cancelled.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The flow without an application start is open

An application start can only be added to an existing and open flow that doesn’t have an application start.


POSTCONDITIONS

Postcondition 1: The code is created for the application start

Postcondition 2: The application start component is included in the flow

The component in the flow is accessible; it can be moved, etc.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Modify Application Start

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

The user can change the properties of the application start component.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to modify the application start component (e.g. MIDlet class) properties.
B2. The user selects the application start component he wants to modify.
B3. The user selects the properties list view for the application start component.
a) The system shows the list of available properties for the application start component.
B4. The user selects the property he wants to modify.
a) The system opens the property editor for the selected property.
B5. The user modifies the property and accepts the change.
a) The system updates the code according to the changes made.
b) The system updates the UI of the flow designer component.

Alternative Flows

Alternative Flow 1: The user inputs an invalid value for the property
A1. If the user gives an invalid new value for the property being altered, the system will warn the user about the invalid value and reverts the property back to its original value.
Alternative Flow 2: The user edits the code for the application start
A2. If the user edits the code for the application start, the system notices the changed code when the user saves the code. Then system will update the application start component in the flow accordingly.
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 components in the designers have been updated accordingly.
Alternative Flow 4: Eclipse refactoring while the Flow designer is closed
A4. The user refactors the code using Eclipse’s refactoring tool.
a) The system updates the flow according to refactoring.
A5. The user opens the Flow designer. The flow is updated according to the refactored code.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The Flow designer is open and has one application start component


POSTCONDITIONS

Postcondition 1: The component is updated according to the changes made

Postcondition 2: The undo feature is available

The undo feature is available to undo the latest change to properties.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION


Comments:


Delete Application Start

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

The user can remove the application start component from the flow.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to remove an application start component from the flow.
B2. The user selects the application start component from within the flow.
B3. The user removes the selected application start component.
a) The system removes the code for the application start component.
b) The system removes the screen changes attached to the application start component.
c) The system removes the application start component from the flow.
d) The system updates the other views accordingly.

Alternative Flows

Alternative Flow 1: The user removes the application start component from the code.
A1. If the user removes the application start component from the code, the system notices the removal when the user saves the code. The system updates the flow and other views according to the change.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The flow designer is open and has an application start


POSTCONDITIONS

Postcondition 1: The application start component and attached code is removed

The user can no longer run the application because it doesn’t have application starting point.

Postcondition 2: The undo feature is available

The undo feature is available for undoing the removal of the application start component.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Add Application End

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

The user can add an application end to the flow as the exit state of the application.

FLOW OF EVENTS 2.1 Basic Flow of Events

B1. The user decides to add an application end.
B2. The user selects the application end component from the component list.
B3. The user places the application end within the flow
B4. The user inputs and accepts the mandatory properties for the application end component.
a) The system creates the code for the application end component.
b) The system adds the application end component to the flow.

Alternative Flows


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The flow is open

An application end can only be added to an existing and open flow.


POSTCONDITIONS

Postcondition 1: The code is created for the application end

Postcondition 2: The application end component is included in the flow

The component in the flow is accessible; it can be moved, etc.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Add Screen

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


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.


FLOW OF EVENTS

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.

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.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

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.


POSTCONDITIONS

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.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Modify Screen

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

Screen components in the flow have several properties that can be altered by the user. Screen component properties define the behaviour and look and feel of the screen in the application. Single or multiple screens can be selected for modification.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to modify a screen.
B2. The user selects the screen component he wants to modify and opens the property editor.
a) The system opens the properties view for the selected screen.
B3. The user modifies the properties.
B4. The user finishes modifying and saves the changes.
a) The system updates the code according to the user’s changes.
b) The system updates the flow design’s code.
c) The system redraws the Flow designers UI.

Alternative Flows

Alternative Flow 1: Multiple screen modifying
A1. The user performs a multi-selection of several screens.
a) The system marks the screens that have been selected.
b) The system displays a property view with the properties that the selected screens have in common available for selection.
A2. The user modifies the properties.
A3. The user finishes modifying the properties and saves the changes.
a) The system updates the code according to the user’s changes.
b) The system updates the flow design’s code.
c) The system redraws the Flow designers UI.
Alternative Flow 2: Eclipse refactoring while the Flow designer is open
A4. If the user performs Eclipse refactoring when the Flow designer is open, the system will inform the user that refactoring was performed and components in the Flow designer have been updated accordingly.
Alternative Flow 4: Eclipse refactoring while the Flow designer is closed
A5. The user refactors the code using Eclipse’s refactoring tool.
a) The system updates the flow according to the refactoring.
A6. The user opens the Flow designer. The flow is updated according to the refactored code.
Exception 1: The file is locked by another application or editor
A7. The user modifies the properties of a screen of which the file is locked by another application.
A8. The user finishes modifying and saves the file.
a) The system shows an error message explaining why the error has occurred.
b) The modifications are not applied.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The Flow designer is open The Flow designer must be open with an active flow present.

5.2 Precondition 2: The user has created a screen and it is within the active flow The active flow in the Flow designer must contain a screen that can be modified.


POSTCONDITIONS

Postcondition 1: The screen is modified according to the user’s actions


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Delete Screen

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

This use-case describes what happens when the user deletes a screen from the active flow.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to delete a screen.
B2. The user selects the delete screen function.
a) The system does not delete the screen’s code, but it removes the code associated with the deleted screen.
i) The possible screenchange code from the deleted screen.
ii) The possible screenchange events code to the removed screen from other components.
b) The system removes the screen from the active flow and updates the flow’s code.
c) The system redraws the active flow.

Alternative Flows

Alternative flow 1: The user deletes multiple screens
A1. The user selects several screens from an active flow.
A2. The user selects the delete screen function.
a) The system removes the code associated with the deleted screens.
b) The system removes the screens from the active flow and updates the flow’s code.
c) The system redraws the active flow.
Alternative flow 2: The screen is deleted using something other than the Flow designer’s delete screen function
A3. The user deletes a screen using another method than those provided by the Flow designer.
A4. The user activates flow that contains deleted component.
a) The system removes the code associated with the deleted screen.
b) The system removes the screen from the active flow and updates the flow’s code.
c) The system redraws the flow.
Exception 1: The file is locked by another application or editor
A5. The user tries to delete a screen but the file is locked by another application.
a) The system shows an error message explaining that the screen cannot be removed because it is locked by another application. Delete is aborted.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The user has the Flow designer open and the flow contains at least one screen


POSTCONDITIONS

Postcondition 1: The screen is removed from the active Flow Diagram The screen is removed from the active Flow Diagram and also the code linked to the screen. The undo feature is available.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Add Screen Change

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION This use-case describes the flow when a screen change is added between two screens in the Flow designer.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to add a screen change between two components.
B2. The user selects the add screen change feature.
a) The system displays all possible starting points in the active flow diagram.
B3. The user selects the starting point.
B4. The user selects the target component.
B5. The user accepts the change and saves the file.
a) The system generates the code.
b) The system updates the Flow diagram’s code.
c) The system redraws the Flow diagram.

Alternative Flows

Alternative flow 1: The user tries to set an invalid value for the properties
A1. The user tries to set invalid values for the mandatory properties.
A2. The user accepts the changes.
a) The system shows an error message and does not remove the mandatory properties view.
Alternative flow 2: The user wants to add a screen change to a new starting point
A3. The user decides to add a screen change between two components.
A4. The user selects the add screen change feature.
a) The system displays all possible starting points.
A5. The user selects the add new command or the add new menu item feature.
a) The system asks for the mandatory properties of the command/menu item.
A6. The user sets the mandatory information and saves the changes.
a) The system generates the code for the command/menu item.
b) The system updates the flow diagram’s code.
c) The system redraws the flow.
d) The system displays the newly created command/menu item as a new starting point.
A7. The user selects the newly created command/menu item as the starting point.
A8. The user selects the target component.
A9. The user accepts the change and saves the file.
a) The system generates the code.
b) The system updates the flow diagram’s code.
c) The system redraws the flow.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: A flow diagram with two screens must be open


POSTCONDITIONS

Postcondition 1: A screen change is made between the user’s selected screens


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Modify Screen Change

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

This use-case describes the flow when the screen change object is modified in the Flow designer.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to modify the screen change.
B2. The user selects the screen change object to modify.
B3. The user selects the modify screen change feature.
a) The system reveals the properties view of the screen change object.
B4. The user modifies the properties.
i) The user can change the starting point.
ii) The user can change the target component.
B5. The user accepts the changes made.
a) The system generates the required code.
b) The system modifies the flow diagram’s code.
c) The system redraws the flow diagram.

Alternative Flows


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS 5.1 Precondition 1: The Flow designer is open with an active flow diagram which contains a screen change object

The Flow designer must be open with a flow diagram which must contain at least one screen change object


POSTCONDITIONS

Postcondition 1: The screen change object is modified

The screen change object is modified according to the changes made by the user.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Delete Screen Change

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

This use-case describes how a screen change object is deleted from an active flow diagram.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to delete a screen change object.
B2. The user selects the screen change object to delete.
B3. The user selects the delete screen change function.
a) The system removes the code that triggers the screen change in the start-up class (.e.g. the code generated inside the commandAction(Command c,Displayable d) )
b) The system updates the flow diagram’s code.
c) The system redraws the flow diagram.

Alternative Flows

Exception 1: The file is locked by another application
A1. The user tries to delete a screen change object but the file is locked by another application.
a) The system shows an error message explaining that the screen change object cannot be removed because it is locked by another application. Delete is aborted.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The Flow designer is open with a flow diagram present which contains at least one screen change object


POSTCONDITIONS

Postcondition 1: The screen change object is removed from the flow

The screen change object is removed from the active flow. The generated code associated with the screen change object is also removed. The undo feature is available.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Add Operation Triggering

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

This use-case describes how pre- and post- command handling can be added to the flow diagram. Pre- and post- command handling means that a method is called before and/or after a command/menu selection.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to add a pre- or post- command handling function.
B2. The user selects the command/menu with menu items to which the pre- or post- command handling will be added to.
B3. The user selects the command or menu where he wants to add the pre- or post- command.
a) The system displays the properties for the selected command or menu.
B4. The user opens the add pre- (or post-) command feature.
a) The system shows a list of all available classes.
B5. The user selects a class.
a) The system shows a list of all available methods.
B6. The user selects the method to be called.
a) The system generates the required code.
b) The system updates the flow’s code.
c) The system redraws the flow.

Alternative Flows


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The Flow designer is open with a flow diagram present

The Flow designer must be open with a flow diagram present. 5.2 Precondition 2: The active flow must contain a command or a menu with menu items

The active flow diagram must contain a command or a menu with menu items since pre- and post- command handling functions are added to these.

6. POSTCONDITIONS

Postcondition 1: The command or menu item must contain a pre- and post- command handling function

The command or menu item within a menu must contain a pre- and post- command handling function that is called prior to or after the selection of this item.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Modify Operation Triggering

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

This use-case describes how pre- and post- command handling functionality can be modified.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to modify pre- and post- command handling.
B2. The user selects the command/menu item that contains pre- and post- command handling.
a) The system opens the properties view for the command/menu.
B3. The user selects the existing pre- or post- command handling feature.
a) The system shows a list of classes with suitable methods for pre- and post- command handling.
B4. The user selects the class to use for pre- or post- command handling.
a) The system shows a list of suitable methods for pre- or post- command handling within the selected class.
B5. The user selects the method.
a) The system updates the code according to the user’s selections.
b) The system updates the flow’s code.
c) The system redraws the flow.

Alternative Flows

Alternative flow 1: The user changes the method to call from code directly
A1. The user changes the method that is called upon pre- or post- command handling.
A2. The user saves the changes.
A3. The user opens the Flow designer.
a) The system shows an information message that the method is no longer available in the pre- or post- command handling function.
Alternative flow 2: The user changes/removes the method name directly from the code
A4. The user changes/removes the method that is called upon pre- or post- command handling.
A5. The user saves the changes.
A6. The user opens the Flow designer.
a) The system shows an information message that the method is no longer available in the pre- or post- command handling function.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The Flow designer is open with a flow diagram present

The Flow designer should be open with an active flow diagram present.

5.2 Precondition 2: The active flow must contain a pre- or post- command handling function

The active flow diagram must contain a pre- or post- command handling function.


POSTCONDITIONS

Postcondition 1: The pre- or post- command handling is modified according to the user’s changes

The pre- or post- command handling is modified according to the user’s actions. The code can be compiled and the undo feature is available.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Delete Operation Triggering

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

This use-case describes how a pre- or post- command can be removed from a command or a menu item to which it is associated.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to delete the pre- or post- command.
B2. The user selects the command/menu that contains the pre- or post- command.
B3. The user selects the delete pre- or post- command and deletes it.
a) The system removes the added method calls from the code.
b) The system updates the flow diagram’s code.
c) The system redraws the flow diagram.

Alternative Flows

Alternative flow 1: The user removes the pre- or post- command from the code directly
A1. The user removes the pre- or post- command from the code directly.
A2. The user saves his changes.
A3. The user opens the Flow Designer.
a) The system updates the flow diagram’s code.
b) The system redraws the flow diagram.
Exception 1: The file is locked by another application
A4. The user tries to delete the pre- or post- command but the file is locked by another application.
a) The system will show an error message explaining that the operation cannot be performed because it is locked by another application. The pre- or post- command is not removed.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The Flow designer is open with a flow diagram present

The Flow designer must be open with a flow diagram present.

5.2 Precondition 2: The active flow diagram must contain a pre- or post- command

The active flow diagram must contain a command or menu item with a pre- or post- command attached to it.


POSTCONDITIONS

Postcondition 1: The pre- or post- command is removed The menu item or command no longer has a pre- or post- command associated with it. The code compiles and undo is available.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Add Alert

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

The user adds an alert/dialog component to the flow.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to add a new alert to the flow.
B2. The user selects an alert component from the component list.
B3. The user adds an alert to the flow designer
a) The system asks for any mandatory properties applicable to the alert (e.g. the name).
B4. The user inputs the mandatory properties.
a) The system adds the new alert to the flow designer.
b) The system creates the code for the alert.
c) The system opens the properties view for the alert/dialog

Alternative Flows

Alternative flow 1: The user inputs an invalid mandatory property for the alert
A1. If the user inputs an invalid mandatory property for the alert, he will be warned of the error and asked to provide the property again. The user can also cancel the addition of the alert.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The flow designer is open and contains an open flow

Components can only be added to the flow in flow designer.


POSTCONDITIONS

Postcondition 1: A new alert component is added to the flow and its code is created

Postcondition 2: The new alert is selected and the property list for it is updated

When a new alert is selected, its property list is updated to the mandatory values the user gave when creating the alert.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Modify Alert

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

The user modifies an existing alert to change, e.g. the text.


FLOW OF EVENTS

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.

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.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

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.


POSTCONDITIONS

Postcondition 1: The code is changed

The code is changed according to the changes made to the property

Postcondition 2: The Flow designer’s UI is updated

The flow designer’s UI is updated according to the changes made.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Delete Alert

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

The user removes an alert/dialog from the flow.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to remove an alert/dialog from the flow.
B2. The user selects an alert/dialog to remove and then removes it.
a) The system removes all of the code associated with the alert/dialog.
i) The possible screen change code from the deleted alert/dialog.
ii) The possible screen change event’s code to the removed alert/dialog from the other components
b) The system removes the alert/dialog connections in flow designer.
c) The system removes the alert/dialog from the flow designer’s design.

Alternative Flows

Alternative flow 1: The user deletes multiple alerts/dialogs
A1. The user selects several alerts/dialogs from an active flow.
A2. The user selects the delete alert/dialog feature.
a) The system removes all of the code associated with the deleted alerts/dialogs.
b) The system removes the alerts/dialogs from the active flow and updates the flow’s code.
c) The system redraws the active flow.
Alternative flow 2: The alert/dialog is deleted using a method other than the Flow designer’s delete feature
A3. The user deletes the alert/dialog using another method than that which is provided by the Flow designer.
A4. The user activates flow flow diagram that contains deleted component
a) The system removes all of the code associated with the deleted alert/dialog.
b) The system removes the screen from the active flow and updates the flow’s code.
c) The system redraws the flow.
Alternative flow 3: The file is locked by another application or editor
A5. The user tries to delete an alert/dialog but the file is locked by another application.
a) The system will show an error message explaining that the alert/dialog cannot be removed because it is locked by another application. Delete is aborted.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The flow designer is open and contains at least one alert/dialog that can be removed

Alerts can only be removed from the flow when the Flow designer is open.


POSTCONDITIONS

Postcondition 1: The alert/dialog is removed from the flow and the flow is updated

Postcondition 2: The screen change related code for the alert is removed


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Install Screen

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

This use-case describes how the user can install a custom screen to the Flow designer.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to install a custom screen.
B2. The user adds the plug-in file to the plug-in’s folder.
B3. The user starts Eclipse.
a) The system updates the installed component to the list of available flow designer components. Installed component can also add new component group.

Alternative Flows

Alternative flow 1: The screen location is corrupt (e.g. jar file is corrupt)
A1. The system will show the user an error message that explains what has happened. The installation is aborted.
Alternative flow 2: The location contains no screen to install
A2. The system ignores the plug-in.
Alternative flow 3: The screen already exists
A3. The system checks if this is an update to an existing screen. If so, the newer version will be used. Otherwise, the plug-in will be ignored.
Alternative flow 4: The Flow designer is open with the wrong UI toolkit
A4. The installed custom screen is not displayed in the list of available Flow designer components.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The user has a custom screen he wants to add

The user must have created a custom screen as an Eclipse plug-in that can be installed to the Flow designer.

5.2 Precondition 2: The Flow designer is open with the same UI toolkit


POSTCONDITIONS

Postcondition 1: The installed screen is available for use

The added screen is visible in the component list and can be added to the flow.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Uninstall Screen

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

This use-case describes how a custom screen can be uninstalled from the Flow designer.

FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to uninstall a container from the Flow designer.
B2. The user deletes the plug-in file from Eclipse.
B3. The user starts Eclipse.
a) The custom screen component is removed from component palette.
b) The custom component group is removed if there aren’t any other components.

Alternative Flows

Alternative flow 1: The user doesn’t delete all of the plug-in files
A1. The user deletes some of the plug-in files.
A2. The user starts Eclipse.
a) The system behaves as if all plug-in files have been deleted.
Alternative flow 2: The removed screen is in use in a flow diagram
A3. The user starts Eclipse after plug-in removal.
A4. The user opens a flow design which uses the removed screen.
a) The system will inform that the flow diagram contains components that are no longer available.
b) The system asks if the components can be removed from the flow diagram.
A5. If user confirms that the components can be removed, the flow diagram is updated according to the basic flow of events in the delete use case. If the components cannot be removed, the flow diagram cannot be opened and the user will be informed about this.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The user has installed a screen that can be uninstalled

5.2 Precondition 2: Eclipse is not running


POSTCONDITIONS

Postcondition 1: The selected screen is uninstalled

The screen is no longer available in the screen list.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Install Alert

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

The user can install a new alert/dialog component.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to install a new alert component.
B2. The user copies the new alert/dialog component’s file(s) into Eclipse’s folder.
B3. The user starts Eclipse.
a) The system updates the installed component to the list of available flow designer components. Installed component can also add new component group.

Alternative flows

Alternative flow 1: Alert/Dialog location is corrupt (e.g. jar file is corrupt)
A1. The system will show the user an error message that explains what has happened. The installation is aborted.
Alternative flow 2: The location contains no alert/dialog to install
A2. The system ignores the plug-in.
Alternative flow 3: The Alert/Dialog already exists
A3. The system checks if this is an update to an existing alert/dialog. If so, the newer version will be being used. Otherwise, the plug-in will be ignored.
Alternative flow 4: The Flow designer is open with the wrong UI toolkit
A4. The installed custom alert/dialog is not displayed in the list of available Flow designer components.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The user has the Alert/Dialog he wants to install as a plug-in


POSTCONDITIONS

Postcondition 1: The new Alert/Dialog component is available in the system


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Uninstall Alert

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

The user can uninstall the alert/dialog component from the system.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to uninstall an alert component from the system.
B2. The user removes the alert component files from the system’s folder.

Alternative Flows

Alternative flow 1: The user doesn’t delete all of the plug-in files.
A1. The user deletes some of the plug-in files.
A2. The user starts Eclipse.
a) The system behaves as if all plug-in files have been deleted.
Alternative flow 2: The uninstalled alert/dialog is in use within a flow diagram
A3. The user starts Eclipse after the plug-in has been removed.
A4. The user opens a flow design which uses the removed alert/dialog.
a) The system will inform that the flow diagram contains components that are no longer available.
b) The system will ask if the components can be removed from the flow diagram.
A5. If user confirms that the components can be removed, the flow diagram is updated according to the basic flow of events in the delete use case. If the components cannot be removed, the flow diagram cannot be opened and the user will be informed about this.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: Eclipse is not running

Components cannot be removed while the system is running.

5.2 Precondition 2: The user has installed an alert that can be uninstalled


POSTCONDITIONS

Postcondition 1: The alert/dialog component is not available in the system


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Install UI Toolkit

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

The user can install a new UI Toolkit.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to install a new UI Toolkit.
B2. The user copies the new UI Toolkit’s file(s) (Eclipse plug-in) to Eclipse’s folders.
B3. The user starts Eclipse.
a) The new UI toolkit adds components and containers for the designer component palette.
b) The new UI toolkit adds its own containers for the visual class wizard.
c) If the UI toolkit contains a new component category, the system shows this group in the designer component palette.
d) The New Flow –wizard has the new UI Toolkit as a selectable choice.

Alternative flows


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The user has a UI toolkit (Eclipse plug-in) he wants to install


POSTCONDITIONS

Postcondition 1: The new UI Toolkit is available in the system


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Uninstall UI Toolkit

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


BRIEF DESCRIPTION

The user can uninstall the UI Toolkit from the system.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to uninstall a UI Toolkit from the system.
B2. The user removes the UI Toolkit’s (Eclipse plug-in) files from Eclipse’s folders.
B3. The user starts Eclipse.

Alternative Flows

Alternative Flow 1: The removed UI toolkit is in use in a flow diagram
A1. The User opens a flow which uses the removed UI toolkit.
a) The system will inform that the design contains components that are no longer available and the flow cannot be displayed.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The system is not running

Components cannot be removed when the system is running.


POSTCONDITIONS

Postcondition 1: The UI Toolkit is not available in the system


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:

Back to the top