JIMMA UNIVERSITY

INSTITUTE OF TECHNOLOGY
FACULTY OF COMPUTING AND INFORMATICS

DEPARTMENT OF INFORMATION TECHNOLOGY

CLASS SCHEDULING SYSTEM FOR JIT

Advisor name Signature

1. Mr. Zerihun Olana

2. Mr. Worku Berhanie

 Submitted to: Faculty of Computing
Submission date: May 24,
2021
 Group members

Name ID

1) Adugna Tadesse RU0614/10

2) Remla Habib RU0803/10

3) Sadam Ahmed RU0810/10

4) Adisu Ayana RU0612/10

 Acknowledgement

First of all, we would like to thank God for giving us the ability, patience and strength to conduct
and complete this project documentation. Second, we would like to acknowledge and thank our
advisors Mr. Zerihun Olana and Mr. Worku Berhanie for their enormous contribution and
patience.
 Abbreviations
UML: Unified Modeling Language

XML: Extended Markup Language

CBTP: Community Based Training Program

GUI: Graphical User Interface

UC: Use Case

CRC: Class Responsibility Collaboration

 List of Tables
Table 1: Project Schedule............................................................................................................................5
Table 2: Use Case table.............................................................................................................................10
Table 3: Create an account use case documentation table.........................................................................12
Table 4: Login use case documentation table............................................................................................12
Table 5: Register course catalog use case documentation table.................................................................13
Table 6: View class schedule use case documentation table......................................................................14
Table 7: View exam schedule use case documentation table.....................................................................15
Table 8: Request class schedule swap use case documentation table.........................................................16
Table 9: Approve swap request use case documentation table..................................................................17
Table 10: Update course catalog use case documentation table.................................................................18
Table 11: Generate class schedule use case documentation table..............................................................19
Table 12: Assign accounts use case documentation table..........................................................................20
Table 15: CRC for Department Coordinator class.....................................................................................35
Table 16: CRC for Teacher class...............................................................................................................35
Table 17: CRC for Student class................................................................................................................36
Table 18: CRC for Class_Schedule class...................................................................................................36
Table 19: CRC for Exam_Schedule class..................................................................................................37
Table 20: CRC for Account class..............................................................................................................37
Table 21: CRC for Swap_Request class....................................................................................................38
Table 22: Access control matrix................................................................................................................48
 List of Figures
Figure 1: Use case diagram........................................................................................................................11
Figure 2: Sequence diagram for Create an account....................................................................................21
Figure 3: Sequence diagram for login........................................................................................................22
Figure 4: Sequence diagram for view class schedule.................................................................................23
Figure 5: Sequence diagram for view exam schedule................................................................................24
Figure 6: Sequence diagram for register course catalog............................................................................25
Figure 7: Sequence diagram for swap invigilation duties..........................................................................26
Figure 8: Sequence diagram for swap class schedule................................................................................27
Figure 9: Sequence diagram for generate class schedule...........................................................................28
Figure 10: State chart diagram for create an account.................................................................................29
Figure 11: State chart diagram for login....................................................................................................30
Figure 12: State chart diagram for swap class schedule.............................................................................30
Figure 13: State chart diagram for view class schedule.............................................................................31
Figure 14: Activity diagram for create an account.....................................................................................32
Figure 15: Activity diagram for login........................................................................................................32
Figure 16: Activity diagram for register course catalog.............................................................................33
Figure 17: Activity diagram for update course catalog..............................................................................33
Figure 18: Activity diagram for view class schedule.................................................................................34
Figure 19: Activity diagram for swap class schedule.................................................................................34
Figure 20: Class diagram...........................................................................................................................39
Figure 21User interface prototype for create an account page...................................................................40
Figure 22: User interface prototype for login page....................................................................................40
Figure 24: Proposed software architecture.................................................................................................43
Figure 25: Subsystem decomposition diagram..........................................................................................44
Figure 26: Component diagram.................................................................................................................45
Figure 27: Deployment diagram................................................................................................................46
Figure 27: E-R diagram.............................................................................................................................47
Figure 28: Sample code of GenerateSchedule method for the GenerateClass Class..................................50
Figure 30: A sample code for assigning teachers.......................................................................................51
Figure 31: A sample code of the isTheTeacherReal method used for checking if the teacher is authorized
to make a swap request..............................................................................................................................51
Figure 32: Homepage of the app................................................................................................................52
Figure 33: Signup page of the app.............................................................................................................52
Figure 34: Swap Request UI of the app.....................................................................................................53
Figure 35: Register Course Catalog interface............................................................................................53
Contents
Abbreviations.............................................................................................................................................iii
Chapter One: Introduction...........................................................................................................................1
1.1 Background..................................................................................................................................1
1.2 Statement of the problem.............................................................................................................1
1.3 Objective.....................................................................................................................................2
1.3.1 General Objective.......................................................................................................................2
1.3.2 Specific Objective.......................................................................................................................2
1.4 Methodology................................................................................................................................2
1.4.1 Requirement gathering................................................................................................................2
1.4.2 System Analysis and Design technique......................................................................................3
1.4.3 Tools used...................................................................................................................................3
1.5 Feasibility....................................................................................................................................4
1.5.1 Technical Feasibility...................................................................................................................4
1.5.2 Operational Feasibility................................................................................................................4
1.5.3 Economic Feasibility..................................................................................................................4
1.5.4 Time Feasibility..........................................................................................................................4
1.6 Project Scope and Limitation.......................................................................................................5
1.7 Significance of the project...........................................................................................................6
1.8 Organization of the project..........................................................................................................6
Chapter Two: Analysis................................................................................................................................7
2.1 Existing System...........................................................................................................................7
2.1.1 Existing System Description.......................................................................................................7
2.1.2 Business Rules............................................................................................................................7
2.2 New System.................................................................................................................................7
2.2.1 New System Description............................................................................................................7
2.2.2 Non-functional requirements and constraints..............................................................................8
2.2.3 Functional Requirements............................................................................................................8
2.3 Use case.......................................................................................................................................9
2.3.1 Actor of the system.....................................................................................................................9
2.3.2 Use cases of the system..............................................................................................................9
2.3.3 Use case diagram......................................................................................................................11
 2.3.4 Use case description.................................................................................................................11
