5. Functional Requirements

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

• The code needs to be highly maintainable, as software engineering and design methodology is constantly evolving. If this software product is to be updated or maintained in a time and cost effective manner, the code needs to be highly maintainable.
• The performance of a number of functions is described as being interactive. This is defined as the user being able to get continuous and quick-to-respond feedback on the operation that they are performing.
• A number of functions use a GUI to display information. This GUI will be implemented in swing, and therefore will be portable to any java platform that fully supports swing applications.

 

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. The meta-Model assigned to the current Model. The package that the user wants to be assigned to the Model.
Output(s):	The updated Model. When the Model is rendered to a viewport, it now uses the assigned package's graphics.
Processing:	Accepts input from the user about which package to use. If the package has the same meta-Model as the current Model, then it is stored this with the Model.  Otherwise an exception occurs.
Control/UI/Reports:	The user should be presented with a list of all available packages that match the Model's meta-Model.  This can be done with a . browse files. dialog, that allows the user to browse for all packages that have the same meta-Model as the current Model.
Quality Aspects:	Usability: The user is provided with the ability to browse though a file system to look for a package. The browsing should only show files that match the meta-Model type of the current Model. Output . The updated Model will always contain a package that matches with it's meta-Model.
Performance:	This function should perform interactively, and take up minimal system resources.
Testing Requirements:	Testers should make sure that the package specified is the one that is used when the nodes of the Model are drawn'they should also make sure that a package can only be assigned to a Model if it uses the same meta-Model.

Exceptions:	Type:	DifferentMetaModel
	Causes:	The meta-Model of the package is not the same as the meta-Model of the current Model.
	Handling Performed:	The user is notified of this and the package isn't assigned to the Model. The user cannot continue until they have specified a valid package (however they can abort/cancel).

5.3.4 Undo/Redo (at least) 10 Changes

During the course of editing, the user can undo and redo changes, to correct errors and to promote exploratory design and use of the product. The changes undone can be re-applied if so desired.
 

Abbreviation:	UNDO
Pre-Condition(s):	There are events in the undo stack
Post-Condition(s):	The respective action(s) have been un-done.
Business Rules:	No business rules apply.
Input(s):	The user enters a number between 1 and threshold set or events that have taken place. This value is then passed to the function.
Output(s):	The Model file which exists in memory, which is reflected on screen, has the last .n. actions reverted.
Processing:	The most recent command in the undo buffer is 'undone'. This is then added to the redo buffer. Some events, such as 'save file' can not be undone. At least all edit functions however will be supported.
Control/UI/Reports:	If the undo is successful, then the only feedback is the change in system state. If the undo was unsuccessful then a message is displayed.
Quality Aspects:	At least 10 events will be stored in the undo buffer. There may however be significantly more.
Performance:	The time to undo an action should be approximately the same at the time to perform the action.
Testing Requirements:	All actions which can be done need to be tested for undo

Exceptions:	Type:	UndoException
	Causes:	No undo actions in the undo buffer.
	Handling Performed:	Message displayed to user via error dialog of problem  Control returned to canvas upon user acknowledgement or error.

5.3.5 Convert between Meta-Model

Change Meta-Model used for any particular Model. The Model keeps the nodes arcs and all Model related components from the previous Model but allows the user to use components from a new Meta-Model.
 

Abbreviation:	CONVERTMM
PreCondition(s):	A Model is open and currently has focus. Current Model has been built based upon a Meta-Model.
PostCondition(s):	All information contained in Model has been changed to represent that of the new Meta-Model.  Representation of Model has not changed.
Business Rules:	No business rules apply.
Input(s):	Meta-Model - New Meta-Model to be used.
Output(s):	Storage of Model contains new Meta-Model information.  Upon completion, process signifies success or failure to calling function to allow exception handling to take place.
Processing:	Client should compare all nodes and arcs of the current Meta-Model with that of the new. If both are compatible, the new Meta-Model is loaded as currently used.
Control/UI/Reports:	Dialog containing all compatible Meta-Models gains focus. Once user confirms selection, control is then given to the canvas assuming no errors otherwise error dialog appears notifying user of problem.
Quality Aspects:	Each Meta-Model contains identifiers which are used to identify other compatible Meta-Models. Only compatible Meta-Models will be shown in selection dialogs.
Performance:	Should be quick but may slow depending on size of Meta-Model for more information has to be loaded.
Testing Requirements:	Create Model based on any particular Meta-Model. Create new Meta-Model and convert current Project Model. From this point on make sure any changes in the new Meta-Model is reflected in the sample Project Model and all existing information has remained unchanged.  Look for rules defined in new Meta-Model are enforced once the conversion has taken place.

Exceptions:	Type:	IncompatibleMMException
	Causes:	Selected Meta-Model is unsuited to take place of existing.
	Handling Performed:	User is notified of error via dialog.  Focus is returned to dialog upon acknowledgment of error.

5.3.6 Multiple Views of the same Model

To view current Model from different perspectives.Two windows of the same Model at different positions and perspectives.
 

Abbreviation:	CHANGEVIEW
PreCondition(s):	A Model is open and currently in active view.
PostCondition(s):	Additional view of Model is been rendered to screen.
Business Rules:	No business rules apply.
Input(s):	Inputs relating to alteration of Model position and perspectives. Defined menu/hotkey/mouse strokes required to activate additional view.
Output(s):	Additional view of Model rendered to screen.
Processing:	Client calculates co-ordinates for altered perspective then renders to screen.
Control/UI/Reports:	Additional view of Model is displayed on canvas. New window accompanyies the current one, both in separate windows. Control is reluinquished to the overall event handling system.
Quality Aspects:	Different views of Model can be easily cycled through by use of menu options or the "Ctrl + Tab" key combination. View should be easily zoomable, therefore size will not affect quality nor speed of redraw.
Performance:	Any system resources that are consumed by this operation are only consumed for the duration of a screen refresh-rate.
Testing Requirements:	When testing focus on making sure correct view of Model is displayed.  When view of one is altered the other remains unchanged.

