Eindhoven University of Technology

OpenACCEL

Architectural Design Document

Authors:Edward Brinkmann (0720803)

Carl van Dueren den Hollander (0743652)Philippe Denissen (0719003)

Kevin de Ridder (0745581)Leo van Gansewinkel (0781263)Loc Tran (0766987)

Roel Jacobs (0767494)

Roy Stoof (0767157)Jacco Snoeren (0772658)

Project Manager:Erikos Alkalai

Quality Manager:Duc Luu

Senior Management:Lou Somers

Advisor:Erik Scheffers

Customer:Kees van Overveld

June 26, 2014

Abstract

This is the Architectural Design Document (ADD) for the OpenACCEL Software Engineer-ing Project. This document is based on the ESA standard for software development. Thearchitectural design decisions in this ADD satisfy the software requirements in the SRD [2].This document complies with the ADD from the Software Engineering Standard, as specifiedby the European Space Agency (ESA) [3].

Contents

1 Introduction 41.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 List of Definitions & Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 List of references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 System Overview 72.1 Basic Design and Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Design Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2 Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 System Context 103.1 Node & NPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.1 Implementation of the interface . . . . . . . . . . . . . . . . . . . . . . 103.2 RequireJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.1 Implementation of the interface . . . . . . . . . . . . . . . . . . . . . . 103.3 Descartes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.1 Implementation of the interface . . . . . . . . . . . . . . . . . . . . . . 113.3.2 Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3.3 Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4 Jade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.4.1 Implementation of the interface . . . . . . . . . . . . . . . . . . . . . . 11

3.5 Jison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.5.1 Implementation of the interface . . . . . . . . . . . . . . . . . . . . . . 12

3.6 JsDoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.6.1 Implementation of the interface . . . . . . . . . . . . . . . . . . . . . . 12

3.7 JQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.7.1 Implementation of the interface . . . . . . . . . . . . . . . . . . . . . . 12

3.8 MatrixJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.8.1 Implementation of the interface . . . . . . . . . . . . . . . . . . . . . . 13

3.9 SweetJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.9.1 Implementation of the interface . . . . . . . . . . . . . . . . . . . . . . 13

1

3.10 MochaJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.10.1 Implementation of the interface . . . . . . . . . . . . . . . . . . . . . . 13

4 System Design 154.1 Design Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Decomposition Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.1 List of components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2.2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2.3 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.4 Plot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.5 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.6 File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Component Descriptions 225.1 Description model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1.1 Component Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2.1 Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2.2 Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2.3 Executable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.2.4 Script Analyser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2.5 Pareto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.2.6 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2.7 Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.3 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.3.1 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.4 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.4.1 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.4.2 Plot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6 Feasibility and Resource Estimates 38

7 Requirements Traceability Matrix 407.1 SRD to ADD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.2 ADD to SRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

A Scripts 45A.1 Vertex Demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45A.2 Speed Ramp Demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2

Document Status Sheet

Document Status Overview

General

Document title: Architectural Design DocumentIdentification: ADD1.1.pdfAuthor: K.A. de Ridder, T.L. Tran, R. Stoof, R. Jacobs, E.K. Brinkmann, P.E.J.G. Denissen

C.J.P.V Dueren den Hollander, J.P.H. Snoeren, L.W.P.H.V. GansewinkelDocument status: Final

Document History

Version Date Author Reason of change

0.1 22-05-2014 K.A. de Ridder Initial version0.2 18-06-2014 K.A. de Ridder, T.L. Tran,

R. Stoof, R. Jacobs, E.K.Brinkmann, P.E.J.G. Denis-sen C.J.P.V Dueren denHollander, J.P.H. Snoeren,L.W.P.H.V. Gansewinkel

First draft version

0.3 19-06-2014 E.K. Brinkmann, T.L. Tran Second draft partially basedon feedback from advisor

0.4 20-06-2014 E.K. Brinkmann Internal review1.0 22-06-2014 E.K. Brinkmann, T.L. Tran,

R. JacobsHand-in version

1.1 26-06-2014 T.L. Tran Hand-in version

Document Change Records since previous issue

General

Date: June 26, 2014Document title: Architectural Design DocumentIdentification: ADD1.1.pdf

Changes

Page Paragraph Changes38 6 Changed response times.

3

Chapter 1

Introduction

1.1 Purpose

The Architectural Design Document (ADD) describes the basic design of the software that willbe made by group OpenACCEL. This document describes the decomposition of the softwareinto components. Then, for each component it describes the relation to external interfacesand the dependencies on other components.

1.2 Scope

OpenACCEL is a web-based application designed and developed by group OpenACCEL forKees van Overveld at the Eindhoven University of Technology. The application is designed toaid students to get an understanding how to model with secondary educational mathematicalknowledge.

1.3 List of Definitions & Abbreviations

1.3.1 Definitions

ACCEL A web-based modeling application which is currently hosted at [4]OpenACCEL The new and improved application which will be developed by team

OpenACCEL, based on ACCELBachelor College The new format of Bachelor education introduced by the TU/e in

2012RequireJS A JavaScript file and module loader that is optimized for in-browser

use.Sweet.js A macro expander written in JavaScript, that expands user-defined

macros into JavaScript.Bison A general-purpose parser generator.Jison A JavaScript parser generator with Bison’s API.Jade A HTML Templating engine written in JavaScript.

1.3.2 Abbreviations

4

ADD Architectural Design DocumentSRD Software Requirements DocumentTU/e Eindhoven University of TechnologyURL Uniform Resource Locator

1.4 List of references

[1] OpenACCEL, User Requirements Document (URD), version 1.4, May 2014.

[2] OpenACCEL, Software Requirements Document (SRD), version 1.0, June 2014.

[3] ESA PSS-05-0 Issue 2, Software requirements and architecture engineering process, Febru-ary 1991.

[4] http://www.keesvanoverveld.com/Accel/accel.htm

[5] http://nodejs.org/

[6] https://www.npmjs.org/

[7] http://jade-lang.com/

[8] http://jade-lang.com/reference/

[9] http://zaach.github.io/jison/

[10] http://zaach.github.io/jison/docs/#specifying-a-language

[11] http://dinosaur.compilertools.net/bison/

[12] http://usejsdoc.org/

[13] http://jquery.com/

[14] http://requirejs.org

[15] https://github.com/amdjs/amdjs-api/blob/master/AMD.md

[16] http://www.cs.bham.ac.uk/~pxc/web/jslib/index.html#Matrix

[17] http://sweetjs.org/

[18] http://visionmedia.github.io/mocha/

[19] http://en.wikipedia.org/wiki/XUnit

[20] W3 Web Storage specification, http://www.w3.org/TR/webstorage/

#the-localstorage-attribute

[21] W3 Web Workers specification, http://www.w3.org/TR/workers/

5

1.5 Overview

The remainder of this document is structured as follows. Chapter 2 contains and overviewof the system and the design decisions made, including their motivation. Chapter 3 coversthe system context in which the relationship with each external system is explained. Next,chapter 4 treats the system design and lists all design methods used. Furthermore an overviewof components is given here. These components are discussed in further detail in Chapter5. Chapter 6 covers the feasibility and resource estimates of OpenACCEL and lastly therequirements traceability matrix is given in chapter 7, linking parts of the architectural designdocumented in Chapter 5 to specific software requirements in the SRD [2].

6

Chapter 2

System Overview

For a description of OpenACCEL, see the User Requirements Document (URD) [1]. For adescription of the relevant background of OpenACCEL and the environment in which thesystem will operate, see sections 2.3 and 2.4 of the Software Requirements Document (SRD)[2] and section 2.5 of the URD [1]. OpenACCEL is a web-based application and is mostly selfcontained. OpenACCEL requires several external libraries, which will be discussed in chapter3.

2.1 Basic Design and Context

OpenACCEL runs locally in the webbrowser of the user. The files needed to run OpenACCELare stored on a webserver and these files are retrieved by the user’s webbrowser through theinternet. After the files are received, OpenACCEL runs independently of the websever. Theonly communication between the browser and the webserver that remains is the retrieval ofdemo-script from the webserver. This has the advantage that it reduces the trafic betweenthe user and the webserver, and since the web server does not have to run the application,the load on the server remains low. Also, because OpenACCEL runs locally, if the internetconnection may drop, the user can continue using the application, so his script is not lost.

