Object – Oriented Modeling Design Final Project

Improvement of Dormitory System

By:
Achnes Choirun Nisa’
Bari Iffat Joesoef Habibi Junior

Industrial Engineering
Sampoerna University
2019

1
Table of Contents

I. Related Work .................................................................................................... 3

II. Introduction

a. Background ................................................................................................ 4

b. Problem Formulation ................................................................................. 4

c. Scope and Limitation ................................................................................. 4

d. Research Goals .......................................................................................... 4

e. Research Method ....................................................................................... 5

f. Research Benefit ........................................................................................ 5

III. Result and Discussion

a. Business Process Current System .............................................................. 6

b. Business Process Proposed System ........................................................... 6

c. Functional Requirement ............................................................................ 7

d. Non- Functional Requirement ................................................................... 8

e. Use Case Diagram ..................................................................................... 9

f. Use Case Description ............................................................................... 12

g. Sequence Diagram .................................................................................... 20

h. Activity Diagram ...................................................................................... 31

i. Class Diagram .......................................................................................... 36

j. Conceptual Data Modelling ..................................................................... 37

k. Logical Record Structure ......................................................................... 38

l. Design Form ............................................................................................. 40

m. Model Data Relational ............................................................................. 50

n. Specification Data Base ........................................................................... 52

IV. Conclusion ...................................................................................................... 56

2
 Improvement of Dormitory System

I. Related work
For a student who goes to school with a dormitory, the system makes a distinct

impression on himself, especially with the system used to regulate their daily lives.

One of the schools with a dormitory system that the writer makes is the Sampoerna

Academy Boarding School Jakarta.

Sampoerna Academy Boarding School (SABS) is one of the high schools that

implements boarding systems. This school applies several licensing regulations for

LPV (Leaving, Permission, and Visit) to students who live in dormitories. Leaving is

a term used to ask permission from the dormitory to visit relatives' homes on

weekends (at 16.00 on Friday until 17.00 on Sundays). Permission is a term used to

request permission from the dormitory to leave the dorm area in one day (07.00 to

17.00 WIB). Whereas visit is a term used to ask permission from the dormitory for

families to visit the dormitory area.

After interviewing the heads of the SABS dormitories, we concluded that

many problems were faced to organize SABS students. Among them is the issue of

LPV licensing which is also related to student food ordering. The hostel must

manually check student data. They must check the data of students who apply for

permits one by one. Therefore, they need a long time to do this.

With this Object-Oriented Model and Design (OOMD) assignment, our group

decided to develop a new system in terms of this LPV. This system will greatly help

the dormitory because this system will utilize the technological sophistication in the

form of an android-based application.

3
 II. Introduction:

a. Background

Schools with dormitory systems have their own challenges in running the system. In addition

to having to run a learning system in the scope of the school but also have to run a system that is run

at the dormitory at once. One example of boarding schools is the Sampoerna Academy Boarding

School or often abbreviated as SABS. SABS itself has been established for six years. It cannot be

denied that if within six years SABS runs the system it must have problems or problems in

implementing the system. Therefore, one of the things that underlie the purpose of this report is to

provide solutions and also develop dormitory systems that already exist in boarding schools so that

the system is more integrated and also provides convenience in its implementation.

b. Problem Formulation

The problems faced in boarding systems in SABS are lack of integration in the 2 system

scope (Eating and LPV) which causes a lack of monitoring of the system running. To overcome this

problem, there is a need for development in existing and more computerized systems, so that the

system will be more integrated and also make it easier for board administrators to monitor the road of

the hostel system itself.

c. Scope and Limitation

In this final project report, the author only chooses 2 (two) crucial scope systems in the

boarding system, namely eating and LPV (Leaving, Permission, and Visit).

d. Research Goals

Can develop the system so that the existing system will be more integrated and also make it

easier for board administrators to monitor the road of the hostel system itself.

4
e. Research Methods

- Interview

The interview is done by asking questions to the resource person to find out the problems that

often arise in the implementation of the boarding system. This process is submitted with

questions orally.

- Observation

Writing is done by directly observing the workings of the system used and recording the

obstacles that occur to be processed further.

f. Research benefit

- Speed up the LPV licensing process.

- Reduce the risk of inaccuracies in the system.

- Can monitor the whereabouts of students.

- Reduce the risk of blurring done by students because students forget to write a permit letter.

- Practically, users can easily access Android-based applications rather than having to write on

paper.

5
III. Result and Discussion

a. Business Process Current System

