Revised Software Architecture Document

Software Architecture Document for Resource Allocation System. Overview

The report will present a detailed analysis of the architecture Resource Allocation System. Further sections cover the architectural representation of the project including architectural representation, architectural goals and constraints and use case realizations. The later sections cover the detailed specific details of the 4 main views (logical view, process view, deployment view and implementation view) of the system. Furthermore, the document describes the data view and performance, quality views.

Architectural Representation

This section describes the architecture using the views defined in the multi-tier architecture model. The views that used to document the Resource Allocation System application are:

1.1 Scenarios

Audience: All the users of the system, including the end-users. Area: Describing the set of scenarios and/or use cases that represent some of the significant, central functionality of the system. Describes each actor and use cases for the system. Other than the basic workflow the documents addresses the exception cases, exception outputs, and other related use cases.

Logical view

Audience: Designers, Testing staff, Programmers Area: Functional requirements, system layers, object hierarchy. Describes the design of object model. Also describes the subsystems of the system and their relationships.

Process view

Audience: Programmers, Integrators. Area: Non-functional requirements, describes the design's synchronization aspects and concurrency and Elaborates the run time behaviour of the system. Development view

Audience: Code testers, Programmers. Area: Software components: describes the subsystem divisions and modules of the system.

Physical view

Audience: Deployment managers, System engineers, Database administrators. Area: Persistence: describes the architecturally significant persistent elements in the data model. Describes the mapping of the software onto the hardware and shows the system's distributed aspects

Logical View

1.2 Overview

1.2.1 Subsystems

Resource Allocation System can be divided into 4 main sub systems.

1. User management subsystem
2. Resource management subsystem
3. Project management system
4. Booking management system

1.2.1.1 User management sub system

This sub system provides the facilities that covers all the user management functionalities. Main use cases that comes under this subsystem includes • User login • New user creation • Update User

Each user that interacts with the system is an actor of these use cases. Depending on the access levels, some actions will not be permitted.

1.2.1.2 Resource management subsystem

This subsystem involves the details of the employees. Main use cases that come under this subsystem includes • Add Resource • Update Resource • Delete Resource

1.2.1.3 Project management subsystem

This subsystem involves the project details of the system. Main use cases that come under this subsystem includes • Add Project • Update Project • Delete Project

1.2.1.4 Booking management subsystem

This subsystem involves the booking details of the system. Main use cases that come under this subsystem includes • Add Booking • Update Booking • Delete Booking

1.2.2 Layering

This system is divided into 4 layers. The layering model of the Resource Allocation System application is based on a responsibility layering strategy that associates each layer with a particular responsibility. This strategy has been chosen because it isolates various system responsibilities from one another, so that it improves both system development, reusability and maintenance.

Previous version Revised Version

Deployment View

Being a web application, this system is hosted in a remote server. The database will be hosted in some other hosting space. Except for the statistical graph generation, all the processing is done in the backend, so that the client computer doesn’t have to spend much of CPU power. In case of statistical graphs generation, all the data processing will be done in the front end, so that the client computer will need a particular level of performance.

Implementation View

The Diagram below depicts the multi-tier Architecture, which will be used when Integrating different components of the System such as: Business logic, Presentation and data tier for storage and retrieval of information from the database System.

1.1 Overview

Resource Allocation System is a web application that follows the MVC architecture pattern. Main reason to use this pattern is to separate functions into layers thus improve the maintainability and reusability. View layer contains the graphical user interfaces (web pages). The actions of these web pages are handled by controller classes. Controller classes invokes and instantiates objects of model classes that contains the business login. Separating software packages in this manner reduces the complexity. The model classes can be subdivided in to two layers. Business layer and the data access layer. Data access layer is manipulated using HIBERNATE framework. Business layer contains the main entity classes such as Student, Lecturer and etc. The object relational mapping is done using the HIBERNATE framework. For each entity in the database there exists a class in the software that provides data access operations to that entity.

Technical Competency Demonstrator

Server side

Resource Allocation System will be hosted at ApacheTomcat server. Being a web-based application, this underlying client OS can be any PC operating system. MySQL will be used as the central database server. All communication with client has to comply with public HTTPS, TCP/IP communication protocol standards.

Client Side

Users will be able to access Resource Allocation System only online. At the initial stage this will be hosted as a web-based application in Google Chrome. but with modifications, it can be integrated with a system modern web browser such as Mozilla Firefox 10, Internet Explorer 9, Google Chrome or Safari to get full user experience.

Security

Central security features are handled by the Spring Security. They’ll be given full access features both in the application and database levels. We used Spring Security for the login page to verify the user when login to the system. Creating user accounts for managers, employees are done by the admin. After the users are added to the system, they’ll be provided with a default password, which can be changed by the user. All the passwords are encrypted in order to ensure higher security. Responses and commits made by the managers can be seen only by the senior manager and admin.

Reliability / Availability

The system will be subjected to several testing operations (Unit testing, integration testing, system testing) before being deployed in order to make sure that the system is reliable. The MYSQL database server can respond to many numbers of clients at a given moment without losing consistency and data integrity.

Performance

The system responds to any request under standard database and web server script timeouts (30 seconds), also system performance can depend on available hardware, network and internet connection capabilities. Especially the statistical information generation tasks may take comparatively high time. Therefore, actual performance can be determined only after the system is deployed and tested.

Portability and reuse

Even though Resource Allocation System is designed as a complete and standalone product. In order to maintain reusability, all the functionalities are very well structured and layered. Best practices of followed throughout the project and the project strictly adheres to OOP standards.

Development tools

The project incorporates many development tools. Programming: Eclipse IDE Database: MySQL 1.2 Database connection: MYSQL connector

Resource Allocation System is a web application that follows the MVC architecture pattern. Main reason to use this pattern is to separate functions into layers thus improve the maintainability and reusability. View layer contains the graphical user interfaces (web pages). The actions of these web pages are handled by controller classes. Controller classes invokes and instantiates objects of model classes that contains the business login. Separating software packages in this manner reduces the complexity. The model classes can be subdivided in to two layers. Business layer and the data access layer. Data access layer is manipulated using HIBERNATE framework. Business layer contains the main entity classes such as Student, Lecturer and etc. The object relational mapping is done using the HIBERNATE framework. For each entity in the database there exists a class in the software that provides data access operations to that entity.