The basic overview of the system can be found in figure 2.1.

Figure 2.1: Overview of OpenACCEL context

2.2 Design Decisions

2.2.1 Architecture

The components of OpenACCEL follow the Model-View-Controller (MVC) architecture. Thethree major components, Model, View and Controller have different responsibilities. The

7

Model is responsible for defining the information that the program will use. This informationis displayed by the View. The Controller is repsonsible for managing the control flow betweenthe model and the view. The subdivision in those three components ensures that the programis built-up in a modular fashion.

Figure 2.2: Model-View-Controller.

The dependencies between the model, view and controller components in OpenACCELare shown in figure 2.2. As you can clearly see the model and view components are entirelyseparate, they do not directly depend on each other. Instead, they are both dependent on thecontroller, which acts as a black box for both the model and view. Furthermore, the controlleruses an abstract interface for the view which means that the view can be easily changed aslong as it adheres to that interface. So actually, the controller only depends upon the abstractview interface and not on the rest of the actual view component. This is indicated by thedotted arrow from the controller to the view.

An alternative to using a controller would be to define and keep track of an explicit internalstate-machine, and actions in the program result in transitions leading to a new state. Thesestate transitions would then define the flow of the program. The downside of this methodis that such a state-machine becomes very complex very quickly, and that each componentmust be completely aware of each state and all allowed transitions in those states. This makesmaking changes much harder.

2.2.2 Compiler

When you look at the ACCEL language, the first thing that you’ll notice is that not only are alllines mostly pure mathematical expressions, but they also look very similar to the JavaScriptlanguage. In fact, one could even argue that ACCEL is a kind of subset of JavaScript, withsome added syntactical sugar. In the current implementation of ACCEL [4], the language iscompiled and executed using a custom made lexer, parser and runtime environment. However,because of the similarities between ACCEL and JavaScript, it was decided for OpenACCELthat instead of creating a custom lexer, parser and runtime environment, we’d compile AC-CEL code to native JavaScript and run it directly into the native runtime environment ofthe browser. Because of this there is minimal overhead, which will result in a performanceimprovement in comparison to the current ACCEL implementation. It would also imply thatwe could implement most functionality as simple library functions, which again are pure na-tive JavaScript functions and thus have minimal overhead.

8

With a simple pre-processor, ACCEL code could be translated to valid JavaScript, which wasalmost runnable. The pre-processor would wrap certain ACCEL constructs around macros,which would be expanded into valid JavaScript code. Take for example a simple line ofACCEL:

x = 5

By using Sweet [17], you could translate this into a piece of JavaScript that would turn itinto a function, returning the correct value:

function x() { return 5; }

However, for Sweet to detect a line of ACCEL script and expand it, a bit of pre-processingwas needed. Before x = 5 could be expanded, it had to be pre-processed into the line:

func(x = 5)

The final output could then be evaluated to create a pure and native JavaScript object, onethat could execute the script.

At first, this pre-processor and Sweet combination seemed like a good plan and was workingquite nicely. However, as OpenACCEL had to support more and more functionality, such asnamed vectors, we ran into more and more special cases that would break the entire com-piler. The simple pre-processor that was in our minds, was no longer simple. After a bit ofresearch and experimentation, it was decided to replace our custom-made pre-processor witha parser generated by the Jison software library [9]. The Jison parser would have the samepurpose as the pre-processor, but was now based on a proper context-free grammar. Thiswould eliminate most if not all of the special cases.

As a bonus, this enabled OpenACCEL to have robust syntax checking capabilities whichwere based directly upon the definition of this grammar. By using Jison, OpenACCEL wouldnow have a proper foundation for its compiler, while still being fairly simple. Finally, Ji-son could potentially take over all functionality of Sweet, but it was decided not to delegateSweet’s tasks in order to preserve the simplicity and maintability that the Sweet macros offer.

9

Chapter 3

System Context

This chapter describes the connections that OpenACCEL has with external systems. Ope-nACCEL does not depend on any external interfaces. However, it does make use of severalexternal libraries. These libraries will be discussed in the following sections.

3.1 Node & NPM

Node.js [5] is a platform built on Chrome’s JavaScript runtime for easily building fast, scal-able network applications. Node.js uses an event-driven, non-blocking I/O model that makesit lightweight and efficient, perfect for data-intensive real-time applications that run acrossdistributed devices [5].

NPM [6] is the package manager for the Node JavaScript platform. It puts modules in placeso that node can find them, and manages dependency conflicts intelligently. It is extremelyconfigurable to support a wide variety of use cases. Most commonly, it is used to publish,discover, install, and develop node programs.

3.1.1 Implementation of the interface

We use Node and NPM for building, testing, and the installation and updating of our depen-dencies. Everything is defined inside a single package.json file in the root project folder.This file configures the project, in such way that deploying, testing and installing / updatingis as easy as running a single command.

3.2 RequireJS

RequireJS [14] is an asynchronous file and module loader for Javascript. It uses the Asyn-chronous Module Definition (AMD) [15] API which enables you to define modules and theirdependencies and load them at runtime when needed. Splitting your javascript code intoseparate modules improves the overall architecture of your application.

3.2.1 Implementation of the interface

Every class in OpenACCEL is defined in a separate module by encapsulating it into a functionthat returns the class object no sooner than after all of it’s dependencies have been loaded.

10

Each class lists all the classes on which it depends at the top of it’s module file. When runningthe application, modules (classes) are loaded into memory asynchronously when they are firstrequired by another module.

3.3 Descartes

Descartes is an external library native to ACCEL. It is developed by the customer and allowsvisualisation of scripts written in the ACCEL language. Descartes requires two additionallibraries, canvastextJS and cloneJS. These two libraries are used to handle drawing text on acanvas and to clone objects that are drawn on the canvas. These are only used internally byDescartes and will not be described in further detail here.

3.3.1 Implementation of the interface

All Descartes files (canvastext.js, clone.js, descartes.js) are placed inside the designated graph-ics folder. To interface with Descartes, a graphics component has been created. Refer to figure3.1 for the class diagram of the graphics component. In the following subsections these com-ponents are described in more detail.

3.3.2 Canvas

Naturally, Descartes will need a canvas to draw the objects on. The canvas is created by thecanvas creator. It creates the canvas and assigns an appropriate descartes handler to it usingthe descartes handler factory. The descartes handler factory determines which of the decarteshandlers should be used.

3.3.3 Handler

The handler is used for interfacing with Descartes. It transforms objects retrieved from themodel, such as plot functions, into input that descartes can handle. In the current system,we are able to render plot functions in scripts and to plot individuals from Pareto. Thehandler passes the objects to Descartes and Descartes will draw these objects onto the canvas.Descartes allows for interaction with the canvas. The handler is able to catch these eventsand handle them accordingly.

3.4 Jade

Jade [7] is a templating engine that compiles template files to HTML code. The reason thatthis library is being used, is that it gives the possibility to create seperate files for differenttabs. This gives the possibility to add tabs to (and thus extend) the website itself in a clearand modular way. Jade has its own syntax which is easy to read and fairly concise. A detaileddescription of it’s syntax is available at [8]

3.4.1 Implementation of the interface

All Jade files are placed inside the designated folder for the view component. The buildscriptthen finds those files and outputs a single HTML file which will be the main webpage ofOpenACCEL.

11

3.5 Jison

Parsers help computers derive meaning from arbitrary text. Jison [9] helps you build parsers.Jison is essentially a clone of the parser generator Bison [11] (thus Yacc), written in JavaScript.It includes its own lexical analyser modeled after Flex. Jison takes Jison grammar files asinput and outputs a parser that can process strings that conform to the defined language.The format of Jison grammar files is described in detail at [10]

3.5.1 Implementation of the interface

A single grammar file, ACCEL.jison, is created that defines the grammar of the ACCELlanguage. This file is used as input to Jison which generates a parser that accepts andpreprocesses ACCEL code. This ACCEL parser is generated when building the project andis included by the modules that use it at runtime.