The previous system used a manual system, namely, students had to write a permit

and staff had to correct student data one by one. Therefore, staff needs considerable time

in the process. In terms of permissions, students must collect the permit no later than

Wednesday at 17.00. while in terms of leaving, students must collect data earlier, namely

Tuesday at 17.00. After the student's permit is collected, the staff will check whether the

student has taken all the permissions or left or not, with whom they left, and where they

went. If anything suspicious is found, the staff will immediately cross out the student's

permission for permission or leaving. Slightly different from leaving, staff must convert

student licenses to parents or guardians of students. If parents allow, the staff will allow it

too. The staff must also check whether students will return before meals or after meals.

b. Business Process Proposed System

In the new system, the system will automatically do all the processes manually by the

previous system. Therefore, the time needed by the system is only a matter of hours to

process and cross-check student data. This new system is considered effective and

efficient because it can process data quickly, precisely, and reduce the risk of human

error.

6
c. Functional Requirements

a. Users must be able to access and download applications personally.

b. Users must be able to log in privately.

c. The system must be able to validate student data input and data in the dormitory.

d. Users must upload photos ID and user to the system for data validation.

e. The system must be able to limit students in terms of permissions and leaving with the

following requirements:

1. students may only take permissions on one of the days of the week.

2. students can only take permission and leave twice in one month.

3. Specifically for leaving, the user must refer to the parent's telephone number. then

the system will provide information to parents automatically.

f. The system must be able to channel student data out of the hostel with food ordering

vendors.

g. The system will process student data within 2 hours before departure.

h. The system must be able to detect whether the user has gone to the right place or not.

i. The system must be able to connect with a tap machine that the user will use to tap his

ID card before departure (in order to make student data really accurate).

j. The system must be able to read and verify code approval.

k. The system must connect with the student's GPS.

7
d. Non-Functional Requirements (Implementation)

a. The system must be able to validate student data in less than 5 seconds.

b. The system must be able to distribute data to dormitory and vendor of food boxes in

less than 5 seconds.

c. The system must be able to send notifications for less than 2 minutes to both students

and dormitories in the event of violations committed by students.

d. System work for less than 6 months.

e. The system will use the Java programming language.

f. Use of the system must be connected to the internet.

g. The system must be equipped with ID.

h. The system must be integrated with ID.

8
e. Use case

Use Case Diagram :

Figure 1. Use Case Diagram

Figure 2. Use Case Diagram

9
Figure 3. Use Case Diagram

Figure 4. Use Case Diagram

10
Figure 5. Use Case Diagram

Figure 6. Activity Diagram

11
f. Use Case Description

1. Use Case Making the Account

a. Use Case: Download the application

Actor: Students, phone

Goals: To make the account for a student that they use to purpose LPV

Description:

- The student must download the application in the application store on their

mobile phone.

- The phone should be connected with an internet connection.

b. Use case: Sign up

Actor: Students, phone, dormitory coordinator

Goals: To make the account for a student that they use to purpose LPV

Description:

- The student has to open the application.

- Students will press the “sign up” button to create their account.

- The student has to make a personal account.

- The student will use this account to purpose LPV.

c. Use case: Input student’s information

Actor: Students, phone, dormitory coordinator

Goal: To input the student’s data into the system

Description:

- The student will input the data. For example, name, house, ID number, phone

number, parent’s number, and etc.

12
 - These data will send to the dormitory coordinator.

- Dormitory coordinator will validate and verify the student’s data with the data

that they already have.

- If the data are matched, the student will get an account.

d. Use case: Account

Actor: Student

Goal: Student will use this account to login to the application

Description:

- The student will get an account.

- The student will create a username and also a password that will be used by the

student to login into their account.

2. Making account for Dormitory Staff

a. Use case: Download the application

Actor: Dormitory staff

Goal: To make account for dormitory as a administrator.

Description:

- Dormitory staff must download the application in the application store on their

mobile phone.

- The phone should be connected with internet connection.

b. Use case: Sign up as administrator

Actor: Dormitory staff and system

Goal: To make account for dormitory as a administrator.

13
 Description:

- Dormitory staffs have to have a personal account.

- They will click the “sign up as administrator” button.

- System will show different appearence with the different sign up.

c. Use case: Make account

Actor: Dormitory staff and system

Goal: Dormitory staff has to input their information and also set the password.

Description:

- Dormitory staffs will create their own account and also password.

- They also have to input their data and special code to make the account.

- System will save and also validate the data.

d. Use case: Input student’s data