Exceptions:	Type:	OutOfMemoryException.
	Causes:	Insufficient memory for new view.
	Handling Performed:	User Notified of error through error dialog. Abort creation of new view then message dialog to user. Control returns to canvas.

5.3.7 View Model
 

5.3.7.1 Display Visible Nodes in a viewport

Displays all of a Model's nodes that are visible in a given viewport. The shape of each node is determined by the current package; or more specifically, the package node that corresponds to the meta-node of which a node is a type of.
 

Abbreviation:	DISPVISNODES
Pre-Condition(s):	User is viewing Model in visible view. A viewport needs to be repainted.
Post-Condition(s):	The visible nodes are displayed in the viewport.
Business Rules:	No business rules apply.
Input(s):	Model needing repainting. Viewport containing Model needing repainting.
Processing:	For all nodes in a Model: Determine any visible nodes by checking the bounds of the node against the viewport dimensions. (The bounds are defined by the package node.)   For all visible nodes:  Transform the node's coordinates from local to viewport coords.   Draw the node at the window coordinates, using the shape defined by the current package.   Draw any properties of the node for which display properties have been specified.
Control/UI/Reports:	Function called automatically when viewport needs repainting. Requires no user interaction but may be called indirectly as a result of user actions. Such as zooming, panning etc.
Quality Aspects:	Only visible nodes will be displayed on viewport. Those that are out of the viewports bounds, aren't displayed hence saving processing time.
Performance:	This function should perform interactively, with performance degrading gracefully as more nodes are added to the Model.
Testing Requirements:	Testers should make sure that all nodes that should be visible are drawn, and that they are drawn as specified by their corresponding package node.  For example this may be forced by scaling, resizing or opening a new Model.
Exceptions:	Not yet determined.

5.3.7.2 Display Visible Arcs in a viewport

Displays any of a Model's arcs that are visible in a given viewport. The shape of the arc is determined by the current package.
 

Abbreviation:	DISPVISARCS
Pre-Condition(s):	User is viewing Model in visible view. A viewport needs to be repainted. Start and end nodes of the arcs have already been transformed.
Post-Condition(s):	All visible arcs are displayed in the viewport.
Business Rules:	No business rules apply.
Input(s):	Model needing repainting ( therefore all arcs in Model ). Viewport containing Model needing repainting.
Output(s):	Model is rendered to screen. No storage is required and no output or information is passed onto any other part of the program.
Processing:	For all arcs: Determine which ones are visible.   For all visible arcs:  Transform the arc's coordinates from local to viewport coords.   Draw the arc as specified by the current package, between the arc's start node and end nodes.   Draw any properties of the arc that have display properties specified.
Control/UI/Reports:	Function called automatically when viewport needs repainting. Requires no user interaction but may be called indirectly as a result of user actions. Such as zooming, panning etc.
Quality Aspects:	Only visible arcs will be displayed on viewport. Those that are out of the viewports bounds, aren't displayed hence saving processing time.
Performance:	This function should perform interactively, with performance degrading gracefully as the number of arc on the Model increases.
Testing Requirements:	Testers should make sure that the arcs are correctly drawn between the start and end nodes, and in the style etc specified by the corresponding package arc.  This may be forced by scaling the Model, resizing or opening a new Model.
Exceptions:	Not yet determined.

5.3.7.3 Transform local coords to viewport coords

This function transforms the coords of an item on a Model from its local coordinate space to the viewport's space.
 

Abbreviation:	TRANSCOORDS
Pre-Condition(s):	A Model is about to be rendered in a viewport. i.e. a Model is open for editing or viewing, and the window the Model is in needs to be repainted.  All of the Model items that are currently visible in the viewport have been determined, as this function is only performed on the items that are visible.
Post-Condition(s):	All visible item's local coords have been transformed to viewspace.
Business Rules:	No business rules apply.
Input(s):	A list of all visible Model items. The viewport that the items are being rendered into.
Output(s):	The transformed coordinates of each item in the list.
Processing:	Local -> Model : package coords + location on Model. The local coordinates are converted to Model space, so that they are centered around their Model position.  Model -> View : Model coords - viewport origin. The Model coords are transformed, so that the coordinates at the center of the viewport are 0,0. View -> Zoom : view coords * Zoom factor. This transform, zooms in/out from the center of the View space. Zoom -> Viewport : zoom coords + ( viewport extents / 2 ). This final transform moves the coords so that the top-left coord is (0,0). This is because the Java drawing routines use (0,0) as the top-left, with positive x to the right, and positive y down. All of these transforms can be combined as: Viewport = ( (Shape + Local . ViewportOrigin) * Zoom ) + ( ViewportExtents / 2 ).
Control/UI/Reports:	This is purely a processing function, and as such doesn't require any UI. It is called to prepare all the view coordinates of each visible Model item before it gets rendered.
Quality Aspects:	The coords should all get correctly transformed, as specified in the processing section.
Testing Requirements:	Testers should make sure that the transformations are being calculated correctly. This can be done by changing the values in the equation, and making sure that the view is updated with the correct positions.
Performance:	Under normal load conditions, this function should be able to perform interactively ( that is, as the user changes the coords of a Model item, they should get interactive feedback about this. ) The performance of this function should degrade gracefully as the number of visible Model items increase.

