1 INTRODUCTION

1.1 Purpose
The purpose of this SDD is to define and describe the use of each view, the architectural
constraints of the system, the functional requirements with a significant impact on the
architecture, logical view, process view, deployment view, use-case realization, concurrency
aspects, the layers and subsystems of the application, overall description, performance issues and
constraints.

This document provides a comprehensive architectural overview of the system, using a number
of different architectural views to depict different aspects of the system. It is intended to capture
and convey the significant architectural decisions which have been made on the system.

The development team can use this document to review the architecture of the system. The
Architecture document will be also useful for future development teams.

Scope

This document gives a detailed description of the software architecture of the inventory system.
It specifies the structure and design of some of the modules discussed in the SRS. It also displays
some of the use cases that had transformed into sequential and activity diagrams. The class
diagrams show how the programming team would implement the specific module.
The Resource Center and Auditorium Booking System’s (RCABS)have many tasks. The
combination of different auditorium’s management of auditorium booking and resource center
with different equipment, the possibility to choose between different dates and times is the
reason why a good booking system is needed to make this task as easy as possible. The basic
functionality of the system is to keep track of auditoriums in different buildings, rooms and their
equipment, reservations of auditorium and rooms and different types of users. Reservations of
the auditorium and rooms should be visualized to the user in a simple and intuitive way. There
should be a simple way of getting overview of the reservations. The system should be
interoperable with any platform and OS.

A booker should be able to reserve and cancel his/her own bookings and should be able to search
for a auditoriums with a certain property like capacity, price, number of seats and equipment.
There should be an administrator that can administrate the whole system through the interface
without writing any SQLqueries. This includes the management of add, edit and delete functions
for every entity in the system including new users and their privilege management. One type of
user should only be able to look at existing reservations and not be able to reserve auditoriums.
The system should be a complete content management system for handling the reservations of
auditoriums, buildings, equipment and users. The interoperability of the system should make it
easy to access and use from different platforms.

1.2 Overview

The rest of the document will elaborate on the system from an architectural point of view. This
document is organized as followed; section two deals about system overview represent the
overall description of the proposed system. In the section three, system architecture that discus
about the architectural design, the main purpose is to gain a general understanding of how and
why the system was decomposed, and how the individual parts work together.
In the section four deals about data design, explain how the information domain of your system
is transformed into data structures and how the major data or system entities are stored,
processed and organized are data description.
In section five, component design that discus about what each component does in a more
systematic way and each component/subsystem you can create new heading using the component
name as a title.
At the section six, human interface design we discus about overview of user interface, explain
how the user will be able to use your system to complete all the expected features and the
feedback information that will be displayed for the user. Screen image and screen object and
action. In the next section, requirement matrix we discuss about the cross reference that traces
components and data structures to the requirements in your SRS document.

1.4 Reference Material

The IEEE Guide to Software Requirements Specification (ANSI/IEEE Std.830-
1984).

Software Architectural and Design Document Template given by the department

1.5Definitions and Acronyms

Acronyms Definitions

SRS Software Requirements Specification

RCABS Resource Center and Auditorium Booking

System

OS Operating system (like Computer windows)

Architecture High level structure of the system

Detail design Low level structure of the system

2. SYSTEM OVERVIEW

This project is concerned with developing a flexible, open-ended design for resource center
auditorium booking information system that incorporates well-known design patterns and a lucid
design style using UML diagrams. Our Resource Center and Auditorium Booking System
consists of two users:
1. Customer
a. student union Customer
b. collage and department Customer
2. Staff
a. Manager (auditorium and resource center)
b. Other Employees Customers can various services provided by the auditorium like auditorium
booking, restaurant, material management etc. The Resource center and Auditorium Booking
System is divided into four main modules. Each and every module performs a particular work.
Those four modules are

1. Maintenance of users and seminar hall

2. Booking the seminar hall
3. Approval and Rejection by In-charge
4. Role of Principal

OBJECTIVES OF THE PROPOSED SYSTEM

 To enable online booking via the internet.

 To enable automated data entry methods.
 Ensure efficient and reliable communication within the university society.
 Enable easy authorized modification of data.
 Enforce security measures to avoid unauthorized access to user records.
 Enable fast and easy retrieval of user records and data for fast reference activities.