3.6 JsDoc

JSDoc 3 [12] is an API documentation generator for JavaScript, similar to JavaDoc or PH-PDoc. You add documentation comments directly to your source code, right alongside thecode itself. The JSDoc Tool will scan your source code and generate a complete HTML doc-umentation website for you. JSDoc parses tags starting with @ from comments in the sourcecode and deduces the meaning of the comment strings from it. A list of all supported tagsand comments formats can be found at the website of JSDoc [12].

3.6.1 Implementation of the interface

During development, the source code will be properly documented using comments in theright format. Upon building OpenACCEL, JsDoc will be automatically invoked using NPMto generate the documentation of all files in the src/ directory. The documentation itselfwill be placed inside a folder called doc/. JsDoc outputs its generated documentation as a’website’, thus the documentation can be viewed by opening index.html in your favouritebrowser.

3.7 JQuery

jQuery [13] is a fast, small, and feature-rich JavaScript library. It makes things like HTMLdocument traversal and manipulation, event handling, animation and Ajax a lot simplerand sports an easy-to-use API that works in a multitude of browsers. With a combinationof versatility and extensibility, jQuery has changed the way that millions of people writeJavaScript.

3.7.1 Implementation of the interface

JQuery is implemented in the code as if it were just another dependency or class that can beimported using RequireJS (see section 3.2).

12

3.8 MatrixJS

Matrix.js [16] is a JavaScript utility library for working with (mathematical) matrices. Itprovides methods for performing all common mathematical operations on matrices.

3.8.1 Implementation of the interface

This matrix library is loaded as part of the OpenACCEL library so it can be used by alllibrary functions.

3.9 SweetJS

Sweet.js [17] brings the hygienic macros of languages like Scheme and Rust to JavaScript.Macros allow you to sweeten the syntax of JavaScript and craft the language youve alwayswanted.

3.9.1 Implementation of the interface

Sweet is implemented in a class called MacroExpander, such that it works in browsers as well aswithin the Node environment. Once you have instantiated an instance of the MacroExpander

class, you can compile JavaScript with Sweet macros as if it were just a normal compilationprocess; with a single MacroExpander.compile(myCode) invocation. Macros are used withinOpenACCEL to replace pieces of ACCEL script with executable javascript.

3.10 MochaJS

Mocha [18] is a feature-rich JavaScript test framework running on node.js and the browser,making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexibleand accurate reporting, while mapping uncaught exceptions to the correct test cases.

3.10.1 Implementation of the interface

All test files are to be placed inside the test/ folder. Test cases are to be written in thexUnit [19] format. If you want to test all files in the test folder, you simply have to invokethe npm test command. If you want to test a specific file, like for example all tests in the filemyTests.js, you’d invoke the test command with an additional argument and execute thetest script directly (without NPM): build/build.sh --test myTests.

13

Figure 3.1: Class diagram of the descartes interface

14

Chapter 4

System Design

This chapter describes the technical aspects of the design of OpenACCEL.

4.1 Design Method

OpenACCEL is implemented as a web application build on JavaScript. It makes use of vari-ous libraries like RequireJS, Sweet and Jison in order to simplify the code of the application.OpenACCEL makes use of various component modules. These modules are made with thedesign method Model-View-Controller (MVC) in mind. MVC is used in order to distinguishbetween the three major components; the Model, the View and the Controller. Each compo-nent has distinct responsibilities. This enables one to implement the system in a controlledand modular manner.

Chapter 4.2 describes the decomposition of OpenACCEL into components together withtheir dependencies.

4.2 Decomposition Description

The decomposition of OpenACCEL into components is based on the requirements in the URD[1] and SRD [2]. Section 4.2.1 gives a list of all components, all of which are described indetail in chapter 5.

4.2.1 List of components

• Model

– Script

– Compiler

– Executable

– Script Analyser

– Analysis

– Network

– Pareto

15

– Storage

– Error

• View

– Layout

– Tabs

– Plot

• Controller

4.2.2 Model

Figure 4.1: Dependencies between ’Model’ modules.

The model section of OpenACCEL can be divided into three main categories, or sub-modules in other words. Namely, the compiler, the script and the analyser. The connectingpiece of these three sub-modules, is the executable, as can be seen in figure 4.1. The executableis a native JavaScript object that contains the functionality to execute and iterate throughan ACCEL script. This executable is created by the compiler in a four-step process which isdepicted in figure 4.2.

Script

The script component is the datastructure that represents the ACCEL script currently beingconstructed by the user. In general, it is the main component that connects the ACCELscript with the compiler and the analyser and is the main provider of information about the(quantities in the) script.

Compiler

In a brief overview, the compiler first loads the files that are needed in order to construct theexecutable, namely the OpenACCEL function library and macros. The compiler then takes

16

Figure 4.2: Compilation process.

an ACCEL script as input and puts it through the Jison parser. This parser will translatethe ACCEL script into almost valid JavaScript. The only thing left to do at that point is toexpand a set of Sweet macros, as generated by the Jison parser. These macros are expandedinto JavaScript, such that our final output can be evaluated with JavaScript’s eval functionin the native runtime environment of the browser. These macros are there in order to delegatesome complexity from the parser to a different component, which increases modularity andsimplicity. When the generated code is evaluated a JavaScript object is created that has allof the functionality needed to execute the script.

Executable

The executable is a native javascript object that contains the functionality to execute anACCEL script. Each quantity gets compiled into a function call, whose invocation will returnthe value of that quantity at that time. In addition, each time-dependent quantity alsocontains an array in which its value over time is recorded. While not neccesary, an executablemay contain a report such that it can optimise the retrieval of quantity values.

Script Analyser

The analyser performs an analysis of the script source as entered by the user. It extracts allproperties of the quantities defined in the script and stores them in the datastructures withinthe Script component. These properties are things like the name and definition of quantities,their dependencies, whether they are time-dependent or not and to which category theybelong.

Analysis

The analysis contains three sub-components. The analysis component detects the dependen-cies between the various quantities and is able to plot the relative values of these quantities.

Network

The network component visualises the dependencies between the quantities in the script in agraph and allows for inspection of this graph by the user.

17

Pareto

The pareto component contains various classes for a genetic optimisation algorithm. Thegenetic optimisation accepts a script as input and extracts the information it needs. Onceinitialised, it will try to find optima for all quantities the user indicated, either a maximum ora minimum. It does this by generating individuals that contain all the information needed.Every generation individuals can mate and/or mutate and the pareto front is determined.This front consists of the individuals that are not dominated by others. The individuals inthe pareto front are deemed optimal and they will be carried over to the next generation.

Next, we give a more detailed overview of our implementation of the algorithm. First, weinitialize our population by choosing random values for the category I-quantities. To deter-mine which individuals are on the Pareto front, we need to define when an individual is betterthan another individual. One individual dominates another individual when it has a bettervalue for all the category II-quantities. One value being better than another one depends onwhether we would like to maximize or minimize the category II- quantity.

We generate new generations by adapting the current generation in different ways. Firstwe select the individuals that we would like to reproduce. The chosen individuals are put intothe mating pool. We fill the mating pool as follows: We take two random individuals fromthe current population and keep the one which dominates more individuals. The other oneis removed from the population. We repeat this process until the mating pool has the samesize as the population.

Now that our mating pool is determined, we are going to reproduce. Two individuals fromthis mating pool are chosen randomly. These individuals breed two children. For each cat-egory I-quantity, the value of the child is chosen randomly from one of both parents. Theother child receives the value of the other parent, so the first child is a complement of theother child. The parents are deleted from the population once they are reproduced.

Finally, we perform some mutations on our children. We have various heuristics for thisprocess. The first heuristic is simply generating a completely new random individual. Thesecond heuristic, the arbitrary mutation, mutates one of the category I- quantities and givesit a random value. Finally, the close mutation generates an individual which is close to theoriginal individual.

After all these operations have been performed, we have mimicked part of the evolutionand can determine the new Pareto front. Maybe we have made no progress and the Paretofront is still the same, but if we are lucky we have found a new individual which is betterthan the previous one

Storage

