Design report

T-404-LOKA, Lokaverkefni

Spring 2017

Team members: Instructor:

Alexandra Líf Ívarsdóttir Haukur Steinn Logason

Eiríkur Birkir Ragnarsson

Ragnar Ingi Ragnarsson

Made for: Moderator:

Redesign ehf. Hannes Pétursson

Kt. 541216-0730

Contact at company:

Eiríkur Birkir Ragnarsson,

+46-76189-1997

eirikurbr@redesign.is

2

Table of Contents

Introduction .................................................................................................................... 3

Context diagram .............................................................................................................. 4

Container diagram ........................................................................................................... 5

Navigation diagram ......................................................................................................... 6 Web client ............................................................................................................................... 6 Application client ..................................................................................................................... 7

Rest URI .......................................................................................................................... 8 Status Codes ............................................................................................................................ 8 Account Service ....................................................................................................................... 9 Activity Service ........................................................................................................................ 9 Schedule Service ...................................................................................................................... 9 User Service ............................................................................................................................. 9

Database Schema ...........................................................................................................10

Wireframes ....................................................................................................................11 Web client ............................................................................................................................. 11 App client .............................................................................................................................. 12

User interface – intermediate design ..............................................................................13 Web client ............................................................................................................................. 13 App client .............................................................................................................................. 16

User interface – final design ............................................................................................17 Web client ............................................................................................................................. 17 App client .............................................................................................................................. 20

Coding rules ...................................................................................................................21

3

Introduction This design report is a high-level guide through myDay's systems architecture.

myDay is a visual scheduling system for children with special needs. The system can be best

described as a suite that connects the home and school and simplifies the organizing for

those children who depend on it. With myDay there is no more need for printing out and

laminating pictures for schedules and organizing like most schools do today. It makes it

easier for parents and guardian to keep track of their child’s daily schedule and decreases

distress and anxiety due to uncertainty in the daily schedule, which is common with e.g.

children on the autism spectrum.

The report will contain a few diagrams to show the structure of the system, such as a

context diagram, container diagram, component diagram and a navigation diagram.In

addition to this there is a chapter containing the structure of the systems database, some

wireframes showing the visual design of the system and finally, the coding rules the team

has agreed on. All of these things will be similar to the original design report but some

changes have been made and those changes will be set forth in this report.

4

Context diagram The Context diagram is the highest-level diagram and the connects all users and external

components to the system. There are three types of users: parent, teacher and children

users. The users can perform different actions as seen on the diagram below.

5

Container diagram The container diagram shows the containers within the myDay system. This diagram dives a

little deeper than context diagram. Shows how the containers interact with one another

after receiving HTTP request from client or when the content uploader has new data for the

system. Only one thing has changed here from the original idea. The plan was to use Swift

for creating the app and have it so it supports only iOS. Now the application supports

android and iOS and will be created with Ionic2. One other thing that was changed from the

original plan was that it was decided to use Ionic push notifications for our message queue

instead of RabbitMQ. However, the message queue has not been implemented at this point

since we are waiting for a DUNS number, but it will be a part of future releases.

API: Node.js + Express MySQL: Data is stored in a SQL (relational) database App: Ionic2 application, supports android and iOS Angular2 – HTML: Web application

6

Navigation diagram The navigation diagram illustrates how the user can navigate through each webpage of the

system or screen of the application. myDay is two systems, a web application for the

parents and teacher and an iOS application for the child.

Web client The web client is mostly the same for both the teacher and parent view. The log in and sign

up screen are in the same modal divided with tabs, and is represented in a red rectangle on

the diagram below. The pages which are the same for both parent and teacher are

represented with green rectangles, the blue rectangle is the page only available to parents

and the purple rectangle is the page only available to teachers. The purple rectangles form a

diagram for the app, where there are only three options: log out, view home and school

schedule.

7

Application client The application client is much simpler than the web client, with only three pages that the

child uses and no log in page since the child should always be logged into the app on his

tablet.

8

Rest URI This is a documentation for the REST URI. This will inform you of all the routes you can call

and the content response and what parameters are required/optional.All data received

shall be in json format and all data sent out will be in json format.The prefix for all routes

is: “/myday/v0”.

Status Codes All status codes are standard HTTP status codes.

The below ones are used in this API.

2XX - Success of some kind

4XX - Error on the client’s behalf

5XX - Error in the server

Status Code Description

200 OK (request successful)

201 Created (new resource created)

