CTEC3110

M2M ConnectSMS → PHP Processing

26th December 2014

Michael BullP12190492

Preet MehtaP1222870x

Pratik PawarP11242166

Module Leader: Clinton Ingrams, cfi@dmu.ac.uk

Project Supervisor: Peter Bounds, plmb@dmu.ac.uk

Contents1 Introduction 1

2 Contract 3

3 Specification 5

4 System Architecture 94.1 Model-view-controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.1.2 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.1.3 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2.1 Use Case: Display Board Statuses . . . . . . . . . . . . . . . . . . 144.2.2 Use Case: Fetch New Statuses . . . . . . . . . . . . . . . . . . . . 14

4.3 UML Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Implementation 175.1 Model-view-controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6 Test Plan 236.1 Testing SMS Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.2 Testing Main Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7 Version Control 27

8 Extension Functionality 318.1 Retina Ready . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318.2 Template Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.3 Template Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338.4 Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338.5 User Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348.6 Data Visualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

9 Conclusion 37

References 39

Glossary 40

Acronyms 41

i

ii

1 Introduction

For this project there has been a software requirement of a web based application thatwill report and manage the status of multiple telematics circuit boards. The applicationwill allow users to retrieve and display updates for a collection of circuit boards, collectingvarious information related to the boards such as their current temperature or fan status.

The information regarding the boards will be displayed on a public facing webpage,allowing any user to view statuses of the circuit boards in real time. For the application toremain public facing it must be developed with security threats in mind, thus being awareof common security vulnerabilities and exploits. The webpage itself must be natural forthe users to engage with and display information in a clear and meaningful fashion.

With the product’s intended use being to monitor a large assortment of circuit boards,it is important that the application performs efficiently and can display a large amountof data to the user without confusing them. For this reason the system architecture andinterface design will be key aspects of this project and require planning and preparationthroughout.

Figure 1: A typical telematics circuit board

1

2

2 Contract

Team Member RolesA Team leader, testerB Web application developer, software architectC Documenter/author, business analyst/designer

Member A Pratik Pawar Signature Date

Member B Michael Bull Signature Date

Member C Preet Mehta Signature Date

3

4

3 Specification

Before design and development of this project can begin, it is important that the require-ments of the project are fully specified for the developer. This ensures that the developerunderstands all the objectives that the project aims to fulfill and will leave little room forinterpretation.

The circuit boards within the telematics labratory are equipped to communicate datausing the short message service (SMS). This service is commonly used within mobiletelephones and web communication systems, allowing the transfer of plaintext messagescomposed of up to 160 characters. With this limit in mind it is important that the entirestatus of a circuit board can be transmitted in a single SMS message.

The SMS status updates from a circuit board will be sent to the Orange SMS Server.This third party ensures that product will not need to be listening for messages itself,but instead may connect to the Orange machine to machine (M2M) web-service. Thisweb-service, provided by Orange, allows stored messages to be downloaded and read byconnecting to the Orange simple object access protocol (SOAP) server.

With these services in mind, the product must utilize a SOAP client that connects to theOrange SOAP server to retrieve new SMS messages from the circuit boards. The SMSmessages are stored on the Orange SOAP server in the extensible markup language (XML)format – thus an XML parser is required to interpret the data contained within eachmessage. An example of the XML message format is displayed in Listing 1 (EE 2013).

1 <messagerx>2 <sourcemsisdn>447966538230</sourcemsisdn>3 <destinationmsisdn>447817814211</destinationmsisdn>4 <receivedtime>23/03/2004 09:35:31</receivedtime>5 <bearer>SMS</bearer>6 <messageref>0</messageref>7 <message>Reply received</message>8 </messagerx>

Listing 1: An example XML message header

5

With the format of the messages provided by the Orange SOAP server outlined, a customformat must be designed for the remaining data; the status of the circuit board.

The required data for the circuit board status to communicate includes:

• The status of each of the four switches, either ON or OFF

• The status of the remote fan, either moving FORWARD or in REVERSE

• The current temperature of the unit, in degrees Celsius (◦C)

• The last number entered on the device’s keypad

Following in the footsteps of the Orange SOAP server format, XML will be used for theformat of the circuit board data. This will allow the product to reuse the system designedfor the parsing of messages from the Orange SOAP server, thus removing the need todevelop another message parser.

Each status messages will format the data using the following key→value pairs:

Name Description

id The message identifier. Used to distinguish messages using our protocolfrom other messages on the server.

s1 The status of switch number one, either 0 (OFF) or 1 (ON).s2 The status of switch number two, either 0 (OFF) or 1 (ON).s3 The status of switch number three, either 0 (OFF) or 1 (ON).s4 The status of switch number four, either 0 (OFF) or 1 (ON).f The status of the remote fan. Either 0 (FORWARD) or 1 (REVERSE).t The current temperature of the unit in degrees Celsius (◦C).k The last entered digit on the keypad.