Exceptions:	Type:	NonPositiveZoom
	Causes:	The zoom factor of the viewport is set to <= 0.
	Handling Performed:	If the user tries to set the zoom factor <= 0 then it should just retain it's previous value. The user should be informed that they can't set the zoom factor to <= 0.

5.3.7.4 Zoom view in/out

Zooms a viewport in or out, allowing more/less of a Model to be seen.
 

Abbreviation:	ZOOM
Pre-Condition(s):	A Model has been opened, and the user is looking at it.
Post-Condition(s):	The zoom factor of the viewport is increased/decreased. This will have the effect of drawing all items on the Model either smaller or larger depending on whether or not the user is zooming out or in.
Business Rules:	No business rules apply.
Input(s):	The viewport. The Model the user is editing. The direction to zoom. The amount to zoom.
Output(s):	The view of the Model will be updated to reflect the new zoom factor.
Processing:	Increase/Decrease the zoom factor of the viewport to the new value.  If the zoom factor is <=0, then don't decrease the value.
Control/UI/Reports:	User should be given a slider or some other widget, so that they control the level of zoom. (Maybe a drop down box with a list of pre-defined zoom factors) etc.  The user should be able to perform this at any stage while editing a Model.
Quality Aspects:	Some jittering may occur as the Model is zoomed in and out. This is due to the integer representation of pixels on the display hardware.
Performance:	The user should be able to zoom the Model in interactively, with performance degrading gracefully as the Model becomes more and more complex.
Testing Requirements:	Testers should make sure that the zoom works in the correct direction, and that the zoom factor is never <= 0.

Exceptions:	Type:	NonPositiveZoom
	Causes:	The zoom factor of the viewport is set to <= 0.
	Handling Performed:	If the user tries to set the zoom factor <= 0 then it should just retain it's previous value. The user should be informed that they can't set the zoom factor to <= 0.

5.3.7.5 Pan view left/right/up/down

Pans around a viewport, showing new areas of a Model, and hiding others.
 

Abbreviation:	PAN
Pre-Condition(s):	A Model has been opened, and the user is looking at it.
Post-Condition(s):	The viewport is now in a new position determined by which way the user pans.  This new position will uncover a part of the Model previously not displayed on the viewport.
Business Rules:	No business rules apply.
Input(s):	The Model the user is viewing. The viewport the Model is in. The direction to pan. The amount to pan.
Output(s):	The view of the Model is now updated to represent where the viewport is over the Model.
Processing:	Increase/Decrease the viewport's origin in the direction specified, by the amount specified.
Control/UI/Reports:	The user should be able to use scroll bars to pan around the Model. There should also be hot-keys assigned to this (probably the arrow keys), so they don't have to use the mouse.  Panning can be performed at anytime while the user is editing a Model.
Quality Aspects:	Some flickering may occur during panning as Java is slow :-). This flickering will become more pronounced as the viewport size increases.
Performance:	The user should be able to pan around the Model interactively, with performance degrading gracefully as the Model becomes more and more complex, and as the size of the viewport increases (due to the speed limitations of Java).
Testing Requirements:	Testers should make sure that the correct parts of the Model are uncovered as the user pans over them. Also, that the scroll bar thumbs accurately represent the amount of scrolling that can be performed.

Exceptions:	Type:	PanOutOfBounds
	Causes:	The user tries to pan beyond the size of the Model.
	Handling Performed:	The processing of this function is aborted. No messages need to get sent to the user. They should get visual indication from the position of the thumb on a scrollbar.

5.4 CRUD Meta-Model
 

5.4.1 Create New Meta-Model

Create new Meta-Model to be used when designing packages and enforced in Model creation.
 

Abbreviation:	CREATEMM
Pre-Condition(s):	Sufficient memory on hard disk. Meta-Model is non-existent concerning registered meta-Models within system. Meta-Model file doesn't exist in specified location on local machine.
Post-Condition(s):	Meta-Model file created and exists in specified location. Meta-Model has been added to list of existing meta-Models. Meta-Model now available to have packages assigned.
Business Rules:	Meta-Model name length limited to 255 charaters maximum.
Input(s):	Local storage path. New meta-Model name.
Output(s):	File created in storage for meta-Model.
Processing:	Once all information has been entered, client will check for an existing meta-Model in the specified path with the same name.  If all checks succeed, blank file created awaiting definitions to be saved.
Control/UI/Reports:	If creation succeeds, a form containing all inputs and controls needed for designing meta-Models will appear. From here user will be able to define nodes, arcs and rules.
Quality Aspects:	Efficient in terms of speed.  Frequent use of this function warrents speedy execution time.
Performance:	Very few system resources are used. Less than half a second should elapse for this operation to complete.
Testing Requirements:	Once meta-Model created, ability to specify nodes, arcs and rules should be available. When creating a Model, new meta-Model chould appear in list of available meta-Models, also make sure the file is created with correct name in the right path.

Exceptions:	Type:	MMExistsException
	Causes:	Meta-Model pre-exists.
	Handling Performed:	A Dialog is displayed indicating that the file already exists and prompts the user to cancel or replace the existing file.
	Type:	FileIOException
	Causes:	File already exists in location  Not enough memory
	Handling Performed:	User is notified of problem via error dialog.  Creation of file and meta-Model is aborted.  Focus is returned to dialog.

5.4.2 CRUD Meta-Nodes

5.4.2.1 Specify Type

Specify a node type to be included with the meta-Model. All nodes specified are considered within the scope of Meta-Model.
(eg "class", "object").
 

