Fall$ 08 - American University in Cairorafea/CSCE492/Fall2015/SDD-Arabity.pdf · disassembler, a...

T h e A m e r i c a n U n i v e r s i t y i n C a i r o

Software Design Document Ahmed ElHussiny, Mohamed ElShaer, Nada Hazem, Omar Abdelwahed, and Omar ElSafty Advised by Dr. Mohamed Shaalan – Coordinated by Dr. Ahmed Rafea

Fall 15

08 Fall

i

Table of Contents

1. INTRODUCTION 1

PURPOSE 1 1.1. DOCUMENT CONVENTIONS 1 1.2. TEAM MEMBERS 2 1.3.

2. DESIGN OVERVIEW 5

BACKGROUND INFORMATION 5 2.1.2.1.1. SYSTEM OVERVIEW 5 2.1.2. SYSTEM SCALABILITY 5

CONSTRAINTS 5 2.2.2.2.1. USER-‐BASE 5 2.2.2. GIV BOX CREATION 6

DESIGN TRADE-‐OFFS 6 2.3.2.3.1. REQUEST SEPARATION 6 2.3.2. BUMP RECOGNITION ALGORITHM 6 2.3.3. EXTERNAL SYSTEM INTEGRATION 6

USER CLASSES AND CHARACTERISTICS 7 2.4.2.4.1. PUBLIC USERS: 7 2.4.2. OWNER USERS: 7 2.4.3. DRIVER USERS: 7

3. SYSTEM ARCHITECTURE 8

SOFTWARE ARCHITECTURE 8 3.1.3.1.1. SYSTEM AS A WHOLE 8 3.1.2. GIV BOX 8 3.1.3. THE CLOUD 8 3.1.4. USER APPLICATION 9

COMMUNICATIONS ARCHITECTURE 9 3.2.

4. DATA DESIGN 11

5. DETAILED DESIGN 15

COACH 15 5.1.5.1.1. PURPOSE 15 5.1.2. INPUT 15 5.1.3. LOGIC 15 5.1.4. OUTPUT 16

GIV 19 5.2.5.2.1. CRYSTALB 19 5.2.2. PERIODIC I-‐PACK GENERATOR 19 5.2.3. ANNIHILATOR 20 5.2.4. WAVER 20

ii

5.2.5. CLASS TABLES 21 5.2.6. CLASS DIAGRAM 24

CLOUD 25 5.3.5.3.1. CLOUD WAVER 25 5.3.2. TRAFFIC ANALYSIS PROGRAM 25 5.3.3. TRAFFIC ANALYSIS API 26 5.3.4. I-‐PACK RECEIVER 26 5.3.5. BUMP CLUSTERING PROGRAM 26 5.3.6. BUMP FILTERING PROGRAM 27 5.3.7. LOCATION COMPARATOR 27 5.3.8. NOTIFIER 28 5.3.9. CLASS TABLES 29 5.3.10. CLASS DIAGRAM 31

MOBILE APPLICATION 32 5.4.5.4.1. USER MANAGEMENT SUBCOMPONENT 32 5.4.2. CAR MANAGEMENT SUBCOMPONENT 32 5.4.3. NOTIFICATION SUBCOMPONENT 33 5.4.4. TRAFFIC CONDITION MAPPING SUBCOMPONENT (MAP) 34 5.4.5. WAVER SUBCOMPONENT 34 5.4.6. CLASS TABLES 36 5.4.7. CLASS DIAGRAM 38

6. USABILITY DESIGN APPROACH 39

7. REQUIREMENTS TRACEABILITY MATRIX 50

8. GLOSSARY OF TERMS 51

1

1. Introduction

Purpose 1.1.This Software Design Document details every aspect of the design, architecture, implementation, and interfacing of 3arabeety. This document is useful in providing a detailed set of objectives, some of which have already been accomplished, and some of which will be, and providing us with the necessary guidelines and implementation techniques for every part of the system. In that sense, this document behaves as our rule book and implementation strategy for 3arabeety.

Document Conventions 1.2.Main section titles: • Font: Times New Roman • Face: Bold • Size: 16 • Color: Navy Blue • Indent: -0.75 inches • Numbered: Yes • Alignment: Left

Sub-section titles: • Font: Times New Roman • Face: Bold • Size: 14 • Color: Blue • Indent: 0 inches • Numbered: Yes • Alignment: Left

Section-Specific Titles: • Font: Times New Roman • Face: Bold • Size: 12 • Color: Blue • Indent: 1.2 inches • Numbered: Yes • Alignment: Left

Categorization Titles: • Font: Times New Roman • Face: Bold • Size: Same as containing text • Color: Same as containing text

3arabeety Software Design Document

2

• Indent: Same as containing text • Numbered: No • Alignment: Left

Text Explanations: • Font: Times New Roman • Face: Normal • Size: 12 • Color: Black • Indent: Same as previous title • Numbered: No • Alignment: Justified

Team Members 1.3.We are compiled of the some of the most dedicated and hardworking individuals focused on ensuring the safety and emptiness of the roads in Egypt. Each proposed member of the team has the capabilities and experience necessary to be able to successfully implement, manage, and test the 3arabeety system, improving the conditions of the road in Egypt. Ahmed ElHussiny will be the Project Manager, as well as the Senior Software Developer. Omar ElSafty will utilize his programming skills at being the Lead Software Developer of the Team. Nada Hazem will ensure the safety and security of the system, serving as 3arabeety’s Senior Security Expert. Omar Abdelwahed and Mohamed ElShaer will collaborate to provide the User Experience and Interfacing Unit, serving as Senior User Experience (UX) Developers. This team of five dedicated AUC students will serve as the core development, implementation, and management team. In order to ensure cost containment as well as the proper functionality of the different subsystems involved, the team members will also dedicate a percentage of their time for testing purposes. A proposed organization structure is provided below, followed by a brief biographical summary of each of the team members, summarizing each member’s skills and expertise, qualifying him/her for the position they would be holding.

Project Manager

(Ahmed ElH. 45%)

Software Development Unit

Senior Software Developer (Ahmed

ElH. 45%)

Lead Software Developer

(Omar ElS. 90%)

System Security Expert (Nada H.

90%) User Experience and Interfacing Unit

Senior User Experience Developer

(Mohamed ElS. 90%)

Lead User Exerpience

Developer (Omar A.90%)

Testing Unit

Software and Hardware Testers (Entire Team 10%

each)

Fall 2015

3

