Plant information management PDF

Preview

Summary

Download Plant information management PDF

Description

HANOI UNVERSITY OF SCIENCE AND TECHNOLOGY

SCHOOL OF ELECTRICAL AND ELECTRONICS ENGINEERING

REPORT

Software Engineering PROJECT:

PLANT INFORMATION MANAGEMENT

Advisor

: Assoc. Prof. Thi-Lan Le

Students:

: Nguyễn Trường An 20193201 Vũ Tống Minh Hiếu 20193218 Đỗ Khôi Nguyên

20193234

Bàn Thị Thủy

20193239

TABLE OF CONTEN

TABLE OF CONTENT.............................................................................................................i TABLE LIST.............................................................................................................................ii CHAPTER 1: INTRODUCTION............................................................................................1 1.1 Context and Current Situation.......................................................................................1 1.2 Requirements..................................................................................................................1 1.2.1 Functional requirements..........................................................................................1 1.2.2 Non-functional requirements:..................................................................................1 CHAPTER 2: SYSTEM DESIGN...........................................................................................2 2.1 Use Case..........................................................................................................................2 2.1.1 System requirements .............................................................................................3 2.2 Detailed usecase..............................................................................................................4 2.3 Activity diagram............................................................................................................10 2.3.1 Login....................................................................................................................11 2.3.2 Change password.................................................................................................11 2.3.3 Search information..............................................................................................12 2.3.4 Modify plant information.....................................................................................12 2.3.5 Modify employee information..............................................................................13 2.4 Class diagram................................................................................................................14 REFERENCE..........................................................................................................................15

i

TABLE LIST

Table 2.1 Deriving Use Cases from System Requirements ............................................3 Table 2.2 Mapping: System requirements to Use cases

ii

CHAPTER 1: INTRODUCTION

1.1 Context and Current Situation: -

Nowadays, the Fourth Industrial Revolution is built upon the Digital Revolution where human and technology are connected. A number of new ways of demonstrating of its abilities have been recently found in many fields, such as: economy, physics, agriculture, … Our project is especially used in the forestry, which helps people to efficiently manage information about plants and their applications. Then, we would like to apply this project in herb management.

-

Normally, it is really hard to find documents about herb with its exact information. Books cost an arm and a leg to buy and the documents on the Internet are not sufficient. Hence, this app is created in order to help people search information in an easier way. Moreover, it provides a fuction that garden owners can manage their gardeners.

1.2 Requirements: 1.2.1 Functional requirements: -

Admin: o Manage the information of both plants and employees o Add new users o Search the data of users and plants

-

Employees: o Search information of plants o Manage their own account: change password, update their information, etc.

1.2.2 Non-functional requirements: Scalability: add more tools for further use Reliability: we use information from verified by many scientists Availability: this shows how long the user can use until periodically maintenance

1

Capacity: up to 100000 plants Maintainability: 75% for 24hr Security: admin only Manageability: define herbs in terms of diseases Environmental: Android Usability: friendly interfaces

CHAPTER 2: SYSTEM DESIGN

2.1. Use Case: U1: Login/ Logout U2: Change password U3: Update my information U4: Search information U5: Modify plant information U6: Modify employee U7: Authenticate User

Login /Logout

U6: Log in Change password

Update my profile

Employee

Admin U7: Log out

Search

Modify plant information

2

Modify employee information

2.1.1.

System requirement:

REQ1: Unlock when valid password. REQ2: Modify plant information at runtime. REQ3: Modify employee information at runtime. REQ4: Search plant information at runtime. REQ5: Search employee information at runtime. REQ6: Change password.

Initiator

Initiator’s Goal

Participants

Usecase

Admin, Employee

Login /Logout

Database

Login / Logout(UC-1)

Admin, Employee

Change password – personal account

Database

Change password(UC-2)

Admin, Employee

Change and update information

Database

Update my profile(UC-3)

Admin

Search information

Database

Search informaton(UC-4)

Add new plant information, remove, update plant information

Database

Modify plant information

Add new employee account, remove, update information

Database

Employee Admin

Admin

(UC-5) Modify employee information (UC-6)

Table 2.1 Deriving Use Cases from System Requirements

3

Requiremen t

UC1

REQ1

X

UC2

UC3

UC4

UC5

UC6

UC7 X

X

REQ2 X

REQ3

X

REQ4

X

REQ5

X X

REQ6

Table 2.2 Mapping: System requirements to Use cases

2.2. Detailed Usecase: Use Case 1: Login / Logout Use Case UC-1:

Login /Logout

Related requirements: REQ1 stated in Table 2.2 Initiating Actor:

Any of: admin, employee

Actor’s Goal:

To login or logout from the app

Participating Actors:

Database The set of valid accounts stored in the system database is nonempty. The application displays the menu of available functions; On the application screen, the menu choices are “Login” or “Logout”.

Preconditions:

Postconditions:

If login: Users can access the application when valid account.

If logout: Screen direct to login function Flow of Events for Main Success Scenario: 4

1. Admin/Employee selects the menu “Login”/ “Logout” 2. include::AuthenticateUser (UC-7) 3. Admin/Employee enter the application Flow of Events for Extensions (Alternate Scenarios): 1a. For axample, admin/employee enter invalid data

Use Case 7: AuthenticateUser Use Case UC-7:

AuthenticateUser(sub – use case)

Related requirements:

REQ1 stated in Table 2.2

Initiating Actor:

Any of: admin, employee To be positively identified by the system (at the first interface)

Actor’s Goal: Participating Actors: Preconditions:

Database The set of valid accountstored in the system database is nonempty.

None worth mentioning Postconditions: Flow of Events for Main Success Scenario: 1. System prompts the actor for identification. 2. Tenant/Landlord supplies a valid identification account 3. System verifies that the account is valid, and signals to the actor the account validity. Flow of Events for Extensions (Alternate Scenarios): 2a. Admin/Employee enters an invalid identification account 1. System detects error, marks a failed attempt, and signals to the actor 1.1 System detects that the count of failed attempts exceeds the maximum allowed number, signals to sound AlarmBell, and notifies the Police actor of a possible break-in 2. Admin/Employee supplies a valid identification account 3. Same as in Step 3 above 5

Use Case 2: Change password Use Case UC-2:

Change password

Related requirements: REQ6 stated in Table 2.2 Initiating Actor:

Any of: Admin, Employee

Actor’s Goal:

Change personal account password

Participating Actors:

Database

Preconditions:

The set of valid accounts stored in the system database is nonempty.

Postconditions: The new account information is saved to the database Flow of Events for Main Success Scenario: 1. Admin/Employee select the menu “Change password” 2. Admin/Employee enter old password. Then, enter a new password. 3. System verifies that the password is changed. Flow of Events for Extensions (Alternate Scenarios): 2a. Admin/Employee enters an invalid old password 1. System detects error, marks a failed attempt, and signals to the actor 2. Admin/Employee supplies a valid password 3. Same as in Step 3 above

Use Case 3: Use Case UC-3:

Name / Identifier

Related requirements:

REQ3

Initiating Actor:

Any of admin, user 6

Actor’s Goal:

To add/remove/change their identity information on the system

Participating Actors:

Database

Preconditions:

+ User login successfully + The system displays the menu of available functions including “Profile” section

Postconditions:

The system displays the new profile modified by the admin/user on the screen and saves the new profile in the system’s memory Flow of Events for Main Success Scenario: 1. The user login to the app by his/her valid key and select menu item “Profile” 2. The system identifies the user by his/her key and shows their profile on the screen 3. The user manages his/her profile as he/she wants and chooses to save 4. The system displays the new profile and saves it in the system’s memory

Use Case 4: Use Case UC-4:

Name / Identifier

Related requirements:

REQ4, REQ5

Initiating Actor:

Any of admins, users

Actor’s Goal:

To search for needed information

Participating Actors:

Database

Preconditions:

+ User login successfully + The system displays the menu of available functions including “Search” section

Postconditions:

The system displays the searched information, the user can use the search bar again to find other information 7

Flow of Events for Main Success Scenario: The user login to the app by his/her valid key and select menu item “Search” The system identifies the user by his/her key and shows their profile on the screen Flow of Events for Extensions (Alternate Scenarios): 2a. Invalid searching information Users search bar to search again or leave If search again, back to step 2 above

Use Case 5: Use Case UC-5:

Modify plant information

Related requirements: REQ2 Initiating Actor:

Only Admin

Actor’s Goal:

Add/ change/ delete the plant data

Participating Actors:

Database

Preconditions:

-Admin account must be logged in. -3 main functions are displayed on the screen: add, change, delete

Postconditions: The modified data is saved to the database Flow of Events for Main Success Scenario: Admin picks 1 function: Add, Change, Delete +Add: Admin enters new data +Change: Admin searches a plant -> Admin changes the data +Delete: Admin searches a plant -> Admin deletes the data Add: System saves the added information Change: System saves the modified information Delete: System deletes the data out of database System shows the new data to users 8

Flow of Events for Extensions (Alternate Scenarios): Admin inputs wrong type of data, example: input String in the slot of Number System: “Error! You have entered wrong type of data” System allows Admin to re-input the data

Use Case 6: Use Case UC-6:

Modify employee information

Related requirements:

REQ3

Initiating Actor:

Admin, Employee

Actor’s Goal:

Add/ change/ delete the employee data

Participating Actors:

Database

Preconditions:

-Show full 3 options to Admin account: Add, Change, Delete -Show only 1 option to Employee accounts

Postconditions: The modified data is saved to the database Flow of Events for Main Success Scenario: Admin picks 1 function: Add, Change, Delete +Add: Admin enters new data +Change: Admin searches a plant -> Admin changes the data +Delete: Admin searches a plant -> Admin deletes the data Employee picks Change function: +Change: Employee searches his/her information-> Employee changes the data Add: System saves the added information Change: System saves the modified information Delete: System deletes the data out of database System shows the new data to users Flow of Events for Extensions (Alternate Scenarios): 9

Users input wrong type of data, example: input String in the slot of Number System: “Error! You have entered wrong type of data” System allows Admin to re-input the data

10

2.3. Activity diagram: 2.3.1.

Login:

2.3.2. Change password:

11

2.3.3. Search information:

12

2.3.4. Modify plant information:

2.3.5. Modify employee information:

13

14

2.4.

Class diagram:

15

REFERENCE

[1] https://www.guru99.com/non-functional-requirement-type-example.html#3 [2]

16...