Job Seeker Website Project Report On Object-Oriented Analysis And Design Major Computer Science.pdf

<span class="text_page_counter">Trang 1</span><div class="page_container" data-page="1">

<b>UNIVERSITY OF ENGINEERING AND TECHNOLOGY</b>

<b>Job Seeker Website</b>

<b>PROJECT REPORT ON OBJECT-ORIENTED ANALYSIS andDESIGN</b>

<b>Major: Computer Science</b>

<b>Supervisor</b>: Assoc. Prof. Trương Ninh Thuận

</div><span class="text_page_counter">Trang 2</span><div class="page_container" data-page="2">

<b>HA NOI – 2022</b>

</div><span class="text_page_counter">Trang 4</span><div class="page_container" data-page="4">

1.1 Admin interface

</div><span class="text_page_counter">Trang 5</span><div class="page_container" data-page="5">

CHAPTER 1 INTRODUCTION 1. Problem statement

1.1 Addressing the problem

As technology develops, online job portal is becoming increasingly popular. It is a much more convenient and easier way to find a appropriate jobs as seekers don’t have to waste their time outside. This evokes the need for a system to help the communication between job seekers and companies representatives. Jobs seekers need to find a job quickly and companies representatives need to find human resources meeting the requirements. This has come to a demand for a system to solve this problem.

1.2 Solution

JobSeeker.com is built as an online system serving as a medium to directly connect job seekers and companies representatives.

The system will be developed as a web application. The end users will interact with the system over the Internet via a wide range of devices (laptop, PC, tablet, smartphones).

This document is used to define terminology specific to the problem domain, explaining terms, which may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information.

2.2 Definitions

Introduction This document is used to define terminology specific to the problem domain, explaining terms, which may be unfamiliar to the reader of the use-case

</div><span class="text_page_counter">Trang 6</span><div class="page_container" data-page="6">

descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions

and other project documents can focus on what the system must do with the information. Definitions The glossary contains the working definitions for the key concepts in the JobSeeker.com website

a. Account

A record about a user/administrator containing information about his/her name, e-mail address, password, phone number and optional self-introduction. Each account has a unique user ID and a password, which are used to identify the user/administrator and grant them access to secure parts of the system.

b. Administrator

A person whose job is to ensure that the site is free of spam offer jobs or abusive behaviors. This entails approving offer jobs before they are published, deleting users with abusive behaviors.

c. Offer Job

An announcement posted by a registered company user about the job offered by that company user. An job offer contains information about the place, salaries and description of the job.

d. User ( Candidate, Company) 1. Candidate

A person who has a registered candidate account on the website. Candidate users are able to publish CV, view lists of jobs and apply for appropriate one.

2. Company

A person who has a registered company account on the website. Company users are able to publish offer job that can be uploaded after administrator approving.

e. Visitor

A person who is interested in viewing offer jobs on the website but does not have an account

</div><span class="text_page_counter">Trang 7</span><div class="page_container" data-page="7">

CHAPTER 2 SOFTWARE SYSTEM REQUIREMENTS 1. Use case diagram

</div><span class="text_page_counter">Trang 8</span><div class="page_container" data-page="8">

Figure 2.1 Use case model for JobSeeker website system

<small>2.</small> Use case specification a. User

</div><span class="text_page_counter">Trang 9</span><div class="page_container" data-page="9">

This use case starts when the Visitor request to create an Candidate Account on the website 1. The system display a form that asks the Visitors to enter the following information

2. Once the Visitor provides the requested information, the system verifies that the username is unique and all required fields are specified. It then adds a new account with the specified information to the user database.

Alternative Flows Missing Information

If any of the above fields (except for self-introduction) are not filled in, the system displays an error message. The Visitor can continue making changes to the registration form or cancel the registration, at which point the use case ends.

User ID Already Exists

</div><span class="text_page_counter">Trang 10</span><div class="page_container" data-page="10">

If the specified user ID already exists, the system displays an error message. The Visitor can continue making changes to the registration form or cancel the registration, at which point the use case ends

Pre-Conditions None. Post-Conditions

If the use case was successful, a new candidate user is added to the system. Otherwise, the system state remains unchanged.

This use case starts when the Candidate user request to sign in the website

1. The system display a form that asks the Candidate user to enter the following information: - Username

- Password

2. Once the Candidate user provides the requested information, the system verifies that the username and password is correct with the username and password in candidate user databases. Alternative Flows

