table of contents - faculty.kutztown.edufaculty.kutztown.edu/tan/csc354/datafiles/sp2018/teamdb...

Tyler Lance - Adam Whittaker - Patrick Earl

Atajan Abdyyev - Freya Chen - Solomon Jatta

November 21, 2017VERSION 2.2

TASK MANAGEMENT SYSTEM

DATABASE TEAM

Fall 2017

High Level Design November 2, 2017

TABLE OF CONTENTS

TABLE OF CONTENTS.....................................................................................................................2

REVISION HISTORY.........................................................................................................................3

1.0 INTRODUCTION........................................................................................................................6

1.1 Purpose of Document..........................................................................................................6

1.2 What are System Sequence Diagrams.................................................................................6

1.3 What are Domain Model Class Diagrams.............................................................................6

1.4 Explanatory Material: Acronyms & References...................................................................7

2.0 SYSTEM ARCHITECTURE DESIGN..............................................................................................8

3.0 UML NOTATION.......................................................................................................................9

4.0 SYSTEM SEQUENCE DIAGRAMS.............................................................................................11

4.1 Search for Task in Library by Name....................................................................................11

4.2 Create Task........................................................................................................................ 12

4.3 Remove Survey Question...................................................................................................13

4.4 Assign Survey from Survey Management..........................................................................14

4.5 Create Survey.....................................................................................................................15

5.0 DOMAIN MODEL CLASS DIAGRAMS.......................................................................................16

5.1 Task Diagram......................................................................................................................17

5.2 Survey Diagram..................................................................................................................18

5.3 User Assignment Diagram..................................................................................................19

2


REVISION HISTORYBelow is the up to date revision history chart. As changes to this document are made, the chart will be edited to include it.

Version Date Description Editor

1.0 10/19/2017 Created template to be used as the High Level Design (HLD).

Tyler Lance

1.1 10/29/2017 Completely redesigned the template for the High Level Design.

Tyler Lance

1.2 10/30/2017 Modified Sections:

1.2 Task Management System

1.3 What are System Sequence Diagrams?

1.4 Explanatory Material: Acronyms & References

3.0 UML Notation

4.1 Search for Task in Library By Name

4.2 Create Task

4.3 Look Up Survey Results

4.4 Assign Survey from Survey Management

4.5 Create Survey

Tyler Lance


4.2 Create Task

4.3 Lookup Survey Results

5.2 Task Diagram

5.3 User Assignment Diagram

Patrick Earl

3


10/31/2017 Modified Sections:

5.1 Task Diagram

5.2 Survey Diagram


Tyler Lance

10/31/2017 1.1 Purpose of the Document

1.4 Domain Model

5.1Task Diagram

4.5 Create Survey

Atajan Abdyyev



4.2 Create Task



Adam Whittaker



4.2 Create Task



Tyler Lance


4.5 Create Survey

2.0 System Architecture

Adam Whittaker

1.5 11/2/2017 Deleted Section 6.0 Acronyms

Reviewed document for grammar and punctuation

Adam Whittaker

2.0 11/9/2017 Created HLD v2 document Tyler Lance

2.1 11/20/2017 Modified sections, reviewed grammar, and Solomon Jatta4


replaced some suggestions:1.1 Purpose of Document1.2 Task Management System1.3 What are System Sequence Diagrams1.4 What are Domain Model Class Diagrams1.5 Explanatory Material: Acronyms & References2.0 SYSTEM ARCHITECTURE DESIGN


4.5 Create Survey

2.0 System Architecture Design

1.3 System Diagrams

1.4 Domain Class Diagram

1.1 Purpose of the Document

Proofread for pronouns

Atajan Abdyyev

11/20/2017 Modified section and rewrote some suggestions3.0 UML NOTATION4.3 Lookup Survey Results

Solomon Jatta

Freya Chen

11/20/2017 Modified sections:

3.0 UML NOTATION

4.1 Search for Task in Library By Name4.2 Create Task4.3 Look Up Survey Results4.4 Assign Survey from Survey Management4.5 Create Survey

Adam Whittaker


5.0 Domain Model Class Diagrams

5.1 Task Diagram

5.2 Survey Diagram

Tyler Lance

5



2.2 11/20/2017 Final revisions and changes Tyler Lance

Adam Whittaker

Table 1: Revision History

6