2.4 Sequence Diagram.....................................................................................................................21
2.5 State chart Diagram...................................................................................................................29
2.6 Activity Diagram.......................................................................................................................32
2.7 Class Responsibility Collaboration (CRC) Model.....................................................................35
2.8 Conceptual modeling: Class diagram.........................................................................................39
2.9 User interface prototyping.........................................................................................................40
Chapter Three: Design...............................................................................................................................41
3.1 Purpose and goals of design.......................................................................................................41
3.2 Current Software Architecture...................................................................................................42
3.3 Proposed software architecture..................................................................................................42
3.4 Subsystem decomposition..........................................................................................................43
3.5 Component diagram...................................................................................................................44
3.6 Deployment diagram.................................................................................................................46
3.7 Database design (E-R diagram).................................................................................................47
3.8 Access control and security.......................................................................................................48
Chapter Four: Implementation...................................................................................................................49
4.1 Objective of Implementation.....................................................................................................49
4.2 Programming Tools and technology overview...........................................................................49
4.3 Prototype of the Project.............................................................................................................49
4.3.1. Class scheduling system....................................................................................................49
4.4 Testing.......................................................................................................................................49
4.5 Sample code and UI screens......................................................................................................50
4.5.1. Sample code screenshots....................................................................................................50
4.5.2. Sample UI Screenshots......................................................................................................52
Chapter Five: Conclusion and Recommendations.....................................................................................54
5.1 Conclusion.................................................................................................................................54
5.2 Recommendation.......................................................................................................................54
References.................................................................................................................................................55
 Chapter One: Introduction
1.1 Background
Jimma Institute of Technology higher learning institute that is located in city of Jimma and is one
of the campuses that are under the Jimma University. In this project we will be working on
schedule management system for Jimma Institute of Technology. Scheduling systems are a
necessity within every organization, without them the organization will not be able to perform
their activities in efficient, effective and organized manner. Scheduling systems reduces the
effort of employees of the organization by producing time tables that makes the process of
performing their jobs easier.

1.2 Statement of the problem

Currently the scheduling system the campus uses is a manual one. The department coordinator
uses the course catalog the calculate the class schedules one rudimentary software’s such as
Microsoft word and this causes the scheduling system to have major drawbacks.

The problems with this system are not necessarily with the overall efficiency of the system rather
are with the fact that:

 The produced schedule is not available easily.

 Students are restricted in the way that they have to be in the university to even see the
schedule for their upcoming semester and the academic calendar for the year
 Student have no choice but to take photos of the schedules for their classes and the
academic calendar and this result in a static data, which doesn’t change unlike dynamic
schedules.
 The schedule might change at any moment and the students don’t know until the teacher
informs them.
 The students do not have platform to raise their concern about the schedule for their
classes.
This way of working makes the students not take part in the important life cycle of the schedule
of their classes and for this reason they are not given the opportunity to plan their days/years
efficiently.

