CHAPTER FOUR

4. Design deliverable of the system

4.1 Introduction

After the determination of the requirements, it is the design that follows. Here iterative
processes through which requirements are translated into a “blueprint” for constructing the
system. The design is all about stating the design goals of the system and subdividing the system
into smaller parts in a modular approach. The output of this phase includes description of each
subsystems and the deployment of the subsystems.

4.1.1 Purpose of the system

It is known that in the software development environment there are so problems regarding
requirements. These problems are unclear or poor requirement, unrealistic schedule, inadequate
testing, futurities, and miscommunication and so on.

Therefore, our system is highly intended to provide service for its users through early and
continuous delivery of valuable software by prevent the above listed challenges in software
development.

The following parts of the document describe the design issues and complete architectural
overview of the proposed system

4.1.2 Design goals

The objectives of designing are to model a system with high quality. Implementing of high
quality system depends on the nature of the design created by the designer. If one wants to make
changes to the system after it has been put in to operation depends on the quality of the system
design. So if the system is designed perfectly, it will be easy to make changes to it. The goal of
the system design is to manage complexity by dividing the system in to manageable pieces.
Some of the goals are listed below.
  Performance: - The proposed system should have a fast response time (real time) with
maximum output. Furthermore, the system should not be taking up too much space in
memory, and hence the system should try to be more interactive. In the case of the
scheduling subsystem, the system should be more reliable in order to satisfy the
constraints than fast response time.

 Maintenance:-The online clearance system for EiABC will be easily extensible to add
new functionalities at a later stage. It will also be easily modifiable to make changes to
the features and functionalities.
 Modifiability: The system should be modifiable to modify different services depending
on the need of the user.
 Flexibility: The system should be changeable to suit new condition or situation.
 Efficiency: The system must do what it supposed to do efficiently without the problem.

 Accessibility One of best feature of proposed system is its accessibility. Users can access
their clearance information easily.

4.2 Proposed system architecture

The proposed system has three tier architecture which has three major components.

 The presentation tier: - This layer presents data to the user and optionally permits
data manipulation and data entry. This is tier which user interacts with the system.

 The middle tier or logic tier:-This is the tier which major system activities are
performed.

 The data tier or data services layer: - This is the actual DBMS access layer. This is
tier which the server fetches data from.
The system will run using web technology. This architecture provides greater application
scalability, high flexibility, high efficiency, lower maintenance, and reusability of components.
Since each tier runs on a separate machine, it improves systems performance. The system uses
dynamic web technology, i.e., adding and retrieving data to and from the data store whenever
requested is possible. It requires a client side program which is accessed by the Administrator, by
the Customer and also an interface that communicate with the external system. It needs server
side functions that implement the functional requirements and the database system that stores
data.

Fig 4.1 System architecture

4.2.2 Subsystem Decomposition

System decomposition refers to the process by which a complex problem or system is broken
down into parts that are easier to conceive, understand, program, and maintain. To reduce the
complexity of the solution domain, we decompose our system into simpler parts, called
subsystems, which are made of a number of solution domain classes. In the case of complex
subsystems, we recursively apply this principle and decompose a sub- system into simpler
subsystems.

4.3 Collaboration diagram

Collaboration diagram is another form of interaction diagram. It represents the structural

organization of a system and the messages sent/received. Structural organization consists of
objects and links.

The purpose of collaboration diagram is similar to sequence diagram. But the specific purpose of
collaboration diagram is to visualize the organization of objects and their interaction.

Fig 4.2 collaboration diagram for Login

Fig 4.3 collaboration diagram for Create Account
Fig 4.4 collaboration diagram for Send Request
Fig 4.5 collaboration diagram for Change Password
Fig 4.6 collaboration diagram for View and approved Request
Fig 4.7 collaboration diagram for View Request Progress
Fig 4.8 collaboration diagram for User Log
Fig 4.9 collaboration diagram for Report Generate

4.4 State chart diagram

The state chart diagram used to show the sequence of states that an object goes through the
events that cause the transition from one state to the other and the actions that result from a state
change. It also describe the behavior of a system considering all the possible states of an object
when an event occurs. This behavior is represented and analyzed in a series of events that occur
in one or more possible states. Each diagram represents objects and tracks the various states of
these objects throughout the system.
Fig 4.10: State chart diagram for Login

Fig 4.11: State chart diagram for create account

Fig 4.12: State chart diagram for change password

Fig 4.13: State chart diagram for send request

Fig 4.14: State chart diagram for View and Approve request

Fig 4.15: State chart diagram for view request progress

Fig 4.16: State chart diagram for User log

Fig 4.17: State chart diagram for Report Generate

4.5 Database design

Database design is the process of producing a detailed data model of a database. This logical data
model contains all the needed logical and physical design choices and physical storage
parameters needed to generate a design in a Data Definition Language, which can then be used to
create a database. A fully attributed data model contains detailed attributes for each entity.

The process of doing database design generally consists of a number of steps, which will be
carried out by the database designer.

In database design we will perform the following activities.

 Identifying keys:
 Primary key: Identifies unique instance of an entity.
 Foreign key: This will help us to show the relationship between two tables or
classes.
 Identifying entities: Entities which are the persistent classes will be stated with their
attributes.
 The methods of the classes will be used.
 Inheritances will be included and if there is any associations exist they will also be
included.
 The attributes will be given data type and initial sizes
Fig 4.18: Database Design of the System