System and Software Architecture Description (SSAD)

(1)

System and Software Architecture Description (SSAD)

Agricultural Drone Team 2

Luis Cuellar

Requirements Engineer, Life-Cycle Plan Jeremy Donde

Operational Concept Engineer, Feasibility Analyst Marjorie Lucas

Operation Concept Engineer, Software Architect, Feasibility Analyst Steven Prockup

Project Manager, Requirements Engineer, Life-Cycle Planner Chenyu Wang

Software Architect, Prototyper, IV&V Sheng Zhang

Prototyper, IV&V George Zhong

Requirements Engineer, Prototyper, IV&V, Quality Focal Point

Oct. 23 2020

(2)

Version History

Date Author Version Changes made Rationale 10/20/2020 CW, ML 1.0 Initial release

10/21/2020 CW, ML 1.1 • Cleaned up use case diagrams

Updated to include comments from presentation.

(3)

System and Software Architecture Description (SSAD) – Team 2 – Agricultural Drone Version 1.1

Table of Tables

Table 1: Actor summary ... 2

Table 2: Artifacts and Information Summary ... 2

Table 3: Application zone check process summary ... 5

Table 4: Application zone check typical course of action ... 6

Table 5: Application zone check alternate course of action ... 6

Table 6: Application zone submission process summary ... 6

Table 7: Application zone submission typical course of action ... 7

Table 8: Application zone submission alternate course of action ... 7

Table 9: Application zone submission exceptional course of action ... 7

Table 10: View Project Status process summary ... 8

Table 11: View Project Status typical course of action ... 8

Table 12: View Project Status alternate course of action ... 8

Table 13: View Project Status exceptional course of action ... 8

Table 14: User Log-In process summary ... 9

Table 15: User Log-In typical course of action ... 9

Table 16: View Project Status alternate course of action ... 10

Table 17: View Project Status exceptional course of action ... 10

Table 18: User Log-Out process summary ... 10

Table 19: User Log-Out typical course of action ... 11

Table 20: Permissions assignment process summary ... 11

Table 21: Permissions assignment typical course of action ... 11

Table 22: Permissions assignment alternate course of action ... 11

Table 23: Permissions assignment exceptional course of action ... 12

Table 24: Upload flight artifacts process summary ... 12

Table 25: Upload flight artifacts typical course of action ... 12

Table 26: Upload flight artifacts exceptional course of action ... 12

Table 27: Set Trigger Parameters process summary ... 13

Table 28: Set Trigger Parameters typical course of action ... 13

Table 30: Set Trigger Parameters exceptional course of action ... 13

(5)

Table of Figures

Figure 1: UAV-IQ system context diagram ... 1

Figure 2: Proposed solution artifacts ... 3

Figure 3: Use case diagram for application zone submission and validation ... 4

Figure 4: Project information retrieval ... 5

Figure 5: Permissions management ... 9

(6)

1. Introduction

1.1 Purpose of the SSAD

The purpose of this document is to provide an overview of the architecture of the proposed solution. The use cases and user roles are identified and will be assessed against the architecture to ensure they may be exercised. The interactions the users have with the system for each activity and what artifacts are used in those interactions is also discussed.

1.2 Status of the SSAD

This version of the SSAD reflects the current knowledge of the proposed system’s software architecture. Differences between this version and the initial release include modifications made to the use case diagrams to improve readability and modifications made to the language used to describe the stakeholders to maintain consistency across project documents.

(7)

2. System Analysis

2.1 System Analysis Overview

The purpose of the proposed solution is to provide an integrated workflow that offers an easy way for users to manage projects, communicate between each other, and view or upload mission artifacts. The solution will have multiple views - each tailored to users who interact with the solution in a different manner - to ensure users are able to perform their mission roles effectively.

2.1.1 System Context

Figure 1 shows the system context diagram for the proposed solution. The Employee actor is the class from which the Project Manager and Drone Pilot actors are derived.

Figure 1: UAV-IQ system context diagram

(8)

Table 1 describes the actors who interact with the proposed solution and lists their responsibilities.

Table 1: Actor summary

Actor Description Responsibilities

UAV-IQ Customer

Growers/farmers that require pest control treatment on their properties.

1. Give contact information.

2. Submit precise boundaries of their properties.

3. Receive crop treatment.

Project/Mission Manager

Coordinate with customers, suppliers, and drone pilots to ensure the process of

treatment.

1. Contact with customers.

2. Confirm plans with entomologists.

3. Communicate with suppliers

4. Check weather and restriction issues.

5. Verify and assign tasks to pilots.

Drone Pilot Conduct drone flights for pest control on customers’

property.

1. Licensed to conduct drone flight in the target area.

2. Submit documents to application.

3. Check issues before flight 4. Perform drone flight Supplier Supplies product for crop

treatment

1. Report availability

2. Supply treatment materials

2.1.2 Artifacts & Information

Table 2 describes the artifacts the proposed solution will create and how they are used within the solution. All of these artifacts are high-level datasets that will be exposed to the system users, though not all artifacts will be accessible to all users. Actors will have access to the artifacts that are directly related to their roles or responsibilities only.