Actor: Dormitory staff and system

Goal: Dormitory staff has to input student’s data (name, ID, etc) in order to

make the system easier to connect with the systm for student.

Description:

- After succeed making the account, dormitory staffs have to input the student’s

data.

- This data will be used as the reference data to cross check between the student’s

data and the dormitory's data.

14
3. Making Account for Catering

a. Use case: Download the application

Actor: Catering

Goal: To make account for catering in order to connect with the dormitory staffs

about ordering the food.

Description:

- Catering must download the application in the application store on their mobile

phone.

- The phone should be connected with internet connection.

b. Use case: Sign in as Staff

Actor: Catering and dormitory staff

Goal: To make account for catering in order to connect with the dormitory staffs

about ordering the food.

Description:

- Catering has to have a personal account.

- They will click the “sign up as staff” button.

- System will show different appearence with the different sign up data.

c. Use case: Account

Actor: Catering, dormitory staff, and system

Goal: Catering has to input their personal information and also set the password.

Description:

- Catering will create their own account and also password.

- System will save and also validate the data.

15
 - The system will automatically send catering’s data to the dormitory staff.

4. The Use Case Applies for Permissions

a. Use case: Login

Actor: Student, dormitory coordinator

Goal: Student has to login to their account before they purposed LPV

Description:

- The student will press the “login” button.

- The student will input their username and also their password.

b. Use Case: LPV form

Actor: Student, dormitory coordinator

Goal: Student will choose whether they will take leaving, permission, or visit in

that week.

Description:

- The student will choose one of the options (LPV)

c. Use Case: Fill the data

Actor: student, dormitory coordinator

Goal: To find out what is the purpose of students taking the LPV, who they go

to, on what date, at what time they leave the dormitory, what time they arrive at

the dormitory, at the house for whom they will sleep (only for leaving).

Description:

- Students must fill in all available data on the screen (the data based on what they

choose).

16
 - The student has it one day before they leave the dormitory.

- The student will get notification whether they are allowed to take LPV or not.

- The notification will send the latest 2 hours after submitting the data (in work

time).

d. Use Case: Term Condition

Actor: Student, dormitory coordinator, food vendor

Goal: Adjustments to the dormitory schedule.

Description:

- Dormitory coordinator will receive the student’s proposal.

- Dormitory coordinator should check whether the student has their LPV or not

(condition 1).

- Dormitory coordinator should check whether there is an event in that weekend

or not (condition 2).

- If the student meets the criteria for passing conditions 1 and 2, the dormitory

will allow students to take LPV.

- When the coordinator accepts the student's proposal, the data will directly send

to the catering.

- The student will get the access that they can use to verify their account that they

have approved.

5 Use Case Mechanism

a. Use case: Access

Actor: Student, machine, dormitory coordinator

17
 Goal: To facilitate the verification process between the student ID and approval

from the dormitory.

Description:

- The student will get access after their proposal approved.

- Access only be used once.

- The access is like a code.

b. Use case: ID card

Actor: Student, machine, dormitory coordinator

Goal: Do attendance with ID cards

Description:

- Students must have an ID card shared by the school

- This ID card cannot be lost because this is the student's access to the LPV

- Students will assign the ID card to a machine that has been provided

- Students will also enter the access approval code that the system has sent.

- Automatically, the machine will validate between LPV approval data and

student ID

- The machine will also record at what time the student goes at what time the

student returns.

- If a delay is found in the hour back to the dormitory, the machine will send a

notification to the dorm staff section.

6 Use case Controlling

a. Use Case: Student Permit Data

Actor: Dormitory coordinator, student

18
 Goal: Data storage by the system

Description:

- Student permission data will be stored by the system until the student performs

confirmation that he is in the dormitory.

b. Use Case: Destination

Actor: GPS, dormitory coordinator, student.

Goal: Ensure the destination of LPV correctly

Description:

- Every student who gets permission to LPV, the system will directly connect

between student cellphones and GPS systems.

- If the student does not go to the destination that has been written, the system

will send a notification to the dormitory coordinator.

19
g. Sequence Diagram
1. For Student

Figure 1. Sequence Diagram

20
Figure 2. Sequence Diagram

21
Figure 3. Sequence Diagram

Figure 4. Sequence Diagram

22
Figure 5. Sequence Diagram

Figure 6. Sequence Diagram

23
Figure 7. Sequence Diagram

24
2. For Dormitory

Figure 8. Sequence Diagram

25
Figure 9. Sequence Diagram