The storage component contains functionality to store and retrieve scripts locally as well ason a remote server or other device. It is used both to save the script locally as a backup andload demo scripts from the server.

18

Error

The error component contains various classes representing the different kinds of errors thatcan occur in the system. These can be instantiated and thrown by any other class in thesystem. Because of this, a lot of modules depend upon the Error module.

4.2.3 View

The view section can be described very briefly. With the help of Jade, a single layout file willbe created. This single layout file then loads different tabs and creates a controller instance.Each tab is almost completely separate from all other tabs, and interfaces through the singlecontroller instance. All user input will be handled by the view component and propagated tothe controller, which will in turn return a response.

4.2.4 Plot

The plot component contains the functionality used to draw objects onto the view and isdirectly linked to the external library Descartes. It is used for plotting plot functions definedin a script. Moreover, the plot component is used by the analysis, pareto and networkcomponents for drawing their objects.

4.2.5 Controller

The controller is the connecting component between the model and the view. It is a blackbox to both the model and the view and acts as a representative of the other party to bothcomponents. In it’s methods it uses the functionality provided by the classes in the modelcomponent to orchestrate the bigger tasks it is responsible for, which are often initiated bythe view. Because the controller is a black box to both the model and the view it has verydiverse responsibilities: see section 5.3.1 for a list of all the functionality it provides. One ofthe most important tasks of the Controller is managing execution of the script. This task isdescribed in detail in the following 2 paragraphs.

Starting execution of script

When the controller is requested to start script execution, it first checks whether the script isnot already executing and whether it is already compiled. If the script is not compiled alreadyit is compiled then. Next, the controller checks whether the script has already completed thefinal execution iteration of the script and has stopped, and if so, resets the executable tobegin at iteration 1 again. Finally the runloop is started. See figure 4.3 for a flowchart of thisprocess.

Runloop

The control flow of executing the model is as depicted in figure 4.4. This is a single iterationof the loop, which is executed every x milliseconds. First, some checking is done to ensurethat the script is still being executed (no request to stop has been received since last iteration)and is compiled. Next the controller checks whether the last iteration has been completed,and if it has it aborts the runloop and stops script execution.

19

Figure 4.3: The process of starting script execution

After these checks, all output quantities are evaluated and the results are given to the view.Lastly the plot is rendered and updated in the view.

Figure 4.4: One iteration of the runloop

20

4.2.6 File Structure

/

build/ Build scripts.

build.sh Build SH script.

lib/ Additional non-NPM libraries.

jquery-ui.js JQuery UI library.

text.js Sweet.js dependency.

prepost/ PrePost support files for JsDoc.

src/ Source Files.

controller/

AbstractView.js Controller view dependency.

ControllerAPI.js Contains main controller class.

model/

analyser/ Script analyser.

passes/

analyzerpass.js

dependencypass.js

pass.js Abstract pass class.

quantitypass.js

analyser.js Main analyser class

datastores/

documentation/ Documentation submodule.

exceptions/

library/ Contains library functions

macros/ Contains sweet macros.

network/ Contains network submodule.

edge.js

network.js

node.js

analysis.js Analyses report struct.

compiler.js Main compiler class.

fileloader.js Utility class for fileloading.

macroexpander.js Class that expands sweet macros.

quantity.js Quantity data structure.

reservedwords.js OpenACCEL reserved words list.

script.js Contains main script class.

view/

namespaces.js JsDoc namespace info.

template.js Example class source file.

test/ Test Files.

utils/ Various uncategorized utility files.

README.md Short introduction to OpenACCEL.

package.json NPM configuration file.

21

Chapter 5

Component Descriptions

In this chapter the components of the previous chapter of OpenACCEL are described. Refer-ences to relevant user requirements and software requirements are given for each component.The Analysis and the Network components have not been implemented, and thus will not bedescribed in this chapter.

5.1 Description model

In this section components which are described are specified. For each component its iden-tifier, type, purpose, function, subordinates, dependencies, interfaces, resources, references,processing and data is given.

5.1.1 Component Identifier

The component identifier gives a unique identifier to a component.

Type

The type of a component.

Purpose

The purpose of a component is about the software requirements implemented. Some softwarerequirements are implemented by multiple components. In this case the purpose of eachcomponent that contributes to its implementation is included. The software requirements arestated in the SRD [2].

Function

The function of a component is a description of what the component does.

Subordinates

The subordinates of a component are sub-modules included within this top-level module.

22

Dependencies

The dependencies of a component consists of the components to be executed before or after,and included operations during execution.

Interfaces

A description of the interface that this component provides. In other words, the functionalitythat it offers.

Processing

A description of the internal control and data flow of the component

Data

The data section gives a description of the internal data of a component.

5.2 Model

5.2.1 Script

Component Identifier

Script

Type

Model component

Purpose

The Script component implements the following software requirements:SCR32, 33, 34 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 131, 132,133, 134, 135, 137, 138

Function

The Script component is responsible for keeping track of the state of the script provided bythe user. It manages quantities defined by the user, and keeps track of the current sourcecode, and the compiled executable code of the script.

Subordinates

This component has the following child modules:

• Quantity

23

Dependencies

The script component depends on the following components:

• Script Analyser

• Error

• Executable

Interfaces

The script component provides an interface to:

• add, remove and redefine quantities

• query the current value of a quantity in the current execution state of the script

• update values of user input quantities at runtime

Processing

When a quantity definition is added to the script, or when it is redefined, first the syntax ofthe definition is checked. After that, the definition is passed to the Script Analyser to extractthe relevant information for the quantity, and the list of quantities of the script is updated.

When a quantity is removed from the script, first all the dependencies of other quantitiesare updated. When there is no longer a quantity dependent on this quantity, the quantity isremoved, otherwise, it is marked as To Do.

When the value of a quantity is requested, the script retrieves the current value from theexecutable if it has already been compiled.When the value of a user input quantity is set, the script sets the new value of that quantityin the executable if it has been compiled.

Data

In the script component, information about quantity definitions of an ACCEL script is storedin a Quantity-object for each quantity. The following information is stored for each quantity:

• Name of the Quantity

• Its definition from the ACCEL script

• Other quantities this quantity depends on

• Other quantities depending on this quantity

• The Category (1, 2, 3 or 4)

• The unit of the quantity

24

• If the quantity is a function: its parameters

• Comment-lines defined in the ACCEL script for this quantity

• Whether the quantity is still To Do (a definition still has to be given)

• Whether the quantity’s value depends on time

• If the quantity is defined by user-input (such as a slider): the type of input and theparameters.

5.2.2 Compiler

Component Identifier

Compiler

Type

Model component

Purpose

The Compiler component implements the following software requirements:SCR54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 131, 132, 133, 134,135, 137, 138

Function

The compiler component is responsible for generating executable Javascript code from a givenACCEL script.

Subordinates

This component includes the following child modules:

• File Loader

• Functions library

• Parser

• Macro Expander

Dependencies

This component depends on the following components:

• Script

• Executable

• Error

25

Interfaces

The compiler component provides an interface to translate a piece of ACCEL code intojavascript code. It produces an Executable object, which contains functions to execute thescript and to query the values of the defined quantities.

Processing

The internal flow of the compiler is described in section 4.2.2.

Data

The compiler holds an instance of the FileLoader, MacroExpander and Parser. These threekey sub-modules are the heart of the compiler.

5.2.3 Executable

Component Identifier

Executable

Type

Model component

Purpose

The Executable component implements the following software requirements:SCR60, 86, 87, 88, 130, 131, 132, 133, 134, 135, 137, 138

Function

The executable is a JavaScript object that contains all functionality to execute an ACCELscript. In other words, it allows the calculation of quantity values and time iteration. It alsokeeps track of the previous values.

Subordinates

This component does not have any child components.

Dependencies

• Error

Interfaces

The Executable component provides an interface to:

• Get the current and historic values of quantities

• Update the values of user input quantities, including mouse position and state

• Advance/reset execution time

26

Processing

After an ACCEL script has been parsed and been macro-expanded, the resulting code getsevaluated by JavaScript’s eval() function. The evaluated code will dynamically extend theExecutable class, such that it is able to execute the model.

Data