Ahmed ElHussiny, Project Manager, Senior Software Developer, and Tester: eMail Address: [email protected] Phone Number: (+2) 0109.717.42.40 Ahmed has been studying Computer Science at the American University in Cairo (AUC) since 2011. In his internship at GPC-GIS Abu Dhabi, Ahmed has had the opportunity to learn about and apply different software-centric project management frameworks such as PMI, TOGAF, and ITIL. It is this knowledge that has enabled Ahmed to lead the different teams he has worked with to complete different team projects throughout his career at AUC. In Ahmed’s coursework, he has acquired a deep understanding of the inner workings of numerous programming languages as well as database querying languages, such as SQL. This understanding then enabled him to create a startup with some colleagues in which he had multiple experiences developing large-scale web-based systems such as ElSupplier. Through his extensive hours of driving in Cairo, Ahmed is fit to test the hardware necessary for the 3arabeety system. Omar El Safty, Lead Software Developer and Tester: eMail Address: [email protected] Phone Number: (+2) 0109.50.4348.1 Omar has been studying Computer Science at the American University in Cairo (AUC) since 2012. He has acquired a distinctive skill-set in his four-year pursuit of the computer science bachelor degree. He has accomplished a deep understanding in the field of programming especially common data structures and algorithms. His design and implementation skills have expressed themselves in several academic projects, including numerous simulations in C++ like CPU pipelining and MIPS disassembler, a chatting system in Java, and a banking system database using Oracle. In addition, he has gained fair knowledge in network programming after a two-months summer internship in OBS (Orange Business Services). Moreover, Omar has agreed to use his vehicle for testing the system to be involved in the testing phase. Using his education and technical experience, Omar will be providing the required technical background to ensure the correct fulfillment of the team’s project. Omar will assume 90% dedication to his role as Software Developer and 10% to his role as Hardware tester using his car. Omar’s solid technical background and dedication make him an ideal candidate for both roles. Nada Hazem, Senior Security Expert and Tester: eMail Address: [email protected] Phone Number: (+2) 01.0000.55.3.11 Nada has been studying Computer Science at the American University in Cairo (AUC) since 2013. During her pursuit for the bachelor of Computer Science over the course of four years, she has been exposed to different areas of the field which has shaped her diverse set of skills. She has completed several projects which include a banking system using the Oracle RDBMS, website design and development for the


4

Entrepreneurship Society at AUC, and mobile applications development. She has also participated in large-scale projects such as ElSupplier as her most recent endeavor. Mohamed El-Shaer, Senior User Experience Developer, and Tester: eMail Address: [email protected] Phone Number: (+2) 0.1111.4499.73 Mohamed has been studying Computer Science at the American University in Cairo (AUC) since 2010. In his internship at the start-up Go Mal3ab in Egypt, Mohamed was given the opportunity to lead the User Experience Design Team. This has given Mohamed the ability to give a heavy opinion in which path to take in order to provide users with a comfortable and friendly experience making every step as easy and convenient as possible. In Mohamed’s coursework, he has acquired a deep understanding of different programming languages, as well as database languages, such as SQL. For this reason, he has started a startup with friends dedicated to Software Development. Moreover, it has given him the confidence to participate in the Egyptian Engineering day competition with BUSTLE, an application to facilitate the use of public transportation in Egypt. Also Mohamed works on campus with one of the leading entrepreneurial organization (Entrepreneurs’ Society) as the Information and Technology associate where he is in charge of their online presence and maintenance, giving him more experience and exposure on the significance of user experience (UX) and user interface (UI). Omar Abdelwahed, Lead User Experience Software Developer, and Tester: eMail Address: [email protected] Phone Number: (+2) 0100.800.5090 Omar has been studying Computer Science at the American University in Cairo (AUC) since 2011. In his internship at Microsoft, Omar has had the opportunity to learn about and apply different approaches on application development using C#. It is this knowledge that has given Omar the ability to work on different projects having been exposed to different ideas and opinions about what is considered as user friendly. Throughout Omar’s coursework, he acquired self-learning mentality that continues to drive him forward towards new paths not necessarily related to his major. Given that mind-set, Omar has decided to complete a minor in Business Administration that helps him offer more than just a technical and design aspect to the project. This understanding then enabled him to create a start up with some colleagues in which he had multiple experiences developing large-scale web-based systems such as ElSupplier, and also work on campus with one of the leading entrepreneurial organization (Entrepreneurs’ Society) as the Information and Technology manager where he is in charge of their online presence and maintenance, giving him more experience and exposure on the significance of user experience (UX).

Fall 2015

5

2. Design Overview

Background Information 2.1.This section provides an overall description of the system functionality, as well as some necessary background information to serve as a guide assisting with an overall understanding of the system.

2.1.1. System Overview 3arabeety’s subsystems are reflective of its core functionalities. The RADFS will enable users to act as information gatherers for the 3arabeety system, informing it of the location of road anomalies on Egyptian streets. This will allow the subsystem to process this information and then be able to warn users of approaching road anomalies. The TAS will also rely on the users to gather information about the condition of traffic in the different roads in Egypt. After processing this information, the subsystem will be able to determine the status of expected traffic conditions on the road and provide this information in the form of a graphical map, with the streets colored the expected levels of traffic. This is in addition to some additional features, such as tracking, that will rely on the same two subsystems to provide their functionalities.

2.1.2. System Scalability 3arabeety is designed to be a highly scalable cloud computing system. For this reason, we have opted to start with the minimal resources outlined in this document. With increased usage and demand, 3arabeety would be able to scale its resources to meet the demand.

Constraints 2.2.When designing a system that is targeted to any and every Egyptian with a car – approximately 7 million – some constraints had to be placed to ensure that when we were building and testing the program, our findings would match the hypothesis. Our results, with adjustments, would then be repeatable when scaled to a wider user base such as the one we are targeting.

2.2.1. User-Base Our system is built to be implemented in any car in Egypt. Clearly the thresholds applied to our system during the testing and even early production phases are very different from those that would apply in real life scenarios. For example, we could assume a bump exists if 2 out of our grand total of 4 users were affected by it. Those 2 users would be an anomaly if they were out of a total of a million users. For that reason, we have chosen to implement our system leaving an array of configurable thresholds. These thresholds would then be adjustable as the system scales up to a wider user-base, thus making our data sensible and repeatable, no matter the user-base.


6

2.2.2. GIV Box Creation As stated in the previously-provided Software Requirements Specification Document, we would simulate the GIV Box on an Android phone, creating an app that performs the same functionality, instead of building that entire system. The reason we have chosen to do that is to be able to focus more on the algorithmic side of our system, achieving a larger number of objectives in the timespan of the project, rather than spend a lot of time building the device that would only provide the input for our program.