1.3 Objective

1.3.1 General Objective

The general objective of this project is to develop an android-app based Class Scheduling System
for Jimma Institute of Technology.

1.3.2 Specific Objective

There are several specific objectives that we will follow in order to meet the general objectives
of the project. These objectives will have their own impact on the completeness of the project.
The project is expected to fulfill the following specific objectives.

 Studying and analyzing the current system

 Identify the requirement for the proposed system
 Design the proposed system based on the requirements
 Developing and testing the proposed system

1.4 Methodology
In this section we discuss the way gathered our system requirement and also how we structured
the requirement and developed the software models.

1.4.1 Requirement gathering

We have used the tools below to gather the user requirement for the system we are developing.

 Observation

We have observed how the current system works and we have decided the way of
working we want to add, change or remove form the system. This also has helped us to
see how the employee of the organization perform their works and how to make their
jobs easier.

 Interviewing
 We have interviewed various employees who are involved in the process of creating a
class schedule what they would like to change or add to the current system. We have used
both open ended and closed ended question to not limit the employee’s perspective on the
current system.

 Document Analysis

We have used the class schedule documents to see how the system creates and produce
the schedule, and analyzed these documents to see what are the limitation of this system
is and how it can be improved upon.

1.4.2 System Analysis and Design technique

In this project we will use object-oriented system development methodology (OOSD). we will
find and identify the business objects, organize the objects and identify the relationship between
them and finally model the behavior of the objects.

1.4.3 Tools used

In this project the tools we have used while developing this system are:

Hardware Tools

 Laptops
 Smart Phones
 Remote Servers (Google’s Firebase Realtime Database)

Software Tools

 Android Studio
 Java Programming Language
 Firebase tool add-on
 Android Operating System (to run the app)
 Internet access
 Edraw for UML design
 XML for the user interface design
1.5 Feasibility
In this portion of the project, we determine whether the proposed system is feasible and useful
for the organization. There are four main areas we consider while testing the feasibility of the
proposed system they are:

 Economic Feasibility
 Technical Feasibility
 Operational Feasibility
 Time Feasibility for building the new system.

1.5.1 Technical Feasibility

Our proposed system only requires that the user have a basic understanding of the
smartphone technology. It is easy to understand what the user interface components represent
and perform. The system will provide all the services by its own without the need for the
involvement of the developer. Therefore, it has a technical feasibility.

1.5.2 Operational Feasibility

The proposed system has operational feasibility because, it can provide the functionalities
we intend for the system to provide, and also because the system runs on the user’s smartphones
which will make it easier to access and use it without their inconvenience.

1.5.3 Economic Feasibility

The system we intend to build requires no initial cost because we are building it from
tools that are freely available but, it can save a large amount of inconvenience for the
organization which in turn will save the university a large amount of cost that has to be spend to
fix the problems caused. The system we will build does not require any new hardware to be
implemented both on the organization and the client side. The only requirements for the users to
use this system is say own and know how to operate a smartphone device. Many students are
familiar the smartphone technology and most of them own their own smartphones. Therefore, the
system is economically feasible for both the organization and the user.
 1.5.4 Time Feasibility
The time that has been given to us to complete this project is around four months. The
first two months for requirement gathering and design, and the next two months for
implementation. To finish our project on time we have organized a schedule to complete the
specific objectives within a specified amount of time. Based on the resulting schedule we have
determined that the project is time feasible.

Table 1: Project Schedule

In addition, the system once launched will be available 24/7, that means the user can access it
any time of the day.

1.6 Project Scope and Limitation

The scope of the proposed system includes the following main tasks, it will create a class
schedule, exam schedule, invigilator schedule and examiner/defense schedule all based on the
courses entered by the department coordinator. It will not include grade calculation, type of
exam, peer group creation or any other task other than the above listed.

Some of the limitations of the proposed system are:

 Requires that the user has smartphone with the ability to install foreign applications
1.7 Significance of the project
The significances of this project are to:

 Save the time that is lost while travelling to registral to get class schedule
 Making sure the schedule is from an authorized source
 To make the process of distributing schedules organized and fast
 Better and fast information distribution
 Allow the ability of exchange classes for teachers by going through the appropriate
channels.

We categorize the benefits of the system into tangible and intangible.

Tangible benefits:

 Reduced processing errors

 Decreased response time
 Manpower reduction
 Cost reduction

Intangible benefits:

 Improved customer satisfaction and convenience

 Improved student moral

1.8 Organization of the project

The project organization comprises four chapters. The first chapter is the introduction of
the project that includes background and existing System Study, statement of problem,
objectives, scope, methodology, significance and organization of the project.

