UML-based Design of Vendor and Employee Management System

Paper ID #34429

UML-based Design of Vendor and Employee Management System

Mr. Michael Porter, Alabama A&M University

Michael Porter is a junior currently attending Alabama A&M University in Huntsville, Alabama, where heis working towards his undergraduate degree in Computer Science with a concentration on cybersecurity.He has experience in many programming languages, including Python, Java, and JavaScript. Michael hasperformed research into the application of UML and object-oriented programming principles.

Dr. Ralph (Phil) Bording, Alabama A&M University

Dr. Bording is a Research Professor at Alabama A&M University. He received his Ph.D. from The Uni-versity of Tulsa in 1995. Active in computational science education he has worked on seismic modelingand data analysis for many years. Currently, he is developing algorithms and educational materials formassively parallel computing machines.

Dr. Yujian Fu P.E., Alabama A&M University

Dr. Yujian Fu is an associate professor of computer science department at Alabama A&M University.Her research interests fall in formal verification of cyber physical systems, behavioral analysis of mobilesecurity, software architecture and design analysis of safety-critical and mission-critical systems. Herprojects are supported by NSF, Air Force and DoD. She have several publications regarding to the researchand educational projects.

c©American Society for Engineering Education, 2021

2021 ASEE Annual Conference

© American Society for Engineering Education, 2021

UML Based Design of Employee Information Management System

Michael Porter, Phil Bording, and Yujian Fu

Alabama A&M University

Abstract

This student project developed a Vendor and Employee Management System (VEMS) that

organizes employees and vendor information using UML model based on object-oriented

software development methodology. A good employee and vendor database system is a critical

piece of software for a business of any size. It is important that detailed information of a

company’s employees, vendors, and payment history are recorded in order for the business to

operate efficiently and comply with the law. The requirements for this system include: (1) the

ability to track employee information, such as salary, responsibilities, seniority and other

relevant information, (2) the ability to track job applicants, including their contact information,

resume, etc., (3) the ability to track vendors that the company purchases products or services

from, as well as a history of any invoices that the company has received, and finally (4) the

ability to track payments that have been paid to both employees and vendors. With the

complexity of the above system requirement, considering software development life cycle

(SDLC), we have three objectives for this student project: (1) master and apply the fundamental

and key concepts of UML design; (2) analyze the nonfunctionalities as well as functionalities of

the designed system in terms of reliability and security; (3) map the design into implementation

and ensure the software quality. The VEMS application was selected for this project because it

can incorporate many different classes and has multiple use cases. This student project serves as

an additional perspective for educators to consider when using UML and Object-Oriented design

with project-based learning. A variety of UML diagrams were designed for this project including

class, state, and use case diagrams. Since these diagrams were designed as part of a class project,

revisions were suggested by the instructor and the rational for these changes is discussed. The

resulting implementation of the VEMS contains 11 user-defined classes, 10 visual C# forms, and

approximately 2,000 lines of code. The final project was determined to satisfy all learning

objectives.

Keywords

Object-Oriented Design with UML, Vendor System, Employee Management System, Applied

UML

I. Introduction

The design of a Vendor and Employee Management System (VEMS) is tricky due to multi-

dimensional relations of the data items to the vendors and employees in the system. In addition,

actions of each actor interact and relate to others in a networked relationship. Data design, actions

and networked authorization are challenges to consider when performing the vendor system design

and management.



Unified Modeling Language (UML) plays a de facto role in the real time software intensive design

in many aspects and operations from cell phones, military applications, and financial systems, etc. 1 . Using UML allows us to describe an overarching view of the system. It can describe, for

example, the different use cases for the system, as well as the relationships between objects. For

instance, it can describe the relationship between a company and its vendors (a one-to-many

relationship). UML also allows us to see how the state of objects change with time. UML can also

be used to map out the changes that an applicant goes through during the job application process.

This term project was designed and implemented during Fall 2020 semester, and was designed to

create a student experience to practice and instantiate Object Oriented Design concepts and

modeling skills in a real-world project. Unified Modeling Language, when properly applied during

the design phase, has been shown to later result in increased source code comprehensibility 2 .

Pedagogically, the learning goals for the fall project are in two categories: (1) one static design

model and a minimum three dynamic design models in the conceptual level; (2) application and

