DEBAT - Preliminary Design Review 8, 9 July 2003

1. DEBAT - Preliminary Design Review 8, 9 July 2003

2. Agenda 8th July afternoon 14.30 - 14.45 Project status 14.45 - 15.00 Product Assurance Report 15.00 - 17.00 Architecture Design of DEBAT 9 July morning 09.00 - 10.00 External interfaces of DEBAT (ICD) 10.00 - 12.00 Presentation & demo of the new DEBAT Modeller

3. Project status 14.30 – 14.45

4. Project Organisation • The French Space market is currently going through a really difficult economic period that generates a drop in the space activities. • As CS is one of the most important service providers in France, it has to face important difficulties. • In spite of the crisis, CS has chosen to avoid firing people and has taken social measures so as to preserve employment, keep the staff and preserve the knowledge acquired by the company.

5. Project Organisation • CS has decided to take a global measure to overcome this crisis. This measure consists in an overall work time reduction of 40%. • It applies to all the staff of the Space Department, until the end of the year, whatever the project or the work load so as to "share" the work (this measure is made within a legal framework that impose that all staff is concerned). • Specific measures are taken for the DEBAT project to guarantee the best performance of the work within the agreed schedule: • the team is reinforced with three more persons (with a good experience of the technology), • training and integration of the new resources are taken in charge by CS. • This is a zero-cost, zero-schedule impact measure.

6. Project Organisation • Current team

7. Project Organisation • New team

8. Project Organisation • Didier Garcin will work on the improved EAST core. It has a thorough knowledge of ADA and has been working on EAST for more than two years. • Jean-Charles Brunet will also work on the improved EAST core, and more specifically on the interfaces between ADA and Java (Java API, support for external functions, generation directives for the DPE and DEQ query handler). • Espen Bjorntvedt has a good experience of Java and will reinforce the team working on the new DEBAT Modeller.

9. PDR Deliveries The following formal deliveries are made on the 8th of July 2003: Architectural Design Document SS/DEBAT/ADD 1.0 Interface Control Document SS/DEBAT/ICD 1.0 Software Verification and Validation Plan SS/DEBAT/SVVP 1.0 Product Assurance Plan SS/DEBAT/PAP 1.2 Project Management Plan SS/DEBAT/PMP 1.2

10. Progress status • The work performed from ATP has been mainly focused on the software specification and architectural design, and on the the implementation of the 1st iteration of the new Data Modeller. • Software specifications and architectural design are completed. • First iteration of the new DEBAT Modeller is completed (a demo is planned tomorrow morning)

11. Progress status • Software specification and architectural design (1 / 2)

12. Progress status • Software specification and architectural design (2 / 2)

13. Progress status • New Data Modeller

14. Future work (from PDR to CDR) • Detailed design

15. Future work (from PDR to CDR) • Implementation of iteration 2 of the new Modeller

16. Product Assurance Report 14.45 – 15.00

17. Introduction • The aim of this presentation is to describe the quality actions performed from the beginning of the phase 2 and until the Preliminary Design Review. • Several quality actions were carried out : • Reminding the development team of the quality devices (files header comments, coding rules and metrics bounds), • Controlling code and documentation, • Participating in progress meetings.

18. Let's focus on the Modeller control code • According to the Product Assurance Plan, a Modeller source code per language and per individual was checked in relation to the project coding standards. • The Modeller control reveals that : • Comments frequency is lower than 20% for few functions. • Declaration doesn’t appear at the beginning of a block in a function.

19. Let's focus on - Controlling documentation for delivery • According to the Product Assurance Plan, five documents were controlled before being delivered: • Any quality comments were done on the documents. So they were approved by the quality manager.

20. Let's focus on conclusion • The Modeller produced code respects the number of instructions and VG bounds, whereas the comments frequency is lower than 20%. Thanks to the development team which undertakes to increase the comments frequency,the quality of the produced code is satisfying.

21. Architecture Design of DEBAT 15.00 – 17.00

22. Overall architecture presentation • What is DEBAT ? • A suite of tools providing support for all phases of the data life cycle • DEBAT is built around the EAST core that forms the backbone of the software • DEBAT is composed of several high-level components (or tools) built on top of EAST to add further capabilities

