Comprehensive Report: Student Housing Management System Project

This project report outlines the development of a student housing management system intended to replace the current ineffective methods used by the housing department. The proposed system aims to streamline processes such as student registration, house allocation, and inventory management. It includes detailed sections on vision, introduction, positioning, stakeholder descriptions, and key goals. The report covers system features, use case modeling (add student, issue house, allocate inventory item), system sequence diagrams, operation contracts, domain modeling, class modeling, dynamic modeling, and implementation considerations. The system is designed as a desktop application with a central MySQL database to facilitate a distributed environment for multiple users. The report also addresses assumptions, dependencies, cost estimates, and licensing agreements, providing a comprehensive overview of the project's scope and execution.

Cover page

Contents
1 vision........................................................................................................................................................3
1.2 Introduction.......................................................................................................................................3
1.3 Positioning.........................................................................................................................................3
1.3.1 Business opportunity..................................................................................................................3
1.3.3 Problem statement.....................................................................................................................3
1.3.4 Product position statement........................................................................................................3
1.4 Stakeholder descriptions...................................................................................................................3
1.5 Key high-level goals and problems of the stakeholders.....................................................................4
1.5.1 User level goals...........................................................................................................................4
1.5.2 User environment.......................................................................................................................4
1.6 Product overview...............................................................................................................................4
1.6.1 Product perspective....................................................................................................................4
1.6.2 Assumptions and dependencies.................................................................................................4
1.6.3 Cost and Pricing..........................................................................................................................4
1.6.4 Licensing and installation............................................................................................................5
1.7 System features.................................................................................................................................5
2 Use case modelling...................................................................................................................................6
2.1 Use case diagram...............................................................................................................................6
2.2 Use case description..........................................................................................................................6
2.2.1 Add student use case..................................................................................................................7
2.2.2 Issue house.................................................................................................................................8
2.2.3 Allocate inventory item..............................................................................................................9
2.3 System sequence diagrams........................................................................................................10
2.3.1 Add student sequence diagram.........................................................................................11
2.3.2 Issue house sequence diagram..........................................................................................12
2.3.3 Allocate item sequence diagram........................................................................................13
2.4 Operation contracts...................................................................................................................14
2.4.1 Contract C01: addStudent..................................................................................................14
2.4.2 Contract C02: issueHouse..................................................................................................14
2.4.3 Contract C03: AllocateItem................................................................................................14
3 Domain modelling..................................................................................................................................15

4 Class modelling and dynamic modelling.................................................................................................16
4.1 Class modelling................................................................................................................................16
4.2 Dynamic modelling..........................................................................................................................17
5 Implementation......................................................................................................................................20

1 vision
1.2 Introduction
The student housing system is in need of a management system that will help them keep track of the
houses allocated to students. Our group envisions a system that will operate to help the housing
department by making it easy to allocate houses to student and to track the allocations of the houses to
the students over a lengthy period of time.
1.3 Positioning
1.3.1 Business opportunity
The current system in use by the housing department is not up to date and does not take advantage of
the current advancement in technology. This presents a business opportunity as an up to date system
can be developed to make sure the housing department is advancing with the advancement in
technology.
1.3.3 Problem statement.
The current system in use by the housing department is not very effective considered to the number of
records and information the department has to deal with. Most information is stored in files while some
other information is stored in spreadsheets. This presents a problem to the department especially when
it comes to generation of reports as the process involved in generating the report is usually very handy
as the staff has to search in large sums of files. The reports includes the details of students
accommodated by the housing department and records of allocation of houses to the students by the
department.
1.3.4 Product position statement
The proposed student housing system will be implemented to replace the current system that is in use
by the housing department. The new system will provide a platform through which the department can
register all students in the system thus making it easy to retrieve any record of a student. The system
will also maintain records of all the houses managed by the housing department thus any allocation of a
house to a student will be done using the system. This will enable the department to track allocations of
all the houses. The system will also comprise of an inventory system which will keep records of the
assets owned by the housing department and issuance of the items to the houses.
1.4 Stakeholder descriptions
The stakeholders involved on this project can be classified as follows;
 Internal executive stakeholders- These stakeholders are comprised of the management of the
housing department. These stakeholders have a high influence on how the project will progress
and are very important to the project as they make all the decisions influencing the path taken
by the project (Felici, 2011).
 External executive stakeholders- These stakeholders are comprised of the administration under
which the housing department sits under. These stakeholders have a high influence because in
most cases they are the one who provide the capital thus their decisions are highly considered
(Torlak, 2015).
 Internal operation stakeholders – These stakeholders will be comprised of the users of the
system when it is deployed and fully operational.

 External operation stakeholders- These stakeholders are the developers who will come up with
the system and in this context these stakeholders are the members of our group.
1.5 Key high-level goals and problems of the stakeholders
To identify the high level-goals a requirements gathering process was conducted in collaboration with
the internal operation stakeholders to identify the requirements of the system.
1.5.1 User level goals
 The users should be able to register a new student to the system.
 The users should be able to add a house to the system.
 The user should be able to issue a house to the student through the system.
 The user should be able to be able to see records of issuance of the houses to the students.
 The user should be able to blacklist a student.
 The user should be able to add an inventory item and allocate it to a house.
 The user should be able to generate various reports based on the information stored by the