The second chapter is System Analysis phase of the project. It deals with description of
existing system, description of the proposed system, functional requirements, non- functional
requirements and analysis models.

The third chapter is design of the project which contains class diagram, deployment
diagram, architectural design, user interface design, data structure design and algorithm design.
The final chapter includes implementation and testing

Chapter Two: Analysis

2.1 Existing System

2.1.1 Existing System Description

As we have said above there does exist a manual system that performs the scheduling task for the
university. The department coordinator will generate the class and exam schedule, and in
addition he/she will also generate an examiner or defense schedule if the list of courses for the
semester contains at-least one of the following: CBTP, Seminar, or Industrial Project course.
How the process works is that the department coordinator will use the current semesters’ course
catalog for their department and he will create the schedule based on the courses’ credit hours,
the available classrooms and lab rooms, and the number of students that the department has
decided to accept.

2.1.2 Business Rules

To understand the business rules first you have to understand how the university schedules the
classes. Each semester contains 4 months period of learning and as we know there are 4 weeks
within a month. Therefore, there will be a total of 16 weeks of learning time. Based on this the
business rules are:

 The system uses the course catalog for the lecture hours, lab hours, tutorial hours and
course code for each course and based on the data obtained will create the schedule by
assigning the appropriate lecture, lab and tutorial hour.

2.2 New System

2.2.1 New System Description

The new system we are building for the university is an android system that solves the
drawbacks of the existing system. It makes the process of creating schedules and making them
accessible easier. Students can easily view their class and exam schedules without any
inconvenience. Department coordinator inserts just the course catalog into the system and the
system will automatically generate the schedule based on the course catalog information,
available classrooms and labs and the number of students that the department has decided to
accept. It will also make sure there are no conflicts between different schedule such as:

 Making sure a teacher is not assigned a class at the same time in different schedules
 Making sure a classroom and laboratories must be available or unoccupied before being
assigned.
 Identifying exceptional business rules for certain courses.

2.2.2 Non-functional requirements and constraints

The following are the non-functional requirements associated with the new system.

 Security: -The project should allow only authorized user to login into the system, and
sensitive data is accessed and changed by authorized body.
 Usability: - The system should have an interactive and attractive GUI which eases users’
usage problem. The user needs no training, because the GUI is intuitive and self-
explanatory.
 User Interface: The interface should be user friendly and be able to properly guide the
user on to how to use the system.
 Performance: -The system should be able perform its task efficiently and effectively
within seconds, because of the simplicity of the algorithm.
 Portability: the authorized body should be able to modify the system easily and make it
adaptable to new devices because of the object-oriented nature of the code.
 Reliability: – The system should be effective and consistent in that integrity of
information is maintained and supplied to the system. [ CITATION ICV94 \l 1033 ][ CITATION
RLR86 \l 1033 ]

2.2.3 Functional Requirements

The system provides the following basic functionality: -

 The system should allow the students to create an account by allowing them to fill out a
form.
 The system should allow the department coordinator to insert the course catalog for the
current semester and assign user accounts for the teachers within their department.
  The system should be able generate and display the class schedule for the selected
department and section.
 The system should be able generate and display the exam schedule for the selected
department and section.
 The system should allow the teacher to make class schedule swapping request.
 The system should allow the teacher to make invigilator schedule swapping request.
 The users of the system should be able to Log in.
 The users of the system should be able to Log out.

2.3 Use case

Based on the functional requirements of the proposed system, the new system process is
modeled, and use cases and actors are identified. We relate actors with the corresponding use
cases as shown in the figure below.

2.3.1 Actor of the system

Actors: an actor represents anything or anyone that interacts with the system. This may include
people (not just the end user), external systems, and other organizations. Actors are always
external to the system being modeled; they are never part of the system. The actors that will
participate in the system are listed below:

 Student: can create user account by filling out required forms, and is able to view class
and exam schedule.
 Teacher: create user account by filling out required forms, and is able to view the class
schedule, view the exam schedule, view the invigilator schedule and request a schedule
swap.
 Department coordinator: can view all the schedules, add the current semester’s courses to
the system to generate a schedule and in addition they can also approve a schedule swap
requests from teachers. The coordinator acts as a system administrator and creates
accounts for the other teachers within their department.
 2.3.2 Use cases of the system
The Use case (UC) represents functionality provided by a system unit and expressed by sequence
of message exchange by the system unit and one or more actors of the system. The following use
cases have been identified for the proposed system specification.

Table 2: Use Case table

Use case name Use case Id Uses/Includes