Design Trade-Offs 2.3.

2.3.1. Request Separation Initially, we had considered two forms of requests: the B-Pack and the T-Pack. The B-Pack was the information package generated and sent to the server when a bump was sensed. The T-Pack was the information package generated and sent to the server periodically to drive the traffic analysis algorithm. Due to the similarities of the information contained in both packages, we have chosen to merge them as a single package with a flag to determine whether or not a bump exists in the user’s location. The package would always be processed as a T-Pack. If the flag is set to true, it would also be processed as a B-Pack. The reasoning behind this decision was to create a simpler, more efficient code on the side of the client and leave the actual processing to the cloud. This has enabled our simulation of the GIV box to be simpler and thus enabled future hardware implementations of the GIV box to also be simpler and cheaper.

2.3.2. Bump Recognition Algorithm Yet another simplification made to the GIV box, and thus the processing power it needs to contain, is how a bump is recognized. Instead of opting for constantly measuring the difference in motion detected, recognizing spikes, and comparing them with one of our baseline algorithms suggested in the SRS Document, we have chosen to implement a machine-learning algorithm. Thus we added a new component to our system: Coach. Coach would collect the training data necessary and provide a machine-learning algorithm, built into the GIV application, with it. We call this machine-learning algorithm CrystalB. CrystalB would then be able to surmise a “shape” for a bump. When given a stream of the road conditions, CyrstalB would be able to recognize a bump when it comes in contact with it.

2.3.3. External System Integration Although at the beginning we had planned to have the GIV Box interface with the car itself through the car’s OBD-II, we found a lot of reluctance from user’s to plugging something they don’t know directly into their car. In fact, in order to avoid any safety concerns, and enable our system to be widely accessible even to those cars that do not possess an OBD-II interface, we have

Fall 2015

7

chosen to not have the GIV Box interface with the car and to rely solely on the capabilities of the GIV Box itself.

User Classes and Characteristics 2.4.With a system such as 3arabeety, integrating many elements of location and privacy, security is an absolutely essential feature of the system. In order to ensure the security of the system, different user types have to be created, clearly defining what they are and are not allowed to do. This here is a brief description of the different user types. A more extensive look at the access rights of each group is possible through checking the System Security Matrix in the security subsection of Non-Functional Requirements section.

2.4.1. Public Users: Public users are those who are not logged in. They are allowed to view the traffic conditions of the streets in Egypt.

2.4.2. Owner Users: Owners are users that are logged in and have all components of the system. In addition to viewing the traffic conditions of the streets in Egypt, they will also be forewarned, based on the location of their car, of upcoming road anomalies so that they can slow down or avoid the anomaly. Since owners can have multiple cars registered to their account, they will be able to select which car they are driving on their current trip to be warned about it. Owners can also grant timed Driver Access to their cars and revoke the access at any time. Owners are also able to track their cars.

2.4.3. Driver Users: Driver users are another form of logged in users. They are only allowed to view the traffic conditions until they are granted driver access to a car owned by an Owner user. When that happens, the Owner user will stop receiving notifications about it. Instead, the user receiving the notifications will be the one granted driver access to the car, as long as his/her rights have not expired or been revoked. Driver users are not able to track the cars they have been given driver access to. An Owner User can become a Guest User on another Driver’s car.


8

3. System Architecture

Software Architecture 3.1.

3.1.1. System as a Whole The architecture of the 3arabeety system is built as a client server architecture model with two clients and one server. The first client which is the GIV box is responsible for collecting data about the car. This data is in the form of longitude & latitude points, speed, GPS accuracy and other attributes and data types that will be discussed later in detail. The GIV box then sends the information to be processed by the cloud component which acts as the server. The cloud or server is responsible for all the processing, coordination of the application, and the making of logical decisions and evaluations and then communicates the information back to the second client which is the user application. The second client is responsible for the user interface and display of information such as bump notifications as well as traffic analysis data along with other components which will be discussed late in detail. The three components, GIV box, Cloud, & User application, act as the client server architecture model and within these three components, each is built in its own architecture.

3.1.2. GIV Box The GIV box, in this case, is a simulation of a piece of hardware. Therefore, it is built as three-tier architecture without the third tier which is the presentation layer. Since a piece of hardware is being represented, then the presentation layer is unnecessary in this case and only the data tier and logic tier are needed. In the data tier, the information is stored and retrieved from a database or the file system and the information is then passed to the logic tier. The logic tier usually coordinates the application, processes commands, makes logical decisions and evaluations, but in this case it is only responsible for triggering the collection of information as well as sending it to the server component which will be responsible for all the processing and the making of logical decisions and evaluations.

3.1.3. The Cloud Second, the cloud is also built as its own architecture and that is a Service Oriented Architecture model in which a number of services communicate with each other within their own network. Simply, the application components provide services to other components via a communication protocol. In this model, a service is a self-contained unit of functionality and is discretely an operation that can be invoked. The Service Oriented Architecture is a best approach for the cloud because each service is built in a way that service can exchange information with any other service in the network without human interaction and without the need to make changes to the underlying program itself. These services include the Notifier service, the Location Comparator

Fall 2015

9

service, and the Traffic Analysis service. This model includes a data tier which is responsible for holding the information in its own component separate from all other components and services. A logic tier is also present and it’s responsible for deciding which services to run on an incoming packet depending on its attributes or stored data. After all the algorithms are executed, the information is then communicated back to the user application.

3.1.4. User Application Third, the user application is again built in as its own architecture model and that is a Model View Controller architecture model. The model contains the data and again it’s being separated in its own component, the view represents the user interface, and the controller is what links the model and view components. For further detail, the controller can send commands to the model’s state. It can also send commands to its associated view to change the view’s presentation of the model. On the other hand, the model stores the data that is retrieved according to the commands from the controller and displayed in the view. The view then generates an output presentation to the user based on changes in the model. It is also responsible for calling the necessary functions for outputting the information to the user. This architecture is built as a thin model fat controller and that is because in this case, the model acts a repository for the data and does not perform any functions, on the other hand, the controller is responsible for performing the necessary functions to link between the model and view components. For the whole client server architecture model, the data is stored at the server which is the cloud component, but the Mobile application architecture contains its own model or data component because the data is being abstracted from the cloud back into the user application to become its own component.