Table 2: Artifacts and Information Summary

Artifact Purpose

Application zone geoJSON polygon describing the area over which the treatment will be applied.

Post-flight report Report that contains any notes the drone pilot would like to include regarding the execution of the flight.

Safety report Report that describes any safety hazards such as high winds or structures that may interfere with future flights in the area.

Work order Form the UAV-IQ customer submits when requesting UAV- IQ’s services. Data will be fed into the project dataset.

Project

Blob that contains relevant project information such as customer information, treatment plan, flight plan, etc. Will be used to convey project information to system users.

(9)

Figure 2 shows the relationships the artifacts have to the other artifacts in the proposed solution.

There is a one-to-one mapping between the project and the work order since the project is

created to satisfy the work order request. One project may have multiple application zones which may be used to perform the crop treatment over different sections of the property boundaries.

Each project will have one post-flight report and one safety report submitted by the Drone Pilot once the flight is complete.

Figure 2: Proposed solution artifacts

2.1.3 Behavior

This section describes the behavior of the proposed solution with respect to the actors acting on the system. For each use case shown in Figure and Figure there is a corresponding detailed description of the process which includes the actor’s actions and the system’s expected response to those actions. The typical, alternative, and exceptional courses of action are explored for each use case defined.

Figure 3 shows the process by which the application zone is submitted to the proposed solution and how the data are used by the project manager. The two actors involved are the UAV-IQ customer, who submits the application zone, and the project manager, who checks the

application zone to confirm it meets requirements. All process elements are defined within the proposed solution.

(10)

Figure 3: Use case diagram for application zone submission and validation

Figure 4 describes the use cases for flight artifact uploads, notifications, and project tracking.

The actors involved with these use cases are the project manager, drone pilot and the generic user, who represents all users of the system. These uses cases were combined for convenience as they all relate to actions that update project information.

(11)

Figure 4: Project information retrieval

2.1.3.1 Application Zone

This section details the processes that relate to the application zone submission and verification.

Refer to the use case diagram shown in Figure 3.

2.1.3.1.1 Application Zone Check

Table 3: Application zone check process summary

Identifier UC-1

Purpose Project manager confirms application zone meets requirements.

Requirements OC-1, OC-2, OC-4

Development Risks None. Behavior is well-defined.

Pre-conditions • Project with application zone exists

Post-conditions • Application zone for given project is verified

(12)

Table 4: Application zone check typical course of action

Seq# Actor’s Action System’s Response

1 Views project application zone Displays points of interest near application zone as pulled from the relevant API’s i.e. airports, prisons, etc.

2 Determines flight over application zone is possible

Updates project entry in database with decision

Table 5: Application zone check alternate course of action

1 Views project application zone Displays points of interest near application zone i.e. airports, prisons, etc.

2 Determines flight over application zone is NOT possible

Updates project entry in database with decision

3 Project is archived

There is no exceptional course of action defined for the Application Zone Check process since there are only two paths that can be taken, both of which are covered in the typical and

alternative courses of action.

2.1.3.1.2 Application Zone Submission

Table 6: Application zone submission process summary

Identifier UC-2

Purpose UAV-IQ customer submits application zone for crop treatment Requirements OC-1, OC-2

Development Risks Handling multiple application zones over a single property not yet well-explored.

Pre-conditions • UAV-IQ customer has started a work order from the UAV- IQ website

Post-conditions • Project is created

• Application zone geoJSON is ingested

(13)

Table 7: Application zone submission typical course of action

1 Defines valid application zone using mapping tool

2 Submits work order Validates application zone

3 Prompts user for submission

confirmation

4 Confirms submission Creates database entry for new project

5 Writes application zone to project

database entry

Table 8: Application zone submission alternate course of action

1 Selects existing application zone

2 Submits work order Prompts user for submission confirmation

3 Confirms submission Creates database entry for new project

4 Writes application zone to project

database entry

Table 9: Application zone submission exceptional course of action

1 Defines invalid application zone using mapping tool

2 Submits work order Validates application zone

3 Prompts user to enter valid application

zone

2.1.3.2 Project Tracking

This section details the processes that relate to project tracking. Refer to the use case diagram shown in Figure 4.

(14)

2.1.3.2.1 View Project Status

Table 10: View Project Status process summary

Identifier UC-3

Purpose Project manager views project status Requirements OC-3

Development Risks None. Prototypes exploring capability have already been developed.

Pre-conditions • Project exists

Post-conditions • No state change expected

Table 11: View Project Status typical course of action

1 Project manager accesses proposed solution dashboard 2 Project manager types in valid

string identifier in search bar

Queries database to display project status for project with matching string identifier

Table 12: View Project Status alternate course of action

1 Project manager accesses proposed solution dashboard 2 Project manager clicks “View

Status All”

Queries database to provide summary of status for all projects

Table 13: View Project Status exceptional course of action

1 Project manager accesses proposed solution dashboard 2 Project manager types in invalid

string identifier in search bar

Alerts project manager no project exists