Create account UC-01
Login UC-02
Register course catalog UC-03 Login
View class schedule UC-04 Login
View exam schedule UC-05 Login
Request class schedule swap UC-06 Login
Request invigilation duties UC-07 Login
swap
Approve swap request UC-08 Login
Update Course Catalog UC-09 Login
Generate Class Schedule UC-10 Login
Generate Exam Schedule UC-11 Login
Assign Account UC-12 Login
 2.3.3 Use case diagram

Figure 1: Use case diagram

2.3.4 Use case description

The following consecutive tables show the use case description for each of the use cases. Each
table contains the use case name, the actor that initiates and interacts with the use case,
description of the use case and typical course of events that show the interaction between the
actor and the use case which enable the team to easily depict the functions of the proposed
system.
Table 3: Create an account use case documentation table

Use case Id UC-01

Use case name Assign Account
Actors Department Coordinator
Description Make the user fill out the appropriate forms to
create an account.
Goal Create an account for the student
Precondition User should have an access to the system.
Basic course of Action Actor action System response
Step1: user clicks on Step2: the system
the “create an will respond by
account” button displaying form to be
Step3: the user will filled out.
fill out the necessary Step4: the system
parts and will click will validate the
signup. entered data and add
them to the system.
Alternative course of action Step4: If the data inserted is invalid.
1. The system displays error message.
2. The system continues at step (2) to take the
registration information again.
Post condition The system transfers to the users homepage.
Include
Exit condition Logout

Table 4: Login use case documentation table

Use case Id UC-02

Use case name Login
Actors Student, Teacher, Department coordinator, Registrar
Description It is authenticating bridge that allows user to login to
the system.
Goal To be accessed by an authorized and trusted system
user.
Precondition User should have an account with the system
Basic course of Action Actor action System response
Step1: user visits the login Step2: system displays the
 page login form.
Step3: user enters the Step4: the system
username and password authenticates the username
and password and display
user Home page.
Alternative course of action Step5. If the username and password is invalid.
1. The system displays error message.
2. The system continues at step (2) to fill username and
password again.
Post condition System transfer to user’s homepage
Include
Exit condition Logout

Table 5: Register course catalog use case documentation table

Use case Id UC-03

Use case name Register Course Catalog
Actors Department coordinator
Description The department coordinator will add the course
catalog for the semester to the system.
Goal Add the courses for the semester
Precondition The user should be logged in to the system.
Basic course of Action Actor action System response
Step1: the user will Step2: the system will
click on the “Register respond by displaying form
courses” button to be filled out.
Step3: the user will Step4: the system will
fill out the necessary validate the entered data
parts and will click and add them to the
add. system.

Alternative course of action Step4: The system will display an error message
because the courses entered are not valid/correct.
Post condition The system transfers to the users homepage.
Include Login
Exit condition Successful operation or back button.
Table 6: View class schedule use case documentation table

Use case Id UC-04

Use case name View class schedule
Actors Student, Teacher, Department Coordinator
Description The user will be able to display the class
schedule for the selected department.
Goal View the class schedule
Precondition The user should be logged in to the system.
Basic course of Action Actors action System response
Step1: the user will Step2: the system
click on the “view will respond by
class schedule” displaying the class
button. schedule for the
department
Alternative course of action Step2: The system will display a message
saying that the class schedule has not yet been
generated.
Post condition Display the class schedule or error message
Include Login
Exit condition Back button

Table 7: View exam schedule use case documentation table

Use case Id UC-05

Use case name View exam schedule
Actors Student, Teacher, Department Coordinator
Description The user will be able to display the exam
schedule for the selected department.
Goal View the exam schedule
Precondition The user should be logged in to the system.
Basic course of Action Actors action System response
Step1: the user will Step2: the system
click on the “view will respond by
exam schedule” displaying the exam
button. schedule for the
department
Alternative course of action Step2: The system will display a message
 saying that the exam schedule has not yet
been generated.
Post condition Display the exam schedule or error message
Include Login
Exit condition Back button

Table 8: Request class schedule swap use case documentation table

Use case Id UC-06

Use case name Request class schedule swap
Actors Teacher
Description Allow the teachers request to swap schedule slots
for their class.
Goal Change schedule time.
Precondition The user should be logged into the system.
Basic course of Action Actor action System response
Step1: user clicks on Step2: the system will
the “Request class respond by displaying
schedule swap” button the available schedule
Step3: the user will swaps.
choose which schedule Step4: the system will
swap they want to send a request to the
make. academic coordinator
Step5: if the swap was for approval.
approved then the
schedule will display
the new changes
Alternative course of action Step5: If the request was not approved then system
will display a message saying “your request has been
denied”.
Post condition The system transfers to the users homepage.
Include Login
Exit condition Back button
Table 9: Approve swap request use case documentation table