Communications Architecture 3.2.There exists three main communication lines, the first line connects the GIV box to the cloud, the second line connects the cloud to the user application, and the third connects the user application back to the cloud. These three lines hold different types of information as well as different security levels depending on the sensitivity of information being transported over the communication channel. For the first communication channel, from the GIV box to the cloud, the information being transported is very sensitive because it holds information such as the user’s longitude and latitude points which represents the user’s location. For that reason, this communication channel will be encrypted SSL and also the data packets are encrypted as well. Therefore, not only will the channel be secured but the data being transport would be secured as well. The second communication channel, which is the line from the server to the mobile application, is not encrypted SSL and that is because this line wouldn’t hold any sensitive information. It holds public information which is in the form of bump notifications or traffic analysis data which is all public. The third communication


10

line, which is from the mobile application to the cloud is in fact encrypted SSL as well, and that is because this communication channel holds sensitive information as well such as the user registration and authentication information which includes usernames, passwords, and such.

Fall 2015

11

4. Data Design


12

Weekday ID ID to refer to weekday Name Name of weekday such as (Sunday,

Monday,…) Trafficinfo ID ID to refer to Traffic info unique to

specific day weekdayid Id as a reference to the weekday name in

weekday table Avgspeed An indicator of the average speed of a

specific hour on a specific weekday Lat A representation of the latitude at which

this traffic info has been recorded Long A representation of the longitude at which

this traffic info has been recorded Hour At what time was this traffic info

recorded calculation The number of calculations recorded in

order to calculate the average LatestTrafficinfo ID ID to refer to Traffic info compared to

previously collected data about specific day at a specific time gotten from Trafficinfo table

calculatedhowcrowded Traffic status compared to previously collected data about specific day at a specific time gotten from Trafficinfo table

infotime A timestamp indicating the time this data has been calculated

Lat A representation of the latitude at which this traffic info has been calculated

Long A representation of the longitude at which this traffic info has been calculated

Fall 2015

13

Bump ID ID unique to each bump Lat A representation of the latitude at which

this bump has been recorded Long A representation of the longitude at which

this bump has been recorded Severity How many times a bump has been hit Direction In which direction was the vehicle

moving when the bump was passed upon active A flag to set whether or not the bump is

still active Notification ID ID unique to each notification givid Id to represent which giv box has the

notification been sent to Usrid Id to represent which user has been sent

the notification Body The body content of this notification Sentat At what time was the notification sent Ipack ID ID unique to each information packet Lat A representation of the latitude at which

this information packet has been generated

Long A representation of the longitude at which this information packet has been generated

Accuracy How accurate in meters is the value of the latitude and longitude information

Speed At what speed was the vehicle moving when the infopacket was generated

Givid Which giv was the infopacket generated by

Weekdayid What day was this info generated on Createdat When was this information generated Isbump A flag to represent if this info packet

contains a bump hit or not direction In which direction was the vehicle

moving when the info packet generated


14

usr ID ID unique to each user Name A username for the user Password A password for the user Firstname The first name of the user Lastname The last name of the user Birthdate The birthdate of the user Registrationon The day the user has registered Phoneno The phone number of the user email The email of the user Giv ID ID unique to each giv Usrid The id of the owner of the givbox Name The name of the car given by the owner usrtype ID ID unique to a user type name Name of type of user usrpermissions ID ID unique to each permission granted givid Id to represent which giv box this

permission is active for Usrid Id to represent which user has been sent

an authorization usrtypeid What type of user is this permission

granted to Journey ID ID unique to each journey givid Id to represent which giv box is this

journey linked to startedat At what date was this journey initiated endedat At what date was this journey terminated usrid Id to represent which user is this journey

linked to

Fall 2015

15

5. Detailed Design

Coach 5.1.

5.1.1. Purpose The main aim of the coach application is to collect Data which consists of (X, Y, Z and Timestamp) Values. This data collected will be studied and analysed by another application so as to add to the supposed brain of the machine learning algorithm; hence the name “Coach”.

5.1.2. Input The input for the Coach applications is dependent on a subcomponent of the application which is the Accelerometer Sensor. The Accelerometer sensor Measures the acceleration force in m/s2 that is applied to a device on all three physical axes (x, y, and z), including the force of gravity. It is mainly used for motion detection (shake, tilt, etc.). In our case it will be used to record the measurements of all three physical axes (x, y, and z) throughout the Training Data Collection period. Hence, the input for the Coach component is the values for all three physical axes (x, y, and z) and also the Timestamp value in which the axes reading were taken.

5.1.3. Logic The logic for the Coach application is as follows… The Accelerometer Sensor keeps on reading the values of all three physical axes (x, y, and z) constantly every 5 millisecond. Thus every 5 milliseconds the input data will have a new reading. Therefore, we have implemented on sensor change the value of each of the three physical axes (x, y, and z) will be stored with the timestamp in which they were taken. Here is when another class will be called which is “AccelData.java” so as to take these four inputs (x, y, z, timestamp) and output them as a string object. This step is to simply add the values generated to a string so it can be stored in an array list of strings. At every sensor change the values of the three axes will be taken to do more than one function. The first function will be to take the values and plot them on an updating chart which is generated on the frontend of the application using MPAndroidChart:v2.1.5. The second function is to add the four values to a new array list called “sensorData”. Other Than the updating chart on the graphical user interface (GUI), there are three buttons; Start, Bump and Stop. The start Button starts the data collecting process. The Bump button does a bit more than that. It starts by creating a new thread and initializing a new Json Array named “thisbump”. Moreover, it takes the value of the “sensorData” array list size and stores it in a variable named “size”. Afterwards, a loop is entered taking this size into consideration and storing the last 2000 entries 5 seconds after the bump button has been clicked. These four values will be stored in a json object called “info” and this “info”


16

object will be added to the json array “thisbump”. Every time Bump is clicked, this process will be done and after each bump is recorded as an “info” object, it will be added to the json array of all bumps called “allbumps”. The logic behind the 5 second delay within the thread is to collect a set of data that represents the bump in the sense that the data collected is about 2000 recordings. These 2000 recording represent 10 seconds of generated data by the accelerometer sensor. 5 seconds after the bump has been clicked, concatenated with 5 seconds before the bump button was clicked. Finally there is the “Stop” button which terminates all processes and stores the final generated file of all bumps in a location recognizable by the GIV Box. Furthermore, the graph is then paused and auto resized so as to be able to go back through all the data recorded and see a visual representation of the journey taken.

5.1.4. Output The output of the Coach application is the data represented in a graphical form for the user to analyse visually. In addition to that, the data is also saved as a json file. This json file contains an array of all bumps. Each bump is itself represented as an array of 2000 entries of coordinates (x, y, z, and t) values.

Fall 2015

17

Main Class

Methods onSensorChanged() This Method is called upon sensor data change detected

onClick() This Method is called on click of any of the three provided buttons (Start, Stop, Bump)

