Tải bản đầy đủ (.pdf) (86 trang)

Object Oriented Analysis And Design (Int3110E 40)Job Recruitment Website.pdf

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (763.45 KB, 86 trang )

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

UNIVERSITY OF ENGINEERING AND TECHNOLOGY

VIETNAM NATIONAL UNIVERSITY, HANOI

Object Oriented Analysis and Design (INT3110E 40) JOB RECRUITMENT WEBSITE

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

<small>1.5.11View jobs information... 20</small>

<small>1.5.12View applicants in each job...20</small>

<small>1.5.13Delete posted jobs information...21</small>

<small>2.2.1 Use-case realisations: sequence diagrams...24</small>

<small>2.2.2 Use-case realisations: views of participating classes...38</small>

<small>2.2.3 Describe analysis mechanism...50</small>

<small>3. Use-case design...51</small>

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

<small>3.1.2. Identify design mechanisms...59</small>

<small>3.2. Describe the run-time architecture...60</small>

<small>3.3. Describe distribution... 61</small>

<small>3.4. Use-case design... 61</small>

<small>3.4.1. Design sequence diagrams... 61</small>

<small>3.4.2 Design view of participating classes...73</small>

<small>3.5 Subsystem design... 74</small>

<small>3.6 Class design... 75</small>

<small>3.7 Database design...85</small>

<small>3</small>

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

1. Requirements 1.1 Problem statement

Today, with the explosion of technology and the trend of globalization, almost everyone has smartphone and can connect to the Internet. So, they can easily find many different jobs anywhere, anytime. Besides, many businesses and companies want to recruit people with the right expertise for the job position, which is also a challenge. Realizing that potential market, our team has built and developed a job recruitment website. This website connects employees and employers with convenience in posting candidate information and finding suitable jobs. Currently, the application provides the main language is English and allows to expand more languages in the future.

1.2 Glossary Introduction

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

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

As an end user, directly use the main services of the application such as login,

A person whose job is to ensure that the site is free of harmful jobs or abusive activities. This entails deleting harmful jobs and users with abusive activities. System Notifications

These are the messages that the administrator sends to all users regarding system problems.

Account

A record about a user/administrator containing information about his/her name, email address and password. Each account has a unique email address and a password, which are used to identify the user/administrator and grant them access to secure parts of the system.

1.3Supplementary specifications Objectives

Describe the constraints as well as special requirements of the customers for the system, this is also a document issued to the customers for approval and as a reference for the design, implementation and testing of the system.

The model is deployed at recruitment service companies across the country. References

<small>5</small>

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

The system must operate reliably.

Fast data import and export speed, the results are returned no more than 5 seconds

Confidentiality of personal information of users.

Only the user who owns the user’s name and password can log in and use the functions corresponding to the account type.

Design Constraints

The system must provide a responsive web-based interface usable on computers and mobile devices.

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

Figure 1.4.1 Generalizing the actors

<small>7</small>

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

Figure 1.4.2 Use- case diagram from the Employees perspective.

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

Figure 1.4.3 Use- case diagram from the Employers perspective.

<small>9</small>

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

Figure 1.4.4 Use- case diagram from the Visitors perspective.

Figure 1.4.5 Use- case diagram from the Administrator perspective.

This use-case starts when the actor wishes to Login to the system. 1. Actor enters his/her email and password.

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

When user enters incorrect email and/or password, the system displays an error message, requests the user to re-enter it. Now, the user can stay on the login screen and re-enter the information correctly, or they will cancel the login, at which point the use-case ends.

Special Requirements

Users who want to use the system must log in, otherwise they are visitors. Pre-Conditions

The system has the login screen displayed. The user already has an account. Post-Conditions

If the use case was successful, the actor is now logged into the system. If not, the system state is unchanged.

2. The system forwards to the registration screen suitable for each type of user.

3. User enters information including name, email, password and if you are Employers, you must enter the company type

4. The system validates the information entered by the user.

5. User presses “REGISTER” button 6. Successful account creation and redirect user to login page

<small>11</small>

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

Alternative Flows

In the 3 step of the Basic Flow, if the user enters the wrong information or omits a <small>rd</small> certain field, the system will mark the wrong input field and request to re-enter it. Special Requirements

This is only a function for users who want to use the services. Pre-Conditions

The system has the register screen displayed.

User does not have a system account and has all the information required by the system (like email, name, …).