Abbreviation:	SPECNODETYPE
Pre-Condition(s):	Meta-Model is open for edit / creation and waiting for node definitions. An instance of node determined by node type is non-existant.
Post-Condition(s):	Validity of node definition checked. Node created and inserted into list of node definitions residing in current opened meta-Model.
Business Rules:	No business rules apply.
Input(s):	Type name of node.
Output(s):	Type included in list of node types that exist within the current meta-Model opened for editing.
Processing:	During the creation of the node definition, all entries are validated. If all checks are successful, node definition is added to meta-Model structure and type added to meta-Model node type list.
Control/UI/Reports:	Form is displayed prompting node type.  List is shown of all nodes contained by meta-Model.  If new type ( text data ) is duplicated, user is informed.
Quality Aspects:	Structure or form of meta-Model definitions should not change over the duration of use of this product. For any type of meta-Model wished to be created, what is provided should be sufficient.
Performance:	Fairly instant, processing fast, restricted by typing speed.
Testing Requirements:	Node type has been correctly inserted into meta-Model.  When saving the meta-Model, check to ensure file size increases respective to the amount of nodes added. Main testing will come in when testing the creation of packages, making sure the created nodes, when saved to file, are available for some sort of graphical representation to be created. Nodes are available when meta-Model has been saved and re-opened.
Exceptions:	Type:	NodeExistsException
	Causes:	Node exists within meta-Model definition.
	Handling Performed:	Error dialog appears informing user of state.  Upon confirmation, dialog disappears, returning focus to definition of node.

5.4.2.2 Specify Properties

Declare attributes and methods to be included with nodes (name, methods etc).
 

Abbreviation:	SPECNODEPROP
Pre-Condition(s):	Meta-Model has been opened of creation / editing. Node type has been specified. Property relating to node is non-existant.
Post-Condition(s):	Property has been added to node spec. Property added to list displaying current existing properties of node.
Business Rules:	No business rules apply.
Input(s):	Text describing attribute or method signature.
Output(s):	Property added to node property list. Returns either success or failure depending on the uniqueness of property.
Processing:	Once the validity of the property is checked within the scope of the associated node, the property is added, otherwise an exception will be thrown.
Control/UI/Reports:	Form is displayed prompting for required data.  List of nodes and their current properties contained by meta-Model are displayed which are selectable to assign a property. The user  is to select a node if to specify the property using controls provided.
Quality Aspects:	All properties are defined through text, making this process very generic allowing nodes to represent anything they dream of. All property information must be clearly displayed as it can potentially contain large amounts of information.
Performance:	Less than half a second response to user selecting meta-node to display current properties. Similar response time for checking of duplicate properties.
Testing Requirements:	Property has been included with other node properties. The use of this node when creating Models should display properties defined. Given this, a test case could include the creation of a node and its properties then using this in a Model. Another, to check saving of data is correct, create meta-Model with nodes associated properties, save, then reopen for edit.

Exceptions:	Type:	PropertyAlreadyExists
	Causes:	Property definition exists within node.
	Handling Performed:	User notified of problem via error dialog.  Any changes are aborted.  Focus returned to control in which the error occurred.

5.4.3 CRUD Meta-Arcs

5.4.3.1 Specify Type

Specify an arc type to be included with the meta-Model, for example-- association, inheritance.
 

Abbreviation:	SPECARCTYPE
Pre-Condition(s):	Meta-Model is open and waiting for arc definitions ( same as waiting for node definitions ). An instance of arc type doesn't exist in meta-Model.
Post-Condition(s):	Validity of arc definition checked. Arc Created and inserted into lists of arc definitions residing in current opened meta-Model.
Business Rules:	No business rules apply.
Input(s):	Type name of arc.
Output(s):	Type included in list of arc types that exist within the current meta-Model opened for edit.
Processing:	During the creation of the arc definition, all entries are validated. If all checks are successful, arc definition is added to meta-Model structure and type added to meta-Model arc type list.
Control/UI/Reports:	Form is displayed prompting for arc name.  List is shown of all arc types contained by meta-Model.  If duplicate type is found, user is informed.
Quality Aspects:	Flexible, simple and generic definition for arc types will enable expansion for future use. For any type of meta-Model wished to be created, what is provided should be sufficient.
Performance:	Less than a second.
Testing Requirements:	Arc type has been correctly inserted into meta-Model.  When saving the meta-Model, check to ensure file size increases respective to the amount of arcs added. Main testing will come in when testing the creation of packages, making sure the created arcs, when saved to file, are available for some sort of graphical representation to be created.

Exceptions:	Type:	ArcExistsException
	Causes:	Arc exists within meta-Model definition.
	Handling Performed:	Error dialog appears informing user of state.  Upon confirmation, dialog disappears, returning focus to definition of arc.

5.4.3.2 Specify Properties

Declare attributes and methods to be included with arc (eg. cardinals, label, etc...).
 

Abbreviation:	SPECARCPROP
Pre-Condition(s):	Meta-Model has been opened of creation / editing. Arc type has been specified. Property relating to arc is non-existant.
Post-Condition(s):	Property has been added to arc spec. Property added to list displaying current existing properties of arc.
Business Rules:	No business rules apply.
Input(s):	Text signifying attribute or method signature which passed through to function for validation and setting.
Output(s):	Property added to arc property list. Returns either success or failure depending on the uniqueness of property.
Processing:	Once duplication of property is checked within the scope of the associated arc, the property is added, otherwise an exception is be thrown.
Control/UI/Reports:	Form is displayed prompting for required data.  List of arcs contained by meta-Model is displayed which are selectable to assign a property. The user is to select an arc to specify property using controls provided.
Quality Aspects:	All properties are defined through text, making this process very generic allowing arcs to represent.
Performance:	Less than half a second.
Testing Requirements:	Property has been included with other arc properties. The use of this arc when creating Models should display properties defined. Given this, a test case could include the creation of a arc and its properties then using this in a Model. Another, to check saving of data is correct, create meta-Model with arcs associated properties, save, then reopen for edit.