SCOPE OF THE SYSTEM.

The system will cover; booking, accommodation, meals, and accounts details. Moreover,
special services such as auditorium, resource center and room service will be automated
by the system also, not to forget the additional facilities information that will be
efficiently handled by the system.

3. SYSTEM ARCHITECTURE

The software architecture of a program or computing system is the structure or structures of the
system which system is the structure or structures of the system, which comprise software
elements, the externally visible properties of those elements, and the relationships between them.
Software system architecture comprises
 A collection of software and system components
 A collection of software and system components, connections, and constraints.
 A collection of system stakeholders' need statements.
 A rationale which demonstrates that the components, connections, and constraints define
a system that, if implemented would satisfy the collection of system implemented, would
satisfy the collection of system stakeholders' need statements.
We are using three tiers architectural for our project.

3.1 Architectural Design

As the main objective or this system is giving easy and manageable means of controlling and
having an access the service through the internet the following components are the main building
blocks of the system.All of thesystem component divided by five module.
1. Register Master
2. Manage account
3. Booking the seminar hall and rooms
4. Manage Resource center
5. Approval and Rejection by In-charge
6. Notification tracker

3.1.1 Component description

3.1.1.1 Manage Account

It consists of Signup, Login and update details of the users. The Administrator create a separate
account for each Department, Seminar hall in-charges, other cells like placement and training
and Principal.

3.1.1.2 Register Master

This component is responsible for letting the user to change and update his/her account
information and changing active account, generally this component is concerned with account of
the system. The manager also the registration of auditorium, update and delete auditorium.

3.1.1.3 Booking the hall and rooms

Each department has the username and password to book the seminar hall for their requirement.
Through this they can view the available dates of particular seminar hall and also the facilities in
the hall like capacity, mic’s projector, marker board etc. This provides user-friendly environment
while booking the seminar hall it gives suggestion regarding the selection of seminar hall based
on the capacity and availability. The concern department head can view the list of the request.
The acceptance and rejection can be viewed by the user through that login or even by the email
id.

3.1.1.4 Approval and Rejection by In-charge

The role of seminar hall in-charge is to check the request came to the seminar hall. in-charges
login into their account the list of new requests are displayed in their page as show. The request
can be either accepted or rejected based on the priority of the request. If more than one request is
made for the same seminar hall on the same date after granting approval to a particular request
by seminar in-charge, the remaining requests are automatically rejected and the email is sent to
the bookie and also it is notified on their page.

3.1.1.5 Manage feedback In this manager can see users feedback and give replays for
that feedback.
 Notification tracker: - it is a component which is responsible for providing and
tracking a notification when new change comes up. It generates a notification when
admin accept user booking request and when it reject.

3.1.2 Layard Architecture

 User interface layer

This Layer is the form which provides the application to either programmer or end user.
 Process layer
This Layer implements business logic that involves collaborating with several domain
classes or even other process classes
 Domain layer
 This layer is used to transfer data from application layer or presentation layer to data
layer. This layer is also used when a class variables are declared corresponding to the
fields of the database which can be required for the application and make the properties.
So that, the team can gets or sets the data using these properties into the variables.

 Persistence layer
This layer encapsulates the capability to store, retrieve, and delete objects/data
permanently without revealing details of the underlying storage technology. This layer is
also a class to get or set data to the database queries back and forth.
 System layer
This Layer provides operating-system-specific functionality for our applications,
isolating our software from the operating system (OS) by wrapping OS-specific features,
increasing the portability of our application.

3.1.2.1Logical View

The User of this system will have the following functionalities from the system as described by
the following class diagram which will be implemented in the system.
Functionality of the system list below
 Login master
 Registration Master
 Booking Auditorium
 Manage rejection and approve
 Manage resource center
 Manage feedback
 Generate report
 Control material
 Fig System class diagram
The above diagram shows the high level structure of class diagram representation of
functionalities. Mainly describe Auditorium and resource center and it is not all functionality of
the system.

