IMPLEMENTING SOFTWARE DEVELOPMENT LIFE CYCLE PRINCIPLES IN THE
CREATION OF A WEB BASED UNIVERSITY
A Project
Presented to the
Faculty of
California State Polytechnic University, Pomona
In Partial Fulfillment
Of the Requirements for the Degree
Master of Science
In
Computer Science
By
Johnson Wei
2021
ii
SIGNATURE PAGE
PROJECT:
IMPLEMENTING SOFTWARE
DEVELOPMENT LIFE CYCLE
PRINCIPLES IN THE CREATION OF A
WEB BASED UNIVERSITY
AUTHOR: Johnson Wei
DATE SUBMITTED: Spring 2021
Department of Computer Science
Dr. Gilbert Young
Project Committee Chair
Professor of Computer Science
Dr. Yu Sun
Professor of Computer Science
iii
ABSTRACT
Effective software development should always strive to incorporate three core principles
consisting of building, maintaining, and updating. The benefits of reusable software are
emphasized in enterprise solutions mainly for cost and time saving management. Aside from
those properties, having software that ages gracefully through time can also be seen as a desirable
consequence. The Software Development Life Cycle (SDLC) of any project aligns with the very
same core principles regarded by effective software development. My Master’s Project will build
a fully integrated web applet that will serve as a platform for an educational institution that will
provide instructors, students, and administrators to communicate with one another. Furthermore,
this web applet will facilitate an online university curriculum that will allow students to complete
their educational goals. The process of building this web applet will concern the six stages of the
software development life cycle regarding to plan, define, design, build, test, and deploy. The first
three stages of the six, provide a blueprint of the project application. The build and test phase of
development will showcase the proof-of-concept of the project description. Lastly, deploying the
project will serve as the finalization of the HBU project. Through the developmental phases,
retroactivity of the previous stages is only revisited to reinforce the SDLC principles.
iv
TABLE OF CONTENTS
SIGNATURE PAGE……………………………………………………………………………...ii
ABSTRACT…………………………………………………………………………………...…iii
LIST OF FIGURES………………………………………………………………………………vi
1. INTRODUCTION………………….…………………………..………………….…………...1
2. DESIGN PROCESS…………………………………………….……………………………...3
2.1 Java Spring Boot Framework…………………………………………………………….3
2.2 Model View Controller………………………………..……………………………….....7
2.3 SRP…………………………………………………………………………………….....8
2.4 Packages/Directories & Annotations…………………………………………………......8
2.5 Authentication and Authorization………………………………………………….........11
2.6 Design Patterns…………………………………………………………………….........12
2.6.1 Spring Framework Design Patterns………………………………………………12
2.6.2 Model View Controller Pattern…………………………………………………...13
2.6.3 Repository Pattern………………………………………………………………...14
2.6.4 Builder Pattern………………………………………………………………….....15
2.6.5 Inversion of Control Pattern……………………………………………………....16
3. METHODOLOGIES………………………………………………………………….………18
3.1 JDBC and MySQL Connector…………………………………………………………..18
3.2 Object Relational Mapping……………………………………………………………...20
3.3 Open-Closed Principle…………………………………………………………………..21
3.4 Data Transfer Objects…………………………………………………………………...22
4. SOFTWARE DEVELOPMENT LIFE CYCLE……………………………………………...23
4.1 Plan……………………………………………………………………………………...24
4.2 Define…………………………………………………………………………………...25
4.3 Design……………………………………………………………………………….…..28
v
4.4 Build………………………………………………………………………………….....29
4.5 Test……………………………………………………………………………………...31
4.6 Deploy……………………………………………………………………………….......32
5. END USER EXPECTATIONS…………………………………………………………….....34
5.1 Administrator…………………………………………………………………………....34
5.2 Instructor………………………………………………………………………………...35
5.3 Student…………………………………………………………………………………..35
6. CONCLUSION………………………....………………………………………………….....37
7. REFERENCES………………………………………………………………………………..38
vi
LIST OF FIGURES
Figure 1. Spring Initializr Template Generator Accessed from [4]................................................4
Figure 2. Snippet of Project Object Model (POM) File with Dependencies Listed……………...6
Figure 3. Model-View-Controller Diagram…………………………..………………………......8
Figure 4. Spring Boot Application Annotation……………………………………………….......9
Figure 5. Gui for End User to Login via HBU Web Application………...……………………..11
Figure 6. Relationship Sequence of Objects within HBU……...……………………………......14
Figure 7. List of JPA Repository Operations………………………………………………........15
Figure 8. MVN Repository Dependency Search Engine…………………………………….….17
Figure 9. JDBC Application Properties Configuration……………………………………….....18
Figure 10. Accessing HBU Database Using Local MySQL Command Line Interface..………..19
Figure 11. User Object Model Table within Database…………..……………………………....21
Figure 12. Student Object Model Table within Database…………………………………….....21
Figure 13. KanBanFlow Agile Framework………………………………………………….......24
Figure 14. HBU Use Case Diagram………………………………………………………….….27
Figure 15. Sequence Diagram…………………………………………………………………...28
Figure 16. Cloning Projects via Github…...…………………………………………………......30
Figure 17. Using the Git Branch Command……………...……………………………………...31
Figure 18. Unit Test Example....………………………………………………………………...32
1
1. INTRODUCTION
The project at focus is called Harvest Bible University (HBU) [1] and will be referred to
as the abbreviated form throughout this literature. The current HBU website currently contains
static web pages without much complexity, however, the goal of this project will be to add the
necessary components to enhance the online educational experience. HBU will serve as an online
educational platform that will have students pursuing their educational goals. Throughout their
experience, the students will be able to interact with their instructors and will be expected to
complete their curriculum by attending web lectures. Depending on each course curriculum, most
will follow a standard web-classroom setting where students are expected to study the materials
of the course and they must be accountable for the associated coursework: assignments, quizzes,
exams, projects, etc.,. To make this online experience fulfilling; a student can expect to register
for HBU. Only upon acceptance can they log into their dashboard to access their university
amenities such as making modifications to their profile, registering for classes, requesting
transcripts, and submitting their coursework through a class module interface. The previous
examples only highlight some of the capabilities that a student will perform and with certainty all
of this will be made possible by incorporating a full stack application; where the frontend client-
side and backend server-side coexist to bring an operational platform for students, instructors, and
administrators to use collectively.
The frontend client-side of the application essentially is the graphical user interface
(GUI) that a user will become accustomed to while they navigate through the HBU dashboard.
For example, when a student logs into their dashboard they will come across a login form where
the username and password text fields will prompt the user to enter their credentials. [DISPLAY
LOGIN FORM] Upon entering their correct credentials, the login page will redirect into a
dashboard page respective to the user (administrator, instructor, student, etc.,). Navigating from
page-to-page will be the main concerns of the frontend tasks.
2
Backend server-side duties involve a myriad of concerns that will be hidden from any
user of the application. To reuse the previous login example; the actions that allow the process of
a user logging into their account can involve a JSON web token (JWT) where a series of letters
and numbers encoded in base64, represented as a header, payload, and signature, will be used to
determine authentication. If the authentication gets approved, then the user will be redirected to
their respective dashboard. The algorithm that determines the authentication process is an
example of a backend service. More elaboration will be covered on the details of logging in using
JWTs in the section: Design Process.
Ultimately, the roles of administrator, instructor, and student are ranked respectively with
administrator having the highest authority. Administrators have the option to grant a user access
into the HBU domain as another administrator or perhaps an instructor or student. They can
create or delete course modules, approve or deny requests, send messages to other users, etc.,.
Instructors will be responsible for creating their assignments relating to their coursework, while
the students will have the opportunity to submit their coursework assignments. The details of the
respective roles will be more thoroughly defined throughout this literature. HBU will serve as a
web-based university where students can earn their degrees respective to their curriculum.
3
2. DESIGN PROCESS
Before discussing the underlying framework that this project will utilize, the topic of
open source must be gone over briefly. Open source projects are usually a collaborative effort
from people who wish to contribute to a specific cause. This specified cause can be in a few or
many forms motivated by the simple desire to share free digital resources. Software that is
managed by an open source project usually contain guidelines that promote its longevity, for
example, if you would like to contribute to an open sourced project, there are rules to follow so
that the livelihood of the project will be in a healthy state. To ensure this so-called “healthy state”
contributors must rigorously test their software for any incompatibilities and more importantly,
make sure that their software can be useful. Another equally important role of open source
communities is the vital existence of their respective resources; community forums,
documentation, frequently asked questions (FAQs), etc.,. Community forums can resolve
troubleshooting problems, documentations exist to serve as a manual, and FAQs can be an
informational gateway to expel confusion. Ultimately, software freedom is essential to enabling
community development of open source software [2], thus, the power of a collective community
can flourish and accomplish many obstacles that an individual developer cannot.
2.1 Java Spring Boot Framework
The existence of this project is made possible by Java Spring Boot [3]; this open source
framework contains libraries that solve many common issues that developers encounter, such as
providing front-end model view controllers, securely authorizing user login attempts, and
validating the integrity of a user request are just some of the common necessities that are required
from an application. The practicality of using such a framework allows an easy start-up via the
spring initializer [4]. A Project can consist of a few to many dependencies, but a user that
initializes this template generator (see figure 1) must specify the type of project (Maven or Gradle
Project).
4
Figure 1. The Spring Initializer template generator allows easy start up of a Spring Boot project and can
be accessed at: https://start.spring.io.
The computer languages Java, Kotlin, or Groovy must be selected, along with the Spring Boot
version to use. The Project Metadata form is provided for clarity and consistency so that a user
can state the Group, Artifact, Name, Description, and Package name in more descriptive detail.
Additionally, the user can also choose from a list of dependencies and the configuration process
will format a specific POM file according to specifications. It is worth noting here that a
‘package’ is synonymous to what one would find in a computer operating system representation
of a folder directory. For example: if a current directory is represented as
5
home/user/workspace/springBootProjectLocation, then the package representation would look
like so: home.user.workspace.springBootProjectLocation. The ‘dot’ notation of a project
hierarchy is prevalent in the Spring Boot framework and many package names like:
com.hbu.backend.controller represent a conventional way of navigating a project. The
com.hbu.backend tells a user that they are in the project structure named ‘hbu’ and they are within
the ‘backend’ directory of a project. Following the chain of ‘dots’ obeys the similar principle of a
folder hierarchy from a computer operating system. Therefore com.hbu.backend.controller
implies that a user is viewing the controller package from the HBU backend project.
A Maven project [5] is simply an objective-based goal that allows developers to maintain
their projects without difficulty. Not only does Maven make the process of building a project
easy, but it also standardizes a way of providing a uniform build system. It solemnly encourages
SDLC principles by promoting ‘best’ developmental practices. A core component of a Maven
project consists of a Project Object Model (POM) file that structures a list of dependencies that a
project will use. This POM file is an XML file that describes the information about a project
through its configuration details. In figure 2, some of the dependencies that are used in the HBU
project are Java Database Connectivity (JDBC), Java Persistence API (JPA), and mysql
connector.
6
Figure 2. A Project Object Model (POM) is represented in the form of an XML file, structured in
dependency tags containing, but not limited to groupId and artifactId tags.
The JDBC is an application programming interface that allows a user to connect to a
database to access the very same contents that a student might in order to request their online
course assignments. The JPA is another important application programming interface that
manages the way a user interacts with relational data. The mySQL connector will bridge the
requests of actual structured query language (SQL) queries in the form of statements so that a
user can make requests to access data; this will be done abstractly, meaning that the application
layer will allow a user to make requests without necessarily exposing the details of writing the
actual SQL statements to make those requests. This topic of hiding details is a common practice
in Object-Oriented Programming (OOP) referred to as encapsulation; the process of hiding data.
The reasoning behind this practice can be elaborated through an example. If a student of HBU
wants to view their unofficial transcript, they have to access their dashboard by logging into their
7
account and make a request to access their unofficial transcript. They make this request by
performing a series of keystrokes (logging into their account) and button clicking to get to where
they want. Throughout this process, the student did not need to know how the html page was
generated, nor did they need to know the composition of the data transfer objects (DTOs) used to
represent the actual unofficial transcript. By hiding these details, a developer can provide a
‘black-box’ tool for any user to use. This ‘black-box’ tool inadvertently prevents users from
manipulating data, which ensures preventive measures to unintended or unwanted actions. If an
application feature promises to get a student their unofficial transcript, it should simply do just
that, nothing less, nothing more.
2.2 Model View Controller
A model-view-controller is a software design pattern that is separated into three main
entities. The model is responsible for maintaining the business logic and rules of an application.
A view provides an interpretation of data in the form of a graphical user interface (GUI). The
controller actively awaits input from a user and implements requests or commands for the model
and view components. The diagram from figure 3, displays a cyclic process of how the elements
of a model-view-controller interact with a user of an application.
8
2.3 SRP
SRP [6] stands for Single Responsibility Principle. In object-oriented programming, SRP
is quite favorable from the perspective of designing software. Suppose that an enterprise software
needs to make changes and we can expect the application to be quite large. In order to make large
applications manageable, Classes and Objects of a program must be carefully designed as not to
remain ambiguous. For example, if a class is created to do many things, how can we properly
keep track of all the features of an application? We can prevent from asking this question by
creating a separation of concerns, that is to create many classes for each major responsibility.
Thus, the creation of multiple classes allows developers to modularize and navigate through
organized layers systematically. The motto for SRP often coincides with the notion of keeping
Classes and Objects simple so that the application layer can be manageable.
2.4 Packages/Directories & Annotations
The term ‘packages’ is synonymous with directories and will be used interchangeably
throughout this literature. The HBU web application follows the MVC design pattern, therefore
Figure 3. The MVC pattern consists of a model, view, and controller entity. The
user interacts with the controller to view a representation of data.
9
the structure of packages embodies the model, view, and controller components closely. The
model package contains the main entities, which are Classes being represented as Plain Old Java
Objects (POJOs). These POJOs must be annotated with the @Entity so that these classes can be
mapped to the Java Database Connectivity (JDBC). Annotations in Spring Boot applications
signal metadata to be provided within a program’s configuration. The main method to start the
HBU application is annotated with @SpringBootApplication, (see figure 4) to configure the
program as a Spring Boot application. Upon developing, code completion and suggestions are
made possible from these convenient annotations.
Figure 4. Annotations provide metadata configuration for a Spring Boot Application; the main method
will then run the Spring Application’s .run( ) method.
A few common annotations that are used within the HBU web application will be
covered here.
@RestController - REST stands for Representational State Transfer and it makes accessing web
services a lot more effective by providing a uniform source identifier (URI). Classes that are
annotated with RestController inform Spring applications that it will be responsible for providing
controller methods.
@Autowired - configures (auto wires) the entity with properties of getter, setter, and constructor
methods so that the developer does not need to write the boilerplate code. This is a dependency
injection method that exists within Spring Boot where an object gets automatically configured for
use. This becomes quite convenient as it eliminates an application for having redundant code.
10
@RequestMapping(“/param”) - within a RESTful web application programming interface (API),
request mappings are affixes to a main URI. The “/param” argument is the affix that will become
appended to a URI. For example, when using the URI: http://localhost:8082 the following
@RequestMapping(“/student”) where “/student” is the affix, informs to the application that this
specified controller will map to the URI: http://localhost:8082/student. This allows for CRUD
operations to make changes by providing an explicit mapping to a URI.
CRUD - stands for Create, Read, Update, and Delete; these are the basic operations that are
implemented when using a repository (database interaction). CRUD is not explicitly an
annotation, but the annotations that follow will be a composite of CRUD operations.
@GetMapping(“/param”) - configures a get request by using a main URI with the string
parameter appended to it.
@PutMapping(“/param”) & @DeleteMapping(“/param”) - similarly configures a put and
delete request, respectively, by using a main URI with the string parameter appended to it. For
example, if a controller for student is annotated with @RequestMapping(“/student”), and another
method within the controller is annotated with @DeleteMapping(“/{id}”) then we can infer that
this particular method will be performing a delete operation within a database concerning the
student with the given id. The full request URI would look something like
http://localhost:8082/student/101 if the student id was ‘101’.
These annotations simplify the process of configuring our controllers to behave the way
the business logic is setup via the controller methods. Another caveat is that Spring Boot
applications contain a resources.templates directory that stores html files. These html files can
then signal to the frontend component to display an associated page. For example, if a developer
11
is working with the @RequestMapping(“/student”) then they could provide a student.html that
could serve as the template to a web view. Similarly, HBU contains a few html template pages
that will be manipulated in this fashion.
2.5 Authentication and Authorization
The HBU application requires a user to login in order to access its features, see figure 5,
(ex: submission of assignments, request for unofficial transcripts, make changes to their profile,
etc.,.) by doing so will trigger the backend to validate if a username credential matches with a
password that is provided.
Figure 5. To log into the HBU dashboard, a user must provide their username and password.
The implementation of the authentication process adheres to the single responsibility principle
(SRP); therefore, it is coupled with a few layers. The sequence of a user logging into the HBU
web application consists of an AuthenticationService that implements an interface from the
Spring Boot library called AuthenticationProvider. For what the name implies, the
AuthenticationProvider ensures a way to grant users of HBU to access their university dashboard.
12
The AuthenticationService implements AuthenticationProvider in two ways; it overrides the
authenticate( ) and supports( ) methods. A UserService object is used to extract the username of
the person logging into the HBU dashboard.
User user = userService.getUser(username). The HashService object is included to provide the
getHashedValue(input_password, salt ) method to check if a user has entered their correct
original password. The supports(authentication) method will return a boolean based on a
comparison of an authentication object with an instance of
UsernamePasswordAuthenticationToken.class.
2.6 Design Patterns
Reusability is an important concept when discussing software development since it saves
time from rewriting code that can already exist. A pattern is usually classified once it becomes
commonplace in the software development lifecycle. If a problem occurs over and over again,
then perhaps write some software that alleviates the problem. Then the next time that the same
problem occurs, we can rely on the very same source code that helped us solve our specific
problem from the very beginning. Thus, the solution can be applied indefinitely to any developers
who will face the same problem. Ultimately, object-oriented design patterns are solutions to a
problem in a context [7].
2.6.1 Spring Framework Design Patterns
The Spring Framework itself consists of a few design patterns, but HBU primarily uses
the Singleton and Template Method design patterns.
Singleton - a creational design pattern that allows a class to have only one instance and sometimes
can be accessed globally. In Spring Boot applications, having the @Autowired annotation ensures
that multiple controller classes can receive the same dependency injection within a single
13
application context. In HBU, the StudentController and CourseController auto-wires a
CourseService object. If we were to run this application, we could make a get request to
determine that the CourseService objects would have the same object id.
Template Method - a behavioral design pattern that produces a structure of an algorithm in a
parent class and allows its subclasses to override specific steps of an algorithm without changing
its overall structure. The JDBC service calls and Java Persistence API that exist in HBU follow
the Template Method design pattern.
2.6.2 Model View Controller Pattern
Also known as MVC, this architectural design pattern specifies that an application must
consist of objects that will represent data model, view, and controller components. HBU relies on
user interface interaction, therefore many of its entity models rely on controller and service
objects to process requests. For example, a Student entity resides in a model package and if a
request needs to be processed, then the StudentRepository will be called upon to provide standard
CRUD operations. These standard operations can contain more complex business logic in the
form of a StudentService layer (example: a student may wish to add or drop their course). In
order to drop a course, an algorithm must determine if the student is even registered to that course
and if they are, then if it is even possible to drop the course from their schedule, permitting the
regulations of the drop course time period. Finally, once a request is processed, it must be
represented on a user interface so that the student can view their interactions via web application.
This is where the controllers come into play, where the StudentController object will provide a
mapping to a html page. Figure 6 summarizes the MVC layout of HBU.
14
Figure 6. The Controller Class contains the most abstraction as it provides a mapping to a view whereby
a Service object exists. The Service object will have access to a Repository object to implement business
logic. The Repository object will have access to an entity class, which is often a Plain Old Java Object
(POJO). This relationship sequence outlines the hierarchy of the Model-View-Controller of HBU.
2.6.3 Repository Pattern
The repository pattern provides encapsulation for data access and serves as a mechanism
for communicating with a database [8]. The HBU repositories that concern User, Student,
Instructor, Admin, and Course all extend the JpaRepository, which is the persistence layer of
data. Persistency describes the ability to store information through a database. In simple
applications, when declaring variables and instantiating objects, the lifetime of the variables and
objects created only exist as long as the program. If the program terminates, then so does its local
storage of variables and objects. However, data will continue to persist through many uses of an
application if it is being stored in a database. In contrast to a simple application, databases will
continue to store information until an authorized request is given to remove or alter the data. A
registered user from HBU can depend on their information long after they stop using the web
application; all made possible by the persistence of data. HBU repositories are interfaces that
implement the JpaRepository. The JpaRepository consists of basic CRUD operations (figure 7)
that provide an extension to any repository interface. For example, if I were to create a new
StudentRepository interface that extends the JpaRepository<Student, Long> with the respective
15
arguments within the angular brackets, then I can expect to persist Student objects through a
database. With the assumption that the proper Service Class is created; simple mySQL queries
can be made just by declaring the StudentRepository as a base class of the JpaRepository. This
becomes quite convenient as once again the Spring Boot library provides a boilerplate setup so
that developers do not need to worry about writing trivial mySQL statements.
Figure 7. The JpaRepository already has its own methods that cover the basic CRUD operations [9],
courtesy of Spring Boot framework.
2.6.4 Builder Pattern
The builder is a creational design pattern that is not primarily used in the HBU
application, but it is still worth noting, perhaps it can be applied to future endeavors of the
16
project. This builder pattern allows the separation of concern toward building complex objects so
that the same construction code can create different representations of objects. One area of
application that needs this attention is the DTOUtility Class. The User entity and its subclasses
can all benefit from a single builder of data transfer objects (DTOs). Introducing this pattern
would separate the concerns of choosing what type of DTO to create.
2.6.5 Inversion of Control Pattern
Inversion of Control (IoC) describes the Spring Boot framework methodology;
independent application components are combined by using frameworks. This reduces the
developmental stages of writing an application because frameworks already cover the basic
integration code that are needed for an application to run. The POM file from a maven project is
really just an abstraction of interconnecting individual components into an aggregation of tools.
One key concept called dependency injection, is a mechanism for injecting components with
dependencies. Dependency injection is a literal term that describes what it does based on its
namesake. During a configuration process of starting up the HBU server, the POM file gets
processed and all the tags that contain the word ‘dependency’ are injected during runtime. The
IoC provides the benefit of flexibility since modifications to a POM file can be easily
implemented. Different versions of maven dependencies can be found through the maven
repository [10] on a need basis. The maven repository contains a search bar that will return a best-
matched list of results the very same way that a common search engine would. For example, upon
entering ‘JDBC’ in the search context; a list of results would follow (figure 8). Conveniently, a
user can sort the return results based on relevance, popularity, newest, etc.
17
Figure 8. The maven repository website [10] consists of a search bar to do a quick lookup of
dependencies.
Ultimately, IoC is a design pattern that can be thought of as the practice of designing
libraries as applications. This successfully addresses any questions relating to “How can I connect
all of my application components with each other?” Therefore, the developmental concerns of a
project can always defer application-specific logic to IoC containers to reduce a lot of boilerplate
and introduce a clean environment, where a separation of concern exists between a business logic
of an application and dependency injections.
18
3. METHODOLOGIES
The HBU application on a grand scale borrows from the many design patterns that were
previously covered. Another important dependency that is widely used is the management of data
persistency. A user has many options to store and send their data on the HBU application. For
example, a student might make requests for transcripts, submit their assignments in the form of a
document, or perhaps just make changes to their profile page. Even the demands of complex
actions can be broken down into simple requests provided by the many dependencies that the
Spring Boot library offers. Some of the methods that are used to solve the issues of data
persistency is further elaborated on in the following sections.
3.1 JDBC and MySQL Connector
The Java Database Connectivity (JDBC) is an API for executing queries and connecting
to a database. The configuration of the HBU application.properties file defines the necessary
URL (figure 9), associated username, and password to a database. It is worth noting that when
HBU reaches production on an enterprise level, methods of database management will need to
switch from a local server to a dedicated server. The POM files will include an artifact id called
spring-boot-starter-data-jdbc to add to the list of many dependencies that HBU will need.
Figure 9. Application properties of HBU provides the URL, username, and password configuration for
the database.
19
The MySQL connector can be configured locally in two ways after installing and
following the setup from the MySQL installer. The first way is to use the GUI application:
MySQL Workbench. Secondly, the mysql command line interface (CLI) exists to get the same
functionalities of the workbench application, but without a graphical user interface. Using the
mysql CLI, a user with administrator privileges can access the HBU database by entering the
command use hbudatabase; (semicolons are used to end a database request), additionally,
entering show tables; will display all the tables of a given database (figure 10).
Figure 10. Through the mysql command line interface, an
admin can access the hbudatabase contents.
20
3.2 Object Relational Mapping
The interconnectedness of Java objects mapping to a database and vice-versa is made
possible by object relational mapping (ORM) [11]. The Spring Framework contains a persistence
configuration from Hibernate, which is just a domain model persistence for relational databases.
This persistence framework has SQL support; therefore, MySQL statements are abstracted
through the Repository Classes and the respective entities use annotations to describe their tables
in the database. For example, the Student entity Class imports from the javax.persistence.*
libraries. The annotations @Table(name = “student”) indicates that this object will map to the
student table in the hbudatabase and similarly requests to alter a student table would be reflected
in the Java objects.
The User Class entity is a superclass of Admin, Instructor, and Student, therefore the
configuration of the hbudatabase must account for an inheritance strategy. To indicate an
inheritance relationship, we simply provide the annotation @Inheritance(strategy =
InheritanceType.JOINED) to the User entity class. This is another way of indicating that the User
class will be a superclass that will follow the ‘joined’ inheritance strategy. Using the joined
inheritance strategy maps the children classes to their parent class, and the repeated fields that
they share will not be repeated in the child class. The only similarity among parent and children
tables is the id-identifier, this identifier serves to join the classes when needed. In figure 11 and
figure 12 we can compare and see that inherited fields are not reflected in the children classes.
The command to see the description of a database table is describe table_name followed by a
semicolon.
21
Figure 11. The User represents the superclass of an entity and all of its fields are listed along with its
types.
Figure 12. The Student is a subclass of User and the joined inheritance strategy does not permit tables of
children classes to repeat the shared fields of their parents.
3.3 Open-Closed Principle
An idea that complements Object-Oriented Programming well is the open-closed
principle. The notion behind the idea is that entities should be open for extension, but closed for
modification [12]. When designing a Class, developers should aim to minimize workload should
the need of making changes to software arise. During the development of HBU, my colleagues
and I had made numerous changes to a lot of Classes and every single time a change was made,
other components that were tightly coupled with the Class would also need to change as well.
This process of following breadcrumbs leads to inefficient software development practices. In
hindsight, the designing of our Classes should not have been tightly coupled with other objects.
22
Thus, an ideal scenario would be to have a well-designed Class that is free from tightly coupled
objects so that it can be openly used without worry of needing to make changes to it. In the event
that changes do need to be made, the action of tracking down the tightly coupled objects would be
eliminated. Closing the Classes to modification does not mean that it cannot ever be changed, but
the mindset in developing one should aim to follow the credence of writing new software without
having to change the existing code.
3.4 Data Transfer Objects
In the application layer of HBU, the frontend will require the data necessary to display a
view to a specific user. For example, if a student were to request to see their profile page, then the
backend business logic would need to pass the data that represents the student profile page. One
of the many attributes of a Student Class is the password attribute. Oftentimes it is too sensitive to
transport data that contains a password, especially if the sensitive data will not be used. Since the
password field was only used at the beginning of the HBU login process, we can choose to
prevent our data from containing such sensitive information by creating a data transfer object
(DTO). A StudentDTO Class can be created to provide a layer of abstraction without exposing the
password attribute of a student. Consequently, in order for the frontend to display a student
profile view, all it would need is a StudentDTO object. Since DTOs are essentially Plain Old Java
Objects, the management of DTOs is not complex. The StudentDTO object consists of basic
attributes from the Student Class; as one would expect, all the necessary fields to fill out a student
profile page (university id, first name, last name, email, etc.,.) The concept of DTOs is frequently
used throughout the HBU application and any Class that requires a representation in a view, then
there is an associated DTO for that Class.
23
4. SOFTWARE DEVELOPMENT LIFE CYCLE
The productive ebb and flow of the software development lifecycle (SDLC) is usually
cyclical. To understand this concept, we must mention the adopted Agile methodology that many
enterprises follow in a production environment. Agile is an iterative approach towards software
development that minimizes big and sudden changes. Instead, small and incremental changes are
the key factors that allow software development teams to meet their requirements.
Scrum is a component of agile development and it emphasizes on keeping a daily
schedule towards meeting the goal of a production team. The main categories of scrum are
composed of having roles, stories, and sprints. Roles from scrum can contain, but not limited to,
scrum master, project manager, dev ops, developer, etc.,. Stories are concise statements that lead
to a use case development. Typically, user stories have a single goal for a user followed by a
specific reason. For example, the heading for this story can be “User to access HBU dashboard”
and its brief description would state: “As a user, I want to login so that I may access the HBU
dashboard”. What follows after a user story is a use case document (figure 14). Sprints would be
associated periods of development lasting from one to two weeks. These sprints would be posted
using a scrum tool that all team members will have access to and their collaborative feedback will
be documented along the developmental stages. It would be up to the scrum master to define the
teams goals and create a schedule to meet those goals. A typical sprint can have various time
frames as long as it is relatively short (no more than two weeks long). The reason for keeping a
sprint’s time frame short has all to do with maximizing the teams chance of meeting their
requirements. In order for a project to undergo continuous integration and continuous
development, it needs to be managed in small and incremental changes.
The six steps of the SDLC are plan, define, design, build, test, and deploy. The process of
the SDLC for the creation of HBU will be elaborated upon here.
24
4.1 Plan
The development team of three consisting of John C. Wang [13] - Project Manager, Gina
Luan [14] - developer, and me (Johnson Wei) - developer, are responsible for the development of
the HBU web application. The planning phase of the HBU web application uses a scrum tool
called KanBan (figure 13) [15]. Members of the team are shown on the website’s header as
initials and members have access to view the board at all times. During the initial stages of
software development, each sprint creation is preceded by a “stand-up” meeting; where each
member of the group will have their chance to communicate any ideas or concerns for the
project’s tasks. After the stand-up meeting, the project manager proposes user stories and assigns
those stories to each developer on the team. Brainstorming ideas and learning about new concepts
were the first few sprints that took place.
Figure 13. KanbanFlow [15] is an agile framework tool used to help software teams meet their project
goals.
25
After doing research and going through tutorials about the main concepts of web
development, our team consistently follows a schedule that consists of one week length sprints,
with a new sprint that gets created after the completion of the previous one. If a previous sprint
does not get completed in time, then the stand-up meeting would readdress those issues to be
reincorporated into the next sprint. To access a user story on KanbanFlow requires a registered
user to click on the post-it note look-alike panels of the web GUI. For example, a user would
know if a specific story belonged to them as indicated by their initials located on the bottom right
hand corner of each post-it note. Each post-it note could be labeled in a different color to show
the level of commitment of a story, for example, red could indicate a sense of urgency, while
green could indicate an approved story. The significance of the planning phase allows us to
iteratively build in maintainable batches. At the end of each sprint, a new one gets developed and
the process repeats itself throughout the entirety of the HBU software development lifecycle.
4.2 Define
The defining stages of HBU involve creating the documentation of the workflow process
of any given action, whether it be a simple frontend display or a complex backend request. A use
case document (figure 14) attempts to solidify the planned concepts from scrum into something
more concrete. For convenience, each post-it note on the scrum board contains useful information
of the given story. Upon clicking the post-it note, a developer can read a detailed version of the
story or any notes left by the other collaborators. Usually, the user stories can contain feedback
from other team members or contain any relevant links to other documents concerning the story.
This is where use case documents can be accessed in the form of a url that will redirect
developers to the document.
Figure 14 is the use case document for users that log into the HBU website. All other use
case documents will follow this same format; therefore, it makes sense to go over the anatomy of
26
a use case document. The blue cells of the document are the labels of a given field and the
adjacent cells following are their descriptions.
➔ Use Case - the title of the use case document.
➔ Created By - the author of the use case document; a use case document can have more
than one author.
➔ Last Updated By - the last person to update the use case document.
➔ Date Created - the date the use case document was born.
➔ Last Revision Date - marks the date of the last time the document was revised.
➔ Description - a brief description of the use case.
➔ Actors - potential personnel that will be involved in the use case scenario.
➔ Preconditions - certain pre-existing conditions that allow an actor to be a part of the use
case.
➔ Postconditions - the consequence of completing the use case; the results.
➔ Flow - a step-wise logical flow of an actor completing the use case scenario.
Upon the completion of a use case document, the next step that follows are the generation
of sequence diagrams.
Use Case: User Logs into Harvest Bible University Website
Created By: Johnson Wei Last Updated By: Johnson Wei
Date Created: 8/26/20 Last Revision Date: 9/10/20
Description: A user from the web can log into the Harvest Bible University.
Actors: General user, Student, Instructor, Administrator, New User (User that did not complete survey)
Preconditions: 1. A user must have access to the internet 2. A user must have successfully registered an account within the
Harvest Bible University website prior to logging in.
Postconditions:
1. A user successfully logs into the Harvest Bible University given that they provided their username and password.
Flow: 1. A web user visits the homepage of the Harvest Bible University
27
2. The web user clicks on ‘login’ within the homepage and the user will be directed to a login page.
3. The login page will display username and password text field entries. 4. The user will also have the option to enter their username and
password in the corresponding text field entries. The user will click the ‘submit’ button. 4.1. If any of the entries are left blank, an error message will be
prompted to the user, notifying that the fields that are left blank need to be filled out. Go back to step 4.
5. The login page will pass input validation to the user-login service: 5.1. If not valid, then the user login service prepares an error
message for the login page to display. 5.2. the login page proceeds to warn the user that either the
username or password is incorrect and needs to be reentered.
5.2.1. The user will have 3 attempts to login, otherwise, the administrator will lock them out of their account. An email will be sent to the user to notify them of their locked-out status and the resolution to rectify the problem. The user can click the active link contained in the email to reset the lockout.
5.3. The user will reenter the username and password and click on submit.
6. The user login service will verify the type of user logging in by confirming their ID. If the user logging in is a/an: 6.1. admin: they will be directed to the admin service.
6.1.1. the admin service will direct the user to the admin dashboard.
6.1.2. the admin dashboard will be displayed to the admin. 6.2. student: they will be directed to the student service.
6.2.1. the student service will direct the user to the student dashboard.
6.2.2. the student dashboard will be displayed to the student.
6.3. instructor: they will be directed to the instructor service. 6.3.1. the instructor service will direct the user to the
instructor dashboard. 6.3.2. the instructor dashboard will be displayed to the
instructor. 6.4. new user: they will be directed to the registration service.
6.4.1. the registration service will direct the user to the Harvest Bible University survey questionnaire page.
6.4.2. The survey questionnaire page will be displayed to the new user.
Figure 14. Use Case document detailing the actions of a user logging into the HBU website and the
consequential flow of doing so.
28
4.3 Design
Sequence diagrams are visual tools that help developers illustrate their ideas, the process
of creating an algorithm’s sequence can show both the strengths and weaknesses of a design
implementation. These diagrams are essential since it offers an easy abstraction to meet a
developer’s end goal. Lucid Chart is the application that we use to create our sequence diagrams.
Each diagram that a developer creates can be made into a shareable link so that they can post that
link on the respective user story. This collective sharing of information keeps digital documents
convenient to access especially if modifications need to be done.
Figure 15 shows the sequence flow for a student to access their course roster details. A
student might want to access this feature so that they can send a message to one of their peers
through the HBU messaging service to ask a question about a course assignment. The upper left
Figure 15. This Sequence Diagram shows the course of actions of a student viewing their course roster
information, this action of viewing the other members of the course promotes communication and
collaboration among peers.
29
yellow post-it note indicates to the viewer that this sequence diagram takes place after a student
logs into the HBU dashboard and they must be viewing one of their course modules. Similar to
the use case documents, this indicator serves as a prerequisite to accessing a course roster
information. This sequence diagram starts from the upper left corner of this LucidChart diagram
and proceeds to flow in the direction of the arrows. The general direction of the flow ultimately
flows downwards toward the bottom of the document. A sequence has ended when a viewer sees
the solid black circle enclosed by another circle; this symbolizes an end to a sequence diagram. A
viewer will see that the Class module page will display to the student, then the student will click
on the course roster link that will trigger a backend component (HBU service) to comply and
make a request to the database for the roster details. The resulting action of this sequence diagram
enables the student to view their course roster details through the course roster page.
4.4 Build
Deciding on which integrated development environment (IDE) to use and which version
of the Java Development Kit (JDK) must be one of the many topics that is brought up during a
scrum session. The HBU team decided that using the IntelliJ IDEA [17] and JDK version 1.8 was
the best option. The significance of consistency is important since a myriad of troubleshooting
“bugs” exists, therefore, if every developer on the team works with the same configuration
details, then it makes debugging a lot easier. A term that quickly becomes familiar in
collaborative environments is “SCM” or source control management.
A source control management tool that we use is called Git [18] and our github repository
can be accessed here [19]. Source control and version control are synonymous and can be used
interchangeably to describe the same thing. Version control management benefits an entire team
since it provides an origin where developers can collaborate on contributing source code. Github
offers a way to share source code through a URL and many options exist to promote team
collaboration. Installing Git allows the use of built-in command line actions that will allow a
30
developer to make their own contributions to a project. By visiting a project repository, a user can
clone (figure 16) a project by accessing a drop down menu. From the drop down menu a user can
access a https URL. Once the Git software is installed, a user can use a command line interface to
clone a project like so: git clone https://github.com/XinyuLuan/HBU.git. Once the project is
cloned, they can use an IntelliJ IDE to make changes to the project. It is up to the team to
communicate with one another so that they know when to update. A git fetch command is
typically used to access the most current content of the project. Through the life cycle of the
software, many branches can exist so that development can occur concurrently without altering
pre-existing source code. The git branch command allows a developer to navigate through
different versions of the project, usually a branch is named accordingly with respect to the
Figure 16. A user can clone a project so that they can make a copy of a pre-existing
project to their local machine, thus, making contributions easier to manage.
31
features that it aims to modify (figure 17). The git branch command also shows all of the
branches that exist for that specific repository. By convention the master branch should contain
the most current working version of the source code of a given project. Ideally, if a user wishes to
update the AdminControllerToModiferUsers branch, they may do so by first navigating into that
branch with git switch AdminControllerToModiferUsers. Once they are in the same directory,
they can git fetch and git pull to bring the source code contents into their local machine. After
making modifications to the branch the developer should git push their contents followed by git
commit -m “message body that describes committed changes”, this previous command just
allows the repository to get updated with a brief description attached to it so that other developers
on the team will have a clue as to what changes were made. The process of using a source control
management like Git becomes an iterative one that fits the standards of agile development.
4.5 Test
Testing source code is just as important as developing the software; rigorous testing
should be implemented to reduce the possibilities of ‘bugs’ (unintended behavior from source
code). Some of the questions that we come across during the HBU testing phase is “does the code
work as intended?” Testing becomes trivially important; therefore, the IntelliJ IDE creates a test
package that is dedicated for the purposes of testing the software code. The process of testing
allows a developer to see if a given source code works as intended, therefore it is up to the
Figure 17. The git branch command will show the current
branch that a user is currently on as indicated by an asterisk.
32
developer to create their own tests. The goal of testing is to discover bugs so that they do not
propagate into the production’s finalized source code.
Tests by default need to be annotated with the @Test annotation, Figure 18 demonstrates
a test method called testAddOneStudent where a student service object will perform the
addStudent( ) method. This addStudent( ) method is an abstraction layer for the
StudentRepository Class, therefore if this test fails, then we will have a clue as to where to look
for the problem. Tests may seem tedious, but they are a necessary step in the process of
development. Tests should be created as soon as possible; once the addStudent( ) method is
created, a test method should immediately follow it. In this manner, bugs can be discovered
sooner rather than later.
Figure 18. A developer can ensure that a method works as intended by creating unit tests.
4.6 Deploy
The last and final step of the HBU application is deployment. During the production
process, the source code has been executed many times using the Tomcat server that exists within
the Spring Boot framework. This was done locally through each individual developer’s local
machine. Once a software development reaches its final stages in preparation to cater to end-
users, a dedicated server needs to be set up so that a web application can be accessed indefinitely.
The HBU application will have to utilize a third party cloud service like Amazon Web Services
[21] or Azure Cloud Services [22] to have a server running 24/7. Since these cloud services
33
follow the software as a service (SaaS) license model; centrally hosted and requires a subscription
fee, we defer deployment to the very last step of the SDLC. Even though it may be the last step,
recall that SDLC is a cyclical process. If any bugs are encountered throughout the lifetime of the
HBU application, developers can provide continuous integration/continuous development by
revisiting any one of the previous stages. With new versions of hardware and updates to
frameworks, reconfiguration is oftentimes inevitable.
34
5. END USER EXPECTATIONS
The three main actors of HBU are the administrator, instructor, and student. Each user
must register and create their account and only upon approval can they access the HBU
dashboard. Creating a username and password allows a user to go through the process of
authentication and authorization. The proceeding sections lists some of the common
functionalities each actor can perform while accessing the HBU web application.
5.1 Administrator
The ranking of roles in HBU are determined by RoleType, with the order of importance;
first being the highest ADMIN, INSTRUCTOR, and STUDENT. The administrator exists to
provide the highest authority; they will be providing approval to the users that wish to access the
HBU website.
➔ Login - administrators would be able to login to the HBU dashboard.
➔ Manage administrator - a super administrator’s role is of the highest role within the HBU
hierarchy. This role exists so that other administrators can be managed. Details pertaining
to the administrators can be changed this way.
➔ Manage instructor - instructors can be managed and details pertaining to the instructors
can be changed.
➔ Manage Student - students can be managed and details pertaining to the students can be
changed.
➔ Manage Courses - courses can be managed and details pertaining to the courses can be
changed.
➔ View Dashboard - an administrator’s dashboard can be viewed.
➔ Send Message - can send messages to all users.
35
➔ Approve Registration - can approve or deny registration to a user. A student might get
denied if they don’t meet the requirements of the university’s policy.
➔ Add Course Module - add course modules to the HBU database.
➔ Add Student - add students to the HBU database
➔ Add Student to Course - add students to a specific course.
➔ Add Instructor - add instructors to the HBU database.
➔ Add Administrator - the super administrator can add administrators to the HBU database.
➔ Create Course - create a course for an instructor.
➔ Remove User - the super administrator can remove any type of user.
5.2 Instructor
The instructor has a higher role compared to a student, therefore, their responsibilities as
an instructor is to mainly provide course content.
➔ Login - instructors can login to the HBU dashboard.
➔ Create Class Module - an instructor can create a class module that they will be teaching.
➔ Create Quiz and Exam - an instructor will be able to create quizzes and exams.
➔ Modify Quiz and Exam - the modification of quizzes and exams are possible.
➔ Remove Quiz and Exam - the instructor can delete quizzes and exams.
➔ Message Student - the instructor can send a message to a student.
➔ View Message - allows the instructor to view their messages.
➔ View Class Module - instructors can view their class modules that they are assigned to.
➔ View Courses - instructors can view their courses that they are teaching.
5.3 Student
Students that are accepted into the HBU will be allowed to complete a course curriculum
towards their degree or certification.
36
➔ Login - a student can login to the HBU dashboard.
➔ Add Course - a student can expect to register for courses.
➔ Remove Course - a student can drop a course from their schedule if the time frame is
within the deadline period to drop a course.
➔ View HBU Course Schedule - a student can view all the courses that HBU offer.
➔ View Course Schedule - a student can view their own current or past course schedules.
➔ Message User - a student can message other users of HBU.
➔ View Course Module - a student can view the course modules of all their courses.
➔ View Dashboard - a student can view the HBU student dashboard.
➔ View Unofficial Transcript - a student can request for an unofficial transcript.
37
6. CONCLUSION
Prior to the completion of this project, the goal of creating a more dynamic web
application that helped with users’ educational experience was only an idea. The current HBU
web page does not offer the tools necessary for users to complete their educational goals
remotely. However, throughout the software development life cycle of this project, end user
expectations from administrators, instructors, and students were made possible. The Model View
Controller (MVC) pattern was necessary for prototyping a frontend interaction so that users could
navigate a web application and hypothetically complete a web based curriculum. The Java Spring
Boot Framework has been an integral part of the HBU project itself since it offers an efficient
way to reuse software without having to rewrite boilerplate code. An extension of object
relational mapping allowed the HBU project to work with persistent data by bridging the gap
between a database and the business logic of software. Ultimately, this project introduces the
necessary components for a user to complete their educational curriculum by introducing an
authentication and authorization mechanism for their login actions. Furthermore, incorporating a
way to facilitate the transmission of files was a crucial feature that completed the end user
expectations of a web based experience. The completion of this project introduces all the
necessary features for a user to complete their educational curriculum remotely and openly invites
the very last step of the software development life cycle deployment.
38
7. REFERENCES
[1] Harvest Bible University, https://harvest.edu. Accessed 12 April 2021.
[2] Open Source Initiative, https://opensource.org. Accessed 15 April 2021.
[3] Spring Boot Framework, https://spring.io. Accessed 15 April 2021.
[4] Spring Initializer, https://start.spring.io. Accessed 17 April 2021.
[5] Apache Maven Project, https://www.apache.org. Accessed 20 April 2021.
[6] Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices,
Upper Saddle River, New Jersey: Pearson Education, Inc., 2003.
[7] Erich Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns - Elements of
Reusable Object Oriented Software, Indianapolis, IN: Addison-Wesley, Pearson
Education, Inc., 1995.
[8] Eric Evan, Domain-Driven Design, Boston, MA: Addison-Wesley, Pearson Education, Inc.,
2004.
[9] JpaRepository Documentation, https://docs.spring.io/spring-data/jpa/docs/current/api/org/
springframework/data/jpa/repository/JpaRepository.html. Accessed 20 April 2021.
[10] MVN Repository, https://mvnrepository.com. Accessed 20 April 2021.
[11] Elizabeth B. O’Neil, Object/Relational Mapping: Hibernate and the Entity Data Model
(EDM), University of Massachusetts, Boston, MA: 2008.
[12] Robert C. Martin, Clean Code - A Handbook of Agile Software Craftsmanship, Boston, MA:
Prentice Hall, Pearson Education, Inc., 2009.
[13] Chi-Wei Wang, [email protected], California State University of Pomona, CA: 2020.
[14] Xinyu Luan, [email protected], California State University of Pomona, CA: 2021.
[15] KanBanFlow, https://kanbanflow.com. Accessed 25 April 2021.
[16] LucidChart, https://www.lucidchart.com. Accessed 27 April 2021.
[17] IntelliJ IDEA, https://www.jetbrains.com/idea. Accessed 27 April 2021.
[18] Git Source Control Management, https://git-scm.com. Accessed 28 April 2021.
39
[19] HBU Application via github, https://github.com/XinyuLuan/HBU. Accessed 28 April 2021.
[20] Apache Tomcat, http://tomcat.apache.org. Accessed 28 April 2021.
[21] Amazon Web Services, https://aws.amazon.com. Accessed 28 April 2021.
[22] Microsoft Azure Cloud Services, https://azure.microsoft.com. Accessed 28 April 2021.