The user creates an account successfully if all valid data is entered, otherwise, the screen will report an error and stay on until the data in all fields meet the requirements.

2. User selects the information fields he/she wants to change, makes changes and requests the system to record.

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

User must not leave the required fields blank.

User must not enter new information in the wrong format or not meet the requirements.

Users have logged into the system and can open the interface to change information. Users have information that need to be changed or have not declared information.

1. User selects “Change Password” field.

2. User enters new password; then requests the system to record. Alternative Flows

In the second step of the Basic Flow, when entering the wrong format, the system will report an error and notify the wrong fields for users to re-enter.

Special Requirements

User must not leave the required fields blank.

User must not enter new information in the wrong format or not meet the

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

The system notifies user that password has been changed successfully. Extension Points

1.5.5 Update Employee’s achievements information Brief Description

This use case describes how a Candidate updates his/her profile in the system. The system displays the following information in editable fields and asks the Candidate to make changes to his/her profile:

*Add a new item in each editable fields (include: Professional

Qualifications/Language Proficiency/Training & Workshop, Referees/Academic Qualification/Working Experience).

1. User selects field they want to add. 2. The system forwards to the screen suitable for each of fields. 3. User selects “Add New” button,

enters the required fields and requests the system to record.

4. The system validates the information entered by the user.

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

1. User selects field they want to edit.

2. The system forwards to the screen suitable for each of fields. 3. User selects “Edit” button in the

existing items in editable fields which they want to edit then , makes changes and requests the system to record.

4. The system validates the information entered by the user.

*Delete item in each editable fields (include: Professional Qualifications/Language Proficiency/Training & Workshop, Referees/Academic Qualification/Working Experience):

1. User selects field they want to edit.

2. The system forwards to the screen suitable for each of fields. 3. User selects “Edit” button in the

existing items in editable fields which they want to delete.

4. The system sends a confirmation message to the user.

5. The user chooses whether to agree to the deletion or not

6. The system deletes that information of the user if employees agree.

Alternative Flows Missing Information

If any of the above fields are not filled in, the system displays an error message. The Candidate can continue making changes to the update form or cancel the update, at which point the use case ends.

Special Requirements *Add a new item/ Edit items:

User must not leave the required fields blank.

User must not enter new information in the wrong format or not meet the requirements.

*Delete items:

<small>15</small>

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

Only users who have created a new Professional Qualification before can delete. Pre-Conditions

Users have logged into the system and can open the interface. Post-Conditions

*Edit items:

The system notifies user that item has been changed successfully *Add a new item:

The screen shows the newly added information section.

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

Display the list of jobs on the screen that the Employees has applied to the employers.

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

2. After careful consideration, Employees select “Apply This Job” button to confirm the application for that company.

3. The system confirms and updates user information.

If the use case was successful, the system will notify Employees that they have successfully applied for the job.

1. The user must choose job category and the country they want. 2. The user clicks on the search icon to display the required jobs.

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

1. The user selects “POST A JOB” field to display screen interface.

2. The user enters information in the required fields and presses the confirm button to record by the system.

Alternative Flows

In the second step of Basic Flow, if the user entered incorrect format or left blank, the system will notify the user to re-enter it.

If the use case was successful, the system will notify Employers that they have successfully posted a job.

Extension Points None

<small>19</small>

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

1.5.11 View jobs information

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

This use case starts when a Company wishes to remove a recruitment information from the system.

1. The system displays list of news posted by this Company. 2. The Company deletes a new.

3. The system deletes the new from the system. Alternative Flows

Delete Cancelled

If the Company decides not to delete the new, the removal is cancelled and the use case is re-started at the beginning.

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

system state remains unchanged.

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

The above figure describes the high-level organisation of the software system. The system consists of three layers:

The Application layer contains the design elements that are specific to each use case of the system

The Business Services layer encapsulates some key abstractions and services common to all use cases. It is accessible from the Application layer

The Middleware layer offers services to enable data communication and management on distributed systems.

2.1.2 Key abstraction

<small>23</small>

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

Figure 2-2. Key abstractions used in the application

Employer: A record about a company account. Each company account has a unique user ID and a password, which is used to identify name of each company, and the recruitment news - this company hasposted.

Employee: A record about a candidate account. Each candidate account has a unique user ID and a password, which is used to identify who is candidate, and the recruitment news - this candidate has applied.