1.0 INTRODUCTION1.1 Purpose of DocumentThe High-Level Design (HLD) explains a chosen System architecture design for the project. HLD uses Unified Modeling Language (UML) notation scenarios, System Sequence Diagrams (SSD), and Domain Class Diagrams (DCD) to describe how Task Management System (TMS) will be designed. The relevant documents to the HLD are the Software Requirement Specification (SRS) and the Software Project Plan (SPP). SRS relevance to HLD points out all requirements, SPP relevance to HLD points out why certain system architecture design is chosen. The intended audience for the HLD is the development team that will design and develop TMS.

HLD is used to describe the conceptual design of TMS and provides a way that supports reasoning about the structures and behaviors of the system framework for more detailed requirements and design activities in later phases of the project.

The architecture design is a contextual model that defines the structure, behavior, and views of the system that is to be built. The system is intended for the use of seniors who are age sixty or older to carry out various tasks assigned to them by their supervisors.

1.2 What are System Sequence DiagramsSystem Sequence Diagrams are diagrams used to show scenarios of use cases, the event that external actors generate, the order of the events, and possible inter system events. The SSDs are derived from the functional requirements outlined by the client. SSDs focus on the messages sent to the system by actors. The messages are displayed chronologically with responses from the system. The system itself is treated as a black box. This notation allows for SSDs to be used as a high-level understanding of how the user will interact with the system for each use case.

1.3 What are Domain Model Class DiagramsDomain Model Class Diagram is a conceptual model of the domain that incorporates both behavior and data, it helps developers identify relevant concepts and ideas of the domain. Conceptually it represents the real world with only necessary data and serves as the basis for the design of software. Each Domain Model Class Diagram has a class name, attribute(s) of that class, method(s) of that class, and relationships connecting classes. During current stage of design, methods are not to be used, only class name and attributes. Each attribute shows its data type as well.

7


1.4 Explanatory Material: Acronyms & ReferencesThe following abbreviations will be used throughout this document.

Acronym Full Name

DCD Domain Class Diagrams

DMCD Domain Model Class Diagrams

HLD High Level Design

SPP Software Project Plan

SQL Structured Query Language

SRS Software Requirement Specification

SSD System Sequence Diagrams

TMS Task Management System

UML Unified Modeling Language

SA System Manager

Table 2: Acronyms & References

8


2.0 SYSTEM ARCHITECTURE DESIGNFigure one shows the system architecture for the Task Management System. The database team will implement TMS’s database in phpmyadmin using MySQL to create the database. There will be a virtual server installed on a Kutztown University server. Kutztown University’s System Administrator (SA) will be setting up the server for the class. The SA chose a virtual server because of not being familiar with Python and Flask, and not wanting to install the resources on the server without fully testing it first. This will allow the database for the Task Management System to be placed on the server, so the website can be viewed on the web. Both the frontend and backend web pages will be accessed through the domain provided by SA.

This architecture is correct because the system must have a database to store all the information that will need to be stored and accessed within the system. The database must be hosted on a network, so a server or virtual server will be implemented for the use of the project. Once there is a server associated with the project a website domain must be set up.

Figure one is an example of a client-server application. The client uses a device to utilize the Task Management System while the server is hosted on the Kutztown University network. The client sends a request, and the server generates the response for the client.

9


Figure 1: TMS Architecture

10


3.0 UML NOTATIONTable three below should be used as a guide to understand the UML notation for the System Sequence Diagrams in Section 4.0. This table contains symbols and provides a description for each defining what the symbols purpose is.

Symbol Description

The symbol on the left is a representation of a stick figure. It has a head denoted by a circle, there are arms and legs denoted by lines. This symbol is going to represent a user. In the TMS system it will be the supervisor. The supervisor will interact with the system.

The symbol on the left is a square box with the word :system located in the box, which is underlined. This symbol will represent the entire TMS as a black box. A user will be interacting with the system, which is represented by the stick figure symbol.

This symbol on the left is the object lifeline symbol. The symbol is a vertical dashed line that extends from both the actor and system. It shows the sequence of messages in chronological order.

Message(parameter(s)) The symbol on the left is the message that is being sent to the system. The arrow is a solid black line with an arrow tip on the end. The message might take a parameter as input depending on the message. The message is represented as an input message which is requested by the actor from the system.

Response This symbol to the left is a representation of a

11


response message/action. The symbol is a dashed line with an arrow tip on the end. The symbol represents a returned value which has been requested from the system by a user.

The symbol on the left is an operational note to further explain a message or response. This will be denoted using a box like object with a rounded edge and a folded corner. The stick note will be the symbol that will appear in the SSDs to explain a message or response the user will see.