1 <id>abc123</id>2 <s1>0</s1>3 <s2>1</s2>4 <s3>0</s3>5 <s4>1</s4>6 <f>0</f>7 <t>38</t>8 <k>5</k>

Listing 2: An example XML message of a circuit board’s status

6

With the data downloaded and parsed it must now be stored so that it may be accessedagain in future. For this reason a relational database must be constructed to allow thestoring of circuit board information and statuses, so that users may view this informationvia the web application at any time. There will be two tables within the database thatrelate to each other, one containing information regarding the boards (such as their nameand unique identifier), and the other containing the most recently stored status of theboard (temperature, fan state etc).

The ‘board information’ table will contain the following data:

• The unique identifier for the circuit board

• The name of the circuit board (this may be the name of the current desk it is settingon or the desktop it is plugged into)

The ‘board status’ table will contain the following data:

• The date and time of this status update

• The status of each of the four switches, either ON or OFF

• The status of the remote fan, either moving FORWARD or in REVERSE

• The current temperature in degrees Celsius (◦C)

• The last entered number on the device’s keypad

With the data parsed and stored it is now ready to be displayed to the user. As previouslymentioned, the data will be displayed through the use of a public facing webpage. Theproduct must use the hypertext preprocessor (PHP) programming language to dynamicallycreate the webpage. The constructed webpage will then be served using the hypertexttransfer protocol (HTTP) via an Apache web server.

The webpage itself will be formulated using the extensible hypertext markup language(XHTML), a recommended industry standard endorsed by the world wide web consortium(W3C) since 2000 (Pemberton et al. 2000). The version of XHTML used will be 1.0 Strict.With the content produced in XHTML, it will then be styled and presented with the useof a cascading style sheet (CSS).

7

8

4 System Architecture

The system architecture is an important part of the design phase of a project as it definesthe structure, behaviour, and presentation of the product. This is achieved by outliningthe architecture, components, interfaces, and data that the system must provide.

This phase will outline to the developer the key design choices that have been made andexplain the steps necessary for an acceptable implementation. As such, the developerwill have a clear set of guidelines to follow regarding the approach of the product’sdevelopment.

4.1 Model-view-controller

With the product’s main feature being the displayment of circuit board data to a user, itis important that the user interface (UI) is designed efficiently and clearly. With theserequirements in mind, the model-view-controller (MVC) pattern has been chosen to aidwith UI development. The MVC pattern is a widely adopted architectural pattern usedto develop UIs, commonly implemented within web applications.

The MVC pattern aids the development of the product by splitting up the system intothree core components, these include:

• ModelThe model is a representation of the data stored within the system. This data maybe the status of a circuit board or a newly received message.

• ViewThe view is the visual representation of the model. It displays to the user the datain the model and is responsible for constructing the UI.

• ControllerThe controller exists to deal with interactions invoked by the user. This meansit is the controller’s responsibility to deal with actions when a user interacts withthe view. For example, the user may click a button on the view to check for newcircuit board statuses, the controller’s job is to then perform the logic requiredto check for new status updates so that it may update the model with any newinformation.

9

4.1.1 Model

As previously outlined, the model represents the data held within the system that may bedisplayed to the user via the view. In this project, the model will include the databasetables containing the board information and current status, as well as any newly updatedstatuses.

With the requirement of a database to store information within the model, a relationaldatabase management system (RDBMS) must be implemented. This will allow thedeveloper to safely interact with an optimized database, thus removing the need todevelop proprietary database software. MySQL is the world’s most popular open sourceRDBMS (solid IT 2014) allowing developers to create and restrict user accounts, managelarge databases with relational rules, and create safe and optimized queries. For thesereasons MySQL will be used to implement the relational database for the product.

The board_info table in MySQL will be implemented with the following data fields:

Name Type Keymsisdn varchar(15) Primaryname varchar(10)

The board_status table in MySQL will be implemented with the following data fields:

Name Type Keymsisdn varchar(15) Primary & Foreigndate timestampswitchOne enum(‘OFF’, ‘ON’)switchTwo enum(‘OFF’, ‘ON’)switchThree enum(‘OFF’, ‘ON’)switchFour enum(‘OFF’, ‘ON’)fan enum(‘FORWARD’, ‘REVERSE’)temperature int(3)keypad int(1)

The two tables will relate to each other in a one-to-one manner, identified by the msisdnfield within each table. This ensures there will only be one status currently stored foreach board, and allow the two to relate to each other such that the status can be gainedfrom the board’s information and vice versa.

10

4.1.2 View

The view is a visual representation of the model, and as such should display the informationand status of each circuit board. Following in the defined standards of XHTML; thestyling of the webpage and the content of the webpage will be seperated through the useof cascading style sheets. This allows the content to be generated in PHP and styled witha single CSS file.