openChart() This Method is called onCreate of the main class

onCreate() This Method is called on Application open

onPause() This Method is called on application pause


18

AccelData Class

Attributes X Each time AccelData is called it has to be passed a unique value for the X coordinate

Y Each time AccelData is called it has to be passed a unique value for the Y coordinate

Z Each time AccelData is called it has to be passed a unique value for the Z coordinate

T Each time AccelData is called it has to be passed a unique value for the timestamp

Methods getTimestamp() This method returns the value for the passed Timestamp

setTimestamp() This method sets the value of the timestamp variable to the passed timestamp value

getX() This method returns the value for the passed X coordinate value

setX() This method sets the value of the X variable to the passed X value

getY() This method returns the value for the passed Y coordinate value

setY() This method sets the value of the Y variable to the passed Y value

getZ() This method returns the value for the passed Z coordinate value

setZ() This method sets the value of the Z variable to the passed Z value

String toString() This method returns a string value of the passed variables in the form t:"+timestamp+", x:"+x+", y:"+y+", z:"+z;

Fall 2015

19

GIV 5.2.

5.2.1. CrystalB

Purpose The CrystalB component is the one that does the machine learning and the one responsible for doing Road Anomaly Detection. It is meant to inform the server every time a new bump is found.

Inputs As can be observed from the class diagram provided, CrystalB has SensorData composed into it. This SensorData will include the current road conditions determined from the accelerometer and gyroscope, the GPS latitude, longitude, bearing, speed, and accuracy, and the current system time.

Logic CrystalB will act as a thread that is constantly running, comparing the current road conditions (accelerometer and gyroscope X, Y, and Z obtained from SensorData) to its definition of a road anomaly. This definition will come from its machine-learning component based on the training data provided by the Coach application. The machine learning will be implemented relying on one of three methods: either a support vector machine, a convolution neural network, or through derivation summation. Those three implementations are different. The support vector machine and convolution neural network would both act as a classifier, while derivation summation will rely on obtaining the current condition of the road, retrieving the derivative of the conditions, and then summing the derivative. When that happens, we will be able to detect how much of a change took place. Comparing that change to a threshold provided by the training data, we would be able to recognize if a bump were detected. If a bump is indeed sensed, CrystalB is going to create an I-Pack, setting the isBump flag to true. The generated I-Pack will be added to the queue for processing.

Outputs CrystalB will have no outputs unless a bump is sensed. In that case, its output would be an I-Pack with the isBump flag set to true.

5.2.2. Periodic I-Pack Generator

Purpose The purpose of the Periodic I-Pack Generator is to generate an I-Pack every given amount of seconds. Those I-Packs would be processed on the server to understand the traffic conditions of the road.


20

Inputs We will rely on the device’s GPS location, GPS accuracy, Time, Speed, and Direction.

Logic Very simply, the Periodic I-Pack Generator will generate an I-Pack every given amount of seconds and then add it to the queue to be processed.

Outputs I-Pack every given amount of seconds.

5.2.3. Annihilator

Purpose To send I-Packs generated by CrystalB and the Periodic I-Pack Generator to the server to be processed.

Inputs Queue of I-Packs

Logic The Annihilator checks whether an internet connections exists and whether the queue is not empty. If both of those conditions are matched, then the Annihilator will send the I-Packs in the queue to the cloud. In addition to that, the Annihilator also checks whether the queue has reached its maximum size. If it has, it starts by removing I-Packs that are not ones containing bumps, as they are the ones with less “permanent” information. Once the queue is full but also entirely of bump I-Packs, then each new isBump I-Pack will replace the oldest I-Pack in the queue.

Outputs When there is an internet connection and I-Packs ready to be sent to the cloud, those I-Packs.

5.2.4. Waver

Purpose The purpose of the Waver is to register the beginning and ending of a journey.

Inputs Current time.

Logic The Waver will be implemented as a broadcast receiver, checking whether the charger has been connected or not. This is to simulate power being connected the device, and hence the car being turned on. When the power

Fall 2015

21

is connected, the Waver will register with the server, informing it that a new journey has started. When the power is disconnected, the Waver will register with the server, informing it that this journey has ended.

Outputs The wave sent to the server, whether it is a hi-wave or a bye-wave.

5.2.5. Class Tables Class SensorData Attributes X: float X-coordinate of the data from accelerometer Y: float Y-coordinate of the data from accelerometer Z: float Z-coordinate of the data from accelerometer lat: double Latitude value of the data from GPS lng: double Longitude value of the data from GPS time: date Timestamp of the data from accelerometer speed: float Speed of the car that contains the GIV box direction: float Direction of the moving car that contains the GIV box Methods getters setters

Class I-Pack Attributes lat: double Latitude value of the data from GPS lng: double Longitude value of the data from GPS accuracy: float GPS accuracy in meters speed: float Speed of the car that contains the GIV box GIV_ID: int ID of the GIV box weekday_ID: int

ID of the day of the week in which the I-Pack is created

createdAt: date Date in which the I-Pack is created isBump: int 1 if the I-Pack contains bump information, 0 otherwise direction: float Direction of the moving car that contains the GIV box Methods NONE NONE


22

Class Periodic-I-Pack-Generator Attributes millisec: int Value of milliseconds Methods run() Starts a thread that takes the sensor data every defined

milliseconds and generates an I-Pack then adds it to the queue

generatePack(): I-Pack

Generates and returns an I-Pack object

addToQueue(I-Pack, Queue)

Adds given I-Pack to a given Queue

Class CrystallB Attributes s: SensorData Sensor data object Methods run() Starts a thread that initializes a sensor data object and

compares the sensor data to definition of a bump. If there’s a bump, it will generate I-Pack object and adds it to the queue

generatePack(): I-Pack

Generates and returns an I-Pack object

addToQueue(I-Pack, Queue)

Adds given I-Pack to a given Queue

Class Annihilator Attributes NONE NONE Methods run() Starts a thread that constantly attempts to dequeue if the

queue is not empty and then sends the I-Pack to the cloud checkConnection(): boolean

Returns true if the connection is established, otherwise returns false

sendtoCloud(I-Pack): boolean

Sends an I-Pack object to the cloud and returns true if the operation is done successfully

Fall 2015

23

Class Queue Attributes PackArray: I-Pack[]

Array of I-Pack objects

MaxSize: int Maximum size of the queue Methods enqueue() Adds an I-Pack object to the tail of the queue dequeue(): I-Pack

Removes and returns one I-Pack object from the queue

pruge() Purges the queue