*[condition]returnValue

:=parameter

The symbol on the left is an alternative looping notation for while a given condition is true. Alternate notation for this is available where all messages and responses are encompassed inside a rectangle and a condition is given that must be satisfied.

This is the traditional notation for looping where the loop is indicated in a square box around the message and response of the system. The text “loop until . . . is needed in a box at the top left to indicate the loop. The box around the message and return messages indicates how long that loop is going to iterate and over what items.

Table 3: UML Notation

12


4.0 SYSTEM SEQUENCE DIAGRAMS4.1 Search for Task in Library by NameThe search function will be used to display the names of tasks listed in the task library. Figure two below demonstrates this function being used by Supervisor.

Figure 2: Search for Task by Name

13


4.2 Create TaskFigure 3 shows the system sequence diagram for creating a task can be done only by a Supervisor on the system. Tasks can be created from scratch or by claiming a pre-existing task and modifying it. Once created a task will be published and visible inside the library of tasks. Please refer to figure three for necessary modifications.

14


Figure 3: Task Creation

15


4.3 Remove Survey QuestionFigure 4 shows the process of removing a question from a survey. The supervisor will be able to search for the survey by name. Once the survey is displayed the Supervisor will have the option of removing a specified question.

Figure 4: Remove Question from Survey

16



Once a survey is created by a Supervisor it may be assigned to a task. This process can be done in two different ways. Search the library of tasks and select the task. Once a task is selected the system will redirect a supervisor to the task management page where the Supervisor can assign that task a survey. Otherwise, the Supervisor can access it through the Survey Management page. Once in the Survey Management page, the Supervisor may search for a survey by name and then search for a task by name or keyword. Once the survey and task have been found the Supervisor may sign them to each other. Figure five demonstrates the second way a Supervisor may assign a survey to a task.

Figure 5: Assign Survey from Survey Management

17


4.5 Create SurveySupervisors are given the ability to create a survey and assign that survey to a task. This process is important because once the survey is assigned, then the User can complete the survey and give valuable feedback to the Supervisor. Figure six demonstrates the process of creating a survey.

Figure 6: Survey Creation

18


5.0 DOMAIN MODEL CLASS DIAGRAMSThe domain model class diagram is a conceptual model representing an overview of the system by describing the classes and attributes inside the system along with the relationships between them. Table four below should be used as a reference for understanding the symbols used in the Domain Model Class Diagrams.

Symbol Description

The symbol on the left is the representation of a class. The class represents a relevant concept from the domain and provides attributes relevant to it.

The symbol on the left is the representation of an attribute. Attributes are listed inside the class and provides a characteristic that is of interest of that class. A characteristic of a User, for example, are username and password.

The symbol on the left is the representation of a relationship. A relationship displays a connection two classes have with each other.

00..*0..111..*

The symbols on the left represent the degrees of multiplicity for a relationship. Each class involved in a relationship has a specific degree of multiplicity. When the multiplicity is a single digit, either zero or one, then that class must have that degree of multiplicity. When the multiplicity has two digits separated by periods, then the left digit represents the lower bound and the right digit represents the upper bound.Table 4: Class Diagram Notation

19


5.1 Task DiagramFigure seven shows how Supervisor can find Tasks, by simply using SupervisorID, and can trace which Users have the Task. Also, Supervisor can trace CompletedSteps and MainSteps through Tasks TaskID. However, to find detailed steps a Supervisor will have to use MainSteps MainStepID for that. Each user must have a Task, but doesn’t have to have any CompletedSteps. Each Task may have no completed step, or no Users. MainSteps can be accessed by using TaskID parameter.

Figure 7: Task Diagram

20


5.2 Survey DiagramFigure eight shows the relationships between the different classes that pertain to surveys. Each survey has a list of questions that relates to it. Supervisors can assign SurveyForms to Tasks. The SurveyResults related to each Task, SurveyForm, and the user that filled out the survey.

Figure 8: Survey Diagram

21


5.3 User Assignment DiagramFigure nine shows the how Users are assigned their groups and tasks. Each User can request a task from the library. Users have the option of being related to a group so that supervisors can mass assign tasks to one of their groups. Tasks are assigned keywords so that Supervisors can easily search for specific tasks within the database.

Figure 9: User Assignment

22

table of contents - faculty.kutztown.edufaculty.kutztown.edu/tan/csc354/datafiles/sp2018/teamdb...

Documents