The UI itself should be split into sections, allowing different pages to perform differenttasks. Looking at the specification, we can identify two core tasks: viewing the circuitboard information and checking for updates. Both of these functions will have theirindividual pages to perform and display the result of each task, and a landing page willbe the entry point to both tasks. This totals to three seperate pages that the user willinteract with.

Below are some conceptual UI designs for each of the three webpages.

Figure 2: The home page

11

Figure 3: The statuses page

Figure 4: The updates page

12

4.1.3 Controller

The controller acts as the middle-man between the user and the model. Allowing the userto directly manipulate the model would create security risks and leave the user confusedas how to correctly change the model, for this reason the controller manipulates the modelfor the user in a secure fashion.

The controller will allow the user to perform tasks by constructing an application pro-gramming interface (API) that provides the view with various tools to invoke certainactions within the controller. This will allow a visual element such as a button or textfield to invoke a method within the controller’s API that carries out a task or manipulatesthe model. An example of this will be the user pressing a button to fetch any new boardstatuses, and the controller acting on this command by populating the model with newlyfetched statuses.

As the controller API is now responsible for the manipulation of data, the security riskmoves from direct user input to security risks within the API itself that the user mayinteract with. An example of this may be the user sending a status update to the serverthat contains malicious commands to alter or even delete the entire database. With thisexample in mind, queries towards the MySQL database will use ‘prepared statements’.Prepared statements ensure that every request to the database only passes data providedby the user, and does not directly execute commands sent by the user. This means that ifthe user were to send a malicious command as a piece of data it would simply be ignoredand not executed in any fashion.

With the potential abuse of unwanted command executions removed, the focus may nowturn to data poisoning. As the previously mentioned, data sent from the user will notbe executed in any way on the database, but that does not mean it is data we still wantwithin our system. For this reason we use techniques known as sanitisation and validation.

Sanitisation is used to ensure the data received from the user only contains valid characters.This means removing any characters from the message that do not fall into the specifiedsanitisation charcter set. An example of this may be removing letters from a value thatis expected to be a number, such as the value of the current temperature. Validation isused to limit the data to a specified format or range. This may be ensuring a number isbetween a set of values, or checking that a password is at least three characters long.

For this data to first be sanitised/validated it must first be downloaded from the OrangeSOAP server and parsed. With the messages being downloaded to an XML format, thecontroller must provide functionality to parse an XML file for its data. The implementedXML parser will then be used to parse messages from the Orange SOAP server as well asthe custom message format for board status updates, specified earlier in this paper.

13

4.2 Use CasesAs outlined in the view section, there are two key functions the product should perform:displaying circuit board statuses and fetching status updates. These can be applied to a‘use case scenario’ to identify the steps involved.

4.2.1 Use Case: Display Board Statuses

Main Success Scenario:1. User requests statuses for circuit board

2. System connects and authenticates to the database

3. System queries database for board information

4. System queries database for board statuses

5. System collates both tables to find the current status for each board

6. System updates the model with the retrieved statuses

7. Model displays the retrieved statuses via the view

Extensions:2. Fail to connect/authenticate to the database

3. No board information found

4. No statuses found

4.2.2 Use Case: Fetch New Statuses

Main Success Scenario:1. User requests statuses udpates

2. System connects and authenticates to the database

3. System queries database for board information

4. System connects to the SOAP server

5. System downloads and parses new messages from SOAP server

6. System updates database with new statuses

7. System updates the model with the new statuses

8. Model displays the new statuses via the view

Extensions:2. Fail to connect/authenticate to the database

3. No board information found

4. Fail to connect to the SOAP server

5. No messages downloaded

14

4.3 UML Class Diagram

To aid with the development process, a visual representation of the product’s classheirarchy has been created. The use of a unified modeling language (UML) diagramhelps to represent the product’s construction in an object oriented (OO) manner. Beloware the UML class diagrams that identify how the product may implement the MVCpattern. These diagrams are merely a guideline and may be changed by the developerwhere appropriate.

Figure 5: The model UML diagram

15

Figure 6: The view UML diagram

Figure 7: The controller UML diagram

16

5 Implementation

The implementation provides a clear outline as to how the specified design choices havebeen adapted and applied to the product successfully, and modified where appropriate.Figure 8 shows the heirarchy of the source code directories.

Figure 8: The source code heirarchy tree

17

5.1 Model-view-controller

Looking at Figure 8 we can see three key directories. The application directory housesthe source code of the product and contains the implementation of the MVC pattern. Theother directories include the public_php directory and the test directory.

• applicationThis directory includes the MVC compliant files:

– controllersThe controllers of the product, providing utility functions to control the RDBMSand SOAP client.

– modelsThe data within the product, including a collection of board information andcurrent statuses.

– viewsThe user interfaces that are displayed to the viewer. These include one ‘view’for each different webpage generated by the product.

• public_phpThis directory includes all of the public facing files. Any files within this directorymay be accessed by the public. This seperation of public and private files increasessecurity as users have only this directory as a point of access to the product, andmay not directly execute any other PHP script.