The Executable contains for each quantity a method to calculate it’s value, which containsthe Javascript code equivalent of the quantity’s definition in ACCEL code.

5.2.4 Script Analyser

Component Identifier

Script Analyser

Type

Model component

Purpose

The Script Analyser component implements the following software requirements: SCR73, 74,75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 131, 132, 133, 134, 135, 137, 138

Function

The Script Analyser is responsible for extracting information about quantities from the quan-tity definitions in an ACCEL script.

Subordinates

The Script Analyser component is build up out of analyser-passes. Each pass is responsiblefor extracting a different kind of information about quantities from ACCEL scripts. Eachpass incrementally adds information to a report.

Dependencies

This component has no dependencies on other modules

Interfaces

The Script Analyser component provides an interface to:

• Analyse a given piece of ACCEL script, adding information to the report passed to theanalyser.

• Determine the category of quantities and get all quantities belonging to a certain cate-gory

27

Processing

The internal processing of the Script Analyser is done by a set of analyser passes, which followa pipeline-architecture. This means that the output of one pass is the input for the next. Eachpass takes an ACCEL-script and an (incomplete) quantity-report, and each pass will extract adifferent kind of information from the script and add it to the report. For example, one passmay determine the name, while another determines the dependencies between quantities.The passes leave the script code unchanged, only information is extracted. A graphicalrepresentation of the process can be found in figure 5.1.

Figure 5.1: Script Analyser process

Data

The analyser holds an array of passes that together form the pipeline. It also holds a parti-tioning of all quantities in the script into the different quantity categories.

5.2.5 Pareto

Component Identifier

Pareto

Type

Model component

Purpose

The Pareto component implements the following software requirements: SCR104, 105, 106,107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 131, 132, 133, 134, 135,137, 138

Function

The Pareto component makes an attempt to find optimal values for category II- quantities bymodifying the values for category I- quantities in the script. It does so by using the methodof genetic optimization. Genetic optimization aims to mimic the process of evolution in thereal world. In a broad sense, it produces generations in various ways which represent evolu-tionary selection, reproduction and mutation. While the population continues to change, wekeep track of ’good’ individuals. An individual is ’good’ if there is no other individual in thepopulation which is better. The set of ’good’ individuals in a certain population is referredto as the Pareto front of that population.

28

Subordinates

This component consists of the following subordinates:

• Genetic Optimisation

• Individual

• Cross-Over

– Uniform Cross-Over

• Mutation

– Close Mutation

– Arbitrary Mutation

– Random Mutation

• Tournament

– Binary Tournament

Dependencies

This component depends on the following components:

• Controller

• Script

• Executable

• Descartes

• Error

Interfaces

The controller component initialises the genetic optimisation component by passing a script.When a new generation needs to be calculated, it receives a request from the controller andwhen it is done the descartes module can extract the information needed to plot the result.

Processing

The internal control of the Pareto component follows the structure of the algorithm as ex-plained in section 5.2.5. First the population is initialized. Then the individual steps of thealgorithm are performed (binary tournament, crossover and mutations) and the Pareto frontis calculated again. The population is stored in the Pareto component and passed to eachstep in the algorithm. The Pareto front is updated after each generation is calculated.

29

Data

The data that is stored in the Pareto component consists of the current population and thePareto Front.

5.2.6 Storage

Component Identifier

Storage

Type

Model component

Purpose

The Storage component implements the following software requirements:131, 132, 133, 134, 135, 137, 138

Function

The Storage component provides the means to save scripts to and load scripts from differentkinds of storage. This can be both locally and on another device or server.

Subordinates

This component has the following child modules:

• LocalBackupStore: for storing scrips in localStorage [20] for backup purposes

• AbstractScriptStore

– ServerScriptStore: for submitting scripts to and loading scripts from a server

Dependencies

The Storage component depends on the following components:

• Error

Interfaces

The Storage component provides an interface to:

• Individual quantities

– Store, retrieve and delete individual quantities to/from storage

– Query a store about the quantities that it contains

• Whole scripts

– Load whole scripts from and store them to storage

– Query a store about the scripts that it contains

30

Processing

When storing quantities to and loading them from localStorage, an index of the quantities inthe store is kept and updated. This index is used to return a list of all quantities in the storeand to check whether a certain quantity is present in the store. Individual quantity namesand their definitions are stored as key-value pairs.

When loading scripts from a server store, the server is first queried for a list of quanti-ties that it has and subsequently the Storage component requests the individual script fromthe server that the user wants to load. It then returns the source code of this script to theScript module, from which a new Script is constructed.

Data

The Storage component does not store any data internally but only loads data from andstores data on external data stores.

5.2.7 Error

Component Identifier

Error

Type

Model component.

Purpose

The Error component implements the following software requirements: SCR59, 131, 132, 133,134, 135, 137, 138

Function

The Error component is responsible for propagating various error messages that can occur inOpenACCEL to the controller. It handles three types of errors.

• Network errors

• Syntax errors

• Runtime errors

Subordinates

This component has a child module for each type of error mentioned in section 5.2.7.

Dependencies

The Error component has no dependencies on other components.

31

Interfaces

The Error component provides an interface to define and throw:

• Network errors

• Syntax errors

• Runtime errors

Processing

The Error component has no internal processing.

Data

The Error component holds the information about the Errors being thrown.

5.3 Controller

5.3.1 Controller

Component Identifier

Controller

Type

Controller component

Purpose

The Controller component implements the following software requirements:SCR3, 12, 13, 31, 86, 87, 88, 89, 90, 91, 92, 93, 94, 125, 126, 127, 128, 129, 131, 132, 133,134, 135, 137, 138, 139

Function

The Controller is responsible for handling the communication between the Model and theView. It provides all the functionality that either of them need, acting as a black-box interfaceto the other component.

Subordinates

This component has no child modules.

32

Dependencies

The controller component depends on the following components:

• View

• Script

• Compiler

• Storage

• Error

Interfaces

The Controller component provides an interface to:

• Create new scripts, load scripts (from storage or server), set source code of scripts

• Add, remove and redefine quantities of Script

• Control script execution (run, pause, stop, set number of iterations that should beexecuted, compile Script)

• Query current application/execution state

• Query the current value of quantities during script execution

• Set the current value of user input quantities

• Get the source code of the script

• Plot graphics in Descartes canvas

• Control SPEA genetic optimization algorithm: initialise, create new generations etcetera

• Application Configuration

– Set whether the script should be automatically executed as soon as it is complete

– Set whether the script should be automatically backed-up to localStorage [20] whenmodified

– Set whether the application should use Web Workers [21] when available

Processing

A lot of the processing that the controller performs in its methods is delegated to classes inthe Model component and are detailed in the corresponding component interface sections.

Additionally, for diagrams depicting the process of adding and removing quantities, see sec-tion 2.7.3 paragraphs 1 and 2 of the SRD [2].

For a flow chart detailing the process of starting script execution, see section 4.2.5. Fora flow chart depicting how the iterative execution of the script inside the runloop works, seesection 4.2.5.

33

Data

The internal data of the controller can be divided into three different parts: core applicationobjects, state variables and configuration parameters.

The core application objects that the controller contains are:

• The Compiler

• The Script

• The View

• The Backup Store

The state variables of the controller are:

• The current execution iteration

• The number of iterations that should be executed

• Current execution state (running, stopped, paused)

The configuration parameters in the controller are:

• Whether the Script should be autosaved when changed

• Whether to automatically execute the script as soon as it has been compiled.

• Whether to use Web Workers

5.4 View

5.4.1 View

Component Identifier

View

Type

View component

Purpose

The view component implements the following software requirements:SCR1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27,28, 29, 30, 31, 95, 96, 124, 131, 132, 133, 134, 135, 137, 136, 138, 139

34

Function

In short, the function of the view component of OpenACCEL is to present the user withtools to manipulate and analyse ACCEL scripts. Internally it both receives data from thecontroller to be displayed in a specific format and it sends data to the controller which wasinput by the user.

Module functionsThe view component contains a main module, it directly or indirectly initiates all componentsof the application. This component also has a module known as view to the controller whichallows communication in a predefined manner from the controller to the view. Lastly all tabsthat are to be implemented will have modules with functionality to handle user input andpresent output to the user.