204 No Content (typically on PUT and DELETE)

400 Bad request (invalid data parameters)

401 Authentication failure (authorization token not recognized, login fail)

404 Resource not found

409 Conflict (username or email invalid)

500 Internal Server Error

The full API documentation can be accessed at

http://docs.redesign.is/documentation/api/docs/index.html. (make sure to choose the

latest version from the dropdown menu in the top right corner).

9

Account Service Here below is the link to the routes created for the account service. Not all the routes are in use though. Routes not being used are: Create a new account. http://docs.redesign.is/documentation/api/docs/index.html#api-Accounts

Activity Service Here below is the link to the routes created for the activity service. Not all the routes are in use though. Routes not being used are: Get all activities, Create Activity, Create a new school schedule and Create a new home schedule. http://docs.redesign.is/documentation/api/docs/index.html#api-Activities

Schedule Service Here below is the link to the routes created for the schedule service. http://docs.redesign.is/documentation/api/docs/index.html#api-Schedules

User Service Here below is the link to the routes created for the user service. http://docs.redesign.is/documentation/api/docs/index.html#api-Users

10

Database Schema The database used is MySQL Database. Here below is the database schema for our database

where all relations, tables and their primary and foreign keys can be seen. There were a few

things that changed from the original idea. Instead of having one user table the database

has now one User table which stores the users email and userID for logging in purposes and

then references the UserInfo table which stores the users details. For the SchoolSchedule

and HomeSchedule table the field “created” was added. The table ScheduleTemplate was

added which is not in use. Here below is the updated database schema.

11

Wireframes This section of the report contains a few wireframes/prototypes to show how the original idea of the layout of the web client and app client would look.

Web client

Figure 1: The main page of the web client

Figure 2: Create an activity page.

12

App client Here below is a prototype of the child application. Since the idea for this project was developed in the class User centred software development the team had some prototypes ready for the child view from the beginning. As can be seen on the image below thre are buttons for choosing to play games, watch videos and point. These functions are not a part of the final project but might be added in later releases.

Figure 3: Main page of app client

13

User interface – intermediate design Here below some pages from the web and app client will be displayed. Not all the pages will be displayed since this is only here to give the reader an idea of the progress that was made on the user interface design.

Web client Here below are some of the pages from the web client in its intermediate design phase.

Figure 4: Log in/ Sign up page

14

Figure 5: Child list page

Figure 6: Create activity page

15

Figure 7: Create schedule page

Figure 8: View child’s details page

16

App client Here below are two of the pages from the app client in its intermediate design phase.

Figure 9: Log in page

Figure 10: Main page of the app/view schedule

17

User interface – final design Here below some pages from the web and app client will be displayed. Not all the pages will be displayed since this is only here to give the reader an idea of the progress that was made on the user interface design.

Web client Here below are some of the pages from the web client in its final design phase.

Figure 11: Log in/ Sign up page

Figure 12: Child list page

18

Figure 13: Create activity page

Figure 14: Create schedule page

19

Figure 15: View child’s details page

20

App client Here below are some of the pages from the app client in its final design phase.

Figure 16: Log in page

Figure 17: Main page of the app/view schedule

21

Coding rules Here below are coding rules the team has decided to follow when we all start coding. These

rules are made to ensure that the code we write will be as readable as possible and easy for

the team members to read each other’s code. The rules are all the same as before.

1. Curly braces

• Opening braces shall be in the same line as the function declaration with one space

separation. The closing braces shall be in the line below the last line of the

function.

• This rule also applies when writing if/else statements and loops.

Example:

2. Naming

• When naming classes pascal casing will be used.

• Example: PascalCasing

• When naming variables and functions camel casing will be used.

• Example: camelCasing

• The name of all classes, variables and functions shall be descriptive.

• Const variables shall always be written in caps lock.

• Example: const VARIABLE

• All names shall be written in English.

22

3. Indentation and spacing

• Indentation will be equivalent to four spaces.

• Between variables and mathematical symbols e.g the equal sign, will always be one space.

Example:

• When writing if/else statements or any kind of loops there will always be one

spacing between the type of statement and the following parentheses.

Example:

• Between functions there shall always be two spacings.

• Inside of a function between variables or between operations there shall only be

most one spacing.

Example:

4. Documentation

• All code shall be well commented with descriptive comments.

5. Github

• Only working code will be pushed onto the Github server. If a part of the code

doesn’t work it must be commented out to be able to push it.