23. Overall architecture presentation • What is the DEBAT operational environment ? Man Machine Interface Enables users to execute all the available DEBAT functions from a user-friendly GUI Command line Allows to invoke some of the DEBAT functions through the command line API in Ada, Java, C/C++ and Fortran Allows the user applications to be linked directly to the libraries of functions provided in DEBAT Web interface Provides access to a subset of the DEBAT functions (the most useful ones) using a Web browser as interface. SOAP interface (Web Service interface) Provides access to some of the DEBAT functions for remote user applications through a SOAP interface

24. Overall architecture presentation • What are the general architectural concepts of DEBAT ? • Modular and integratedarchitecture to allow the replacement or the addition of functions with no impact on the others (plug-in concept) • Flexibility to allow the use of DEBAT in different ways • Standalone suite of tools • DEBAT integration in existing systems • Generic data framework providing many building blocks

25. General features • Installation procedure allowing to install the entire environment • The same installation procedure whatever the platform and the tools • Two modes • Automatic : all the DEBAT environment and tools are installed • Custom : the user can choose the tools he wants to install • Use of an installer product such as InstallAnywhere • A common core Java libraryprovides the following general functions • Online help documents all the available functions • Screenshot function enables users to capture parts of the DEBAT MMI • Printing capabilities enables users to print text files • Internationalization mechanismallows to • Add another language easily without modification or recompilation of the source code • Choose the language to use during the installation or by reconfiguring the software when it is running • The core library is directly part of the DEBAT Integrated Environment • The core library is accessible to all the components through a Java API

26. General features • Technical solutions • The online help is implemented with the Java-Help technology • Screenshots and printing capabilities are implemented using the built-in mechanisms of the Java language • Internationalization mechanism • All the DEBAT man-machine interfaces are provided by default in the English language • Use of external resource files (one resource file per language) • Name: [name]_[language]_[country].property • Content: the texts to be internationalized (labels, menus, buttons, …) • Format: key = value where key is the reference used in the source code

27. INTEGRATED ENVIRONMENT DEBAT FRAMEWORK COMMON FUNCTIONS PLUG-IN SYTEM PROJECT MANAGEMENT USER PLUG-IN DEBAT DATA MODELLER ... USER PLUG-IN DEBAT TOOLS Integrated Environment • The DEBAT integrated environment is composed of • The DEBAT framework • The plug-in system • The project management

28. Integrated Environment – DEBAT framework • Single and intuitive accessto the set of tools/plug-ins • Fully re-configurable: • enable/disable the plug-ins • define/modify the name, icon and command (the action to be triggered when clicking on the icon) associated to the plug-ins • Logbook: store and display all the messages/warnings/errors raised by the tools

29. Integrated Environment – DEBAT framework • The framework is composed of three Java sub-components • Framework GUI: the entry point of the DEBAT software • Framework configuration GUI • display the list of available plug-ins with their properties • allow the user to change the configuration of the framework • Framework manager • read the XML configuration file that defines the available plug-ins and their configuration • forward the calls to a plug-in to the plug-in manager component

30. Integrated Environment – Plug-in system • Functions • Allow the addition or replacement of new functions within the suite of tools • Enable to add/upgrade/remove tools in the framework with no impact on the other tools • DEBAT is responsible for: • monitoring and controlling the tools: loading into memory, starting, monitoring and stopping • maintaining a virtual storage space in memory allowing the tools/plug-ins to share common data • Bi-directional communications between DEBAT and the plug-ins • DEBAT is able to send messages to the plug-ins being executed • The plug-ins provide a Services Interface defining the services they can offer to the others

31. Integrated Environment – Plug-in system • The plug-in system comprises three Java sub-component • Plug-in loader: load the plug-ins in memory • Java plug-ins are dynamically loaded in memory inside the same Java Virtual Machine • Black-box plug-ins are separate non-Java programs that are launched by DEBAT • All is plug-in • Plug-in manager: hold the list of the active plug-ins • receive the call events from the framework GUI • handle, monitor and control the plug-ins • Plug-in interface:enable the bi-directional communication between the IE and the plug-ins. It supports: • the monitoring and control of the plug-ins (load, start, stop) • the passing of messages • the sharing of services between all the tools/plug-ins • To build a Java plugin • implement the Plugin interface : init (), start (), stop (), messageReceived() • package in a jar file