skills of modeling real world system in the project-based learning paradigm. With all the above

considerations and goals, the objectives of this term projects can be elaborated as follows. (1) In

this class students are able to master the fundamental syntax of object-oriented design and four

UML design models with the applications domains; (2) students are able to understand and

implement the modeling skills of the four design models with the given guidelines; (3) students

are able to properly design and analyze the design model; (4) students are able to transfer design

model into the implementation of an object-oriented programming language (preferably Java, C#,

or C++). The implementation discussed in this paper was written in the C# programming language.

During the project design phase, students are expected to be able to use and apply the UML design

tools.

II. Background/Related Works

A recent study in 2018 found that there is growing scientific interest in UML model execution,

and that the lack of coverage of the UML language is its most common limitation 3 . It is relevant

to study how it can be applied in a variety of applications to understand its limitations, and what

applications it is best suited for. For instance, a paper published in i-KNOW 2015 explores the

possibilities of using a 3D space for UML class diagrams 4 . In this paper, we analyze how UML

can be applied in the development of a VEMS.

It is important that detailed records of a company’s employees, vendors, and payment history are

recorded in order for the business to operate efficiently and comply with the law. The

requirements for this system includes: (1) the ability to track employee information, such as

salary, responsibilities, or other information deemed relevant to the system, (2) the ability to

track job applicants, including their contact information, resume, etc., (3) the ability to track

vendors that the company purchases products or services from, as well as a history of any

invoices that the company has received, and finally (4) the ability to track payments that have

been paid to both employees and vendors.

III. Design Model of the System

In this section, we will present the main three UML models including class diagrams, state

diagrams, and use case diagrams of the system design. A class diagram demonstrates the static



structure of the system in the organization of objects. State diagrams will illustrate the dynamic

aspects of the objects with regarding to each class. While use case diagram provides a high-level

view of the system in terms of scenarios and sequences of functions which may be related to one

or more scenarios. State diagrams and use case diagrams represent the system dynamic aspect from

a different level of granularity.

3.1 Class Diagram

The class diagram of the system modeling provides the essential framework into which the state

and interaction models can be placed. Changes and interactions are meaningless unless there is

something to be changed or with which to interact. Objects are the units into which we divide the

world, the molecules of our models 5 . In the VEMS design, twelve user defined classes are

developed to support the specified system functions. In addition, 2 packages, 11 user-defined

classes and 5 predefined packages were adopted to support the object design. The overall class

diagram is shown in Figure 1.

A list of user-defined classes is shown in Table I, and a description of each class is given. In this

class model, the Employee and Applicant classes inherit from the Person using a generalization

relationship. The Invoice class is referenced by the Payment class if the payment is part of an

invoice. Otherwise, it will be null. Each company has many Jobs. The PayPeriod class is a dated

container for all the payments between a start date and end date. Its functions include the ability

to add payments to it, or view all the payments in that PayPeriod.

Figure 1. The class model of the VEMS.



Table I. A list of the user-defined classes designed for the VEMS.

Class Name Descriptions

Applicant Represents a person that has applied to a specific job in the system. It holds

information of the applicant’s resume, the application date, the application

status, and interview status. The Applicant class inherits from the Person

class.

Company Contains some basic information about the business, such as name, founding

date, number of employees, vendors, and pay periods.

Employee Represents an employee of the company. The class inherits from the Person

class and associated with PayableEntity class. It contains information such as

the employee’s start date and salary, and also a reference to the employee’s

job and manager.

Invoice Represents an invoice received from a vendor for a product or service. The

invoice contains information about the date the invoice was received, a

description of the product or service, the unit price, and the quantity.

Job Contains information about a job position that the company offers, which

includes the job description, requirements, and status. It is referenced by

both the Employee and Applicant classes.

PayableEntity An abstract class that represents an entity (either a person or business) that

may receive a payment from the company.

PayPeriod Represents a period of pay, which has a start date and an end date.

Payment Includes information about the payment amount, the payment period, and a

reference to the recipient of the payment.

Person Represents a single person in the system with the common attributes and

operations of the person objects of the system. It contains basic profile

information, such as name, gender, and birth date, as well as contact

information, such as address and phone number.

Vendor Represents another business that the company purchases either products or

services from. A vendor has the ability to invoice the company for those