3.1.2.3 Process view

In this view we try to describe the flow of activities which are mainly can be done by this
system.
Fig flow diagram for the system

The above diagram shows the process activity showing by using flow diagram representation of
functionalities. Mainly describe how the system flows at the time of using of the system.

3.1.2.4 Deployment view

UML Deployment Diagram is a type of Structure Diagrams that shows the physical deployment
of information generated by the software programs.

The information generated by the software is called “artifact”. The hardware with installed
software is called “node”. Thus, UML Deployment Diagram models the physical deployment of
artifacts on nodes.
The deployment view of the system is used to describe which components are deployed on
which device or hardware while deployment of the software is taken places. The components of
the system placed on the different device that request one to another.

 Account manager.
 Account processor.
 Register master.
 Booking.
 Approve and Rejection.
 Manage feedback
 Notification tracker

Fig deployment diagram

In this view model we will illustrate a system from a programmer’s perspective and is concerned
with software management. This view will present the demonstration of inter component
relations and component wise representation of the system.

3.2 Decomposition Description

Account processor

Identification Account processor

Type Control Procedure
Purpose The purpose of this component is allow the user to manage his/her account
and get information about his/her account.
Function The functions of this component is providing the mean to changing
account information.
Subordinates This component has classes namely Account Setting, Update Account Info
and Change Password,
Dependencies This component mainly depends on the database and the network
(internet ) since the main function is to filter information from database
tables.
Interface Account processor
This component can connect to register master.

 Change Password(String Old Password, String New Password,

String Confirm Password)

Resource Web browser, Mysql Database, Database Server Network (Intern ate or
Wi-Fi).
Processing This component has the following processes to give the desired
functionality
1. Changing account setting: this functionality includes
  Changing account password this functionality achieved by
Change Password class which checks old password and the
sameness of new password with confirmed password and will
update the password from the database.

Data This component fetched data from database and transforms the fetched
data like account information.

Account Manager

Identification Account Manager

Type Class
Purpose The purpose of this component is to enable the admin to manage user account.
Function Using this component the admin of the resource center and auditorium can add user
Account to the system update user information, view user info, activate and
deactivate user Account and delete user from the system.
Subordinates This component has the following classes Activate and deactivate user Account,
Update user Account and View user Info.
Dependencies This component is mainly depends on the database and the network connection.
Interfaces Account manager
This component has interfaces which connects to the database
 Add user (String user Full Name, string user email, int phone, string username,
string user pass word string user type)
 Update user Account(String user Full Name, string user email, int phone, string
username, string user password ,string user type)

Resources Computer Memory, Mysql Database, Database Server, internet connection

Processing This component achieves the desired functionality through the following process
 Activating and deactivate user Account: to achieve this functionality first the
user has to be activated using contact the admin, and then admin Activate and
deactivate user Accounts.
  Adding user these functionalities will be achieved by the Add user classes.
Updating and deleting user these functionalities will be achieved by the Update
and delete user classes.
Data This component will store and fetch data from database and present it in plain text
format.

Register master

Identification Register master

Type Class
Purpose The purpose of this component is to enable the manager to control material and add
some tasks.
Function Using this component the manager of the recourse center can add material, delete
material, update material, view material information, register room, register hall and
add meal info.
Subordinates This component has the following classes register room, register hall, add material,
update room, update hall, delete material and add meal.
Dependencies This component is mainly depends on the database and the network connection.
Interfaces Register master
This component has interfaces which connects to the database
 Add material (String material Name, string material Id, String product Type)
 Register room(String room Number, int room capacity)
 Register hall(String hall Name, String hall Capacity)
 Update material(String material Name, string material Id)
 Delete(string material Id)
 Add Meal(String name, String type, int meal costs)

Resources Computer Memory, Mysql Database, Database Server, internet connection

Processing This component achieves the desired functionality through the following process
  Add material: to achieve this functionality the manager has to be add material
using Add material class.
 Register room: to achieve this functionality the manager has to be register room
using Register room class.
 Register hall: to achieve this functionality the manager has to be register hall
using Register hall class.
 Add meal: to achieve this functionality the manager has to be add meal using