Missing Information

If any of the above fields (except for self-introduction) are not filled in, the system displays an error message. The Candidate user can continue making changes to the registration form or cancel the registration, at which point the use case ends.

User ID or password doesn’t match

</div><span class="text_page_counter">Trang 11</span><div class="page_container" data-page="11">

If the specified user ID or password doesn’t match with the username or password in candidate user databases, the system displays an error message.

The Candidate user can continue making changes to the sign in form or cancel it, at which point the use case ends.

To sign in successfully, the Candidate user must have the data in the candidate user databases. Post-Conditions

If the use case was successful, the Candidate user can log in the website. Otherwise, the system state remains unchanged.

This use case starts when the Candidate user request to change password in the website 1. The system display a form that asks the Candidate user to enter the following information:

- Old password - New password - Retype new password

2. Once the Candidate user provides the requested information, the system verifies that the password is correct with password in candidate user databases; check new password with consistent security and match with retype new password

Alternative Flows

Missing Information

</div><span class="text_page_counter">Trang 12</span><div class="page_container" data-page="12">

If any of the above fields (except for self-introduction) are not filled in, the system displays an error message. The Candidate user can continue making changes to the

registration form or cancel the registration, at which point the use case ends. Password doesn’t match

If the specified password doesn’t match with the password in candidate user databases, the system displays an error message.

The Candidate user can continue making changes to the sign in form or cancel it, at which point the use case ends.

Password and retyped password don’t match

If the new password doesn’t match with the retyped password, the system displays an error message.

The Candidate user can continue making changes to the sign in form or cancel it, at which point the use case ends.

Candidate user have to sign in successfully. Post-Conditions

If the use case was successful, the Candidate user changes password successfully and the new password will be updated in Candidate user databases. Otherwise, the system state remains

</div><span class="text_page_counter">Trang 13</span><div class="page_container" data-page="13">

1. The system display a form that asks the Candidate user to view and change some of the following information:

- Full name - Email

2. Once the Candidate user provides the requested information, the system verifies the availability of full name and email

Alternative Flows Missing Information

If any of the above fields (except for self-introduction) are not filled in, the system displays an error message. The Candidate user can continue making changes to the registration form or cancel the registration, at which point the use case ends.

To sign in successfully, the Candidate user must have the data in the candidate user databases. Candidate user have to log in successfully.

If the use case was successful, the Candidate user update profile information successfully and it will be updated in databases. Otherwise, the system state remains unchanged.

This use case starts when the Candidate user request to update CV on the website 1. The system display a form that asks the Candidate user to upload CV as pdf file. Alternative Flows

</div><span class="text_page_counter">Trang 14</span><div class="page_container" data-page="14">

Error File

If this file is not a pdf file, the systems displays an error message. The Candidate user can continue making changes to the registration form or cancel the registration, at which point the use case ends.

The Candidate user have to log in successfully. Post-Conditions

If the use case was successful, the system receive this CV, update to databases and upload to your account. Otherwise, the system state remains unchanged.

This use case starts when the Candidate user request to filter job display on the website 1. The system display a list of filter button that Candidate user can choose to filter job:

- Name of job with Search field - Field of job with Select field - Location with Select field

2. Once the Candidate user provides the requested information, the system displays the appropriate list of offered job with filters.

Alternative Flows Not available Job

If the system can’t find any job with these filters, the system displays a notification message. Pre-Conditions

The Candidate user have to log in successfully.

</div><span class="text_page_counter">Trang 40</span><div class="page_container" data-page="40">

1.3 Identify subsystems and interfaces

Figure 4.5 The Database subsystem and interfaces

1.4 Identify design mechanisms

Table 4.2 Design and implementation mechanisms

2. Use case design and architecture refinement 2.1 Subsystem design

</div><span class="text_page_counter">Trang 41</span><div class="page_container" data-page="41">

Figure 4.6 The Database subsystem elements diagram

Figure 4.7 System dependencies class diagrams

2.2 Design sequence diagram

</div><span class="text_page_counter">Trang 42</span><div class="page_container" data-page="42">

Figure 4.8 Design sequence diagram for Apply Job Use Case

Figure 4.9 Design sequence diagram for Approve Job UC

</div><span class="text_page_counter">Trang 43</span><div class="page_container" data-page="43">

Figure 4.10 Design sequence diagram for Create Account UC

Figure 4.11 Design sequence diagram for Delete User UC