system.
1.5.2 User environment
The system will be designed and developed as a desktop application which will run on computers
running Windows 7 or above operating systems. The system will have a backend MySQL database which
will be used to store the data.
1.6 Product overview
1.6.1 Product perspective
The student housing system will run as a desktop application with a central MySQL database where
information will be stored. This will help create a distributed environment for the system to enable
multiple users to use the system while accessing and manipulating the same type of information.
Figure 1: Housing system context diagram
1.6.2 Assumptions and dependencies
The student housing system will run on windows thus the housing department should have computers
running on windows operating system. The database server will run on MySQL thus a powerful server is
needed to handle all the concurrent transactions.
1.6.3 Cost and Pricing
The cost estimated to come up with the system is $150,000. This cost will be used to acquire all the
hardware needed to run the system and also to pay the team of developers.

1.6.4 Licensing and installation
After deployment of the student housing system, the housing department will have acquired full
ownership of the deployed system but the development will maintain the right to use the codes of the
system or even some aspects of the design on other systems.
1.7 System features
 The system should be able to register a new student to the system.
 The system should be able to add a house to the system.
 The system should enable the user to issue a house to a student.
 The user system be able to be able to show records of issuance of the houses to the students.
 The system should be able to blacklist a student.
 The system should be able to add an inventory item and allocate it to a house.
 The system should be able to generate various reports based on the information stored by the
system.

2 Use case modelling
2.1 Use case diagram
Figure 2: Use case diagram
2.2 Use case description
The three use cases selected are;
 Add student
 Issue house
 Allocate inventory item

2.2.1 Add student use case
Use Case ID: UC1
Use Case Name: Add student
Created By: Author Last Updated By: Author
Date Created: 2/26/2017 Date Last Updated: 2/26/2017
Actors: User
Description: A housing system user adds a student to the system
Trigger: Add student button is pressed
Preconditions: 1. the user must be logged in to add a user
Postconditions: 1. The system should save the user to the database
Normal Flow: 1. User presses add new student button
2. System displays student registration form
3. User fills the form and presses save
4. System validates information
5. System saves and displays a success message
Alternative Flows: 4. System validates information
4.1 Information entered is incorrect
4.2 System displays an error message
4.3 System takes user back to step 3
Exceptions:
Includes: Filling registration form
Priority: High
Frequency of Use: Frequent
Business Rules: The student must be a student in the school
Special Requirements: The system is connected to the database at the time of registration
Assumptions: The user is supposed to enter the correct details in the system
Notes and Issues: If the system is not connected to the database, then this use case
will not work as described in the normal flow

2.2.2 Issue house
Use Case ID: UC2
Use Case Name: Issue house
Created By: Author Last Updated By: Author
Date Created: 2/26/2017 Date Last Updated: 2/26/2017
Actors: User
Description: The user issues a house to a student
Trigger: Issue house button is pressed
Preconditions: 1. the user must be logged in issue a house to a student
Postconditions: 1. The system should save the issue record to the database
Normal Flow: 1. User presses issue house button
2. System fetches all the students and all the houses
3. User selects student and the house and presses save
button
4. System validates and checks the student does not already
have a house and that the house is not occupied
5. System saves the record and displays a success message
Alternative Flows: 4. System validation
4.1 System finds the house is already issued to another student
4.2 System displays an error message
4.3 System takes user back to step 3
Exceptions: The room takes more than one student
Includes:
Priority: High
Frequency of Use: Frequent
Business Rules: The student must be a student in the school
Special Requirements: The system is connected to the database at the time of issuing a
house
Assumptions: Some houses might be accommodating more than one student
Notes and Issues: If the system is not connected to the database, then this use case

will not work as described in the normal flow
2.2.3 Allocate inventory item
Use Case ID: UC3
Use Case Name: Allocate inventory item
Created By: Author Last Updated By: Author
Date Created: 2/26/2017 Date Last Updated: 2/26/2017
Actors: User
Description: An inventory item is allocated to a house
Trigger: Allocate item button is pressed
Preconditions: 2. the user must be logged in to allocate an item
Postconditions: 2. The system should save the record to the database
Normal Flow: 1. User presses allocate item button
2. System fetches all the available items and all the houses
3. User selects the item and the house
4. System validates information
5. System saves and displays a success message
Alternative Flows: 4. System validates information
4.1 The item is not available
4.2 System displays an error message
4.3 System takes user back to step 3
Exceptions:
Includes:
Priority: High
Frequency of Use: Moderate
Business Rules: Every house is allocated to a number of inventory items
Special Requirements: The system is connected to the database at the time of allocating
the item
Assumptions: The user is supposed to enter the correct details in the system
Notes and Issues: If the system is not connected to the database, then this use case

will not work as described in the normal flow
2.3 System sequence diagrams
The following are the sequence diagrams for the use cases described in section 2.2 above

2.3.1 Add student sequence diagram
Figure 3: Add new student sequence diagram