26
Figure 10. Sequence Diagram

Figure 11. Sequence Diagram

27
 Figure 12. Sequence Diagram

3. For Catering

Figure 13. Sequence Diagram

28
Figure 14. Sequence Diagram

29
Figure 15. Sequence Diagram

30
h. Activity Diagram

Figure 1. Activity Diagram

31
Figure 2. Activity Diagram

32
Figure 3. Activity Diagram

33
Figure 4. Activity Diagram

34
Figure 5. Activity Diagram

35
i. Class Diagram

Figure 1. Class Diagram

36
j. Conceptual Data Modelling

Figure 1. Conceptual Data Modelling

37
k. Logical Record Structure

Figure 1. Logical Record Structure

38
l. Design Form

General Form:

39
40
1. For Student

41
42
43
2. For Dormitory

44
45
46
3. For Catering

47
48
49
 m. Model Data Relational

A. The form of the Logical Record Structure converted into a relation or table is displayed in the

table as follows:

1. Tabel data Student

Full ID House Room Phone Email ID Parent’s Parent’s Set

name number number photo name number Password

PK, CK PK, CK

2. LPV Form

Student’s name ID number Date Duration Purpose LPV code

PK PK PK

FK

3. Dormitory

Username NIP Password Term Validate LPV Access Licencing

Condition Code code

PK

FK PK PK

4. Catering

Username ID catering Password Receive Perizinan

notification

PK

FK

50
B. 1. Student

Student’s name ID Number Password Access code

PK, CK PK, CK

2. Machine

ID number Access Code

PK, CK PK, CK

FK FK

C. 1. Catering

User Name ID catering

PK

2. Dormitory

Username NIP ID catering

PK

FK

51
n. Spesification Data Base

Nama file : Student

Isi : Student’s data

Media : Harddisk

Primary Key : Student’s name, ID number

Panjang Record : 215

Jumlah record : 215000 (215 x 200 students x 5 years)

No. Field’s name Type Length

1. Student’s name Varchar 50

2. ID number Number 15

3. House Varchar 10

4. Room Varchar and Number 10

5. Phone Number Number 15

6. Email Varchar and Number 30

7. ID photo Picture -

8. Parent’s name Varchar 50

9. Parent’s number Number 15

10. Set Password Number 20

Nama file : LPV form

Isi : Student’s data to take LPV

Media : Harddisk

Primary Key :-

Panjang Record : 120

Jumlah record : 1,440,000 (120 x 2400 form/years x 5 years)

52
 No. Field’s name Type Length

1. Student’s Name Varchar 50

2. ID Number Number 15

3. NIP Number 15

4. ID Catering Number 10

5. LPV code Number 5

6. Licencing Varchar 20

7. Access code Number 5

Nama file : Dormitory

Isi : Dormitory’s data

Media : Harddisk

Primary Key : NIP, Access code, Licencing

Panjang Record : 140

Jumlah record : 3500 (140 x 5 accounts x 5 years)

No. Field’s name Type Length

1. Username Varchar 50

2. NIP Number 15

3. Password Number 20

4. Term condition Date and Varchar 30

5. Access code Number 5

6. Licencing Varchar 20

53
Nama file : Catering

Isi : Catering’s data

Media : Harddisk

Primary Key : ID catering

Panjang Record : 80

Jumlah record : 4800 (80 x 12 caterings x 5 years)

No. Field’s name Type Length

1. Username Varchar 50

2. ID catering Number 10

3. Password Number 20

Nama file : Student

Isi : Student’s data

Media : Harddisk

Primary Key : ID number, Access Code

Panjang Record : 85

Jumlah record : 1,020,000 (85 x 2400 form/years x 5 years)

No. Field’s name Type Length

1. Student’s name Varchar 50

2. ID number Number 10

3. Password Number 20

4. Access code Number 5

54
Nama file : Machine

Isi : Record student’s data

Media : Harddisk

Primary Key :-

Panjang Record : 15

Jumlah record : 180,000 (15 x 2400 form/years x 5 years)

No. Field’s name Type Length

1. ID number Number 10

2. Access code Number 5

55
IV. Conclusion

The system of Online LPV form will help not only the dormitory staff to monitoring the

students, but also help the students itself to easily make an LPV form everywhere without

taking a form paper in dormitory staff office. This system also gives advantages for the

dormitory staff to submit the orders related to student food. The system will be

integrating all system manuals that were previously used in LPV activities becomes easier

and more systematic in its processing.

56