</div><span class="text_page_counter">Trang 44</span><div class="page_container" data-page="44">

Figure 4.12 Design sequence diagram for Edit Job UC

Figure 4.13 Design sequence diagram for Filter Job UC

</div><span class="text_page_counter">Trang 45</span><div class="page_container" data-page="45">

Figure 4.14 Design sequence diagram for Login UC

Figure 4.15 Design sequence diagram for Publish Job UC

</div><span class="text_page_counter">Trang 46</span><div class="page_container" data-page="46">

Figure 4.16 Design sequence diagram for Resolve Job UC

Figure 4.17 Design sequence diagram for Update Account UC

</div><span class="text_page_counter">Trang 47</span><div class="page_container" data-page="47">

2.3 Class design

Figure 4.18 Design VOPC for Apply Job UC

</div><span class="text_page_counter">Trang 48</span><div class="page_container" data-page="48">

Figure 4.19 Design VOPC for Approve Job UC

</div><span class="text_page_counter">Trang 49</span><div class="page_container" data-page="49">

Figure 4.20 Design VOPC for Create Account UC

</div><span class="text_page_counter">Trang 50</span><div class="page_container" data-page="50">

Figure 4.21 Design VOPC for Delete User UC

</div><span class="text_page_counter">Trang 51</span><div class="page_container" data-page="51">

Figure 4.22 Design VOPC for Add To Edit Job UC

</div><span class="text_page_counter">Trang 52</span><div class="page_container" data-page="52">

Figure 4.23 Design VOPC for Filter Job UC

</div><span class="text_page_counter">Trang 53</span><div class="page_container" data-page="53">

Figure 4.24 Design VOPC for Login Form UC

</div><span class="text_page_counter">Trang 54</span><div class="page_container" data-page="54">

Figure 4.25 Design VOPC for Publish Job UC

</div><span class="text_page_counter">Trang 55</span><div class="page_container" data-page="55">

Figure 4.26 Design VOPC for Resolve Job UC

</div><span class="text_page_counter">Trang 56</span><div class="page_container" data-page="56">

Figure 4.27 Design VOPC for Update Account UC

2.4 Database design

</div><span class="text_page_counter">Trang 57</span><div class="page_container" data-page="57">

CHAPTER 5 USER INTERFACE DESIGN 1. User interface design

Objectives of designing user interface:

● User-friendly interface

● Information is presented clearly and highlight important information

● Harmonious and bright colors

● Improve user experience on the website

</div><span class="text_page_counter">Trang 58</span><div class="page_container" data-page="58">

● Reusable

The website system is divided into two parts, the client side and the admin side. Therefore, each part needs to have a separate interface design with layouts and blocks to be reused. The following is the design of some typical interfaces and layouts for each section.

1.1 Admin interface

Most of the admin interface pages are divided into 3 parts as follows:

Figure 5.1 Admin interface Inside:

- Menu is the place to store a list of features for administrator, for example: Filter job, Apply Job,..

- Header contains the website's logo, user’ name

- Content contains the content of the specific function contained in the Menu. The admin page usually manages a list of objects, so it is necessary to build a tabular interface that the administrator can interact with. Thus, Content part usually has the following layout:

</div><span class="text_page_counter">Trang 59</span><div class="page_container" data-page="59">

Figure 5.2 Content part

</div><span class="text_page_counter">Trang 60</span><div class="page_container" data-page="60">

2. Result

Figure 5.4 Sign up

Figure 5.5 Sign in

</div><span class="text_page_counter">Trang 61</span><div class="page_container" data-page="61">

Figure 5.6 Candidate Homepage

Figure 5.7 Company Homepage

</div><span class="text_page_counter">Trang 62</span><div class="page_container" data-page="62">

Figure 5.8 Visitor View

Figure 5.9 Candidate Apply Job

</div><span class="text_page_counter">Trang 63</span><div class="page_container" data-page="63">

Figure 5.10 Candidate Pending Job

Figure 5.11 Candidate Update profile

</div><span class="text_page_counter">Trang 64</span><div class="page_container" data-page="64">

Figure 5.12 Company Resolve Job

Figure 5.13 Company Pending Candidate

</div><span class="text_page_counter">Trang 65</span><div class="page_container" data-page="65">

Figure 5.14 Job

Figure 5.15 Admin manage account

</div><span class="text_page_counter">Trang 66</span><div class="page_container" data-page="66">

Figure 5.16 Admin manage job

</div>