Documentation Documentation Home BKernel Javadoc Documentation (No Frames) Cohesion - Client User Guide Cohesion - Administration Manual Configuration Management CVS Documentation Debug Package Documentation Demerit Point Scheme Management Procedures Package Description Project Plans and Procedures Samba Software Design Spec. Software Requirements Spec. Syndicate User Manual Technical Style Standards Web Document Style Standards Work Log & Weekly Plan Proc. WWW Document Template   Table of Contents Executive Summary 1.   Introduction 1.1  Document Purpose 1.2  Project Scope 1.3  Definitions, Acronyms, and Abbreviations 1.4  Document Overview 1.5  Applicable Documents 2.   Development Process Perspective 2.1  Methodology 2.2  Software Process 2.3  Core Functionality 3.   Product Characteristics 3.1 Functions 3.2 Performance 3.3 Interfaces 3.3.1 Mouse 3.3.2 Keyboard 3.3.3 Screen 3.3.4 Printer 4. User Characteristics 4.1 The General User 4.2 The Software Designer 4.3 The Quality Engineer 4.4 The Administrator 4.5 The Client 5. Functional Requirements 5.1  CRUD Project 5.2  CRUD Workspace 5.3  CRUD Model 5.4  CRUD Meta-Model 5.5  CRUD Package 5.6  File IO 5.7  Communications 5.8  Administration 5.9  Online Help 6. Interface Requirements 6.1 Supported Display Modes 6.2 Supported Devices 7. System Diagnostics 7.1 Level of Diagnostics 7.2 General Reporting Formats 7.3 Diagnostic Utility Software 8. Verification Requirements 9. General Constraints 9.1 Assumptions and Dependencies 10. System Requirements 10.1 Client Computer 10.2 Server Computer Appendix A : External Context Diagram Appendix B : Internal Context Diagram Appendix C : Use Cases Appendix D : Hierarchical User Interface Decomposition