Use case Id UC-08

Use case name Approve swap request
Actors Department Coordinator
Description Allow the department coordinator to approve or
reject a swap request from teachers
Goal To approve the swap request from teachers.
Precondition The user should be logged into the system.
Basic course of Action Actor action System response
Step1: user clicks on Step2: the system will
the “Approve swap respond by displaying
request” button the request that hasn’t
Step3: the user will been reviewed yet.
choose a request to Step4: the system will
review. display the request
Step5: the user will details.
click on “approve”
button.
Alternative course of action Step5: If the request was to be denied then the user
will click on the “reject” button.
Post condition The system transfers to the users homepage.
Include Login
Exit condition Back button

Table 10: Update course catalog use case documentation table

Use case Id UC-09

Use case name Update Course Catalog
Actors Department coordinator
Description The department coordinator will update the course
 catalog inserted for the semester.
Goal Update the course catalog for the semester
Precondition The user should be logged in to the system.
Basic course of Action Actor action System response
Step1: the user will Step2: the system will
click on the “Update respond by displaying the
courses” button course catalog form to be
Step3: the user will edited.
edit the catalog and Step4: the system will
will click add. validate the inserted data
and add them to the
system.
Alternative course of action Step4: The system will display an error message
because the data inserted is not valid/correct.
Post condition The system transfers to the users homepage.
Include Login
Exit condition Successful operation or back button.

Table 11: Generate class schedule use case documentation table

Use case Id UC-10

Use case name Generate Class Schedule
Actors Department coordinator
Description The department coordinator will instruct the system
to generate the class schedule.
Goal Generate the class schedule for the semester
Precondition The user should be logged in to the system.
Basic course of Action Actor action System response
Step1: the user will Step2: the system will
click on the respond by generating class
“Generate class schedule for the semester.
 Schedule” button

Alternative course of action Step2: The system will display an error message
because the course catalog has not yet been inserted.
Post condition The system transfers to the users homepage.
Include Login
Exit condition Successful operation or back button.

Table 12: Assign accounts use case documentation table

Use case Id UC-12

Use case name Assign Accounts
Actors Department Coordinator
Description Allow the department coordinator to fill out
the appropriate forms to create an account for
the teachers within their department.
Goal Create an account for the teachers.
Precondition The user should be logged in to the system.
Basic course of Action Actor action System response
Step1: user clicks on Step2: the system
the “Assign will respond by
Accounts” button displaying form to be
Step3: the user will filled out.
fill out the necessary Step4: the system
parts and will click will validate the
signup. entered data and add
 them to the system.
Alternative course of action Step4: If the data inserted is invalid.
1. The system displays error message.
2. The system continues at step (2) to take the
registration information again.
Post condition The system transfers to the users homepage.
Include Login
Exit condition Logout

2.4 Sequence Diagram

Sequence diagrams are used to show how objects interact in a given situation. The interaction

starts near the top of the diagram and ends at the bottom.
Figure 2: Sequence diagram for Create an account
Figure 3: Sequence diagram for login
Figure 4: Sequence diagram for view class schedule
Figure 5: Sequence diagram for view exam schedule
Figure 6: Sequence diagram for register course catalog
Figure 7: Sequence diagram for swap invigilation duties
Figure 8: Sequence diagram for swap class schedule
Figure 9: Sequence diagram for generate class schedule
 2.5 State chart Diagram
State chart diagram shows the states the object (class) passes through in its life. This model guide how
objects in our system change from one state to another and when the change happens.

Figure 10: State chart diagram for create an account

Figure 11: State chart diagram for login

Figure 12: State chart diagram for swap class schedule

Figure 13: State chart diagram for view class schedule
 2.6 Activity Diagram
Activity diagram is basically a flow chart to represent the flow form one activity to another activity. The
activity can be described as an operation of the system. So, the control flow is drawn from one operation
to another.

Figure 14: Activity diagram for create an account

Figure 15: Activity diagram for login

Figure 16: Activity diagram for register course catalog

Figure 17: Activity diagram for update course catalog

Figure 18: Activity diagram for view class schedule

Figure 19: Activity diagram for swap class schedule

 2.7 Class Responsibility Collaboration (CRC) Model
A class responsibility collaboration model is a collection of standard index cards that have been divided
in to three sections. A class represents a collection of similar objects, a responsibility is something that a
class knows or does, and collaboration is another class that a class interact with to fulfill its responsibility.

