1 / 21

DEBAT – Progress Meeting 17 th December 2003

DEBAT – Progress Meeting 17 th December 2003. Agenda. 17 th December Morning 9h00 – 9h15 : Project Status 9h15 – 9h30 : Product Assurance Report 9h30 – 11h30 : DEBAT tools Demonstration 11h30 – 12h15 : Round Table 17 th December Afternoon 14h30 – 16h : TM/TC Activities reutilization.

trudy
Télécharger la présentation

DEBAT – Progress Meeting 17 th December 2003

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DEBAT – Progress Meeting 17th December 2003

  2. Agenda 17th December Morning9h00 – 9h15 : Project Status 9h15 – 9h30 : Product Assurance Report 9h30 – 11h30 : DEBAT tools Demonstration 11h30 – 12h15 : Round Table 17th December Afternoon14h30 – 16h : TM/TC Activities reutilization

  3. Project status 9.00 – 9.15

  4. CDR Deliveries • The following deliveries were made during the month of September: • Architectural Design Document 2.0 SS/DEBAT/ADD describing the modules structure of the application, theirs relations, the sketches of GUI, menu trees, and the diagram of the main UML diagrams classes • Design Technical Note 1.0 SS/DEBAT/DD_TN gathering all the background information required to understand the design, but that does not belong to the design proper (choices made, explanations, XML query language, etc …) • Interface Control Document 2.0 SS/DEBAT/ICD describing the interfaces of the APIs. • EAST Language Changes 2.0 SS/DEBAT/ELC describing the changes made to the EAST language; this will be the basis for a proposal to CCSDS to update the EAST standard • The Detailed Design Document 1.1 SS/DEBAT/DDD is a set of HTML pages directly generated from the code. The code, is in fact initialised (main classes, main functions, …), and sufficiently commented. The HTML generation is based on the comments. • The Project Management Plan 1.3 SS-DEBAT-PMP. • A draft version of the Modeller software.

  5. Progress status • The work performed from CDR has been mainly focused on the Implementation of : • the Integrated Environment: it is completed, • the DEBAT Launcher: it is completed, • the new EAST core functionalities: the Java API (Interpreter, Query handler), the Query handler, calculations capabilities, directives files generation. • the Modeller: DEDSL files generation, EAST files generation, taking into account the CNES remarks, Documentations generation • the Data Extractor & Querying: Gui, Data reading, Querying management.

  6. Progress status • As it is planned in the agenda, the reuse of the TM/TC activities will be discussed this afternoon. • The following activities are proposed: • The integration of the EAST core 4.1 modifications into the DEBAT-EAST Core • The generation of the XML-Schema modelling XML-data • The generation of the XML-Schema used by the Derby software of GAEL Consultant • The modification of the Modeller to develop a "plug-in" system for several kind of generation

  7. Schedule from CDR to FAR

  8. Product Assurance Report 9.15 – 9.30

  9. Introduction • The aim of this presentation is to describe the quality actions performed from the Critical Design Review and until the Progress Meeting of December 2003. • Several quality actions were carried out : • Reminding the development team of the quality devices (files header comments, coding rules and metrics bounds), • Participating at the organisation of the cross-checking review, • Use Logiscope Java tool to check the whole of the producted Java code, • Preparation of the progress meeting.

  10. Let's focus on the Java code control • According to the Product Assurance Plan, Logiscope Java tool has been use to check the Java code produced since the begin of the phase 2in relation to the project coding standards • The results are, for each component (modeller, cs, deq, ie and packager), • the list of methods which have out of bound metrics, • the discrepancies list of standard rules.

  11. Let's focus on components code metrics • Components code metrics • Results about basic metrics for Java code. A little number of Java methods have basic metrics out of the bounds : • For the Number of statements, 14 methods over 2837, • For the Cyclomatic number, 17 methods over 2837, • For the Comments frequency, 179 methods over 2837.

  12. Let's focus on - Controlling documentation for delivery • ive documents were controlled before being delivered: • Any quality comments were done on the documents. So they were approved by the quality manager.

  13. Let's focus on conclusion • The quality of the produced code in this phase is satisfying at this step of the phase. • The taking into account of the remarks made during the Java and Ada codes cross-control, the Java basic metrics over bounds and the Java coding rules discrepancies will improve the quality of the code. They will be taken into account at the end of the week

  14. Reutilization of the TM/TC activities 14h15 – 16.00

  15. Introduction • The aim of this presentation is to describe the new proposed activities to replaced the TM/TC activities. • The following activities are proposed: • The generation of the XML-Schema modelling XML-data • The generation of the XML-Schema used by the Derby software of GAEL Consultant • The modification of the Modeller to develop a "plug-in" system for several kind of generation

  16. The XML-schemas generation • This activity is to add a generation of XML-schemas from the DEBAT Modeller • The generated XML-Schemas have the same role against XML data than EAST against the ASCII/Binary data

  17. The XML-schemas generation • The XML Schemas generation should be based on the EAST generation. • The syntax of the generated XML Schemas will be compliant with the XML-Schemas recommendations • The generation will be easier than the EAST because some EAST features will not be used (the discriminated values) • The GUI of the Modeller can be reuse easily. • The Type library principle can be kept.

  18. The XML-schemas generation • This generation is proposed by CNES and could be used by : • The PLEIADE project • The COROT project

  19. The GAEL XML-schemas generation • This activity is to add a generation of XML-schemas from the DEBAT Modeller that can be read by the Derby software

  20. The GAEL XML-schemas generation • This generation can be based upon the EAST generation (from the XML-IF of Modeller) • The main function is to a provide a software for the generation of the Schemas for the use of the DERBY software. • The GAEL Schemas (DRB) is not compliant with the XML-Schemas recommendations because new tag are defined. • The main difficulty is the use of the XML-Query language to define the occurrence and the length of a data block. • The GUI of the Modeller have to be change.

  21. The Modeller modifications • To enhance the DEBAT capabilities with new formats generation, the Modeller GUI have to be modified. • In the XML-Schemas generation, the modification are easy • But in the GAEL XML-Schemas generation the modification are more complicated • IDEA : Modify the Modeller GUI to ease the adding of new format generation. This enhancement implies a redesign of the Modeller !!

More Related