Pages 1 - 2 - 3 - 4 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.  5.6.4 Export as Image File 5.6.4.1 Define Region to Export The user can select the whole Model, or a subset of the Model to Export   Abbreviation: SELREGION  Pre-Condition(s): The user is Exporting an image Post-Condition(s): The user has selected a region of the Model that they wish to Export and the scale to Export to which they wish to Export it. Business Rules: No business rules apply. Input(s): The Model being Exported Output(s): The region of the Model and the scale factor. The user can cancel the operation Processing: The Model is rendered in the preview window, so the user can specify a selection Control/UI/Reports: A preview can be shown to allow selection of greater that one screen full. The user selects the region using a rubber box.  Quality Aspects: If the Model is larger than the screen, the user should still be able to select the entire Model. Performance: This operation is performed by the user and so there is no time limit. Testing Requirements: Models larger than the screen, and with no elements must scale properly to allow selection of a portion, or the whole Model 5.6.4.2 Export to File Once the user has selected a region, the image is saved to file   Abbreviation: EXPORTIMG Pre-Condition(s): The user has write access to the selected destination.  The user has selected a Model Post-Condition(s): A graphic representation of the Model is written to a file.  Business Rules: No business rules apply. Input(s): The Model to render The region to Export The scale of the image The file format to use The file name to use Output(s): A file containing a graphic representation of the Model. Processing: First the user can select a region of the image to Export. They are then prompted for a file name and the file is written.  The image is then rendered at the appropriate scale and written to file.  Control/UI/Reports: A Dialog allows the file format, output file name to be specified. A progress bar can show the progress. This can be integrated with the preview dialog of SELREGION Quality Aspects: The image must comply with the image format selected.  Performance: The time taken depends of the size of the image, the selected scale and the complexity of the file format. This operation should take less than 10 seconds Testing Requirements: The output has to conform to standard file formats, and be able to be opened by other applications, such as Paint Shop Pro. Exceptions: Type: IOException Causes: The user does not have write access to the file  Out of memory  Handling Performed: The user is notified of the problem  The Export is aborted  5.6.5 Print Hardcopy The user is able to print the selected Model to produce a hard copy. 5.6.5.1 Define Region to Print The user can select the whole Model, or a subset of the Model to print   Abbreviation: SELREGION  Pre-Condition(s): The user is printing an image Post-Condition(s): The user has selected a region of the Model that they wish to Export and the scale to Export it at Business Rules: No business rules apply. Input(s): The region of the Model and the scale factor. The user can cancel at any time  Output(s): The region of the Model and the scale factor. The user can cancel the operation Processing: The Model is rendered in the preview window, so the user can specify a selection Control/UI/Reports: A preview can be shown to allow selection of greater that one screen full. The user selects the region using a rubber box.  Quality Aspects: If the Model is larger than the screen, the user should still be able to select the entire Model. Performance: This operation is performed by the user and so there is no time limit.  Testing Requirements: Models larger than the screen, and with no elements must scale properly to allow selection of a portion, or the whole Model Exceptions: none yet determined. 5.6.5.2 Print Image Once the user has selected a region, the Model is printed.   Abbreviation: PRINT Pre-Condition(s): The user has a printer connected The selected printer is functioning correctly  The user has selected a Model Post-Condition(s): A hard copy of the Model is generated  Business Rules: No business rules apply. Input(s): The region to print The scale to use The printer to print to Output(s): A hardcopy of the selected Model Processing: The Model is rendered to the printer. This may require system specific code.  Control/UI/Reports: A progress bar can show the progress. This can be integrated with the preview dialog of SELREGION The Model to print is selected from the workspace tree Quality Aspects: The hard copy should retain the same format of the on screen Model.  Performance: The time taken depends of the size of the image, the selected scale and the speed of the printer.  Testing Requirements: This has to work on different printers.  Java's printer support is buggy, so correct output may not be possible Exceptions: Type: IOException Causes: The printer is not functioning correctly  The printer is out of paper  Out of memory  Handling Performed: The user is notified of the problem  The print is aborted  The state of the printer may be undefined.  5.6.6 Export as Source Stubs A Class Diagram should have a close mapping to the code of an Object-Oriented implementation'the speed initial development, the information present in the diagram can be used to generate source code which implements the designated functionality.   Abbreviation: EXPRTSRC  Pre-Condition(s): The user has selected a Model in the workspace tree The selected Model uses a meta-Model which can be Exported Post-Condition(s): A number of .java files are written to Disk  Business Rules: No business rules apply. Input(s): The destination directory Naming options  meta-Model specific options Output(s): A number of java stubs If there are problems, possible resolutions can be suggested (modification of the diagram to better support the java language)  Processing: The information contained in the class diagram will be used to generate skeleton java 1.2 source code.  This will be code stubs and not guaranteed to compile.  The code will be formatted to the Synergy code style guide. Control/UI/Reports: A progress dialog will show progress and a message on completion. Quality Aspects: The code will be correct java 1.2 source code. It may however be incomplete and will require modification before it can be compiled.  Testing Requirements: Class diagrams should produce java classes, with associations, aggregations and inheritance supported Exceptions: Type: ExportException Causes: The Model does not use an Exportable meta-Model  The Model contains elements which can not be Exported  The user does not have write permission for the selected directory  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.   Any already Exported files are left on the Disk  5.6.7 Import Model From JMetric This creates a new Class Diagram based on the output from JMetric.   Abbreviation: Import  Input(s): As per JMetric Export interface. A Project to put the new Model in Pre-Condition(s): The user has selected a Project JMetric is installed and functioning correctly Post-Condition(s): A new Model is created containing a class diagram of an existing Java program. Business Rules: No business rules apply. Processing: The required information will be sourced from JMetric. An AI algorithm can be used to assign an initial layout for the diagram. Output(s): A new class Model. Control/UI/Reports: A progress dialog may be supported. There may also be options regarding the Import of the data. Quality Aspects: This module can only use the information made available by JMetric. This may result in a poor diagram. Performance: This could be a time consuming process.  An estimation is between 1 and 5 minutes. Testing Requirements: Any sample Imports provided with either JMetric or Cohesion should work correctly. Exceptions: Type: ImportException Causes: JMetric is not working correctly  A required meta-Model can't be found  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.   No new Model is created      5.7 Communications 5.7.1 Logging in to Server Login to the Server as a specified user, establishing a unique session.   Abbreviation: LOGIN  PreCondition(s): Client machine is connected to a network A Server is running on that network. PostCondition(s): A unique session is established between the user's Client computer and the Server. Business Rules: No business rules apply. Input(s): Server: The name of the Server to log into username: The user to log in as  password: The corresponding password  Output(s): When authentication fails, the user is notified, or Notification of successful login Processing: The available Servers are identified and listed. The required one is passed into the function and a session created. The Server will find the specified user, if it exists, in the user manager and compare the passwords from the existing user and the supplied parameter. The result of the authentication are then shipped back to the Client, along with any relevant messages. If the login is successful, a session is set up between the Client and the Server. When the Client receives confirmation of the authentication is stores the details locally for later reference.  Control/UI/Reports: If the authentication fails, the session is closed on the Server and the Client is notified. Quality Aspects: Usability: Identification of active Servers on the network in a drop down list. Performance: Depends on network performance after Local information has been processed. Low use of system resources. Testing Requirements: Need to make sure can't perform network-related operations without first successfully logging in. Exceptions: Type: Broken Socket Causes: physical network error.  Handling Performed: user is notified and instructed how to deal with it (ie. Try and log in again).   5.7.2 Logging Out From Server Logout from the Server upon completion of a session.   Abbreviation: LOGOUT  PreCondition(s): Client machine is connected to a network The relevant Server is still running User was logged in PostCondition(s): A unique session is closed between the user and the Server Business Rules: No business rules apply. Input(s): A request to logout from the current session Output(s): Notification of a successful logout Processing: A message is passed to the Server, to close the current session between the Client and Server.  The Server then closes the session and notifies the Client. Control/UI/Reports: Upon successful logout, a dialog will display a message notifying the user. Quality Aspects: Usability: no issues Performance: Depends on network performance after Local information has been processed. Low use of system resources. Testing Requirements: Make sure the connection has been effectively closed, and the user has been removed as a logged user on the Server. Exceptions: Type: Broken Socket Causes: physical network error.  Handling Performed: user is notified and instructed how to deal with it (ie. Try and log out again).   5.7.3 Send SMTP Message Users can send e-mail messages to colleagues or parties of interest.   Abbreviation: SMTP  Pre-Condition(s): User must be logged on; Case tool Client must be connected to a Server User must have permission to send an e-mail message.  Post-Condition(s): Message is sent via SMTP. Business Rules: No business rules apply. Input(s): Message, Subject, and Receivers.  Processing: Sends message details to Server, where the details are converted to SMTP and sent using the SMTP module.  Output(s): A message sent to the designated receiver's. Control/UI/Reports: Dialog for entering message information, including access to a separate Address Book dialog to access Address Book entries for obtaining receivers of a message. Relevant error messages will be displayed to the user if an exception occurs.  Quality Aspects: Usability: intuitive access to Address Book from message dialog. Performance: The issue of speed over the network is not overly Important for this feature, although typically you would expect an e-mail message to take a limited amount of network resources and processing time to complete. This operation will not use an excessive amount of Local system resources. Testing Requirements: Needs to provide the data for the message to the Server in a format compatible to send via SMTP. Message must be sent accurately (no loss of data, and received by designated receivers), should not attempt to send if no receiver's listed.  Exceptions: Type: Broken socket connection to Server; not logged on (should not get to this stage if not logged on); no receivers listed for the message; inadequate permissions for sending an e-mail Causes: physical network error.  Insufficient information provided by user.  Handling Performed: user is notified of the relevant problem and instructed how to deal with it.  5.7.3.1 Select Receiver from Address Book When preparing an e-mail to send, users can select receivers of the message from either the Local or Server Address Book.   Abbreviation: SRAB  Pre-Condition(s): User must be logged on; Case tool Client must be connected to the Server; Address Book must be opened from a Cohesion e-mail dialog.  Post-Condition(s): Selected receivers are placed in the 'To' field of the e-mail dialog.  Business Rules: No business rules apply. Input(s): One or more Address Book entries Processing: When the user selects the 'To' button on the e-mail dialog, an Address Book dialog will be displayed. The user will select entries in the Address Book that they wish to send the message to. Output(s): Selected receivers are placed in the 'To' field of the e-mail dialog.  Control/UI/Reports: The Address Book Dialog containing the Address Book entries from the Server Address Book and the user's Local address book.  Quality Aspects: Usability: easy to select desired receivers (intuitive) Performance: This operation will not use an excessive amount of Local system resources. Testing Requirements: Address Book entries must be displayed according to those listed in the Local and Server Address Books. Selected Address Book entries must be placed in the 'To:' field of the message dialog. Exceptions: Type: Broken socket; not logged on (should not get to this stage if not logged on). Causes: physical network error.  Handling Performed: user is notified of the relevant problem and instructed how  to deal with it.  5.7.4 Display Address Book Entries. The Address Book must be able to retrieve Address Book entries from the Server and from a user's Local Address Book.   Abbreviation: AB DISPLAY  Input(s): Address Book entries from Server and Local Address Books. Pre-Condition(s): The User must be logged on Post-Condition(s): Address Book dialog is displayed with retrieved address entries; Address Book entries are stored locally on the Client's machine.  Business Rules: No business rules apply. Processing: Retrieve both Server and Client Address Books (if they exist), from the Server and the Local file system respectively. Display these entries in the Address Book dialog.  Output(s): A collection of Address Book entries displayed in the Address Book GUI.  Control/UI/Reports: An Address Book dialog will be displayed, containing all address entries from the Client and Server Address Books.  Quality Aspects: Usability: intuitive layout of Address Book entries. Performance: The toll on the network should be minimal when retrieving the Server Address Book. Minimal Local system resources will be used when retrieving the Local Address Book. Testing Requirements: All Local Address Book entries must be displayed accurately All Server Address Book entries must be displayed accurately Exceptions: Type: No Address Book exists; not connected to Server; Not logged on (should not get to this stage if not logged on); User not authenticated on Server. Causes: physical network error.  No address bok has been created locally  No Address Book has been created on the Server  Handling Performed: user is notified of the relevant problem and instructed how to deal with  5.7.5 Send Direct Internal Message Users can send messages to other logged on users, either by specifically stating the user/s that the message is intended for, or by broadcasting the message to all logged on users of the system.   Abbreviation: SEND DIRECT  Input(s): Message, Receivers.  Pre-Condition(s): User must be logged on; Case tool Client must be connected to the Server; User must have permission to send a direct message.  Post-Condition(s): Message sent to the specified users via the Server.  Business Rules: No business rules apply. Processing: Sends message details to Server, where the details are sent to the relevant users, if they are logged onto the system.  Output(s): A message sent to the user (if they are currently logged on).  Control/UI/Reports: A dialog will be available for users to enter in direct messages; A list of logged on users will be available for the user to send the message to.  Quality Aspects: Usability: Easy to select receivers from a list of currently logged on users Performance: The issue of speed over the network is not overly Important for this feature, although typically you would expect a direct message to use a minimal amount of network resources and processing time to complete (logged on user's should receive the message within a few seconds). This operation will not use an excessive amount of Local system resources. Testing Requirements: Message must be sent accurately (no loss of data, received by designated receivers); Should not attempt to send if no receiver's listed.  Exceptions: Type: Broken socket connection to Server; not logged on (should not get to this stage if not logged on); User must provide at least one receiver for the message; not permitted to send a direct message.  Causes: physical network error.  Insufficient information provided by the user.  Handling Performed: user is notified of the relevant problem and instructed how to deal with  5.7.5.1 Select Logged on Users to Receive Direct Message When sending direct messages to other users, a Cohesion user can select a user to send to from a list of users that are currently logged on'the user can also choose to broadcast the message to all logged on users on the Cohesion Server.   Abbreviation: SLOU  Input(s): Users to send direct message to.  Pre-Condition(s): User must be logged on; Case tool Client must be connected to the Server; User must have permission to send a direct message.  Post-Condition(s): User/s selected for receiving the direct message.  Business Rules: No business rules apply. Processing: The user will click on the desired receivers of the direct message, which will then be listed above the subject heading of the direct message.  Output(s): The selected receivers will be listed above the subject heading of the direct message.  Control/UI/Reports: A dialog will display all logged on users that can receive a direct message.  Quality Aspects: The list of the logged on users must be consistent with the current state of the system.  Performance: This operation will take a minimal toll on system resources. Testing Requirements: The list of logged on users must be consistent with the current state of the system Selected user's must be placed in the 'To:' field of the direct message dialog Exceptions: Type: Not connected to Server, not logged on (should not get to this stage if not logged on); not permitted to send a direct message. Causes: physical network error.  Handling Performed: user is notified of the relevant problem and instructed how to deal with  5.7.5.2 Select Message to Reply To For any given session on Cohesion, any direct messages received by a user will be stored, and the user can select any of these messages to reply to.   Abbreviation: SMTR  Input(s): History of direct messages from the current session. Pre-Condition(s): User must be logged on; Case tool Client must be connected to the Server; At least one stored message must reside on the user's machine for the session.  Post-Condition(s): A message will be selected for reply.  Business Rules: No business rules apply. Processing: The user will select the message they wish to reply to by clicking on it from a 'history' of messages received during their current session on Cohesion.  Output(s): The selected message to reply to. Control/UI/Reports: A dialog containing the message history for the current session.  A dialog containing the rect message to reply to. Quality Aspects: Usability: ordered list of all direct messages received during a Cohesion session. Performance: This operation will take a minimal toll on system resources. Testing Requirements: All messages received during the current session must be listed and available for reply. Messages selected for reply must be displayed accurately in a direct message dialog. Exceptions: Not determined as of yet. 5.7.5.3 Reply To a Direct Message For any given session on Cohesion, any direct messages received by a user can be replied to.   Abbreviation: RTDM  Input(s): The reply message.  Pre-Condition(s): User must be logged on; Case tool Client must be connected to the Server; User must have permission to send a direct message; At least one stored message must reside on the user's machine for the session.  Post-Condition(s): The message will be sent back to the original sender (and any extra listed recipients). Business Rules: No business rules apply. Processing: The user will select the message they wish to reply to, and a dialog will be displayed to enter in the reply-message details. Once finished they will choose to send the message, and the message will be sent to the user via the Server.  Output(s): Message sent to the Server for distribution to the recipients.  Control/UI/Reports: A dialog for entering the reply information.  Quality Aspects: Usability: Easy to select additional recipients from a list of currently logged on users Performance: A user would typically expect a direct message to take a limited amount of network resources and to be received by the specified users (who are logged on) within seconds of sending the message. This operation will take a minimal toll on Local system resources. Testing Requirements: Message must be sent accurately (no loss of data, received by designated receivers) Should not attempt to send if no receiver's listed.  Exceptions: Type: Not connected to Server, not logged on (should not get to this stage if not logged on); User must provide at least one receiver for the message; not permitted to send a direct message. Causes: physical network error.  insufficient information provided by the user.  Handling Performed: user is notified of the relevant problem and instructed how to deal with  5.7.6 Set Mail Preferences A user can customise the way their mail is handled by the system.   Abbreviation: SMPR Input(s): Preferences for the current user.  Pre-Condition(s): User must be logged on; Case tool Client must be connected to the Server; User must have permission to send messages.  Post-Condition(s): The user preferences may have changed.  Business Rules: No business rules apply. Processing: The user will open a dialog for setting mail preferences such as 'reply address', 'outgoing mail Server', notification level', and 'disable message receive'. Once changed, these preferences will be stored on the Client.  Output(s): Notification if the operation failed. Control/UI/Reports: A dialog displaying the user's mail preferences.  Quality Aspects: Usability: no issues. Performance: This operation will take a minimal toll on system resources. Testing Requirements: Are the preferences saved correctly? Does the system adhere to these preferences in relevant situations? Exceptions: Type: IOException Causes: The file containing mail preferences data is corrupt  The user does not have read access to the file  Handling Performed: The user is notified of the problem   A new mail preferences file may be created.  5.7.7 Store Address Book Entry The Address Book must be able to store Address Book entries in a file on the Server and in a user's Local Address Book (on their Local file system)   Abbreviation: AB STORE  Input(s): Address Book Entry (Name, e-mail address, user name).  Pre-Condition(s): User must be logged on to modify the Server Address Book; Post-Condition(s): Name of Address Book entry cannot already exist; Entry must contain one of either an e-mail address (for SMTP messaging) entry or a User Name entry (for direct messaging).  Business Rules: No business rules apply. Processing: The user enters Address Book entry details and then elects to add it to an Address Book.  If it is specified as a Local Address Book entry,  the entry will be stored  locally; otherwise, passes data across Server to be stored on the Server Address Book. Output(s): Notification if the operation failed. Control/UI/Reports: The Address Book details are displayed in a dialog. New entries are added via this dialog; Another dialog to display the reason a new entry was not saved. Quality Aspects: Usability: no issues. Performance: The toll on the network will be minimal (very little data is contained in an Address Book entry).   Same applies to the Client system. Testing Requirements: Make sure all details from a recently added Address Book entry have been stored correctly.  Exceptions: Type: Address Book entry no longer exists; An Address Book entry with the same name already exists; Not connected to Server; Inappropriate permission's to modify global Address Book; Not logged on (should not get to this stage if not logged on); No address or name information for the new Address Book entry. Causes: The Address Book may have been deleted   Insufficient information provided by the user.   Physical network error  Handling Performed: A new Address Book will be created on the fly   User is notified of the relevant problem and instructed how to deal with it.  5.7.8 Modify Address Book Address Book entries will be able to be modified or deleted on the Server and a user's Local Address Book.   Abbreviation: AB MODIFY  Pre-Condition(s): User must be logged on to modify the Server Address Book Post-Condition(s): Name of Address Book entry cannot already exist; Entry must contain one of either an e-mail address (for SMTP messaging) entry or a User Name entry (for direct messaging).  Business Rules: No business rules apply. Input(s): Modified Address Book entry (modified name, e-mail address, and/or user name).  Processing: If Client Address Book, store modified address entry locally; otherwise, pass data across Server to be stored there.  Output(s): Notification if the operation failed. Control/UI/Reports: An Address Book Dialog to provide ability to modify existing Address Book entries; A dialog displaying why an Address Book entry was not modified.  Quality Aspects: Usability: no issues. Performance: The toll on the network will be minimal (very little data is contained in an Address Book entry).  Same applies to the Client system. Testing Requirements: Make sure entries are being modified successfully. Exceptions: Type: Address Book entry no longer exists; Inappropriate permission's for modify global Address Book; Not connected to Server; Not logged on (should not get to this stage if not logged on); name and/or address details not entered. Causes: Physical network error  Handling Performed: New Address Book created on the fly.  Insufficient information provided by user.  5.7.9 Receive Direct Message Messages will be received by those currently-connected users as specified by the user sending the message.   Abbreviation: RDIM  Pre-Condition(s): User must be logged on to a Cohesion Server. Post-Condition(s): Notification of a received message on the receiver's workspace, either with a subtle sound, or by displaying of a dialog containing the sent message details.  Business Rules: No business rules apply. Input(s): The received message. Processing: A direct message is transported via the Server from the sender's Client to the receiver's Client, and the receiver is notified of the message's arrival. Output(s): Depending on the settings of the user's mail preferences, upon receiving a direct message, either a sound will be invoked, or a dialog will be displayed with the message contents (or both).  Control/UI/Reports: The message dialog will display the contents of a message. Quality Aspects: Usability: Easy access of the newly received message. Performance: The toll on the network will be minimal (very little data is contained in an Address Book entry).  Same applies to the Client system. Testing Requirements: The message contents must be the same as those originally sent. The message must be sent to all appropriate connected users that were specified as receivers in the message. Exceptions: Type: Not connected to Server; corrupted message Causes: Physical network error      5.8 Administration   5.8.1 Assign permissions to individual/group level read/write access to Project/Models The security settings on Projects and Models stored on the server can all be modified from the client.   Abbreviation: SETPERM  Pre-Condition(s): The current user is logged in to the server and has permission to change the permissions of the given Project or Model Post-Condition(s): The security settings are updated on the server.  Business Rules: No business rules apply. Input(s): The name of a user or group A Project or Model The level of access desired Output(s): The updated Model or Project Processing: Checks to make sure the preconditions are met. If they are then the user is presented with a dialog with all the available options. The new settings are retrieved from the dialog if the user has accepted the changes and assigned to the Model or Project. The Model or Project is then sent to the server to be updated. Control/UI/Reports: One dialog should provide access to all the security settings. Drag and drop would provide an easy to use interface for adding and removing users. Any errors will be displayed in a Dialog. Quality Aspects: Security code must be robust and not allow any kind of unauthorised access. All security settings set must be immediately reflect throughout all clients currently logged onto the system. Performance: The performance is dependant on the speed of the connected network and the load on the server. Given this however, the speed by which all other currently logged in users that are affected by the change must take no more than thirty seconds. Testing Requirements: Make sure the new security settings meet the performance requirements above. Make sure that the new security settings are enforced by all clients existing and newly connected. Exceptions: Type:   SecurityException Causes: The user trying to make the changes doesn't have the required permissions  Handling Performed: When the user doesn't have the required permissions to make the modifications, a dialog will be displayed indicating this and any follow up action recommended.  Type: NetworkException Causes: The server application has gone down  The network itself has gone down  Handling Performed: The user is notified of the network problem and any possible solutions are suggested  5.8.2 Create Users and Groups 5.8.2.1 Create/Edit/View User Provides access to the fields and properties of a new or existing user   Abbreviation: CVEDITUSER  PreCondition(s): The user to display already exists unless creating a new user PostCondition(s): Any changes to the user or group is returned to the appropriate module Business Rules: No business rules apply. Input(s): The user to view/edit unless creating a new one The edit state (whether viewing, editing or setting the privileges of the user) Output(s): The updated or newly created user, if any. Processing: This takes a user and displays their details. If the edit flag has been set then the user may update the details or enter them initially and the Choose group function will be used to select the group. When the user submits the changes the updated user is sent to the module to be updated on the server. Control/UI/Reports: The panel displaying all the fields respective to all the details of users. Any errors or problems will be displayed in a dialog. Quality Aspects: The details updated must be reflected in the user after it is saved. Performance: The performance of this module is entirely dependent on the modules it communicates with. Displaying the details of the user or group should be instantaneous from the instant it receives the user to display. Testing Requirements: The values entered by the user must be the same as those placed in the updated user object and passed to the relevant module. The details displayed must reflect the content of the user or group it is displaying. Exceptions: none determined as yet 5.8.2.1.1 Add User Add a new user to the server.   Abbreviation: ADDUSER  PreCondition(s): The user adding is already logged into the server  User to add not already in system  User adding is an administrator  PostCondition(s): User is stored in the user database on the server. Business Rules: No business rules apply. Input(s): Not yet determined. Output(s): The new user is sent to the server Notification that the user has been added  Notification that the user has not been added  Processing: Accepts the details of the new user and checks to see if this user is not already in the system. If ok and the user attempting to add is an Administrator, create a new user using function 5.16.1 and add it to the user manager on the server. The user manager should store this on the server. Notification of the success of this operation is then sent back to the client.  Control/UI/Reports: If the new user cannot be added for some reason, as indicated by the notification from the server, the client will notify the user giving details regarding why and how to avoid the problem in future.  Quality Aspects: Only administrative users are allowed to perform this function. Need to make sure one one else can  Performance: The performance of the process should degrade gracefully with the number of users currently logged onto the same server.  Testing Requirements: Make sure whoever is performing the function has been authenticated and has the appropriate privileges. All other forms need to be tested to ensure this is the case. The new user must be on the server and all the details reflect the details entered. Exceptions: Type: NetworkException Causes: The server application has stopped The network has gone down  Handling Performed: The user is notified by a dialog indicating what went wrong and any possible solutions to fix the problem.  Type: SecurityException Causes: The user doesn't have permission to create new users  Handling Performed: The user doesn't have the required permissions to create a user in the system.  5.8.2.1.2 Edit User Change the properties of an existing user.   Abbreviation: EDITUSER  PreCondition(s): The user adding is already logged into the server.  User to edit already in system.  User editing is an administrator.  PostCondition(s): Updated user is saved on the server.  Business Rules: No business rules apply. Input(s): The user to edit Output(s): The updated user is sent to the server Notification that the user has been edited.  Notification that the user has not been edited.  Processing: Takes the user to update and sends it with the edit flag set. Accepts the details of the updated user and looks in the user's old username field to find them in the system. If the user cannot be found, a response indicating such is sent back to the client. Otherwise, the users detailed are updated to reflect those submitted and saved on the server.  Control/UI/Reports: If the new user cannot be updated for some reason, as indicated by the notification from the server, the client will notify the user via a dialog giving details regarding why and how to avoid the problem in future.  Quality Aspects: Only administrative users are allowed to perform this function. Need to make sure one one else can.  Performance: The performance of the process should degrade gracefully with the number of users currently logged onto the same server.  Testing Requirements: Make sure whoever is performing the function has been authenticated and has the appropriate privileges. All other forms need to be tested to ensure this is the case. Test for editting conflicts (two people editting the same user at the same time) Exceptions: Type: NetworkException Causes: The server application has stopped  The network has gone down  Handling Performed: The user is notified by a dialog indicating what went wrong and any possible solutions to fix the problem. Type: SecurityException Causes: The user doesn't have permission to edit the user  Handling Performed: The user doesn't have the required permissions to edit a user in the system. 5.8.2.1.3 Remove User Remove an existing user from the system.   Abbreviation: DELUSER  PreCondition(s): The user adding is already logged into the server  User to remove is already in system  User removing is an administrator  PostCondition(s): Removed user is removed from the server.  Business Rules: No business rules apply. Input(s): User Name: The name of the user to remove (must be unique) Output(s): Notification that the user has been removed.  Notification that the user has not been removed.  Processing: Accepts the details of the user to remove and sends the request to the user manager on the server. If the user cannot be found, a response indicating such is sent back to the client. Otherwise, the user is removed from the server and confirmation is sent back to the client.  Control/UI/Reports: If the new user cannot be removed for some reason, as indicated by the notification from the server, the client will notify the user giving details regarding why and how to avoid the problem in future.  Quality Aspects: Only administrative users are allowed to perform this function. Performance: The performance of the process should degrade gracefully with the number of users currently logged onto the same server.  Testing Requirements: Make sure whoever is performing the function has been authenticated and has the appropriate privileges. All other forms need to be tested to ensure this is the case.  Exceptions: Type: NetworkException Causes: The server application has stopped  The network has gone down  Handling Performed: The user is notified by a dialog indicating what went wrong and any possible solutions to fix the problem.  Type: SecurityException Causes: User doesn't have permission to edit the user  Handling Performed: The user doesn't have the required permissions to remove a user in the system.  5.8.2.2 Set User/Group Privileges Each user in the system has a certain privilage associated with them, this function allows this privilage to be set.   5.8.2.2.1 Choose User/Group Select the user to alter the privileges for.   Abbreviation: CHOOSEUSERG  Pre-Condition(s): User is logged in.  Post-Condition(s): User is logged in.  Business Rules: No business rules apply. Input(s): Indicate whether to select a user or a group Output(s): The selected user or group  Processing: Retrieves the list of existing users or groups which is displayed to the user graphically. The user may then select one of the users or groups from this list. Once the user indicates that this is their selection, most likely by clicking an ok or select button, the user or group selected is returned.  Control/UI/Reports: The user interface will most likely consist of a simple scrolling list of users and/or groups with a cancel and select or ok button. Any errors will come up in a separate dialog as necessary.  Quality Aspects: Need to ensure the updated user or group is stored on the server in a manner that is retrievable after the server and the client have been shut down and restarted.  Testing Requirements: Do boundary checking to ensure that it does not fail when there are no users to select from. Exceptions: Type: NetworkException Causes: The server application has stopped  The network has gone down  Handling Performed: The user is notified by a dialog indicating what went wrong and any possible solutions to fix the problem. 5.8.2.2.2 Assign Privileges to selected user or group Change the privilege of the selected user or group   Abbreviation: SETPRIVILEGE  Pre-Condition(s): User is logged in.  Post-Condition(s): User is logged in. Updated user or group is stored on the server.  Business Rules: No business rules apply. Input(s): The user or group to change  Output(s): The udpated user or group Processing: Takes the user or group to update and provides a graphical representation of the data using 5.16.1.2 The user may then use this interface to change the privilages to a predetermine value. Once the user has indicated that they are done, the updated user or group is stored on the server. In the event that the same item has been updated or removed by someone else during the time it was being editted, this is indicated and the current state of the details are updated to reflect the state of the item on the server.  Control/UI/Reports: Each of the fields of the user or group selected will be displayed and the list of available privilages that can be assigned is provided in a choice menu. There will be an ok and cancel button to allow the user to indicate when they are done.  Quality Aspects: Data must not be lost or corrupted when more than one user is editting the same item at the same time.  Performance: The propogation of the new security settings must take place within about thirty seconds to all currently logged in users. Testing Requirements: Must test for concurrent editting. Make sure the new privileges are effective immediately on all currently logged in users and newly logged in users. Exceptions: Type: NetworkException Causes: The server application has stopped  The network has gone down  Handling Performed: The user is notified by a dialog indicating what went wrong and any possible solutions to fix the problem.  Type: SecurityException Causes: User doesn't have permission to edit the user  Handling Performed: The user doesn't have the required permissions to remove a user in the system.  5.8.2.3 CRUD Groups Groups can be created, retrieved, updated and deleted in a similar manner to the users. One difference is that groups can be created at the Project and Model level as well as the server level. 5.8.2.3.1 Create/View/Edit group details The details of a group include the name of the group, the privilage and the users in the group.   Abbreviation: CVEDITUSER  PreCondition(s): The group to display already exists unless creating a new group PostCondition(s): Any changes to the group is returned to the appropriate module Business Rules: No business rules apply. Input(s): The group to view/edit unless creating a new one The edit state (whether viewing, editting or setting the privileges of the group) Output(s): The updated or newly created group, if any. Processing: This takes a group and displays their details. If the edit flag has been set then the user may update the details or enter them initially. When the user submits the changes the updated group is sent to the module to be updated on the server. Control/UI/Reports: The panel displaying all the fields respective to all the details of the group. Any errors or problems will be displayed in a dialog. Quality Aspects: The details updated must be reflected in the group after it is saved. Performance: The performance of this module is entirely dependent on the modules it communicates with. Displaying the details of the group should be instantaneous from the instant it receives the user to display. Testing Requirements: The values entered by the user must be the same as those placed in the updated group object and passed to the relevant module. The details displayed must reflect the content of the user or group it is displaying. Exceptions: none determined as yet 5.8.2.3.2 Add Group Add a new group to the server.   Abbreviation: CVEDITGROUP  Pre-Condition(s): User is logged in. Post-Condition(s): User is logged in. Business Rules: No business rules apply. Input(s): No perceived need. Output(s): New group  Processing: Enters the details of the new group. This will return the new group which can then be sent to the user manager on the server for storage. Control/UI/Reports: The only GUI components required will be dialogs indicating problems to the user and possible solutions. Quality Aspects: Data must not be lost or corrupted when more than one user is editting the same item at the same time. No two groups can have the same name.  Testing Requirements: Make sure the new group is stored permanently that is to say, you can shut down both the server and the client and the new state will be preserved across sessions.  Exceptions: Type: NetworkException Causes: The server application has stopped  The network has gone down  Handling Performed: The user is notified by a dialog indicating what went wrong and any possible solutions to fix the problem.  Type: SecurityException Causes: User doesn't have permission to create a group    Handling Performed: The user doesn't have the required permissions to create a group in the system.  5.8.2.3.3 Edit Group Change the properties of an existing group.   Abbreviation: EDITGROUP PreCondition(s): The user editting is already logged into the server.  Group  to edit already in system.  User editing is an administrator.  PostCondition(s): Updated group is saved on the server.  Business Rules: No business rules apply. Input(s): The group to edit Output(s): The updated group is sent to the server Notification that the group has been edited.  Notification that the group has not been edited.  Processing: Takes the group to update and sends it with the edit flag set. Accepts the details of the updated group and looks in the group's old name field to find them in the system. If the group cannot be found, a response indicating such is sent back to the client. Otherwise, the groups details are updated to reflect those submitted and saved on the server.  Control/UI/Reports: If the new group cannot be updated for some reason, as indicated by the notification from the server, the client will notify the user via a dialog giving details regarding why and how to avoid the problem in future.  Quality Aspects: Only administrative users are allowed to perform this function. Performance: The performance of the process should degrade gracefully with the number of users currently logged onto the same server.  Testing Requirements: Make sure whoever is performing the function has been authenticated and has the appropriate privileges. All other forms need to be tested to ensure this is the case. Test for editting conflicts (two people editting the same group at the same time) Exceptions: Type: NetworkException Causes: The server application has stopped  The network has gone down  Handling Performed: The user is notified by a dialog indicating what went wrong and any possible solutions to fix the problem.  Type: SecurityException Causes: The user doesn't have permission to edit the group  Handling Performed: The user doesn't have the required permissions to edit a group in the system.  5.8.2.3.4 Remove Group Remove an existing group from the system.   Abbreviation: DELGROUP  PreCondition(s): The user adding is already logged into the server  User to remove is already in system  User removing is an administrator  PostCondition(s): Removed group is removed from the server.  Business Rules: No business rules apply. Input(s): Group Name: The name of the group to remove (must be unique) Output(s): Notification that the group has been removed.  Notification that the group has not been removed.  Processing: Accepts the details of the group to remove and sends the request to the user manager on the server. If the group cannot be found, a response indicating such is sent back to the client. Otherwise, the group is removed from the server and confirmation is sent back to the client.  Control/UI/Reports: If the group cannot be removed for some reason, as indicated by the notification from the server, the client will notify the user giving details regarding why and how to avoid the problem in future.  Quality Aspects: Only administrative users are allowed to perform this function. Performance: The performance of the process should degrade gracefully with the number of users currently logged onto the same server.  Testing Requirements: Make sure whoever is performing the function has been authenticated and has the appropriate privileges. All other forms need to be tested to ensure this is the case.  Exceptions: Type: NetworkException Causes: The server application has stopped  The network has gone down  Handling Performed: The user is notified by a dialog indicating what went wrong and any possible solutions to fix the problem.  Type: SecurityException Causes: User doesn't have permission to edit the group  Handling Performed: The user doesn't have the required permissions to remove a group in the system.  5.9 Online Help 5.9.1 Search Help Allows user to search help system.  User may select specific help file through contents, navigate the index where a list of every help item resides or search for a key word where a list of help items are generated.   Abbreviation: SEARCHHELP  PreCondition(s): Help module has been activated through menu option. Help search type has been selected ( Contents, Index, Find ).  PostCondition(s): Contents / Index – Help item found and selected in tree / list. Find – List of items generated and desired help item selected in list. Business Rules: No business rules apply. Input(s): Index – Search string isolating particular help item. Find – String or character which is to be searched throughout every registered help item.  Search type ( contains / similar to ) is also to be specified. Processing: Tree : Every time a node is selected its url is retrieved and stored.  If node does contain url, “Display” button is enabled. Index : When typing search string, a comparison is done on the current string with every string contained in the list.  The most compatible is selected in list.  Search through list is executed upon key pressed in text box. Find : When search is hit, the string residing in text box is retrieved.  A list of all items is retrieved.  Each item is opened and searched for search string according to the search type.  If the current item is found to contain the exact of similar string, it is added to our search list. Control/UI/Reports: Tabbed pane presented containing all help search facilities.  User is requied to select search, then input as required ( Expand tree, enter string for “Index” as well as “Find” including search type and hitting the search button ).  Once searches have completed, a list of all selectable items are presented in a scrollable list.  When user selects item and presses “Display” button, another form is presented displaying the html help page including history navigational buttons.  Quality Aspects: Any plugin may register their help at any time, during start-up or during run time and it will convieniently be added to the help system. Performance: This function should perform interactively. Performance will only degrade in respect to the search once the number of modules are loaded with the application.  Testing Requirements: Two main testable areas reside.  All items are registered in both “Contents” and “Index” tabs when loaded with plugin.  When search is conducted on “Find” tab, all items retrieved MUST contain the search word.  Therefore case scenarios could include loading a plugin and ensuring branch and items have been inserted correctly into their respective areas.  Second, conduct a search on a particular word, ensuring that all items retrieved contain that particular string.  Exceptions: No exceptions have been determined at this time. 5.9.2 Display Help Item Once searching for particular item has been complete, this allows user to display the help document in a view pane.   Abbreviation: DISPHELP  PreCondition(s): Help system has been opened. Search has taken place. Help item selected in either list or tree.  PostCondition(s): Correct html document is displayed in the created view pane. Business Rules: No business rules apply. Input(s): Particular help item requesting display. Output(s): View rendered to screen.  No storage is required and no output or information is passed onto any other part of the program other than the “Help Manager” which owns the view pane is notified of its existence. Processing: When “Display” is pressed, the url is obtained from the selected item.  This item is set in the specific view pane, which is displayed on screen.  Help item is then inserted into the current position of the history list poited to by the history index. Control/UI/Reports: View pane is displayed showing selected url document.  User is now able to select hyperlinks, go forward or back depending on amount of items viewed.  Quality Aspects: Any plugin may register their help at any time, during start-up or during run time and it will convieniently be added to the help system. Performance: Depending on speed of computing, if view pane is not visible, can take up to one second for HTML to be displayed.  Some times mouse clicks or button hits aren’t registered, so actions might have to be performed twice.  Testing Requirements: When display hit, it is important for the correct document to be displayed.  Display of specific help items and comparisons to HTML document should take place to assess validating of HTML reading ability.  Exceptions: Type: MalformedURLException Causes: Attempt to set incorrect url in view pane  Url doesn’t exist  Handling Performed: Error html page displayed  User has option of navigating back through history buttons or selecting another item 5.9.3 Navigate Via Links When help items are displayed use may jump to related help items via the user of hyper links.   Abbreviation: NAVHYP  PreCondition(s): Help system has been opened. Search has taken place and item currently viewable in view pane. Documents contain hyperlinks.  PostCondition(s): View pane jumps to correct documents pointed to by hyperlink in previous document. Business Rules: No business rules apply. Input(s): Url, hyperlink points to. Output(s): HTML document displayed in view pane.  No storage is required and no output or information is passed onto any other part of the program other than the “Help Manager” which owns the view pane is notified and changes the current url being displayed Processing: Once hyperlink is activated, destined url is retrieved through the event created through the action.  “Help Manager” stores this url then tells the view pane to display the new url.  Help item is then inserted into the current position of the history list poited to by the history index. Control/UI/Reports: View pane remains open.  “Back” and “Forward” buttons enable / disable depending on the position we have within the history list.  Quality Aspects: View panes is capable of displaying and handling all versions of HTML, up to and include version 4.0. Performance: Depending on speed of computing, mouse clicks may not registered, so actions might have to be performed twice.  Testing Requirements: Every time a hyperlink is activated, url displayed must be correct.  Exceptions: Type: IOException Causes: Page is set to a null or invalid url  Handling Performed: Error html page displayed User has option of navigating back through history buttons or selecting another item 5.9.4 Navigate History Once a user has visited a number of pages, they then have the choice of navigating through the history list via use of the “Back” and “Forward” buttons placed on top of the view pane.   Abbreviation: NAVHISTORY  PreCondition(s): Help system has been opened. Search has taken place and item currently viewable in view pane. Mulitple pages have been visited during the existence of the view pane.  PostCondition(s): View pane jumps to correct documents in the correct order visited by user. Business Rules: No business rules apply. Input(s): Previous or next help item contained in history list. Output(s): HTML document displayed in view pane.  No storage is required and no output or information is passed onto any other part of the program other than the “Help Manager” which owns the view pane is notified and changes the current url being displayed Processing: When back / forward button pressed in view pane,  current index in history list is decremented / incremented.  The item then pointed to by the index is displayed. Control/UI/Reports: View pane remains open.  “Back” and “Forward” buttons enable / disable depending on the position we have within the history list.  Quality Aspects: Any url visited by the view pane is inserted into the history list.  Pages displayed from use of history navigation are not re-inserted into the list, therefore maintaining correct order. Performance: Depending on speed of computer, button hits may not register, so actions might have to be performed twice.  Testing Requirements: Testing to be performed should be to open a list of pages.  Once completed, navigate via “Back” / “Forward” buttons.  Comparisons should be made between pages displayed and the order of those visited.  Exceptions: No exceptions have been determined at this time.