2.1.3.3 User Permissions Management

This section details the processes that relate to permissions management. Refer to the use case

(15)

settings for specific users. These use cases were combined in the same diagram as they both pertain to the overall permissions management system.

Figure 5: Permissions management

2.1.3.3.1 User Log-In

Table 14: User Log-In process summary

Identifier UC-4

Purpose User logs into proposed solution Requirements OC-7

Development Risks Security protocols and standards have not yet been defined.

Pre-conditions • User has accessed UAV-IQ landing page Post-conditions • User is logged in

Table 15: User Log-In typical course of action

(16)

2 User enters credentials into modal

Checks user database to confirm user exists and credentials are valid

3 Redirects user to dashboard if

successfully authenticated

Table 16: View Project Status alternate course of action

1 User clicks “Log-In” icon Modal prompting user for login info is displayed

3 Determines user does not exist and

redirects user to “Account Creation”

page

Table 17: View Project Status exceptional course of action

1 User clicks “Log-In” icon Modal prompting user for login info is displayed

3 Determines user exists but credentials

are invalid

4 Alerts user of invalid credentials and

prompts user to re-enter credentials 2.1.3.3.2 User Log-Out

Table 18: User Log-Out process summary

Identifier UC-5

Purpose User logs out of proposed solution Requirements OC-7

Development Risks None

Pre-conditions • User is logged in Post-conditions • User is logged out

(17)

Table 19: User Log-Out typical course of action

1 User clicks “Log-Out” icon Unauthenticates user

2 Redirects user to landing page

There is no alternative or exceptional course of action for this process since the user provides only one action.

2.1.3.3.3 Permissions Assignment

Table 20: Permissions assignment process summary

Identifier UC-6

Purpose Project manager defines user permissions type Requirements OC-7

Development Risks User types are defined; however, the information these user types have access to is not well-defined.

Pre-conditions • Project manager is logged in

• Project manager is in permissions settings Post-conditions • User has been assigned permissions

Table 21: Permissions assignment typical course of action

1 Project manager selects user by typing string identifier

Returns user profile 2 Selects user type from

predefined list Updates user database to include assigned user type to selected user

Table 22: Permissions assignment alternate course of action

1 Project manager clicks “Create

User” Prompts project manager to enter user

details 2 Project manager assigns user

type and enters user information

3 Project manager clicks “Submit” New user entry added to user database with user type information

(18)

Table 23: Permissions assignment exceptional course of action

1 Project manager enters invalid string identifier

Alerts project manager no user for provided string identifier exists 2 Project manager acknowledges

alert by clicking “OK”

2.1.3.4 Flight Operations

This section details the processes that relate to flight operations. Refer to the use case diagram shown in Figure 3.

2.1.3.4.1 Upload Flight Artifacts

Table 24: Upload flight artifacts process summary

Identifier UC-7

Purpose Drone pilot uploads flight artifacts for a given project Requirements OC-6

Development Risks Formats for artifacts is not well-defined Pre-conditions • Drone pilot is logged in

• Drone pilot has completed flight

• Drone pilot has navigated to assigned project Post-conditions • Flight artifacts are published to project

Table 25: Upload flight artifacts typical course of action

1 Drone pilot clicks “Upload”

2 Drone pilot selects valid flight artifact to upload

Validates flight artifact

3 Adds flight artifact to project entry

4 Alerts drone pilot of successful upload

Table 26: Upload flight artifacts exceptional course of action

1 Drone pilot clicks “Upload”

2 Drone pilot selects invalid flight artifact to upload

Validates flight artifact

3 Alerts drone pilot flight artifact failed

(19)

4 Drone pilot acknowledges alert by clicking “OK”

Redirects drone pilot to project view

2.1.3.5 Notification Service

This section details the processes that relate to flight operations. Refer to the use case diagram shown in Figure 3.

2.1.3.5.1 Set Trigger Parameters

Table 27: Set Trigger Parameters process summary

Identifier UC-8

Purpose Project manager sets notification trigger parameters Requirements OC-5

Development Risks None

Pre-conditions • Project manager is logged in

• Project manager is in notification settings Post-conditions • Project manager has set notification triggers

Table 28: Set Trigger Parameters typical course of action

1 Project manager selects trigger type from form

2 Project manager sets valid parameter for trigger type

Validates parameter

3 Updates backend trigger parameter

4 Project manager specifies what user types will receive triggered notification

Updates backend distribution list

Table 29: Set Trigger Parameters exceptional course of action

1 Project manager selects trigger type from form

2 Project manager sets invalid parameter for trigger type

Validates parameter

3 Alerts project manager parameter is

invalid

4 Project manager acknowledges Redirects projects manager to

(20)

2.1.3 Modes of Operation

There is only one mode of operation for the proposed solution so analysis of alternate modes is not applicable.

2.2 System Analysis Rationale

The majority of the use cases described in this document should be fairly intuitive to the reader.

They were deliberately designed to be concise to ensure the delivered solution is as intuitive and user-friendly as can be.

System and Software Architecture Description (SSAD)