RobertaLab: Configuration, Architecture, Frameworks, Design

Transcription

1 Roberta Seite 1 RobertaLab: Configuration, Architecture, Frameworks, Design reinhard.budde at iais.fraunhofer.de version :57 Overview The system consists out of three distributed components, which are described in three chapters: A) the brick and its software B) the Javascript-enabled browser C) the server A separate chapter D) is devoted to the connection between brick and browser and its stability and safety. - In the eclipse workspace (see later) three projects store the resources related to the brick (to be refactored soon) and one project stores the resources related to the server (project robertalabserver) A program to be excuted on the brick consists out of two components: - the brick program, which defines the behavior of the robot (blockly blocks, text) - the brick layout, which defines the hardware properties of the robot (other blockly blocks, text): the connection of sensors and actuators to the various ports the sizes of component used (diameter of wheels, wheel base). This is needed for higher level blocks (move 30 cm and turn to the right 90, e.g.) - the components will be defined with of blockly, later a text based definition will be supplied, too. A) the brick and its software lejos is used in a version modified by the project. The image is supplied on a SD card. a service to download and to start a jar has been added. a service that detects the type of sensors and actuators connected to the brick has been added. This service is used to check consistency between the detected hardware connections and the brick layout as specified (see above) it is planned to add instrumentation to the generated code that allows a decent debugging of the brick program (highlight the block that has control, see values of variables,...)

2 Roberta Seite 2 B) the Javascript-enabled browser the javascript frontend is developed as a single page application. After starting the client only ajax calls to the server are issued to update the clients state jquery is used as main framework. jquery-ui and its theming are used for interface design. The design will be finalized after the functionality has stabilized (frameworks with a higher level of abstraction will be used when needed, e.g. angular or languages as dart. Upfront design will be avioded. three modules realized as self-executing function are used (more will be designed in the near future): i. COMM (ajax-abstraction including automated logging from client-side at server-side) ii. DBC (design by contract functions, including wrapper) iii. LOG (client-side logging, automated send to the server by the COMM-module) blockly is used as framework to support graphical programming the client calls the REST services of the server. Data is transferred as an attached entity. JSON is used as transport format. XML (blockly programs e.g.) are embedded as strings in JSON objects. unit tests of Javascript modules and functions have to be fully automated and i. are executed in the browser, to have full access to the DOM (as abstracted by jquery) ii. are implemented as HTML pages in which the test fixture (javascript functions, of course) a button for each test case text fields whose contents define whether a test case is running and whether the expected result was found iii. are started from a Java junit class. This class executes all test cases and fails if the test cases in the browser fail. The class is derived from a class generated with selenium. system tests have to be fully automated and should be generated Java classes from recorded user actions. Recording and generating is done using selenium. for stable (system and junit) tests the DOM has to be test-friendly. This means i. consistent use of CSS for design classes and marker classes ii. consistent and comprehensive naming of IDs of the DOM. C) the server C.1) configuration and quality assurance the server resources are stored in an eclipse kepler workspace, java7 is used (likely to change to luna and java8 soon) all resources are stored in one java project: robertalabserver (disaggregation into more projects is likely to occur, but on demand. E.g. to guarantee acyclic relationsships between components and to ease dependency management) maven standard configuration (w.r.t. to src and target folders) with packaging jar (not war, maybe change later) generated sources are stored in target/generated (jaxb2, antlr4) the project pom uses dependency management and version properties to ease the adaption to new realeases of frameworks the (full) Atlassian stack is used: i. stash (as git repository) ii. jira (as issue tracker

3 Roberta Seite 3 iii. confluence (as wiki) iv. bamboo (as continuous integration server) v. sonar (for QA). A standard configuration is used (likely to be adapted to project needs soon) This is documented elsewhere. unit tests of Java classes have to be fully automated and are based on junit4 and mockito. Classes are using DI to ease testing -preferable constructor injection. system tests have to be fully automated and use selenium. See the remarks about testing Javascript in chapter B) above. C.2) architecture and components jetty is used as an embedded server. Jetty is configured programmatically (without web.xml e.g.). jersey is used to implement REST services. dependency injection (DI) into the jersey services and other resources is done with guice (i.e. guice serves all requests arriving at the jetty server) jaxb2 is used to marshall/unmarshall data. Marshalling/unmarshalling is supported for XML and JSON as well as for jaxb2-based objects, maps and beans. jackson is used to provide these services under the hood hibernate is used as persistence framework JPA annotations are used to declare classes as persistent entities. Properties are only used at field level. for each persistent entity a data access object (DAO) is defined sessions are injected w.t.h. of a session factory by guice c3po is used as connection manager sqlite is used as database system. The hibernate binding for sqlite is supplied by the project. An advantage of sqlite is the great flexibility of the varchar datatype (The database may change in the future on demand, e.g. need for more concurrency, size,.... This should have almost no impact on the Java part) 1 1 logging is done by using slf4j. Logging is implemented using logback. the bridges to all other logging frameworks (log4j, JUL, CL) are available on demand. 1 1 it is planned to have a textual representation of the graphical language. The conversion is based on bi - directional transformation between blockly XML, an abstract syntax tree (AST) and text. Parsing of text will be based on antlr the definition of the tool boxes (more than one...) and the blocks will be finished in the near future. Extensions will be added from time to time. Starting point are blocks for beginners and blocks related to programming a self-driving car. C.3) design decisions clean use of the design by contract principle (DBC) is one of the most valuable goals. The contract should be clearly stated in the javadoc part of all (public?) methods.