products or services. This class contains the vendor’s name, as well as a

point of contact for the vendor. It also has a reference to the vendor’s

invoices.

Program This is the aggregate class that holds the essential object references and

instantiate them to start the application.



Payment processing is one of the key functionalities of the company and employees. In our

implementation, three classes are designed to complete the process of payment – PayPeriod,

Payment, and PayEntity class. The UML class definition of each is shown in Figure 2. A short

description of these payment process classes is given below:

PayPeriod Class: The PayPeriod class represents a period of pay, which has a start date and an

end date. Each pay period has associated with it some payments, issued to either vendors or

employees. For example, a company may issue payments on the 1st and 15th of each month, so it

would have two pay periods for each month.

Payment Class: The payment class represents a payment from the company to a payable entity

(either an employee or a vendor). The payment includes information about the payment amount,

the date of the payment, and a reference to the recipient of the payment.

PayableEntity Class: An abstract class containing information about a potential payee, and their

payment information. It contains information about the entity’s financial institution, such as

routing and account number.

3.2 State Diagrams

A state diagram is useful to define all possible states that an object can contain within the

application. It also shows how those different states relate to each other. Due to limited space, we

have shown four state diagrams developed for the corresponding classes. A summary is shown in

Table II below.

Figure 2. A selected class definition in UML Class model (a) Payment class (b) PayPeriod class (c) PayableEntity class.

(a) Payment class (b) PayPeriod class (c) PayableEntity class



Table II. A list of state diagrams of some critical user-defined classes for the VEMS.

State Diagram (SD) Description

Applicant SD Models the state transitions of application process.

Employee SD Denotes the state change of employee object from on duty to off duty.

Invoice SD Represents the status change of Invoice object.

Payment SD Denotes the dynamic aspects of Payment object and how the payment is

processed.

Applicant State Diagram: The state diagram for an Applicant (Figure 3. (a)) illustrates all the

different states that an applicant can assume while applying for a job. The applicant starts by

applying, and ends up either being rejected, declining the position, or accepting the position.

Payment State Diagram: All payments must be approved by accounting before they are sent.

After the payment is reviewed, it is either rejected or sent. If the payment is sent and there are

insufficient funds, then the payment is marked as incomplete. Otherwise, the payment is marked

as completed. This state diagram is shown in Figure 3 (b).

Employee State Diagram: This state diagram (Figure 4. (a)) describes the different states an

employee can be in during their workday. An employee starts out working, and then continues

working until they either take a break or go off duty. They will eventually return to working again.

Figure 3. A state model (a) state diagram of Applicant object (b) state diagram of Payment object.

(a) (b)



Invoice State Diagram: The invoice state diagram (Figure 4. (b)) shows how an invoice object

can change. An invoice starts out by being received by the company. After it is reviewed, it is

either found to have a discrepancy or it is approved. Finally, it is either revised, rejected, or paid.

From the above diagrams, the Employee object and Applicant object have different state changes

due to the interactions with different externals, which can be elaborated from the use case diagram

found in the next section. Invoice objects focus on the finalization of the payment documents and

has interactions with vendors.

3.3 Use Case Diagrams

A use case diagram demonstrates the interaction of the system with the external entities or actors.

Use case diagrams are useful for showing how an application will be used by its different end users.

For instance, the users of the VEMS would be the employees and job applicants. It should show

all the potential use cases for each actor, as well as which role each actor performs in that use case.

In Figure 5, three external actors are involved with the system in eleven use cases. These use cases

fall in the three domains – job listing, management, and payment processing. A manager is

responsible for accepting or rejecting job applicants. Meanwhile, the Job Applicant is able to

search and apply for a job listed. An employee is able to receive the payment based on the created

pay period and invoice. In addition, the Create Payment use case is generalized by Vendor Payment

and Payroll Payment, which handle the financial data of Vendors and Employees.

Figure 4. State model (a) Employee class state diagram (b) Invoice class state diagram.

(a) (b)



IV. System Implementation and Results

The application is a Windows Forms application consisting of 10 different forms. Aside from the

forms, the application contains 11 different classes, and totals approximately 2,000 lines of code.

The forms created in this application consists of the Login, Home, Invoice, View Invoices, View

Pay Periods, View Pay Period, View Payment, View Applications, View Company Information,

and View Employee forms.