• testThis directory contains the unit tests for features of the product. The structure ofthe directory mimics the structure of the directories that are being tested.

18

5.2 Security

The security of the product was approached with great severity within the implementa-tion. This is demonstrated within the SMSValidator class which is used to ensure thatsanitisation and validation techniques were applied to data contained within the SMSmessages. These techniques were implemented with the use of PHPs provided filter_varfunction. This allowed the developer to apply various filters to sanitise the data to removeany unwanted characters, and validate the data to ensure it is formatted in an expectedmanner. An example of this is shown in Listing 3.

1 /**2 * Sanitizes and validates the fan status.3 * @return string The fan status.4 * @throws Exception If an error occurs during sanitisation/validation.5 */6 public function validateFan()7 {8 $key = ’F’;9

10 $fan = $this->getValue($key);11 $fan = filter_var($fan, FILTER_SANITIZE_NUMBER_INT);12 $fan = filter_var($fan, FILTER_VALIDATE_INT,13 array(’options’ => array(’min_range’ => 0, ’max_range’ => 1)));1415 if ($fan === false) {16 throw new FilterException($key);17 }1819 if ($fan === 0) {20 return ’FORWARD’;21 } else if ($fan === 1) {22 return ’REVERSE’;23 }2425 throw new FanStateMismatchException($key);26 }

Listing 3: The validation method used for the fan state

Upon inspecting this validation function, we can see the first check ensures that the ‘F’key has been set. Looking at the specification defined earlier within this paper we seethat the ‘F’ value must be either 0 to indicate the fan moving forward, or 1 to indicatethe fan moving in reverse. This ensures that the value is set before proceeding.

19

The next security technique within the function applies the filter_var function providedby PHP to ensure the variable is an integer value. The first call to the filter_varfunction sanitises the data, removing any extraneous characters that are unrelated to aninteger, and the second call then validates that the result is between 0 and 1. If eitherof these calls to filter_var fail, then they will return a value of false, for this reasonwe check to see if the filtering has failed and if so throw an exception upwards to theexception handler.

Finally we check which fan state the validated value corresponds to. We do this by usingthe identical (===) operator to ensure the variable is the same value and type of therequired field. We can see that the values it checks for are 0 and 1, and any other valuecauses an error to be thrown.

Another class that incorporates extensive security measures is the DatabaseWrapper. Thisclass involves the direct manipulation of values within the database and as such createsa large security risk of data being manipulated maliciously by a user. For this reasonsecurity techniques were implemented to reduce the risk of any malicious activity againstthe database.

One security technique used for the control of the database was the use of databaseaccounts with specified privileges. This ensures that the account that the product isusing to interact with the database has a limited amount of actions it can perform on thedatabase, thus removing its ability to directly manipulate the entire table in a maliciousmanner.

Another security techniqued used involved prepared statements. This ensured that whenupdating the database, data was only passed to the statement and never executed directly.This ensures that if a user was to pass a malicious command via a status update, thecommand would simply be stored as textual data and never directly executed by theproduct. This is shown in Listing 4.

20

1 /**2 * Updates the {@var database} with a new user account.3 * @param $account UserAccount The user account.4 * @throws ExecuteStatementException If the statement fails to execute.5 * @throws PrepareStatementException If the statement fails to prepare.6 */7 public function addAccount($account)8 {9 $statement = $this->database->prepare(

10 ’INSERT INTO users11 SET username = :username,12 passwordHash = :passwordHash,13 rank = :rank’);1415 if ($statement === false) {16 throw new PrepareStatementException(__FUNCTION__);17 }1819 $username = $account->getUsername();20 $passwordHash = $account->getPasswordHash();21 $rank = $account->getRank();2223 $statement->bindParam(’:username’, $username, PDO::PARAM_STR);24 $statement->bindParam(’:passwordHash’, $passwordHash, PDO::PARAM_STR);25 $statement->bindParam(’:rank’, $rank, PDO::PARAM_STR);2627 if ($statement->execute() === false) {28 throw new ExecuteStatementException(__FUNCTION__);29 }30 }

Listing 4: The usage of prepared statements

21

22

6 Test Plan

In order for the product to perform as the user expects, it should be bug free and void ofany security risks. For this reason the product must undergo an extensive testing processto ensure any bugs or faults are fixed before production. The project adopted a test-drivendevelopment (TDD) process that allowed the developer to continually test source code asit was written, ensuring that the product did not fail any user written tests. This wasachieved with the use of unit testing, providing the developer with tools to test every partof the produced source code during development. This ensured that there were no bugsleft unattended in each feature before moving on to the next deliverable.

The unit test suite used the product was SimpleTest, an open source unit testing frameworkfor the PHP language. An example unit test of the product using SimpleTest is shown inListing 5.