4 Roberta Seite 4 Preconditions have to be checked using the project's Assert class at the beginning of a method. exception handling is based on DBC. read Joshua Bloch, Effective Java, 2nd edition (3rd coming soon, hopefully) and Martin, Clean Code immutable data is preferred to mutable. Collections returned to clients have to be wrapped by Collections.unmodifiable...(...) where it makes sense. Arrays returned to clients should be avoided or created objects to be returned. emphasis is placed on designing classes "as immutable as possible". E.g. i. each class of the AST package has a factory method make creating a mutable object ii. after construction the object can be sealed iii. if AST objects (e.g. sub expressions or statements) are aggregated to larger objects (expressions or statement lists), the aggregator has to check that the components are sealed. iv. it is forbidden to add unsealed AST objects to any kind of collection special care is needed when operating on persistent entities (e.g. loaded by hibernate from the database). They should either be detached (makes no sense in many cases) or use seal/unseal methods to avoid unintended changes in the database. Of course, other design patterns are available to avoid data damage and may be applied on demand. C.4) data flow the simplified data flow from the browser to the server and from the server to the brick is described below: a blockly program is created in the browser at client side either time-triggered or based on user action the blocks are transformed to XML. this XML has to conform to an XSD. It is different from the default XML generated by blockly. the XML is sent to the server, embedded in JSON. State and logging information is passed alongside to the server jetty receives the request. The REST resource gets its dependencies injected. the XML is unmarshalled to an jaxb2-based object structure. The classes usedare generated by xjc (jaxb2) from the XSD mentioned above. the program is persisted as XML string. This may change in the near future. the jaxb2-based object structure is transformed to an abstract syntax tree (AST). This AST is the basis for (type-)checking, further transformations (optimizations) and code generation the brick issues a /downloadlejos REST call, if it is ready to execute a program. If this request times out the brick repeats it. the server puts the request into a synchronization table and blocks the request (by not returning a response) if the user presses the run button at client side, an appropriate REST call is issued. this call unblocks the requesting thread from the brick and returns the jar with the compiled program. because code generation is not finished, only a demo jar is uploaded to the brick to demonstrate the synchronization. Actually code generation is not yet finished. The synchronization is working, a demo jar is sent. See D) for details of the synchronization.

5 Roberta Seite 5 D) the connection problem between browser and brick in three pictures :-) the (implicit) expectation of the user the (technical) solution, that an engineer expects a bug, which we have to avoid definitively