Each form consists of a graphical user component as well as an application logic component. For

example, the graphical user component of the login form would be the username and password

boxes, and the login button. The application logic component would be the code that checks that

the credentials the user enters are valid and then launches the next part of the application if login

is successful. Some of selected user interfaces are shown in Figure 8.

Each form makes a call to the InitializeComponent method in its constructor. This method creates

and initializes all of the different graphical components that the user will see. For instance, an

excerpt from the login form’s initialization method is shown in Figure 6.

Figure 5. The use case diagram of a potential VEMS.



Once the form’s graphical components are initialized, we can then add event handlers to be called

when a specific action is taken by the user. For instance, if we want to exit the application when

the cancel button is clicked, then we create a method cancelBTN_Click. The names of these

handler methods are determined by the convention defined in the Visual C# documentation 6 .

The login form is the first thing displayed when the application is run. Currently, a user can enter

any username and password because the implementation is not connected to any database for

validation.

Once on the home form, several key functions are provided, such as viewing pay periods and

payments, viewing vendor invoices, viewing employee files and company information, and

viewing job applications.

The user is prompted to select a monthly pay period in order to view the payments made during

that month. Once the user selects a pay period, they will click the view period button, which will

open up a list of payments.

Once the payment is issued, it is available in the read only mode (the user is not allowed to edit

any of the details). If the user were to create a new payment, it would use the same form but the

user could interact with the form controls.

Figure 6. The Login Form’s initialization method system.

Figure 7. The cancelBTN_Click method.



V. Analysis, Validation and Discussion

A VEMS is used to manage the personnel, vendor information, human resource, finance and

payment of employees. It is highly desirable for the system to maintain reliability, robustness,

responsiveness, with high performance. To validate the system requirements, we investigated

several nonfunctionalities, corresponding tests were performed.

White box testing is a type of testing used to observe the internal behavior during execution.

White box testing is used to identify or track the errors from the function and variable view. The

results from white box testing provides a finer view of the internal behaviors of each object in

regarding to the signals received. In this project, MSTest is adopted to validate the C# code 7 .

MSTest, also referred to as the Unit Testing Framework, is a unified framework that provides

support the effective unit tests to test software applications. MSTest is an open-source test

framework with the Visual Studio IDE. MSTest provides a set of commands with a lot of options

to customize the tests running at various NET applications.

(a) (b)

(c) (d)

Figure 8. Some selected interface of the VEMS (a) user log in page; (b) home page; (c) pay period page; (d) view/edit pay period page.



In order to reach the previously-stated design goal, several critical properties of the system are

defined below, e.g., reliability & robustness, authentication, correctness, and identity.

Reliability and Robustness: Using UML and object-oriented concepts to plan and design the

employee and vendor management system resulted in a more reliable and robust system.

Authentication: A very naïve and basic form of authentication was added to the application in

the form of a hard-coded username and password pair that must be entered to access the home

menu. This could be further developed to use a database to store user access credentials. For any

user (u), if the login credential (user name and password) is validated, the user will be able to

access the home menu. valid(u.username, u.password) -> u.loggedin. The test code snippet is

shown in Figure 9.

Correctness: The correctness of the application logic is able to be verified using unit testing. For

instance, we want to make sure that our invoice class is able to add up the total amount due

correctly. To do this, we can implement a test with three items o1, o2, and o2. We can then

verify that the sum of their unit prices (p1, p2, p3) multiplied by their quantities (q1, q2, q3)

gives us the expected result. (p1 * q1 + p2 * q2 + p3 * q3 = total). Test code snippet is shown in

Figure 10.

Figure 9. A test of user authentication for the login process.

Figure 10. A test for the correctness of the total price of the invoice.



Identity: Any instance of the system must have distinguishable identification, i.e., for any two

objects o1 and o2, (o1 == o2) implies the two objects hold the same name, attributes and

operations; on the other side, if o1 and o2’s attributes and operations are same, but names

different, then (o1 != o2). For instance, to test the identity of the instances of the Employee class,

two objects were created with same reference but different value (Figure 11).

This code creates an employee Linda. In the first test, we are checking if Linda and Linda are the

same, which is of course true. In the second test, we are asserting that Linda and a different

employee are not the same person, which is also true. Because both cases are true, the tests pass.

