Pages 1 - 2 - 3 - 4

5. Functional Requirements

For all of the following functions, these assumptions have been made:

5.1 CRUD Project


5.1.1 Create New Project

Creates new Project on disk which has the ability to contain many Models. Project can have local or distributed Models.
 
Abbreviation: CREATEPROJECT
Pre-Condition(s): Project with the same name doesn't already exist.
Post-Condition(s): New Project created on disk.
Business Rules: Project name is limited to a maximum of 255 characters.
Input(s): Name - name of Project.
Path - home directory where Project will be stored locally.
Output(s): Created Project added under current workspace "Project tree".
Created Project rejected.
Processing: The Project file is created and saved on the disk in the specified location. A file browser dialog allows the user to specify where it is going to go.
Control/UI/Reports: The file browser dialog allows the user to specify the location to save the file. If file is unable to be created, client is notified through a response message.
Quality Aspects: Under no circumstances should an existing file be over-written without the consent of the user.
Performance: All interaction with the system is local and so should be relatively instantaneous as far as the user is concerned.
Testing Requirements: Must ensure Project can't be created if already exists.
Delete Project while in use.
Exceptions: Type: FileException
Causes:
  • File permissions are not set to the required state (ie. Can't create a file). 
  • There is not enough room to save the file.
Handling Performed: An appropriate dialog will be displayed indicating what has gone wrong.
Type: ProjectExists
Causes: Project already exists in the location specified.
Handling Performed: The Project is not created and the user is notified via a dialog indicating what the problem is and given the option of over-writing the existing file or cancelling.

5.1.1.1 Edit Properties of Project

Alter properties specific to the current active Project.
 
Abbreviation: EDITPROP
Pre-Condition(s): Project whose properties are to be changed is active.
Post-Condition(s): Properties of active Project are changed.
Business Rules: No business rules apply.
Input(s): Project to update.
Output(s): Updated Project.
Processing: Takes the Project to update and displays its properties in a graphical form through which the user may edit them. On confirmation from the user, it takes the updated properties, sets them in the Project itself and returns.
Control/UI/Reports: Dialog containing all required data is presented to user. Any problems or information will be displayed in a dialog.
Quality Aspects: All properties are reflected in all copies of the Project and are persistant.
Performance: All interaction with the system are local and so the delay experiened by the user should be almost zero.
Testing Requirements: Changes are reflected in the running of functional operations concerned with the Project.
Exceptions: Type: FileException
Causes:
  • File permissions are not set to the required state (ie. Can't create a file). 
  • There is not enough room to save the file.
Handling Performed:
  • An appropriate dialog will be displayed indicating what has gone wrong.


5.1.2 Add Model to Project

Add an existing Model into the active Project.
 
Abbreviation: ADDMODEL
Pre-Condition(s): Project exists and is active.
Model exists or has been created.
Model doesn't exist within active Project.
Post-Condition(s): Project containing additional Model.
Business Rules: No business rules apply.
Input(s): File Name - The file path and name of Model.
Output(s): Model inserted under active Project "Model tree".
Processing: Once Model name has been entered, client should check for existence of Model on hard disk and in Project.  If either not found on disk or found in Project, addition of Model should be aborted and user notified and given choice of aborting operation or changing name of Model.
Control/UI/Reports: The File browser to select the file will use the  standard Swing File Browser. Dialogs should appear informing user if Model not found or Model already exist within Project.
Quality Aspects: The file browser needs to be standard and its use and functions implicit.
Performance: The stress on the system will be low given that it simply provides a reference to the file. The time taken to perform this operation should be instantaneous as far as the user is concerned on the target system.
Testing Requirements: Testing should be done for adding non-existent Models to Projects, trying to insert existing Models and check for proper response when names of Models have been changed through other programs.
Exceptions: Type: FileException
Causes:
  • File has been renamed, moved or deleted and system tries to access it. 
  • File permissions are not set to the required state. 
Handling Performed:
  • An appropriate dialog will be displayed indicating what has gone wrong. 
Type: ModelExists
Causes:
  • Model has already been added to the Project. 
Handling Performed:
  • The Model is not added a second time but the interface treats it as if it were just added. 


5.1.3 Open Project

Load a Project from local disk into a workspace
 
Abbreviation: OPENPRJ 
Pre-Condition(s): There is a checked out to the local drive Project or a local Project available. 
Post-Condition(s): The Model in the Project are added to the selected workspace tree, under the appropriate Project.
Business Rules: No business rules apply.
Input(s): The name of the Project to open.
The directory that the Project is in.
Output(s): The Project contents is added to the workspace.
The screen is updated to show the new workspace contents.
Processing: The Project is opened and the list of Models is loaded. The Models are added under the Project in the workspace tree.
If there is no open workspace then a new one is created, the Project added, and then the contents of the Project.
Control/UI/Reports: The Project is accessed through the workspace tree. 
If the user does not have an open workspace, they can select open Project from the Project menu.
Quality Aspects: The GUI should still respond while the Projects is being loaded.
Performance: On an idle computer, this should take less than 10 seconds. This is however dependent on the size of the Project being loaded. 
Testing Requirements: If there is a large number of items in the Project, then the process could use an excess amount of memory and take a long time.
Exceptions: If the file is corrupt then the open is aborted and the system state remains un-changed. 
Type: IOException
Causes:
  • The file is corrupt. 
  • The user does not have read access to the file. 
Handling Performed:
  • The user is notified of the problem. 
  • The load is aborted. 
  • The user is given the option to remove the Project from the workspace .

5.2 CRUD Workspace


5.2.1 Create new workspace

Creates a new workspace which may contain many Projects.
 
Abbreviation: NEWWORKSPACE
Pre-Condition(s): Workspace doesn't exist in specified path.
Post-Condition(s): New workspace file exists in specified path.
Business Rules: Workspace name limited to a maximum of 255 characters in length.
Input(s): Name - Name of workspace.
Path - Path for workspace location.
Output(s): Created workspace file saved in specified path.
Newly created workspace opened, with empty Project tree.
Processing: The program will search locally for existing workspaces with desired name in the specified path.  If filename is found to be unique, workspace is created.
Control/UI/Reports: All required input is done through a dialog.
If workspace cannot be created, user is informed.
Quality Aspects: Usability: path is selected by use of a GUI, reducing possible user errors.
Performance: On an idle computer this should take less than 10 seconds.  This should only cause low stress on system resources.
Testing Requirements: Create workspaces which already exist.
Delete workspace while in use.
Exceptions: If workspace already exists the user asked to select another filename.
Type: IOException
Causes:
  • If workspace already exists on disk. 
  • If not enough disk space. 
Handling Performed:
  • Messages dispatched: "Filename already in use", "Insufficient space on drive". 


5.2.2 Add Project to Workspace

Add current Project to an existing workspace.
 
Abbreviation: CREATEPROJ 
PreCondition(s): Project exists.
Workspace exists.
Workspace is open. 
Post-Condition(s)): Workspace file contains reference to an additional Project.  Workspace window has an additional Project displayed.
Business Rules: No business rules apply.
Input(s): Name - Name of desired Project.
Path - Location of desired Project. 
Output(s): Project inserted into Workspace file's Project tree. 
Processing: Once Project has been selected, existence of Project is confirmed. The current workspace file is updated to include details of additional Project. 
Control/UI/Reports: If insertion fails, dialog will appear notifying the user. 
Quality Aspects: Usability: The Project file is selected via dialog decreasing the chance of error by the user and the the need for users to recall filenames.
Performance: on an idle computer this action should take less than 10 seconds.  This action should only cause low stress on system performance.
Testing Requirements: Once inserted, tests to ensure data saved in workspace file are correct. 
Exceptions: Type: IOException
Causes:
  • If Project file is not found. 
Handling Performed:
  • user is asked to select another file 

5.3 CRUD Model
 

5.3.1 Create New Model

Create new Model file.
 
Abbreviation: CREATEMODEL
Pre-Condition(s): Sufficient memory.
Model doesn't exist in Project and or saving location on local machine.
Post-Condition(s): Blank canvas appears in GUI on client system, ready for user input.
Model added to current active Project.
Business Rules: Model name is limited to a maximum of 255 characters in length.
Input(s): Name - Name of Model.
Path - Location to create Model file. 
Project - Project that the Model is to be added to. 
Meta-Model - Meta-Model for this Model to be based on. 
Package - Package used to represent meta-Model.
Output(s): Branch is created for Model under active Project tree.
File is created in specified directory path on local machine.
Blank canvas is generated and displayed.
Processing: When "Open" dialog appears a scan is executed looking for all possible Model types.
Name of Model, directory for storage and Project are received from user input. Duplicate
of Model name within Project is checked, if succeeds, Model is added to Project and file is
created on disk.
Control/UI/Reports: Either "New" selected by user through menu options or speed button pressed by user. 
Control is given to the "New Model" dialog which containing types of Models to select from, 
inputs for file name and path are provided with check box to add to current active Project. 
Dialogs appear requesting selection of meta-Model and associated package to be used. 
"OK" selected returning focus to the newly created canvas.
Quality Aspects: If and when new types of Models are created, this will be reflected in the types of Models  selectable when creating a new Model.
Performance: This should take less than half a second and very little system resources are used.
Testing Requirements: Testing should concentrate on the correct creation of the Model file and the addition to the  appropriate Project.  Test case could include trying to create a Model and add to Project  with existing Model with same name.  Another includes creating a new file and checking file  location for existence of file.
Exceptions: Type: ModelExistsInProjException
Causes:
  • Model assigned same name exists under current active Project 
Handling Performed:
  • User notified by error dialog. Insertion of project is aborted, and control is returned to the desktop. 
Type: FileIOException
Causes:
  • File already exists in location 
  • Not enough memory 
Handling Performed:
  • User is notified of problem via some means. 
  • Creation of file is aborted. 
  • Focus is returned to "open" dialog. 

5.3.1.1 Edit Model

5.3.1.1.1 Select a tool from the palette

Selects the current tool for drawing from a palette that contains all drawable components from the Model's meta-Model.
This component can then be added to a particular Model.
 
Abbreviation: SELECTTOOL 
Pre-Condition(s): A Model must be opened in a viewport that has the focus. (i.e. the current Model).
The components from the current Model's meta-Model, have all been added to the tool palette.
The user has write access to the current Model.
Post-Condition(s): The selected tool will be the next item placed on the Model, until a different one is chosen, or the tool is unselected.
Business Rules: No business rules apply.
Input(s): The user is required to select the tool by clicking on it with the mouse. Certain tools may also be given hot-keys, and they can also be selected with the hot-keys.
Output(s): The button appears as depressed, and the previously selected button is raised.
Processing: Accept a selection from the user.
Unselect any previously selected tool.
Store this selection, so that we know what one to draw when the user wants to place something on the Model. 
Control/UI/Reports: A tool palette needs to be provided to the user. This will contain a set of toggle buttons that can be toggled on or off by selecting them. Only one of these buttons can be toggled on at a given time. Selecting one will automatically unselect the previously selected button.
Quality Aspects: Usability: no issues.
Portability . The tool bar and all buttons will use swing, so it will be portable to any platform that fully supports swing applications.
Performance: Under normal load conditions, this function should perform in under 1 second. It will not take up any excessive system resources.
Testing Requirements: Testers should make sure that when a tool is selected, that is the one that is placed on the Model. Testers should make sure that previously selected tools get unselected etc. They should also test usability, to make sure that it behaves as expected, when selecting/unselecting tools etc.
Exceptions: Not yet determined.

5.3.1.1.2 Place node on Model

Places a node on a Model. A node contains information such as the meta-node that it represents, and it's coordinates in Model space.
 
Abbreviation: ADDNODE 
Pre-Condition(s): A Model is opened, and it's viewport has the focus (this Model is the current Model).
SELECTTOOL has occurred, and the tool selected is a meta-node from the current Model's meta-Model. 
The meta-node's type belongs to the meta-Model of the Model.
The user has write access to the current Model.
Post-Condition(s): A new instance of the meta-node is added to the Model's internal data structure. This will be evident when the Model is rendered (as the new node will be visible) and also when the Model is saved (as the node will be added to the file). The Model is also marked as . edited. .
Business Rules: No business rules apply.
Input(s): The Model that currently has the input focus.
The meta-node type to add (got from the currently selected tool from the tool-palette.
The position in viewport space to place the node.
Output(s): The updated Model. 
Processing: Accepts from the user input about which meta-node type to add (this is chosen by the user when they select a tool from the tool palette), and it's position in viewport space. A new instance of the meta-node is created and added to the Model's data structure. The viewport position is then back-transformed to Model space, and this is the value stored with the new node. 
Control/UI/Reports: User should be able to place the node by selecting the type of node from the tool palette, and then clicking on the viewport that is displaying the Model. The currently selected item should still remain, even if the focus changes to another Model.
Quality Aspects: Usability . The user can only place new nodes on . empty. parts of the Model. i.e they can't place a node on top of another node.
Performance: Under normal load conditions, this function should be performed in under 1 second. It will take up some system resources, but this will only start becoming evident as more and more nodes are added to a Model.
Testing Requirements: Testers need to make sure that they can only add nodes to a Model if the node's type exists in the Model's meta-Model.
They also need to make sure that the node added is the one currently selected by the tool-palette.
Exceptions: Type: InvalidMetaNode
Causes: The meta-node type that the user wants to add doesn't exist in the current Model. s meta-Model.
Handling Performed: The node isn't added, and the user is issued with a warning. If this exception occurs, it could indicate a bug in the selection logic, so an appropriate debug message should be added to the log.
Type: ReadAccessOnly
Causes: User doesn't have write permission to the current Model.
Handling Performed: The functional area isn't performed on the Model, and the user is notified with a message saying that they don't have write access to the Model.

5.3.1.1.3 Connect nodes with an arc

Connects two nodes on the Model with an arc.
 
Abbreviation: CONNECTNODES 
Pre-Condition(s): The Model is opened in a viewport, that has the current focus.
The user has write access to the Model.
The Model has at least two nodes to join.
The meta-arc type has been selected from the tool palette.
The meta-arc allows the two nodes to be connected.
Post-Condition(s): An arc is added to the Model, connecting the two nodes. 
The Model is marked as being edited.
Business Rules: No business rules apply.
Input(s): The current Model.
The meta-arc type. (retrived from the tool-palette)
The start node. (selected by the user )
The end node. (selected by the user )
Output(s): The updated Model. 
Processing: Accepts from the user the start and end nodes to connect the arcs.
Evaluate any rules belonging to the arc.
If any of the rules fail, then notify the user as specified by the notification preferences.
Control/UI/Reports: User should be able to select an arc from the tool palette, and then click on the start and then drag the arc to the end node - thus connecting them. If the drag is stopped and the cursor isn't over a node, then the operation is aborted.
Quality Aspects: Usability: After the start node has been selected, the arc should be temporarily drawn from the start node to the current mouse cursor, to give the user an indication of what the arc will look like.
Performance: This function should perform interactively under normal load conditions. It will require some system resources (for storing the new arc, and also when the arc gets rendered) but this will only be noticeable when more and more arcs get added.
Testing Requirements: Testers should make sure that if any of the arc rules fail, that the correct notification is issued to the user. 
They should also make sure that the arc can only be added if the arc's corresponding meta-arc exists in the Model's meta-Model.
Exceptions: Type: InvalidMetaArc
Causes: The meta-arc type that the user wants to add doesn't exist in the current Model. s meta-Model.
Handling Performed: The arc isn't added, and the user is issued with a warning. If this exception occurs, it could indicate a bug in the selection logic, so an appropriate debug message should be added to the log.
Type: MetaRuleFailed
Causes: A meta-rule associated with the arc, failed - this failure is rule dependant.
Handling Performed: This is dependant on the user. s preferences, but one of 3 things could occur:
  • The function is aborted, and the user is notified.  
  • The function succeeds, but the new node is drawn in a separate . error. colour indicating that a rule has been violated.  
  • The function succeeds, and the rule is ignored. 
Type: ReadAccessOnly
Causes: User doesn't have write permission to the current Model.
Handling Performed: The functional area isn't performed on the Model, and the user is notified with a message saying that they don't have write access to the Model.

5.3.1.1.4 Select selectable item

Adds any part of the Model that is defined to be 'selectable' to the list of currently selected items. This includes nodes, arcs, and various other things. There are two types of selection, exclusive select . which deselects any previously selected items, and additive select which just adds it to the list of selected items.
 
Abbreviation: SELECT 
Pre-Condition(s): The user is editing a Model.
There are selectable items on the Model. 
Post-Condition(s): A selectable item has been added to the list of currently selected items. 
The common properties of the selected items are displayed in a . properties. window.
Business Rules: No business rules apply.
Input(s): The current Model. 
The item that was selected.
The current selection list.
Output(s): The updated current selection list. 
The common properties list of the selection is also updated.
Processing: Adds the selectable item to the list of currently selected items. If the user wants an exclusive select then all other currently selected items are deselected. The other type of select is an additive select, where the other items aren't deselected. The function VIEWCOMMONSELECT is also performed.
Control/UI/Reports: Should behave like standard selection. Clicking on an item with the mouse should deselect all other items, and then select the item under the mouse. Holding down shift/ctrl/some hotkey, adds the item to the list of currently selected items, without deselecting the other items. Selected items are drawn with dot points around the edges, to show that they have been selected. Each Model will maintain it's own list of currently selected items.
Quality Aspects: Usability: no issues.
Performance: Under normal load conditions, this function will perform in under 1 second. It takes up minimal system resources both for storing the selected state of the item, and for rendering the item as selected.
Testing Requirements: Testers should make sure that all functions that perform some operation on the list of currently selected items, work correctly with the newly selected item, and no longer work with any deselected items. 
Exceptions: Type: ItemNotSelectable
Causes: The user tries to select an item that cannot be selected.
Handling Performed: Nothing is selected, and no feedback is given to the user . this is how it happens in other applications, as the user will realise that the item wasn't selected when it isn't drawn with an outline.

5.3.1.1.5 Deselect selectable item

Removes from the list of currently selected items any part of the Model that is defined to be 'selectable'. This includes nodes, arcs, and various other things.
 
Abbreviation: DESELECT 
Pre-Condition(s): There is at least one item in the current selection.
The item being deselected is in the current selection. 
The user is editing a Model.
Post-Condition(s): The item is no longer in the current selection. 
The common properties window is also updated with the new common properties of the selection.
Business Rules: No business rules apply.
Input(s): The item to deselect.
The list of currently selected items. 
Output(s): The updated list of currently selected items. 
The common properties window is updated.
Processing: Find the item in the list.
Removes the item from the list.
Perform the VIEWCOMMONSELECT function on the selection.
Control/UI/Reports: Should behave like standard selection (see SELECT). 
Quality Aspects: Usability: no issues.
Performance: Under normal load conditions, this function will perform in under 1 second. It will free up a small amount of system resources.
Testing Requirements: Testers should make sure that the deselected item no longer responds to any functions that operate on the list of currently selected items.
Exceptions: Not yet determined.

5.3.1.1.6 Move selection

Moves all of a Model's currently selected items around in Model space. This can be used to move individual nodes, to re-route the elbows/joins on arcs to better positions etc.
 
Abbreviation: MOVESELECT 
Pre-Condition(s): The user is editing a Model.
The user has write access to the Model.
The Model's current selection has at least one item.
The items in the current selection are moveable. 
Post-Condition(s): The Model space coordinates of all items in the selection have been updated. 
The Model is marked as having been . edited. .
Business Rules: No business rules apply.
Input(s): The Model.
The current selection.
The amount and direction to move each item in the selection (represented by an x,y pair). This will typically be generated by moving the mouse, but may also be done using hot-keys.
Output(s): The Model.
The current selection.
Processing: For all items in the current selection:  Update their Model space coords to the new position, determined by the x,y pair given as input.
Control/UI/Reports: User should be able to perform this function by clicking on any item in the selection, and dragging it around the viewport. 
Quality Aspects: Usability: no issues.
Performance: This function should be able to perform interactively, with performance degrading gracefully as the Model has more and more nodes and arcs, and also as the number of selected items increases. 
Testing Requirements: Testers should make sure that all items in the selection (and no others) move by the correct amount, and in the correct direction. 
Exceptions: Type: ItemNotMovable:
Causes: An item in the selection isn't allowed to be moved.
Handling Performed: Based on user preferences, one of two things can happen: 
  • No items in the selection get moved.  
  • All items are moved except the ones that aren't allowed to be moved. 
Type: ReadAccessOnly
Causes: User doesn't have write permission to the current Model.
Handling Performed: The functional area isn't performed on the Model, and the user is notified with a message saying that they don't have write access to the Model.

5.3.1.1.7 Group selection

Creates a group from the current selection'this group is now treated as a single item.
 
Abbreviation: GRPSELECT 
Pre-Condition(s): The user is editing a Model.
There are at least two items in the Model's current selection.
All items in the current selection are groupable. 
Post-Condition(s): All items in the current selection now belong to the one group, and are treated as a single item.
Business Rules: No business rules apply.
Input(s): The Model being edited ( this is the Model with the current input focus).
The current selection. (got from the Model).
Output(s): A new group. 
Processing: A new group item is created.
All items in the current selection are added to the new group item.
SELECT is performed on the group item. 
Control/UI/Reports: User should select the . group. command from either a menu, a toolbar, or a hot-key. All selected items in the current Model then become the one item, and any commands applied to the group item also get applied to all the items in the group.
Quality Aspects: Usability: no issues.
Performance: Under normal load conditions, this function will perform in under 1 second. It will require a small amount of extra resources for maintaining the group data structure.
Testing Requirements: Testers should make sure that all selected items (and only the selected items)have been added to the group, and that they are now all treated as one item. 
Exceptions: Type: ItemNotGroupable
Causes: An item in the current selection isn't allowed to be grouped.
Handling Performed: None of the items are grouped, the user isn't given any extra notification'this is standard behaviour as the user will see that the grouping hasn't occurred.
Type: NotEnoughItemsToGroup
Causes: There is only one item in the Model. s current selection.
Handling Performed: The item isn't placed into a group and is just left as is. The user doesn't have to be notified about this.

5.3.1.1.8 Ungroup selection

Ungroups any groups that are part of the current selection. (i.e. splits them back up into their individual parts.
 
Abbreviation: UNGRPSELECT 
Pre-Condition(s): The user is editing a Model.
There are items of the Model that are selected.
There are group items in this selection.
Post-Condition(s): Any group items are now ungrouped. 
Business Rules: No business rules apply.
Input(s): The current selection. 
Output(s): The current selection. 
Processing: For all items in the current selection, if the item is a group item:Split it up into it's individual items, and add them performs an additive SELECT on each item.
Note:  This function does not work recursively-- If there are groups inside groups, then the nested groups are not ungrouped. 
Control/UI/Reports: The user performs this function, by selecting the items they want to ungroup, and then selecting the 'ungroup' command from a menu, toolbar or hot-key.
Quality Aspects: Usability: no issues
Performance: Under normal load conditions, this function will perform in under 1 second. It will free up a small amount of system resources because memory will not be needed for the group data structure.
Testing Requirements: Testers should make sure that all grouped items in the selection are now ungrouped, and that the items that made up the group are now part of the current selection'they should also make sure that the ungroup didn't work recursively.
Exceptions: Type: NotGroupItem
Causes: An item in the selection is not a group item.
Handling Performed: This item is ignored. The user doesn't have to be notified. 

5.3.1.1.9 Bring selection to front

Gives all currently selected items of the current Model a higher priority, so they appear in front of any other item (both from a rendering, and a hit-testing point of view).
 
Abbreviation: BRINGSELECT 
Pre-Condition(s): The user is editing a Model.
There is at least one item in the Model. s current selection. 
Post-Condition(s): All items in the current selection now appear above ones that aren't in the selection, both for rendering, and hit-testing.
Business Rules: No business rules apply.
Input(s): The Model that is being edited.
The Model's current selection.
Output(s): The updated Model. When rendered, this updated Model should now display the selected items in front of any others. If there are overlapping elements on the Model, then the ones that have the front priority will be clicked on instead of the others.
Processing: For all items in the Model:
If the item is part of the current selection, set its priority to front;
Otherwise set its priority to back. 
Control/UI/Reports: The user performs this function, by selecting the items they want to bring to the front, and then selecting the 'bring to front' command from a menu, toolbar or hot-key.
Quality Aspects: Usability: no issues.
Performance: Under normal load conditions, this function should perform in under 1 second. It won't take up any extra system resources.
Testing Requirements: Testers need to make sure that all items in the selection are now drawn above other items in the Model, and also that they are selected instead of items that are below them if there is any overlap. 
Exceptions: Not yet determined.

5.3.1.1.10 Send selection to back

Gives all currently selected items a lower priority, so they appear behind all other items in the Model both for rendering and hit-testing.
 
Abbreviation: SENDSELECT 
Pre-Condition(s): The user is editing a Model.
There is at least one item in the Model. s current selection.
Post-Condition(s): All items in the current selection appear behind any others in the Model, both for rendering and hit-testing.
Business Rules: No business rules apply.
Input(s): The Model being edited.
The current selection of the Model.
Output(s): The updated Model. When this updated Model is rendered, then all selected items will be drawn behind the other elements in the Model.
Processing: For all items in the Model:
If the item is part of the current selection, set it's priority to back;
Otherwise, set it's priority to front. 
Control/UI/Reports: The user performs this function, by selecting the items they want to send to the back, and then selecting the 'send to back' command from a menu, toolbar or hot-key.
Quality Aspects: Usability: no issues.
Performance: Under normal load conditions, this function should perform in less than 1 second. It won't take up any extra system resources.
Testing Requirements: Testers need to make sure that all items in the selection are now drawn below other items in the Model, and also that they aren't selected if there are items above them that are overlapping.
Exceptions: Not yet determined.

5.3.1.1.11 Delete selected items

Removes from a Model all items in that Model's current selection.
 
Abbreviation: DELSELECT 
Pre-Condition(s): The user is editing a Model.
There is at least one item in the Model. s current selection. 
All items in the selection can be deleted.
Post-Condition(s): The previously selected items have been removed from the Model. 
The Model is marked as having been . edited. .
Business Rules: No business rules apply.
Input(s): The current Model.
The Model's current selection. 
Output(s): The updated Model. When rendered, this Model will no longer display the removed elements. They are also no longer stored in the Model's data structure. This change isn't represented on disk until the updated Model is saved.
Processing: If all items in the selection can be deleted from the Model then for all items:
If the user wants to confirm the delete get user confirmation of delete.
Otherwise delete the item.
Otherwise, abort the deletion. 
Control/UI/Reports: User should just be able to select the items they want to delete, and then activate the delete command from either a menu, toolbar, or hot-key. There should be a preference that the user can specify to always confirm deletes, or to always delete the items without confirmation.
Quality Aspects: Usability: the user preferences allows the user to always delete the selection, or to confirm deletion for each item.
Performance: Under normal load conditions, this function should perform in less than 5 seconds. The performance of this function should degrade gracefully as the number of selected items increases. It should release any system resources associated with storing the deleted items.
Testing Requirements: Testers should make sure that the items in the selection are correctly deleted based on the user. s preferences. They should also make sure that none of the items are deleted if there are any items in the selection that can't be deleted.
Exceptions: Type: CannotDeleteSelection
Causes: There is an item in the Model's current selection that cannot be deleted.
Handling Performed: None of the items in the selection are deleted. The user is notified with an appropriate message that the deletion couldn't take place. 

5.3.1.1.12 Evaluate rule

Evaluates a rule from a meta-Model.
 
Abbreviation: EVALRULE 
Pre-Condition(s): The user has just performed a task that requires a rule to be evaluated. i.e. they have just connected two nodes with an arc, and need to know if this is valid. 
Post-Condition(s): The rule is evaluated, and the user notified in an appropriate manner (as defined by the notification preferences of the user ). 
Business Rules: No business rules apply.
Input(s): The current Model.
The meta-Model of the Model
The meta-rule to evaluate. 
Output(s): Success or Failure of the evaluation. Success indicates that the task performed is valid. Failure indicates that it is invalid.
Processing: Check that the meta-rule's constraints and relationships match the current state of the Model. i.e if the user has added a new arc, make sure that the two end nodes are allowed to be joined with this arc.
If the constraints and relationships do match the current state of the Model, then the rule succeeds, otherwise it fails. 
Control/UI/Reports: Evaluation of rules is performed only when an event that requires evaluation occurs. Such events include . adding a new node to a Model, adding an arc to a Model etc. They can also be triggered from a menu, toolbar or hotkey, if the user requires it.
Quality Aspects: Usability: The user is given preferences to decide what will happen when a rule fails. They will also be able to force evaluation of a rule, or set of rules.
Performance: This function should perform in under 5 seconds, with performance degrading gracefully as the number of rules needed to be evaluated increases. It will take up minimal system resources.
Testing Requirements: Testers should make sure that the rules are evaluated correctly as defined by the meta-Model, and that the correct response is given for incorrect and correct rules. They should also make sure that rules are evaluated at the correct times.
Exceptions: Not yet determined.

5.3.1.1.13 Align selected items

Aligns all selected items of a Model, to a user specified boundary ( left, right, up, down, to grid etc.).
 
Abbreviation: ALIGNSELECT 
Pre-Condition(s): User is editing a Model.
There are at least two items in the Model's current selection. 
Post-Condition(s): All selected items are now aligned along the specified boundary. 
This is done by changing the Model-space coordinates of the items.
Business Rules: No business rules apply.
Input(s): The Model being edited.
The current selection of the Model.
The boundary to align against. 
Output(s): The updated Model. The selected items now have their appropriate coordinates aligned along the boundary (i.e the x coords are aligned along a given x boundary).
Processing: For all items in the current selection:
Change the Model-space coordinates of each item, so that they are aligned along the specified boundary. 
Control/UI/Reports: When editing a Model, the user should select each item that they want to align, and then choose the . align. command from a menu, toolbar, or hot-key.
Quality Aspects: Usability: The user will be provided with default boundaries, such as left, right, top, bottom, that align all selected items to the boundary.
Performance: Under normal load conditions, this function should perform in under 2 seconds. The performance will degrade gracefully as the number of selected items increases. It will take up minimal system resources.
Testing Requirements: Testers should make sure that all selected items are aligned along the correct boundary, and only the items that were selected are moved.
Exceptions: Type: NotEnoughNodes
Causes: There are less than 2 items in the Model's current selection.
Handling Performed: No aligning needs to be done if there is only 1 item. The user doesn't need to be notified about this.

5.3.1.1.14 View selection common properties

Displays any common properties that the selected items have. Optionally allows the user to specify an item type, such as 'node' which will then only display all common properties of the 'nodes' in the selection. (other types may include arc, all, notes, arc joints, etc ).
 
Abbreviation: VIEWCOMMONSELECT 
Pre-Condition(s): User is editing a Model.
There is at least one item in the Model. s current selection. 
There is at least one common property among the selected items. 
Post-Condition(s): The common properties for the selected items are displayed on the screen. 
Business Rules: No business rules apply.
Input(s): The current Model.
The Model's current selection.
The item type to match against (node, arc etc).
Output(s): The common properties of the items in the Model's selection.
Processing: For all items in the Model's selection:
If the item is of the same type as the specified item type.
If the item has a common property with all other item types in the selection, then 
display the common property. 
Control/UI/Reports: The user selects all items of a Model that they want to see the common properties of. These properties should automatically get displayed in a . properties. window.
Quality Aspects: Usability: The common properties of any selected items should always be displayed in the . properties window. regardless of what the user wants to do with the selection.
Under normal load conditions, this function should perform interactively . i.e. when the user selects the item, the common properties get displayed straight away in the properties window. The performance of this function will degrade gracefully as the number of items in the selection increases.
Testing Requirements: Testers should make sure that all properties that are common are displayed, and all that aren't common are not displayed.
Exceptions: Type: NoCommonProperties
Causes: There are no properties that are common to the selected items.
Handling Performed: Nothing gets displayed in the properties window. The user doesn't need to be informed about this, as they will see that there are no common properties.
Type: NoItemsInSelection
Causes: There are no items in the Model's current selection.
Handling Performed: The properties window get. s cleared. The user doesn't need to be notified about this, as they should expect the properties window to be empty if there are no items selected.

5.3.1.1.15 Change selection common properties

Changes any of the common properties that the current selection has. Optionally allows the user to specify an item type, such as 'node' which will then only change all common properties of the 'nodes' in the selection. (other types may include arc, all, notes, arc joints, etc ).
 
Abbreviation: CHNGCOMMONSELECT 
Pre-Condition(s): User is editing a Model.
The user has write access to the Model.
There is at least one item in the Model. s current selection. 
There is at least one common property among the selected items. 
Post-Condition(s): The common properties have been changed. 
Business Rules: No business rules apply.
Input(s): The Model to edit.
The current selection of the Model.
The common property of the selected items that is to be changed.
The new value of the common property. 
Output(s): The updated selected items. 
The view of the common properties is also updated.
Processing: For all items in the selection:
If the item is of the same item type as the one specified,
If the item has a common property, then change it to the new value. 
Perform the VIEWCOMMONSELECT to update the view of the common properties.
Control/UI/Reports: The user should select all items that have the common property that they want to change. The user should be able to select that common property from the 'properties' window, and then enter a new value for the property. All items then get this new property. This can be performed so long as there are common properties displayed in the . properties. window. 
Quality Aspects: Usability: no issues.
Performance: Under normal load conditions, this function should perform in under 5 seconds. The performance will degrade as the number of items in the selection increases.
Testing Requirements: Testers should make sure that all items that have the common property now have the new value. This can be done by individually selecting each item and making sure it has been changed. 
Exceptions: Type: ReadAccessOnly
Causes: User doesn't have write permission to the current Model.
Handling Performed: The functional area isn't performed on the Model, and the user is notified with a message saying that they don't have write access to the Model.

5.3.1.1.16 Graphical resolution of Conflicts

Provides a gui that allows a user to decide on how to resolve any conflicts in a given Model.
 
Abbreviation: GRPHRESOLVE 
Pre-Condition(s): The user is trying to check-in a Model they have been working on.
There are unresolvable conflicts when the user tries to check-in a Model. 
Post-Condition(s): The conflicts are resolved, in which case the Model is now able to be checked in, or the user has aborted the check-in. 
Business Rules: No business rules apply.
Input(s): The Model from the repository.
The Model that user is trying to check-in.
A list of all conflicts in the Model.
Output(s): The user is given a number of views of the Model:
  • The view of the Model in the repository. 
  • The view of their edited Model. 
  • A view of what the Model looks like with the conflicts resolved. 
Processing: User is shown graphically where conflicts are in the Model (perhaps by using colours etc). The user must then decide how to resolve the Model, by allowing changes to occur, or by deleting changes etc. 
Control/UI/Reports: The user is shown three Models. Their version, the version in the repository, and what the new resolved version currently looks like. They will need to have some sort of visualisation of what has been changed in the repository's version since they checked it out, and also the changes that they have made. The user can then select which changes are going to be in the final version. When all conflicts are resolved, then the user is allowed to check the Model in to the repository.
Quality Aspects: Usability: the user is given the three views of the Model with any relevant changes shown'this will allow them to better decide on how to resolve them. 
Performance: This function should perform interactively, and degrade gracefully as the size of the Model increases, and as the number of conflicts increase.
Note: 
This is only the graphical resolution of conflicts. Calculating if a conflict has occurred is another function. 
Testing Requirements: Testers should make sure that resolved Model is the one that is checked into the repository, and that all resolved changes take place.
Exceptions: Type: UnresolvedConflict
Causes: The user tries to finish this function, but there are still unresolved conflicts.
Handling Performed: Nothing gets changed. User isn't allowed to continue until the conflicts are resolved (unless they cancel the function). The user is notified of the unresolved conflict.

5.3.2 Assign Meta-Model to Model

Assigns a meta-Model to a Model. When editing a Model, the user can then add to the Model any of the drawable components within the meta-Model.
 
Abbreviation: ASSIGNMM 
Pre-Condition(s): The user is creating a new Model.
There is at least one meta-Model that has already been created.
Post-Condition(s): The Model now uses the specified meta-Model for evaluating it's rules, and for specifying what nodes and arcs can be placed on the Model.
Business Rules: No business rules apply.
Input(s): The Model that is being created.
The filename of the meta-Model that the user wants to assign to the Model.
Output(s): The updated Model.
Processing: Accepts input from the user about which meta-Model to use.
Stores the meta-Model with the Model. 
Control/UI/Reports: This function is performed from within the create Model function'the user should be allowed to type in the meta-Model file name, or be allowed to browse through a directory structure to look for meta-Model files. 
Quality Aspects: Usability: The user is provided with the ability to browse though a file system to look for a meta-Model. The browsing should only show files that are of the meta-Model type. 
Output . The updated Model will always contain a valid meta-Model.
Performance: This function should perform interactively. It takes doesn't take up excessive system resources.
Testing Requirements: Testers should make sure that only valid meta-Model's can be assigned to the Model. They should also make sure that when editing the Model, the tool palette contains all the drawable items from the Model's meta-Model, such as the nodes and arcs. They should also make sure that they can add all of the meta-Models drawable items.
Exceptions: Type: NoMetaModelDefined
Causes: The user doesn't specify a valid meta-Model file.
Handling Performed: The user should be notified that they haven't specified a valid meta-Model. They are unable to continue until they have specified one (however they can abort/cancel).

5.3.3 Assign Package to Model

Assigns a package to a Model. The Model then displays all of it's elements using this package.
 
Abbreviation: ASSIGNPKGE 
Pre-Condition(s): The user is editing or creating a Model.
The user has assigned a meta-Model to the Model.
There is at least one package defined that uses the Model's meta-Model. 
Post-Condition(s): The Model now uses the package's graphic definition of the nodes and arcs, when rendering them to a viewport.
Business Rules: No business rules apply.
Input(s): The current Model.