Table 13: CRC for Department Coordinator class

Table 14: CRC for Teacher class

Table 15: CRC for Student class

Table 16: CRC for Class_Schedule class

Table 17: CRC for Exam_Schedule class

Table 18: CRC for Account class

Table 19: CRC for Swap_Request class
 2.8 Conceptual modeling: Class diagram
Class Modeling in the Unified Modeling Language (UML) is a type of static structure Modeling
that describes the structure of a system by showing the system's classes, their attributes,
operations (or methods), and the relationships among objects.

Class Diagram

Create a class diagram is diagram that we will use to build block the system we will develop. Our Class
diagrams should show the objects and how they are interrelated.

Figure 20: Class diagram

Change cases

Some of the potential changes that might occur to our system are:

 We might allow teachers to create a user account instead of just the department coordinator
creating it for them.
 We might have additional actor within the system called Admin and his/her job will be to
approved the account creation request from teachers and department coordinators.
 We might also just use the student registration systems’ database as a way to get the users of our
system, in which students will not create their own accounts.

2.9 User interface prototyping

We have shown below some basic prototypes for our system.
Figure 22: User interface prototype for login page
Figure 21User interface prototype for create an account page
Chapter Three: Design

System Design phase is process of describing, organizing, and structuring system components at
architectural design level and detailed design level. System Design converts functional models
from analysis into design models that helps to represent the solution for the problem.[ CITATION
KJ11 \l 1033 ]

3.1 Purpose and goals of design

The purposes and design goals of the system we are building are derived from non-functional
requirements that we have listed above. The system should provide a solution for problems that
are listed on the analysis phase. Design goals are specification which the system needs to
achieve.

 Performance: the system should perform all of its required functionalities, and allow
multiple users to access it concurrently.
 Maintainability. The application should be easily scalable and extensible to add new
features. And also, it should be easily modifiable to make changes on the functionalities.
To achieve this well documented manual for the system is necessary. The maintainability
of the system includes:
 Adaptive: Adapting changes to the external environment such as, changes to the
business rules.
 Corrective: Fixing bugs and features to the system.
 Preventive: Avoid a system failure by setting up validation controls on the user
inputs.
 Usability: can be seen in two ways:
 Effectiveness: the system should provide services which help the user to
achieve their goal.
 Efficiency: The users should spend minimum effort and resource to
achieve their goal.
 Reliability: The system should maintain and perform its functionalities 24/7.
  Security: the system should have authentication to allow only authorized users.
 User-friendly: the system should be easy to learn, understand and operate. It should
provide interactive and easy interfaces which can allow novice users to become familiar
with it.

3.2 Current Software Architecture

The current system the university uses as their class scheduling system is manual system, hence
there is no current software architecture that will be considered. As a result, we only describe the
software architecture of the newly proposed system.
3.3 Proposed software architecture
The mobile architecture is the most important part of mobile app development. It can lead to the
success or failure of the mobile app. Mobile app architecture is a set of structural elements along
with their interfaces that compose the system. It includes some techniques which help one in
developing a mobile application. The app architecture gets formulated by taking all procedure
that works on mobiles. This set of system helps to avoid user problems.

To develop our Class Scheduling mobile app we will use the most popular multilayer
architecture which is the three-layer architecture. This three-layer architecture is important for
designing or creating mobile app architecture. It refers to your component’s internal architecture.
The given are the main three important layers of mobile architecture design:

 Presentation Layer

The presentation layer consists of two components. These two components include the User
Interface and UI process. While discussing this layer, the primary focus is the end user’s mobile
application’s presentation.

 Business Layer

The business layer is for the elements on the business front. This layer looks at how the app will
present the business to the end-users. This layer includes business components, workflow, and
entities.

 Data Access Layer‍

The data access layers are to meet the application needs. They offer efficient and secure data
transactions. For this purpose, a developer needs to design this layer.[ CITATION OSs20 \l 1033 ]

Figure 23: Proposed software architecture

3.4 Subsystem decomposition

Subsystem decomposition is a general approach to solve a problem by breaking it up into smaller
ones and solving each of the smaller ones separately. Subsystem decompositions will help reduce
the complexity of the system. The subsystems can be considered as packages holding related
classes or objects. The system is decomposed in to the following subsystems:
Figure 24: Subsystem decomposition diagram

3.5 Component diagram

Component diagram displays the structural relationship of components of a software system.
These are mostly used when working with complex system that have many components
communicate with each other using interfaces. In this Diagram components of the system will be
wired showing that there is relation among components, management of the system, database
and operations performed on databases. The following diagram shows the dependencies among
software components.
Figure 25: Component diagram
 3.6 Deployment diagram
