Design



System Architecture

Frontend

Our front end was designed using components from MaterializeCSS in order to recreate the front end of the current version of time machine but with improved aesthetics, and some minor changes to improve on the interface heuristics. Alongside this we used typescript compiled using webpack to handle all of the requests made to the backend and React JS to dynamically render javascript to the page when a request required as such.

Backend

Our backend was programmed using nodejs alongside several packages the main of which was express. The use of these enabled to create a backend with an API, due to the routing capabilities of express. This was done to make integration with other ATOS software without making them have to try and access the database directly themselves. The functionality provided by the API give other programs the same functions as what the front end uses to interact with the database.

Server

Our web server runs both the Apache server that our frontend is deployed on, and our backend nodejs server. We made sure that the server is easy to deploy with instructions being present on this site. Additionally we have made it so that commits that are pushed to production branch of our git repository automatically redeploy our front and backend due our our configuration of our servers as a service.

Design Patterns

Model-View-Controller

The model view controller pattern is an architecture design pattern that divides your application into a distinct three section structure in order to provide more clarity and improve maintenance, and we have also employed this strategy with our frontend, API, and database controller.

Callback

The use of callbacks is a design pattern which is commonly found in javascript written for networking purposes. Our application makes use of it in order to make all of our function asynchronous which mean that the server can run all functionalities in the background with slowing the down anything that making use of the API (including our frontend).

Observer

The observer pattern involves making use of events and listeners, which we use with our program so that the tables present on the front can be automatically updated when another user (or someone using the API) makes a change that would affect the respective tables.

E-R data modelling

This is a design pattern that affects the structure of our database. We followed this by having our database in 3rd normalised form in order to preserve our data’s integrity and remove redundancy and future proof it from errors.

Modular

This is a design pattern which involved dividing up your codebase and importing it when necessary. We used this with our control file to make it more convenient to set up unit tests as they wouldn’t be using the API routes only the core functionality, and we also used it for our config file so we wouldn’t have to upload it to our public repository.

Database

Experiments

Experiment 1 - Find the most appropriate DBMS

We narrowed down a list of DBMSs to the most common ones (SQL Server, Oracle SQL, SQLite and MySQL) and we performed some tests to decided which one do adopt for this project.

Experiment No. Experiment Title Experiment Details Experiment Results
1.1 Dealing with different platforms We have tried to install and perform small tasks (e.g. create a simple table) for every of the proposed DBMS in the following Operative Systems: Windows; UNIX-based systems. As SQL Server is only available on Windows platform, we decided to discard it.
1.2 Dealing with proprietary software To avoid intellectual property issues, we decided to research whether or not the proposed DBMS use a proprietary license As Oracle SQL use a proprietary license, we decided to discard it
1.3 Data types variety To facilitate further database improvements and extensions, we opted for a DBMS that allows as many data types as possible. Using each integrated environment, we had access to a list of all the available data types for each DBMS and we could therefore compare them As SQLite offers way less data types than MySQL does, we decided to discard it. We eventually chose to use MySQL as DBMS to use for this project

Experiment 2 - Find the most appropriate MySQL Engine

Once decided which DBMS to go for, we had to decide whether to adopt MyISAM or Innodb as table engine.

Experiment No. Experiment Title Experiment Details Experiment Results
2.1 Following ACID properties Given the potential frequency of use of the system, we decided that ACID transactions had to be used to maintain data integrity. We therefore researched which engine made use of ACID properties Consequently to our research, we found out that MyISAM does not offer ACID proprieties whilst Innodb does
2.2 Speed Given the potential size of the system, we decided that speed was also to prioritise. We therefore researched which engine performed faster operations Consequently to our research, we found out that MyISAM is slightly faster as it does not offer ACID proprieties
2.3 Finding a compromise After performing some speed tests on our database, we found out the difference of speed between the two systems is not sensibly big, even performing multiple complicated calculations at the same time We decided to value the ACID properties more than speed as data integrity is much more important for this particular project. Therefore we chose Innodb as engine to use for this project

Experiment 3 - Data Normalisation and Standardisation

We went through the process of Data Normalisation and Standardisation for our Database and changed it accordingly

Experiment No. Experiment Title Experiment Details Experiment Results
3.1 Data Normalisation and Standardisation Performed usual checks to see whether the created database respect the 1 st , 2 nd and 3 rd Normal Form and researched about the most used data standards Performed usual checks to see whether the created database respect the 1 st , 2 nd and 3 rd Normal Form and researched about the most used data standards

Experiment 4 - Dealing with fields’ data types

We needed to check the previous system and perform some tests on the new system’s fields to optimally satisfy the user requirements.

Experiment No. Experiment Title Experiment Details Experiment Results
4.1 Checking the data behaviour of the existing solution Checked the behaviour of inserting any type of data in any field of the existing solution Came up with a list of behaviours for each fields
4.2 Perform complicated overtime calculations We performed some calculations on huge salaries and compared the outcome results with the ones of the existing system Switched travelCost and callout fields from FLOAT to to CONCURRENCY type
4.3 Trying to put NULL values We checked the errors thrown in case we omit any value To not overcomplicate the system, we set every field’s boundary to NOT NULL
4.4 Fetch the example IDs into our Database As we were undecided whether to use INT or TEXT type for IDs, we performed some research on the standard and the requirements of the system We used TEXT for staffID as required from the client, but we used INT for the other keys for a performance and standardisation matter

Creation


Toolchain

  • Chrome
  • Safari
  • Edge
  • Firefox

We decided that we would try and keep our web application flexible and able to be used all of the most web browsers which are still being developed. This will allow our clients more flexibility in choosing the web browsers they want to use, especially if they change later on after development has been completed.

  • HTML5
  • CSS3
  • JavaScript
  • PHP
  • MYSQL
  • NodeJS

We choose programming languages that we were already comfortable with because our client’s gave us free reign on which language to use. The combination of these languages will easily allow us to program both our front-ends and back-ends with the addition of the fact that PHP was designed to be able to be integrated with HTML and Javascript.

  • Cloud Server- Azure
  • Script for automatic build for each version control push
  • Script for automatic restart on server reboot
  • Script for automatic database backups
  • Script for automating unit tests for each build
  • Script for moving staging build to production server

We decided to use Azure as a Cloud Server as one of our team members has had previous experiences using it. We also compared Azure service with the Amazon EC2, and we found the first one to be easier to use and more suitable for this project’s goals. We chose to write scripts for automise version control push, reboots, backups creation and unit test as it will save us time and it will best prevent human errors.

  • Sublime Text 3
  • Atom
  • WebStorm

Each of our group members will most likely be using different text editors according to what they are most useful which in terms of this project we felt would be most useful as using what you are comfortable with will make it easier to develop more efficiently. Due to the nature of using HTML, Javascript and PHP, the fact that we are using different text editors will not make any difference and will just provide more convenience for us.

  • Balsamiq Mockups

In order to create our wireframes to be a high fidelity representation of our user interface designs we decided to use Balsamiq. This enables to quickly create high quality wireframes where we can easily demonstrate how we are consider design principles and gearing our interface to stand up to Nielsen Heuristics. This also means that our clients will be able to have a better idea of the direction we’re taking.

  • Git (Github)

For our version control we decided to use github since all of our team members have had previous experience with it before, and our clients did not mind where we host our repository. Github is a version control system which works with git allowing all of the contributors to push to the same repository allowing this project to be more of a collaborative effort. We also chose to use Github over other version control system because of the broad community and wide amount of support meaning anyone else who might want to on this project at a later date will easily be able to do so.