Class Waver Attributes time: date Start time of the journey GIV_ID: int ID of the GIV box journey_id: int ID of the journey Methods SendHi(time,GIV_ID) Calls StartJourney method in CloudWaver class and

passes the start time of the journey and the ID of the GIV as parameters of that method

SendBye(journey_id) Updates the journey record by setting the end date of the journey


24

5.2.6. Class Diagram

Fall 2015

25

Cloud 5.3.

5.3.1. Cloud Waver

Purpose The purpose of the Cloud Waver is to respond to waves from the GIV and from the User App.

Inputs The input to the Cloud Waver relies on the command that is also inputted. In the case of adding a journey, the inputs are the GIV ID and the journey start date. In the case of adding a user, it receives the GIV ID and the user ID. In the case of ending a journey, it receives the journey ID and the end date.

Logic Firstly, a new record is created in the Journey table in case of staring a journey. This also returns the journey ID to the GIV box. In the case of ending a journey, it adds the end date to the record of this journey in the journey table. In the case of adding a user, it adds the user to the record of the journey.

5.3.2. Traffic Analysis Program

Purpose The purpose for the Traffic Analysis program is to determine the average speed in a given location for a given hour in a given day. It also compares the current road traffic condition to this average.

Inputs Traffic Analysis program receives I-Pack as a parameter.

Logic The program updates updates the historical average speed for this location. After that, the program compares the speed from the I-Pack with the updated average and stores the road condition to the database accordingly.

Outputs The program updates the historical average speed of the location of the I-Pack. Also, the road condition for the location is saved.


26

5.3.3. Traffic Analysis API

Purpose The purpose of the Traffic Analysis API is to provide latest traffic analysis information to the mobile application.

Inputs The input of Traffic Analysis API is the current traffic information.

Logic The traffic analysis information in the database is converted to a JSON Array holding the same data.

Outputs The output is the JSON Array that carries the traffic analysis information.

5.3.4. I-Pack Receiver

Purpose The purpose of the I-Pack Receiver subcomponent is to determine the way in which the I-Pack will be processed.

Inputs The I-Pack Receiver receives I-Pack as a parameter.

Logic Every single I-Pack is processed by the Traffic Analysis program as well as the Location Comparator. If the I-Pack indicates the existence of a bump, the I-Pack will be added to the Bump table in the database. Then the bump-clustering program will be called.

5.3.5. Bump Clustering Program

Purpose The purpose of the Bump Clustering Program is to cluster together the bumps that are duplicates of each other in a given threshold range. This is done to enhance accuracy of the Road Anomaly detection functionality.

Inputs The input to the Bump Clustering Program is all bump locations in the Bump table in the database.

Logic Duplicate bumps within a certain range is detected and then merged into the most accurate representation of the bump. This accurate

Fall 2015

27

representation is determined by summing the severities of the inaccurate bumps.

Outputs The program updates the Bump table with the clustered bumps.

5.3.6. Bump Filtering Program

Purpose The purpose of the Bump Filtering Program is to update the status of a bump. This allows the system to keep track of the active bumps and ignore the inactive ones from the Road Anomaly Detection and Forewarning System in case the road anomaly got fixed. This will be done once per day.

Inputs The input of the Bump Filtering Program is all bumps and I-Packs from the previous week.

Logic The program goes through all bump locations to find the I-Packs from the same location. If these I-Packs did not have the isBump flag set to true, then in that case we consider that the bump is inactive.

Outputs The program updates the bump activity status of the bumps in the database.

5.3.7. Location Comparator

Purpose The purpose of the Location comparator is to check the closeness of a user to a bump.

Inputs The input of the Location Comparator is the I-Pack generated by the Periodic I-Pack Generator as well as all the bumps stored in the database.

Logic The Location Comparator compares the location from the I-Pack received to all bump locations in the database. If the location of the I-Pack is close by certain threshold distance, the Notifier will be activated to notify the driver of a coming road anomaly. The threshold will be determined according to the average speed of the driver.


28

Outputs The Location Comparator activates the Notifier in case the user is in the vicinity of a road anomaly.

5.3.8. Notifier

Purpose The purpose of Notifier is to send a notification to a user in case of being in the vicinity of a road anomaly.

Inputs The input to Notifier is the user driver who is to be warned.

Logic A notification with a specific string body is generated and sent to the device the user is logged into.

Outputs The output of Notifier is the notification sent to the specified user.

Fall 2015

29

5.3.9. Class Tables

Class I-Pack Attributes lat: double Latitude value of the data from GPS lng: double Longitude value of the data from GPS accuracy: float GPS accuracy in meters speed: float Speed of the car that contains the GIV box GIV_ID: int ID of the GIV box weekday_ID: int

ID of the day of the week in which the I-Pack is created

createdAt: date Date in which the I-Pack is created isBump: int 1 if the I-Pack contains bump information, 0 otherwise direction: float Direction of the moving car that contains the GIV box Methods NONE NONE

Class I-PackReceiver Attributes NONE NONE Methods ProcessPack(I-Pack)

Determines the path where the I-Pack is supposed to follow

Class BumpClustering Attributes NONE NONE Methods cluster() Removes duplicate bumps

Class TrafficAnalysis Attributes NONE NONE Methods measureAvg(I-Pack)

Compares the historical average to the current road condition

Class BumpFiltering Attributes NONE NONE Methods setStatus() Determines the activity of the bump by setting the status


30

of the bump whether it’s active or inactive

Class LocationComparator Attributes NONE NONE Methods compare(I-Pack) Compares the user’s location to the known bump locations

stored in the database

Class TrafficDisplayer Attributes NONE NONE Methods display(): JSONArray

Displays traffic information as JSONArray

Class Notifier Attributes user_id: int ID of the user body: string The body string of the notification Methods send(user_id , body)

Sends a notification to a specific user

Class CloudWaver Attributes GIV_ID: int ID of the GIV box time: date Start/End time of the journey journey_id: int ID of the journey user_id: int ID of the user command: string The function which the cloud execute Methods startJourney(GIV_ID,time) Creates a record in the journey table with

given time and GIV_ID endJourney(journey_ID,time) Updates the journey record by setting the end

date of the journey of the given journey_ID addUser(user_id, journey_id) Updates the journey record by adding the

driver of the journey of the given journey_ID

Fall 2015

31



32

Mobile Application 5.4.

5.4.1. User management Subcomponent

Purpose The user management component allows a new user to be registered in the 3arabeety system and therefore be able to login to the system. Logging in would allow the user to use the system functionalities such as viewing traffic conditions, receiving notifications about bump locations, and managing the car which includes adding or deleting users for the purpose of receiving notifications & alerts regarding the specific car a user is granted permission to.