A Deployment Modeling shows the configuration of run-time processing elements and the
software components, processes, and objects. Deployment modeling shows the physical
configurations of software and hardware. Deployment diagram helps to model the physical
aspects of an object-oriented software system it models the right time configuration in static view
and visualize the distribution of components in an application.
Figure 26: Deployment diagram

3.7 Database design (E-R diagram)

Figure 27: E-R diagram

 3.8 Access control and security
Access control and security describes user model of the system in terms of an access privilege. It
involves managing who has access to specific system and resources at a given time. Below is the
description of access control using access control matrix.

Table 20: Access control matrix

Functionalities Student Teacher Department

Coordinator
Create Account

Login
  
Assign Accounts

Register Couse

Catalog
Update Course

Catalog
View Class Schedule
  
View Exam Schedule
  
Swap Invigilator
 
Duties
Swap Class Schedule
 
Generate Class

Schedule
Generate Exam

Schedule
 Chapter Four: Implementation
In this section we will implement our design of the system that we have proposed by using java
language in the android studio environment.

4.1 Objective of Implementation

 Developing the proposed system according to the various designs we have made in the
analysis and design phase of the project.
 This implementation will solve the problems associated with scheduling such as
availability and time consumption.
 Making the system available and usable in large scale.

4.2 Programming Tools and technology overview

 Android Studio IDE – It is used to develop the application.
 Java – It is the programming language we used to develop our application
 Firebase Realtime Database – the database platform we used to store and distribute data
for our application.
 XML – xml is used to define the visual structure for the user interface of our application.

4.3 Prototype of the Project

4.3.1. Class scheduling system

Class scheduling system is an android application developed for generating and distributing class
and exam schedules automatically with the department coordinators only inserting the courses
for the semester to the course catalog, and the students can view the schedules. And also, it is an
android application developed for generating, distributing, viewing class and exam schedules,
and in-addition teachers can request to swap their class schedule time slots. Then the department
coordinator approves or denies the request.

4.4 Testing
We have conducted various kinds of tests to see that the system performs correctly. Some of the
types of tests we have conducted are:
  Unit testing: In this phase we have tested the various modules of our system such as:
assign accounts, register course, view class schedule, and made sure they functioning as
expected.
 Integration testing: In this phase we have tested if the modules work in cooperation when
integrated. E.g., Swap Request and Approve Swap modules activities need to integrate
for the overall swapping function to work.
 System Testing: In this phase we have tested whether the system accomplishes the task it
was made for in general and whether it fulfills the requirements of the user.

4.5 Sample code and UI screens

4.5.1. Sample code screenshots

Figure 28: Sample code of GenerateSchedule method for the GenerateClass Class.
Figure 29: A sample code for assigning teachers.

4.5.2. Sample UI Screenshots

Figure 30: A sample code of the isTheTeacherReal method used for checking if the teacher is authorized to make a swap request.
 Chapter Five: Conclusion and Recommendations
5.1 Conclusion
This project is developed to address the difficulties that students and teachers face while dealing
with the class and exam schedules. We designed our system to make the scheduling system of
the class and exams easy for all parties involved. To accomplish this, we have developed the
system to have the capability to: Register Courses, Assign Accounts, Generate Class Schedules
and Exam Schedules, View Class and Exam Schedules, and added the capability for the teachers
to request a schedule swap among themselves. The system simplifies the task of generating
schedules because the all the academic coordinator has to do is register the courses for the
semester and click on generate schedule and the system will do the rest. The students can use the
accounts assigned for them by their department coordinator to log in view the schedules that
have been generated.

5.2 Recommendation
The system we have developed includes the basic functionalities that are need to for scheduling
system of a class/classes. In the future we recommend the expansion of project scope to include
functionalities such as, the ability to generate the schedules of different universities with their
corresponding class scheduling business rules, review and rating of schedules by management,
including other schedules for different purposes e.g., meetings, travels, etc.
References

[1] I. C. Vessey, "Requirement Specification: Learning Object, Process, and Data Methodologies,"
Communications of the ACM, vol. 2, no. 15, pp. 102-113, 1994.

[2] R. R. L., "Organizational Information Requirements, Media Richness, and Structural Design,"
Management Science, vol. 32, no. 5, pp. 554-571, 1986.

[3] .. J. K., System analysis and design, Upper Saddle River: Pearson Prentice Hall, 2011.

[4] OS system, "Mobile App Architecture - How to Design it?," 27 October 2020. [Online]. Available:
os-system.com.