Subordinates

This component has the following child modules:

• Main

• View

• Tab specific modules

– Intro

– Edit / Run script

– Help / Demo

– IO / Edit

– Analysis

– Genetic Optimisation

– Simulation

– Network

Dependencies

The view component depends on the following components:

• Controller

• AbstractView

• Error

35

Interfaces

The view component provides an interface for the controller to:

• Send a list of existing quantities

• Force updates of the results

• Setup, show and update the graphics canvas

• Send information on the status of the model

Processing

Main The starting point for the application initializes the controller and the connectionbetween these the view and the controller. It will also initiate a restore of the previouslyloaded script and set any controller contained variables to match the intended functionality.For instance, it will set the variable that determines whether a script will be automaticallyexecuted.

View The view module should be an implementation of an abstract class provided by thecontroller and should in turn provide a working interface for the controller to send data to.The controller can call on functionality provided by the view module. It will in turn call onthe appropriate functionality, as provided in the tab specific modules.

Tabs The tab specific modules provide functionality to alter the content of the User Interfacein each modules associated tab. They also contain functionality to be called on by the userfrom the browser, these calls will often be delegated to the controller component.

Data

The view component’s data will mostly be stored in the produced HTML but some interme-diary data structures may be used to optimize the performance of the component.

5.4.2 Plot

Component Identifier

Plot

Type

View component

Purpose

The Plot component implements the following software requirements: SCR16, 25, 26, 28, 29,98, 99, 100, 101, 102, 103, 107, 118, 119, 120, 121, 122, 123, 131, 132, 133, 134, 135, 137, 138

36

Function

The Plot component is responsible for drawing all plot objects in OpenACCEL.

Subordinates

The Plot component has a canvas. A canvas has a Descartes handler which directly interfaceswith the Descartes library.

Dependencies

This component depends on the following components:

• Controller

• Pareto

• Script

• View

Interfaces

The plot component provides an interface for:

• Drawing plot functions for user scripts.

• Drawing plots of individuals of Pareto.

• Drawing relative values of dependent output values.

• Drawing a network of points with connections.

• Interaction with the canvas.

Processing

The processing of the Plot component is described in section 3.3.

Data

The plot component does not keep track of any data. Descartes has a buffer which holds allthe objects that have to be drawn after being passed through the descartes handler.

37

Chapter 6

Feasibility and Resource Estimates

This chapter gives an estimation of the computer resources which are needed to develop anduse OpenACCEL. The usage of OpenACCEL is divided into a server side and a client side.

The requirements for the development of OpenACCEL are:CPU ≥ 2.0 GHz x86 or equivalentMemory ≥ 2 GB RAMHard disk ≥ 1 GB free on hard diskOperating system Any supporting the software excluding OSXSoftware Any Text editor able to handle JavaScript code, such as Sublime text v3.

Safari browser v5 or higher, Chrome v35 or higher or any other browsersupporting the same set of JavaScript and HTML5 functionality. gitv2.0. Benchmark v1.0. http-server v0.6. jade v1.3. jison v0.4. jqueryv2.1. jsdoc v3.3. mocha v1.20. requirejs v2.1. sweetjs v0.6. underscorev1.6

Response times

OperationInstalling dependencies ≤ 5000msBuilding OpenACCEL ≤ 6000msBuilding documents ≤ 10000msTesting ≤ 75000ms

The requirements for operating OpenACCEL are:

- Server side:CPU ≥ 2.0 GHz x86 or equivalentMemory ≥ 4 GB RAMHard disk ≥ 1 GB free on hard diskOperating system Any supporting the softwareSoftware http-server v0.6

Response timesOperationDeploying OpenACCEL ≤ 1000ms

- Client side:

38

CPU ≥ 2.0 GHz x86 or equivalentMemory ≥ 1 GB RAMOperating system Any supporting the softwareSoftware Safari browser v5 or higher, Chrome v35 or higher or any other

browser supporting the same, or larger, set of JavaScript andHTML5 functionality.

Response times

OperationOpening OpenACCEL ≤ 2500msOpening tabs ≤ 100msCompiling line see: A.1 ≤ 2000msCompiling script see: A.2 ≤ 5000ms

39

Chapter 7

Requirements Traceability Matrix

Tracing software requirements to components is important in the software production process.A traceability matrix will help to correlate and trace the requirements to the implementation.It evaluates and relates between different system components and provides the status of therequirements. This way it allows developers to relate specific parts of the software to the userrequirements and the developer will know what the purpose of a component is.

7.1 SRD to ADD

This section is about the traces and relations between the software requirements and thearchitectural design. Architectural designs that are in italic have not been implemented, andthus are not described in chapter 5.

Software requirement Architectual design

SCR1 View

SCR2 View

SCR3 View, Controller

SCR4 View

SCR5 View

SCR6 View

SCR7 View

SCR8 View

SCR9 View

SCR10 View

SCR11 View

SCR12 View, Controller

SCR13 View, Controller

SCR14 View

SCR15 View

SCR16 View, Plot

SCR17 View

SCR18 View

SCR19 View

SCR20 View

40

SCR21 View

SCR22 View

SCR23 View

SCR24 View

SCR25 View, Plot

SCR26 View, Plot

SCR27 View

SCR28 View, Plot

SCR29 View, Plot

SCR30 View

SCR31 View, Controller

SCR32 Script

SCR33 Script

SCR34 Script

SCR35 Script

SCR36 Script

SCR37 Script

SCR38 Script

SCR39 Script

SCR40 Script

SCR41 Script

SCR42 Script

SCR43 Script

SCR44 Script

SCR45 Script

SCR46 Script

SCR47 Script

SCR48 Script

SCR49 Script

SCR50 Script

SCR51 Script

SCR52 Script

SCR53 Script

SCR54 Compiler

SCR55 Compiler

SCR56 Compiler

SCR57 Compiler

SCR58 Compiler

SCR59 Compiler, Error

SCR60 Compiler, Executable

SCR61 Compiler

SCR62 Compiler

SCR63 Compiler

SCR64 Compiler

41

SCR65 Compiler

SCR66 Compiler

SCR67 Compiler

SCR68 Compiler

SCR69 Compiler

SCR70 Compiler

SCR71 Compiler

SCR72 Compiler

SCR73 Script Analyser

SCR74 Script Analyser

SCR75 Script Analyser

SCR76 Script Analyser

SCR77 Script Analyser

SCR78 Script Analyser

SCR79 Script Analyser

SCR80 Script Analyser

SCR81 Script Analyser

SCR82 Script Analyser

SCR83 Script Analyser

SCR84 Script Analyser

SCR85 Script Analyser

SCR86 Controller, Executable

SCR87 Controller, Executable

SCR88 Controller, Executable

SCR89 Controller

SCR90 Controller

SCR91 Controller

SCR92 Controller

SCR93 Controller

SCR94 Controller

SCR95 View

SCR96 View

SCR97 Analysis

SCR98 Analysis, Plot

SCR99 Analysis, Plot

SCR100 Analysis, Plot

SCR101 Analysis, Plot

SCR102 Analysis, Plot

SCR103 Analysis, Plot

SCR104 Pareto

SCR105 Pareto

SCR106 Pareto

SCR107 Pareto, Plot

SCR108 Pareto

42

SCR109 Pareto

SCR110 Pareto

SCR111 Pareto

SCR112 Pareto

SCR113 Pareto

SCR114 Pareto

SCR115 Pareto

SCR116 Pareto

SCR117 Pareto

SCR118 Pareto, Plot

SCR119 Pareto, Plot

SCR120 Pareto, Plot

SCR121 Network, Plot

SCR122 Network, Plot

SCR123 Network, Plot

SCR124 View

SCR125 Controller

SCR126 Controller

SCR127 Controller

SCR128 Controller

SCR129 Not applicable

SCR130 Executable

SCR131 All components

SCR132 All components

SCR133 All components

SCR134 All components

SCR135 All components

SCR136 View

SCR137 All components

SCR138 All components

SCR139 Controller, View

7.2 ADD to SRD

This section is about the traces and relations between the architectural design and the softwarerequirements.