meal class.

 Update and delete material: to achieve this functionality the manager has to be
update and delete material using Update material and delete material class.

Data This component will store and fetch data from database and present it in plain text
format.

Booking

Identification Booking
Type Class
Purpose The purpose of this component is to enable the user to book room and hall.
Function Using this component the user of the system can book resource center room, meal,
auditorium hall and also pay money.
Subordinates This component has the following classes booking Hall, booking Room, view room
info, view hall info, book meal, view meal info and payment.
Dependencies This component is mainly depends on the database and the network connection.
Interfaces Booking
This component has interfaces which connects to the database
 Book hall(String hall name, String starting date and time, String ending date and
time)
 bookroom(String room Number, String starting date and time , String ending
date and time)
  book Meal(String Meal name, , String meal type)
 view room info(String room type, String capacity , String place, Int cost)
 view hall info(String name, String capacity , String place, Int cost)
 view meal info(String meal type, String name , Int cost)
 payment(string bank name, String Card type, String pin number, String valid
date, int user code)

Resources Computer Memory, mysql Database, Database Server, internet connection

Processing This component achieves the desired functionality through the following process
 booking Hall and Room: to achieve this functionality first the user has to be
view about resource center rooms and Hall information then book using book
Hall class and bookroom class.
 Book Meal: to achieve this functionality first the user has to be see about
resource center Meal by using view Meal info class and then book Meal using
book Meal class.

Data This component will store and fetch data from database and present it in plain text
format.

Approve and Reject

Identification Approve and Reject

Type Class
Purpose The purpose of this component is to enable the manager to Approve or Reject user
booking requests.
Function Using this component the manager of the resource center can approve and reject
user requests.
Subordinates This component has the following class Approve and Rejection, view user requests.
Dependencies This component is mainly depends on the database and the network connection.
Interfaces Approve and Reject
This component has interfaces which connects to the database
 Approve booking request(String hall Name, String room Number, String starting
date and time, String ending date and time )
 Reject booking request(String hall Name, String room Number, String starting
date and time, String ending date and time )

Resources Computer Memory, Mysql Database, Database Server, internet connection

Processing This component achieves the desired functionality through the following process
 Approve and Reject user booking request: - to achieve this functionality first the
manager has to be view user Booking Requests from view user requests class
then Approve User requests by using Approve and Rejection class.

Data This component will store and

fetch data from database and present it in plain text format.

Notification Tracker
Identification Notification Tracker
Type control procedure
Purpose Notifying the user if there is new changes on the system and on the accept of
request.
Function The main function of this component is to trace changes in the database tables and
provide changes in user understandable mode
Subordinates This component is composed of classes namely Change Tracker, Prepare
Notification, and Display Notification.
Dependencies This component mainly depends on the database since the main function is to filter
changes from database tables. This component can be used by acceptance and reject
component as a link to the changes in the database that has to be presented for the
user. This component will be feed by the Booking and account processor
Interfaces Notification tracker
 Check request (String Cost Name, String Cost ID,)
This method is initiated when the web is started and it used to connect with
accept and reject component.

Resources Web browosers Mysql Database, Database Server, Mobile Network or Wi-Fi

Processing As described in Subordinate subsection this component contains three class each of
the classes interact with each other as follows as a result they will provide the
required function.
 Change Tracker class is lunched at first this class filters changes in the users
account, using its methods of Check user account.
 If there is change in the database then Prepare Notification class will prepare
notification as pre the change, if not there the notification panel list will stay
the same.
 Display Notification class is triggered when only one notification is clicked
from the notification list. This class feed the display panel with the full
description of the notification selected.
Data This component fetched data from database and presented in plain text format.

3.3 Data Rationale

For the reason that we are going to develop a system which has to be more secure and reliable
system we prefer to use three tiers architecture. As of three tier architecture is the mix of client
server and layered architecture, by using this architecture we can achieve the necessary
nonfunctional requirements like scalability of the system in the way that each tier can scale
Horizontally. This architecture has different usages with different applications and distributed
applications. The strength in particular is when using this architecture over distributed systems.
4 DATA DESIGN