Exceptions:	Type:	PropertyAlreadyExists
	Causes:	Property definition exists within arc.
	Handling Performed:	User notified of problem via error dialog.  Any changes are aborted.  Focus returned to control in which the error occurred..

5.4.4 CRUD Meta-Rules
 

5.4.4.1 Specify Type of Meta-Rule

Specify type of rule for Meta-Rule(eg.simple, multiplicity, cyclic)
 

Abbreviation:	SPECMRULE
Pre-Condition(s):	Meta-Model file open for edit / creation. Meta-Rule has not been defined within scope of meta-Model.
Post-Condition(s):	New rule specified within scope of meta-Model. Rule created and inserted into list of rule definitions held within meta-Model.
Business Rules:	No business rules apply.
Input(s):	Label accompanying and representing the type of rule.
Output(s):	Success or failure.
Processing:	Once the rule name has been entered, checks to ensure rule name hasn't previously been specified take place.
Control/UI/Reports:	These operations would usually conducted after creating a meta-Model therefore all controls and input boxes would be part of the same form in some tabular fashion. Meta-Model tab would be selected prompting user for rule name.
Quality Aspects:	Structure or form of rule definitions should not change over the duration of use of this product. For any rule type, what is provided should be sufficient.
Performance:	Less than half a second.
Testing Requirements:	Rule type should be stored with meta-Model information, two main concerns when testing this is with the storage and enforcement of the rule. Two test cases which spring to mind include saving meta-Model, then re-open for edit. Another is to save the meta-Model, when rule breached during creation of Model, error message should display rule type which has been violated.

Exceptions:	Type:	RuleTypeExistsException
	Causes:	Rule exists within Meta-Model definition.
	Handling Performed:	Error dialog appears informing user of state.  Upon confirmation, dialog disappears, returning focus to meta-Model dialog.

5.4.4.2 Specify Components of Meta-Rule

Specify components (component being meta-node or meta-arc) used to create rule.
 

Abbreviation:	SPECMCOMPONENT
Pre-Condition(s):	Meta-Model file open for edit / creation. Rule type has been specified.  Component to be included in rule specification has not already been specified.
Post-Condition(s):	Selected component is now associated with rule.
Business Rules:	No business rules apply.
Input(s):	Meta-Node or meta-arc to be included in rule definition.
Output(s):	Function shall return success or failure depending on component duplication.
Processing:	After component has been selected a duplication check is executed.
Control/UI/Reports:	These operations would usually be conducted during creation of a meta-Model therefore all controls and input boxes would be part of the same form in some tabular fashion. Meta-Model tab would be selected prompting user for components. Upon completion control would logically be passed to specify conditions of rule.
Quality Aspects:	Any component may be specified, allowing rules to be necessarily generic.
Performance:	Less than half a second.
Testing Requirements:	Component should be stored with meta-Model information'two main concerns when testing this is with the storage and enforcement of rule involving component. Two test cases which spring to mind include saving meta-Model, then re-open for edit. Another is to save the meta-Model, when rule breached during Model creation, ensure correct components are involved.

Exceptions:	Type:	ComponentExistsException
	Causes:	Component has already been associated with rule.
	Handling Performed:	Error dialog appears informing user of state.  Upon confirmation, dialog disappears, returning focus to definition of node.

5.4.4.3 Specify Meta-Condition

Declare conditions which are to be enforced when applying a rule. Allowing the base satisfiable rule to be applied for validating Models at run-time.
(eg. Joining two nodes with a particular arc)
 

Abbreviation:	SPECMCONDITION
Pre-Condition(s):	Meta-Model file open for edit / creation. Meta-Node type(s) which are to be included have been specified  Meta-Arc type(s) which are to be included have been specified.  Condition do not currently exist within meta-Model.
Post-Condition(s):	Condition applied and stored with meta-rule.
Business Rules:	No business rules apply.
Input(s):	Meta-Rule to which condition applies. Condition(s) to be enforced when applying rule.
Output(s):	Condition included with others specified within meta-Model.
Processing:	Duplicates of condition are checked. If none are found the specified condition is added to list of conditions residing with meta-Model currently opened for edit.
Control/UI/Reports:	These operations would usually be conducted during creation of a meta-Model therefore all controls and input boxes would be part of the same form in some tabular fashion. Meta-Model tab would be selected prompting user for conditions. Control should return to specifying rule type.
Quality Aspects:	Creation of rule conditions are limited by only the users imagination. Whatever conditions or rules needing enforcement may be done through this functionality.
Performance:	Less than half a second.
Testing Requirements:	Condition should be stored with meta-Model information'two main concerns when testing this should be with storage and enforcement of condition'two test cases which spring to mind include saving meta-Model, then re-open for edit. Another is to save the meta-Model, force rule to be breached when creating Model based on this meta-Model.

Exceptions:	Type:	ConditionExistsException
	Causes:	Condition has already been defined.
	Handling Performed:	Error dialog appears informing user of state.  Upon confirmation, dialog disappears, returning focus to definition of node.

5.5 CRUD Package
 

5.5.1 Create new package

5.5.1.1 Select Meta-Model to Implement

Selects which meta-Model the package will be based on.
 