32. Integrated Environment – Project management • What is a project ? • A bundle containing all the files related to a project • the data models • the project documentation in Word, HTML, PDF,… generated by the Modeller • the EAST and DEDSL description files • and, the data files • Project management • provide a virtual organization of the file system • offer a tree-view MMI displaying all the opened projects. The MMI enables users to: • create or delete a project, • add, move or delete files in a project • trigger an action (e.g. open in Modeller, generate EAST) on a file or on a bulk of files.

33. Integrated Environment – Project management • A Java plug-in split into two components: • Project management GUI • provide the users with a tree-like graphical user interface very similar to the Windows Explorer • Project manager • load the XML configuration files containing the definition of the projects • hold the list of the opened projects • manage the associations between the files and the potential actions that can be triggered on the files • expose an interface of services that can be used by the other tools/plug-ins to: • retrieve the list of the opened projects • retrieve the files bundled in a given project • trigger an action on a bulk of files, etc

34. EAST CORE - Functions • Data querying • Process queries on data products • Data writing • Improved performances • Standard output and socket support • Integer/Real formats support • External functions support • Direct access • User directives support • APIs • Updated with these new functions • Creation of a complete JAVA API • EAST Analyser • Read/Write string constant • Version management support • Calculation functions support • Unique identification of elements • Default values support • Data reading • Improved performances • Standard input or socket support • Multi-file data products support • Direct access to data • External functions • Data checking • Computed constraints • Different levels of checking • Enhanced errors management

35. EAST CORE - Software Architecture • API • Provide access to the EAST CORE functions for ADA, C/C++, Fortran and Java. • Queries Handler • Process queries • EAST Analyser • Compute EAST descriptions • Manage the EAST internal form • Interpreter • Enable access to data values in products • Data generator • Enable generation of data values • Data computer • Insure correct execution of functions

36. EAST CORE - Software Architecture • EAST Analyser • The EAST analyser is responsible for reading and analysing the EAST descriptions and translating them into an internal form (i.e. DIANA form) • It will be enhanced to support the new features of the EAST descriptions: • Handle string constant: define constant of string type in the descriptions • Version management support: express DEBAT and EAST versions in the EAST descriptions • Unique identification of elements: avoid confusion between two discriminants having the same name • Handle calculation capabilities: specify computed values for array lengths and discriminants • Default values support: handle default values for the variables of the descriptions • All these new information are stored in the DIANA internal form

37. EAST CORE - Software Architecture • Queries Handler • Its role is to decode and execute the query (if well-formed) and return the results to the calling application.

38. EAST CORE - Software Architecture • Data computer • Calculation capabilities • The role of the data computer module is to compute the calculation and render the results to the caller • External functions • These are functions written in Java and dynamically linked and executed at runtime by EAST • They are used to apply specific transformation to the data during reading and writing processes • The communication between the ADA and Java languages is made using the JNI (Java Native Interface) technology • Random value generation • This function is used to generate integers or reals within specific bounds/ranges • It can be used to generate either valid or degraded values • Support for string patterns • This function is used to generate random strings matching a given pattern

39. EAST CORE - Software Architecture • Interpreter • Multi-file data products support • Read data products split into several files • TCP/IP sockets and standard input • Add the capability to read data product from TCP/IP sockets and standard input • Data checking improvements • Add the capability of verifying a particular element • Add the support of computed constraints applying to a value of a given field • Handle regular expressions for strings and ASCII-encoded numbers • Support different levels of checking (e.g. warning, fatal, error) • Improve the errors management by introducing a unique EAST internal error stack

40. EAST CORE - Software Architecture • Data generator • Integer/Real formats • Specify a format to apply when encoding a number in ASCII • Default values • The writing of elements is processed even if these elements have not been explicitly assigned by the user (directly or through an external function) • Generation directives handler • This component is in charge of reading the generation directives specified by the user (through the DPE tool) and generating the data values according to these directives • Standard output and socket • Direct access • Modify exactly a given element’s value on the medium without loading the whole block in memory • This only works if the structure or the size of the block is not modified (by changing the values of some of the discriminants)