Jobs: A record about a jobs account. Each jobs account has a unique user ID, which is used to identify employer, and the function can be done.

2.2 Use-case realisations

2.2.1 Use-case realisations: sequence diagrams

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

Figure 2-3. Sequence diagram for login use-case

<small>25</small>

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

Figure 2-4. Sequence diagram for register use-case

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

Figure 2-5. Sequence diagram for update personal information use-case

<small>27</small>

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

Figure 2-6. Sequence diagram for change password use-case

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

Figure 2-7. Sequence diagram for update Employee’s achievements use-case(edit & add item)

<small>29</small>

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

Figure 2-8. Sequence diagram for update Employee’s achievements use-case(delete)

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

Figure 2-11. Sequence diagram for apply job use-case.

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

Figure 2-12. Sequence diagram for search jobs use-case.

<small>33</small>

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

Figure 2-13. Sequence diagram for post jobs use-case.

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

Figure 2-14. Sequence diagram for view jobs information use-case.

<small>35</small>

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

Figure 2-15. Sequence diagram for view applicants use-case.

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

Figure 2-16. Sequence diagram for delete posted jobs use-case.

Figure 2-17. Sequence diagram for logout use-case. 2.2.2 Use-case realisations: views of participating classes

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

Figure 2-18. VOPC for Login use-case.

Figure 2-19. VOPC for Register use-case.

<small>39</small>

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

Figure 2-20. VOPC for update personal information use-case.

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

Figure 2-21. VOPC for change password use-case.

Figure 2-22. VOPC for update Employee’s achievements use-case.

<small>41</small>

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

Figure 2-23. VOPC for view applied jobs use-case.

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

Figure 2-24. VOPC for view CV use-case.

<small>43</small>

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

Figure 2-25. VOPC for apply jobs use-case.

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

Figure 2-26. VOPC for search jobs use-case.

<small>45</small>

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

Figure 2-27. VOPC for post jobs use-case

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

Figure 2-28. VOPC for view jobs information use-case .

<small>47</small>

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

Figure 2-29. VOPC for view applicants use-case

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

Figure 2-30. VOPC for delete posted jobs information use-case

<small>49</small>

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

Figure 2-31. VOPC for logout use-case 2.2.3 Describe analysis mechanism

Analysis mechanism characteristics Security

Data granularity: attribute level

User granularity: three roles – USER, MANAGER and ADMIN Security rules:

o Only registered USER/MANAGER/ADMIN may log into the system. o Only logged in users may view and edit their own account profile. o A news could be deleted by its owner or admin

o A news can not be edited

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

Professional_qualification Professional_qualification, Database

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

JobsController CVController ProfileController

Table 3-1. Analysis-Class-To-Design-Element map 3.1.1.2. Identify subsystems and interfaces

The Database subsystem provides support for relational databases written in the SQL language. The subsystem is designed as follows:

3.1.1.2. Identify subsystems and interfaces

The Database subsystem provides support for relational databases written in the SQL language. The subsystem is designed as follows:

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

Figure 3-1. The Database subsystem and its interfaces 3.1.1.3. Identify packages

Each layer in the analysis corresponds to a high-level package in the system.

<small>53</small>

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

The Application package

Figure 3-2. The Applilcation package and its sub-packages

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

• The View sub-class is the realisation use cases related to the viewing and searching of news. This part of the application can be freely accessed by anyone.

• The User Interaction sub-class contains classes involving actions which require the user to be logged in: updating profile, apply, view candidate’s applied jobs, view comapny’s jobs and post job.

• The Administration sub-class contains utilities that help administrators maintain accounts, candidates and companies.

The Business Services package

<small>55</small>

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

Figure 3-3. The Business Services package

The Business Services package contains the Database subsystem and its interfaces,

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

Figure 3-4. The Middleware package

The Middleware package includes Java’s SQL package, which provides access to databases and the Java Spring framework, which provides network services. Packages and their dependencies

As already stated, the Application package depends on the Business Services package, which in turn depends on the Middleware package.

<small>57</small>

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

Figure 3-5. Package dependencies diagram

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

3.1.2. Identify design mechanisms

Analysis mechanism Design mechanism Implementation mechanism

Table 3-2. Design and implementation mechanisms

<small>59</small>

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

3.2. Describe the run-time architecture

Figure 3-6. The system’s process model

</div>

×