Abbreviation:	SELECTMM
Pre-Condition(s):	At least one meta-Model has already been created. User is in the process of creating a new package.
Post-Condition(s):	The package being created is now associated with a pre existing meta-Model.
Business Rules:	No business rules apply.
Input(s):	A meta-Model The package that is being constructed
Output(s):	A package that is now associated to a meta-Model
Processing:	Any applicable, locally available, meta-Models are presented to user to choose from. The package is associated with the meta-Model.
Control/UI/Reports:	User is given a list of all available meta-Models to select from.
Quality Aspects:	Usability: Selection of meta Model is done via gui list.
Performance:	This action should have low stress on the System Resources
Testing Requirements:	Testers should make sure that the list of meta-Models is filled with all applicable Meta-Models. Testers should ensure that the package file is now associated with the meta Model
Exceptions:	causes: If no meta-Models are available.  handling performed: user is informed of the lack of Meta-Models and  package creation is cancelled. messages dispatched: "There are no metaModels to choose from"

5.5.2 CRUD package node

Allows the user to CRUD a package node.
 

Abbreviation:	CRUDPN
Pre-Condition(s):	The user must be editing a package. The user must have write permissions on the package. There has to be an unassigned meta-node from the package's meta-Model.
Post-Condition(s):	A new package node is CRUDed to the package. A meta-node from the package's meta-Model has been assigned/unassigned to the package node.
Business Rules:	No business rules apply.
Input(s):	The package being edited,  A meta-node from the package's meta-Model
Output(s):	The altered package.
Processing:	A meta-node is selected from a list of unassigned meta-nodes in the meta-Model. User specifies package node shape. User optionally specifies attributes for any of the meta-node's properties.
Control/UI/Reports:	list of possible meta nodes is displayed.
Quality Aspects:	Not yet determined.
Performance:	The user should be able to create package nodes in real-time. This operation will have medium system resources usage.
Testing Requirements:	Testers should make sure that the package node is properly CRUD'ed, and that when a node is displayed using the package, the package node is displayed as it was specified.Module must ensure that the package node conforms to the rules of the meta Model node
Exceptions:	type: security error cause: If the user doesn't have write permission on the package handling performed:  the user should be notified. messages dispatched: 'You do not have write permissions on this package.'   type: no nodes cause:  If there are no unassigned meta-nodes handling performed:  the user should be notified. message dispatched: "There are no unnassigned nodes available."

5.5.2.1 Specify package node shape

Lets the user define the shape/outline of a package node
 

Abbreviation:	SPECPNSHAPE
Pre-Condition(s):	The User must be CRUD'ing the package node.
Post-Condition(s):	The package node shape is now set to what was specified by the user.
Business Rules:	No business rules apply.
Input(s):	The shape definition using point and click technique to draw graphical representation of the node.
Processing:	The user specifies the shape/outline of the package node, by using a set of drawing tools. The bounds of the shape are calculated such that all parts of the shape are inside the bounds. The user sets the center point of the shape. If unspecified, this defaults to the center of the bounds.
Control/UI/Reports:	The UI of this function is similar to that of a simple paint program. The user has a set of pre-defined tools for drawing shapes, and uses them to create the shapes. A set of rulers should also be provided, so the user can accurately line up different parts of the shape. Standard editing commands such as cut, copy, paste, etc should be provided.
Quality Aspects:	Usability: make sure that it is easy to add components.  Make sure that drawing icons are meaningful and easy to recognise.
Performance:	The operation should use low system resources.
Testing Requirements:	Testers need to make sure that the shape specified, is the one used when drawing nodes with this package. Making sure that the center point and the bounds are also correct. Make sure that mouse controls are correct.
Exceptions:	Not determined as of yet.

5.5.2.2 Specify display information for a meta-node's properties

Lets the user specify information about how to display the properties of a meta-node associated with a particular package node.
 

Abbreviation:	SPECMNPROPDISP
Pre-Condition(s):	User must be CRUD'ing a package node. The package node must have a shape, and a center point.
Post-Condition(s):	The package node is updated with the new values.
Business Rules:	No business rules apply.
Input(s):	The current package node being edited The meta-node associated with the package node. Position relative to the center of the package node. An outline of the property's area. A bounding region for the property's data.
Output(s):	The revised package node with modified properties.
Processing:	Accepts input from the user regarding where to display the property relative to the center of the package node shape, the outline of the properties area (rounded box, rectangle etc), and a bounding region for displaying the properties data. This is then stored with the package node data.
Control/UI/Reports:	list of all properties for package node. Drop down list for all alternatives for each property.
Quality Aspects:	usablility: major usablity concerns with this function as it's possible complexity is apparent.  It must be made so that the inputs made by that user are intuitive.
Performance:	Low stress on system resources.
Testing Requirements:	Testers should make sure that the positions and attributes of each property are correct when a node is drawn using this package.
Exceptions:	type: NoPackageShapeError causes:If the package node doesn't have a shape, and a center point handling performed:  the user is notified that they have to specify the shape first.  messages dispatched: "Please specify the shape and center point of this package node.

5.5.3 CRUD package arc

Lets the user CRUD a package arc.
 

Abbreviation:	CRUDPA
Pre-Condition(s):	The user must be editing a package. The user must have write permissions on the package. There has to be an unassigned/assigned   meta-arc from the package's meta-Model.
Post-Condition(s):	A new package arc is CRUDed to the package. A meta-arc from the packages meta-Model has been assigned/unassigned.
Business Rules:	No business rules apply.
Input(s):	The package being edited. A meta-arc from the packages meta-Model.
Output(s):	A modified package include the CRUDed package arc.
Processing:	A meta-arc is selected from a list of  meta-arcs in the meta-Model. User specifies package arc line type. User specifies package arc line style. User specifies package arc graphics and locations. User optionally specifies display attributes for any of the meta-node's properties.
Control/UI/Reports:	There needs to be a preview window, showing the user how the arc will look. This is updated as the user specifies different line types, styles, arc graphics etc.
Quality Aspects:	Usability: easy of selection of meta arc from list
Performance:	this operation should be low on system resources
Testing Requirements:	make sure all applicable meta arcs are displayed.  Ensure that the arc that is specified maps to the selected meta arc.
Exceptions:	type: security error cause: If the user doesn't have write permission on the package handling performed:  the user should be notified. messages dispatched: 'You do not have write permissions on this package.'   type: no arcs cause  If there are no unassigned meta-arcs handling performed:  the user should be notified. message dispatched: "There are no unnassigned arcs available."