Architectural description Software requirement

5.2.1 Script SCR32, 33, 34 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46,47, 48, 49, 50, 51, 52, 53, 131, 132, 133, 134, 135, 137, 138

5.2.2 Compiler SCR54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68,69, 70, 71, 72, 131, 132, 133, 134, 135, 137, 138

5.2.3 Executable SCR60, 86, 87, 88, 130, 131, 132, 133, 134, 135, 137, 1385.2.4 Script Analyzer SCR73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 131,

132, 133, 134, 135, 137, 138

43

5.2.5 Pareto SCR104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114,115, 116, 117, 118, 119, 120, 131, 132, 133, 134, 135, 137,138

5.2.6 Storage 131, 132, 133, 134, 135, 137, 1385.2.7 Error SCR59, 131, 132, 133, 134, 135, 137, 1385.3.1 Controller SCR3, 12, 13, 31, 86, 87, 88, 89, 90, 91, 92, 93, 94, 125, 126,

127, 128, 129, 131, 132, 133, 134, 135, 137, 138, 1395.4.1 View SCR1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18,

19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 95, 96, 124,131, 132, 133, 134, 135, 137, 136, 138, 139

5.4.2 Plot SCR16, 25, 26, 28, 29, 98, 99, 100, 101, 102, 103, 107, 118,119, 120, 121, 122, 123, 131, 132, 133, 134, 135, 137, 138

Analysis SCR97, 98, 99, 100, 101, 102, 103, 131, 132, 133, 134, 135,137, 138

Network SCR121, 122, 123, 131, 132, 133, 134, 135, 137, 138

44

Appendix A

Scripts

A.1 Vertex Demo

a = vMake(1,5000000)

A.2 Speed Ramp Demo

x0=0; dm// f i x e s the o r i g i n o f the x−a x i s// un i t s are in dm; one p i x e l corresponds to 1 dm.

x1=100; dm// s t a r t i n g po int o f speed ramp

fSW=s l i d e r ( 1 5 , 0 . 1 , 6 0 ) ; dm// f r o n t s l ope width

tSW=s l i d e r ( 1 5 , 0 . 1 , 6 0 ) ; dm// t r a i l i n g s l ope width

pW=s l i d e r ( 3 0 , 0 . 0 , 8 0 ) ; dm// plateau width

t r a i l =50; dm// the part a f t e r the speed ramp

x2=x1+fSWx3=x2+pWx4=x3+tSWx5=x4+t r a i l

// the s a i l a n t x−l o c a t i o n s in the roadyOff=40

// to move the image a b i t up , so that speed ramps a l s o canhave negat ive he ight

fH=s l i d e r (4 .0 ,−20 ,20) ; dm// f r o n t he ight

tH=s l i d e r (4 .0 ,−20 ,20) ; dm// t r a i l i n g he ight

v=s l i d e r (100 ,1 ,500) ; dm/ s// speed o f the car . 100 dm/ s = 10 m/ s = 36 km/h

45

hOff=i f ( hOff {1}<−200 ,0 , hOff{1}−v∗dt )// where the p i c t u r e o f the road s t a r t s . The p i c t u r e i s

s h i f t e d// in the oppos i t e d i r e c t i o n o f the speed o f the car , so the

wheels// stay at f i x e d h o r i z o n t a l p o s i t i o n in the image

t=i f ( ! r e s e t , t{1}+dt , 0 )// the time i s r e s e t when the r e s e t button i s c l i c k e d

r e s e t=button ( )// to i n t e r r u p t and r e s e t the animation

dt=s l i d e r ( 0 . 0 1 , 0 . 0 0 5 , 0 . 0 2 ) ; s// sample time i n t e r v a l// p i c t u r e=p lo t ( [ roadImg ( road ) ,whImg(fW) ,whImg(rW) , sImg ( fS ) ,

sImg ( rS ) , chImg ( ch ) ] )p i c t u r e=p lo t ( [ roadImg ( road ) ,whImg(fW) ,whImg(rW) , sImg ( fS ) , sImg ( rS ) ,

chImg ( ch ) , sPImg ( fPS ) , sPImg ( rPS ) ,pImg(p) ] )// everyth ing that needs to be p l o t t ed

road=#(i , vSeq (0 ,100) ,vVecRamp( xL i s t+hOff , yList , i ) , vAppend)roadImg ( r ) =[ [ plotType : ’ l i n e ’ , c o l r : 0 , width : 3 , x : [ mode : ’ intp ’ ] , y : [

mode : ’ data ’ , r e f : 1 ] ] , yOff+r ]// the road moves in the image

xL i s t =[x0 , x1 , x2 , x3 , x4 , x5 ]// the h o r i z o n t a l l o c a t i o n s o f the s a i l a n t po in t s in the speed

rampyLi s t =[0 ,0 , fH , tH , 0 , 0 ]

// the v e r t i c a l l o c a t i o n s o f the s a i l a n t po in t s in the speedramp

fW=i f ( t<=dt , [ x : xF , y : 0 ,vY: 0 , a : g ] , [ x : xF , y : fW{1} . y+fW{1} .vY∗dt ,vY : fW{1} .vY+fW{1} . a∗dt , a : g+( fS {1} . f+f C o l l (fW{1}) ) /wM] )

rW=i f ( t<=dt , [ x : xR, y : 0 ,vY: 0 , a : g ] , [ x : xR, y :rW{1} . y+rW{1} .vY∗dt ,vY :rW{1} .vY+rW{1} . a∗dt , a : g+(rS {1} . f+f C o l l (rW{1}) ) /wM] )// the wheel geometry :// x−coo rd ina t e s move uni formly with speed v − so they stand

s t i l l in the moving image// y−coo rd ina t e s ( o f wheel l owest po int ) found by i n t e g r a t i n g

vY// vY (y−speed ) i n t e g r a t i n g a// a i s the r e s u l t o f g rav i ty p lus the c o l l i s i o n f o r c e p lus

the f o r c e from the corre spond ing spr ing .f C o l l (w)=−min (0 , co l lC ∗(w. y−road [w. x ] ) )− i f (w. y<road [w. x ] ,w.vY∗ col lD

, 0 ) /dtco l lC =4000co l lD =0.15

// a wheel s h a l l not s ink below the road , or e l s e the re i s ar e a c t i o n f o r c e .

// We model the t i r e as a dampened spr ing . Damping does notwork when the wheel i s detached from the road

46

rad =6; dm// rad iu s o f a wheel

wM=cM/10// mass o f a wheel i s 10% of the mass o f the c h a s s i s

g=−30; dm/ s2// g rav i ty v e l o c i t y − given the masses , t h i s g i v e s n i c e ’

f a l l i n g ’ behaviorxF=30; dm

// f rontwhee l x−p o s i t i o n o f carxR=80; dm

// rea r wheel x−p o s i t i o n o f carwhImg(w) =[ [ plotType : ’ bubble ’ , x : [ mode : ’ data ’ , r e f : 1 ] , y : [ mode : ’ data ’ ,

r e f : 2 ] , c o l r : 255 , diameter : 2∗ rad ] , [w. x ] , [ yOff+w. y+rad ] ]devFS=ch . fY−(fW. y+rad+sL )devRS=ch . rY−(rW. y+rad+sL )fS=i f ( t<=dt , [ x1 : xF , x2 : xF , y1 : rad , y2 : rad+sL , f : 0 ] , [ x1 : xF , x2 : xF , y1 : fW. y

+rad , y2 : ch . fY , f : c∗devFS+d ∗ ( ( ch . fY−fW. y )−(ch {1} . fY−fW{1} . y ) ) /dt ] )rS=i f ( t<=dt , [ x1 : xR, x2 : xR, y1 : rad , y2 : rad+sL , f : 0 ] , [ x1 : xR, x2 : xR, y1 :rW. y

+rad , y2 : ch . rY , f : c∗devRS+d ∗ ( ( ch . rY−rW. y )−(ch {1} . rY−rW{1} . y ) ) /dt ] )// geometry o f the s p r i n g s :// x1 and x2 both f o l l o w the l o c a t i o n o f the cor respond ing