1 function testValidDate()2 {3 $this->assertNotNull($this->validateDate(’27/12/2014 02:19:28’));4 $this->assertException(’InvalidDateException’,5 [$this, ’validateDate’], [’27/12/2014’]);6 $this->assertException(’InvalidDateException’,7 [$this, ’validateDate’], [’Monday 29th Dec’]);8 $this->assertNotNull($this->validateDate(’1/1/2001 01:01:01’));9 $this->assertException(’InvalidDateException’,

10 [$this, ’validateDate’], [’\’\’’]);11 $this->assertException(’InvalidDateException’,12 [$this, ’validateDate’], [’<>\’\’#&’]);13 $this->assertException(’MissingSMSKeyException’,14 [$this, ’validateDate’], [null]);15 }

Listing 5: An example unit test

The unit testing is relied on heavily throughout every part of the product. This includestesting the database client, the SOAP client, the XML parser, and the model classes.Figure 9 displays the final unit testing results, identifying 145 completed tests within 3test cases, performed during the course of development.

Figure 9: The unit test results

23

6.1 Testing SMS Messages

With the unit testing incorporated we can see the sanitisation and validation processes ineffect for the SMS message parsing. The tables below outline the rigorous testing methodsinvolved for the SMS message parsing and demonstrate the effectiveness of the sanitisationand validation processes.

Field Input Expected Output Actual OutputMSISDN 447817814149 447817814149 447817814149MSISDN ‘+447817814149’ 447817814149 447817814149MSISDN -447817814149 FilterException FilterExceptionMSISDN ‘<447817814149>’ 447817814149 447817814149MSISDN 4401010101 4401010101 4401010101MSISDN 0005 0005 0005MSISDN ‘(+44) 7817 814 149’ 447817814149 447817814149MSISDN null MissingSMSKeyException MissingSMSKeyExceptionDate ‘27/12/2014 02:19:28’ DateTime DateTimeDate ‘27/12/2014’ InvalidDateException InvalidDateExceptionDate ‘Monday 29th Dec’ InvalidDateException InvalidDateExceptionDate ‘1/1/2001 01:01:01’ DateTime DateTimeDate ‘ ‘’ ’ InvalidDateException InvalidDateExceptionDate ‘<>‘’#&’ InvalidDateException InvalidDateExceptionDate null MissingSMSKeyException MissingSMSKeyExceptionBearer ‘SMS’ ‘SMS’ ‘SMS’Bearer ‘sms’ BearerMismatchException BearerMismatchExceptionBearer ‘<SMS>’ BearerMismatchException BearerMismatchExceptionBearer ‘GPRS’ BearerMismatchException BearerMismatchExceptionBearer null MissingSMSKeyException MissingSMSKeyExceptionID ‘abc123’ ‘abc123’ ‘abc123’ID ABC123 IDMismatchException IDMismatchExceptionID abc__123 IDMismatchException IDMismatchExceptionID #_& IDMismatchException IDMismatchExceptionID null MissingSMSKeyException MissingSMSKeyExceptionSwitch 0 ‘OFF’ ‘OFF’Switch 1 ‘ON’ ‘ON’Switch off FilterException FilterExceptionSwitch 2 FilterException FilterExceptionSwitch -1 FilterException FilterExceptionSwitch null MissingSMSKeyException MissingSMSKeyExceptionKeypad 0 0 0Keypad 5 5 5Keypad 10 FilterException FilterExceptionKeypad -1 FilterException FilterExceptionKeypad ‘five’ FilterException FilterExceptionKeypad ‘_5’ 5 5Keypad ‘&2&’ 2 2Keypad null MissingSMSKeyException MissingSMSKeyException

24

Field Input Expected Output Actual OutputFan 0 ‘FORWARD’ ‘FORWARD’Fan ‘<0>’ ‘FORWARD’ ‘FORWARD’Fan 1 ‘REVERSE’ ‘REVERSE’Fan 1; ‘REVERSE’ ‘REVERSE’Fan 2 FilterException FilterExceptionFan 3 FilterException FilterExceptionFan -1 FilterException FilterExceptionFan ‘On’ FilterException FilterExceptionFan ‘off’ FilterException FilterExceptionFan ‘FORWARD’ FilterException FilterExceptionFan null MissingSMSKeyException MissingSMSKeyExceptionTemperature 25 25 25Temperature 99 99 99Temperature 105 105 105Temperature -12 -12 -12Temperature ‘HOT!’ FilterException FilterExceptionTemperature ‘really cold’ FilterException FilterExceptionTemperature -55 -55 -55Temperature -25; -25 -25Temperature ‘SELECT 25’ 25 25Temperature null MissingSMSKeyException MissingSMSKeyException

6.2 Testing Main FunctionsNext we should test both of the two main functions of the program, the retrieval of storedinformation from the database and the retrieval of new status updates.

Test 1. Display information - No board information savedThe system should inform the user that there has been no saved information.

Test 2. Display information - Board with no status savedThe system should inform the user of the board’s details (name, MSISDN) but note thatthere is no currently stored status for the board.

Test 3. Display information - Board with a saved statusThe system should display the information of the board (name, MSISDN) as well as thecurrent status of the board (switch states, fan state, temperature etc).

Test 4. Fetch new statuses - No new messagesThe system should inform the user that there have been no new updates.

Test 5. Fetch new statuses - New message with invalid formatThe system should inform the user that there have been no new updates.

Test 6. Fetch new statuses - New message with valid formatThe system should parse the message, update the database with the new status and thendisplay the new status to the user.

25

26

7 Version Control

During the product’s development, a version control system (VCS) was used to managethe changes that each team member provided to the product. This ensured that as ateam, we always had access to backups of the product and could identify who changedwhat feature and at what time.

The VCS chosen was Git. Git is a distributed VCS and the most widely adopted VCSon the market. A private GitHub repository was used to host the project, providing theteam with a private area to submit changes, discuss issues, and open bug reports.

A full list of the commits each user made to the repository is provided below.

1 commit c899d01380f18feca0bf00ed3027df9304322d792 Author: Michael3 Date: Mon Dec 145 Initial commit67 commit 54f6542e1b837f5f7badf489f9062f4d5551d3328 Author: Michael9 Date: Tue Dec 2

1011 Basic SOAP client1213 commit bb86c13e25de2a9d4b6f24c5d5ec683b002a994b14 Author: Pratik15 Date: Tue Dec 21617 Soap client testing1819 commit 4ac2cae3bd26a000a8976a057afe8174c1091c4220 Author: Preet21 Date: Wed Dec 32223 GUI design docs2425 commit 090fb5929521bcb6e5f83b259d694027e7c2ad6026 Author: Michael27 Date: Wed Dec 32829 Implemented view3031 commit 33de4c30332eff48b34a1514bef67f170cf2904932 Author: Michael33 Date: Wed Dec 33435 Message parsing3637 commit 2b094bdf5800c72d20db4ba7fa91315e74d5a30e

27

38 Author: Pratik39 Date: Wed Dec 34041 Test XML parser4243 commit 23f65dd02b24a79d18cead11f8e318ea27ed106144 Author: Preet45 Date: Fri Dec 54647 Database design docs4849 commit 4a66dc0850517313ac03cf1906eefd63d166200050 Author: Michael51 Date: Fri Dec 55253 Database implemented5455 commit c681f054a6d20405e7633c8285beaf2e913e418f56 Author: Michael57 Date: Fri Dec 55859 Db support in PHP6061 commit 7236da1e1641135bdec46c3df1b8a9fd57bf6c7762 Author: Pratik63 Date: Sat Dec 66465 Test DB System6667 commit af09ef1d4ffa6beb5c0def1e91e3c3ef30fde4ec68 Author: Preet69 Date: Sat Dec 67071 Message format spec.7273 commit f6428dd294d3c452db81ff165d847e17f9833e2774 Author: Michael75 Date: Sun Dec 77677 Updates stored in DB7879 commit 57b898843cc9702b4e1ede2b777faab13f8f095980 Author: Pratik81 Date: Mon Dec 88283 DB pen testing8485 commit 0263d0df9cf3f61c67254df59a4d6ab8ded63d9786 Author: Preet87 Date: Tue Dec 988

28

89 User system design docs9091 commit 7fe1e8c0979efade63a55cfd9c4bf0d10aa7d9fb92 Author: Michael93 Date: Tue Dec 99495 Register system9697 commit 379afb5e89be4174497f2d41427a7714a43cf5cf98 Author: Michael99 Date: Thu Dec 11

100101 User acc system finished102103 commit d56052f15b8ff9c043d40c6ce5fb34c5b06d2081104 Author: Pratik105 Date: Fri Dec 12106107 Test user acc system108109 commit b3d7863f8730291b040aeb57da0ce1e3c3eebf63110 Author: Pratik111 Date: Sat Dec 13112113 Test SMS validation114115 commit 761343a21ab068e3981192558d64adb63cbe823d116 Author: Michael117 Date: Sun Dec 14118119 Vector graphics made120121 commit 66104ce70ceca2da4932eaf44ca4c63d7b7fef76122 Author: Preet123 Date: Mon Dec 15124125 UI Improvements126127 commit 231e29cfc2635e4fb5e4c806cfc49d70daa60544128 Author: Michael129 Date: Tue Dec 16130131 Added charts to view132133 commit 5cd6822fbf1ccda8c6fe56d9ac638424f7d615ec134 Author: Michael135 Date: Thu Dec 18136137 Optimisation

Listing 6: The Git commit log

29

30

8 Extension Functionality

After the product was completed, extra allocated time within the project was used toidentify and develop natural extensions to the product.

8.1 Retina ReadyWith devices having increasingly higher pixel densities on their screens it is important thata new website is developed with these technologies in mind. Dubbed ‘retina’ by Apple,high pixel density screens include more pixels per inch of screen, thus allowing a screento display more content in the same amount of space. Raster images are designed to beviewed at one scale and thus enlarging it results in a poor quality ‘pixelated’ image. Thiscan be rectified by using vector images. Whereas a raster image contains a grid of pixelsand their associated colours, a vector image is constructed with geometrical operationssuch as points, lines, or curves. This allows the image to be upscaled without creating apixelated mess, thus providing the same level of clarity across all devices of varying pixeldensity.

Scalable vector graphics (SVG) is an XML-based vector image format and open standarddeveloped by the W3C. Vector images saved with this format can be upscaled withina webpage without being pixelated, as demonstrated in Figure 11. An upscaled rasterimage is shown in Figure 12 for comparison.

Figure 10: The normal scale of the ‘home’ icon

Figure 11: The home icon upscaled as an SVG file

Figure 12: The home icon upscaled as a raster image file

31

8.2 Template Engine

Smarty is a web template system written in PHP that allows seperation of PHP code andXHTML output. It uses data provided in the view component of MVC and assigns itto a given Smarty template file (.tpl). These template files allow a front end developerto construct a webpage and use the values supplied by a back end developer within thepage’s content. This means that the front end developer can change how the XHTMLpage is displayed without having to touch or interfere with the back end. Similarly, a backend developer can change how the content is produced without affecting the producedXHTML page.

The implementation of Smarty incorporates template inheritance, allowing us to definethe layout of a page that all other pages will conform to. This means that every otherpage will look the same and only the content will be changed. This OO approach totemplate design means that the look of the page only has to be written once, and if itis changed then all other pages will reflect this change. An example of this is shown inFigure 7, where we can see the page inheriting from the main site layout (layout.tpl)and adding content in the form of a welcome message. The template in Figure 7 is thenused by Smarty to produce the webpage shown in Figure 13.

1 {extends file="layout.tpl"}2 {block name="content"}3 <h3>Welcome</h3>4 <p>5 To begin, simply <a href="/?action=register">create an account</a>. Once6 created, you may then <a href="/?action=login">log in to it</a> for the7 ability to <a href="/?action=statuses">view circuit board statuses</a>.8 </p>9

10 <p>11 Administrators may poll the service for12 <a href="/?action=updates">updates to the circuit boards</a>.13 </p>14 {/block}

Listing 7: An example of template inheritance within Smarty

Figure 13: The result of index.tpl

32

8.3 Template Caching

Smarty also provides a feature for template caching. Once templates have been constructedand compiled, Smarty can cache them for a specific amount of time so that they do notneed to be generated for every user upon opening the webpage. Cached pages are onlystored in this implementation for 120 seconds, meaning that if a front end developerchanges any of the templates, it may take up to two minutes for them to see the result.

Various fields within the created templates have been marked with the {nocache} function.This function, provided by Smarty, is used to signal that data within the function shouldnot be cached. This includes error message, the status of the boards, parsed updates, andother frequently changing data. This is important as if the system was to cache theseresults then a user may be repeatedly be shown an error message for two minutes whenthere is no error with their input.

1 /* construct template engine */2 $smarty = new Smarty();3 $smarty->caching = true;4 $smarty->cache_lifetime = 120;5 $smarty->setTemplateDir(__DIR__ . ’/layouts’);6 $smarty->setCompileDir(__DIR__ . ’/../data/compiled_templates’);7 $smarty->setCacheDir(__DIR__ . ’/../data/cache’);

Listing 8: The code used to enable caching within Smarty

1 {extends file="layout.tpl"}2 {block name="content"}3 <h3>Error</h3>4 {nocache}5 <p>{$error}</p>6 {/nocache}7 {/block}

Listing 9: An example of the {nocache} function used in error.tpl

8.4 Optimisation

The final use of Smarty within the product’s implementation was its ability to opti-mize the XHTML output. It does this by stripping whitespace and new lines betweeneach XML tag. This action is performed by calling $smarty->loadFilter("output","trimwhitespace").

33

8.5 User Management

Further security measures were implemented in the form of a user management system.This system allows users to register for basic access to the product (viewing the circuitboard statuses) and requires an administrator account to access the debug page or pollthe service for updated circuit board states. This adds a new level of security to theproduct, and a natural extension to this would be logging the activity of each accountwhilst using the product.

Users are stored in the users table within the database, the structure of which is describedbelow.

Name Type Keyusername varchar(50) PrimarypasswordHash varchar(255)rank enum(‘USER’, ‘ADMIN’)

Extending the lessons learned in the security section of this paper, accounts do not storetheir password in the database, but instead store a ‘hashed’ password. This ensuresthat if the database is compromised, user passwords are never exposed in plaintext. Thepassword_hash function provided by PHP is used to hash the passwords with the bcryptalgorithm. PHP also automatically generates a random salt for the password to preventagainst rainbow table attacks. When logging in, the user provided password is checkedagainst the stored password hash in the database using the password_verify functionprovided by PHP.

Figure 14: The registration page

Figure 15: The login page

34

8.6 Data Visualisation

With the use of the Google Chart API, temperature information of each circuit boardis displayed in a bar graph to visualise the values in degrees Celsius (◦C) and degreesFarenheit (◦F). This is done by utilising the JavaScript API provided by Google to generatea portable network graphic (PNG) file.

1 <script type="text/javascript" src="https://www.google.com/jsapi"></script>2 <script type="text/javascript">3 google.load("visualization", "1", {packages: ["corechart"]});4 google.setOnLoadCallback(drawCharts);56 function drawCharts() {7 var element = document.getElementById("chart_447966925647");89 new google.visualization.ColumnChart(element).draw(

10 google.visualization.arrayToDataTable([11 ["", "Temperature", { role: "style" }],12 ["Celsius (C)", 99, "blue"],13 ["Farenheit (F)", 210.2, "red"]14 ]),15 {16 title: "Temperature of Michaels Phone",17 legend: "none"18 }19 );20 }21 </script>

Listing 10: JavaScript code used to create a Google Chart

Figure 16: An example temperature chart

35

36

9 Conclusion

From the inception of this project the core design principles have helped shape theimplementation process to create a fully functioning product that accurately follows therequirement specification provided. The product performs in an efficient and clear mannerfor the user and performs the tasks that the user requires, with minimal effort.

The design methodologies adopted within the product’s implementation helped greatly toshape a well built and manageable piece of software that future developers may easilyimprove upon. Natural extensions to the product may include:

• Improved visual representations of data.

• A control system that allows the user to issue commands and updates to the boardsvia the web application.

Figure 17: The final product

37

38

References

EE (2013). EE M2MConnect User Guide, p. 14.

Pemberton, Steven et al. (2000). “XHTML 1.0 the extensible hypertext markup language”.In: W3C Recommendations, pp. 1–11.

solid IT (2014). DB-Engines Ranking. url: http://db-engines.com/en/ranking.

List of Figures

1 A typical telematics circuit board . . . . . . . . . . . . . . . . . . . . . . . 1

2 The home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 The statuses page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 The updates page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 The model UML diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 The view UML diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7 The controller UML diagram . . . . . . . . . . . . . . . . . . . . . . . . . 16

8 The source code heirarchy tree . . . . . . . . . . . . . . . . . . . . . . . . 17

9 The unit test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

10 The normal scale of the ‘home’ icon . . . . . . . . . . . . . . . . . . . . . . 31

11 The home icon upscaled as an SVG file . . . . . . . . . . . . . . . . . . . . 31

12 The home icon upscaled as a raster image file . . . . . . . . . . . . . . . . 31

13 The result of index.tpl . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

14 The registration page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

15 The login page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

16 An example temperature chart . . . . . . . . . . . . . . . . . . . . . . . . 35

17 The final product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

39

Listings

1 An example XML message header . . . . . . . . . . . . . . . . . . . . . . 5

2 An example XML message of a circuit board’s status . . . . . . . . . . . 6

3 The validation method used for the fan state . . . . . . . . . . . . . . . . 19

4 The usage of prepared statements . . . . . . . . . . . . . . . . . . . . . . . 21

5 An example unit test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6 The Git commit log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7 An example of template inheritance within Smarty . . . . . . . . . . . . 32

8 The code used to enable caching within Smarty . . . . . . . . . . . . . . 33

9 An example of the {nocache} function used in error.tpl . . . . . . . . 33

10 JavaScript code used to create a Google Chart . . . . . . . . . . . . . . . 35

Glossary

Git

a distributed VCS. 27

MySQL

an open source RDBMS. 10, 13

open source

universally accessible and freely licensed. 10, 23, 40

retina

a high pixel density screen. i, 31

SimpleTest

an open source unit testing framework for the PHP language. 23

Smarty

a web template system written in PHP. 32, 33, 40

unit testing

testing method involving individual units of source code. 23, 40

40

Acronyms

API application programming interface. 13, 35

CSS cascading style sheet. 7, 11

HTTP hypertext transfer protocol. 7

M2M machine to machine. 5

MVC model-view-controller. i, 9, 15, 18, 32

OO object oriented. 15, 32

PHP hypertext preprocessor. 7, 11, 18–20, 23, 32, 34, 40

PNG portable network graphic. 35

RDBMS relational database management system. 10, 18, 40

SMS short message service. 5, 19

SOAP simple object access protocol. 5, 6, 13, 18, 23

SVG scalable vector graphic. 31, 39

TDD test-driven development. 23

UI user interface. 9, 11

UML unified modeling language. i, 15, 16, 39

VCS version control system. 27, 40

W3C world wide web consortium. 7, 31

XHTML extensible hypertext markup language. 7, 11, 32, 33

XML extensible markup language. 5, 6, 13, 23, 31, 33, 40

41