41. EAST CORE - Software Architecture • Data product explorer • Direct access to data • Access only the element of interest without traversing the whole file to find it • Two main functions: • navigation through the different blocks of a data product. It becomes possible to set on a precise block without needing to load the intermediary blocks • access data entities directly once a data block is selected • This functionality can be used either in reading or in writing mode • Performances improvements • The goal is to improve the EAST core concerning processing time and memory consumption • The following modules/features of the EAST core will be improved: • EAST analyser • Data interpreter • Data checking • Data converter • DIANA tree

42. EAST CORE - Software Architecture • Log-book • All the warnings and errors are kept in memory and accessible through the API • APIs • ADA, C/C++ and Fortran APIs are updated with all the previous new functions • A new complete JAVA API is created based on the ADA API using the JNI technology

43. DEBAT Modeller - Functions • It is based on the existing OASIS tool and then offers the same functionalities (concerning EAST and DEDSL features) plus the abilities to: • specify real and integer formats for ASCII encoded numbers • associate default value to particular element • handle calculation capabilities • define external functions • generate documentationin PDF, HTML and RTF formats • reuse data modelsbetween several projects/missions • generatetype declarations in C/C++ and Java • associate images or external filesto the semantic information • import directly existing EAST descriptions • It is built from scratch using Java technologies and specifically the Swing components

44. DEBAT Modeller - Logical Model • XML IF • Graphical edition of XML IF • Manipulation of the tree model • EAST import • Graphical edition of the EAST descriptions • Compatibility with existing IF • Transformation of existing IF files into XML • Type library • Management of reusable types • Data model validation • Verification of the syntactic and semantic attributes of each element of the model • EAST descriptions • Generation of EAST description corresponding to the loaded model • DEDSL • Generation of the DEDSL files corresponding to the loaded model • Documentation • Generation of documentation corresponding to the loaded model

45. DEBAT Modeller - Software Architecture • GUI • Provide access to the Modeller functions • Edit the data model (syntactic & semantic information and tree view) • Data manager • Manage the XML IF file (read/write) • Manage the type library • Process search on the model • Files import • Insure compatibility with existing OASIS IF • Allow reading of EAST files • Syntax • Manage the syntactic attributes of the model • Semantic • Manage the semantic attribute of the model • Files generation • Generate documentation • Generate types declaration • Generate formats files

46. DEBAT Modeller - Software Architecture • Graphical Interface Toolbar and menu view Provide access to all the functionalities of the Modeller (menu, icons and shortcuts) Tree view Display the data model being edited in a tree view form. It is based on the JGraph library. It provides lots of manipulations functionalities (e.g. zoom, expand/collapse, …) Type Manager view Jtree Swing widget to manage the types in the library Syntactic/Semantic view Display of the syntactic/semantic information associated with the elements of the model

47. DEBAT Modeller - Software Architecture • Data Manager • XML-IF manager • Insure a coherent mapping between XML IF content and Java objects • Hold a list of the opened data models • Type library manager • Manage (create/add/edit/remove) types in the library to allow their reuse in other models or projects/missions • The types of the library follow the same structure as for the XML If and are handled the same way • Users are able to organise their types • Search manager • Search for elements using any combination of syntactic and semantic attributes

48. DEBAT Modeller - Software Architecture • Files Import • OASIS IF files import • Transform the existing OASIS IF files (having a proprietary format) into the new XML IF format. • EAST file import • Provide the ability to transform an EAST description into an XML IF data model • Implemented with the JavaCC (JavaCompiler Compiler) technology

49. DEBAT Modeller - Software Architecture • Syntax component • EAST checker module: verifies that all the syntactic information required to generate the EAST description have been correctly filled • EAST generator module: is in charge of generating the EAST descriptions based on the model • Semantic component • It is the same as the Syntax component applied for DEDSL files

50. DEBAT Modeller - Software Architecture • Files Generation • Documentation generator • Generate documentation in HTML, PDF and RTF formats based on syntactic and semantic information contained in the XML IF • Implemented using the XSLT (eXtensible Stylesheet Language for Transformation) and XSL-FO (XSL-Formatting Objects) technologies and the FOP (Formatting Objects Processor) library • Types declaration generator • Generate ADA, C/C++ and Java type declarations • Formats file generator • Generate a format file containing rules defining how ASCII-encoded numbers have to be written in the data products