wheel ( no dynamics )// y1 = cent r e o f cor re spond ing wheel// y2 = extreme point o f the c h a s s i s// f o r c e = the f o r c e on the lower extreme . So compressed

spr ing pushes downwards .// Two components : one hooke term , p r o p o r t i o n a l to d i f f e r e n c e

between r e s t l ength ( sL ) and ac tua l l ength ;// one damping term , p r o p o r t i o n a l to d i f f e r e n c e in top− and

bottom speeds o f sp r ing .c=100

// spr ing constant f o r the wheel suspens iond=170

// damper constant f o r the wheel suspens ionsL=5; dm

// spr ing r e s t l ength f o r the wheel suspens ionbL=s l i d e r (40 ,−100 ,500) ; dm

// o f f s e t to sp r ing l ength to have c h a s s i s o f f the f l o o r −must be adjusted when car mass i s ad justed

// t h i s l ooks b e t t e r but has no i n f l u e n c e on the dynamics .sImg ( s ) =[ [ plotType : ’ l i n e ’ , c o l b : 255 , width : 4 , x : [ mode : ’ data ’ , r e f : 1 ] , y

: [ mode : ’ data ’ , r e f : 2 ] ] , [ s . x1 , s . x2 ] , yOff +[ s . y1 , s . y2+bL ] ]// to p l o t the s p r i n g s

ch=i f ( t<=dt , [ fX : xF , rX : xR, fY : rad+sL , rY : rad+sL , fVY : 0 , rVY: 0 , fAY : g , rAY:g ] , [ fX : xF , rX : xR, fY : ch {1} . fY+ch {1} . fVY∗dt , rY : ch {1} . rY+ch {1} . rVY∗dt , fVY : ch {1} . fVY+ch {1} . fAY∗dt , rVY: ch {1} . rVY+ch {1} . rAY∗dt , fAY : g−fS {1} . f /cM, rAY: g−rS {1} . f /cM] )

47

// geometry o f the c h a s s i s .We assume that f r o n t and rea r// end only move v e r t i c a l l y to the dynamics ; t h e i r h o r i z o n t a l

motion i s// not coupled to the dynamics and pure ly d i c t a t ed by the hor .

l o c a t i o n o f the// wheels .// fY , rY i n t e g r a t e fVY and rVY;// fVY , rVY i n t e g r a t e aVY and rVY;// aVY and rVY are the sum of g rav i ty and the spr ing f o r c e s in

the f ront ,// and rea r spr ings , r e s p e c t i v e l y .// Not ice that the s i g n s o f the se f o r c e s are oppos i t e// to the s i g n s o f the f o r c e s on the wheels .

cM=s l i d e r (100 ,100 ,500) ; kg// the weight o f the c h a s s i s

chImg ( chs ) =[ [ plotType : ’ l i n e ’ , c o l r : 255 , width : 8 , x : [ mode : ’ data ’ , r e f: 1 ] , y : [ mode : ’ data ’ , r e f : 2 ] ] , [ chs . fX , chs . rX ] , yOff +[ chs . fY+bL , chs .rY+bL ] ]

// to p l o t the c h a s s i sp=i f ( t<=dt , [ x : ( xF+xR) /2 , y :3∗ rad+sL ,m:pM,vX: 0 ,vY: 0 , aX : 0 , aY : g ] , [ x : p{1} . x+p{1} .vX∗dt , y : p{1} . y+p{1} .vY∗dt ,m:pM,vX: p{1} .vX+p{1} .aX∗dt ,vY : p{1} .vY+p{1} .aY∗dt , aX : ( fPS {1} . f [0 ]+ rPS {1} . f [ 0 ] ) /pM, aY : g+fCol lP /pM] )// the geometry o f the passenger .// m: the mass// x , y : coord inate s , i n t e g r a t i n g vX,vY// vX,vY : v e l o c i t i e s , i n t e g r a t i n g a c c e l e r a t i o n s// aX , aY : a c c e l e r a t i o n s , g iven by the s p r i n g s . Not ice : the

mass o f the passenger// i s cons ide r ed to be n e g l i g a b l e to the mass o f the c h a s s i s .

There fore we// don ’ t r e s p e c t ac t i on = −r e a c t i o n f o r the passenger s p r i n g s :

the se only// exce r t f o r c e s on the passenger , but not on the c h a s s i s .

This would be// impos s ib l e anyway f o r the x−components , s i n c e everyth ing i s

assumed to have uniform x−motion ;// i t i s an approximation w. r . t . the y−components .

fCo l lP=−min (0 , co l lP ∗(p{1} . y−(chassY+2∗rad ) ) )− i f (p{1} . y<chassY+2∗rad, p{1} .vY∗collPD , 0 ) /dt// the c o l l i s i o n f o r c e that should keep the passenger from

f a l l i n g through the c h a s s i schassY=(ch . fY ∗(xR−p{1} . x )+ch . rY∗(p{1} . x−xF) ) /(xR−xF)

// the y−coord inate o f the po int on the c h a s s i s with x−coord inate the x−coord inate o f the passenger

pM=30// the mass o f the passenger

48

restLfPS=i f ( t<=dt , s q r t (pow ( (xR−xF) /2 ,2)+rad∗ rad ) , restLfPS {1})restLrPS=i f ( t<=dt , s q r t (pow ( (xR−xF) /2 ,2)+rad∗ rad ) , restLrPS {1})

// the r e s t l eng th s o f the two s p r i n g s that keep the passengerin p lace

vfPS=[p . x−xF , p . y−ch . fY ]vrPS=[p . x−xR, p . y−ch . rY ]curLfPS=vNormEuclid ( vfPS )curLrPS=vNormEuclid ( vrPS )nfPS=vfPS/curLfPSnrPS=vrPS/curLrPS

// the l ength and the un i t vec to r corre spond ing to the f r o n tpassenger sp r ing

// and s i m i l a r f o r the r ea r passenger sp r ingfPS=i f ( t<=dt , [ x1 : xF , x2 : ( xF+xR) /2 , y1 : rad+sL , y2 : p . y , f : [ 0 , 0 ] ] , [ x1 : xF ,

x2 : p . x , y1 : ch . fY , y2 : p . y , f : ( cPS∗( restLfPS−curLfPS )−dPS∗( curLfPS−curLfPS {1}) /dt ) ∗nfPS ] )

rPS=i f ( t<=dt , [ x1 : xR, x2 : ( xF+xR) /2 , y1 : rad+sL , y2 : p . y , f : [ 0 , 0 ] ] , [ x1 : xR,x2 : p . x , y1 : ch . rY , y2 : p . y , f : ( cPS∗( restLrPS−curLrPS )−dPS∗( curLrPS−curLrPS {1}) /dt ) ∗nrPS ] )

// the two s p r i n g s that keep the passenger in p lace are// euc l i d ean spr ings , e . i . , they work along the d i r e c t i o n o f

the spr ing .// Their f o r c e has a Hook component and a dampened component ;

the l a t t e r// i s der ived from the change in cur rent l ength s i n c e the

prev ious eva lua t i onsPImg ( s ) =[ [ plotType : ’ l i n e ’ , c o l b : 0 , width : 2 , x : [ mode : ’ data ’ , r e f : 1 ] , y

: [ mode : ’ data ’ , r e f : 2 ] ] , [ s . x1 , s . x2 ] , yOff+bL+[ s . y1 , s . y2 ] ]// p l o t t i n g the spr ing that keeps the passenger in p lace

pImg(p) =[ [ plotType : ’ bubble ’ , x : [ mode : ’ data ’ , r e f : 1 ] , y : [ mode : ’ data ’ ,r e f : 2 ] , c o l r : 128 , diameter : 4∗ rad ] , [ p . x ] , [ yOff+p . y+bL ] ]

cPS=250// spr ing constant o f s a f e t y b e l t s and other passenger−

f i x a t i o n systemsdPS=110

// damper constant o f passenger−f i x a t i o n systemco l lP =1300

// c o l l i s i o n handl ing r e a c t i o n f o r c e to keep passenger fromf a l l i n g through the c h a s s i s

collPD =0.75// c o l l i s i o n handl ing damper f o r c e to keep passenger from

f a l l i n g through the c h a s s i s

49