VI. Analysis of Learning Objectives

In this section, based on the results of this project, we will analyze how the goals and objectives

were met to gain a perspective into the effectiveness and student experience of using UML and

Object-Oriented design concepts in conjunction with project-based learning. This perspective

would be valuable to raise critical thinking and facilitate the conceptual learning in high level

computer science and STEM classes.

It is well noticed that the theme of project-based learning is learn-by-doing. Students will gain

experience by being exposed to real world problem and challenges and finding solutions by the

applying concepts and methodologies. This class was planned to ensure that students are

provided an environment for the successfully tackling of a problem using the knowledge units,

not just landing a job.

To align with the course objective of changing mindsets from “wild” code writing to prior planning

and documentation, each learning objective has a corresponding assessment with the analytic

rubric in support the effectiveness of project-based learning, which includes lectures, assignment

and quizzes. These supporting assessments conform to the overall goal of the class. The project is

Figure 11. A unit test for the identity of an employee object.



evaluated by the modules and milestones with deadlines. Applications not respecting those

blueprints are entirely dismissed, even if they are completely functional. Project milestones include

proposing project topics, brainstorming the project, creating the initial design models, writing a

midterm report, creating dynamic models, completing the implementation, and writing a final

report. The “back-office” assessment of the deliverables is based on two parameters:

• Achievement of milestone goals: where technical quality is analyzed with readability and

organization of blueprints, to discourage traditional downplay of documentation;

• Progress since the last milestone: to reward improvement made by those who cease the

opportunity to learn and revise documents from one milestone to the next.

Pedagogically, the learning goals for the fall project are in two categories: (1) one static design

model and a minimum three dynamic design models in the conceptual level; (2) and the skills

required to model a real-world system in the project-based learning paradigm. The learning

objectives regarding the project is shown in Table III below.

Table III. Project Evaluation Regarding The Learning Objectives

O1. Master the fundamental concepts of OO design and syntax of (four) UML models

The classes are identified with correct attributes, and operations and defined in correct

UML notations. The class model was developed with correct relations. All states were

properly defined and captured the key observable transitions. Sequence of functions

were identified in the proper use cases and reflected in the related scenarios. Control

flow was modeled with correct activities and execution sequences are captured in the

activity diagram.

O2. Understand and implement the modeling skills with the instructions.

Each element as well as each model were properly described regarding the semantics. It

is one of the key objectives to ensure the implementation is a reflection of the design

model.

O3. Be able to apply the design and analyze the design model.

The significance of the modeling was introduced in the delivery in addition to the design

background. The testing was performed based on the properties defined on the system

specification. Testing results are analyzed and properties are held.

O4. Transfer the design model to the OO programming language in C# here.

During the implementation, the functional classes are defined based on the class model.

The method invocations and object communications were carefully investigated against

the state models and use case models.

The evaluation criteria include: (1) rationale, goal and objectives; (2) literature review; (3) syntax

of model; (4) matching the semantics of the problem domain; (5) writing style; (6) using



references throughout the document; (7) implementation; (8) testing; (9) result analysis,

conclusion and future works; (10) formatting. The overall evaluation regarding the above criteria

is given in Table IV, where each criterion is denoted by Ei, e.g., E1 refers to the first criteria, E9

refers to the nineth criteria.

Table IV. Criteria and Assessment

Criteria Learning

Objectives

Percentage

E1. Rational, goal and objects O1, O2, O3 10%

E2. Literature review O1, O4 10%

E3. Syntax of model O1, O2, O3 20%

E4. Matching the semantics of the problem domain O3, O4 5%

E5. Writing style 10%

E6. Using references throughout the document 10%

E7. Implementation, classes, program structure, comments,

etc.

O2, O4 15%

E8. Testing O3 5%

E9. Results analysis, conclusion and future works O1, O2, O3 10%

E10. Formatting 5%

VII. Design Challenges and Lessons Learned

Class identification is the initial key step of creating a design model. It is common for designer to

form up the classes based on the physical entities. In the original class model, the Employee and

Manager classes were defined as two different classes. Each of the Employee and Manager

classes formulated their own entities with their own sets of attributes and operations. Discussion

during the analysis phase revealed that many of these attributes and operations were shared

between the two classes. A simplified design is to merge the Manager class into the Employee