In this section the data design description is presented as how data are represented in this project
and what type of data are used in this project. Also this section will discuss about available
objects in the project with their respective attributes.

4.1 Data Description

In this describes the database objects for each component of Web Logic Portal. The information
in this section is collectively known as the data dictionary. For each component of Web Logic
Portal, the following information is provided:
An entity-relationship diagram
A detailed description of each database table, including:
 Table Name - The predefined name for the Table.
 Table Description - A detailed description of the contents and purpose for the table in
Web Logic Portal database schema.
 Column Name - The predefined name for the column. Data Type - The predefined
characteristics for the column.
 Data types vary slightly by DBMS. For instance, columns defined as BLOB data types in
Oracle, DB2, and Point Base would be defined as TEXT columns in Microsoft SQL
Server and Sybase.
 Null Value - Indicates whether or not null values can be stored for the column.
 Column Description - A detailed description of the contents and purpose for the column
including Primary Key (PK-) and Foreign Key (FK-) designations.
Firstly every visitor seen website or home page of the website but, In order to booking
auditorium firstly every user login to the page if have account else first create account then login
after login to the page using any service from the system.
The logical database requirements include the retention of the following data elements. This list
is not a complete list and is designed as a starting point for development.

Auditorium Booking System

  Customer first name
 Customer last name
 Customer address
 Customer phone number
 Assigned Type of auditorium
 Default auditorium rate
 Rate description
 Guaranteed auditorium (yes/no)
 Automatic cancellation date
 Expected check-in date
 Expected check-in time
 Actual check-in date
 Actual check-in time
 Expected check-out date
 Expected check-out time
 Actual check-out date
 Actual check-out time
 Customer feedback

Resource center
 Meal
 Meal type
 Meal item
 Meal order
 Meal payment (Bill to room/Credit/Check/Cash)

Database Entities Attributes Type Description

Admin Sec User Id Integer This entity is
First Name VARCHAR(50) responsible for
Middle Name VARCHAR(50) handling the
Auditori security issue of
um Last Name VARCHAR(50) the system
booking Phone Number Integer database admins of
system Email VARCHAR(50) the website.
User Name VARCHAR(50)
Password VARCHAR(50)
Booking Auditorium Name VARCHAR(100) This entity is the
Auditorium capacity Integer representation of
S Date of Booking Date booking of the
E Date of Booking Date auditorium table of
Customer Phone Integer the user send
Customer Email TEXT request for
Purpose of the event VARCHAR(50) manager. And also
Session VARCHAR(50) for registration
booking
auditorium
Describe the
process used to
add a new booking
Auditorium Auditorium Name Integer This entity is
Info Auditorium Capacity VARCHAR(50) mainly responsible
Auditorium Place VARCHAR(50) for storing
Auditorium Id VARCHAR(50) Auditorium
Resource Text information.
City VARCHAR(50)
Registration Customer Full Name VARCHAR(100) This entity is
user Customer Id Integer responsible for
Customer Email TEXT recording received
Customer Phone Integer transactions as log
Address VARCHAR(100)
Role VARCHAR(100)
 Dept Text
User Name VARCHAR(50)
Phone VARCHAR(50)
Email VARCHAR(50)
Customer Info Customer F name VARCHAR(50) This entity is
Customer M name VARCHAR(50) mainly responsible
Customer L name VARCHAR(50) for storing
Phone Number Integer customer’s
Customer Email VARCHAR(50) information.
Customer Role VARCHAR(50)
Customer Address VARCHAR(100)
Meal Register Meal Name TEXT This entity stores
Meal type VARCHAR(50) security
Meal item TEXT information about
Cost of the meal VARCHAR(50) the meal in
resource center
service database.

5. COMPONENT DESIGN

5.1 Account manager

Class diagram for account manager
5.2 Account processor

Class diagram for account processor

5.3 Register master

Class diagram for Register master

5.4 Booking

Class diagram for Booking

5.5 Accept and Reject

Class diagram for accept and reject requests

Class diagram for notification tracker
Sequence diagram for notification
Activity diagram for notification tracker
Figure: User registration interface