|
|
|---|---|
|
|
|
Version 1.0 Edition 1
Revision History
Table Of Contents The objectives of this document are to provide a basis for the implementation of the following:
The major software functions provided by the system are:
The Project Plan was used extensively throughout the creation of this document. The product was developed according to these plans and procedures. The Project Plan details the crucial aspects of the development process. More specifically it outlines the initial system development plan, configuration management plan and procedures, development support environment, verification and validation, testing plan, quality assurance process plan, documentation plan, delivery plan, distribution plan and marketing plan. 2.1.2 SRS - Software Requirement Specification The Software
Requirements Specification details the functional and performance requirements
for the computer software to be developed by Team Synergy.
It is intended to supply sufficient software requirement information to
the Client to establish a solid foundation for subsequent software assessment
and approval. The SRS provides an excellent starting block for the Software
Design Specification. All elements outlined in this document are extensions
to those functional requirements outlined in the SRS.
All network data transfers (client to server, server to client) are encrypted by the sender and decrypted by the reciever on the fly (real-time). To enhance system customisation, any type of encryption can be plugged into Cohesion, for that matter, any kind of filtering device on the Network Layer can be plugged into Cohesion. This allows administrators of the system to upgrade / downgrade network security as desired. However, all machines on the network must be running the same network security plugins. Passwords are protected using standard UNIX one-way password encryption. There have been a number
of industry conventions implemented in the development of the product's
GUI. Most were based on the conventions set by Microsoft Windows. The menu
set has such conventional features as cut, copy, paste, undo, redo, help
/ about, and the commonly associated shortcut key combinations (ctrl-z,
ctrl-x, ctrl-c, ctrl-v, F1, etc).
All errors outside of the
oprerating system throw custom exceptions. These exceptions are all handled
gracefully by the software product and will not forceably or undesireably
terminate execution of the application. Exceptions, critical or otherwise,
are reported to the user via a combination of pop-up dialogs, status messages,
and messages displayed by the command prompt.
Team Synergy have
attempted to identify all possible security issues to a reasonable extent.
All identified security issues have been addressed. Wherever possible sensitive
data has been encrypted, and user access privileges are strictly adhered
to. All network connections are secure, with data encrypted / decrypted
on the fly (See section 3.1). There are two security
levels, user and administrator. While accounts with administrator privilages
can access all features of the system, user accounts have limited access
to such features as User Manager, remote commands, and versioning directory
structure modification.
Cohesion is based on a client/server architecture. The core of the architecture is the kernel which is responsible for loading plugins and dispatching command events. 4.1 Kernel/Plugin Architecture The kernel reads a configuration file specified on the command line. If no file is specified then the default modules.conf file is used. The configuration file specifies a list of plugins to load. Each plugin then registers itself with the kernel, so it can receive messages. Once all the plugins have been loaded the kernel sends out a boot event to all the registered plugins. Plugins can communicate with
each other by passing a command event to the kernel to be dispatched. The
kernel then forwards this event to all registered plugins. A plugin can
either process or ignore a dispatched event. The plugin can return information
to the originating plugin by calling the completion object for the specified
event.
4.2 Client/Server Architecture The architecture was designed specifically to support transparent client/server interaction. On the client side, the client plugin allows connection to a remote server using TCP/IP. Events can then be sent over the network to the remote kernel. Completion objects are also supported, so when the event has been processed, the completion object is executed on the client side. The server plugin allows many clients to connect to it. Events are received from the network and sent to the kernel. It is also possible to send events from the server to an individual client, or broadcast to all clients. The first event the client sends to the server is an authentication event. If the authentication fails the connection is immediately closed. There is no limit on the number of events which can be outstanding at any time. It is possible for each plugin
to register a filter which can modify the network stream to allow for services
such as encryption.
Address Book [au.edu.swin.synergy.plugin.addressbook] The Address Book plugin provides a GUI and management of the Address Book. The Address Book GUI provides the user interface to add/remove address book entries which contain the user name and email address. This user interface can be displayed through the Messaging menu option or from the To: button in the send message dialog. The Address Book Manager
provides the interface between the GUI and the Address Book and processes
the Create/Retrieve/Update/Delete operations. The client and server each
have an Address Book Manager however the Server Address Books entries are
global and can be seen by all the clients.
Other plugins used are:
The Broadcast Client plugin starts its own thread to communicate with the broadcast server. It collates a list of available servers on the local area network. A command line option is also available with this plugin. The input event handled by the Broadcast Client plugin is GetServers. There are no outputs or events dispatched by the Broadcast Client plugin. A list of unique servers is maintained. When a duplicate is detected, it is discarded. On the Broadcast Client startup/boot, a notification request is broadcast to the network. Any time that a server notification is received, the server is added to the list. This change is automatically reflected in any list on the GUI. Other plugins used are:
.gif) Broadcast Server [au.edu.swin.synergy.plugin.broadcastsvr] The Broadcast Server plugin starts its own thread to listen for broadcast requests from each of the clients. It responds after receiving the request. On startup it sends a broadcast message to all nodes on the local area network that it has been started. There are no inputs events handled and no outputs events dispatched by the broadcastsvr. On startup/boot, a notification is broadcasted to the network. Whenever a server request broadcast is detected, a responce is sent back to the originating machine. Other plugins used are:
.gif)
Client [au.edu.swin.synergy.plugin.client] The Client Side Network plugin is a client side event redirector. It waits for the client to make a request to the server, and then sends that request to the server. This module also handles logging in and logging out to the server, and also listens for events coming from the server and distributes the event to the other modules on the client side. The inputs or events handled by the client plugin are Login events, Logout events, and events which need to be sent to the server. The outputs or events dispatched by the client plugin are Login Complete and Logout Complete. The client also calls completion objects for events returning from the server. The client maintains a hashtable of outstanding events. Each event which is redirected to the server is assigned a unique ID and added to the hashtable. The ID is used to locate the original object in the hashtable when the event is being completed. Once the event has been completed, it is removed from the hashtable of outstanding events. Other plugins used are:
.gif) Client GUI [au.edu.swin.synergy.plugin.clientgui] The Client GUI is used to display the menu items for logging in and logging out, with a login status bar. The Client GUI uses the Client Side Network plugin to do all the processing. The input events handled by the Client GUI are Login Complete and Logout Complete. The output events dispatched by the Client GUI are Login, Logout and FindServers. On creation, menus are registered and are enabled and disabled based on the current login state. When login is selected, a dialog is displayed with a list of available servers, prompting for username and password. This information is then dispatched in a Login event. Other plugins used are:
.gif)
Command Line [au.edu.swin.synergy.plugin.command] The Command line plugin allows text based commands to be entered and outputs text to the command line. Commands can be dynamically added and removed at run-time and can store environmental variables. The input events handled by the Command line plugin are EnableRemoteCommands, ExecuteCommand, GetEnvironment, HandleStandardOutEvents, RegisterCommand, UnregisterCommand, SetInputOutputStreams and StandardOutput. The output events dispatched by the Command line plugin are ExecuteCommand and RegisterCommand. All registered commands are kept in a hashtable. Commands are read from the input stream which is by default System.in but can be re-assigned. Once a command has been read, it is parsed into a sentence. The first word is used to find the appropriate command in the hashtable. The command is then invoked and the rest of the sentence is passed in as parameters to the command. The core set of default commands with their descriptions are in the table below.
Other plugins used are:
.gif) Command GUI [au.edu.swin.synergy.plugin.cmdgui] The Command GUI plugin is the interface to the command line. The are no input events handled by the Command GUI plugin. The output event dispatched by the Command GUI plugin is SetInputOutputStreams. When the Enter key is pressed, the line of input is passed to the input stream. The Command GUI plugin registers with the Window Manager to display the command line window. Other plugins used are:
.gif)
Diagram [au.edu.swin.synergy.plugin.diagram] This plugin takes care of all everything which is related to diagram. One example of this would be the display of Drawables on the viewport. Apart from that, it also stores drawables, allow other plugins to connect to the viewport, and interacts with the drawable palette. This plugin requires the module 'au.edu.swin.synergy.kernel.BPlugin' as one or more of its classes extends it. There is a command event - BRegisterViewportCE - which is handled by this plugin. This command event is sent by other plugin to register a viewport. On the other hand, this plugin dispatches two comand events - BAddWindowCE and BAddMenuItemCE. Event BAddWindowCE adds a window to the window manager, whereas BAddMenuItemCE adds room menun item to the menu manager. In summary,
Package diagram is made up of the following classes:
Whereas it implements interface BView for the purpose of Height, Width, and Depth.
The following is a description of the above diagram in point form:
This plugin has 2 sides, the plugin, which dispatches events, and the static methods contained within the classes. The plugin begins by registering a panel with the preferences plugin via an Add Preferences command. The preferences panel provides a means for the user to change the current locale and consequently the language the User Interface is displayed in. When the dialect plugin receives a preferences updated command, it dispatches a dialect change event to all plugins that they need to update their interface. The static methods provide
ways to read the relevant properties file and return the appropriate values
for the current locale. It also provides a means for formatting compound
messages (a string containing variables which are provided at runtime).
Other plugins used are:
Direct Messaging Server [au.edu.swin.synergy.plugin.directsvr] The Direct Messaging Server
plugin is loaded on the server and allows messages to be sent between logged
on clients. The Direct Messaging Server communicates by listening for Mail
events. All Mail events have a "container" object which contains all the
fields relevant to a message ie. sender, receiver, subject, message, time
spent, etc. The Direct Messaging Server detects the absence of the '@'
symbol which indicates it is not an SMTP message. If it is not an SMTP
message, it detects whether the user is logged in to obtain their connection
ID. It then dispatches a Direct Mail event to the client utilising the
connection ID.
Other plugins used are:
.gif) Encryption [au.edu.swin.synergy.plugin.crypt] The Encryption plugin uses cryptography to make the communication between clients and servers secure. The final cryptographic method is yet to be determined. There are no input events handled by the Encryption plugin. The output event dispatched by the Encryption plugin is RegisterEvent. Data is read from the appropriate stream then either encrypted or decrypted. Initial key exchange can be done and is transperant to any higher layer, such as the networking plugins. Other plugins used are:
.gif)
Help [au.edu.swin.synergy.plugin.help] This plugin provides help structure for plugins to register help files. For example, if a new plugin is implemented and the developer wishes to register its help system, then the .html help files can be sent to Help, evething will be taken care of by Help and updated automatically, for example: table of contents, search, and so on. Module used:
In summary,
Plugin Help has the following classes:
It implements Comparable so that Help Items can sorted within a list.
Mail Client [au.edu.swin.synergy.plugin.mailclient] The Mail Client plugin is
client related and provides an interface for sending SMTP/Direct Mail and
viewing/receiving Direct Mail. The Mail Client GUI can be displayed through
the Send Message menu item in the Messaging menu, which dispatches a Direct
Mail event to be received by the Mail GUI to display the window. To send
a message the receivers are selected from the Address Book. When a message
is sent, a Mail event is dispatched. When a Direct Message is received,
the Mail GUI receives a Direct Mail event containing the message details
which are then displayed. Each Direct Message received during the life
of the current session is saved. The previous messages received can be
viewed through the dialog.
Other plugins used are:
.gif) Meta-Modeller [au.edu.swin.synergy.plugin.metamodeller] This plugin
is a definition of what a model can be made up of.
Modules Used
In summary,
Meta-modeller is made up of the following classes:
The description for the above diagram is as follow:
Modeller [au.edu.swin.synergy.plugin.modeller] This package is used for drawing all the models. It is different from just square, shapes, etc. Modeller is not a simple model. It is a way of drawing models given a package and a meta model. This plugin uses two other modules, they are:
Input (event handled) = none Output (event dispatched) = none Plugin modeller is made up of the following classes:
.gif)
Packager [au.edu.swin.synergy.plugin.packager] This plugin is used for building notation. It specifies notation for the meta model. New notation can be created using packager. However a meta model must be selected to be based on. There are two section to this packager. The first section allows user to specify what they wish to have in their notation, such as class, interface, node, arc, and so on. The second section is the notation builder, which enables user to specify the shapes for those elements defined earlier on. Modules Used:
In summary,
Plugin Packager has the following classes:
Preferences [au.edu.swin.synergy.plugin.prefs] This package
provides a central place for plugins to display their preference panel.
This plugin uses only one other module, and this module is 'au.edu.swin.synergy.kernel.BPlugin'. Package 'au.edu.swin.synergy.kernel.BPlugin' handles two command events - BAddPrefsCE and BRemovePrefsCE. BAddPrefsCE is the command event that other plugins dispatches to add a preference panel to the preference area, whereas BRemovePrefsCE is the command event that other plugins dispatches to remove a preference panel from the preference area. Having handled the command event (BAddPrefsCE or BRemovePrefsCE), this plugin dispatches a command event - BUpdatePrefsCE - which instructs the other plugins to update their preference panel on the preference area. In summary,
There is no
class diagram for this package as it only contain one single class - class
BPrefs. Class BPrefs extends BPlugin because it is a plugin. Any class
that
is to be a plugin must extend BPlugin.
Remote Transfer Protocol [au.edu.swin.synergy.plugin.rtp] The Remote Transfer Protocol plugin is the client side for the repository and has a command line interface to the repository. There is also a GUI version which allows the user to graphically check in, check out, add and delete files. It also has an ACL editor for setting the appropriate security settings. Information is retreived from the repository server by sending command events. Files are transferred to and from the server using events. Permissions are changed using the set security event. The BFile class within the au.edu.swin.synergy.lib plugin is used for the method in which compressed files are transferred across the network. Other plugins used are:
.gif)
Repository [au.edu.swin.synergy.plugin.repository] The Repository plugin is used for the server side storage of files, with version management. The input events handled by the repository plugin are GetFile, PutFile, StatFile and ChangeSecurity. There are no output events dispatched by the Repository plugin. All persistant storage is stored in a file called meta-data. The actual file contents is saved in a file with version information. Security access to the file is checked, then the results of this check are passed back as an event. The BACL class, which maintains an Access Control List, within this plugin contains a list of security descriptors (BDescriptor) and an owner. It performs the security checks of files and has a one-to-many relationship with BDescriptor. The BDescriptor class within this plugin maps a user or a group to an access level. The access levels available are read, read/write and no access. BDescriptor contains a relm (user/group), an id and an access level. By default no access is given unless specified. The BMetaData class within this plugin contains meta-data for each file in the repository. These meta-data are date, name, size, type, version and BACL. The BRepository class within this plugin listens for events from the client and performs the request.
Other plugins used are:
.gif)
Server [au.edu.swin.synergy.plugin.server] The Server plugin is the server side event redirector. It checks for event authentication and allows multiple connections. It takes an event on the server, sends it to the client, listens for events coming from the clients and distributes them to the plugins on the server side. Events dispatched: None
The server maintains a list of connections. Each session has an ID which is placed inside every event handled by the server. Other plugins can then request the BUser who is authenticated on that session ID. The server also handles requests for encryption plugins and can return a complete list of current sessions. The BNetCredentials class within this plugin contains the username and password used to perform authentification. The BServer class within this plugin listens for incoming connections and creates a BServerSession to handle them. The BServerSession class within this plugin is a thread that listens for incoming events from the network. The BSocketObjectPipe class within this plugin takes an object and sends it over the network and pipes the data through any registered filters.
Other plugins used are:
.gif)
SMTP Server [au.edu.swin.synergy.plugin.smtpsvr] This plugin operates in much
the same way as the Direct Messaging server except it processes the address
objects, which contain an '@'. It uses a SMTP object to send the message
using the SMTP standards format.
Other plugins used are:
au.edu.swin.synergy.plugin.userdb .gif) User Database [au.edu.swin.synergy.plugin.userdb] This is a server side plugin and provides services via command events for creating, retrieving, updating and deleting. It provides a means for editing users/groups and permanently storing them in human readable text files on the server. It also provides a way for assigning priviledges to user/group levels, which is used for access control to the repository and anything else that requires priviledge based access. It is also used as the basis for logging into servers. It maintains referntial integrity across users/groups. ie. Users/groups are stored in individual files and it makes sure that if a user is a member of a group that the group includes the user. When a user/group is updated
the plugin broadcasts an Update event to all clients. The changes/updates
take effect on all logged on clients/servers immediately. The User Database
enforces security while running on the server, such as only administrators
can add users, etc.
Other plugins used are:
.gif)
User Manager [au.edu.swin.synergy.plugin.userman] This plugin provides a user
interface to the User Database which facilitates remote administration.
It can either be used through the GUI or the command line. Both interfaces
allow the full range of User Manager commands except that the command line
also allows input/output redirection, ie. scripting commands, log files.
The User Manager enforces security with the latest available priviledge
information and when changes are made it updates immediately. For example,
if an administrator revokes the administrative priviledges of another administrator
while the second administrator is conducting an administrative transaction
(eg. add user/change priviledges) the updated priviledges from the User
Database running on the server will override the current priviledges on
the client.
Other plugins used are:
.gif) Window Manager [au.edu.swin.synergy.plugin.mod13] The Window Manager plugin controls the layout for all graphical components and provides an application framework which includes menus, menu items, dialogs, windows and panels. It maintains three default menus: File, which contains Exit; Edit, which contains Cut, Copy and Paste; and Windows, which contains the windows added to the Window Manager. All listeners & controls of added items are handled by the source plugin. Menus - If the menu names are the same the Window Manager merges the menus. Groups of menu items within a menu are divided by a horizontal seperator. Plugins can nominate a preferred mnemonic for the menu, the Window Manager will ensure it is unique. If it is not, it takes the next unique letter in the menu name as the mnemonic. Windows - If a window has the same name as another window, a sequential number is added to the window name, both in the window title and the window menu. If a window is added with the same name, the original window will become window1 and the second becomes window2, etc. If there are 5 windows and window3 is closed then windows 1,2,4 & 5 will remain. Any components added to the Top, Bottom, Left or Right of the Window Manager are added seperately to a tab on a split pane. A way of selecting the tab is provided via events. Tab panes and menus are only created when components are added. When all items have been removed so will the menu, tab pane and status bar. Status Bar - The status bar provides a means for adding/removing items onto the status bar. Selecting menus, tabs on tab pane, minimising, maximising, hiding, closing, bringing to front, sending to back, etc. can be done with the mouse or through the command line. The Window Manager also redirects
events to relevant Listeners of the window and notifies focus window of
cut, copy and paste events.
Other plugins used are:
.gif) Workspace [au.edu.swin.synergy.plugin.workspace] The Workspace is a client plugin and provides a user interface representing what the user is working on. New Project makes a new Workspace with the same name as the project. Only one Workspace at a time can be displayed in the panel. It is possible to remove the project and add a new project. It is also possible to have multiple projects in the one Workspace. Each project is displayed with its contents, such as models. Selecting a model displays it in the working area. Clicking on a model in the workspace switches between the models. If there is no workspace open when a new project is created a new workspace is created with the same name. If there is a workspace open then you can choose to add the new project to the current workspace or create a new workspace.
Other plugins used are:
.gif)
6. File Structure and Global Data The file structure of the released product that is maintained on secondary storage media is: .\cohesion\cohesion.jar
This directory contains the executable jar file which can be run from a computer which supports java. The cohesion directory is the only one needed by the cohesion program. Other directories which may require maintenance are ones which hold data files. This is at the discretion of the user of the product. The jar file encapsulates the file data structure. For a complete listing please refer to the jar file directly (Unjar using the jar command). 6.1.2 Logical Record Description The file format used for cohesion models is a XML like file format. Any object which implements the BSaveable interface can be loaded and saved in the cohesion file format. Each section represents an object with a start tag, an end tag and a number of text strings and sub-sections. Data is saved in a human readble format with a series of key = value strings. If any key is omitted then defaults are used. Section names are mapped to java classes using a set of registered aliases. The file format is designed to allow changes in code while maintaining compatibility with the existing files. The files are text based
and are maintainable via any text editor. eg. Notepad.
7.
Requirements Cross Reference
|
.gif)
.gif)
.gif)
.gif)
.gif)
