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, chiwang@cpp.edu, California State University of Pomona, CA: 2020.

[14] Xinyu Luan, xinyuluan@cpp.edu, 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.