5.5.3.1 Specify default line type (straight, curved, stepped)

Lets the user specify the default line type that a particular arc will have. These are straight, curved, and stepped.
 

Abbreviation:	SPECLINETYPE
Pre-Condition(s):	The user is CRUD'ing a package arc.
Post-Condition(s):	The package arc now has the line style specified by the user.
Business Rules:	No business rules apply.
Input(s):	The package arc being edited. The type of line.
Output(s):	The edited arc of the specified line type.
Processing:	Accepts input from the user regarding the line type, and then stores it with the package arc. Preview of Arc is updatred
Control/UI/Reports:	GUI could just be a set of radio buttons, letting the user choose which type to use.
Quality Aspects:	Usability: The different line types should be selected from a radio button group to reduce user errors
Performance:	this action should have a low stress on system resources
Testing Requirements:	Ensure that the line type specified is used when the arc is displayed.
Exceptions:	none determined at this time

5.5.3.2 Specify arc graphic and it's location

Lets the user specify a graphic, and that graphics position on the arc. e.g. aggregation graphic, with location at the start of the arc.
 

Abbreviation:	SPECARCGRAPH
Pre-Condition(s):	The user must be CRUD'ing a package arc. Arc graphics must have been specified by the user.
Post-Condition(s):	The package arc now has information concerning where to draw graphics on the arc.
Business Rules:	No business rules apply.
Input(s):	The package arc being edited. Any number of graphics, and their location on the arc.
Output(s):	The revised package arc containing information concerning where to draw graphics on the arc.
Processing:	Accepts from the user an arc graphic, and it's location on the arc, such as the start, the end, the first elbow etc. Stores this information in the package arc. Preview of arc is updated.
Control/UI/Reports:	User needs to have a list of all available arc graphics.
Quality Aspects:	selection of where graphics is diplayed on the arc is done via a gui.
Performance:	low system resources usage.
Testing Requirements:	ensure that graphic informaion is diplayed when arc is displayed.
Exceptions:	type noArcGrasphics cause: If no arc graphics have been specified handling performed: the user must be notified.  message dispatched: "Please specify arc graphics first".

5.5.3.3 Specify line style (thickness, dashed)

Lets the user specify the line style of the arc. Including the thickness, dashed, and the end style (directional arrows etc).
 

Abbreviation:	SPECARCSTYLE
Pre-Condition(s):	The user must be CRUD'ing a package arc.
Post-Condition(s):	The package arc now has info on how to draw the line.
Business Rules:	No business rules apply.
Input(s):	The package arc being edited. The line style.
Output(s):	The modified package arc.
Processing:	Accepts from the user information about the line style, and stores this info, with the package arc. Preview of arc is updated.
Control/UI/Reports:	This function should be done by using a dialog box similar to the one in most applications that let you specify line styles, including options for things such as line style, dashed, thickness etc.
Quality Aspects:	Usability: Dilog of line styles shows user example of the line styles available
Performance:	This function should perform in real-time.
Testing Requirements:	Ensure preview of arc is updated. Ensure that the line style specified is displayed when the arc is used in a Model.
Exceptions:	none determined at this time

5.5.3.4 Specify for each property, display attributes such as position, outline & bounding region

Allows the user to specify a relative position, an outline of, and a bounding region for any an arc's properties (as defined by the meta-node that the particular package arc represents).
 

Abbreviation:	SPECMAPROPDISP
Pre-Condition(s):	The user must be CRUD'ing a package arc The meta-node associated with the package arc must have properties.
Post-Condition(s):	The package arc now has info, on where/how to draw any properties of the meta-arc.
Business Rules:	No business rules apply.
Input(s):	The currently being edited package arc. The properties of the meta-arc The position on the arc to display the property. The outline of the property. The bounding region of the property.
Output(s):	The modified package arc containg the properties information.
Processing:	Accept input from the user about how to display a property of the arc, and store it with the package arc.
Control/UI/Reports:	The user should be able to do this graphically, by moving the properties about on a sample display of the package arc.
Quality Aspects:	usablilty: major usablity concerns with this function as it's possible complexity is apparent.  It must be made so that the inputs made by that user are intuitive.
Performance:	This function should perform in real-time.
Testing Requirements:	Ensure that these properties are saved with the arc.
Exceptions:	type: NoPropertiesError cause:  the meta-arc doesn't have any properties. handling  performed: notify user that there are no properties to edit messages dispatched: "There are no properties to edit for this arc"

5.5.4 Specify arc terminator

Lets the user create graphic symbols to appear on arcs, such as aggregation, inheritance etc.
 

Abbreviation:	SPECARCGRPH
Pre-Condition(s):	The user should be CRUD'ing a package.
Post-Condition(s):	The package now has a new arc graphic which can be used when CRUD'ing package arcs.
Business Rules:	No business rules apply.
Input(s):	The current package. The users definition of the graphic.
Output(s):	The revised package.
Processing:	Accepts from the user input about the graphic. This is done similar to a paint program, where the user has a set of drawing tools that they choose from to create the graphic. Once finished, the arc graphic is stored with the package.
Control/UI/Reports:	This function should behave similarly to a paint program, with the user selecting pre-defined graphic primitives, to create the graphic they want.
Quality Aspects:	Usability: make sure that it is easy to add components.  Make sure that drawing icons are meaningful and easy to recognise.
Performance:	This function should perform in real-time.
Testing Requirements:	Testers need to make sure that the shape specified, is the one used when drawing nodes with this package. Making sure that the center point and the bounds are also correct. Make sure that mouse controls are correct.
Exceptions:	none determined at this time

