Software Design Document, Testing, Deployment and Configuration Management, and User Manual of the UUIS -- a Team 4 COMP5541-W10 Project Approach

This document provides a description of the technical design for Unified University Inventory System -Web Portal. This document’s primary purpose is to describe the technical vision for how business requirements will be realized. This document provides an architectural overview of the system to depict different aspects of the system. This document also functions as a foundational reference point for developers.

Please note that this is a baseline document and may be updated as development progresses.

This document is targeted (but not limited) to technical stakeholders:

It is assumed that the reader has a technical background in software design and development.

The design approach used here is based on the following:

The data flow of the UUIS is Internet-based. Hibernate technologies will be utilized to retrieve and cache data from MySQL database to be displayed by the Web portal user interface. Hibernate would also allow updating the data where applicable.

The Customer Support System application will follow a Four Layer Architecture so that the objects in the system as a whole can be organized to best separate concerns and prepare for distribution and reuse. A principal advantage to this design is the relative stability of the components as seen by the applications developer. Implementations may change considerably to enhance the performance or in response to changes in the architecture. These changes are less likely to cause major impact to the applications’ programs.

Wire Frames are used for UI design. Wire frames are an effective tool for collecting and presenting functionality, navigation, and content of an application or web site. Annotations or notes attached to elements or widgets on the wire frame help to communicate specific functions.

This application is designed as an object-oriented system for an Internet-based architecture using four-layer architecture by factoring application classes into the following layers:

The Presentation layer. This is the layer where the physical window and widget objects live. It will also contain Controller classes as in classical MVC. Any new user interface widgets developed for this application are put in this layer. In most cases this layer is completely developed within Grails.

The Domain Mode. Most objects identified in the OO analysis and design will reside. To a great extent, the objects in this layer can be application-independent. Generic objects may be used in this application to reap the benefits of Object Oriented programming.

The Hibernate layer. The domain model has been mapped using Hibernate. This will map Grails domain classes onto a wider range of legacy systems and will be more flexible in the creation of your database schema.

The Data layer. The data is managed by MySQL. Audit_Logging plug in: easy to implement the audit log module.

The following web-site directories will be used to organize the JSP Pages used in the web-site: User site Directories:  Root Directory -All web pages related to user functions.  Images Directory -Contains the images used by the system.  Reports: Contains the local reports that would be used to export to CSV format.

A good way to track exceptions is to implement an exception handler at the application level. This will allow consolidation of the logging and notification parts of the exception handling in one convenient place.

The global exception handler can handle both specific exceptions that UUIS trap in the code as well as generic un-handled exceptions. After global exception handler has done its work, it would redirect the users of the website to a friendly error page that tells them that something has gone wrong and instructions on what to do.

All unhandled exceptions would be logged in the Windows Application Event Log or log files with some detail on the nature of the failure.

The general search included that retrieve records from the database according to userspecified search criteria. Further, the search may encompass other information collections like on-screen data.

The advanced search may need to be added to the system in order to remain as flexible as possible, the search module is designed in such a way as to isolate the specifics of search implementation from the application. The search module has a limited API exposed, and depending on its configuration it can implement the required search class without further programmer intervention. It should be possible to add other classes of search, relating to other types of data, with relatively little effort.

The assets included the management of asserts (et. Computers, tables, office supplies, software …). The granted user can add, edit and modify the assets within his scope. When