Input Username, password, first name, last name, birthdate, phone number, email.

Logic For a new user to be registered in the system, a user inputs a username, password, first name, last name, birthdate, phone number & email. This module takes the inputs mentioned above and performs validations, which includes checking the uniqueness of the username against all existing usernames in the database, as well as “correct format” validations for the rest of the inputs. Upon the success of input field validations, the data would be communicated with the database to be stored in the “usr” table in the corresponding columns. Upon success of the insert query, the user is prompted to add a GIV box ID. For an existing user to log in to the system, the user is prompted to input his/her unique username and password. The username is checked against the existing usernames in the “username” column in the “usr” table in the database. If the inputted username exists, the inputted password is then matched with the existing password in the database. If password match is true, the user is redirected to his/her profile and is now able to use the system functionalities such as managing other users, managing the car, viewing traffic conditions,

5.4.2. Car Management Subcomponent

Purpose The car management component allows the user to add and delete new cars and that would be in the case that a user owns more than one car, hence, more than one GIV box. This component also includes managing permissions for the user’s car(s) such as granting another user permission to drive his/her car and thereby granting him access to the bump alert system.

Fall 2015

33

Input Car name, GIV box ID, and permission type.

Logic To add a new car, the user would input the car name, GIV box ID, and permission type to be stored in the database. The GIV box ID is checked for uniqueness against the existing GIV box IDs in the “giv” table in the database. If successful, the inputs are stored in the database, thus the inputted GIV box ID is associated with the current logged in username, making that username the sole “owner” of that GIV box ID. An “owner” can grant or revoke access to other users who drive his/her car. Granting access to a user only needs the “owner” user to input the username to be given access to. The username (to be given access to) and the logged in username (owner) will be communicated with the database to be stored. Of course, the “owner” user already has a GIV box ID associated to them, hence, the username (to be given access to) is able to be linked to a specific GIV box ID. For revoking access, the “owner” user needs to specify the username (to be revoked access from) and the corresponding permissions in the “usrpermissions” table is deleted. Adding a car allows the user application to receive notifications regarding the specific car they’re linked to.

5.4.3. Notification Subcomponent

Purpose To provide the user with notifications regarding imminent road anomalies.

Input Alert or a warning of imminent road anomalies received from the cloud as a push notification.

Logic The logged in username’s longitude and latitude points are constantly compared to existing bumps longitude and latitude points stored in the database. As soon as the user’s location is within the vicinity of a road anomaly, a push notification will be sent from the cloud warning him of the impending danger. However, this is not all what occurs. The speed of the user is also taken into consideration and this done for efficiency so as to know when to notify the user. For instance, if the user is driving at 100 Km/Hour and we warn him ten meters before the collision of the road anomaly, this notification will be considered useless as he will have no time to react conveniently so as to avoid the


34

anomaly. And this works the other way around as well. If the user is driving at a slow rate then it would be convenient for him/her to be warned when he is closer to the road anomaly rather than 200 meters away.

Output A notification to the user containing the distance until collision with a road bump.

5.4.4. Traffic Condition Mapping Subcomponent (MAP)

Purpose To display the traffic analysis data in the form of a colored map having the most congested streets on the map represented by the red color and the least congested as green. .

Input Traffic analysis data received from the cloud. (Location, Ration of current speed of the street over average speed)

Logic The mobile application MAP activity is constantly being updated from generated information received from the cloud. This information is in the form of three values. The latitude and the longitude that constitute for the location of the sent traffic data, and the ratio of the current speed over the average speed, which is retrieved from the historical data collected about the traffic condition of this specific location at this specific time. The application itself however, does not implement any computations. It is simply a means of displaying the traffic data in a readable or understandable format to the user. So what is constantly being done by the MAP activity is just refreshing the data every set interval of time so as to give the users a reliable source of relevant traffic information.

Output The output of the MAP subcomponent of the mobile application is the map with colored streets corresponding to the traffic conditions of the viewed streets. RED being the most congested and GREEN being the least.

5.4.5. Waver Subcomponent

Purpose Notifying the cloud that a specific user is driving a specific car to be able to activate the application (sending and receiving of data)

Fall 2015

35

Input GIV, and Current username (Username of the user actually driving that specific car corresponding to that GIV Box ID)

Logic User would send a notification in the form of a flag to be received by the cloud, which would open the connection between the user application and the cloud to start the receiving and sending of data. The user has to send a request to the cloud to be able to connect his application to the wanted GIV Box, and so be able to receive notifications relevant to the information being collected from the GIV Box that is related to the car that is being driven. However, this request will only be validated only is this user is authorized to be using this car, hence the owner has given him/her permission.

Output A signal to the cloud indicating a request to add the user to the journey record, if authorized, and is now connected to the information being generated from that specific GIV Box.


36

5.4.6. Class Tables Class LoginActivity Attributes NONE NONE Methods LogIn(username , password): boolean

Returns true and allows a user to log in to the system if the username and password were matched in the database

RecoverPassword(username) Sends email to the user with the recovered password

Class RegistrationActivity Attributes NONE NONE Methods reg(username,password,fname,lname,birthdate,email,phoneno)

Registers a user with her information to the system

Class SettingsActivity Attributes NONE NONE Methods ChangeVolume() Changes the volume of the

notification ToggleNotification() Allows the user to turn

on/off the notifications ChangePassword(oldpass,newpass,username) Allows the user to change

password

Class SingleCarActivity Attributes NONE NONE Methods Grant(username, GIV_ID) Grants permission for a user to drive a car Revoke(username, GIV_ID) Revokes permission for a user to drive a car DeleteCar() Relinquishes the ownership of a car

Fall 2015

37

Class ManageCarActivity Attributes NONE NONE Methods AddCar(username,GIV_ID) Adds a new car SelectCar(GIV_ID) Selects a car from the owned cars

Class HomeMapActivity Attributes NONE Methods ChooseCar(GIV_ID) Chooses a new car from the set of owned cars DrawOnMap() Displays the traffic information in the top of

the map

Class User Attributes username: string Username of the user password: string Password of the user fname: string First name of the user lname: string Last name of the user birthdate: date Birthdate of the user email: string Email of the user phoneno: int Phone number of the user Methods NONE

Class Car Attributes carName: string Name of the car GIV_ID: int The ID of the GIV box of the car Methods NONE


38


Fall 2015

39