5.6 File I/O
 

5.6.1 Save Project/Model Locally

This saves the selected Project or Model to the Local Disk.

5.6.1.1 Save Locally
 

Abbreviation:	SAVELOCAL
Pre-Condition(s):	The user has selected a Model or Project in the workspace tree.
Post-Condition(s):	The selected Model or Project is written to Disk
Business Rules:	No business rules apply.
Input(s):	The Model or Project to be saved
Output(s):	The selected Model is saved to the Local Disk
Processing:	All the information relevant to the selected object is collected and written to a file. Any existing file with the same name is over-written by the new file.
Control/UI/Reports:	A progress dialog will show how much of the file has been saved  The user can save the file by selecting "Save" from the file menu.  This will save the file selected in the current workspace tree.
Quality Aspects:	If the saving process takes less than one second then the progress dialog should not be shown.
Performance:	The time taken to save the file is dependant on the size of the Project or Model being saved. It is estimated that a save will take less than 10 seconds.
Testing Requirements:	The Model must be saved to Disk in format which can be read back by the open Project.
Exceptions:	Type:	IOException
	Causes:	Disk failure  missing OS permissions
	Handling Performed:	A dialog is displayed, showing the error that has occurred, and a possible solution to the problem.  The current system state should remain unchanged.

5.6.1.2 Check-In to Remote Server

Takes the Local version and sends it back to the originating Server
 

Abbreviation:	CHECKIN
Pre-Condition(s):	The user has selected a Model or Project in the workspace tree.
Post-Condition(s):	The selected Model or Project is written to Disk on the Server
Business Rules:	No business rules apply.
Input(s):	The name of the Model or Project. The path of the Model or Project The way in which layout conflicts are handled. (Ignore, or conflict)
Output(s):	Returns a Success or failure code to the calling module. A progress dialog shows the current state of the transaction, and the success or failure notice.
Processing:	If the user is not logged in to the Server, then a connection is first established. The selected file is then sent to the Server for processing. If everything is OK then the Server sends an acknowledgment. If there are changes which are not mutually exclusive with the latest version on the Server, the Server returns a list of the conflicts to be resolved.
Control/UI/Reports:	A progress dialog shows the current state of the transaction, and the success or failure notice.
Quality Aspects:	If no error occurs, the dialog should close automatically.
Performance:	This is dependant on the size and complexity of the Model/Project, the speed of the connecting network and the load of the Server.
Testing Requirements:	The module has to fulfil the post-conditions.

Exceptions:	Type:	IOException
	Causes:	Server is not running  The Server has an error  The user is not logged in
	Handling Performed:	The check-in is aborted.   The Client returns to the state before the checking was started   The Server returns to the state of before the checking was started.

5.6.1.3 Resolve Conflicts

The conflicts detected need to be resolved in order to successfully check-in the Project or Model.
 

Abbreviation:	RESOLVE
Pre-Condition(s):	A check-in has detected conflicts.
Post-Condition(s):	All conflicts have been resolved.
Business Rules:	No business rules apply.
Input(s):	The current Model and the list of conflicts.
Output(s):	A resolved Model.
Processing:	Each conflict is displayed in the Model editor. Conflicts may consist of new items, deleted items and modified items. The modifications may only be layout-related or modification of properties. There should be an option as to whether layout related conflicts count as conflicts requiring resolution.
Control/UI/Reports:	Once the conflicts are resolved, the user should be given the option to attempt another check-in.  They also have the option to abort the check-in, and return to edit mode.
Quality Aspects:	The actions of the Client need to satisfy the requirements of the Server. It is possible that the Client thinks that everything is resolved, but another check-in attempt detects more conflicts.  The GUI for editing the Model needs to be easy to use, and as close as possible to the edit Model GUI. It should be made obvious that the user is in conflict resolution mode, and not in edit mode.
Performance:	The conflict resolution is performed by the user, so there is no time restrictions on performing the resolutions.
Testing Requirements:	If the user does not resolve the conflicts, or produces new conflicts, then the check-in should still fail.

Exceptions:

None determined at this time

5.6.2 Check-Out Project/Model

The Client application can download Projects and Models from the Server.
 

Abbreviation:	CHECKOUT
Pre-Condition(s):	The user has logged in to a Server
Post-Condition(s):	The selected Project or Model is transferred to the Client
Business Rules:	No business rules apply.
Input(s):	The name of the Model or Project to be checked out Whether any locking should be performed The version of the file to check out.
Output(s):	The selected file is written to Local Disk.
Processing:	The user will select the Project or Model to check out from a list of those available from the Server. The selected Model or Project is then transferred to the Client. If a Project is selected, all the Models within the Project are also transferred.
Control/UI/Reports:	A dialog is needed to allow the selection of the available Projects and Models.
Quality Aspects:	The dialog should provide information on the possible versions, and possible a preview option.
Performance:	The time taken is dependant on the speed of the connecting network, the size of the selected items and the load on the Server.
Testing Requirements:	If there is a file in the way (another file with the same name), then it should be overwritten.

Exceptions:	Type:	IOException
	Causes:	Server is not running  The Server has an error  The user is not logged in
	Handling Performed:	The check-in is aborted.  The Client returns to the state before the checking was started  The Server returns to the state of before the checking was started.