Professional Documents
Culture Documents
Documentation For Comment
Documentation For Comment
Documentation For Comment
Name ID No.
1. Helen Tilahun CCS/UR7794/11
2. Milion Nugusie CCS/UR7747/11
3. Negasa Birhanu CCS/UR7751/11
4. Samuel Rabuma CCS/UR7762/11
5. Tahir Dekamo CCS/UR7761/11
Feb, 2022
No part of the project work has been reproduced illegally (copy and paste) which can be considered
as Plagiarism. All referenced parts have been used to argue the idea and have been cited properly.
We will be responsible and liable for any consequence if violation of this declaration is proven.
Full Name Signature Date
I
APPROVAL FORM
This is to confirm that the project report entitled “Dormitory Management System for ARU”
submitted to Arsi University, College of Natural and Computational Sciences, Department of
Computer Science by: Milion Nugusie, Tahir Dekamo, Samuel Rabuma, Negasa Birhanu, and Helen
Tilahun are approved for submission.
II
ACKNOWLEDGEMENT
III
TABLE OF CONTENTS
DECLARATION ................................................................................................................................ I
APPROVAL FORM ......................................................................................................................... II
ACKNOWLEDGEMENT ............................................................................................................... III
TABLE OF CONTENTS ................................................................................................................. IV
LIST OF TABLE ........................................................................................................................... VII
LIST OF FIGURES ...................................................................................................................... VIII
LIST OF ABBREVATIONS ........................................................................................................... IX
ABSTRACT ...................................................................................................................................... X
Chapter one ........................................................................................................................................ 1
1. Introduction ................................................................................................................................. 1
1.1. Background of the Organization .......................................................................................... 1
1.2. Statement of problem ........................................................................................................... 2
1.3. Objectives of the Project ....................................................................................................... 3
1.3.1. General Objectives ...................................................................................................................... 3
1.3.2. Specific Objectives ..................................................................................................................... 3
1.4. Feasibility Study................................................................................................................... 3
1.4.1. Technical feasibility .................................................................................................................... 3
1.4.2. Operational feasibility ................................................................................................................. 4
1.4.3. Economic feasibility ................................................................................................................... 4
1.5. Significance and Beneficiary of the Project ......................................................................... 4
1.6. Scope and Limitation of Project ........................................................................................... 5
1.6.1. Scope of Project .......................................................................................................................... 5
1.6.2. Limitation of Project ................................................................................................................... 6
1.7. Methodologies of Project ..................................................................................................... 6
1.7.1. Methodologies for data collection............................................................................................... 6
1.7.2. System analysis and design techniques ....................................................................................... 7
1.7.3. System Development Models ..................................................................................................... 8
1.7.4. System Testing Methodology ..................................................................................................... 8
1.8. System Development Tools and Techniques ....................................................................... 9
CHAPTER TWO ............................................................................................................................. 10
2. DESCRIPTION OF EXISTING SYSTEM .............................................................................. 10
IV
2.1 Introduction to Existing System ......................................................................................... 10
2.2 Users of Existing System ................................................................................................... 10
2.3 Major Function of Existing Systems .................................................................................. 10
2.4 Forms and Other Documents of the Existing Systems ....................................................... 11
2.5 Drawbacks of the Existing System .................................................................................... 16
2.6 Business rule of the existing system .................................................................................. 17
CHAPTER THREE ......................................................................................................................... 18
3. PROPOSED SYSTEM ............................................................................................................. 18
3.1. System Description ............................................................................................................ 18
3.2. Functional Requirement of Proposed System .................................................................... 18
3.3. Non-functional Requirements ............................................................................................ 19
3.3.1. User Interface and Human Factors............................................................................................ 19
3.3.2. Hardware Consideration ........................................................................................................... 19
3.3.3. Security Issues .......................................................................................................................... 20
3.3.4. Performance Consideration ....................................................................................................... 20
3.3.5. Error Handling and Validation.................................................................................................. 20
3.3.6. Quality Issues ............................................................................................................................ 20
3.3.7. Backup and Recovery ............................................................................................................... 20
3.3.8. Physical Environment ............................................................................................................... 21
3.3.9. Resource Issues ......................................................................................................................... 21
CHAPTER FOUR ............................................................................................................................ 22
4. SYSTEM ANALYSIS .............................................................................................................. 22
4.1. System Model ..................................................................................................................... 22
4.1.1 Use Case Model ........................................................................................................................ 22
4.2. Object Model ...................................................................................................................... 34
4.2.1. Class Diagram ........................................................................................................................... 34
4.2.2. Data Dictionary ......................................................................................................................... 36
4.3. Dynamic Model .................................................................................................................. 39
4.3.1. Sequence Diagram .................................................................................................................... 39
4.3.2. Activity Diagram ...................................................................................................................... 50
4.3.3. State Chart Diagram .................................................................................................................. 58
CHAPTER FIVE ............................................................................................................................. 64
5. SYSTEM DESIGN ................................................................................................................... 64
5.1. Design Goals ...................................................................................................................... 64
V
5.2. Proposed System Architecture ........................................................................................... 65
5.2.1. Subsystem Decomposition and Description ............................................................................. 66
5.2.2. Hardware/Software Mapping .................................................................................................... 68
5.2.3. Detailed Class Diagram ............................................................................................................ 70
5.2.4. Persistent Data Management..................................................................................................... 72
5.2.5. Access Control and Security ..................................................................................................... 74
5.3. Packages ............................................................................................................................. 75
5.4. Algorithm Design ............................................................................................................... 75
5.5. User Interface Design ......................................................................................................... 76
References ........................................................................................................................................ 78
VI
LIST OF TABLE
Table 1.1 Hardware tools -------------------------------------------------------------------------------------------------------- 9
Table 1.2 Software tools --------------------------------------------------------------------------------------------------------- 9
Table 1.3 Development languages --------------------------------------------------------------------------------------------- 9
Table 4.1 Use case identification----------------------------------------------------------------------------------------------24
Table 4.2 Data dictionary for Block ------------------------------------------------------------------------------------------36
Table 4.3 Data dictionary for user account ----------------------------------------------------------------------------------36
Table 4.4 Data dictionary for Allocated students --------------------------------------------------------------------------37
Table 4.5 Data dictionary for list of students to be allocate -------------------------------------------------------------38
Table 4.6 Data dictionary for comments of different user ---------------------------------------------------------------38
Table 5.1 Access privileges for users ----------------------------------------------------------------------------------------75
VII
LIST OF FIGURES
Figure 1-1 Iterative methodology ---------------------------------------------------------------------------------------------- 8
Figure 2-1 Form for allocation-------------------------------------------------------------------------------------------------12
Figure 2-2 Form for materials allocate to student--------------------------------------------------------------------------13
Figure 2-3 Document for comments ------------------------------------------------------------------------------------------14
Figure 2-4 Forms for cafe food stock out ------------------------------------------------------------------------------------15
Figure 2-5 Forms for material stock out -------------------------------------------------------------------------------------15
Figure 4-1 Use case diagram ---------------------------------------------------------------------------------------------------25
Figure 4-2 Class diagram -------------------------------------------------------------------------------------------------------35
Figure 4-3 Data dictionary for room------------------------------------------------------------------------------------------39
Figure 4-4 sequence diagram for login---------------------------------------------------------------------------------------40
Figure 4-5 Sequence diagram for Delete user account --------------------------------------------------------------------41
Figure 4-6 Sequence diagram for Generating report ----------------------------------------------------------------------42
Figure 4-7 sequence diagram for create user account ---------------------------------------------------------------------43
Figure 4-8 Sequence diagram for update user account -------------------------------------------------------------------44
Figure 4-9 Sequence diagram for register block ---------------------------------------------------------------------------45
Figure 4-10 sequence diagram for allocate dorm --------------------------------------------------------------------------46
Figure 4-11 Sequence diagram for Student view dorm -------------------------------------------------------------------47
Figure 4-12 Sequence diagram for View student information-----------------------------------------------------------48
Figure 4-13 sequence diagram for change user password ----------------------------------------------------------------49
Figure 4-14 Activity diagram for login --------------------------------------------------------------------------------------51
Figure 4-15 Activity diagram for Create user account --------------------------------------------------------------------52
Figure 4-16 Activity diagram for registering block -----------------------------------------------------------------------53
Figure 4-17 Activity diagram for allocate dorm ---------------------------------------------------------------------------54
Figure 4-18 Activity diagram for view dorm -------------------------------------------------------------------------------55
Figure 4-19 Activity diagram for view student info -----------------------------------------------------------------------56
Figure 4-20 Activity diagram for forget password ------------------------------------------------------------------------57
Figure 4-21 state chart diagram for login ------------------------------------------------------------------------------------59
Figure 4-22 state diagram for view dorm info ------------------------------------------------------------------------------60
Figure 4-23 state chart diagram for register block -------------------------------------------------------------------------61
Figure 4-24 state chart diagram for generate report -----------------------------------------------------------------------62
Figure 4-25 state chart diagram for submit comment ---------------------------------------------------------------------63
Figure 5-1 Proposed system architecture ------------------------------------------------------------------------------------66
Figure 5-2 Subsystem decomposition ----------------------------------------------------------------------------------------68
Figure 5-3 component diagram ------------------------------------------------------------------------------------------------69
Figure 5-4 Deployment diagram ----------------------------------------------------------------------------------------------70
Figure 5-5 Detailed class diagram --------------------------------------------------------------------------------------------71
Figure 5-6 Persistent diagram --------------------------------------------------------------------------------------------------73
Figure 5-7 User Interface prototype ------------------------------------------------------------------------------------------77
VIII
LIST OF ABBREVATIONS
GB: - Giga Byte
RAM: - Random Access Memory
HTML: - Hyper Text Markup Language
CSS: - Cascading Style Sheet
PHP:-Preprocessor Hypertext Preprocessor
MS Word: - Microsoft Word
ETB: - Ethiopian Birr
GHz: - Giga Hertz
CPU: - Central Processing Unit
XAMPP: - Xerox Apache MySQL Perl PHP
WAMP: - Window Apache MySQL PHP
MySQL: - My Standard Query Language
MS_ppt:- Microsoft Power Point
ARU: - Arsi University
BR: - Business Rule
DMS: - Dormitory Management System.
IX
ABSTRACT
After Comment
X
Chapter one
1. Introduction
Technology is spreading its wing in almost every walks of human life activities. Now a day it is better
if every activity is done using new technology in order to fulfill the need of human being,
Organization, Enterprise etc. As today’s world there are many organizations and each organizations
needs to be preferable, computable and work on fastest way in order to satisfy users interest etc. i.e.
they should have facilitate their activities in computerized way.
Hence, developing the system using technology has a tremendous effect for organizations and offices;
which is in our case the Arsi University dormitory management system. Currently, the system is
manual based; due to this the students and proctors faces some problems. Because of this, we are
initiated to develop our project on dormitory system in order to minimize the problem by using
computerized system.
1
Innovation
Respect diversity environment friendly
Efficiency and effectiveness
Professional commitment
Transparency
Generally, for the above and other problems the existing dormitory management system is weak in all
aspects and need to be automated in to functional system.
2
1.3. Objectives of the Project
1.3.1. General Objectives
The general objective of this project is to develop automated Dormitory Management System for Arsi
University.
1.3.2. Specific Objectives
The aim of this project is to achieve general objective of project with the following specific objectives:
Studying and analyzing the existing system.
Identify the problems of the existing system.
Perform requirement analysis.
Design the architecture for the project.
Implement and test the system for validation under variety of conditions
Demonstrate the potential of the system for further application and scalability.
The system to be developed is economically feasible and the benefit is outweighing the cost. Since
this project already computerizes the existing system, by now the reduction of cost for materials used
in manual operation becomes beneficiary to the organization. Generally the system that will be
developed, brought a number of tangible and intangible benefits.
University: the university gets better audience, reduces extra cost for stationary materials and
employee salary and succeeds its way toward modern technology.
o Updating or modifying
Generating latest report of general block assigned, registered room and assigned students.
6
cannot maintain from the interview or others and also it is important if they are unable to
communicate with stakeholder because of the language difficulties they have.
C. Questionnaires: since dormitories have work load they cannot able to answer/give
information what we ask. So we will prepare some sample questions to get précised
information.
D. Existing document: To get more information about the project we will use earlier documents
that help us to develop the project. During the analysis of documents, we give a special
consideration to those documents which can bring more features to the project.
1.7.2. System analysis and design techniques
Here for the analysis of our project we have selected object oriented system analysis and design
method specifically UML (Unified Modeling Language) model.
This has the following phases: -
Object Oriented Analysis (OOA): During this phase the team used to Model the
functions of the system (use case modeling), Find and identify the business objects,
Organize the objects and identify the relationship between them and finally model the
behavior of the objects.
Object Oriented Design (OOD): During this phase the team used to refine the use
case model to reflect the implementation environment, Model object interactions and
behaviors that support the use case scenario, and finally update object model to reflect
the implementation environment.
We have selected this techniques because of the following advantages:-
To simplify the design and implementation of complex program.
To make it easier for teams of designers and programmers to work in a single software
project.
To enable a high degree of reusability of designs and of software codes.
To decrease the cost of software maintenance.
Increase reusability.
Reduce maintenance burden.
Increased consistency among analysis, design and programming activities.
Improved communication among users, analysis, design and programming.
7
1.7.3. System Development Models
Software development methodology we are going to use for our system development is iterative
software development methodology. Iterative development is a rework scheduling strategy in which
time is set aside to revise and improve parts of the system. This model iterates requirements, design,
build and test phases again and again for each requirement and builds up a system iteratively till the
system is completely build.
I. Unit testing: - To test the independent module using this mechanism of testing.
II. Integration testing: - using this type of testing method to test the modules which are
independent and dependent to each other.
III. System Testing: -using this methods will test the functionality of all modules considering
as a single system. System will be tested using the following system testing procedures.
Alpha testing:-In this testing method, the system will tested by giving the correct
input. It is tested by a customer at the developer Site.
Beta testing: -In this testing method, team will force the system to be tested for
incorrect data input.
8
1.8. System Development Tools and Techniques
While developing the project starts from the documentation to the implementation we will use the
following case tools:
Hardware Tools
TOOLS ACTIVITIES
Flash disk with >=8 GB To transfer data from one computer to the other computer.
Used for recovery purpose.
Both desktop and laptop computer To input data, to display the output, to do the main programs and to insert input and
with >=4 GB RAM and 500 GB to store information.
(this specifications are a minimum
requirement)
Printer For print the documentation.
Ethernet cable Used for connection to access different information that helps our projects.
Table 1.1 Hardware tools
Software Tools
TOOLS ACTIVITIES
Notepad++, Sublime_Text_2.0.2 For code editing
Chrome, Internet explorer, Opera mini Browser
MS Word For write documentation part.
MS_ppt For presentation purpose.
Edraw Max To draw different diagrams.
Table 1.2 Software tools
Development languages
Languages used Purposes used for
HTML
JavaScript For Client side scripting or front end development
CSS
PHP For Server side scripting
MySQL Database for data storage and access
Table 1.3 Development languages
9
CHAPTER TWO
2. DESCRIPTION OF EXISTING SYSTEM
10
Generating allocation report: based the dormitory allocation the allocation report is prepared
and posted for student when they arrive at the campus after annual break.
Managing and controlling dormitory materials: at the beginning and end of each year,
dormitory materials are recorded and controlled whether they are functioning properly or not,
then appropriate measure is taken.
Controlling student’s discipline: In addition to the above functionalities student’s discipline
measures are controlled and recorded, whether they use the dormitory materials properly or not,
and whether they act and perform things as per the dormitory rules and regulations.
11
Figure 2-1 Form for allocation
12
Figure 2-2 Form for materials allocate to student
13
Figure 2-3 Document for comments
14
Figure 2-4 Forms for cafe food stock out
15
2.5 Drawbacks of the Existing System
The manual dormitory management system have many drawbacks. These drawbacks can be seen from
the following perspectives like performance, information, economic, control, efficiency and services
given by the existing system to the users.
The performance of any system is required to show to meet the needs of users of that system.
The current system’s performance is weak and measured by its throughput and response time.
o Response time:-the performance of the current system is weak because of its response
time is very high. For instance when proctor want to update or change the allocation
information of a student who assigned wrongly in the existing system, it takes too much
time to search the document and change it.
o Throughput: - due to every task is performed by manual way the throughput of the
existing system is very high. For instance when the proctor manager arranges blocks for
allocation it sakes too much time to arrange the buildings.
Information- the main input for the current system is student record and records of different
dormitory materials which enable the system to rearrange students and buildings for the
allocation. Based on this the system rearranges and allocates dorms for students at the
beginning each academic year and generates the allocation report which may be viewed by the
students as well as the management. The other data that is stored is record of materials
associated with the dormitory. The system manipulates and manages all of these and other
records manually on papers.
Economy
From view of material, there is high resources usage for unnecessary expanses, like paper,
pen and etc. For a number of students per dorms there is a number of paper. The same is true
for report purpose also. This cause the university to spend more money for regularly buying
of those stationary materials.
From view of man power, since there are a number of proctor managers and proctors for
allocation purpose only, the university has to pay salary for each employee. This factor also
lead university to spend extra money for employee salary.
Controlling- since all the records associated with the manual system are recorded and stored
manually the security that the system provide for the privacy of this records is not good. The
system shouldn’t provide sufficient protection for access and manipulation of the records
16
associated with the system.
Efficiency
o Time wastage: - employees waste time due to manual: - data processing, data entry, report
generation and Preparation of different forms.
o Material wastage: - The organization wastes many materials especially concerning
stationery materials, and file cabinets.
Services- The services given to users is not flexible i.e. the users (proctor manager, proctor and
student) must be in the university to access the system. For instance students must be in the
university to see their dormitory information stumped on the wall of buildings.
Space reservation problems: - the manual system is using papers for storing information. As
the number of students is increasing and information is stored redundantly, the space reserved
for storing this information is more than required.
17
CHAPTER THREE
3. PROPOSED SYSTEM
Login
Search information
accept comment
The system should store all the data related with all the tasks performed into a database.
Data processing: The system on input data will provide the following data processing:
Member’s validation
Verify the requested information (delete, update, search, add based on granted users, forgot
password)
Search user request (view dorm placement, view report, view assigned students).
Validate submission details (files like comment, private property, and student ask basic
service)
Generally, the functional requirements of our system is that it provides almost all functionalities of
existing system and provides advanced services for user/client of system over existing system.
19
The system will use high memory capacity and high processing speed computers to help users in
getting instant responses.
3.3.3. Security Issues
This system provides an access to an authorized user by giving account for each and every special
function. Students can view their dorm information by using their identification card number and/or
registration number, and give comment without any validation.
3.3.4. Performance Consideration
Performance requirements are concerned with quantifiable attributes of the system such as
System should quickly respond for user request that is system must immediately display
the needed service along with their allocation details after he/she insert needed information
to view. Since the system will be accessed by different users with different needs, it is
capable of handling and processing their queries quickly. Usually it is hard to tell exactly
how many users will be using the system at a time. However, if the system is being accessed
by many, all the users must feel that they are the only one using the system.
3.3.5. Error Handling and Validation
When the user makes some mistakes the system will responds that error is occurred using easily
understandable messages and allows the user to recover from the error. The system should handle
error and extreme condition during operation. The error could occur because of user of the system
itself. In the case of error occurred because of human error while login to the system or entering data,
the error should be handled by appropriate exception handling mechanism. Like displaying message
which tells user’s that user name or password or data entered is incorrect. Error due to system failure
will be handled by having a regular data back up during system operation.
3.3.6. Quality Issues
Information in database should be as much as possible correct and updated in each semester.
3.3.7. Backup and Recovery
A backup or the process of backing up refer to making copies of data so that these additional copies
may be used to restore the original after a data loss event. These additional copies are typically called
"backups." Backups are useful primarily for two purposes.
1. The first is to restore a state following a disaster (called disaster recovery).
2. The second is to restore small numbers of files after they have been accidentally
deleted or corrupted.
20
There are several realistic methods for backing up data. Some of them are Flash Memory, DVD
Backup, Tape Backup, and Hard Drives. The best backup method for data depends upon many
factors, including: the importance of the data, the amount of data to be backed up, and the funds
available for backup.
For the system we are going to develop, we choose Hard Drives because copying and retrieving
data from separate hard drives is very easy and cheap compared to tape drive systems. All we have
to do is plug the hard drive into our computer’s USB port. And while hard drives do fail, their
failure rate is much lower than that of backup media such as CDs.
3.3.8. Physical Environment
Physical environment, mainly concerns with the environment in which system will perform better. So
those physical environment ranges from air condition under which server operates to ergonomics
arrangement of server-client computers. Since Arsi university is currently growing in technology
issues from time to time. Its main data center may afford server machine to deploy the system
effectively. The system is expected to withstand the following external factor. • Less processor speed
of personal computer that are caused by dust and other unnecessary things happened in client
computers for accessing the system.
Less power that causes the system fail or stop functionality.
The server and the other devices in which system installed should kept in a secured and air-
conditioned rooms.
3.3.9. Resource Issues
On the server side the resource required by the server will be a hung memory space, high speed
processor and good connection to serve many users. However on the client side, internet access and
connection speeds many become an issue.
21
CHAPTER FOUR
4. SYSTEM ANALYSIS
Logout
24
Constructing Use case Diagrams
26
Precondition: The Administrator must log in to the system.
Flow of action:
Actor Action:
Step3: The system displays the option as create account and remove account.
27
Step4: The user fills all the required fields.
System response:
28
Alternative course of action: (if student identification number is not existing)
The system display error messages that student identification is not exist.
Go to step 4
Post condition: The system displays the detailed information.
Step3: The system reorders the comments according to the time of delivery
Step4: The administrator selects one at a time from the given options.
Step3: The system will give the options like delete, update or search record.
31
Use Case Name: View Student Info
Use case Id: UC09
Description: the user can view the detail information about the dorm as well as the student.
Actors: Proctor manager, proctor.
Precondition: The user must have a full privilege to access the information.
Flow of action:
Actor action
Step1: The user log to his/her page.
Step3: The system displays the form to select and to enter the criteria’s.
Step5: The system displays the detail information about the student.
The system display error messages that the input values are incorrect.
Go to step 3
Use case end
Post condition: The user gets the information.
32
Step2: The user select generate report link
Step4: The user selects the criteria from the given options and clicks on Display button.
System response:
Step3: the system displays the options (criteria)
Step5: The system displays the information to the user
Step6: Use case ends
Alternative course of action: (the system verify information is not correctly)
33
4.2. Object Model
An object model is a logical interface, software or system that is modeled through the use of object-
oriented techniques. It enables the creation of an architectural software or system model prior to
development or programming.
4.2.1. Class Diagram
A class diagram is the building block of the system that we are going to develop that shows the objects
the system is comprised of and how they are interrelated. It represents a detailed view of a single use
case and the classes that participate in the use case. Class diagram contains attributes and operations.
The following are components that are useful to model a class diagram.
Classes: has members and method that operates or performs the behavior of objects.
Responsibilities: - A responsibility is anything that a class knows or does.
Associations: -Associations are modeled as lines connecting use cases and actors to one
34
Figure 4-2 Class diagram
35
4.2.2. Data Dictionary
A data dictionary is a collection of data definitions used by applications to describe and access a
database. As described in the system it comprises a number of tables which are stored in MYSQL
server.
Table name Block
Room_No Int 5 Not null Used to hold number of rooms on each block
37
Table name Registrar
Block_no Varchar 30 Not null Holds block id, to which room belongs
Materials_available Varchar 500 Not null Holds materials available in that room
39
Figure 4-4 sequence diagram for login
40
Figure 4-5 Sequence diagram for Delete user account
41
Figure 4-6 Sequence diagram for Generating report
42
Figure 4-7 sequence diagram for create user account
43
Figure 4-8 Sequence diagram for update user account
44
Figure 4-9 Sequence diagram for register block
45
Figure 4-10 sequence diagram for allocate dorm
46
Figure 4-11 Sequence diagram for Student view dorm
47
Figure 4-12 Sequence diagram for View student information
48
Figure 4-13 sequence diagram for change user password
49
4.3.2. Activity Diagram
Activity diagrams are used to Document the logic of a single operation /methods, a single use case,
or the flow of logic of a business operation. In many ways, Activity Diagrams are the object_ oriented
Equivalent of flow charts and Data Flow Diagrams (DFD) from Structure. Activity diagrams are used
to show how different work flows in the system are constructed, how they start and the possibly many
decision paths that can be taken from start to finish. They may also illustrate the where parallel
processing may occur in the execution of some activities.
50
Figure 4-14 Activity diagram for login
51
Figure 4-15 Activity diagram for Create user account
52
Figure 4-16 Activity diagram for registering block
53
Figure 4-17 Activity diagram for allocate dorm
54
Figure 4-18 Activity diagram for view dorm
55
Figure 4-19 Activity diagram for view student info
56
Figure 4-20 Activity diagram for forget password
57
4.3.3. State Chart Diagram
A state chart diagram is a view of a state machine that models the changing behavior of a state. State
chart diagrams show the various states that an object goes through, as well as the events that cause a
transition from one state to another.
The common model elements that state chart diagrams contain are:
States
Transitions
A state represents a condition during the life of an object during which it satisfies some condition or
waits for some event. Start and end states represent the beginning or ending of a process.
58
Initial State
Idle State
Activate
Home
Page
Select
Login
Link
Fill
Login
Form
Incorrect
Verify Correct Confirm
Login
Display Appropriate
Page
Logout
Final state
59
initial State Idle
activate
Home
Page
select
View DormInfo
Link
fill
Search
form
Doesn't exist
Check exist Confirm
Search
Display Dorm
Information
final state
60
initial State
Idle
activate
Home
Page
Log to
the page
select
Register Block
fill
Registration
Form
Incorre ct
Validate Correct Confirm
Register
Display Successfull
message
final state
61
initial State Idle
activ ate
Home
Page
se le ct
Se le ct Re port
Link
se le ct
Se le ct
Re port Type
Displaye d
final state
62
initial State
Idle
activate
Home
Page
select
Select
Comment Link
fill
Comment
Form
Incorrect
Validate Correct Confirm
Comment
Display Successfull
message
final state
63
CHAPTER FIVE
5. SYSTEM DESIGN
System design is the transformation of the analysis model into a system design model. Up to now we
were in the problem domain. System design is the first part to get into the solution domain in a
software development. This chapter focuses on transforming the analysis model into the design model
that takes into account the non-functional requirements and constraints described in the problem
statement and requirement analysis sections discussed earlier.
The purpose of designing is to show the direction how the system is built and to obtain clear and
enough information needed to drive the actual implementation of the system. It is based on
understanding of the model the software built on.
Performance: The system should respond fast with high throughput, i.e. it should perform
the task quickly possible as possible such as allocating students and proctors, viewing
student and dormitory information etc. Furthermore, the system should not be taking up too
much space in memory.
Reliability: system should be reliable.
Fault Tolerance: system should be fault tolerant to loss of connectivity with the service.
Maintenance: The system should be easily extensible to add new functionalities at a later
stage. It should also be easily modifiable to make changes to the features and functionalities.
Usability: From the end users’ perspective the system should be designed in such a way
that it is easy to learn and use, efficient and having few errors if any.
Efficiency: The system must do what it is supposed to do efficiently without the problem.
64
Security: The system should be secured from unauthorized user.
Reliability: system should be reliable.
Fault Tolerance: system should be fault tolerant to loss of connectivity with the service.
Cost: The system should be developed with minimum cost possible. In reality there is
always trade-offs or disadvantages and therefore from its previous experience the
University prefers to invest more on development cost than maintenance cost to minimize
bugs which may appear at the later stage.
End User Criteria: - The system should have simple and understandable graphical user
Interface such as forms and buttons, which have descriptive names. It should give reliable
response for each user request at least before the session expires. All the interfaces, forms
and buttons are written or designed in a simple language or common language so that the
user can access it without any difficult.
Browser: These include Mozilla Firefox, Google Chrome, Opera Mini, Internet Explorer, and
some others browsers. These are used to run the system in the computer system.
Web server: It is the heart of system. It has a lot of responsibilities to perform like to
communicate with clients and database. Since the system is network-connected, it uses HTTPs
to send and receive data. HTTPs Protocol used for communication between two
devices/machines over the network to interact with each other.
MYSQL Database: Is the database software deals with the storing and managing the data
based on the request from the web server. It will write new records to the storage and will
retrieve and deliver to the web server when needed. MySQL is one of the most popular
database technologies in the world. Known for being secure and scalable, it is the go-to
solution for businesses of all sizes.
65
Figure 5-1 Proposed system architecture
This subsystem mainly provides persistent data storage and management facilities
to store, modify and extract information from the database. Request for information
from this database are made in the form of a query.
3. Webserver sub-system
67
Figure 5-2 Subsystem decomposition
68
So the purpose of the component diagram can be summarized as:
Deployment Diagram
The name Deployment itself describes the purpose of the diagram. Deployment diagrams are used for
describing the hardware components where software components are deployed. Component diagrams
and deployment diagrams are closely related.
Component diagrams are used to describe the components and deployment diagrams shows how they
are deployed in hardware.
70
Figure 5-5 Detailed class diagram
71
5.2.4. Persistent Data Management
Persistence modeling is used to communicate the design of the database, usually the data base to both
the users and the developers. It is also used to describe the persistence data aspect of the system. The
Persistent data is a data that must be stored in the database for future use with their data type and their
domain.
72
Figure 5-6 Persistent diagram
73
5.2.5. Access Control and Security
Access control and security describes the user model of the system in terms of an access matrix. This
section also describes security issues, such as the selection of an authentication mechanism, the use
of encryption, and the management of keys.
In the systems, different actors have access to different functionality and data. Define the access
controls for your system.
Access control rules
Privilege: every user of the system is privileged for some specific tasks. A user privileged to
access some data is allowed only to access the data that he/she have privileged to access. When
a user try to access the data that he/she haven’t allowed to access the system must ignore that
unauthorized user. Generally privilege is the assignment of the right authority to the right
person. The privilege is given based on the user type.
Authentication: identifying an individual who is trying to access the accounts secure data
and relevant information. The authentication process is based on username and password of
the user. When a user tries to login to the system the system asks for his username and
password. Then match the username and password he/she enter to login with the username
and password of his/her own account. If it doesn’t match the system reject the user to login to
the system. If it matches then the user is allowed to login.
Function User/Actor
74
Delete account Yes No No No
Register room No No Yes No
Allocate dorm No No Yes No
5.3. Packages
Package is a grouping mechanism for organizing elements into groups to increase their readability. In
other words, it is a grouping of model elements, such as use cases, or activities, defining scopes of
understanding. Packages are used to deal with complexity in the same way a user organizes files and
subdirectories into directories.
Our DMS comprises one main package DMS which in turn has six sub packages. Each subsystem is
depicted as a package.
75
Click the Login button
If (Form is filled)
If (valid)
Generate MYSQLI select queries
Connect to database
Pass queries to database
If (any query fails)
Display error message
Else
Read session
If session exists on database, user is already logged in,
Display the page
Else
Display the page error message
End if
End if
Else
Display error message
Ask the user to refill the form
End if
End if
76
Figure 5-7 User Interface prototype
77
References
78