6. Usability Design Approach The user application is the first point of contact for the user with our system. We decided to deploy our user app on android devices, so we had to build it with the design language of Google, Material design. So what is material design? Material Design is a design language developed by Google. It makes more liberal use of grid-based layouts, responsive animations and transitions, padding, and depth effects such as lighting and shadows. Material Design can be used in Android version 2.1 and up via the v7 AppCompat library, which is used on virtually all Android devices that were made after 2009.Material is the metaphor used in the unifying theory of a rationalized space and a system of motion. It is also grounded in tactile reality, inspired by the study of paper and ink, yet technologically advanced and open to imagination. Surfaces and edges of the material provide visual cues that are grounded in reality. The fundamentals of light, surface, and movement are key to conveying how objects move, interact, and exist in space and in relation to each other. It also helps in showing layers, divisions of space, and indicates moving parts. Now lets see how we used this design language in the development of our prototype. You will also see the simplicity of the design and how we set out to build the application as user-friendly as possible were the user is able to take an action in a maximum of three to four clicks.


40

Activity (no.1)

This activity acts as the entry phase into the application. It is an amplification of

simplicity and efficiency that would achieve the purpose of the first phase and also act as an entry into our system. The user is able to enter his user name and password to

log in to our system. He is also able to press on the forget password link to retrieve his password on the email he registered the user name with. If the user is a first time user of our system he is able to create a new account by pressing on the create account and

that will send him to activity (no.2)

Fall 2015

41

Activity (no.2)

In this activity a new user is able to create a new user account by entering his personal information. The system doesn’t require a lot of information from the user but simply his chosen user name, email, phone number, and password. To make sure that the user

enters the passwords he want he has to confirm it to avoid any spelling mistakes. After the user signs up he is sent back to activity (no.1)


42

Activity(no.3a)

After the user enters his user name and password, he is then able to access our system. And the first point of contact with his account is activity (no.3) this activity simply

holds the map that has all the traffic information that was analyzed in the cloud but in user-friendlier manner. This manner is in the form of colored road where each color

represents how crowded a road is. This visual manner helps the user take a better look at traffic information.

Fall 2015

43

Activity(no.3.a) Activity(no.3.b)

Also in this activity the user is able to choose which car he will be driving in order to receive the appropriate notifications regarding the road anomaly detection. When the user chooses the car he will be driving he will notified (activity(no.3.b)) to make sure

that he choose the right car he wishes to drive. And by clicking on the top right icon on this activity the user is able to go to

activity(no.4) where he is able to manage his account.


44

Activity(no.4a)

In this activity the user is able to manage his car. He can see all the cars that he owns and can manage. The user is able to add a new car by clicking on the action button on

the bottom right corner of the screen (activity(no.4.b))

Fall 2015

45

Activity(no.4.b) Activity(no.4.c)

By clicking on the action button the user is prompted to add a new car. The user is able to so by entering a name for the new car and the scanning the code on the GIV

box that is related to this specific car. And the he can click add. Then the car is added (activity(no.4.c)) the user is also able to click on specific car to manage this specific

car by adding new driving permeations to other users , or to relinquish car’s ownership. (activity(no.5.a))


46

Activity(no.5.a) Activity(no.5.b)

In this activity the user is able manage all the privileges that is related to this specific

car. By clicking on the action button on the bottom right of the screen he is able to add a new car or relinquish car’s ownership. He is also able to remove driving

permeation for a specific user by clicking on the delete button under each driver.

Fall 2015

47

Activity(no.5.c) Activity(no.5.d)

When the user clicks on the action button he is prompted to add the user name of the user that he wishes to give driving permissions to. After that he clicks add to add the

driver.


48

Activity(no.5.a)

After adding a new driver. The user at any time can remove the privilege that he gave to the user to drive the car by clicking on the delete button found under the drive’s name. before the user privilege is delete the owner is has to confirm the processes.

Fall 2015

49

Activity(no.6)

In this activity the user is able to manage the settings of his application and account. The user can adjust the volume of the notifications that he gets regarding the road

anomalies that are detected in his/her way. The user is also able to turn on or of the notification service. The user is also able to change the password of his account at any given time by entering his old password to confirm that he is actually the user of this

app and then he is able to enter and confirm the new password.


50

7. Requirements Traceability Matrix Requirement Done Note REQ-GIV-001 Y Merged with REQ-GIV-004 REQ-GIV-004 Y Merged with REG-GIV-001 REQ-GIV-002 Y Merged with REQ-GIV-005 REQ-GIV-005 Y Merged with REQ-GIV-002 REQ-GIV-003 Y REQ-GIV-006 Y REQ-CLP-001 N Done on-device instead REQ-CLP-002 Y REQ-CLP-003 Y REQ-CLP-004 Y REQ-CLP-005 Y Merged with REQ-CLP-010 and REQ-CLP-008 REQ-CLP-006 Y REQ-CLP-007 Y REQ-CLP-008 Merged with REQ-CLP-010 and REQ-CLP-005 REQ-CLP-009 Y REQ-CLP-010 Y Merged with REQ-CLP-008 and REQ-CLP-005 REQ-CLP-011 Y REQ-CLP-012 Y REQ-CLP-013 Y REQ-CLP-014 N Chose to handle activity instead REQ-OVR-001 Y REQ-OVR-002 Y REQ-OVR-003 Y REQ-OVR-004 Y REQ-OVR-005 Y REQ-OVR-006 Y REQ-OVR-007 Y REQ-OVR-008 Y REQ-OVR-009 Y REQ-OVR-010 Y REQ-OVR-011 Y REQ-OVR-012 Y REQ-OVR-013 Y REQ-OVR-014 Y REQ-OVR-015 Y Will be implemented in code REQ-OVR-016 Y REQ-OVR-017 Y

Fall 2015

51

8. Glossary of Terms Abbreviation Stands For API Application Program Interface AUC American University in Cairo CPU Central Processing Unit GIV Global Interfacing with the Vehicle

GPC-GIS Geographic Planning Collaborative Geographical Information Systems

GPS Global Positioning System ID Identity ITIL Information Technology Infrastructure Library MIPS Million Instructions Per Second OBS Orange Business Services PMI Project Management Institute RA Road Anomaly RADFS Road Anomaly Detection and Forewarning Subsystem SQL Structured Querying Language SRS Software Requirement Specifications SSL Secure Sockets Layer TAS Traffic Analysis Subsystem TOGAF The Open Group Architectural Framework UI User Interface UX User Experience

Fall$ 08 - American University in Cairorafea/CSCE492/Fall2015/SDD-Arabity.pdf · disassembler, a...

Documents

Transcript of Fall$ 08 - American University in Cairorafea/CSCE492/Fall2015/SDD-Arabity.pdf · disassembler, a...