class by adding an attribute to designate if the employee was a manager. This design simplifies

the program by reducing the number of objects with common data and behaviors, and reduces

code complexity.

Program execution status can be observed and analyzed using a state diagram. For the state

diagram of the Job Applicant class, originally, there were two different waiting states, one for

when the applicant was waiting to be interviewed, and another for when awaiting a decision from



the applicant. It was discovered that two waiting states represents the same candidate for the

same Job Applicant object, so one was removed. This will reduce the complexity of the system

implementation.

VIII. Conclusion and Future Work

The Vendor and Employee Management System (VEMS) is important for any business to have

an intelligent, flexible and maintainable IT infrastructure. In this VEMS, the detailed records of a

company’s employees, vendors, and payment history are recorded in order for the business to

operate efficiently and effectively. In addition, the validation of records will ensure the business

complies with the law. An employee database system was created and corresponding functions

for data storing and retrieving were developed.

The system was developed in the models specified in Unified Modeling Language from different

levels of abstraction. By this design model, we understand how to represent the structure and

relationships of the objects in the program. Using UML to define all the different use cases and

structure of the application allows for a streamlined development process and allows us to avoid

potential errors. Class diagrams, use case diagrams, and some other dynamic diagrams have been

used in order to plan out the application in both static and dynamic views. Through this project, a

well understanding of OOP concepts such as encapsulation, abstraction, inheritance, and

polymorphism and how to simplify the implementation of the application were outlined and

described clearly. It is obvious to say these well-defined models make it easier to maintain.

Finally, the system requirement properties are defined and specified. To validate the system

against the requirement, some unit tests were performed and results have been demonstrated.

This class project validates our programming skills learned in CS1 and CS2 in addition to the

high-level design concepts. Project based learning provides a wonderful stage for students to

play with all programming skills and master the design and modeling concepts and theories.

Acknowledgement

The authors would like to thank the reviewers for taking the time to provide us with comments

on how to improve the paper. This work is partially supported by NSF projects under award

numbers DUE-1525120.



References

1 C. F. J. Lange, M. R. V. Chaudron and J. Muskens, "In practice: UML software architecture and design

description," IEEE Software, vol. 23, pp. 40-46, 2006.

2 Scanniello, G., Gravino, C., Genero, M. et al., "Do software models based on the UML aid in source-

code comprehensibility? Aggregating evidence from 12 controlled experiments.," Empir Software Eng,

vol. 23, p. 2695–2733, 2018.

3 F. Ciccozzi, I. Malavolta and B. Selic, "Execution of UML models: a systematic review of research and

practice," Software & Systems Modeling, vol. 18, p. pages2313–2360, 2019.

4 L. Gregorovic and I. Polasek, "Analysis and design of object-oriented software using multidimensional

UML," i-KNOW '15: Proceedings of the 15th International Conference on Knowledge Technologies and

Data-driven Business, pp. 1-4, 2015.

5 M. Blaha, Object-oriented modeling and design with UML, Upper Saddle River: Pearson Education,

2005.

6 Microsoft, "Event Handlers Overview (Windows Forms)," Online. Available:

https://docs.microsoft.com/en-us/dotnet/desktop/winforms/event-handlers-overview-windows-

forms?view=netframeworkdesktop-4.8.

7 Microsoft, "Use the MSTest framework in unit tests," Microsoft, Online. Available:

https://docs.microsoft.com/en-us/visualstudio/test/using-microsoft-visualstudio-testtools-unittesting-

members-in-unit-tests?view=vs-2019.

Michael Porter

Michael Porter is a junior currently attending Alabama A&M University in Huntsville, Alabama.

He is working towards his undergraduate degree in Computer Science with a concentration on

Cybersecurity. He has experience in many programming languages, including Python, Java, and

JavaScript. Michael has completed research into the application of UML and object-oriented

programming principles.

Phil Bording, PhD.

Phil Bording is a research professor of the department of Electrical Engineering & Computer

Science at Alabama A&M University. His research interests fall in the areas of computer

science, computational artificial intelligence, and computer science education.

Yujian Fu, PhD.

Yujian Fu is a professor of computer science program at Alabama A&M University. Her

research focuses on the formal verification of cyber physical systems, mobile security analysis

and mission-critical systems.

Documents

UML-based Design of Vendor and Employee Management System