DEBAT : Development of EAST Based Access Toolsdebat.c-s.fr/project/documents/doc/ADD1.1.doc ·...

DEBAT: Development of EAST Based Access ToolsArchitectural Design Document

Contract: 16562/02/I-LGReference: SS/DEBAT/ADDIssue: 1.1Date: 14/10/2003

Prepared by:

DEBAT teamDate:

Checked by:

Josiane DenailhacDate:

Approved by:

Laurent CohenDate:

DEBAT – Development of EAST Based Access Tools

Architectural Design Document Reference: SS/DEBAT/ADD Issue : 1.1 Date : 14/10/2003 Page : ii

Document Status Sheet

Document Title Architectural Design DocumentDocument Reference Number SS/DEBAT/ADD

Issue Revision Date Reason for change1 1 14/10/2003 First revision including corrections resulting from PDR1 0 08/07/2003 First version delivered for the PDR0 2 30/06/2003 Second draft version0 1 16/06/2003 First draft version


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : iii

Document Change Records

Document Title Architectural Design DocumentDocument Reference Number SS/DEBAT/ADDDocument Issue/Revision Number 1.1

Page Paragraph Reason for changeAll First revision after PDR – extensive rewriting has been made.


Page Paragraph Reason for changeAll First version


Page Paragraph Reason for changeAll Second draft version


Page Paragraph Reason for changeAll First draft version


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : iv

Table of contents

DOCUMENT STATUS SHEET......................................................................................................II

DOCUMENT CHANGE RECORDS............................................................................................III

TABLE OF CONTENTS................................................................................................................IV

TABLE OF FIGURES..................................................................................................................XIV

ACRONYMS AND ABBREVIATIONS.....................................................................................XXI

APPLICABLE DOCUMENTS.................................................................................................XXIII

REFERENCE DOCUMENTS..................................................................................................XXIV

1. INTRODUCTION..........................................................................................................................1

1.1 PURPOSE......................................................................................................................................11.2 SCOPE..........................................................................................................................................11.3 DEFINITIONS................................................................................................................................11.4 STRUCTURE OF THE DOCUMENT..................................................................................................2

2. SYSTEM OVERVIEW..................................................................................................................3

2.1.1 Background...........................................................................................................................32.1.2 Operational environment......................................................................................................3

3. FUNCTIONAL ARCHITECTURE.............................................................................................5

3.1.1 Improved EAST core.............................................................................................................73.1.2 DEBAT Integrated Environment...........................................................................................73.1.3 DEBAT Modeller..................................................................................................................83.1.4 DEBAT Producer and Editor................................................................................................83.1.5 DEBAT Extractor and Querying..........................................................................................83.1.6 DEBAT Utilities....................................................................................................................93.1.7 DEBAT Post-processing tools..............................................................................................93.1.8 DEBAT Packager..................................................................................................................93.1.9 DEBAT Local Web Site.........................................................................................................93.1.10 DEBAT Web Services.......................................................................................................10

4. SYSTEM DESIGN.......................................................................................................................11

4.1 DESIGN METHOD........................................................................................................................114.2 SOFTWARE DECOMPOSITION......................................................................................................11

4.2.1 Components decomposition view........................................................................................114.2.2 Dependencies......................................................................................................................13

5. COMPONENTS DESCRIPTION...............................................................................................18

5.1 DEBAT GENERAL FEATURES....................................................................................................195.1.1 Type.....................................................................................................................................19


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : v

5.1.2 Purpose...............................................................................................................................195.1.3 Function..............................................................................................................................205.1.4 Dependencies......................................................................................................................215.1.5 Interfaces............................................................................................................................215.1.6 Processing...........................................................................................................................225.1.7 Sketches of the GUI............................................................................................................25

5.2 INTEGRATED ENVIRONMENT.....................................................................................................265.2.1 Type.....................................................................................................................................265.2.2 Purpose...............................................................................................................................275.2.3 Function..............................................................................................................................275.2.4 Dependencies......................................................................................................................275.2.5 Interfaces............................................................................................................................29

5.2.5.1 Framework component...........................................................................................305.2.5.1.1 Type....................................................................................................................305.2.5.1.2 Purpose...............................................................................................................315.2.5.1.3 Function..............................................................................................................315.2.5.1.4 Dependencies......................................................................................................325.2.5.1.5 Interfaces............................................................................................................345.2.5.1.6 Processing...........................................................................................................345.2.5.1.7 Sketches of the GUI...........................................................................................385.2.5.1.8 Menu trees..........................................................................................................39

5.2.5.2 Plug in system component......................................................................................405.2.5.2.1 Type....................................................................................................................405.2.5.2.2 Purpose...............................................................................................................415.2.5.2.3 Function..............................................................................................................415.2.5.2.4 Dependencies......................................................................................................435.2.5.2.5 Interfaces............................................................................................................435.2.5.2.6 Processing...........................................................................................................44

5.2.5.3 Project Management component............................................................................475.2.5.3.1 Type....................................................................................................................475.2.5.3.2 Purpose...............................................................................................................475.2.5.3.3 Function..............................................................................................................485.2.5.3.4 Dependencies......................................................................................................485.2.5.3.5 Interfaces............................................................................................................505.2.5.3.6 Processing...........................................................................................................505.2.5.3.7 Sketches of the GUI...........................................................................................515.2.5.3.8 Menu trees..........................................................................................................52

5.3 EAST CORE...............................................................................................................................545.3.1 Type.....................................................................................................................................545.3.2 Purpose...............................................................................................................................565.3.3 Function..............................................................................................................................565.3.4 Dependencies......................................................................................................................585.3.5 Interfaces............................................................................................................................59

5.3.5.1 Java API component...............................................................................................605.3.5.1.1 Type....................................................................................................................605.3.5.1.2 Purpose...............................................................................................................615.3.5.1.3 Function..............................................................................................................615.3.5.1.4 Dependencies......................................................................................................61


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : vi

5.3.5.1.5 Interfaces............................................................................................................625.3.5.1.6 Processing...........................................................................................................63

5.3.5.2 Data Product Explorer component.........................................................................655.3.5.2.1 Type....................................................................................................................655.3.5.2.2 Purpose...............................................................................................................655.3.5.2.3 Function..............................................................................................................655.3.5.2.4 Dependencies......................................................................................................665.3.5.2.5 Processing...........................................................................................................675.3.5.2.6 Operations..........................................................................................................69

5.3.5.3 Interpreter component............................................................................................715.3.5.3.1 Type....................................................................................................................715.3.5.3.2 Purpose...............................................................................................................715.3.5.3.3 Function..............................................................................................................715.3.5.3.4 Dependencies......................................................................................................725.3.5.3.5 Interfaces............................................................................................................735.3.5.3.6 Processing...........................................................................................................745.3.5.3.7 Operations (only the new operations are described here)..................................78

5.3.5.4 Data Generator Component....................................................................................815.3.5.4.1 Type....................................................................................................................815.3.5.4.2 Purpose...............................................................................................................815.3.5.4.3 Function..............................................................................................................815.3.5.4.4 Dependencies......................................................................................................825.3.5.4.5 Interfaces............................................................................................................835.3.5.4.6 Processing...........................................................................................................845.3.5.4.7 Operations..........................................................................................................86

5.3.5.5 Queries handler component....................................................................................885.3.5.5.1 Type....................................................................................................................885.3.5.5.2 Purpose...............................................................................................................885.3.5.5.3 Function..............................................................................................................885.3.5.5.4 Dependencies......................................................................................................895.3.5.5.5 Interfaces............................................................................................................905.3.5.5.6 Processing...........................................................................................................905.3.5.5.7 Types..................................................................................................................915.3.5.5.8 Operations..........................................................................................................91

5.3.5.6 Data algorithms component....................................................................................925.3.5.6.1 Type....................................................................................................................925.3.5.6.2 Purpose...............................................................................................................925.3.5.6.3 Function..............................................................................................................925.3.5.6.4 Dynamic Java component..................................................................................93

5.3.5.6.4.1 Type.............................................................................................................935.3.5.6.4.2 Purpose........................................................................................................935.3.5.6.4.3 Function.......................................................................................................935.3.5.6.4.4 Dependencies...............................................................................................945.3.5.6.4.5 Processing....................................................................................................965.3.5.6.4.6 Types...........................................................................................................975.3.5.6.4.7 Operations...................................................................................................97

5.3.5.6.5 Random_Strings component..............................................................................985.3.5.6.5.1 Type.............................................................................................................98


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : vii

5.3.5.6.5.2 Purpose........................................................................................................985.3.5.6.5.3 Function.......................................................................................................985.3.5.6.5.4 Dependencies...............................................................................................985.3.5.6.5.5 Processing..................................................................................................1005.3.5.6.5.6 Types.........................................................................................................1025.3.5.6.5.7 Operations.................................................................................................102

5.3.5.6.6 Random_Numbers component.........................................................................1035.3.5.6.6.1 Type...........................................................................................................1035.3.5.6.6.2 Purpose......................................................................................................1045.3.5.6.6.3 Function.....................................................................................................1045.3.5.6.6.4 Dependencies.............................................................................................1045.3.5.6.6.5 Interfaces...................................................................................................1045.3.5.6.6.6 Processing..................................................................................................104

5.4 DEBAT DATA MODELLER......................................................................................................1065.4.1 Type...................................................................................................................................1065.4.2 Purpose.............................................................................................................................1075.4.3 Function............................................................................................................................1085.4.4 Dependencies....................................................................................................................1095.4.5 Interfaces..........................................................................................................................1115.4.6 Processing.........................................................................................................................112

5.4.6.1 GUI component....................................................................................................1145.4.6.1.1 Type..................................................................................................................1145.4.6.1.2 Purpose.............................................................................................................1155.4.6.1.3 Function............................................................................................................1165.4.6.1.4 Dependencies....................................................................................................1165.4.6.1.5 Processing.........................................................................................................1165.4.6.1.6 Sketches of a GUI.............................................................................................118

5.4.6.1.6.1 Description panel.......................................................................................1195.4.6.1.6.2 Semantic and syntactic panels...................................................................1215.4.6.1.6.3 Type library panel.....................................................................................1225.4.6.1.6.4 Semantic and syntactic search...................................................................1235.4.6.1.6.5 Modeller configuration..............................................................................123

5.4.6.1.7 Menu tree..........................................................................................................1255.4.6.1.7.1 Modeller frame menu................................................................................1255.4.6.1.7.2 Type library menus....................................................................................1265.4.6.1.7.3 Data model Tree menus.............................................................................127

5.4.6.2 Data Manager component....................................................................................1285.4.6.2.1 Type..................................................................................................................1285.4.6.2.2 Purpose.............................................................................................................1305.4.6.2.3 Function............................................................................................................130

5.4.6.2.3.1 -IF manager...............................................................................................1305.4.6.2.3.2 Type Library manager...............................................................................1305.4.6.2.3.3 Search manager.........................................................................................131

5.4.6.2.4 Interfaces..........................................................................................................1315.4.6.2.5 Processing.........................................................................................................131

5.4.6.2.5.1 JAXB generation.......................................................................................1315.4.6.2.5.2 Type library definition...............................................................................1325.4.6.2.5.3 Search........................................................................................................133


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : viii

5.4.6.3 Modeller Configuration component.....................................................................1355.4.6.3.1 Type..................................................................................................................1355.4.6.3.2 Purpose.............................................................................................................1355.4.6.3.3 Function............................................................................................................1355.4.6.3.4 Interfaces..........................................................................................................1365.4.6.3.5 Processing.........................................................................................................136

5.4.6.4 Files import component........................................................................................1375.4.6.4.1 Type..................................................................................................................1375.4.6.4.2 Purpose.............................................................................................................1385.4.6.4.3 Function............................................................................................................1385.4.6.4.4 Dependencies....................................................................................................1385.4.6.4.5 Interfaces..........................................................................................................1385.4.6.4.6 Processing.........................................................................................................139

5.4.6.5 Files generation component..................................................................................1415.4.6.5.1 Type..................................................................................................................1415.4.6.5.2 Purpose.............................................................................................................1425.4.6.5.3 Function............................................................................................................1425.4.6.5.4 Dependencies....................................................................................................1425.4.6.5.5 Interfaces..........................................................................................................1435.4.6.5.6 Processing.........................................................................................................143

5.4.6.5.6.1 Document generator..................................................................................1435.4.6.5.7 Type declarations generator.............................................................................145

5.4.6.6 Syntax component................................................................................................1465.4.6.6.1 Type..................................................................................................................1465.4.6.6.2 Purpose.............................................................................................................1475.4.6.6.3 Function............................................................................................................1475.4.6.6.4 Dependencies....................................................................................................1485.4.6.6.5 Interfaces..........................................................................................................1495.4.6.6.6 Processing.........................................................................................................149

5.4.6.7 Semantic component............................................................................................1515.4.6.7.1 Type..................................................................................................................1515.4.6.7.2 Purpose.............................................................................................................1525.4.6.7.3 Function............................................................................................................1525.4.6.7.4 Dependencies....................................................................................................1525.4.6.7.5 Interfaces..........................................................................................................1525.4.6.7.6 Processing.........................................................................................................153

5.5 DEBAT DATA PRODUCER & EDITOR.....................................................................................1555.5.1 Type...................................................................................................................................1555.5.2 Purpose.............................................................................................................................1565.5.3 Function............................................................................................................................1565.5.4 Dependencies....................................................................................................................158

5.5.4.1 External dependencies..........................................................................................1585.5.4.2 Internal dependencies...........................................................................................158

5.5.5 Interfaces..........................................................................................................................1595.5.6 Processing.........................................................................................................................160

5.5.6.1 GUI component....................................................................................................1625.5.6.1.1 Type..................................................................................................................1625.5.6.1.2 Purpose.............................................................................................................162


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ix

5.5.6.1.3 Function............................................................................................................1635.5.6.1.3.1 GUI Infrastructure.....................................................................................1635.5.6.1.3.2 Tree navigation GUI..................................................................................1645.5.6.1.3.3 Data products GUI.....................................................................................1645.5.6.1.3.4 Syntactic and semantic GUI......................................................................1645.5.6.1.3.5 Generation GUI.........................................................................................164

5.5.6.1.4 Dependencies....................................................................................................1655.5.6.1.5 Interfaces..........................................................................................................1655.5.6.1.6 Processing.........................................................................................................1655.5.6.1.7 Sketches of the GUI.........................................................................................1675.5.6.1.8 Menu trees........................................................................................................167

5.5.6.2 Data Manager component....................................................................................1695.5.6.2.1 Type..................................................................................................................1695.5.6.2.2 Purpose.............................................................................................................1695.5.6.2.3 Function............................................................................................................1705.5.6.2.4 Dependencies....................................................................................................1705.5.6.2.5 Interfaces..........................................................................................................1715.5.6.2.6 Processing.........................................................................................................172

5.5.6.2.6.1 Data model reading...................................................................................1735.5.6.2.6.2 Data reading..............................................................................................1735.5.6.2.6.3 Data edition...............................................................................................1755.5.6.2.6.4 Block deletion/insertion............................................................................1765.5.6.2.6.5 Undo/Redo.................................................................................................176

5.5.6.3 Data Storage component......................................................................................1775.5.6.3.1 Type..................................................................................................................1775.5.6.3.2 Purpose.............................................................................................................1775.5.6.3.3 Function............................................................................................................1775.5.6.3.4 Dependencies....................................................................................................1785.5.6.3.5 Interfaces..........................................................................................................1785.5.6.3.6 Processing.........................................................................................................179

5.5.6.4 Data Generator component...................................................................................1805.5.6.4.1 Type..................................................................................................................1805.5.6.4.2 Purpose.............................................................................................................1805.5.6.4.3 Function............................................................................................................1815.5.6.4.4 Dependencies....................................................................................................1815.5.6.4.5 Interfaces..........................................................................................................1825.5.6.4.6 Processing.........................................................................................................187

5.5.6.4.6.1 DirectivesManager....................................................................................1875.5.6.4.6.2 GenerationEngine......................................................................................189

5.5.6.5 Data checking component....................................................................................1905.5.6.5.1 Type..................................................................................................................1905.5.6.5.2 Purpose.............................................................................................................1905.5.6.5.3 Function............................................................................................................1905.5.6.5.4 Dependencies....................................................................................................1905.5.6.5.5 Interfaces..........................................................................................................1915.5.6.5.6 Processing.........................................................................................................191

5.5.6.6 Search capabilities component.............................................................................1925.5.6.6.1 Type..................................................................................................................192


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : x

5.5.6.6.2 Purpose.............................................................................................................1935.5.6.6.3 Function............................................................................................................1935.5.6.6.4 Dependencies....................................................................................................1935.5.6.6.5 Interfaces..........................................................................................................1945.5.6.6.6 Processing.........................................................................................................194

5.6 DEBAT DATA EXTRACTOR & QUERYING..............................................................................1955.6.1 Type...................................................................................................................................1955.6.2 Purpose.............................................................................................................................1965.6.3 Function............................................................................................................................1965.6.4 Dependencies....................................................................................................................1985.6.5 Interfaces..........................................................................................................................2005.6.6 Processing.........................................................................................................................201

5.6.6.1 GUI component....................................................................................................2025.6.6.1.1 Type..................................................................................................................2025.6.6.1.2 Purpose.............................................................................................................2035.6.6.1.3 Function............................................................................................................2035.6.6.1.4 Dependencies....................................................................................................2055.6.6.1.5 Processing.........................................................................................................2055.6.6.1.6 Sketches of the GUI.........................................................................................2065.6.6.1.7 Menu tree..........................................................................................................211

5.6.6.2 Data Manager component....................................................................................2125.6.6.2.1 Type..................................................................................................................2125.6.6.2.2 Purpose.............................................................................................................2135.6.6.2.3 Function............................................................................................................2135.6.6.2.4 Dependencies....................................................................................................2135.6.6.2.5 Interfaces..........................................................................................................2145.6.6.2.6 Processing.........................................................................................................214

5.6.6.3 Search capabilities component.............................................................................2175.6.6.3.1 Type..................................................................................................................2175.6.6.3.2 Purpose.............................................................................................................2175.6.6.3.3 Function............................................................................................................2185.6.6.3.4 Dependencies....................................................................................................2185.6.6.3.5 Processing.........................................................................................................219

5.6.6.4 XML-like queries component..............................................................................2235.6.6.4.1 Type..................................................................................................................2235.6.6.4.2 Purpose.............................................................................................................2235.6.6.4.3 Function............................................................................................................2235.6.6.4.4 Dependencies....................................................................................................2255.6.6.4.5 Processing.........................................................................................................226

5.6.6.5 Extraction.............................................................................................................2285.6.6.5.1 Type..................................................................................................................2285.6.6.5.2 Purpose.............................................................................................................2285.6.6.5.3 Function............................................................................................................2285.6.6.5.4 Dependencies....................................................................................................2295.6.6.5.5 Processing.........................................................................................................229

5.6.6.6 Data Storage.........................................................................................................2315.6.6.6.1 Type..................................................................................................................2315.6.6.6.2 Purpose.............................................................................................................231


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xi

5.6.6.6.3 Function............................................................................................................2315.6.6.6.4 Dependencies....................................................................................................2325.6.6.6.5 Interfaces..........................................................................................................2325.6.6.6.6 Processing.........................................................................................................232

5.6.6.7 Batch processing...................................................................................................2365.6.6.7.1 Type..................................................................................................................2365.6.6.7.2 Purpose.............................................................................................................2365.6.6.7.3 Function............................................................................................................2365.6.6.7.4 Dependencies....................................................................................................2375.6.6.7.5 Interfaces..........................................................................................................2375.6.6.7.6 Processing.........................................................................................................237

5.7 DEBAT UTILITIES...................................................................................................................2385.7.1 Type...................................................................................................................................2385.7.2 Purpose.............................................................................................................................2395.7.3 Function............................................................................................................................2395.7.4 Dependencies....................................................................................................................2405.7.5 Interfaces..........................................................................................................................241

5.7.5.1 Data checker component......................................................................................2415.7.5.1.1 Type..................................................................................................................2415.7.5.1.2 Purpose.............................................................................................................2435.7.5.1.3 Function............................................................................................................2435.7.5.1.4 Dependencies....................................................................................................2435.7.5.1.5 Interfaces..........................................................................................................2455.7.5.1.6 Processing.........................................................................................................2455.7.5.1.7 Sketches of the GUI.........................................................................................247

5.7.5.2 Ascii dump component.........................................................................................2485.7.5.2.1 Type..................................................................................................................2485.7.5.2.2 Purpose.............................................................................................................2485.7.5.2.3 Function............................................................................................................2485.7.5.2.4 Dependencies....................................................................................................2505.7.5.2.5 Interfaces..........................................................................................................2515.7.5.2.6 Processing.........................................................................................................2515.7.5.2.7 Sketches of the GUI.........................................................................................253

5.7.5.3 Comparison tool...................................................................................................2535.7.5.3.1 Type..................................................................................................................2535.7.5.3.2 Purpose.............................................................................................................2545.7.5.3.3 Function............................................................................................................2545.7.5.3.4 Dependencies....................................................................................................2545.7.5.3.5 Interfaces..........................................................................................................2565.7.5.3.6 Processing.........................................................................................................2565.7.5.3.7 Sketches of the GUI.........................................................................................257

5.8 DEBAT POST PROCESSING TOOLS.........................................................................................2585.8.1 Type...................................................................................................................................2585.8.2 Purpose.............................................................................................................................2595.8.3 Function............................................................................................................................2595.8.4 Dependencies....................................................................................................................2595.8.5 Interfaces..........................................................................................................................260

5.8.5.1 2D visualisation tool component..........................................................................261


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xii

5.8.5.1.1 Type..................................................................................................................2615.8.5.1.2 Purpose.............................................................................................................2625.8.5.1.3 Function............................................................................................................2625.8.5.1.4 Dependencies....................................................................................................2635.8.5.1.5 Interfaces..........................................................................................................2655.8.5.1.6 Processing.........................................................................................................2655.8.5.1.7 Sketches of the GUI.........................................................................................2675.8.5.1.8 Menu trees........................................................................................................269

5.8.5.2 Quick-look generator............................................................................................2695.8.5.2.1 Type..................................................................................................................2695.8.5.2.2 Purpose.............................................................................................................2705.8.5.2.3 Function............................................................................................................2705.8.5.2.4 Dependencies....................................................................................................2705.8.5.2.5 Interfaces..........................................................................................................2725.8.5.2.6 Processing.........................................................................................................2725.8.5.2.7 Sketches of the GUI.........................................................................................274

5.8.5.3 Data transformer...................................................................................................2745.8.5.3.1 Type..................................................................................................................2745.8.5.3.2 Purpose.............................................................................................................2755.8.5.3.3 Function............................................................................................................2755.8.5.3.4 Dependencies....................................................................................................2765.8.5.3.5 Interfaces..........................................................................................................2775.8.5.3.6 Processing.........................................................................................................2785.8.5.3.7 Sketches of the GUI.........................................................................................279

5.9 DEBAT PACKAGER.................................................................................................................2805.9.1 Type...................................................................................................................................2805.9.2 Purpose.............................................................................................................................2805.9.3 Function............................................................................................................................2805.9.4 Dependencies....................................................................................................................2815.9.5 Interfaces..........................................................................................................................2825.9.6 Processing.........................................................................................................................283

5.10 WEB.......................................................................................................................................2855.10.1 Type.................................................................................................................................2855.10.2 Function..........................................................................................................................2855.10.3 Dependencies..................................................................................................................2875.10.4 Interfaces........................................................................................................................2895.10.5 Processing.......................................................................................................................289

5.10.5.1 Services component..............................................................................................2915.10.5.1.1 Type................................................................................................................2915.10.5.1.2 Purpose............................................................................................................2925.10.5.1.3 Function..........................................................................................................2925.10.5.1.4 Dependencies..................................................................................................2925.10.5.1.5 Interfaces.........................................................................................................2945.10.5.1.6 Processing.......................................................................................................294

5.10.5.2 Web Site component............................................................................................2965.10.5.2.1 Type................................................................................................................2965.10.5.2.2 Purpose............................................................................................................2985.10.5.2.3 Function..........................................................................................................298


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xiii

5.10.5.2.4 Dependencies..................................................................................................2995.10.5.2.5 Interfaces.........................................................................................................3005.10.5.2.6 Processing.......................................................................................................300

6. Traceability matrix.....................................................................................................................302


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xiv

Table of figures

Figure 2-1 DEBAT operational environment.......................................................................................4Figure 3-1 DEBAT global architecture................................................................................................6Figure 4-1 DEBAT software decomposition view.............................................................................11Figure 4-2 DEBAT software package view.......................................................................................12Figure 4-3 DEBAT dependencies – EAST core services...................................................................14Figure 4-4 DEBAT dependencies – General features services..........................................................15Figure 4-5 DEBAT dependencies – Integrated Environment services..............................................16Figure 4-6 DEBAT dependencies – Modeller, DPE and DEQ..........................................................17Figure 4-7 DEBAT dependencies – Web...........................................................................................17Figure 5-1 General features Package View........................................................................................19Figure 5-2 General features component dependency.........................................................................21Figure 5-3 General features component interfaces.............................................................................22Figure 5-4 Installation class diagram.................................................................................................22Figure 5-5 Help system class diagram...............................................................................................23Figure 5-6 Printer and ScreenShot class diagram..............................................................................23Figure 5-7 Internationalisation class diagram....................................................................................24Figure 5-8 Help viewer.......................................................................................................................25Figure 5-9 Integrated Environment Components Decomposition View............................................26Figure 5-10 Integrated Environment Components Package View.....................................................26Figure 5-11 Integrated Environment external dependencies..............................................................28Figure 5-12 Integrated Environment internal dependencies..............................................................29Figure 5-13 Integrated Environment interfaces..................................................................................29Figure 5-14 Framework component Packages View.........................................................................30Figure 5-15 Framework functional logic............................................................................................32Figure 5-16 Framework dependencies...............................................................................................33Figure 5-17 Framework interfaces.....................................................................................................34Figure 5-18 FrameworkManager class diagram.................................................................................35Figure 5-19 “Start DEBAT” sequence diagram.................................................................................36Figure 5-20 “Start plug-in” sequence diagram...................................................................................37Figure 5-21 Logbook class diagram...................................................................................................37Figure 5-22 FrameworkFrame............................................................................................................38Figure 5-23 FrameworkConfigurationFrame.....................................................................................38Figure 5-24 LogbookFrame................................................................................................................38Figure 5-25 Plug in component Package View..................................................................................40Figure 5-26 Plug-in system services definition..................................................................................42Figure 5-27 Plug-in system functional logic......................................................................................43Figure 5-28 Plug-in system interfaces................................................................................................44Figure 5-29 Plug-in system class diagram.........................................................................................45Figure 5-30 Black-box plug-in interface............................................................................................46Figure 5-31 Project management component Package View.............................................................47Figure 5-32 Project management functional logic.............................................................................48Figure 5-33 Project Management component interfaces....................................................................49Figure 5-34 Project Management interfaces......................................................................................50Figure 5-35 ProjectManager class diagram........................................................................................51


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xv

Figure 5-36 ProjectManagementFrame..............................................................................................52Figure 5-37 File chooser widget.........................................................................................................52Figure 5-38 EAST core component decomposition view..................................................................54Figure 5-39 EAST core components view.........................................................................................54Figure 5-40 EAST core component dependencies.............................................................................58Figure 5-41 EAST core component interfaces...................................................................................59Figure 5-42 Java API component decomposition view......................................................................60Figure 5-43 Java API packages view.................................................................................................60Figure 5-44 Java API component dependency view..........................................................................61Figure 5-45 Java API component interfaces......................................................................................62Figure 5-46 Java API component class diagram................................................................................63Figure 5-47 Structural (types) Diagram of Data_Product_Explorer component...............................66Figure 5-48 Functional (operations) Diagram of Data_Product_Explorer component......................67Figure 5-49 Structural (types) Diagram of Interpreter component....................................................72Figure 5-50 Functional (oper.) Diagram of Interpreter component...................................................73Figure 5-51 Interpreter component interfaces....................................................................................73Figure 5-52 Structural (types) Diagram of Interpreter component....................................................77Figure 5-53 Functional (operations) Diagram of Interpreter component...........................................78Figure 5-54 Structural (types) Diagram Data_Generator component...............................................82Figure 5-55 Functional (operations) Diagram Data_Generator component.....................................83Figure 5-56 Data Generator interfaces...............................................................................................84Figure 5-57 Structural (types) Diagram Data_Generator component...............................................85Figure 5-58 Functional (operations) Diagram Data_Generator component......................................86Figure 5-59 East_Query_Handler Structural (types) Diagram...........................................................89Figure 5-60 East_Query_Handler Functional (operations) Diagram.................................................90Figure 5-61 Data Algorithms component decomposition view.........................................................92Figure 5-62 External function during data reading............................................................................94Figure 5-63 External function during data reading............................................................................94Figure 5-64 DYNAMIC_JAVA Structural (types) Diagram.............................................................95Figure 5-65 DYNAMIC_JAVA Functional (operations) Diagram...................................................96Figure 5-66 Dynamic_Java component processing............................................................................97Figure 5-67 Structural (types) Diagram of Random Strings..............................................................99Figure 5-68 Functional (operations) Diagram of Random Strings...................................................100Figure 5-69 Structural (types) Implementation Diagram of Random Strings..................................101Figure 5-70 Functional (operations) Implementation Diagram of Random Strings........................102Figure 5-71 Random_Numbers component Structural (types) Diagram.........................................103Figure 5-72 Random_Numbers Functional (operations) Diagram...................................................104Figure 5-73- DEBAT Modeller components decomposition view..................................................106Figure 5-74 DEBAT Modeller components Package View.............................................................106Figure 5-75 Modeller functional logic.............................................................................................109Figure 5-76: Modeller components external dependencies view.....................................................110Figure 5-77: Modeller components dependencies view...................................................................111Figure 5-78 Modeller component Interface view.............................................................................112Figure 5-79 Modeller component class diagram..............................................................................113Figure 5-80: ModellerServicesInterface class..................................................................................114Figure 5-81: GUI component package view....................................................................................115Figure 5-82: GUI component dependencies.....................................................................................116Figure 5-83: GUI component class diagram....................................................................................118


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xvi

Figure 5-84: ModellerFrame............................................................................................................119Figure 5-85: description panel..........................................................................................................120Figure 5-86:Element Modification frame.........................................................................................121Figure 5-87: Type Library panel......................................................................................................122Figure 5-88: Search frame................................................................................................................123Figure 5-89: Configuration frame....................................................................................................124Figure 5-90: Configuration frame....................................................................................................124Figure 5-91:DataManager component package view.......................................................................129Figure 5-92: Data Manager Component Interface view...................................................................131Figure 5-93 Modeller XML-IF file manager architecture................................................................132Figure 5-94 Type Library Manager..................................................................................................133Figure 5-95 Search manager architecture.........................................................................................134Figure 5-96: Data Manager Component class diagram....................................................................134Figure 5-97: Modeller Configuration component package view.....................................................135Figure 5-98: Modeller Configuration interface view.......................................................................136Figure 5-99 Modeller XML-IF file manager architecture................................................................136Figure 5-100: :Files Import component package view.....................................................................137Figure 5-101: Files Import Interface View.......................................................................................138Figure 5-102: :Files Generation component Interface view.............................................................139Figure 5-103 OASIS-IF files import component.............................................................................139Figure 5-104 EAST import files generator architecture...................................................................140Figure 5-105: :Files Generation component class diagram..............................................................141Figure 5-106: :Files Generation component package view..............................................................141Figure 5-107: Files generation component dependencies view.......................................................143Figure 5-108: Files Generation Interface view.................................................................................143Figure 5-109 document generator architecture.................................................................................144Figure 5-110 Type declaration generator architecture.....................................................................145Figure 5-111: Files Generation class diagram..................................................................................146Figure 5-112: Syntax component package view..............................................................................147Figure 5-113: Syntax component dependencies view......................................................................148Figure 5-114 : Syntax Component Interface view...........................................................................149Figure 5-115 EAST checker architecture.........................................................................................149Figure 5-116 Format file generator..................................................................................................150Figure 5-117 : Syntax Component class diagram............................................................................151Figure 5-118: Syntax component package view..............................................................................151Figure 5-119: Semantic component dependencies view..................................................................152Figure 5-120 : Semantic Component Interface view........................................................................153Figure 5-121 DEDSL checker architecture......................................................................................153Figure 5-122 : Semantics Component class diagram.......................................................................154Figure 5-123 DPE Components Decomposition View....................................................................155Figure 5-124 DPE Components Package View...............................................................................155Figure 5-125 DPE Component Functional Logic.............................................................................157Figure 5-126 DPE Dependency General View................................................................................158Figure 5-127 DPE Components Dependency Detailed View..........................................................159Figure 5-128 DPE Component Interfaces View...............................................................................160Figure 5-129 DPE Component Class Diagram................................................................................161Figure 5-130 GUI Component Package View.................................................................................162Figure 5-131 DPE GUI infrastructure..............................................................................................164


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xvii

Figure 5-132 GUI software dependency view.................................................................................165Figure 5-133 GUI component class diagram...................................................................................166Figure 5-134 DPE frame..................................................................................................................167Figure 5-135 Data Manager Component Package View..................................................................169Figure 5-136 Data Manager software dependency view..................................................................171Figure 5-137 Data Manager Interface View.....................................................................................171Figure 5-138 Data Manager Class Diagram.....................................................................................172Figure 5-139 “Read data model” sequence diagram........................................................................173Figure 5-140 “Read from socket” sequence diagram.......................................................................174Figure 5-141 “Read from file” sequence diagram............................................................................175Figure 5-142 Data Storage Component Package View....................................................................177Figure 5-143 Data Storage software dependency view....................................................................178Figure 5-144 Data Storage Interface View.......................................................................................178Figure 5-145 Data Storage Class Diagram.......................................................................................179Figure 5-146 Data Generator Component Package View................................................................180Figure 5-147 Data Generator Software Dependency View..............................................................181Figure 5-148 “Generate new block” sequence diagram...................................................................182Figure 5-149 Data Generator Interface view....................................................................................182Figure 5-150 Data model of the example.........................................................................................185Figure 5-151 Data Generator Class Diagram...................................................................................187Figure 5-152 Data Checking Software Dependency View..............................................................190Figure 5-153 Data Checking Interface view....................................................................................191Figure 5-154 Data Checking Class Diagram....................................................................................191Figure 5-155 Search Capabilities Component Package View..........................................................192Figure 5-156 Search Capabilities Software Dependency View.......................................................194Figure 5-157 Search Capabilities Class Diagram.............................................................................194Figure 5-158 DEQ components decomposition view......................................................................195Figure 5-159 DEQ components package view.................................................................................195Figure 5-160 Data Extractor & Querying component functional logic............................................198Figure 5-161 Data Extractor & Querying component dependencies...............................................199Figure 5-162 DEQ components detailed dependencies...................................................................200Figure 5-163 DEQ component interfaces.........................................................................................201Figure 5-164 DEQ component classes diagram...............................................................................202Figure 5-165 GUI component package view...................................................................................203Figure 5-166 DeqMainFrame...........................................................................................................204Figure 5-167 GUI component dependencies....................................................................................205Figure 5-168 DEQ graphical interface class diagram......................................................................206Figure 5-169 DeqMainFrame GUI...................................................................................................207Figure 5-170 QueryWizardFrame GUI............................................................................................208Figure 5-171 QueryFrame GUI........................................................................................................209Figure 5-172 QueryResultsFrame GUI (display by elements).........................................................209Figure 5-173 QueryResultsFrame GUI (display by blocks)............................................................210Figure 5-174 – ExtractionFrame GUI..............................................................................................210Figure 5-175 – XMLViewsFrame GUI............................................................................................211Figure 5-176 - Data Manager components package view................................................................212Figure 5-177 - Data Manager components dependencies................................................................213Figure 5-178 - Data Manager component interfaces view...............................................................214Figure 5-179 - DataModelManager class diagram (XML-IF loading)............................................215


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xviii

Figure 5-180 - DataManager class diagram (data reading)..............................................................216Figure 5-181 - XMLViews class diagram........................................................................................216Figure 5-182 - Search capabilities component package view..........................................................217Figure 5-183 -Search capabilities component dependencies...........................................................219Figure 5-184 ExistenceCheck class diagram....................................................................................220Figure 5-185 - Existence Check sequence diagram.........................................................................221Figure 5-186 - SyntacticSemanticSearchManager class diagram....................................................222Figure 5-187 – XML-like queries component package decomposition view..................................223Figure 5-188 - XML-like queries component dependencies............................................................225Figure 5-189 XML-like queries component class diagram..............................................................226Figure 5-190 - Query processing sequence diagram........................................................................227Figure 5-191 - Extraction component package view........................................................................228Figure 5-192 - Extraction component dependencies........................................................................229Figure 5-193 - Extraction component class diagram........................................................................230Figure 5-194 - Extraction sequence diagram...................................................................................230Figure 5-195 - Data storage components package view..................................................................231Figure 5-196 – Data storage component dependencies...................................................................232Figure 5-197 Data Storage interfaces..............................................................................................232Figure 5-198 Data Storage component class diagram.....................................................................233Figure 5-199 – Query results file saving sequence diagram............................................................234Figure 5-200 - Socket storage sequence diagram.............................................................................235Figure 5-201 Batch processing components package view.............................................................236Figure 5-202 - Batch processing component dependencies.............................................................237Figure 5-203 - Batch processing component interfaces...................................................................237Figure 5-204 - BatchProcessing component class diagram..............................................................237Figure 5-205 Utilities Component Decomposition view.................................................................238Figure 5-206 Utilities Component Packages view...........................................................................238Figure 5-207 Utility component dependency view..........................................................................240Figure 5-208 Utilities component interfaces....................................................................................241Figure 5-209 Data checker component package view......................................................................242Figure 5-210 Data checker functional logic.....................................................................................243Figure 5-211 Data checker component dependency view................................................................244Figure 5-212 Data checker component interfaces............................................................................245Figure 5-213 Data checker class diagram........................................................................................246Figure 5-214 Data checking sequence diagram...............................................................................247Figure 5-215 DataCheckerFrame.....................................................................................................247Figure 5-216 Ascii dump component package view........................................................................248Figure 5-217 Ascii-dump functional logic.......................................................................................249Figure 5-218 Ascii dump component dependencies........................................................................250Figure 5-219 Ascii dump component interfaces..............................................................................251Figure 5-220 Ascii dump class diagram...........................................................................................252Figure 5-221 Ascii dump sequence diagram....................................................................................252Figure 5-222 AsciiDumpFrame........................................................................................................253Figure 5-223 Comparison tool package view...................................................................................253Figure 5-224 Comparison tool functional logic...............................................................................254Figure 5-225 Comparison tool component dependencies................................................................255Figure 5-226 Comparison tool component interfaces......................................................................256Figure 5-227 Comparison tool class diagram...................................................................................257


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xix

Figure 5-228 ComparatorFrame.......................................................................................................257Figure 5-229 Post-Processing Tools component decomposition view............................................258Figure 5-230 Post-Processing Tools component package view.......................................................258Figure 5-231 Post-Processing Tools component Dependencies......................................................260Figure 5-232 Post-processing tools interfaces..................................................................................261Figure 5-233 2D visualisation component packages view...............................................................261Figure 5-234 2D visualisation tool functional logic.........................................................................263Figure 5-235 2D visualisation component dependencies.................................................................264Figure 5-236 2D visualisation component interfaces.......................................................................265Figure 5-237 ChartManager class diagram......................................................................................266Figure 5-238 MainFrame class diagram...........................................................................................267Figure 5-239 2D visualisation tool MainFrame...............................................................................267Figure 5-240 2D visualisation tool ChartFrame...............................................................................268Figure 5-241 2D visualisation tool GraphSetFrame.........................................................................268Figure 5-242 2D visualisation tool GraphFrame..............................................................................268Figure 5-243 Quick look generator component package view.........................................................269Figure 5-244 Quicklook generator component functional logic......................................................270Figure 5-245 Quick look generator component dependencies.........................................................271Figure 5-246 Quick look generator component interfaces...............................................................272Figure 5-247 Quick look generator class diagram...........................................................................273Figure 5-248 Quick look generation sequence diagram...................................................................274Figure 5-249 QuickLookGeneratorFrame........................................................................................274Figure 5-250 Data transformer component package view...............................................................275Figure 5-251 Data transformer component functional logic............................................................276Figure 5-252 Data transformer component dependencies................................................................277Figure 5-253 Data transformer component interfaces......................................................................277Figure 5-254 Data transformer class diagram..................................................................................278Figure 5-255 Transform to XML sequence diagram........................................................................279Figure 5-256 DataTransformerFrame..............................................................................................279Figure 5-257 Packager component package view............................................................................280Figure 5-258 DEBAT packager functional logic.............................................................................281Figure 5-259 Packager component dependencies............................................................................282Figure 5-260 Packager component interfaces..................................................................................283Figure 5-261 Packager class diagram...............................................................................................284Figure 5-262 Web Components decomposition view......................................................................285Figure 5-263 - Web component package decomposition.................................................................285Figure 5-264 DEBAT Web Services................................................................................................286Figure 5-265 Web dependencies views............................................................................................288Figure 5-266 Web internal dependencies views...............................................................................288Figure 5-267 Web component interfaces.........................................................................................289Figure 5-268 Local Web Site global software architecture..............................................................290Figure 5-269 Web Services Components decomposition view........................................................291Figure 5-270 – Web services component package decomposition..................................................291Figure 5-271: Services component internal dependencies...............................................................293Figure 5-272 Web Services component interfaces...........................................................................294Figure 5-273: Web services class diagram.......................................................................................296Figure 5-274 Web site Components decomposition view................................................................296Figure 5-275 – Web site component package decomposition..........................................................297


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xx

Figure 5-276 Local Web Site logical model....................................................................................299Figure 5-277: Services component internal dependencies...............................................................299Figure 5-278 Web site component interfaces...................................................................................300Figure 5-279: Web site class diagram..............................................................................................301


Architectural Design Document Reference: SS/DEBAT/ADD Issue : 1.1 Date : 14/10/2003 Page : xxi

Acronyms and Abbreviations

ADD Architectural Design DocumentAMS Archive Management SystemAPI Application Program InterfaceAR Acceptance ReviewATP Authorisation To ProceedCA Control AuthorityCAID Control Authority IdentifierCAO Control Authority OfficeCAOS Control Authority Office SystemCDF Common Data FormatCDR Critical Design ReviewCEOS Committee on Earth Observation ScienceCFI Customer Furnished ItemCNES Centre National D’Etudes Spatiales (French Space Agency)COTS Commercial Off The ShelfCCSDS Consultative Committee for Space Data SystemsDEAL Display EAST Access ListDEBAT Development of EAST Based Access ToolsDM DEBAT Data ModellerDPE DEBAT Data Producer & EditorDEQ DEBAT Data Extractor & QueryingPPT DEBAT Post Processing ToolsUT DEBAT UtilitiesDDR Data Description RecordDDU Data Description UnitDDF Design Definition FileDED Data Entity DictionaryDEDSL Data Entity Description Specification LanguageDEW Data Extractor WizardDIP Dissemination Information PackageDJF Design Justification FileDUW Data Update WizardDW DEBAT WorkshopEAST Enhanced ADA Sub SeTECSS European Cooperation for Space StandardizationEO Earth ObservationESA European Space AgencyESRIN European Space Research INstituteERS European Remote Sensing satelliteESA European Space AgencyEVA ESA Virtual ArchiveFA Final AcceptanceFAQ Frequently Asked QuestionFAR Factory Acceptance ReviewFAT Factory Acceptance Tests


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxii

FDIR Fault Detection, Isolation and RecoveryFP Final PresentationFPA Final Presentation and AcceptanceGUI Graphical User InterfaceHDF Hierarchical Data FormatHTML Hyper Text Mark-up LanguageHTTP Hyper Text Transfer ProtocolHW HardwareICD Interface Control DocumentIDVP Implementation, Diffusion and Validation PlanIR Interface RequirementsITT Invitation To TenderJSP Java Server PagesKOM Kick Off MeetingMACAO Member Agency Control Authority OfficeMMI Man-Machine InterfaceNAS Network Attached StorageOAIS Open Archival Information SystemOASIS Space Data Modelling Help Tool OSAT On Site installation and Acceptance TestsPAP Product Assurance PlanPDR Preliminary Design ReviewPMP Project Management PlanPUS Packet Utilisation StandardPVL Parameter Value LanguageRB Requirements BaselineRID Review Item DiscrepancyRTD Research and Technology DevelopmentSCMP Software Configuration Management PlanSIP Submission Information PackageSOAP Simple Object Access ProtocolSOW Statement of WorkSPMP Software Project Management PlanSRR System Requirements ReviewSVG Scalable Vector GraphicTM/TC Telemetry / TelecommandTS Technical SpecificationsUDDI Universal Description Discovery and IntegrationSRD Software Requirements DocumentURD User Requirements DocumentWSDL Web Service Description LanguageWWW World Wide WebXML eXtensible Mark-up LanguageXSL eXtensible Stylesheet LanguageXSLT eXtensible Stylesheet Language Transformation


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxiii

Applicable Documents

Title Issue Date ReferenceAD1 ESRIN SOW “Development of

EAST Based Access Tools”1.1 18/03/2002 GSPS-RTDA-EOAD-SW-02-0001

AD2 Fax received from ESA 07/06/2002 IMT-CR/9021/02/I-LG

AD3 CS SI Proposal "DEBAT" 21/06/2002 CSSI/111-1/CG/LM/2/453-1

AD4 Minutes of Kick-off Meeting 17/09/2002 /CRR/SS/DEBAT/001

AD5 ECSS – Space Engineering Standards – Software ECSS-E-40B

ECSS-E-40B

AD6 CS SI Proposal for Phase 2 March 2003 CSSI/111-1/CG/PKV/3/140

AD7 Minutes of Phase 2 Kick-off meeting (Authorisation To Proceed)

30/04/2003 /CRR/SS/DEBAT/006


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxiv

Reference Documents

Title Issue Date ReferenceRD1 DEBAT - Project Management Plan 1.2 08/07/2003 SS/DEBAT/PMP

RD2 DEBAT - Product Assurance Plan 1.2 08/07/2003 SS/DEBAT/PAP

RD3 DEBAT – User Requirements Document

1.2 10/03/2003 SS/DEBAT/URD

RD4 DEBAT – Software Requirements Document

1.1 10/03/2003 SS/DEBAT/SRD

RD5 DEBAT – Interface Control Document

1.0 08/07/2003 SS/DEBAT/ICD

RD6 The Data Description Language EAST Specification (CCSD0010). Blue Book.

2.0 November 2000

CCSDS 644.0-B-2

RD7 The Data Description Language EAST - A Tutorial. Green Book.

1.0 May 1997 CCSDS 645.0-G-1

RD8 The Data Description Language EAST - List of Conventions. Green Book.

1.0 May 1997 CCSDS 646.0-G-1

RD9 Data Entity Dictionary Specification Language (DEDSL) - Abstract Syntax (CCSD0011). Blue Book.

1.0 June 2001 CCSDS 647.1-B-1

RD10 Data Entity Dictionary Specification Language (DEDSL) - PVL Syntax (CCSD0012). Blue Book.

1.0 June 2001 CCSDS 647.2-B-1

RD11 Data Entity Dictionary Specification Language (DEDSL) - XML/DTD Syntax (CCSD0013). Blue Book.

1.0 January 2002

CCSDS 647.3-B-1


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxv

1. Introduction

1.1 Purpose

This document takes place in the frame of the DEBAT – Development of EAST Based Access Tools – project. DEBAT is aimed at building a set of enhanced tools based upon the EAST technology to support the entire data life cycle for various kind of users.

This document describes the architecture design of the DEBAT software. The architecture design results from the analysis of the Software Requirements Document [RD8].

1.2 Scope

This document is the Architectural Design Document of DEBAT. It describes the software specifications, the design and behaviour of the global software and of its sub-components.

1.3 Definitions

Data Model The data model is the name of the DEBAT Data Modeller internal format of a data format description. This internal format (often called IF) contains all the syntactic and semantic information of the data. It is created, modified and read by the DEBAT Data Modeller and is used to generate the EAST and DEDSL description files.

IF or OASIS-IF Internal Format: this is the old internal format used by OASIS (the old Modeller). This file follows an in-house textual formalism that is difficult to read and handle.

XML-IF XML-Internal Format: this is the new internal format used by the Modeller to store the data model information under the form of an XML document.

EAST description file The EAST description file contains the syntactic information of a data model in the EAST format. This file conforms to the EAST CCSDS recommendation. It is created by the DEBAT Data Modeller and is used by all the other tools to read, generate, extract, check data products.

DEDSL description file The DEDSL description file contains the semantic information of a data model in the DEDSL format. This file conforms to the DEDSL CCSDS recommendation. It is created by the DEBAT Data Modeller and is used by all the other tools when the semantic information of a data product are managed.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxvi

1.4 Structure of the document

This document is structured as follows:

Chapter 1: IntroductionThe current chapter gives the objectives, scope, definitions and structure of the document.

Chapter 2: System OverviewThis chapter presents an overview of the system.

Chapter 3: Functional ArchitectureThis chapter presents the functional architecture of DEBAT.

Chapter 4: Components DescriptionThis chapter describes the architectural design of the components that forms the DEBAT software.

Chapter 6: Traceability matrixThis chapter gathers the traceability information.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxvii

2. System overview

2.1.1 Background

EAST (which stands for "Enhanced ADA Subset") was primarily imagined by CNES and designed in the framework of CCSDS Panel II (CCSDS 644.0-B-1 and ISO 15889:2000). As the name implies, EAST is based upon the ADA language (in fact, EAST is 100% compliant with the ADA syntax). EAST is the specification of formalism designed to create non-ambiguous descriptions of data formats including syntactic (logical and physical) information.

DEDSL (Data Entity Dictionary Specification language) was also designed in the framework of CCSDS Panel II. It allows adding semantic information to the data by the means of semantic attributes. Two implementations are available: one in PVL (Parameter Value Language), the other one in XML (eXtensible Mark-up Language).

The technology has been primarily developed to provide complete, perennial, easily understandable and evolutionary descriptions of data formats (with enough flexibility to allow the description of almost any data formats down to whatever level of detail required), and to provide engineers, scientists and end-users with generic tools for supporting the technology: to easily describe the data formats and make them evolve, to produce quickly test data independently from the storage media, and to access and extract the values of the data without having to write specific code.

The DEBAT project is the continuation of the work done for several years on EAST technologies.

The main objective of DEBAT is to improve and extend the set of tools built in support of EAST to provide engineers, scientists and end-users with a coherent set covering the entire data life cycle (define, generate, access, check, extract, generate samples of, describe and document data products).

2.1.2 Operational environment

The functions of DEBAT are accessible through the following external interfaces:

Man Machine Interface: DEBAT provides a user-friendly MMI that allows the users to execute all the available functions.

API’s: DEBAT offers a wide range of possible connections through the availability of API’s in ADA, C, C++, FORTRAN and JAVA. These API’s allow the user applications to be linked directly to the libraries of functions provided in DEBAT.

Web interface: The Web interface provides access to a subset of the DEBAT functions (the most useful ones) using a Web browser as interface. This interface is therefore intended to allow the direct use of the DEBAT functions whatever the target platform and without any specific installation.

SOAP interface (Web services interface): The Web Service interface provides access to some of the DEBAT functions for remote user applications through a SOAP interface.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxviii

Figure 2-1 DEBAT operational environment

The external interfaces of DEBAT are described in the Interface Control Document [RD5].


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxix

3. Functional architecture

Satisfy: SR1_DEBAT Conformity: CSR8_DEBAT Conformity: CSR9_DEBAT Conformity: CSR14_DEBAT Conformity: CSR15_DEBAT Conformity: CSR16_DEBAT Conformity: C SR20_DEBAT Conformity: CSR21_DEBAT Conformity: CSR22_DEBAT Conformity: CSR23_DEBAT Conformity: CSR39_DEBAT Conformity: CSR40_DEBAT Conformity: CSR417_PERFORMANCE Conformity: C SR418_PERFORMANCE Conformity: CSR419_PERFORMANCE Conformity: CSR434_RELIABILITY Conformity: CSR435_CONSTRAINT Conformity: CSR436_CONSTRAINT Conformity: CSR437_CONSTRAINT Conformity: C SR425_RESOURCE Conformity: C SR426_ RESOURCE Conformity: CSR427_ RESOURCE Conformity: CSR428_ RESOURCE Conformity: C SR429_ RESOURCE Conformity: CSR430_ RESOURCE Conformity: CSR431_ RESOURCE Conformity: CSR432_ RESOURCE Conformity: C

DEBAT can basically be seen as 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. Several high-level components (or tools) are also provided on top of EAST to add further capabilities to the suite of tools.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxx

USERPLUG-IN

DEBAT FRAMEWORK

DEBAT DATA

MODELLER

DEBAT DATA

PRODUCER & EDITOR

DEBAT DATA

EXTRACTOR & QUERYING

DEBAT POST-

PROCESSINGTOOLS

DEBAT UTILITIES

DEBAT WEBINTERFACE

EAST / DEDSL

DEBAT PACKAGER

EAST CORE

JAVA API ADA API FORTRAN API C/C++ API

WEB SITE

DEBAT WEB

SERVICES

DATA PRODUCTSXML

USERPLUG-INUSER

PLUG-IN

USERPLUG-IN

PROJECTMANAGEMENT

Figure 3-2 DEBAT global architecture

DEBAT is designed with a modular and integrated architecture, which is primarily meant to allow the replacement or the addition of functions with no impact on the other.The user can plug his own application into DEBAT so as to enhance or modify the capabilities of the suite of tools. The user plug-ins are automatically and transparently recognised and handled by DEBAT. It’s worth mentioning that the tools provided “by default” in DEBAT (such as the Modeller, the Producer & Editor, etc.) are basically plug-in themselves and are managed in the same way.

The architecture of DEBAT is designed with enough flexibility so that the tools can be used easily in different ways.DEBAT can be used directly as a standalone suite of tools (with almost no regard to architectural issues) as it is the current practice with the current EAST. DEBAT can also be easily integrated in existing systems (archive systems, for example) as it is not an intrusive or hegemonic architecture, and as it provides a wide range of possible connections through API's, command line invocations, man machine interfaces and Web/TCP-IP and pipes interfaces. DEBAT can also be used as a generic data framework providing the building blocks necessary to create your own system upon the DEBAT architecture.

DEBAT is built with modern technologies and makes (only!) extensive use of free and open source product (no runtime cost is associated with DEBAT). Furthermore, DEBAT is portable on the following three platforms: Unix, Linux, and Windows. The DEBAT suite of tools will be made available freely for users under the form of a binary distribution (no COTS license will be required).

The previous diagram gives a graphic overview of the global architecture of the DEBAT suite of tools; the main components are described in the following paragraphs.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxxi

3.1.1 Improved EAST core

DEBAT is build around the EAST core that forms the backbone of the software.

The existing capabilities of EAST are left unchanged (a strict requirement is the backward compatibility). The EAST core provides mainly the low-levels functions used by all the other tools in order to analyse, handle and process the EAST descriptions and the associated data products.

The EAST core is basically a set of low-level libraries implemented in ADA and allowing mainly: to read, analyse, handle and process EAST descriptions,

to read data products conforming to a given EAST description,

to generate data products conforming to a given EAST description,

to check an EAST description file against the EAST CCSDS recommendation,

to check a given data products against its EAST description.

Furthermore, several significant improvements to the existing capabilities are added, such as: the addition of calculation capabilities to enhance the descriptive power of the

technology.

the addition of enhanced data checking capabilities to be able to check binary data expressing the checking constraints in an XML-Schema like fashion.

the addition of the ability to define "external functions" associated with a data description. These functions are dynamically linked and executed at runtime (no compilation needed) by DEBAT when reading/writing from/to a data package. This feature is particularly useful as it allows to enhance/modify at runtime the behaviour of EAST without the need to write and compile a separate program. This can be used to apply specific transformations to the raw data being read before returning them to the calling application (e.g. to apply a calibration curve), or during the writing process (e.g., for the reverse purpose when generating test data).

some performances improvements so as to be able to face continuously increasing volumes of data.

A wide range of connections with existing programming languages is also provided through the availability of API's in ADA, C, C++, FORTRAN and JAVA.

3.1.2 DEBAT Integrated Environment

One key concept of DEBAT is the Integrated Environment support that gathers three components: The DEBAT Framework, a Plug-in system, and the Project Management support.

The DEBAT Framework proposes a simple and intuitive access to the suite of tools through a user-friendly GUI that can be highly customised by each user according to his specific needs and preferences. The main goal of the framework is to provide a homogeneous look and feel and behaviour, and to allow the sharing of data between the tools (data model, raw data, extracted data, etc).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxxii

The Plug-in system intends to provide users with a mechanism to extend the suite of tools by adding new applications in the framework. This extensibility is a key concept allowing to plug-in specific applications in the framework. These plug-ins are automatically and transparently recognised and handled by DEBAT.

The Project Management support provides a virtual organisation of the file system allowing to gather in one bundle all the files related to a given project/mission (data models, data files, documentation, etc.); all the tools in the integrated environment access the same logical organisation of the files.

3.1.3 DEBAT Modeller

The DEBAT Modeller is one of the most useful tools and provides support for defining, specifying and modelling data formats through a graphical interface. It supports the definition of the logical model – i.e. the data structure, the data type, the range of possible values, etc. and the definition of the physical model – i.e. encoding format of the data on the medium. It also supports the definition of the semantic information related to a data format.Once the definition of the data model completed, the Modeller is able to generate the EAST description containing all the syntactic information and the DEDSL description containing all the semantic information.

The Modeller provides valuable documentation capabilities allowing documenting data formats in XML, HTML, and PDF or WORD formats. The generated documentation is automatically handled by DEBAT and is fully customisable.

A new concept of Type Library is also provided. This facility is intended to allow the reuse and the sharing of predefined types (sub-parts of data models) between several data formats or projects/missions. This new functionality is really valuable, timesaving, and therefore cost saving, as it allows the definition of reusable libraries that can be shared and distributed among several projects/missions.

3.1.4 DEBAT Producer and Editor

The DEBAT Producer & Editor tool offers an easy access to the data products. It is mainly designed to display and edit data products in a graphical tree-view representation, and to navigate through this representation using the mouse, shortcuts and search capabilities.

The DEBAT Producer & Editor is also capable of easily and automatically generating data products conforming to their data model (no coding required!) with two customisable generation modes: fully automatic generation (all the data values are generated randomly) or user-controlled process (the user can define how the values are to be generated).

3.1.5 DEBAT Extractor and Querying

Users might not be interested in all the values contained in a data product and may want to extract only subsets of a data product and to generate smaller data packages that could be easily disseminated over the network. This is particularly relevant for very large data files that are difficult to handle and transport.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxxiii

The DEBAT Extractor & Querying tool is primarily designed to provide a solution to this need, by making it easy to extract values from data products responding to given search criteria (e.g. time, value…) and to create new data packages upon these results. The DEBAT Extractor & Querying uses an XML-Query like language to process complex queries on the data products and allows a batch processing mode.

3.1.6 DEBAT Utilities

The DEBAT Utilities are independent useful applications that can be invoked from the command-line or directly from the DEBAT MMI. Three utilities are mainly provided: the ascii-dump tool, the data-checker and a comparison tool.

The ascii-dump is a small utility used to generate an ascii representation of a data product in a simple tabular form or in XML. This capability is often and mainly used for debugging purposes.

The data-checker is a standalone tool that takes as input a data product and an EAST description and is able to verify if the data product conforms to the given EAST description.

The comparison tool is primarily intended to compute and display the differences between two data models. This feature is useful to follow-up the evolutions/modifications of the data models during their lifecycle, and to identify or document the changes.

3.1.7 DEBAT Post-processing tools

The DEBAT Post-processing set comprises three tools: a customisable 2D visualisation tool able to plot the data contained within a data

product,

a Quick-look generator able to generate quick-looks from raw data,

a Data transformer able to transform raw binary data products into XML documents in a customisable way. This feature is peculiarly useful for projects/missions that have chosen to work internally with XML, but have to face and handle other and potentially binary formats.

3.1.8 DEBAT Packager

The data distribution comes at the end of the data lifecycle. The DEBAT packager provides packaging and compression capabilities to ease the dissemination of data packages (data alone, data and descriptions, data and documentation, etc.).

3.1.9 DEBAT Local Web Site

The DEBAT Local Web Site provides a Web Interface (through HTTP) accessible through a Web browser to access remotely some functions of DEBAT. For example, a data archive will be able to provide to users the means to extract only the part(s) of the archived products that are of interest (as opposed to e.g. downloading the whole product and then performing the selection), or to generate a sample data set complying with a given format definition.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxxiv

3.1.10 DEBAT Web Services

DEBAT also provides a Web Services interface (through SOAP) allowing remote user applications to access some of the DEBAT functions. For example, a remote application will be able to request that a particular data product be checked against a format description available on the remote server.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxxv

4. System design

4.1 Design method

The design method used for DEBAT is UML for Java components and HOOD for Ada components.

4.2 Software decomposition

4.2.1 Components decomposition view

The current section gives the decomposition of the software into its main components.

A static decomposition view is first provided showing the breakdown of the components from a logical viewpoint. A package view is then presented: this one shows the component decomposition in software packages that implement the logical components. A table showing the mapping between the logical component (together with a short description of the component purpose) and the associated packages implementing the functionality of the component is then presented. A dependency view is then given showing the relationships between the components.

DEBAT<<System>>

Integrated Env ironment<<Component>>

EAST core<<Component>>

Modeller<<Component>>

Data Producer & Editor<<Component>>

Data Extractor & Querying<<Component>>

General features<<Component>>

Uti lities<<Component>>

PostProcessing Tools<<Component>>

Packager<<Component>>

Web Site<<Component>>

Web Services<<Component>>

Figure 4-3 DEBAT software decomposition view


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxxvi

debat(f rom Packages Decomposition)

cs ie modeller

dpe deq ppt uti l ities

east

packager web

ie

uti l ities

Figure 4-4 DEBAT software package view

The following table shows the mapping between the logical decomposition of the component and the packages that implement the component.

Component Purpose Implementation packages

General features Provides all the functions common to the DEBAT tools: installation support, internationalisation, help support, screenshot and printing capabilities.

cs.*

Integrated Environment Provides the DEBAT framework, a plug in system and the project management support.

ie.*

EAST core Provides the low-levels functions used by the other tools in order to analyse, handle and process the EAST descriptions and the associated data products.

east.*

Modeller Provides support for defining, specifying and modelling data formats through a graphical interface.

modeller.*

Data Producer & Editor Provides functions to read, edit and generate data products that conform to an EAST description through a graphical interface.

dpe.*


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxxvii

Component Purpose Implementation packages

Data Extractor & Querying Provides functions to search for/extract values from data products (using XML queries) responding to given search criteria (e.g. time, value…) and to create new data packages upon these results.

deq.*

Utilities Provides independent useful applications to generate a dump of a data product in a text or XML file (ascii-dump component), to verify that a given product conforms to its EAST description (data-checker component) and to compare two different XML-IF data models (comparison component).

utilities.*

Post Processing tools Provides a 2D visualisation tool to plot data, a quick-look generator, and a data transformer component able to transform raw binary data into XML in a customisable way.

ppt.*

Packager Provides packaging and compression capabilities to ease the dissemination of data packages.

packager.*

Web site Provides a Web Interface (through HTTP) accessible through a Web browser to access remotely some of DEBAT functions.

web.site.*

Web services Provides a web services interface (through SOAP) allowing remote user applications to access some of DEBAT functions.

web.services.*

4.2.2 Dependencies

The following diagrams show the dependencies between the software components that are part of DEBAT. For a better understanding of the various dependencies of the software, the dependencies are split into several diagrams.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxxviii



Data Extractor & Query ing<<Component>>



Web Serv ices<<Component>>

EAST serv ices: read / existence check / process XML queries

EAST services : dump/check

EAST serv ices: read/check/search/extract/generate/transf orm to XML

EAST serv ices: quick look generation/transf orm to XML

EAST serv ices: read / edit / generate / store

Figure 4-5 DEBAT dependencies – EAST core services

The EAST core component is used by several other components. The Data Producer & Editor component uses the EAST core:

to read EAST descriptions and associated data products,

to edit a data product,

to generate data blocks/products,

and, to store the edited/generated data on the medium.

The Data Extractor & Querying component uses the EAST core:


to perform “existence checks”, i.e. to verify the existence of an element in a given data product,

and, to perform XML queries on data products.

The Post Processing Tools component uses the EAST core:

to support the generation of quick looks images,


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xxxix

and, to perform the transformation of raw data into XML.

The Utilities component uses the EAST core:

to dump data products into XML or text files,

and, to check that a data product conforms to its EAST description.

The Web services component uses the EAST core:


to check that a data product conforms to its EAST description,

to search within data products (existence check and values search),

to generate data blocks products,

and, to perform the transformation of raw data into XML.

The General features component provides services that are used by several other components (installation, internationalisation support, online help, screenshots functions, and printing).

General f eatures<<Component>>

Integrated Environment<<Component>>








Prov ides serv ices used by all the other components:- installation- internationalisation- online help- sreenshot f unction- printing

Figure 4-6 DEBAT dependencies – General features services


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xl

The Integrated Environment component provides the Project Management component and defines the plug-in interface that shall be implemented by the other components in order to be integrated within the suite of tools.








Prov ides the Project Management component that is used by the other tools to acces the v irtual organisation of the f iles and the f iles within a project and def ines the plug-in interf ace that shall be implemented by the other tools

Figure 4-7 DEBAT dependencies – Integrated Environment services

For what regards the dependencies between the Modeller, the Data Producer& Editor and the Data Extractor & Querying components:

The Modeller component provides the ability to load XML-IF files into memory and the semantic and syntactic search capabilities that are used by the Data Producer & Editor and by the Data Extractor & Querying components.

The Data Extractor & Querying component provides the values search capabilities that are used by the Data Producer & Editor.

The Utilities (Data checker) component provides the data checking capabilities (themselves through the EAST core services) to the Data Producer & Editor.

The Utilities (Ascii dump) component provides the ability to create XML views (itself through the EAST core services) to the Data Extractor & Querying component.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xli





cal l data checker

XML-IF loading / Sy ntax & Semantic search


Values search creates XML v iews

Figure 4-8 DEBAT dependencies – Modeller, DPE and DEQ

Regarding the web functions provided in DEBAT, the Web Site component relies on the Web services component for all of its functions; the Web services in turn implements its services using the EAST core component.


Web Serv ices<<Component>>


EAST serv ices: read/check/search/extract/generate/transf orm to XML

read/check/search/extract/generate/transf orm to XML

Figure 4-9 DEBAT dependencies – Web


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xlii

5. Components descriptionThe current chapter describes the components that are part of the DEBAT architecture.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xliii

5.1 DEBAT general features

5.1.1 Type

The General features component is implemented in the cs.* package.

cs(from debat)

installation help property print screenshot

Figure 5-10 General features Package View

The following table shows the contents of each package and the classes that are part of it.

Package Contents Classes

cs.installation.* Classes for the installation procedure

CustomInstallerCustomUninstallerInstallerFrame

cs.help.* Classes implementing the help system

HelpManagerHelpViewer

cs.property.* Classes managing internationalisation

Resource

cs.print.* Printing classes Printercs.screenshot.* Screenshot classes Screenshot


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xliv

5.1.2 PurposeSatisfy: SR4_DEBAT Conformity: C

SR5_DEBAT Conformity: CSR6_DEBAT Conformity: CSR7_DEBAT Conformity: CSR25_DEBAT Conformity: CSR26_DEBAT Conformity: CSR27_DEBAT Conformity: CSR28_DEBAT Conformity: CSR29_DEBAT Conformity: CSR30_DEBAT Conformity: CSR433_DOCUMENTATION Conformity: CSR41_DEBAT Conformity: CSR43_DEBAT Conformity: CSR44_DEBAT Conformity: CSR45_DEBAT Conformity: CSR46_DEBAT Conformity: CSR47_DEBAT Conformity: CSR2_DEBAT Conformity: CSR3_DEBAT Conformity: CSR26_DEBAT Conformity: C

5.1.3 Function

Some general capabilities are common to all the DEBAT tools. They comprise: The installation procedure allowing the installation of DEBAT on a target machine.

The current EAST tools have different installation procedures that change according to the tools but also according to the platform where they are to be installed. On the contrary, the installation procedure of DEBAT is unique and allows to install the entire environment. It is the same for all the tools and for all the platforms, and can be automatic (all the DEBAT environment and tools are installed) or custom (the user can choose the tools he wants to install). A un-installation procedure is also provided.

The internationalisation mechanism allowing the users to choose the MMI language.

All the man-machine interface of DEBAT is provided by default in English (menus, buttons, labels, messages…). However, DEBAT provides an internationalisation mechanism allowing to add another language easily without having to change the source code of DEBAT, or to recompile the product. The choice of the language to use (provided it is available) can be done by the user during the installation, or by reconfiguring the software when it is running. The choice of the language also affects the online help system that displays the help in the selected language (if available).

An online help documenting all the available functions.

DEBAT provides an online help documenting all the available functions. This help is provided in HTML and is accessible from the DEBAT graphical interface. This help is similar to the Win Help available on almost all Windows platforms: it offers a visual interface (MMI) with a table of contents, the support for URL’s and links and text search capabilities.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xlv

A screenshot function allowing the users to “capture” some parts of the DEBAT graphical interface.

A screenshot function is implemented in DEBAT so as to provide the users with the ability to “capture” some parts of the DEBAT MMI. The screen-captures can then be saved as JPEG images for printing or for inclusion in the documentation of the data formats being defined with DEBAT (e.g. tree-views structures of the data models, tables, syntactic/semantic information).

And, printing capabilities enabling the users to print text files.

Printing capabilities are also provided: they enable to print text files (data models, EAST or DEDSL descriptions) directly from the DEBAT MMI.

5.1.4 Dependencies

The General features component provides services used by all the other components. It depends on the JavaHelp library for the implementation of the online help system and on the InstallAnywhere COTS for the installation procedure.



Model ler<<Component>>







Prov ides serv ices used by all the other components:- installation- internationalisation- online help- sreenshot f unction- printing

Jav aHelp library<<JAR file>>

InstallAny where<<COTS>>

uses

uses

Figure 5-11 General features component dependency


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xlvi

5.1.5 Interfaces

The General features component has the following interfaces: It reads the help information that is stored in jar-packaged help set files (each help set

contains the HTML help pages, the list of the help topics and the mapping between the help topics and the HMTL pages).

It reads an XML configuration file that defines the help configuration (list of help sets with associated language).

It takes as input property files and image files that are used for the internationalisation (these files contain the texts to be internationalised, i.e. menus, labels, buttons, error messages, references to the image files).

It reads an XML configuration file that defines the configuration of the installation (plug-ins/tools to install by default).


HelpSet<<JAR f ile>>

Conf iguration<<XML File >>

load

load help conf iguration

Property f ile<< Text f ile >>

read

conf iguration<<XML f ile>>

load installation conf iguration

jpeg, gi f file<<Image f ile>>

read

Figure 5-12 General features component interfaces

5.1.6 Processing

The installation procedure is implemented with an Installer Product (InstallAnywhere). This product offers user-friendly graphical interfaces to help the user during the installation process.The installation / un-installation is managed by the CustomInstaller / CustomUninstaller classes. They take as input the XML configuration file that defines the plug-ins available/installed, and they display an InstallerFrame that helps the user during the installation process.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xlvii

CustomInstal ler

installAll()installToolBy Name()load()

CustomUninstaller

uninstallAll()uninstallToolBy Name()load()

conf iguration<<XML f ile>>

load

load

InstallAny where<<COTS>>

uses

InstallerFrame

show()

displays

uses

display s

Figure 5-13 Installation class diagram

The on-line help is implemented with the Java-Help technology. Java-Help software is a platform-independent, extensible help system that enables developers and authors to incorporate online help in applets, components, applications, operating systems, and devices. More information can be found at http://java.sun.com/products/javahelp/index.html.

The help is implemented with the HelpManager class that is in charge of: reading an XML configuration file defining the list of the help sets and associated

language,

loading the help sets in memory,

and, displaying the help through the HelpViewer.


http://java.sun.com/products/javahelp/index.html

Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xlviii

HelpManager

load()loadHelpSets()display Help()

HelpViewer

displays

HelpSet<<JAR f ile>>

Conf iguration<<XML File >>

loadHelpsets

1..1

0..n

load conf iguration

Jav aHelp library<<JAR file>>

uses

Figure 5-14 Help system class diagram

Screenshots and printing capabilities are implemented using the built-in mechanisms of the Java language through two classes: Printer and ScreenShot.

Printer

run() : v oidprintFile(f ile : String) : v oidprintTable(table : JTable) : v oidprintText(text : String) : v oidprintComponent(component : Component) : v oidprintImage(im : Image) : v oid

Screenshot

doScreenShot(component : Component) : v oidsav eScreenShot(f ileName : String) : v oid

(from screenshot)

Figure 5-15 Printer and ScreenShot class diagram


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xlix

The internationalisation mechanism is implemented through the use of external resource files. The texts to be internationalised (menus, labels, buttons, error messages…) are not directly hard-coded in the source code, but instead, written into external files (called property files in the Java terminology). Each text is associated with a given key and the source code only refers to the key. This allows changing the text in the MMI without having to change the source code (only the property file has to be modified).For dealing with the internationalisation issue, there are as many property files as available languages (one property file per language). The property files are named with the following conventions:

[name]_[language]_[country].property

For instance, a MMI frame called MainFrame that can be displayed in three languages would have its labels stored in the following property files:

MainFrame_en_EN.property (English language)MainFrame_fr_FR.property (French language)MainFrame_es_ES.property (Spanish language)

When running, DEBAT looks for the MMI labels within the right property file according to the language chosen by the user.This mechanism is implemented with the Resource class that is able to read the right property file according to the selected language.

Resource

Resource(o : Object)Resource(o : Object, createLocalizedBundle : boolean)Resource(o : Object, locale : Locale, createLocalizedBundle : boolean)Resource(className : String)Resource(className : String, createLocalizedBundle : boolean)Resource(className : String, locale : Locale, createLocalizedBundle : boolean)getString(key : String) : StringgetImageResource(resourceName : String) : URLgetSoundResource(resourceName : String) : URLgetFileResource(resourceName : String) : URLtoString() : StringsetNullStringValueAllowed(nullStringValueAllowed : boolean) : v oidsetNullImageResourceAllowed(nullImageResourceAllowed : boolean) : v oidsetNullSoundResourceAllowed(nullSoundResourceAllowed : boolean) : v oidsetNullFileResourceAllowed(nullFileResourceAllowed : boolean) : v oid

Property f ile<< Text f ile >>

jpeg, gi f file<<Image f ile>>

1..n 1..n

Figure 5-16 Internationalisation class diagram


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : l

5.1.7 Sketches of the GUI

The HelpViewer has three panes: A toolbar: A bar over the navigation and content panes that displays toolbar buttons

(Back, Forward, and Print)

A navigation pane: A tabbed interface appearing on the left that allows users to switch between the table of contents, index, and full text search displays.

A content pane: A pane on the right that displays help topics formatted with HTML 3.2 or later.

The following figure shows an example of a help viewer:

Figure 5-17 Help viewer


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : li

5.2 Integrated Environment

5.2.1 Type

The Integrated Environment component is composed of three components as shown in the following decomposition view:

Integrated Env ironment<<Component>>

Framework<<Component>>

Plugin System

<<Component>>

Project Management<<Component>>

Figure 5-18 Integrated Environment Components Decomposition View

The Integrated Environment component is implemented in the ie.* package.

ie(from debat)

framework plugin projectMgt

Figure 5-19 Integrated Environment Components Package View


Component Purpose Associated packages

Framework Provides a single and intuitive access to the set of DEBAT tools/plug-in through a customisable MMI.

ie.framework.*

Plug in System The Plug-in system is primarily meant to allow the addition or replacement of new functions within the suite of tools. This mechanism enables users to add/upgrade/remove a tool in the framework with no impact

ie.plugin.*


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lii


on the other tools.Project Management Provides a virtual organisation

of the file system that gathers all the files related to a given project.

ie.projectMgt.*


SR32_DEBAT Conformity: CSR34_DEBAT Conformity: CSR35_DEBAT Conformity: CSR36_DEBAT Conformity: CSR37_DEBAT Conformity: C

5.2.3 Function

The Integrated Environment comprises three sub-components: a Framework component providing a user-friendly GUI to access the set of DEBAT functions, a Plug-in system component providing users with a mechanism to extend/modify the suite of tools, and, a Project Management component providing a virtual organisation of the file system.

5.2.4 Dependencies

The next diagram shows the dependencies between the Integrated Environment component and the other components of DEBAT.

The Modeller, Data Producer & Editor, Data Extractor & Querying, Utilities, Post-Processing Tools, and Distribution components implements the plug-in interface defined by the Plug-in System component.

They also use the Project Management component to access the virtual organisation of the project files.

The Project Management and the Framework component uses the General features component for the installation support, internationalisation, online help, screenshots functions, and printing.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : liii





Data Extractor & Query ing<<Component>> Uti lities

<<Component>>



installation,internationaliation, help, screenshots, print

access project/f iles - implements plugin interf ace

Figure 5-20 Integrated Environment external dependencies

The next diagram shows the dependencies between the components of the Integrated Environment.

The Project Management component is itself developed as a plug-in and therefore it shall implement the plug-in interface provided by the Plug-in System.

The Framework component provides a MMI with which the user interacts. The user actions are then forwarded to the Plug-in System for activating the plug-in. Moreover, the Framework component is also in charge of instanciating the various plug-in/tools of the DEBAT suite.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : liv


Plugin Sy stem<<Component>>


implements plug-in interf ace

User

f orwards MMI calls

instanciates plug-ins

Figure 5-21 Integrated Environment internal dependencies

5.2.5 Interfaces


Framework conf iguration<<XML file>>

Projects conf iguration<<XML file>>

Java<<Plugin>>

Black box<<Plugin>>

Logbook<<Text f ile>>

load

load

load

load

sendMessage

save

save

save

init, start, stop, messageReceiv ed init, start, stop, messageReceiv ed

load

sendMessage

Figure 5-22 Integrated Environment interfaces


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lv

The Integrated Environment has the following interfaces: It uses an XML file to store the configuration of the Framework component.

It uses another XML file to store the definition of the projects (used by the Project Management component).

It uses a text file to store the messages sent to the logbook.

It is able to load Java plug-in and black box plug-in (i.e. written in another language) and to communicate with them.

5.2.5.1 Framework component

5.2.5.1.1 TypeThe Framework component is implemented in the ie.framework.* package

ie(from debat)

framework

logbook(f rom f ramework)

gui(f rom f ramework)

Figure 5-23 Framework component Packages View



ie.framework.* High level and services interface classes

FrameworkManagerFrameworkServicesInterface

ie.framework.gui.* MMI classes FrameworkFrameFrameworkConfigurationFrameFrameworkConfigurationTreePluginPanel

ie.framework.logbook.* Gathers all the classes that implement the logbook function

LogbookMessageMessageTypeLogbookFrame


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lvi

5.2.5.1.2 PurposeSatisfy: SR48_INTEGRATEDENV Conformity: C

SR49_INTEGRATEDENV Conformity: CSR50_INTEGRATEDENV Conformity: CSR54_INTEGRATEDENV Conformity: CSR55_INTEGRATEDENV Conformity: CSR57_INTEGRATEDENV Conformity: CSR48_INTEGRATEDENV Conformity: CSR52_INTEGRATEDENV Conformity: CSR53_INTEGRATEDENV Conformity: CSR54_INTEGRATEDENV Conformity: CSR55_INTEGRATEDENV Conformity: CSR56_INTEGRATEDENV Conformity: CSR57_INTEGRATEDENV Conformity: CSR58_INTEGRATEDENV Conformity: CSR49_INTEGRATEDENV Conformity: CSR50_INTEGRATEDENV Conformity: C

5.2.5.1.3 Function

The framework proposes a single and intuitive access to the set of tools/plug-ins. It provides a homogeneous look and feel and behaviour through a user-friendly GUI that can be customised by each user.

The framework MMI uses a configuration file that describes the number of tools to be displayed, the name and icon of each tool, and the action to be triggered when clicking on a given icon. The framework is fully re-configurable and allows to enable/disable the plug-ins, to define/modify the name, the icon and the command associated to the plug-ins.

The framework also provides a logbook that stores and displays all the messages, warnings and errors raised by the tools.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lvii

Figure 5-24 Framework functional logic

5.2.5.1.4 DependenciesThe Framework component uses the Plugin system component:

to instanciate Plugin objects from the definition read from the configuration file,

to add Plugins to the plug-in list managed by the PluginManager object,

to forward the calls to a plug-in to the PluginManager in charge of communicating with the plug-in loaded.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lviii


Plugin System<<Component>>

FrameworkManager

load()sav e()f orwardCall()getPlugins()getPluginBy Name()addPlugin()remov ePlugin()

(from framework)

Plugin

nameicontooltipshortDescriptionty pepathstartCommandstatus$ JAVA_PLUGIN$ BLACKBOX_PLUGIN

(from objects)

PluginFolder

nameicontooltip

(f rom objects)

10..*

1

+plugin list

0..*has

PluginManager

getPlugins()getPluginBy Name()addPlugin()remov ePlugin()f orwardCall()

(from plugin)

add plugin / forward call

1

0..*

1-plugin list

0..*

holds

1

0..*

1

0..*

holds

instanciates

Figure 5-25 Framework dependencies


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lix

5.2.5.1.5 Interfaces


FrameworkManager

load()sav e()f orwardCall()getPlugins()getPluginBy Name()addPlugin()remov ePlugin()

(from framework)

Framework conf iguration<<XML file>>


Logbook

load()sav e()appendMessage()

(from logbook)

save load

FrameworkServ icesInterf ace

appendMessageToLogbook()

(from framework)

f orward call

This interf ace is called by the other tools/plugin to add a message to the logbook

load save

Figure 5-26 Framework interfaces

5.2.5.1.6 Processing

The Framework component has three sub-components built in Java: the FrameworkFrame, the FrameworkConfigurationFrame and the FrameworkManager. The graphical interfaces are built with the SWING Java library. The Swing toolkit is a fully featured User Interface component library implemented entirely in the Java programming language. More information can be found at http://java.sun.com/docs/books/tutorial/uiswing.

The FrameworkFrame is the entry point of the DEBAT software. It consists of a MMI that looks like a tool bar where the plug-in icons and names are displayed. When an icon is clicked, the framework GUI forwards the call to the FrameworkManager component.


http://java.sun.com/docs/books/tutorial/uiswing

Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lx

FrameworkConf igurationTree

(from gui)

PluginPanel

(from gui)

1

1

1

1

FrameworkConf igurationFrame

show()

(from gui)

display s

FrameworkFrame

show()

(from gui)

sends MMI events

displays / updates

sends MMI events

save load

FrameworkManager

load()sav e()f orwardCall()getPlugins()getPluginByName()addPlugin()removePlugin()

Conf iguration<<XML f ile>>

Figure 5-27 FrameworkManager class diagram

The FrameworkManager is in charge of reading the XML configuration file that defines the available plug-ins and their configuration. It is also in charge of forwarding the calls to a plug-in to the PluginManager component.

The XML configuration file is defined by an XML schema, and contains the following information:

Property Meaning

Name The short meaningful name of the plug-in Icon The icon to be displayed in the GUITool-tip The tool-tip to be displayed in the GUI when the mouse is over the

tool’s icon


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxi

Property Meaning

Short description A short description of the capabilities of the tool

Plug-in type The Integrated Environment supports two types of plug-ins: Java plug-ins that have full access to DEBAT (as DEBAT is

mainly written in Java) Other (non-Java) plug-ins with more limited interactions with

DEBAT (black-box executables).Plug-in location The path to the Java plug-in (the jar archive that forms the plug-in) or

to the executable if it is not written in Java.Plug-in start command The “command” to start the plug-in.:

For a Java plug-in: the fully qualified name of the class that is the entry point of the plug-in

For other plug-in: the command-line to start the executableStatus (enabled / disabled) This flag indicates is the plug-in is active and must be displayed in the

framework GUI or disabled and hidden in the GUI.

The FrameworkConfigurationFrame displays the list of available plug-ins with their properties and allows the user to change the configuration of the framework. The changes are stored in the XML configuration file by the FrameworkManager component.

The following diagram shows how the various components interact when a user starts DEBAT.

: FrameworkManager

: User

: PluginManager : FrameworkFrame : PluginLoader

start DEBAT

load XML conf iguration

create Plugin

addPlugin to PluginManager list

loadPlugin(Plugin)

show( )

For each plug-in/tool of the DEBAT sui te

Figure 5-28 “Start DEBAT” sequence diagram


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxii

The following sequence diagram shows how the various components interact when a user starts a plug-in.

: User : FrameworkFrame : FrameworkManager : PluginManager Plugin X : PluginInterface

start plugin X

forwardCall("start","X")

forwardCall("start", "X")

start( )

Figure 5-29 “Start plug-in” sequence diagram

The Logbook is used to store Messages that are sent by the other tools/plug-ins.

LogbookFrame

show()

(f rom logbook)

displays

Logbook

load()sav e()appendMessage()

(from logbook)


save

load

Message

number : intdate : Datesender : Stringty pe : MessageTy pecontent : String

(from logbook)

0..*

1

11

MessageTy pe

$ INFO$ ERROR$ WARNING

(f rom logbook)

Figure 5-30 Logbook class diagram


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxiii

5.2.5.1.7 Sketches of the GUIThe following pictures show sketches of the Framework GUI.The FrameworkFrame is the entry point of the DEBAT suite of tools. It displays a tool bar where each tool/plug-in is shown with an icon. An icon can also represent several plug-ins: in this case, clicking on the icon displays a popup menu representing the list of available plug-ins.

Figure 5-31 FrameworkFrame

The FrameworkConfigurationFrame is the frame that allows the user to configure the framework. This frame is split in two areas: on the left, there is a tree showing the available plug-ins (FrameworkConfigurationTree); on the right there is a panel that displays the information associated to the plug-in selected in the tree (PluginPanel); i.e. name, icon, tool-tip, short description, plug-in type, plug-in location, plug-in start command, and status.

Figure 5-32 FrameworkConfigurationFrame

The LogbookFrame displays the messages stored in the logbook.

Figure 5-33 LogbookFrame


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxiv

5.2.5.1.8 Menu trees

By default the FrameworkFrame displays the following icons/menus:

Menu/Icon Sub-menus Description

DEBAT configuration

Launches the framework configuration MMI

Project Manager Launches the project management MMIData Modeller Launches the ModellerData Producer & Editor

Launches the Data Producer & Editor

Data Extractor & Querying

Launches the Data Extractor & Querying

Post-Processing Tools

2D visualisation Launches the 2D visualisation toolQuick-look generator Launches the quick look generator

Comparison tool Launches the comparison toolUtilities Ascii dump Launches the ascii dump tool

Data checker Launches the data checker toolData transformer Launches the data transformer tool

Logbook Displays the logbook MMI

The FrameworkConfigurationFrame displays the list of the available plug-ins in a tree-like fashion. When right-clicking on the nodes of the tree, one can access the following functions:

Node type Menus Description

Plug-ins (root node)

Add plug-in Add a new plug-in to the top level of the suite of tools

Plug-in folder (i.e. a folder containing several plug-ins)

Add plug-in Add a new plug-in to the selected plug-in folder

Plug-in node (leaf of the tree)

Edit Allows the user to edit the plug-in properties

Remove Remove the plug-in from the DEBAT suite of tools

The user can change the location of a plug-in from a folder to another one by drag-and-drop.

The logbook provides the following menu tree:


File Open Open a new logbook filePrint Print le logbook

Export Export the logbook to text


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxv


Close Close the logbook frameFilter Number Filter the logbook by number ranges

Date Filter the logbook by datesSender Filter the logbook by sendersType Filter the logbook by message types

Content Filter the logbook by contentComplete logbook Display the entire logbook

Edit Add message Adds manually a message to the logbook

5.2.5.2 Plug in system component

5.2.5.2.1 TypeThe Plug in System component is implemented in the ie.plugin.* package

ie(from debat)

plugin

objects(from plugin)

interface(from plugin)

Figure 5-34 Plug in component Package View



ie.plugin.* High level classes PluginManagerPluginLoader

ie.plugin.objects.* Classes that defines what a “plug-in” is.

PluginPluginFolder

ie.plugin.interface.* Define the interface that all the tools/plug-ins shall implement

PluginInterfaceBlackboxWrapper


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxvi


SR59_INTEGRATEDENV Conformity: CSR60_INTEGRATEDENV Conformity: CSR61_INTEGRATEDENV Conformity: CSR62_INTEGRATEDENV Conformity: CSR63_INTEGRATEDENV Conformity: CSR64_INTEGRATEDENV Conformity: CSR65_INTEGRATEDENV Conformity: C

5.2.5.2.3 FunctionThe Plug-in system is primarily meant to allow the addition or replacement of new functions within the suite of tools. This mechanism enables users to add/upgrade/remove a tool in the framework with no impact on the other tools. This property makes it easy to extend indefinitely the capabilities of DEBAT.

The plug-in concept is fundamental in DEBAT: exactly as user plug-ins, all the tools provided by default are themselves plug-ins (“all is plug-in”) and are managed as such.

The Plug-in system is responsible for the monitoring and control of the tools: it is in charge of loading into memory, starting, monitoring, and stopping the plug-ins when requested by the user.

Bi-directional communications between The Plug-in system and the plug-ins are handled transparently. The Plug-in system is able to send messages to the plug-ins being executed. On the other hand, plug-ins can be viewed as “service providers”, which once installed within DEBAT, make their services available to all the other plug-ins. Therefore, all the plug-ins provide also a services interface defining the services they can offer to the other plug-ins.

The following diagram shows two plug-ins: Plugin1 and Plugin2. Both implement the PluginInterface. Furthermore, Plugin2 exposes a services interface Plugin2ServicesInterface with two operations op1() and op2(). Theses operations are made available to the rest of the plug-ins (in the diagram Plugin1 calls these services).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxvii


PluginManager


(from plugin)

Plugin1

init()start()stop()messageReceiv ed()sendMessage()

<<Plugin>>

PluginInterface


(from interface)

cal l plugin interface

Plugin2


<<Plugin>>

Plugin2Serv icesInterf ace

op1()op2()

1

11

1

cal l services of Plugin2

Plugin1 and Plugin2 implements the PluginInterface

Plugin1 uses serv ices that are made available by Plugin2

Figure 5-35 Plug-in system services definition


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxviii

Figure 5-36 Plug-in system functional logic

5.2.5.2.4 DependenciesThe Plug-in system component does not rely, nor use other components.

5.2.5.2.5 InterfacesThe PluginLoader is in charge of loading the plug-ins in memory. It is used by the Framework component as explained in section 5.2.5.1.4.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxix


Black box<<Plugin>> Java

<<Plugin>>

PluginLoader

loadPlugin()

(from plugin)

PluginManager

getPlugins()getPluginBy Name()addPlugin()removePlugin()f orwardCall()

(from plugin)

loadsendMessage

load sendMessage

uses

init, start, stop, messageReceiv ed

init, start, stop, messageReceiv ed

Figure 5-37 Plug-in system interfaces

5.2.5.2.6 ProcessingThe main classes of the Plug-in system component are: the PluginLoader, the PluginManager and the PluginInterface.

The PluginLoader is responsible for loading the plug-ins in memory. The PluginLoader accepts two kinds of plug-ins: Java plug-ins and non-Java plug-ins (executables written in another language) called black-box plug-ins.

Java plug-ins are applications written in Java. As these plug-ins are directly written in Java, they have a complete access to all the libraries/services provided by DEBAT and by the other tools/plug-ins. These plug-ins are dynamically loaded in memory inside the same Java Virtual Machine (the Java Virtual Machine is the application that is running the Java compiled code) as DEBAT itself, and can easily be monitored and controlled.

Black-box plug-ins are programs written and compiled in another language and that can not be dynamically loaded in the JVM memory. As the name implies, these plug-ins are viewed from DEBAT as black-box processes: these are separate programs that are launched by DEBAT, but the level of interaction between DEBAT and these external programs is less efficient and more limited.

The PluginManager holds the list of the active plug-ins. It is in charge of receiving the call events from the framework GUI and of handling, monitoring and controlling the plug-ins. It communicates with the plug-ins through the PluginInterface.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxx

PluginLoader

loadPlugin(plugin : Plugin)

PluginInterface


(from interface)

<<Interface>>

PluginManager


PluginFolder

nameicontooltip

(f rom objects)

0..*

1

0..*

1

holds

BlackboxWrapper


(from interface)

Plugin


(from objects)

0..11

0..11

0..*

1

-plugin list

0..*

1

holds

0..*1+plugin list

0..*1

has

0..1

1

0..1

1

uses

cal l plugin interface cal l plugin interface

Figure 5-38 Plug-in system class diagram

The PluginInterface enables the bi-directional communication between the Integrated Environment and the Plugins. It supports the monitoring and control of the plug-ins (load, start, stop…), the passing of messages, and the sharing of services between all the tools/plug-ins. In the case of a black box plug-in the interactions are made through the BlackboxWrapper class that acts like a wrapper around the black box plug-in.

The plug-ins have to be implemented in such a way that they can be automatically and transparently recognised and handled by DEBAT. Some implementation rules have been defined.

The Java plug-in implementation rules are as follows. A Java plug-in shall provide a class that implements the PluginInterface

A Java plug-in shall be packaged in a jar archive.

The System.exit() command shall never be called (the dispose() command shall be called instead).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxi

The Black-box plug-in implementation rules are as follows: A black box plug-in shall be an independent executable program that can be launched

directly from a command-line.

A black-box plug-in shall reserved its standard input, output and error to communicate with DEBAT, as DEBAT assumes that a black-box plug-in is listening to DEBAT on its standard input, and posting string messages on its standard output and error streams. Note that this rule can be violated if a user doesn’t want to make his plug-in communicate with DEBAT.


PluginManager


(from plugin)

BlackboxWrapper


(from interface)

Plugin


(from objects)

10..*

1

-plugin list

0..*holds

1

0..1

1

0..1

Black box<<Plugin>>

string messages on standard in

string messages on standard out/err

Figure 5-39 Black-box plug-in interface


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxii

5.2.5.3 Project Management component

5.2.5.3.1 TypeThe Plug in System component is implemented in the ie.projectMgt.* package.

ie(from debat)

projectMgt

objects(f rom projectMgt)

gui(f rom projectMgt)

Figure 5-40 Project management component Package View



ie.projectMgt.* High level and services classes

ProjectManagerProjectManagementServicesInterface

ie.projectMgt.objects.* Business logic classes ProjectFolderFileAssociation

ie.projectMgt.gui.* MMI classes ProjectManagementFrameProjectManagementTreeProjectPanel


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxiii


SR68_INTEGRATEDENV Conformity: CSR70_INTEGRATEDENV Conformity: CSR71_INTEGRATEDENV Conformity: CSR72_INTEGRATEDENV Conformity: CSR73_INTEGRATEDENV Conformity: CSR74_INTEGRATEDENV Conformity: CSR75_INTEGRATEDENV Conformity: CSR76_INTEGRATEDENV Conformity: CSR77_INTEGRATEDENV Conformity: CSR66_INTEGRATEDENV Conformity: CSR67_INTEGRATEDENV Conformity: CSR68_INTEGRATEDENV Conformity: CSR69_INTEGRATEDENV Conformity: CSR71_INTEGRATEDENV Conformity: CSR72_INTEGRATEDENV Conformity: C

5.2.5.3.3 Function

DEBAT supports the project management concept. A project is a bundle containing all the files related to a given project/mission, with in particular:

The data models (Internal Format of the Modeller),

The project documentation (Word, HTML, PDF… generated by the Modeller),

The EAST and DEDSL description files (outputs of the Modeller),

And, the data files.The project management provides a virtual organisation of the file system. All the tools of the Integrated Environment access this same logical organisation of files.

The project management offers a tree-view MMI (very similar to the Windows Explorer) displaying all the opened projects. It enables users to create or delete a project, to add, move or delete files in a project or to trigger an action (e.g. open in Modeller, generate EAST) on a file or on a bulk of files.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxiv

Figure 5-41 Project management functional logic

5.2.5.3.4 DependenciesThe ProjectManagement component implements the PluginInterface provided by the Plug-in system component.It does not rely on another component (except the General features component for the common functions)


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxv



PluginInterface


(from interface)

ProjectManager

load()sav e()getProjects()getProjectBy Name()addProject()remov eProject()trigger()

(from projectMgt)

implements


Figure 5-42 Project Management component interfaces



ProjectManager


(from projectMgt)

ProjectManagementServ icesInterf ace

getProjects()getProjectByName()addProject()removeProject()trigger()

(from projectMgt)

f orwards call

Projects conf iguration<<XML file>>

sav eload

This interf ace is used by the other tools/plug-ins to:- get the projects list- get a project giv en its name- add a project- remov e a project- trigger an action on a f ile or a grou of f iles

Figure 5-43 Project Management interfaces


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxvi

5.2.5.3.6 Processing The Project Management component is itself implemented as a Java plug-in. It comprises mainly two sub-components: the ProjectManagementFrame and the ProjectManager.

The ProjectManagementFrame provides the users with a tree-like graphical user interface very similar to the Windows Explorer.

The ProjectManager component is responsible for loading an XML configuration file that contains the definition of the projects. It implements the Java PluginInterface, and is therefore compliant with the interface that DEBAT expects.It holds the list of the projects and manages the associations between the files and the potential actions that can be triggered on the files (for example, several actions can be associated to an XML-IF file: “Open in Modeller”, “Generate documentation”, “Print”). The user can trigger these actions by clicking on popup menus appearing when selecting a file on the tree-view MMI with a mouse right-click.


getProjects()getProjectBy Name()addProject()remov eProject()trigger()

PluginInterface


(from interface)

<<Interface>>

ProjectManagementTree

(from gui)

ProjectPanel

(from gui)

ProjectManagementFrame

(from gui)

11

11

1 11 1

File

pathextensionactionList

(f rom objects)

Folder

name

addFile()remov eFile()getFiles()

(f rom objects)

0..*1..* -file list

0..*1..*

has

Project

name

addFile()remov eFile()mov eFile()addFolder()remov eFolder()getFiles()getFolders()

(from objects)

0..*

1..*

-file list

0..*

1..*

has

0..*

1..*

0..*

1..*

ProjectManager


implements

f orwards call

sends MMI events

0..*

1

-project list

0..*

1

holds

Association

f ileExtensionactionToTrigger

(from objects)

0..*1 0..*1

+associations

Figure 5-44 ProjectManager class diagram


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxvii

Furthermore, the Project Management component exposes an interface of services (ProjectManagementServicesInterface) that can be used by the other tools/plug-ins. This interface provides means to: retrieve the list of the projects, retrieve a Project given its name, add a Project, remove a Project, trigger an action on a file or a group of files.

5.2.5.3.7 Sketches of the GUIThe ProjectManagementFrame is the frame that allows the user to access the virtual organisation of the file system. It is split in two areas: on the left, there is a tree showing the available projects and the files within the projects (ProjectManagementTree). On the right, there is a panel that displays the information relative to the selected node (ProjectPanel): file/project name, icon and extension, actions associated to the given extension. The user accesses popup menus when right-clicking on the projects tree.

Figure 5-45 ProjectManagementFrame

When adding a file to a project or a project folder, the following widget is displayed to the user:

Figure 5-46 File chooser widget


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxviii

5.2.5.3.8 Menu treesWhen right-clicking on the tree nodes, one can access the following functions:

Node type Menu Description

Projects (root node)

Add project Allows the user to add a project.

Project node Add Allows the user to add a file or a folder to the selected project

Remove Allows the user to remove the selected project

Folder node Add Allows the user to add a file or a folder to the selected folder

Remove Allows the user to remove the selected folder

File node (leaf)All Remove Allows the user to remove the selected

fileIF file (old OASIS file)

Import in Modeller

Print

Transform the old OASIS model into the new XIF format, and open it in the ModellerPrint the IF file

XIF file (new Modeller data model)

Open in ModellerPrint

Generate documentation

Open the data model in the ModellerPrint the data modelGenerate HTML, PDF or Word documentation

EAS file Print Print the fileDEDSL file Print Print the fileWord (.doc, .rtf) Open Open in word (if available Windows)PDF (.pdf) Open Open with Acrobat reader if available

The user can customise the actions that can be associated with a given file extension. He can also change the location of a file from a folder/project to another one by drag and drop.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxix

5.3 EAST core

5.3.1 Type

The EAST core component is composed of nine components as shown in the following decomposition view:


C Library<<Component>>

C Servers<<Component>>

Fortran Serv ers<<Component>>

Queries Handler<<Component>>

Interpreter<<Component>>

Data Generator<<Component>>

Data Algorithms<<Component>>

Ada API<<Component>>

Java API<<Component>>

Data Product Explorer<<Component>>

Figure 5-47 EAST core component decomposition view

The EAST Core is composed of components written in Ada, Java, C and Fortran. In the rest of this section, the formalism used to describe the components written in Ada is the HOOD formalism, while the UML formalism is used for Java components.

EAST Core

C Library

javaapi

C Servers

Fortran Servers

Ada API

Queries Handler Interpreter

Data Product Explorer

Data Generator

Data Algorithms

Library implementedin java

Libraries implementedin Ada

Libraries implementedin C

Library implementedin Fortran

Figure 5-48 EAST core components view


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxx

Component Purpose Comments

Ada API The Ada East API provides a thin layer to the EAST components Interpreter, Data_Generator and EAST_Query_Handler.

This is only a “conceptual” component that allows separating the visible interface of the Interpreter, Data_Generator and East_Query_Handler from their implementation.

Queries Handler Performs XML queries on data products Implemented by the East_Query_Handler HOOD module

Data Product Explorer

Provides direct access reading functions Implemented by the Data_Product_Explorer HOOD module

Interpreter Provides data reading and checking functions Implemented by the Interpreter HOOD module

Data Generator Provides data writing functions Implemented by the Data_Generator HOOD module

Data Algorithms Provides calculation capabilities, the support for external functions, and the generation of random strings and numbers.

Implemented by the following HOOD modules:Expression_EvaluatorDynamic_ExecutionRandom_NumbersRandom_Strings

Java API Java interface to the Ada API Implemented in the east.javaapi.* Java package.

C Library C interface to the Ada API Thin C layer to the Ada APIC Servers Multithread API in C Built upon the C LibraryFortran Servers Fortran interface to the C Servers Thin layer to the C API

Being only upgraded in DEBAT in order to implement the new functions designed for the Java API, the C Library, C Servers and Fortran Servers component will not be described in this document. The users who want to use the new functionalities of these APIs will refer to the Java API description in order to get the list of functions and to the ICD (Interface Control Document) to get the detailed descriptions of the available functions.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxxi

5.3.2 PurposeSatisfy: SR106_EASTCORE Conformity: C

SR107_EASTCORE Conformity: CSR108_EASTCORE Conformity: CSR109_EASTCORE Conformity: C

5.3.3 Function

The EAST core provides functions: to read, analyse, handle and process EAST descriptions,

to read data products conforming to a given EAST description,

to generate data products conforming to a given EAST description,

to check an EAST description file against the EAST CCSDS recommendation,

to check a given data products against its EAST description.

Several improvements are made to the EAST core Interpreter component

Data reading

o The performances for data reading and extraction are improved.

o The ability to read the data products directly from TCP/IP sockets and from the standard input is added (in addition to the current possible reading from the file system and from memory).

o The support for multi-file data products (to read data products split into several files) is provided.

o The current EAST only supports sequential access to the data: this means that the data blocks preceding a given element (and all the elements preceding it within a block) have to be read before being able to read the value of interest. A direct access to the values contained in the data products is therefore to be implemented in order to be able to read exactly (and only) the element of interest. This will allows handling huge volumes of data, and to speed-up the reading process.

o The ability to define and handle "external functions" associated with a data description is also added to the technology. These functions are dynamically linked and executed at runtime (no compilation needed) by EAST when reading from a data package.

Data checking

o Enhanced data checking capabilities using computed constraints are made possible.

o Different levels of checking (e.g. warning, error, fatal) are supported

o The data checking API is improved.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxxii

East_Query_Handler component

This completely new module is added to EAST core to be able to perform queries on data products. The East_Query_Handler component is implemented mainly to support the services requested by the Data Extractor & Querying component (DEQ). This package is therefore able to understand the XML-Query language used by the DEQ. It is in charge of decoding the XML-Query request, executing the query and returning the results to the DEQ.

Data_Generator component

The performances for data writing are improved.

The ability to write the data products directly to TCP/IP sockets and to the standard output is added (in addition to the current possible writing to the file system and into memory).

The support for integer and real formats (ascii-encoded numbers) is added to customise the writing.

The support for "external functions" is also added to the data writing process to be able to dynamically link and execute external functions for customising how the values are to be generated.

Direct access for writing is also provided.

New services are also added to support the needs of the Data Producer & Editor (DPE). These improvements are mainly the addition of the capability to automate the writing of a data product by taking as input a macro generation file (generated by the DPE). This file contains generation directives that describe how EAST has to generate the values of the data product.

API’s: All the current API's (ADA, C/C++, and FORTRAN) are updated with these new functions, and a new complete Java API is built to support the DEBAT suite of tools (written in Java).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxxiii

5.3.4 Dependencies

Ada API<<Component>>

C Library<<Component>>

C Servers<<Component>>

Data Algorithms<<Component>>


Fortran Serv ers<<Component>>



Queries Handler<<Component>>

built onbuilt on

built onbuilt on

use use

Data Product Explorer<<Component>>

use

implemented by

implemented by implemented by

use

use use

Figure 5-49 EAST core component dependencies


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxxiv

5.3.5 Interfaces

Description File<<EAST file>>

EAST conf iguration f ile<<TEXT file>>

the f ile containing data<<DATA file>>

Data f low f rom/to standard input/output<<DATA flow>>

Data f low f rom/to socket<<DATA flow>>


Macro generation f ile<<MACRO fi le>>

Format def init ion f ile<<FRT file>>

Jav a external f unction<<TEXT file>>

External checking constraints<<Text file>>

Figure 5-50 EAST core component interfaces

The EAST core has the following interfaces: It reads the EAST description file describing the format of the data products.

It reads the EAST configuration file giving some parameters used y the EAST core such as directory path and logbook configuration.

It reads/writes data files following the format given by the EAST description file.

It reads/writes from/to the standard input/output (the data can come/go from/to the standard input instead of being read from a file.

It can read/write from/to sockets.

It can take as input a FRT file (format file generated by the DEBAT Modeller). This file contains for each element to format: the path to the element and the format to apply.

It can take as input a macro generation file (generated by the Data producer & Editor): this file contains generation directives that describes how new data blocks have to be generated.

It can read external Java files containing external functions that allow modifying the behaviour of EAST at runtime.

It can take as input external checking constraints written in an external file (enhanced checking constraints).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxxv

5.3.5.1 Java API component

5.3.5.1.1 TypeThe Java API component is composed of two components as shown in the following decomposition view:

Jav a API(f rom Component EAST core)

<<Component>>

Java inteface<<Component>>

Debat Launcher<<Ada Library>>

Figure 5-51 Java API component decomposition view

The Java interface component is implemented in Java in the east.javaapi.javainterface.* package as shown in the following package view.

east(from debat)

javaapi(from east)

javainterface

Figure 5-52 Java API packages view

The Debat_Launcher is written in Ada. This library is necessary to make the EAST Java API accessible from the Java language.

Package / Library Contents Classes

east.javaapi.javainterface.* Java Interface to the EAST Ada API

Interpreter (Java)DataGenerator (Java)QueriesHandler (Java)

Debat Launcher This library is able to start a Java Virtual Machine to make the EAST Java API accessible to Java applications.

Debat_Launcher (Ada)


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxxvi

5.3.5.1.2 PurposeSatisfy: SR111_EASTCORE Conformity: C

5.3.5.1.3 FunctionA complete Java API is built from scratch. It gives access to all the functions of the EAST core implemented in Ada. This API is built using the JNI technology, which enables the java language to have access to native functions written in Ada. The java API is composed of two components:

Java interface: this set of four classes gives access to the full EAST API to java users. Its conception is mapped on the structure of the Ada API that is the native interface to the EAST functions.

Debat Launcher: this Ada component implements a full java launcher in Ada. This java launcher is the same than the standard one except that it grants access to the EAST Java API.

5.3.5.1.4 Dependencies

Java API(from Component EAST core)

<<Component>>

Ada API(from Component EAST core)

<<Component>>

Interpreter DataGenerator QueriesHandler

Interpreter(f rom Component EAST core)

<<Component>>

implemented by

Data Generator(f rom Component EAST core)

<<Component>>

implemented by

Queries Handler(f rom Component EAST core)

<<Component>>

implemented by

Figure 5-53 Java API component dependency view

The Java API relies only on the Ada API (component from the EAST core).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxxvii








Macro generation f ile<<MACRO fi le>>

Format def inition f ile<<FRT file>>


External checking constraints<<Text file>>

Figure 5-54 Java API component interfaces

Being an implementation of the EAST functions in java built upon the Ada API, the Java API has the same interfaces as the EAST core.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxxviii


Interpreter

selectDDR()setOnDDR()focusOn()releaseDDR()getPaths()getPathsForCurrentRecord()prepareAccessesForCurrentBlock()prepareAccessesForCurrentRecord()start()stop()getDataEnti tyBinary()getDataEnti tyAsci i()freeOctetString()getRequestList()releaseAccessPath()getNumberOccurencesOfDataEnti ty()getNumberElementsOfArray()startSequenceRecording()stopSequenceRecording()removeSequence()getNameOfCurrentRecord()loadNextDataBlockFromMemory()loadNextDataBlockFromFile()loadNextRecordFromFile()loadNextRecordFromMemory()loadEndOfCurrentBlockFromFile()loadEndOfCurrentBlockFromMemory()checkNextDataBlockFromFile()checkNextDataBlockFromMemory()checkNextRecordFromFile()checkNextRecordFromMemory()checkEndOfCurrentBlockFromFile()checkEndOfCurrentBlockFromMemory()getErrorsNumber()getErrorsNumberInCurrentBlock()clearBuffer()closeFile()loadNextDataBlockFromSocket()loadEndOfCurrentBlockFromSocket()loadNextRecordFromSocket()checkNextDataBlockFromSocket()checkNextRecordFromSocket()checkEndOfCurrentBlockFromSocket()closeSocket()loadNextDataBlockFromStandardInput()loadEndOfCurrentBlockFromStandardIntput()loadNextRecordFromStandardInput()checkNextDataBlockFromStandardInput()checkNextRecordFromStandardInput()checkEndOfCurrentBlockFromStandardIntput()checkDataEnti ty()selectDataProduct()selectBlock()getCurrentBlockNumber()readDataEnti tyAsci i()readDataEnti tyBinary()selectDataProductFromSocket()selectDataProductFromStandardInput()exi st()dump()dumpT oXml()

DataGenerator

startSequenceRecording()stopSequenceRecording()removeSequence()enableSequence()disableSequence()closeFile()flush()focusOn()forceDataEnti ty()freeMem ory()getPaths()getRemainingList()isComplete()read()releaseAccessPath()releaseDDR()reset()selectDDR()setDataEnti ty()start()stop()veri fy()wri te()generateNewBlock()close()readStandardInput()wri teStandardOutput()flushStandardOutput()closeStandardOutput()selectDataProduct()selectBlock()getCurrentBlockNumber()readDataEnti tyAsci i()readDataEnti tyBinary()selectDataProductFromSocket()selectDataProductFromStandardInput()exi st()

QueriesHandler

analyseQuery()nextDataRecords()isColumnPresent()variableValue()freeDataRecords()freeQuery()recordsCount()blockNumberOfRecords()dataFi lenameOfRecords()

Ada API(from Component EAST core)

<<Component>>

Debat Launcher

launch()register_natives()

<<Ada Library>>

cal ls native ada functions via the JNI

<<JNI cal l>>

cal ls native ada functions via the JNI

<<JNI cal l>>cal ls native ada functions via the JNI

<<JNI cal l>>

register native functions to the jvm<<JNI cal l>>

Figure 5-55 Java API component class diagram

The java API component is composed of four main classes: Interpreter: the Interpreter class gives access to the functions of the Ada Interpreter

component from the EAST core. The Interpreter class uses the JNI technology to call functions of the Ada EAST core.

DataGenerator: the DataGenerator class gives access to the functions of the Ada Data Generator component from the EAST core. The DataGenerator class uses the JNI technology to call functions of the Ada EAST core.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : lxxxix

QueriesHandler: the QueriesHandler class gives access to the functions of the Queries Handler component of the EAST core. The QueriesHandler class uses the JNI technology to call functions of the Ada EAST core.

Debat_Launcher : this Ada library implements a full java launcher in Ada.

Each Java class of the diagram has an Ada equivalent which makes the interface between Java and Ada possible using JNI. Those Ada components have not been represented on the class diagram. Instead the links use a special stereotype called “JNI call” which shows that the class is not calling the Ada API directly but instead the Ada JNI layer that makes the interface.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xc

5.3.5.2 Data Product Explorer component

5.3.5.2.1 TypeThis component is not decomposed anymore. It is a terminal component and implemented by only one Hood root module: Data_Product_Explorer.

5.3.5.2.2 PurposeSatisfy: SR17_DEBAT Conformity: C

SR128_EASTCORE Conformity: C

5.3.5.2.3 FunctionThe current EAST only supports sequential access to the data: this means that the data blocks preceding a given element (and all the elements preceding it within a block) have to be read before being able to read the value of interest. A direct access to the values contained in the data products is therefore to be implemented in order to be able to read exactly (and only) the element of interest. This will allow handling huge volumes of data, and to speed-up the reading process.

The Data explorer component is designed to answer this need. It comprises two main functions:

The ability to navigate through different blocks of a data product (e.g. skipping blocks),

The ability to read data entities directly once a data block is selected (without having to load/read the elements before the element of interest).

This component is used by the Data Interpreter and by the Data Generator that are in charge of reading/writing data products according to an EAST description.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xci


Structural (types) Diagram

SYSTEM_CONFIGURATION (!)

type

Data_Product_Explorer (!)

STANDARD (!){STANDARD_ADA_TYPES}

Format_Converter (!)LINELINE_ARRAYARRAY_STORAGEKIND_OF_CONVERSIONCONVENTION

Type_Converter (!)

ENTIER_TRES_COURTENTIER_NON_SIGNE_TRES_COURTENTIER_NON_SIGNE_COURTCONVERSION_MODECONVERSION_RULE

East_Analyser (!)

TYPE_MANIPULATIONMANIPULATED_FORMCHAINE_IDENTSYMBOL_REPVALUENUMBER_REPSOURCE_POSITIONTREESEQ_OF_TYPENODE_NAMELISTE_DE_TREEREPONSE

Log_Book (!)TYPE_DE_MESSAGENOMBRECHEMIN_ACCES

Support_Physique (!)T_NATURE_SUPPORTT_TYPE_ACCEST_POSITIONNEMENT_CASSETTET_INFO_COMPLEMENTAIRET_FILE_TYPEOCTETTABLEAU_OCTETS

Common (!){COMMON_EAST}

Figure 5-56 Structural (types) Diagram of Data_Product_Explorer component


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xcii

Functional (operations) Diagram


operation

Data_Product_Explorer (!){Navigation_through_data_blocks:

select_data_product_from_fileselect_data_product_from_memoryselect_data_product_from_socketselect_data_product_from_standard_inputselect_blockget_current_block_number

}{Data_entity_reading:

read_data_entity_asciiread_data_entity_binary#1read_data_entity_binary#2

}

STANDARD (!)

Format_Converter (!)start{convention_inversion}does_the_host_inverse{convert}{get_converted}

Type_Converter (!)

{long_integer_to_}{long_real_to_}{ascii_to_}{integer_to_}enum_to_long_integerreal_to_long_realvaleur_range_enumreconnaitre_un_entierreconnaitre_un_reelreconnaitre_une_enumerationcontroler_valeur_entiercontroler_valeur_reelcontroler_valeur_enumerationcontroler_l_entiercontroler_le_reelcontroler_l_enumerereconnaitre_un_entier_asciireconnaitre_un_reel_asciireconnaitre_une_enumeration_asciienumeration_ascii_to_sm_posun_bit_de_signe_est_il_obligatoireest_character

East_Analyser (!)

analyse_DDR_and_pathnamesanalyse_DDRanalyse_pathnamemodify_pathnamefocus_onget_focus_pathpoint_on_formpoint_on_pathnamerelease_formrelease_pathnamedelete_forminitializeclean_current_formclean_positions_on_current_forminit_current_forminit_current_form_for_focus{internal_access_form}valeur_uniquevaleur_unique#1est_valeur_unique

Log_Book (!)createis_openclosebegin_messagewrite_messagewrite_textend_messageget_name

Support_Physique (!)ouvrirfermercreerobtenir_octetsecrire_octetsdonner_numero_bidonest_ouvert

Common (!){operation_set}{operation_set}

Figure 5-57 Functional (operations) Diagram of Data_Product_Explorer component


The current EAST only supports sequential access to the data. This means that the n-1 blocks have to be loaded in memory before being able to reading the block n. Furthermore, if the focus function inside a block is used to access to a particular data entity, the user must load the data sequentially, according to the physical order given by the EAST description. The succession of the focus, left to the user responsibility, must respect this order. It may be a source of errors, especially when the accesses are driven from a GUI. By adding this concept of direct access, the user has now the ability to set on a block far away of his current block by specifying a block number without needing to load the intermediary blocks. Inside the current block, he is also able to read any data entity without respecting the physical order of the EAST description. This evolution implies to compute the size of each data block and, also, to compute the location of each data entity within the selected data block. This calculation depends on the structure of the EAST description:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xciii

The first case is an EAST description containing no discriminant and no list, or

containing only discriminants that don't affect the block size. The size of each data block is constant and can thus be directly recorded in the DIANA form. It's therefore easy to compute the location of a given data block, and to set on this data block.

The second case is an EAST description containing discriminants or lists that affect the data block size and the location of the elements. The first thing to do is to get the values of the discriminants to be able to compute the block sizes and the element locations. Theirs positions aren't fixed or don't exist from one block to another.

A first solution would consist, for each element, in inserting in the DIANA form the algorithm that provides the calculation of the element location. When this algorithm is applied to a particular data block, it requires knowing the discriminating values involved from the beginning of the data block until the element in question. At runtime, the algorithms are to be executed to determine the location of each element and the block sizes. The possible combinations may become rapidly very complicated (by example, for arrays of elements discriminated by computed values). The implementation of such a solution seems cost-expensive; the volume of the DIANA form may become very huge (an algorithm for each element whose location varies), and the performances may be degraded (the algorithms have to be re-computed each time).

A second solution would consist in traversing the DIANA tree to compute and to record progressively the offset of each field in the DIANA form retrieving and recording the values of the discriminants and of the element locations when running across them. This approach is applied for the determination of the block sizes and for the computation of the element locations:

o For the computation of the block sizes, the DIANA tree is traversed in order to determine the size of a given data block. Only the discriminant values are recorded in the DIANA form (as the location of the element are not of interest). This process is used to be able to select a specific block of data, to skip data blocks or to navigate forward and backward in a data product.

o For the computation of the element locations, the tree is traversed in order to determine and record the position of each element for future access. This process is applied on a given data block whose size and discriminating values have already been computed. The position of each data element is expressed in bit and represents an offset from the beginning of the block. In order to be more efficient in time, the location of the fields with a fixed size are not retrieved each time, but their positions are recorded once and retrieved when required.

The second solution has been chosen because it is easier to implement and has less impact on the existing EAST. Navigation through data blocksIn the current EAST, the navigation through the different blocks is limited to the next block.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xciv

The navigation capabilities are extended to be able to read and process large volumes of data in a more efficient way and to be able:

to select a particular data block within a data product,

to jump several data blocks (without having to load the data blocks as it is currently the case),

to go forward or backward in a data product. The data product explorer provides the size of each jumped block, and consequently by offset, knows the position of the next block in the data product. This involves

to know :

the current block number in the data product,

the current data file for a data files product (or the current socket, or the memory address containing the data product)

the current block position, expressed by an offset in bits from the beginning of the data product (the beginning of the current data file for a data files product).

when going forward, each position is computed and recorded in order to compute the position of the block only once.

when going backward, the data product explorer uses the recorded positions of the preceding blocks (that have been previously calculated)

Some solutions could be found to optimise the storage of all the computed locations (for instance when the size is constant during n consecutive blocks). Data entity reading First of all, a data product and a data block must be selected. Then, the user accesses a data entity by giving its EAST path, in order to get its interpreted value. The DIANA form is instantiated with the selected block. By asking the DIANA form, the location of the desired data entity is well known. It is expressed by an offset in bits from the beginning of the block, which has the position zero. The position of the beginning of the block on the support is known. Reading data products cannot be managed below the byte (programming languages allow reading down to the byte level, but generally not below). A mechanism must be implemented to load the set of bytes containing the data entity, and to extract from them the set of bits corresponding exactly to the data entity, taking into account the necessary conversions concerning the format of the target machines.

5.3.5.2.6 Operations select_data_product_from_file This operation permits to select a data product from files by its pathname. select_data_product_from_memory This operation permits to select a data product from memory by its pathname. select_data_product_from_socket This operation permits to select a data product from a socket by its pathname. select_data_product_from_standard_input This operation permits to select a data product from the standard input by its pathname. select_block


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xcv

This operation computes all the block sizes from the block following the current block to the selected block, deduces what are theirs positions in the data product, and records them. Then, it instanciates the DIANA tree with the current data block: it computes and records the values of the discriminants and the element locations. get_current_block_number This operation gives the number of the actual selected block. read_data_entity_ascii This operation retrieves the value of a data entity by giving its path. Its value is given in the ASCII format. read_data_entity_binary#1 This operation retrieves the value of a data entity by giving its path. Its value is given in the specified format type. read_data_entity_binary#2 This operation retrieves the value of a data entity by giving its path when the user doesn't know the value length. Its value is given in the specified format type.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xcvi

5.3.5.3 Interpreter component

5.3.5.3.1 TypeThis component is not decomposed anymore. It is a terminal component and implemented by only one Hood root module: Interpreter.


SR112_EASTCORE Conformity: CSR114_EASTCORE Conformity: CSR115_EASTCORE Conformity: CSR116_EASTCORE Conformity: CSR117_EASTCORE Conformity: CSR127_EASTCORE Conformity: CSR126_EASTCORE Conformity: CSR129_EASTCORE Conformity: CSR130_EASTCORE Conformity: CSR131_EASTCORE Conformity: CSR137_EASTCORE Conformity: CSR138_EASTCORE Conformity: CSR139_EASTCORE Conformity: CSR140_EASTCORE Conformity: CSR141_EASTCORE Conformity: CSR142_EASTCORE Conformity: C

5.3.5.3.3 FunctionAll the features that provide data reading and checking functions are located in the Interpreter component. When a user wants to read some data with EAST, he has first to indicate which data model he wants to use by specifying the EAST description file. This provokes the creation/loading of the DIANA form (DIANA tree) corresponding to the model.

After that, the user can read data blocks corresponding to the model using two different ways: the sequential access or the direct access. The sequential access is already implemented, whereas the direct access is a new feature that is provided by calling the Data Explorer component.

The following capabilities are provided for reading: The ability to read the data products directly from the file system, from memory, from

TCP/IP sockets and from the standard input.

The support for multi-file data products (to read data products split into several files).

A direct access to the values contained in the data products (provided by using the Data Product Explorer component). This will allow handling huge volumes of data, and to speed-up the reading process.

The ability to handle "Java external functions" associated with a data description is also added to the Interpreter. These functions are dynamically linked and executed at runtime (no compilation needed) by the Interpreter when reading from a data package.

The following checking capabilities are provided:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xcvii

The data's range checking related to the type of data defined in EAST description.

The addition of enhanced data checking capabilities in relation to user external constraints:

computed constraints (additional to the range) that applies to a value of a specific field,

regular expressions for strings or ASCII encoded numbers

The support for different levels of checking (e.g. warning, error, fatal).



SYSTEM_CONFIGURATION (!)A

type

Interpreter (!)

LANGUAGELENGTHKIND_OF_CONVERSIONOCTETOCTET_STRINGOCTET_STRING_ACCESS


EAST_Analyser (!)

TYPE_MANIPULATIONMANIPULATED_FORMCHAINE_IDENTSYMBOL_REPVALUENUMBER_REPSOURCE_POSITIONTREESEQ_OF_TYPENODE_NAMELISTE_DE_TREEREPONSE

SUPPORT_PHYSIQUE (!)T_NATURE_SUPPORTT_TYPE_ACCEST_POSITIONNEMENT_CASSETTET_INFO_COMPLEMENTAIRET_FILE_TYPEOCTETTABLEAU_OCTETS

Common (!)POINTEUR_TABLEAUTABLEAU_OCTETSENTIER_COURTENTIER_LONGOCTETLANGUAGEREEL_COURTREEL_LONGCHEMIN_ACCESBITTABLEAU_BITSNUMERO_DE_BITPTR_TABLEAU_OCTETSPTR_TABLEAU_BITSENTIER_TRES_LONGINFOS_FICHIER_CONFIGURATIONENTIER_LONG_NON_SIGNENOM_DE_FICHIERLISTE_DE_FICHIERSTABLEAU_ENTIER

SYSTEM (!)address

TEXT_IO (!)

FILE_TYPEFILE_MODECOUNTPOSITIVE_COUNTFIELDNUMBER_BASETYPE_SETFLOAT_IOINTEGER_IO

Data_Loader (!)

LENGTH

System_Interface (!)NUMBER_OF_STORAGE_UNITS

Type_Converter (!)ENTIER_TRES_COURTENTIER_NON_SIGNE_TRES_COURTENTIER_NON_SIGNE_COURTconversion_modeCONVERSION_RULE


Configuration_Des_Acces (!)

Data_Product_Explorer (!)Data_Product_Explorer

Expression_Evaluator (!)Expression_Evaluator

Figure 5-58 Structural (types) Diagram of Interpreter component


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xcviii


SYSTEM_CONFIGURATION (!)A

operation

Numero_Message

Data_File

DDR_File

Interpreter (!)

startstop{handle_DDR}{parcourir}{sequence}{sequential_load}{sequential_check}{get_data_entity}{select_data}{read_data}


EAST_Analyser (!)

analyse_DDRanalyse_pathnamepoint_on_formpoint_on_pathnamerelease_formrelease_pathnamedelete_forminitialize{internal_access_form}clean_current_formanalyse_DDR_and_pathnamesfocus_oninit_current_formget_focus_pathinit_current_form_for_focusmodify_pathnamevaleur_uniquevaleur_unique#1est_valeur_uniquepartly_clean_current_form

SUPPORT_PHYSIQUE (!)ouvrirfermercreerobtenir_octetsecrire_octetsdonner_numero_bidonest_ouvert

Common (!)lire_chemin_courantecrire_chemin_courant"-""+"">""<""*"entier_long_vers_entier_tres_longentier_tres_long_vers_entier_longascii_vers_entier_tres_longentier_tres_long_vers_asciidivision_entiere_et_restevaleur_absolue"-"#2"<="permuter_bits_dans_chaine_de_bitsinverser_bits_dans_les_octetslire_jdb_courantlire_infos_configurationecrire_nom_jdb_courantlire_variable_eastfree_tableau_octetsfree_tableau_bitsentier_long_non_signe_vers_entier_tres_longlire_variable_conflire_case_sensitivecomparaison_chainecomparaison_chaine_no_sensitivelire_variable_discriminant_constantsuppression_suffixe_occlire_pos_compactmaximumlire_espace_tempoecrire_espace_tempocomparaison_chaine_permissiveest_positifest_negatifest_strictement_positifest_strictement_negatifafficher_infos_confcharger_conf_specifiquedetecter_fichierreinitialiser_confrepertoriersupprimer_chemin_et_versionsupprimer_extension{operation_set}supprimer_chemin_et_version_bissupprimer_extension_bisget_expanded_pathchemin_repete_premier_niveausupprimer_blancs

SYSTEM (!)null_address

TEXT_IO (!)

{File_Management}{Control_Of_Default}{Line_And_Page_Length}{Column_Line_And_Page_Control}{Character_Input_Output}{String_Input_Output}

Data_Loader (!)

{load_next_data}current_recordreadinit_loading_flagget_loading_flagdscrt_range_valueinit_memory_sizefree_memoryexp_valuechoice_handlerinit_DDRclose_fileclear_bufferposition_of_current_recordget_loaded_data_lengthcheck_next_data_block_from_file{check_next_data}get_errors_numberget_errors_number_in_current_blockstart_sequence_recordingstop_sequence_recordingremove_sequence

System_Interface (!)systememktempgetenvstat

Type_Converter (!){long_integer_to_}{long_real_to_}{ascii_to_}{integer_to_}enum_to_long_integerreal_to_long_realvaleur_range_enumreconnaitre_un_entierreconnaitre_un_reelreconnaitre_une_enumerationcontroler_valeur_entiercontroler_valeur_reelcontroler_valeur_enumerationcontroler_l_entiercontroler_le_reelcontroler_l_enumerereconnaitre_un_entier_asciireconnaitre_un_reel_asciireconnaitre_une_enumeration_asciiun_bit_de_signe_est_il_obligatoireest_characterenumeration_ascii_to_sm_pos



pre_initialiserlire_nb_max_acceslire_nb_max_element


Expression_Evaluator (!)

Figure 5-59 Functional (oper.) Diagram of Interpreter component




Data f low f rom standard input<<DATA flow>>

Data f low f rom socket<<DATA flow>>



External checking constraints<<Text fi le>>

Figure 5-60 Interpreter component interfacesThe Interpreter has the following interfaces:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : xcix

It reads the EAST description file describing the format of the data products.

It reads data files following the format given by the EAST description file.

It reads from the standard input.

It can read from sockets.

It can read external Java files containing external functions that allow modifying the behaviour of the Interpreter at runtime.

It can take as input external checking constraints written in an external file (enhanced checking constraints).

5.3.5.3.6 ProcessingAll the features that provide data reading and checking functions are located in this object. When a user wants to read some data with EAST, he has first to indicate which data model he wants to use by specifying the EAST description file. This provokes the creation/loading of the DIANA form (DIANA tree) corresponding to the model. After that, the user can read data blocks corresponding to the model using two different ways: the sequential access or the direct access. The sequential access is whole implemented in this design, whereas the direct access is delegated to a required interface. Support for multi file data products With the current data interpreter, when the end of a data file is found, EAST raises an error indicating that the data file is incomplete if the data block is not entire in the data file. The Interpreter shall be modified in order to be able to read data products split into several files.The set of functions that are responsible for the loading or the selection of data blocks has to be modified to handle a list of data files instead of only one file. These functions make a loop on the list of files passed as argument and trap the exception raised at each end of file to continue the reading in the next file of the list.

In the case of direct access: o select_data_product.

In the case of the sequential access:

o load_next_data_block_from_file o load_next_record_from_file o load_end_of_current_block_from_file o check_next_data_block_from_file o check_next_record_from_file o check_end_of_current_block_from_file o close_file

These operations require a list of data products provided by their pathnames. Support for reading from sockets The main purpose of this evolution is to add the capability to read data products from TCP/IP sockets.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : c

This feature adds the capability to handle data on the fly and without any auxiliary storage. Data is analysed in near real-time on a block per block (or record per record) basis, at choice. EAST performs the data analysis on a block per block (or record per record) basis: this means that the calling application may be blocked until an entire record or block is received and analysed. This new capability is built using the GNAT.Sockets API (itself built upon the GCC sockets implementation). The following operations are added:

o load_next_data_block_from_socket o load_end_of_current_block_from_socket o load_next_record_from_socket o check_next_data_block_from_socket o check_next_record_from_socket o check_end_of_current_block_from_socket o close_socket

For direct access, the selection of the data product is provided with the following service:

o select_data_product_from_socket Support for reading from standard input The main purpose of this evolution is to add the capability to read data products from the standard input. The following operations are added:

o load_next_data_block_from_standard_input o load_end_of_current_block_from_standard_input o load_next_record_from_standard_input o check_next_data_block_from_standard_input o check_next_record_from_standard_input o check_end_of_current_block_from_standard_input

In case of direct access, the selection of the data product is provided as follows:

o select_data_product_from_standard_input

Data checkingThe currents Interpreter only provides checking at the block or record level (this means that the checking is applied on an entire block or record). This limitation is due to the checking process that is inherently coupled with the data loading process (checking is done on the fly).The ability to check a particular element of a data product (and only this element) is added to the Interpreter. This function is made possible by the addition of "direct access" capabilities provided by the Data Explorer component. The current checking capabilities of the Interpreter are the following:

Structure checking: checks that the data conforms to the logical description,

Enumeration checking: checks that a value belongs to a given enumeration,

Bounds checking: checks the range of an INTEGER, REAL, or CHARACTER.The goal of this change is to enhance the current checking capabilities of the Interpreter by adding:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ci

computed constraint (additional to the range) that applies to a value of a specific field,

regular expressions for strings or ASCII encoded numbers,

the support for different levels of checking (e.g. warning, error, fatal).These constraints are defined in external files containing for each constraint:

the path of the element to which the constraint applies,

the constraint itself (computed or not),

the level of gravity (warning, error, fatal).The constrains are specified as follows:East-path { constraint } return gravity ;

East-path is the complete path to the element to check.Constraint is the definition of the constraint to verify.Gravity is a string that is returned to the user is the constraint is violated. The string to be returned is totally specified by the user.

Constraints applying to the whole description are defined as follows (the east-path is not mentioned):{ constraint } return gravity ;

The following figure gives an example:

{ (N1 + N2 + N3) > 100 } return "ORANGE" ;

N1 { (N1 > 5) & (N1 < 10) } return "ORANGE" ;N1 { N1 >10 } return 'RED"

N2 { N2 < (N1+1) } return "FATAL" ;N2 { cos(N2) < cos(N1 / 2) } return "CATASTROPHIC" ;

N3 { match([abc]*) } return "WARNING";


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cii


Interpreter (!)LANGUAGELENGTHKIND_OF_CONVERSIONOCTETOCTET_STRINGOCTET_STRING_ACCESS

type

Format_Converter

Common

ConfigurationLANGUAGE

Bloc_De_Donnees (!)LENGTHKIND_OF_CONVERSIONOCTETOCTET_STRINGOCTET_STRING_ACCESS

Descriptif_EAST

Direct_Access_IDirect_Access_I

Figure 5-61 Structural (types) Diagram of Interpreter component


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ciii


Interpreter (!)startstop{handle_DDR}{parcourir}{sequence}{sequential_load}{sequential_check}{get_data_entity}{select_data}{read_data}

operation

TEXT_IOSystem_Interface

Log_Book

SUPPORT_PHYSIQUE

Log_Book

EAST_Analyser

CommonEAST_Analyser

EAST_Analyser

SYSTEM

Data_Loader

Common

Type_Converter

Format_Converter

Configuration_Des_Acces

Data_Product_Explorer

Format_Converter

Expression_Evaluator


Configurationstartstop

Bloc_De_Donnees (!){parcourir}{sequence}{sequential_load}{sequential_check}{get_data_entity}init_memory_sizeinit_chargementdesactiverinit_DDR

Descriptif_EAST{handle_DDR}init

Direct_Access_I{select_data}{read_data}

Figure 5-62 Functional (operations) Diagram of Interpreter component

5.3.5.3.7 Operations (only the new operations are described here)

load_next_data_block_from_socket This operation loads a data block from a socket. The data are interpreted to the host format during the loading. load_next_record_from_socket This operation loads a data record from a standard input The data are interpreted to the host format during the loading. load_end_of_current_block_from_socket This operation loads the end of block from a socket. The data are interpreted to the host format during the loading. This operation is used after the load_next_record_from_socket operation. close_socket This operation closes the current socket. load_next_data_block_from_standard_input This operation loads a data block from the standard input. The data are interpreted to the host format during the loading. load_next_record_from_standard_input


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : civ

This operation loads a data record from the standard input. The data are interpreted to the host format during the loading. load_end_of_current_block_from_standard_input This operation loads the end of block from the standard input. The data are interpreted to the host format during the loading. This operation is used after the load_next_record_from_standard_input operation. check_next_data_block_from_socket This operation checks a data block from a socket. The data are loaded, interpreted to the host format during the loading, and check in according of the data description format. check_next_record_from_socket This operation checks a data record from a socket. The data are loaded, interpreted to the host format during the loading, and check in according of the data description format. check_end_of_current_block_from_socket This operation checks the end of a data block from a socket. The data are loaded, interpreted to the host format during the loading, and check in according of the data description format. This operation is used after the check_next_record_from_socket operation. check_next_data_block_from_standard_input This operation checks a data block from the standard input. The data are loaded, interpreted to the host format during the loading, and check in according of the data description format. check_next_record_from_standard_input This operation checks a data record from the standard input. The data are loaded, interpreted to the host format during the loading, and check in according of the data description format. check_end_of_current_block_from_standart_input This operation checks the end of a data block from the standard input. The data are loaded, interpreted to the host format during the loading, and check in according of the data description format. This operation is used after the check_next_record_from_standard_input operation. select_data_product_from_file This operation takes into account the set of files that compose the data product and open the first one. select_data_product_from_memory This operation takes into account the memory address that contains the data product. select_data_product_from_socket This operation takes into account the socket that contains the data product. select_data_product_from_standard_input This operation takes into account the standard input which contains the data product. select_block This operation allows to be positioned on the block_number block in the selected data product. Furthermore, it prepares the future direct reading of the data entity in this selected block. read_data_entity_ascii This operation retrieves the value of a data entity by giving its EAST path. The value is converted in an ascii value. read_data_entity_binary This operation retrieves the value of a data entity by giving its EAST path. The value is converted to the required type. read_data_entity_binary#1 This operation has the same function of the read_data_entity_binary. It is used when the user doesn't know the length of the retrieved data. check_data_entity


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cv

This operation checks a particular data entity by giving its path, and by giving a user constraint. It returns if the constraint is verify or not. exist This operation verifies the existence of a data entity by giving its EAST path.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cvi

5.3.5.4 Data Generator Component

5.3.5.4.1 TypeThis component is not decomposed anymore. It is a terminal component and implemented by only one Hood root module: Data_Generator.


SR438_EASTCORE Conformity: CSR439_EASTCORE Conformity: CSR110_EASTCORE Conformity: CSR112_EASTCORE Conformity: CSR114_EASTCORE Conformity: CSR115_EASTCORE Conformity: CSR116_EASTCORE Conformity: CSR117_EASTCORE Conformity: CSR126_EASTCORE Conformity: CSR133_EASTCORE Conformity: CSR134_EASTCORE Conformity: CSR135_EASTCORE Conformity: CSR136_EASTCORE Conformity: C

5.3.5.4.3 FunctionAll the features that provide data writing functions are implemented by the Data Generator component.

The Data Generator component provides the ability to work on existing data (read, modify and save an existing data product) or to generate new data products from scratch. EAST currently supports both functions, with some limitations, the main one being that the user has to specify each element of the description (the process is not automated and if a value is not set EAST raises and error!) to be able to generated data products. This task is tedious and time consuming, and could be automated. The new Data Generator overcomes this limitation.

The new Data Generator adds several other enhancements, such as: the support for integer and real formats to define precisely how the ascii-encoded

numbers are written in a data product (this function is very similar to the features provided by an utility like printf in C language).

the support for default values.

the support for the macro generation files providing the ability to generate data products starting from a macro generation file that contains generation directives that describe how the data values are to be generated (this file is generated by the Data Extractor & Querying).

the support for external functions defined in external files following a Java syntax allowing to modify the behaviour of the Data Generator at runtime.

the support for writing data products to TCP/IP sockets and to the standard output.

the support for direct access.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cvii




type

Data_Generator (!)LANGUAGEOCTET_STRINGOCTET_STRING_ACCESSLENGTHKIND_OF_CONVERSION

EAST_Analyser (!)TYPE_MANIPULATIONMANIPULATED_FORMCHAINE_IDENTSYMBOL_REPVALUENUMBER_REPSOURCE_POSITIONTREESEQ_OF_TYPENODE_NAMELISTE_DE_TREEREPONSE

Common (!)POINTEUR_TABLEAUTABLEAU_OCTETSENTIER_COURTENTIER_LONGOCTETLANGUAGEREEL_COURTREEL_LONGCHEMIN_ACCESBITTABLEAU_BITSNUMERO_DE_BITPTR_TABLEAU_OCTETSPTR_TABLEAU_BITSENTIER_TRES_LONGINFOS_FICHIER_CONFIGURATIONENTIER_LONG_NON_SIGNENOM_DE_FICHIERLISTE_DE_FICHIERSTABLEAU_ENTIER

Random_Numbers (!)GENERATORUNIFORMLY_DISTRIBUTED

Support_Physique (!)T_NATURE_SUPPORTT_TYPE_ACCEST_POSITIONNEMENT_CASSETTET_INFO_COMPLEMENTAIRET_FILE_TYPEOCTETTABLEAU_OCTETS


SYSTEM (!)address

TEXT_IO (!)FILE_TYPEFILE_MODECOUNTPOSITIVE_COUNTFIELDNUMBER_BASETYPE_SETFLOAT_IOINTEGER_IO

System_Interface (!)NUMBER_OF_STORAGE_UNITS

Data_Writer (!)

Type_Converter (!)ENTIER_TRES_COURTENTIER_NON_SIGNE_TRES_COURTENTIER_NON_SIGNE_COURTCONVERSION_MODECONVERSION_RULE



P_STRING (!)new_stringstring_access

Data_Product_Explorer (!)Data_Product_Explorer

DYNAMIC_JAVA (!)DYNAMIC_JAVA

Random_String (!)

Expression_Evaluator (!)Expression_Evaluator

Figure 5-63 Structural (types) Diagram Data_Generator component


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cviii



operation

Data_Generator (!)startstop{handle_DDR}{sequential_read}{set_data_entity}{sequential_write}{parcourir}generate_new_block{sequence}release_block{select_data}{read_data}

EAST_Analyser (!)analyse_DDRanalyse_pathnamepoint_on_formpoint_on_pathnamerelease_formrelease_pathnamedelete_forminitialize{internal_access_form}clean_current_formanalyse_DDR_and_pathnamesinit_current_formfocus_onget_focus_pathinit_current_form_for_focusmodify_pathnamevaleur_uniquevaleur_unique#1est_valeur_uniquepartly_clean_current_form

Common (!)lire_chemin_courantecrire_chemin_courant"-""+"">""<""*"entier_long_vers_entier_tres_longentier_tres_long_vers_entier_longascii_vers_entier_tres_longentier_tres_long_vers_asciidivision_entiere_et_restevaleur_absolue"-"#2"<="">="permuter_bits_dans_chaine_de_bitsinverser_bits_dans_les_octetslire_jdb_courantlire_infos_configurationecrire_nom_jdb_courantlire_variable_eastfree_tableau_octetsfree_tableau_bitsentier_long_non_signe_vers_entier_tres_longlire_variable_conflire_case_sensitivecomparaison_chainecomparaison_chaine_no_sensitivelire_variable_discriminant_constantsuppression_suffixe_occlire_pos_compactmaximumlire_espace_tempoecrire_espace_tempocomparaison_chaine_permissiveest_positifest_negatifest_strictement_positifest_strictement_negatifafficher_infos_confcharger_conf_specifiquedetecter_fichierreinitialiser_confrepertoriersupprimer_chemin_et_versionsupprimer_extensionsupprimer_chemin_et_version_bissupprimer_extension_bisget_expanded_pathchemin_repete_premier_niveausupprimer_blancs

Random_Numbers (!)RandomRandom_IntegerReset#1Reset#2

Support_Physique (!)ouvrirfermercreerobtenir_octetsecrire_octetsdonner_numero_bidonest_ouvert


SYSTEM (!)null_address

TEXT_IO (!){File_Management}{Control_Of_Default}{Line_And_Page_Length}{Column_Line_And_Page_Control}{String_Input_Output}

System_Interface (!)systememktempgetenvstat

Data_Writer (!)startdefine_blockpoint_on_blockdestroy_blockstopwrite_on_filewrite_on_memoryclose_fileappend_data_itemreplace_data_itemrelease_data_itemget_data_itemcurrent_block_sizedscrt_range_valueexp_valuechoice_handler

Type_Converter (!){long_integer_to_}{long_real_to_}{ascii_to_}{integer_to_}enum_to_long_integerreal_to_long_realvaleur_range_enumreconnaitre_un_entierreconnaitre_un_reelreconnaitre_une_enumerationcontroler_valeur_entiercontroler_valeur_reelcontroler_valeur_enumerationcontroler_l_entiercontroler_le_reelcontroler_l_enumerereconnaitre_un_entier_asciireconnaitre_un_reel_asciireconnaitre_une_enumeration_asciiun_bit_de_signe_est_il_obligatoireest_characterenumeration_ascii_to_sm_pos


Configuration_Des_Acces (!)pre_initialiserlire_nb_max_acceslire_nb_max_element

P_STRING (!)viderremplirliretaille


DYNAMIC_JAVA (!)

Random_String (!)

Expression_Evaluator (!)

Figure 5-64 Functional (operations) Diagram Data_Generator component

5.3.5.4.5 InterfacesThe Data Generator has the following interfaces:

It reads the EAST description file describing the format of the data products.

It reads the EAST configuration file giving some parameters used y the EAST core such as directory path and logbook configuration.

It reads/writes data files following the format given by the EAST description file.

It reads/writes from/to the standard input/output (the data can come/go from/to the standard input instead of being read from a file.

It can read/write from/to sockets.

It can take as input a FRT file (format file generated by the DEBAT Modeller). This file contains for each element to format: the path to the element and the format to apply.

It can take as input a macro generation file (generated by the Data producer & Editor): this file contains generation directives that describes how new data blocks have to be generated.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cix

It can read external Java files containing external functions that allow modifying the behaviour of the Data Generator at runtime.






Macro generation f ile<<MACRO file>>

Format def inition f ile<<FRT file>>



Figure 5-65 Data Generator interfaces

5.3.5.4.6 ProcessingAll the features that provide data reading and writing functions are located in this object. When a user wants to read/write some data with EAST, he has first to indicate which data model he wants to use by specifying the EAST description file. This provokes the creation/loading of the DIANA form (DIANA tree) corresponding to the model. After that, the user can read data blocks corresponding to the model using two different ways: the sequential access or the direct access. In the case of the direct access, the operations are:

o read (on multi-file data product or on memory) o read_socket (that support the connection oriented Sockets) o read_standard_input

In the case of the sequential access:o select_data_product_from_file o select_data_product_from_socket o select_data_product_from_standard_input.

Then, the user set values to some data entities giving binary or ascii values or at random. The operations are:

o set_data_entity o force_data_entity

The value can be a value or a mathematical expression or function, in case of a given ascii value. The ability to set a random value taking into account intervals or string pattern is provided.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cx

The user can generate a block by using an external file that contains all the directives to generate the data. The operation is:

o generate_new_block Then the user writes the data blocks corresponding to the model. The operations are:

o write, flush, close_file (on multi file data product or on memory) o write_socket, flush_socket,flush_socket o write_standard_output, flush_standard_out, close_standard_output

The format of writing the integer and the real ascii can be specified by an external file (FRT file) that contains for each type of element the format to apply.

The user has the ability to release a block. If it is in memory, only in memory, if it is on the medium and the release is specified, the release will be done on the medium also. The operation is:

o release_block


Data_Generator (!)LANGUAGEOCTET_STRINGOCTET_STRING_ACCESSLENGTHKIND_OF_CONVERSION

type

Aiguilleur (!)LANGUAGETABLEAU_OCTETSPTR_TABLEAU_OCTETSENTIER_LONGKIND_OF_CONVERSION

Chargeur (!)

Chemins_Restants (!)

Generateur (!)

Gestion_Rangs (!)LISTES_DE_RANGS

Chemins_Presents (!)

Directives_Handler (!)Directives_Handler

Direct_Access_G (!)

Direct_Access_G

Figure 5-66 Structural (types) Diagram Data_Generator component


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxi


Data_Generator (!)startstop{handle_DDR}{sequential_read}{set_data_entity}{sequential_write}{parcourir}generate_new_block{sequence}release_block{select_data}{read_data}

operation

Common

Log_Book

SYSTEM

TEXT_IO

Configuration_Des_AccesP_STRING EAST_Analyser

EAST_Analyser

EAST_Analyser

Support_Physique

Data_Writer

Data_Writer

Data_Writer

Type_Converter

Type_Converter

Format_Converter

Format_Converter

System_Interface

EAST_Analyser

Data_Product_Explorer Data_Writer

Random_Numbers

Random_StringDYNAMIC_JAVA Expression_Evaluator

Aiguilleur (!)initialiserdesactiver{manipuler_DDR}{lire}{set_data_entity}{ecrire}{parcourir}

Chargeur (!){init_op}{charger}desactiver

Chemins_Restants (!)

etablir_liste

Generateur (!){init}{sequence}release_block{assigner}{ecrire}

Gestion_Rangs (!){gerer_les_rangs}

Chemins_Presents (!)visualiser

Directives_Handler (!)generate_new_block

Direct_Access_G (!)

{select_data}{read_data}

Figure 5-67 Functional (operations) Diagram Data_Generator component

5.3.5.4.7 Operations select_DDR This operation selects a description file (DDR). Then, an empty block is created in memory in order to be ready to receive the future generations of data entities. read#1 This operation is in charge to read data product from files (multi file or not). read#2 This operation is in charge to read data product from memory. read_socket This operation is in charge to read data from a socket. read_standard_input This operation is in charge to read data from the standard input. flush This operation is in charge to write the last octet, if it isn't write before, in the file. close_file


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxii

This operation is in charge to close the file. write_socket This operation is in charge to write data on a socket. write_socket#1 This operation is in charge to write data on a socket. The writing is not recorded in the DIANA form. flush_socket This operation is in charge to write the last octet, if it isn't write before, in a socket. close_socket This operation is in charge to close the socket. write_standard_output This operation is in charge to write data on the standard output. write_standard_output#1 This operation is in charge to write data on the standard output. The writing is not recorded in the DIANA form. flush_standard_output This operation is in charge to write the last octet, if it isn't write before, in the standard output. close_standard_output This operation is in charge to close the standard output. generate_new_block This operation is in charge of parsing the generation directives file for generate a new block. The generated data blocks are recorded in the DIANA form. select_data_product_from_file This operation takes into account the set of files that compose the data product and open the first one. select_data_product_from_memory This operation takes into account the memory address that contains the data product. select_data_product_from_socket This operation takes into account the socket that contains the data product. select_data_product_from_standard_input This operation takes into account the standard input which contains the data product. select_block This operation allows to be positioned on the block_number block in the selected data product. Furthermore, it prepares the future direct reading of the data entity in this selected block. read_data_entity_ascii This operation retrieves the value of a data entity by giving its EAST path. The value is converted in an ascii value. read_data_entity_binary This operation retrieves the value of a data entity by giving its EAST path. The value is converted to the required type. read_data_entity_binary#1 This operation has the same function of the read_data_entity_binary. It is used when the user doesn't know the length of the retrieved data.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxiii

5.3.5.5 Queries handler component

5.3.5.5.1 TypeThis component is not decomposed anymore. It is a terminal component and implemented by only one Hood root module: East_Query_handler.

5.3.5.5.2 PurposeSatisfy: SR311_DEQ Conformity: C

5.3.5.5.3 FunctionThis Queries handler component is added to the EAST core to be able to perform XML queries on data products. The Queries handler component is implemented mainly to support the services requested by the Data Extractor & Querying tool (DEQ). This component is therefore able to understand the XML-Query language used by the DEQ. It is in charge of decoding the XML-Query request, executing the query and returning the results to the calling application.

The XML-queries are submitted to Queries Handler that verifies and translates them, if well formed, in a sequence of EAST actions (this process is called the query compilation). The second step is to execute the query (search and retrieval of the data responding to the query) and to return the values to the calling application.

The Query handler component has to main functions.

The first function does the syntactic analysis of the query and builds the execution plan (this is the compilation phase). In particular, this part controls the execution plan elaboration in such a way that performances in time and space remain safe.

The second function plays the execution plan and loads the data responding to the request criteria. It is to be noted that the data responding to a query is not returned to the caller in a sole bulk of data (as the volume of data may be important). It's up to the caller to iterate on the results of a query (this mechanism is the same as for relational database queries) to retrieve the data. This approach guarantees good performances and gives full control to the user on how the data has to be extracted.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxiv




type

East_Query_Handler (!)A_QUERY_ACCESSDATA_RECORDS

STANDARD (!)

BOOLEANINTEGERNATURALPOSITIVEFLOATDURATIONCHARACTERSTRING

Interpreter (!)

LANGUAGELENGTHKIND_OF_CONVERSIONOCTETOCTET_STRINGOCTET_STRING_ACCESS

East_Analyser (!)TYPE_MANIPULATIONMANIPULATED_FORMCHAINE_IDENTSYMBOL_REPVALUENUMBER_REPSOURCE_POSITIONTREESEQ_OF_TYPENODE_NAMELISTE_DE_TREEREPONSEFigure 5-68 East_Query_Handler Structural (types) Diagram

The low typed data structure, OCTET_STRING provided by the EAST core module Interpreter is used in order to store file’s data.

Types provided by Ada package STANDARD are used to define components of data abstract types in both provided interface and internals of the actual module.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxv



operation

East_Query_Handler (!)ANALYSE_QUERYNEXT_DATA_RECORDSIS_COLUMN_PRESENTVARIABLE_VALUEFREE_DATA_RECORDSFREE_QUERYRECORDS_COUNTBLOCK_NUMBER_OF_RECORDSDATA_FILENAME_OF_RECORDS

STANDARD (!) Interpreter (!)

select_DDRset_on_DDRfocus_onrelease_DDRget_pathsget_paths_for_current_recordprepare_accesses_for_current_blockprepare_accesses_for_current_recordstartstop{get_data_entity}get_request_listrelease_access_pathget_number_occurrences_of_data_entityget_number_elements_of_arraystart_sequence_recordingstop_sequence_recordingremove_sequenceget_name_of_current_record{load_next_data_block}{load_next_record}{check_next_data_block}{check_next_record}get_errors_numberget_errors_number_in_current_blockclear_bufferclose_file

East_Analyser (!){analyse_DDR_and_pathnames}modify_pathname{about_focus}{release_and_deletion}{cleaning}{initialization}point_on_formpoint_on_pathname{internal_access_form}valeur_uniquevaleur_unique#1est_valeur_uniqueFigure 5-69 East_Query_Handler Functional (operations) Diagram

The EAST_Query_Handler relies on the East_Analyser to handle the EAST descriptions. The reading of the data files is delegated to the EAST core component, Interpreter.

5.3.5.5.5 InterfacesThis component handles two kinds of data:

EAST description files taken as input

Data files following the EAST description.

5.3.5.5.6 ProcessingOnce the query is compiled, an algorithm analyses and elaborates the execution plan to access data efficiently (which records to open, useful focuses, grouping accesses, etc.). The results are obtained piece by piece on demand to improve the performances. The execution plan is a partial DIANA tree of the EAST description: sole the sub-tree where variables to hold and discriminants on which the resulting reading depends are present. The actions involved in reading (focus, load_next_data_block, start_sequence recording, get_data_entity or stop_sequence_recording) are hold at the node involved.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxvi

The data reading is then led by the crossing of the execution plan according to discriminants from the beginning to the end, and the execution of the associated actions.

5.3.5.5.7 Types A_QUERY_ACCESS This type is an access to the compiled query. DATA_RECORDS This type stores result rows of query.

5.3.5.5.8 Operations ANALYSE_QUERY This operation analyses the EAST query and builds the execution plan. If the query provided by the caller is not well formed, an exception is raised and an error message is provided by EAST core. NEXT_DATA_RECORDS This operation provides the next resulting records of a query. An identifier specifies the query. An exception is raised when the identifier does not belong to any query. The returned records are gathered by data file and block. Exceptions of the EAST Interpreter are propagated too. IS_COLUMN_PRESENT This operation indicates the presence of a variable identified by its rank in the return section on the query. An exception is raised if the rank (less than 1 or greater than variables count) or index (less than 1 or greater than records count) is wrong. VARIABLE_VALUE This operation provides the value of a variable identified by its rank in the return section on the query. An exception is raised if the rank (less than 1 or greater than variables count) or index (less than 1 or greater than records count) is wrong. FREE_DATA_RECORDS This operation releases all the memory resources held by the specified data records. FREE_QUERY This operation releases the data structure involved in the query designated by an identifier.RECORDS_COUNT This operation provides the records count of a data records set. BLOCK_NUMBER_OF_RECORDS This operation provides the block number the specified data records belong to. DATA_FILENAME_OF_RECORDS This operation provides the data file's name the specified data records belong to.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxvii

5.3.5.6 Data algorithms component

5.3.5.6.1 TypeThe Data Algorithms component is composed of four components as shown in the following decomposition view:

Data Algorithms(from Component EAST core)

<<Component>>

Dynamic_Java<<Component>>

Random_Numbers<<Component>>

Random_Strings<<Component>>

Expression Evaluator<<Component>>

Figure 5-70 Data Algorithms component decomposition view

Component Purpose Hood module

Dynamic_Java Allows to dynamically execute Java code at runtime from Ada (no compilation needed)

Dynamic_Java

Expression Evaluator Allows to evaluate mathematical expressions following a predefined grammar


Random Numbers Provides functions that return random scalars (real or integer) belonging to a given definition domain

Random_Numbers

Random Strings Provides a package able to generate strings of fixed length satisfying an associated string pattern

Random_Strings


SR119_EASTCORE Conformity: CSR120_EASTCORE Conformity: CSR123_EASTCORE Conformity: CSR440_EASTCORE Conformity: CSR124_EASTCORE Conformity: CSR125_EASTCORE Conformity: C

5.3.5.6.3 FunctionThe Data Algorithms component is a completely new component designed to provide:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxviii

Calculation capabilities provided by Expression_Evaluator component: these calculations are defined as ADA functions directly in the EAST file. These calculation capabilities are mainly used by the Data Interpreter component.

The support for "external functions" provided by the Dynamic_Java component: these functions are defined in external files with a JAVA syntax. They are dynamically linked and executed at runtime by EAST to enhance/modify its behaviour. External functions are mainly used by the EAST Data Interpreter and Generator.

The ability to generate random values (provided by the Random_Numbers component) within a given interval defining the range of possible values. The Data Producer & Editor requires this feature.

The ability to generate random strings that match a given pattern. The Data Producer & Editor requires this feature that is provided by the Random_Strings component.

5.3.5.6.4 Dynamic Java component

5.3.5.6.4.1 Type

This component is not decomposed anymore. It is a terminal component and implemented by only one Hood root module: DYNAMIC_ JAVA.

5.3.5.6.4.2 Purpose

Satisfy: SR118_EASTCORE Conformity: CSR119_EASTCORE Conformity: CSR120_EASTCORE Conformity: CSR121_EASTCORE Conformity: C

5.3.5.6.4.3 Function

This component provides the ability to execute Java code within a running Ada application. These “java functions” are defined in external files read by the Interpreter and Data Generator. The Dynamic Java component is responsible for executing the Java code, and returning the results to the calling component (Interpreter or Data Generator).

This feature is particularly useful as it allows to enhance/modify at runtime the behaviour of EAST without the need to write and compile a separate program. This can be used to apply specific transformations to the raw data being read before returning them to the calling application (e.g. to apply a calibration curve), or during the writing process (e.g., for the reverse purpose when generating test data).

The following drawing gives an example of use from the Interpreter component:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxix

Figure 5-71 External function during data reading

In the previous example, the data returned to the calling user application is modified by the application of an external function written in an external file.

The following drawing gives an example of use from the Data Generator component: the data that is written to the data product is generated / modified by an external function.

Figure 5-72 External function during data reading

The Java language has been chosen for the implementation of the external functions, as it is the only programming language that provides dynamic linking and execution capabilities. Furthermore, this language is widely used and provides a wide range of powerful capabilities.

5.3.5.6.4.4 Dependencies


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxx


SYSTEM_CONFIGURATION

type

DYNAMIC_JAVAFLOAT_HASHTABLEINTEGER_HASHTABLESTRING_HASHTABLE

JNI_CAFE_1815E

STANDARDE

Figure 5-73 DYNAMIC_JAVA Structural (types) Diagram

Sole STANDARD ’s types dependency is needed.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxi



operation

DYNAMIC_JAVA{GET:

GET_VALUES_INTEGERGET_VALUES_FLOATGET_VALUES_STRING

}

JNI_CAFE_1815E

STANDARDE

Figure 5-74 DYNAMIC_JAVA Functional (operations) Diagram

JNI CAFE 1815 ’s functional dependency is needed in view to simplify interface between Ada language and Java.

5.3.5.6.4.5 Processing

The interface between Java and ADA are made with JNI (the CAFE 1815 implementation of JNI is used)

The dynamic linking and execution are implemented with a Java technology called DynamicJava. DynamicJava is a Java source interpreter that is able to execute programs written in Java on the fly (the compilation of the Java program is not necessary!). This technology is fully compatible with the Java Language Specification, is itself written in Java, and is a free open-source technology. More information can be found at http://koala.ilog.fr/djava.


http://koala.ilog.fr/djava

Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxii

Figure 5-75 Dynamic_Java component processing

The Dynamic_Java Ada component is called by the Interpreter and Data Generator when they need to execute a Java external function. The Dynamic_Java Ada component calls the DynamicJava tool through the CAFE 1815 JNI layer.

5.3.5.6.4.6 Types

FLOAT_HASHTABLE It is a Hashtable containing as key a variable name (if the variable is not bound to an EAST element) or the string representation of an EAST path (if the variable is bound to an EAST element). The corresponding value is a Float.INTEGER_HASHTABLEIt is a Hashtable containing as key a variable name (if the variable is not bound to an EAST element) or the string representation of an EAST path (if the variable is bound to an EAST element). The corresponding value is an INTEGER.STRING_HASHTABLEIt is a Hashtable containing as key a variable name (if the variable is not bound to an EAST element) or the string representation of an EAST path (if the variable is bound to an EAST element). The corresponding value is a STRING.

5.3.5.6.4.7 Operations

GET_VALUES_INTEGERThis function enables the user to get the value of an Integer parameter via an external java function. The parameters are three hash tables for the three types INTEGER, FLOAT, STRING, and the name of the external function.GET_VALUES_FLOATThis function enables the user to get the value of a Float parameter via an external java function.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxiii

The parameters are three hash tables for the three types INTEGER, FLOAT, STRING, and the name of the external function.GET_VALUES_STRINGThis function enables the user to get the value of a String parameter via an external java function. The parameters are three hash tables for the three types INTEGER, FLOAT, STRING, and the name of the external function.

5.3.5.6.5 Random_Strings component

5.3.5.6.5.1 Type

This component is not decomposed anymore. It is a terminal component and implemented by only one Hood root module: Random_Strings.

5.3.5.6.5.2 Purpose

Satisfy: SR438_EASTCORE Conformity: C


This component provides the ability to generate strings of fixed length satisfying an associated pattern. The string pattern syntax is the following:

regexp → term regexp → term '|' term // alternation term ( term or term ... ) term → itemterm → item item ... // concatenation ( item then item ) item → elmt item → elmt'*' // zero or more times elmt item → elmt'+' // one or more times elmt item → elmt'?' // zero or one time elmt elmt → nchr elmt → [nchr nchr ...] // any character between nchr, nchr ... elmt → ['^'nchr nchr ...] // any character but nchr, nchr ... elmt → [char'-'char] // any character in range of char and char elmt → '.' // any character elmt → '('regexp')' // grouping elmt → any character, including special characters nchr → any character except \()[].*+?^ or \char to match char.



Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxiv



type

Random_Strings

A_REGEXPA_SOLVED_REGEXPA_REGEXP_ERROR

StandardBOOLEANINTEGERNATURALPOSITIVEFLOATDURATIONCHARACTERSTRING

Figure 5-76 Structural (types) Diagram of Random Strings

This module only uses STANDARD’s types.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxv



operation

Random_Strings

SOLVINGRANDOMCOMPILATIONSOLUTIONS_COUNTLAST_ERROR#1LAST_ERROR#2

Standard

Figure 5-77 Functional (operations) Diagram of Random Strings

No functional dependency is required.


The regular expression is translated in a diophantine equation in order to handle the fixed length problem. For example, the regular expression aaa((ba)*(cab)*)*cdc* is described by 3+(2m+3p)*n+2+q = N where N is the length of the string to generate and m, n, p, q are unknown integers. Each time a regular expression is compiled such an equation is associated. The left member of the equation is cut in several variables. The whole composes an abstract tree of an arithmetic expression following the same hierarchy as the compiled regular expression. This way, the previous equation is translated to Z+q+5 = N, Z= Y*n, Y=2m+3p. Each time a string's length is submitted, the solutions are calculated to generate a string matching the given pattern. Two algorithms are possible to compute solutions to the equation:

Naive algorithm: From lowest sub-expressions to the whole, sub-string's lengths are calculated and transmitted provided that the resulting length does not exceed the total. Such a strategy of counting is not prohibitive in time. For example, the regular


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxvi

expression 'aaa((ba)*(cab)*)*cdc*' requires less than one tenth of second on a Sun Sparc machine, Ultra-5_10.

Equation solver: It consists in solving diophantine equations from the top expression to the lowest ones.

The generation of strings matching a given pattern is therefore performed in three stages:

The first one is the compilation of the string representation of the regular expression.

The second one, given the result of compilation, is the calculation of solutions for a given length. For a same compiled regular expression, several solutions can be found.

The last one is the final aim: the random generation given the set of associated solutions.


Random_StringsA_REGEXPA_SOLVED_REGEXPA_REGEXP_ERROR

type

Standard

list_of

list_of

one

REGEXPA_REGEXPA_SOLVED_REGEXPA_REGEXP_ERRORAN_ARRAY_OF_TERMSAN_ACCESS_TO_TERM

TERMA_TERMAN_ARRAY_OF_ITEMSA_CLASS_WIDE_ITEMAN_ARRAY_OF_NATURALSAN_ACCESS_TO_CLASS_WIDE_ITEM

ITEMAN_ITEMA_CLASS_WIDE_ELEMENTAN_ACCESS_TO_CLASS_WIDE_ELEMENT

BOUNDED_ITEMA_BOUNDED_ITEM

UNBOUNDED_ITEMAN_UNBOUNDED_ITEM

INTERVALS_ELEMENTAN_INTERVALS_ELEMENT

STRING_ELEMENTA_STRING_ELEMENT

ELEMENTAN_ELEMENT

Diophantine_SolutionsA_SET_OF_SOLUTIONSA_SOLUTION

Figure 5-78 Structural (types) Implementation Diagram of Random Strings


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxvii


Random_StringsSOLVINGRANDOMCOMPILATIONSOLUTIONS_COUNTLAST_ERROR#1LAST_ERROR#2

operation

sub_results delegation

sub_results

delegationsub_results

delegation

REGEXPSOLVINGRANDOMCOMPILATIONSOLUTIONS_COUNTLAST_ERROR#1LAST_ERROR#2SOLVEGENERATED_STRINGREGEXP#1REGEXP#2

TERMTERMSOLVEGENERATED_STRING

ITEMSOLVEGENERATED_STRING

BOUNDED_ITEMBOUNDED_ITEMSOLVEGENERATED_STRING

UNBOUNDED_ITEMUNBOUNDED_ITEMSOLVEGENERATED_STRING

INTERVALS_ELEMENTINTERVALS_ELEMENTSOLVEGENERATED_STRING

STRING_ELEMENTSTRING_ELEMENTSOLVEGENERATED_STRING

ELEMENT[SOLVE][GENERATED_STRING]

Diophantine_Solutions

Figure 5-79 Functional (operations) Implementation Diagram of Random Strings

5.3.5.6.5.6 Types

A_REGEXP This type holds the result of compilation of a string pattern in order to generate strings efficiently. A_SOLVED_REGEXP This type holds solutions for a fixed length of string. A_REGEXP_ERROR This type handles errors for regexps.

5.3.5.6.5.7 Operations

SOLVING This procedure calculates all the solutions given a fixed length of string.RANDOM This operation picks up a particular solution of the given solved regexp and builds the related string that is returned.COMPILATION This function creates a regular expression given a pattern. SOLUTIONS_COUNT


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxviii

This operation gives the feasible strings count. LAST_ERROR#1 This operation gives the last error that occurred to the given regexp. LAST_ERROR#2 This operation gives the last error that occurred to the given solved regexp.

5.3.5.6.6 Random_Numbers component

5.3.5.6.6.1 Type

This component is not decomposed anymore. It is a terminal component and implemented by only one Hood root module : Random_Numbers.



type

Random_Numbers

Figure 5-80 Random_Numbers component Structural (types) Diagram


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxix



operation

Random_Numbersrandom_numeric_valuerandom_char_value

Figure 5-81 Random_Numbers Functional (operations) Diagram

5.3.5.6.6.2 Purpose


The Random_Numbers component is provided to be able to generate integers or real within specified bounds/ranges.

The specified intervals shall be constrained in the element ranges of the EAST description to generate compliant values, or constrained out of the range to generate degraded values.


This component has no dependencies

5.3.5.6.6.5 Interfaces

This component has no interfaces; all the parameters for the random generation are given as argument to the functions.


The ADA API of this component includes the following method:

o random_numeric_value( with_def_domain : in string) return integer;o random_numeric_value( with_def_domain : in string) return real;o random_char_value(with_def_domain : in string) return character;


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxx

The parameter with_def_domain is made of intervals. Depending on the element’s type, the Random_Numbers component is able to handle numerical intervals, handle character/enumeration intervals and singletons, and handle union between intervals. Here are two examples: ‘a’ || [‘c’, ‘f’] ; [2, 10] || [13, 15].


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxxi

5.4 DEBAT Data Modeller

5.4.1 Type

The modeller component is composed of seven components as shown in the following decomposition view:


GUI<<Component>>

Data Manager<<Component>>

Files import<<Component>>

Files generation<<Component>>

Syntax<<Component>>

Semantic<<Component>>

Model ler Configuration<<Component>>

Figure 5-82- DEBAT Modeller components decomposition view.

The modeller component is implemented in the modeller.* package.

semantic

syntax gui dataManager filesGeneration

filesImport

configuration

modeller(from debat)

Figure 5-83 DEBAT Modeller components Package View.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxxii



Semantic Checks semantics data and generates the DEDSL files

modeller.semantic.*

Syntax Checks syntactic data and generates the EAST files and the format files (FRT).

modeller.syntax.*

Files Import Reads the EAST files and the OASIS-IF files.

modeller.filesImport.*

Files Generation Generates the type declaration files, and the documentation (RTF, HTML, PDF)

modeller.filesGeneration.*

Data Manager Manages the internal format: type library, XML-IF files (.xif) and allows the search capabilities.

modeller.dataManager.*

GUI Contains all GUI classes to display data structures, search results, syntactic and semantics information, type library and all GUI classes described in the following paragraphs.

modeller.gui.*

Modeller configuration Contains all classes that provide the modeller configuration: semantic configuration, language and GUI display configuration.

modeller.configuration.*


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxxiii


SR11_DEBAT Conformity: CSR12_DEBA Conformity: CSR13_DEBAT Conformity: C SR24_DEBAT Conformity: CSR33_DEBAT Conformity: CSR38_DEBAT Conformity: CSR18_DEBAT Conformity: CSR19_DEBAT Conformity: CSR143_MODELLER Conformity: CSR144_MODELLER Conformity: CSR148_ MODELLER Conformity: CSR149_ MODELLER Conformity: CSR420_PERFORMANCE Conformity: C SR146_ MODELLER Conformity: C SR151_ MODELLER Conformity: CSR152_ MODELLER Conformity: CSR153_ MODELLER Conformity: CSR154_ MODELLER Conformity: CSR159_ MODELLER Conformity: C

5.4.3 Function

The Modeller is basically a MMI that allows users to model data formats. Once the data formats modelled, the tool is capable of generating the EAST description (syntactic information) and the DESDSL description (semantic information in PVL or XML) conforming to the CCSDS recommendations. It is also able to generate the data type declarations in ADA, C/C++ and Java.All the features of the current EAST norm are supported. Moreover, several capabilities are added, such as the ability:

to specify real and integer formats (this formats applies to ascii encoded numbers, and are the used by EAST to write the value in a data product with the specified format),

to associate default values to a given element of the data model,

to define elements discriminated by a computed value (calculation capabilities),

to define "external functions" to enhance/modify the behaviour of EAST when reading/writing from/to a data product. These external functions are written directly in Java, and are dynamically linked with the EAST core to be executed (no compilation required).

to check that the syntactic information is correctly and exhaustively filled in the data model.

All the features of the current DEDSL norm are supported. Moreover, several capabilities are added, such as the ability:

to associate images or external files (e.g. UML diagram) to the semantic information,

to check that the semantic information is correctly and exhaustively filled in the data model.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxxiv

The Modeller provides documentation capabilities and is able to generate customisable documents in RTF, PDF and HTML formats.

It also supports the concept of "type library" allowing reusing parts of a data model between several projects/missions. The types coming from a library can be created, edited, loaded, and stored through a graphical interface.

All the functions of the Modeller described above are available through a graphical interface providing useful capabilities, such as: copy/paste, undo/redo, clone view, errors management, models removal/creation, drag & drop, zoom and search capabilities based on semantic and/or syntactic attributes. They are also made available through API's and command line.

The Modeller uses internally an XML file (called XML-IF) to store the data model. As the name implies, this file is XML-based, as opposed to the old OASIS that uses a specific proprietary format. However, as a strict requirement is to be backward compatible, the Modeller is provided with the ability to transform the old internal format of OASIS to the new XML-IF format, and to import directly EAST descriptions.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxxv

The following schema describes the functional logic view of the previous described functions.

Figure 5-84 Modeller functional logic

5.4.4 Dependencies

The Modeller component provides the ability to load XML-IF files into memory and the semantic and syntactic search capabilities that are used by the Data Producer & Editor and by the Data Extractor & Querying components.

The Modeller component depends on two libraries, the JGraph library which provides graphical components to build the tree representing the data model and the JAXB libraries which allows to generate classes to read and write XML-IF files (see paragraphs 5.4.6.1.6.1 and 5.4.6.2.3.1).It also depends on two components:

The Integrated Environment component which provides the Project Management component and defines the plug-in interface,

The General features component provides services (installation, internationalisation support, online help, screenshots functions, and printing).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxxvi






JGraph library<<JAR file>>

JAXB libraries<<JAR file>>

uses services

uses plugin interface & project management

tree graphical building

generating classes for reading/writing XML files

syntax & semantic search / XML-IF loading

syntax & semantic search / XML-IF loading

uses following services:- installation- internationalisation- online help- screenshot function- printing

Figure 5-85: Modeller components external dependencies view.

The GUI component provides a graphical interface between the user and the others “business” components. That’s why this component depends on all the others components, it requests each component to execute a service. The “buisness” components treat the request and the GUI component displays results. The GUI component is able to request:

the “Data Manager” component to search about a data element from a semantics or/and syntactic information and to read/write a XML-IF file,

the “Modeller Configuration” component to load or store XML semantic configuration file,

the “Files Generation” component to generate documentation and declaration (ADA, C/C++ and Java) type files,

the “Files import” component to read EAST files and OASIS-IF files.

the “Semantics” component to check the semantics data structure and to generate DEDSL files.

the “Syntax” component to check the syntactic data structure and to generate EAST files and FRT files

The “Files Import” component read files (EAST files and OASIS-IF files) to build internal objects structure representing the data model. The “Files Generation”, “Semantics” and “Syntax” components generate files; data contained in these files come from the internal objects structure representing the data model.The data model is represented in the XML-IF file which is managed by the “Data Manager” component. That’s why the four previous components depend on the “Data Manager” component.

The files generation component depends on the semantic and syntax component because it needs to check the semantics and syntactic structure before generating the files.

The dependencies are described in the following schemas:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxxvii

GUI<<Component>>




Syntax<<Component>>

Semantics<<Component>>


creates XML-IF structure creates XML-IF structure

syntactic check

semantics check

creates XML-IF structuregenerates documentations

read EAST files

Check semantics format

Check syntax structure

read/write XML-IF

generates FRT files

generates declaration type files

generates DEDSL files

generate EAST files

read OASIS-IF files

searchloads/stores configuration

creates XML-IF structure

Figure 5-86: Modeller components dependencies view.

5.4.5 Interfaces

The Modeller is based on an Internal form which is saved in XML files (XML-IF). This tool can read this file format and has to generate it. The previous OASIS-IF format has to be read by the tool to keep the compatibility with OASIS. It also has to read the EAST files to transform it in the internal format.

The semantic information contains a list of parameters. This list is stored in the “Semantic configuration file” (XML files).

The Modeller has to generate several kind of files. The internal format is saved in XML-IF files, the syntactic parameters are stored into the EAST files and the semantics parameters are saved into DEDSL files (XML and/or PVL format).The modeller component can generate documentation into HTML, PDF and RTF format. It has to generate format files (FRT), and type declaration file.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxxviii

Modeller(from Component Decomposition)

<<Component>>

XML-IF<<XML File>>

East Description<<EAST File>>

Oasis Internal Format<<OASIS-IF File>>

XML-IF<<XML File>>


Dedsl Description<<DEDSL File>>

Html Document<<HTML File>>

PDF Document<<PDF File>>

RTF Document<<RTF File>>

Format File<<FRT File>>

Declaration File<<Type Declaration File>>

Semantic configuration file<<XML File>>

Semantic configuration file

<<XML File>>

Figure 5-87 Modeller component Interface view.

5.4.6 Processing

The Modeller is itself implemented as a Java plug-in, so the ModellerManager class implements the PluginInterface class. It uses the Project Management component to open descriptions and files managed by this component.

The ModellerManager class uses several services of the General Features component: the printing function provided by the Printer class,

the help online display provided by the HelpManager class,

the screenshot function provided by the ScreenShot class,

the use of properties files provided by the Resource class. The use of properties files allows to configure GUI (internationalisation, size) and to store all GUI messages.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxxxix

makes screenshot




PluginInterface

init()start()stop()messageReceived()sendMessage()

<<Interface>>

ProjectManagementServicesInterface



Printer

run()printFile()printTable()printText()printComponent()printImage()

Resource

Resource()Resource()Resource()Resource()Resource()Resource()getString()getImageResource()getSoundResource()getFileResource()toString()setNullStringValueAllowed()setNullImageResourceAllowed()setNullSoundResourceAllowed()setNullFileResourceAllowed()

HelpManager

load()loadHelpSets()displayHelp()

ModellerManager

run()addProject()removeProject()print()displayHelp()doScreenShot()setLanguage()

implements

1

1

uses

11

prints

0..n

1

1

1

Screenshot

doScreenShot()saveScreenShot()

1

1

1

1

11

set properties files

0..n

1

shows online help

1

1

1

1

Figure 5-88 Modeller component class diagram

The ModellerServicesInterface class provides the modeller main functions to others components. It allows to load the XML-IF files, the EAST files and the OASIS-IF files. It provides the files generation service. The following files could be generated: EAST files, DEDSL-XML files, DEDSL-PVL files, HTML documentation, RTF documentation, PDF documentation, FRT file, ADA, C/C++ and Java declaration files and XML-IF files. It also provides syntactic and semantic


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxl

checking and searching functionalities. Finally, it is possible to get the current selected data model loaded in the Modeller and the list of data models opened by the Modeller.

ModellerServicesInterface

loadXmlIf()loadEastFile()loadOasisIf()generateEastFile()generateDedslXmlFile()generateDedslPvlFile()generateHtmlDocumentation()generatePdfDocumentation()generateRtfDocumentation()generateFormatFile()generateAdaDeclarationFile()generateC_CppDeclarationFile()generateJavaDeclarationFile()generateXmlIfFile()checkSyntax()checkSemantic()getModellerCurrentDataModel()getModellerOpenedDataModels()saveCurrentDataModel()searchElements()

Figure 5-89: ModellerServicesInterface class

5.4.6.1 GUI component

5.4.6.1.1 TypeThe GUI component is implemented in the modeller.gui.* package


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxli

frames(from gui)

panels(from gui)

gui


Figure 5-90: GUI component package view.

The following table shows the mapping between the package and the classes:


modeller.gui.frames.* MMI frame classes. ModellerFrame, SearchFrame.modeller.gui.panels.* Panels classes DescriptionPanel,

TypeLibraryPanel, InternalTypePanel, ConstantType Panel, SemanticAndSyntacticPanel, SyntacticPanel, SemanticPanel.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxlii

5.4.6.1.2 PurposeSatisfy: SR147_ MODELLER Conformity: C

SR168_ MODELLER Conformity: CSR169_ MODELLER Conformity: CSR170_ MODELLER Conformity: CSR171_ MODELLER Conformity: CSR172_ MODELLER Conformity: CSR173_ MODELLER Conformity: C SR174_ MODELLER Conformity: CSR175_ MODELLER Conformity: CSR176_ MODELLER Conformity: CSR177_ MODELLER Conformity: CSR178_ MODELLER Conformity: CSR179_ MODELLER Conformity: C SR180_ MODELLER Conformity: CSR181_ MODELLER Conformity: CSR182_ MODELLER Conformity: CSR183_ MODELLER Conformity: C SR184_ MODELLER Conformity: CSR150_ MODELLER Conformity: CSR158_ MODELLER Conformity: CSR178_ MODELLER Conformity: CSR179_ MODELLER Conformity: CSR180_ MODELLER Conformity: C

5.4.6.1.3 FunctionThe GUI component is the user interface component. It is composed of graphical elements (frames and panels) requesting the others components. The MMI shows:

a tree view of the data description,

a tree-view of the types contained in the Modeller type library,

a list of the constants and the internal types of the description,

the syntactic and semantics information of the description elements.

5.4.6.1.4 DependenciesThe GUI component depends on all the others components, these dependencies are described in the previous paragraph (cf. paragraph 5.4.4).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxliii

GUI<<Component>>




Syntax<<Component>>



read/write XML-IF

search

read EAST files

read OASIS-IF files

generates documentations

generates FRT files

generates declaration type files

Check syntax structure

generate EAST files

Check semantics format

generates DEDSL files

loads/stores configuration

Figure 5-91: GUI component dependencies.

5.4.6.1.5 ProcessingAll the graphical interface of the Modeller is implemented in Java (SWING library).

The GUI component contains a lot of classes which implement frame and panels (Panels are low graphical components). The following class diagram describes:

The ModellerFrame which is the main frame containing the others panels.

The DescriptionPanel that contains the tree representing the data model. The tree-view is implemented on top of an existing graph library called JGraph. JGraph is a free open source Java library that provides advanced capabilities to draw and handle graph and tree-view structures. More information can be found at http://jgraph.sourceforge.net/.

The TypeLibraryPanel, InternalTypePanel and ConstantTypePanel display respectively the type library explorer, the internal types list and the constants lists.

The SemanticAndSyntacticPanel display the semantic and syntactic information. Two panels are in charge of displaying these information: the SemanticPanel and the SyntacticPanel.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxliv

SemanticPanel(from panels)

SyntacticPanel(from panels)

SemanticAndSyntacticPanel(from panels)

1

1

1

1

contains

1

1

1

1

contains

ConstantTypePanel(from panels)

InternalTypePanel(from panels)

TypeLibrayPanel(from panels)


SearchFrame

search()

DescriptionPanel

addElement()removeElement()removeLevel()refresh()

(from panels)

DataManager

readNewDataModel()addDataModel()saveCurrentDataModel()createDataModel()removeDataModel()search()



Modeller Configuration<<Component>>


Syntax<<Component>>

uses

FilesGenerator

generateFrtFile()generateTypeDeclarationFile()generateDocumentation()

SemanticsManager

checksSemantics()generateDEDSL()

SyntaxManager

checkSyntax()generateEastFile()

SemanticConfigurationManager

addDocumentation()removeDocumentation()getCurrentDocumentation()

ModellerFrame

addDescription()removeDescription()addLibrary()removeLibrary()

(from frames)

1

1

1

1

shows

1

1

1

1

shows

1

1

1

1

shows1

1

1

1shows

0..n1 0..n1

shows

1

1

1

1

shows

generates

checks and generates

checks and generates

FilesReader

readOasisIfFiles()readEastFiles()createDataModel()

reads Oasis and East files

loads/saves documentation

Figure 5-92: GUI component class diagram.

5.4.6.1.6 Sketches of a GUIThe ModellerFrame is made up with a high-level frame containing a menu bar and a toolbar providing access to the functions of the Modeller. It is split into several areas dedicated so the display/edition of each set of functions:

the description panel that shows the model tree-view navigation and display,

the semantic and syntactic panel shows the semantics and syntactic information edition and display,


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxlv

the type library panel shows the type library tree.

The internal type panel that shows the list of types that belong to the description.

The constant type panel that shows the list of the constants of the description.

Figure 5-93: ModellerFrame

5.4.6.1.6.1 Description panel

The description panel is made up with a panel that displays the data models being edited in a tree view graphical form.

The description panel provides the following capabilities: Mouse handling capabilities : popup menus display and invocations, left/right mouse

clicks, select node or group of nodes.

UI functions : zoom, scroll up/down/right/left, expand/collapse tree, copy/paste element, undo/redo, drag and drop elements, clone model view.

Model handling : add/move/remove element.

Some operations can be executed from this tree: adding an element,


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxlvi

remove an element,

add/remove a level in a branch of the tree,

adding existence conditions,

copy/cut/paste operations,

zoom,

clone the view.Theses operations can be executed from a “pop-up” menu described in the following paragraph (cf. paragraph Data model Tree menus 5.4.6.1.7.3).

Figure 5-94: description panel


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxlvii

5.4.6.1.6.2 Semantic and syntactic panels

The syntactic panel is made up of several panels (one panel for each EAST basic type: integer, real, character, string, array, list, record, enumeration) that display the syntactic information related to the element selected in the tree-view. It also provides edition capabilities so as to modify the syntactic information of a given element in the data model.The syntactic panel is very similar to the old OASIS MMI panels (the UI design was deduced from this reference so as to not disturb current OASIS users).

The semantic panel is made up of several panels that display the semantic information related to the element selected in the tree-view. It also provides edition capabilities so as to modify the semantic information of a given element in the data model.The semantic panel is rather similar to the old OASIS MMI panels, but several enhancements are made. The semantic information is presented in a more compact way; enough space is given to users to fill-in the semantic information (in the current OASIS, the text fields to enter the semantic information are too small); a working copy/paste function is provided to be able for example to copy text from external applications (such as Word) and to paste it in the Modeller (this feature is lacking in the current OASIS).

The syntactic and semantic panel is also used into the element modification frame. The parameters of the elements are not just displayed but edited.

The following sketch of GUI shows the element modification frame which allows to modify the syntactic and semantic parameters of the selected element.

Figure 5-95:Element Modification frame


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxlviii

5.4.6.1.6.3 Type library panel

The type library panel provides a tree-view of the types contained in the Modeller type library. This tree structure is built directly upon the JTree Swing widget.

Users can add, edit, or remove types in the library through popup menus displayed when a given node of the tree-view is selected with a mouse right-click. Types coming from the library can be assigned to the elements of the data model being edited, and inversely, types belonging to a specific data model can be stored in the type library for future reuse.

The type library interface looks like a files explorer where the libraries are mounted and unmounted on the root node which is named “Filesystem” in the following example. The libraries appear like folders in the “windows explorer” and the type are the leaf of this tree.

Figure 5-96: Type Library panel


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxlix

5.4.6.1.6.4 Semantic and syntactic search

The search frame provides two parts to set the syntactic request and the semantic request.The user filled the searched words corresponding to the parameters and make its own expression with the “insert buttons” and the “(“, “)”, “&” and “|” button.

Figure 5-97: Search frame

5.4.6.1.6.5 Modeller configuration

The GUI of the Modeller configuration component has two parts: the Semantic configuration part, this GUI allows to add and define, or remove semantics

parameters from the list.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cl

Figure 5-98: Configuration frame

the GUI configuration part allows to choose the language and some GUI presentation.

Figure 5-99: Configuration frame


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cli

5.4.6.1.7 Menu tree

5.4.6.1.7.1 Modeller frame menu

The following table shows the menu structure of the Modeller frame:

Menu Sub-menus Description

File

New Creates a new data model

Open Opens an existing data model from an XML-IF file (*.xif)

Close Closes a data model.

Save Saves the current data model into the associated XML-IF file.

Save as Saves the current data model

Print Prints the data tree and all of the semantic and syntactic information.

Capture Makes a screenshot of the tree and saves it as an image or prints it.

Exit Quits the modeller application.

Edit

Undo Cancels the last action into the treeRedo Cancels the last cancellation .Cut Cut the selected element into the tree.Copy Copy the selected element into the tree

Paste Paste the element which was cut or copied into the selected Record

Delete Delete the selected element and all of the descendants.

Delete Level Delete the selected Record and paste the descendants at the level above.

Find Launches the semantic and syntactic search tool.

Settings GUI which offer a set of configuration parameters for the modeller.

Check

Syntactic check Check the syntactic structure of the data.Semantic check Check the semantic structure of the data

Check all Check the semantic and syntactic structure.

Generate Generate DEDSL-XML Generate the DEDSL file in the XML format

Generate DEDSL-PVL Generate the DEDSL file in the PVL format

Generate EAST Generate the EAST FileGenerate ADA declaration Generate the ADA declaration fileGenerate C/C++ declaration Generate the C/C++ declaration fileGenerate Java declaration Generate the Java declaration file


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clii


Generate RTF documentation Generate the documentation in the RTF format

Generate PDF documentation Generate the documentation in the PDF format

Generate HTML documentation Generate the documentation in the HTML format

View

View DEDSL-XML View the DEDSL file in the XML formatView DEDSL-PVL View the DEDSL file in the PVL formatView logical EAST View the logical EAST partView physical EAST View the physical EAST partView ADA declaration View the ADA declaration fileView C/C++ declaration View the C/C++ declaration fileView Java declaration View the Java declaration file

Tools

Import EAST Read a EAST file and generate the associated data model (XML-IF)

Import OASIS-IF Transform the OASIS-IF format into the XML-IF format

Dates Information Display dates information about the last generations

Help

Contents Display the help GUI.

AboutDisplay several information about the Modeller (version, authors, dates of the last version).

5.4.6.1.7.2 Type library menus

These following menus are popup menus which appear when the user clicks on the right mouse button. The menus are different according to the element where the mouse click is executed:

On the Root element :

Menu Description

Mount library The user can choose a library, and it is added to root libraries list.Refresh Refresh all the tree.

On a Library element

Menu Description

New type Creates a new type in the selected library. A data description tree maker frame allows to build the type.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cliii

Menu Description

New folder Creates a new folder in the selected library.Unmount library Removes the selected library from the root.Save library Store library on files.Refresh Refresh the library folders.

On a folder Element

Menu Description

New type Creates a new type in the selected folder. A data description tree maker frame allows to build the type.

New folder Creates a new folder in the selected folder.Remove folder Removes the selected folder all descendants files.Save types Stores all the types containing in the selected folder.

On a type element

Menu Description

Edit type Edit the type with a data description tree.Delete type Delete the selected type.Save type Save the selected type into a file.

Some actions can be executed with the drag and drop mouse functionality: The user can drag and drop a type from the tree to the library. By this way, the type is

added to the library.

The user can select a type and add it in the tree.

5.4.6.1.7.3 Data model Tree menus

These following menus are popup menus which appear when the user clicks on the right mouse button. The menus are different according to the element where the mouse click is executed:

On an element of the tree

Menu Description

Modify Shows the modification frame (see Figure 5-95:Element Modification frame)

Add fieldThis functionality is set when the selected element is a record. The element modification frame is shown to enter the syntactic and semantics parameters value.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cliv

Menu Description

Remove levelThis functionality is set when the selected element is a record. The record is deleted and the elements containing in this record become elements of the parent when this one is a record.

Copy Copy the selected element.Cut Cuts the selected element

Paste Pastes the loaded element (from the copy or cut function) into the selected element.

Delete Deletes the selected element and all of its descendants.

Existence conditions Shows the existence conditions frame to set the existence condition of the selected element.

Applied functions Shows the applied functions frame. This frame allows to set the functions to defining the selected element.

The user can selected several elements in one time. This action creates a new Record element which containing the selected element.

Out of the tree

Menu Descritpion

Zoom in Zoom in the tree viewZoom out Zoom out the tree viewSyntactic check Launches the syntactic check.Semantic check Launches the semantics check.Clone view Clones the tree view in independent second frame.Close Closes the current data description tree.Save Saves the current model.

5.4.6.2 Data Manager component

5.4.6.2.1 TypeThe data manager component is implemented in the modeller.dataManager.* package


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clv

searchManager(from dataManager)

ifManager(from dataManager)

objectsIf(from ifManager)

typeLibraryManager(from dataManager)

dataManager


Figure 5-100:DataManager component package view.



modeller.dataManager.* All classes that handle the data model, the type library and allow the search engine to look for syntactic or semantic information..

DataManager.

modeller.dataManager.searchManager.* All classes that allow the search engine to look for syntactic or semantic information..

DataSearch.

modeller.dataManager.typeLibraryManager.* Classes that read/write and handle the type libraries.

TypeLibraryManager.

modeller.dataManager.ifManager.* Classes representing the data description and the element of the data.

DataModel, ObjectsIf,.

modeller.dataManager.ifManager.objectsIf.* All classes generated with JAXB from the schemas describing the XML-IF file structure.

These classes are automatically generated by JAXB.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clvi


SR161_ MODELLER Conformity: CSR162_ MODELLER Conformity: CSR163_ MODELLER Conformity: CSR164_ MODELLER Conformity: CSR165_ MODELLER Conformity: CSR166_ MODELLER Conformity: CSR167_ MODELLER Conformity: C SR185_ MODELLER Conformity: CSR186_ MODELLER Conformity: CSR188_ MODELLER Conformity: CSR189_ MODELLER Conformity: CSR190_ MODELLER Conformity: CSR191_ MODELLER Conformity: C

5.4.6.2.3 FunctionThis component is split into three sub-components: the IF manager, the Type Library manager, and the Search manager. The data manager component holds a list of the opened data models, and is responsible for ensuring the correct mapping between the XML-IF files and the object structures mounted in memory.

5.4.6.2.3.1 -IF manager

The Modeller uses an XML file internally to store the data models. The -IF manager component is in charge of reading the XML-IF file, translating it into an object structure representing the data model in memory, and storing the object structure in the XML-IF file when updated by users. It also provides functions to add/remove/insert elements.

5.4.6.2.3.2 Type Library manager

The type library manager component is responsible for the management of the Modeller type library. This library is intended to allow the reuse and the sharing of predefined types (sub-parts of data models) between several data formats or projects/missions. This new function allows the definition of reusable libraries that can be shared and distributed among several projects/missions.

The type library manager component is in charge of providing the ability: to create a new type in the library: the type is created from scratch by the user.

to add a type in the library: the type is extracted from a data model being edited (this type is therefore a sub-part of the data model being edited).

to edit a type of the library to change the type.

to remove type from the library.

Types coming from the type library are not different from the types contained within a data model (these ones are said to be internal types, as opposed to the types belonging to the type library that are saved in an external XML file). Only one extra tag is added to indicate that the type belongs to the type library.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clvii

The type library manager component provides a hierarchical organisation of the types stored in the library. This organisation is identical to the file system folder organisation: users are thus able to organise their types, as they want. References to types belonging to the library are explicitly made giving the relative path from the root of the type library manager.

5.4.6.2.3.3 Search manager

The search manager component provides several functions to search for elements in a data model.

It supports searching with syntactic or semantic attributes (or any combination of both). Syntactic searching is based on the following information: element name, type, size or

bounds.

Semantic searching is based on the semantic attributes name or content.

"AND" and "OR" operators are supported for combining several search criteria. The "*" and "?" meta-characters are also supported by the search engine.

5.4.6.2.4 InterfacesThe Data Manager component reads and generates XML-IF files.

XML-IF<<XML File>>

XML-IF<<XML File>>


Figure 5-101: Data Manager Component Interface view.

5.4.6.2.5 ProcessingThe Data Manager component is managed by the DataManager class which provides the main functions to handle data models and make requests for semantic and syntactics search. The TypeLibraryManager class allows to manage the handling of type libraries.

5.4.6.2.5.1 JAXB generation

These mapping classes are automatically generated using a Java technology called JAXB (that stands for Java API for XML Binding). JAXB is part of the Java Web Services Developer Pack, an all-in-one package for XML handling providing support for technologies such as SAX, DOM, XSLT, SOAP, UDDI, and WSDL. More information can be found at http://java.sun.com/webservices/webservicespack.html.

JAXB is a powerful, timesaving and less error-prone technology that is able to generate automatically the mapping classes capable of reading/loading XML documents in memory, and for the reverse process, capable of storing the object structure in an XML document that reflects the state of the objects in memory.

JAXB takes as input an XML schema defining the structure of the XML-IF document and generates as output a set of Java classes to read/write the XML-IF file. This set of classes is then used by the other components of the Modeller to access the information of the data model being edited.


http://java.sun.com/webservices/webservicespack.html

Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clviii

Figure 5-102 Modeller XML-IF file manager architecture

5.4.6.2.5.2 Type library definition

Types of the library are defined in XML files following exactly the same structure as the XML-IF used for the data models. They are handled in the same way as for a complete data model: the same mapping classes generated by JAXB are used to load/save the types of the library.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clix

Figure 5-103 Type Library Manager

5.4.6.2.5.3 Search

The search is directly performed on the object structure loaded in memory by the IF manager component. This object structure is basically a tree that reflects the elements of the data format. The search manager traverses the object tree starting from the root and applying the search criteria to each node: if a node fulfils the criteria, it is added to the list of the responding elements; if no, the next node is visited. Once the tree exploration is completed, the list of the responding element is returned to the calling component.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clx

Figure 5-104 Search manager architecture

The previous descriptions are represented in the following class diagram.

IfJaxbGenerated(from objectsIf)

TypeLibraryManager

loadLibrary()saveLibrary()

(from typeLibraryManager)

DataManager

readNewDataModel()addDataModel()saveCurrentDataModel()createDataModel()removeDataModel()search()

1

1

1

1

manage

ObjectsIf

namepathNameparent

(from ifManager)

0..n

0..n

0..n

0..ncontains

DataModel

root

addElement()deleteElement()DeleteLevel()

(from ifManager)

0..n1 0..n1lists

0..1

1

0..1

1

treats

1

1..n

1

1..n

contains

DataSearch

search()

(from searchManager)

1

1

1

1

1

0..n

1

0..n

lists

load

Figure 5-105: Data Manager Component class diagram.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxi

5.4.6.3 Modeller Configuration component

5.4.6.3.1 TypeThe Modeller configuration component is implemented in the modeller.configurationManager.* package.

objectsDoc(from configuration)

configuration


Figure 5-106: Modeller Configuration component package view.



modeller.configuration.* All classes that handles the modeller configuration.

SemanticConfigurationManager, SemanticConfigurationModel, ObjectsDoc.

modeller.configuration.objectsDoc.* All classes generated with JAXB from the schemas describing the semantic configuration XML file structure.

generated


5.4.6.3.3 FunctionThis component manages the semantic configuration which is the list of semantics parameters proposed to the user for the semantic information of the data. This list contains some mandatory parameters and can be enhanced by new ones.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxii

5.4.6.3.4 InterfacesThe Modeller configuration component reads and generates Semantic Configuration files. These files are XML files (*.xsc).



Modeller Configuration<<Component>>

Figure 5-107: Modeller Configuration interface view.

5.4.6.3.5 ProcessingThe configuration is stored in a XML files. The modeller configuration component manages the mapping between the XML files and the object structures mounted in memory. The mapping is ensuring by the JAXB technology already used for the Data Manager component (cf paragraph 5.4.6.2.3.1)

JAXB takes as input an XML schema defining the structure of the semantic configuration file (*.xsc) and generates as output a set of Java classes to read/write the XML-IF file. This set of classes is then used by the other components of the Modeller to access the information of the data model being edited.

Figure 5-108 Modeller XML-IF file manager architecture


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxiii

The SemanticConfigurationManager class provides functions to add or remove new configuration file.

SemanticConfigurationManager

addDocumentation()removeDocumentation()getCurrentDocumentation()

SemanticConfigurationModel

load()save()

1 0..n1 0..nlists

ObjectsDocname

1

1..n

1

1..n

contains

Doc_JaxbGenerated(from objectsDoc)

5.4.6.4 Files import component

5.4.6.4.1 TypeThe Files Import component is implemented in the modeller.filesImport.* package

eastFiles

oasisFiles

filesImportmodeller(from debat)

Figure 5-109: :Files Import component package view.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxiv


modeller.filesImport.* The class that offers the service to read EAST files and OASIS-IF files. This class calls the services of the following classes.

FilesReader.

modeller.filesImport.eastFiles.* The class which allows to read EAST files and to transform the data into XML-IF format.

EastFileReader..

modeller.filesImport.oasisFiles.* The classes which allow to read and OASIS-IF files and to transform the data into XML-IF format.

OasisIfReader.


SR19_DEBAT Conformity: C SR145_ MODELLER Conformity: C

5.4.6.4.3 FunctionThe OASIS-IF files import component is in charge of transforming the old OASIS internal proprietary format into the new XML-IF format (XML based). This function is mainly implemented to guarantee the backward compatibility with existing data models made with the current OASIS.

The goal of the EAST files import component is to provide the ability to transform an EAST description into an XML-IF data model (for example, in case the XML-IF file has been lost).This function is to be used with care, as it is not the normal way of working with the Modeller (the process of recovering an XML-IF file from the EAST description can be viewed as a king of reverse engineering process).

5.4.6.4.4 DependenciesThe Files import component depends on the Data Manager component. The Data Manager component allows to load the XML-IF structure representing the data model. The Files Import component reads OASIS-If and EAST files and set data into the data model.


creates XML-IF structure Data Manager<<Component>>

Figure 5-110: Files Import Interface View

5.4.6.4.5 InterfacesThe Files Import component reads the EAST files and the OASIS-IF files.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxv


Oasis Internal Format<<OASIS-IF File>>


Figure 5-111: :Files Generation component Interface view.

5.4.6.4.6 ProcessingThe Oasisfiles sub-component is developed in Java and is totally independent of the rest of the Modeller. It is composed of a set of Java classes that takes as input the old IF, reads and parses the model information and generates an XML-IF file that reflects the data model stored in the old IF. As the concept implemented in the old IF and in the new XML-IF are similar (both file contain exactly the same information), the transformation process is a simple translation of the items found in the input file.

Figure 5-112 OASIS-IF files import component

The EastFiles sub-component is implemented with a technology called JavaCC. Java Compiler Compiler (JavaCC [tm]) is the most popular parser generator for use with Java [tm] applications. A parser generator is a tool that reads a grammar specification and converts it to a Java program that can recognise matches to the grammar. More information can be found at http://www.experimentalstuff.com/Technologies/JavaCC.

The EAST file import component is thus built upon an ADA parser built in Java. This Ada parser is automatically generated with the JavaCC technology. The EAST file import component uses this Ada parser to read the EAST file and to transform it into and internal object structure that is then written in an XML-IF file by the XML-IF file manager.


http://www.experimentalstuff.com/Technologies/JavaCC

Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxvi

Figure 5-113 EAST import files generator architecture

The Files Import component has three main classes: The FilesReader class provides the following services: reading of an Oasis-IF file,

reading of an EAST file and creating of a data model from one of theses reading.

The EastFilesReader class reads the EAST file.

The OasisIfFilesReader class reads the OASIS-IF file.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxvii

EastFilesReader

readFile()

(from eastFiles)

OasisIfFilesReader

readFile()

(from oasisFiles)


FilesReader

readOasisIfFiles()readEastFiles()createDataModel()

1

1

1

1

uses

1

1

1

1

uses

DataModelroot


0..n1

creates

0..n1

Figure 5-114: :Files Generation component class diagram.

5.4.6.5 Files generation component

5.4.6.5.1 TypeThe Files generation component is implemented in the modeller.filesGeneration.* package


filesGeneration

documents(from filesGeneration)

typeDecalarations(from filesGeneration)

Figure 5-115: :Files Generation component package view.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxviii


modeller.filesGeneration.* The class that offers the service to generate documents, type declaration files and format files. This class calls the services of the following classes.

FilesGenerator.

modeller.filesGeneration.documents.* The classes that generates documents (PDF, RTF and HTML).

DocumentGenerator, HtmlGenerator, PdfGenerator, RtfGenerator.

modeller.filesGeneration.typeDeclarations.* The class that generates the type declaration files .

TypeDeclarationGenerator.


SR202_ MODELLER Conformity: CSR203_ MODELLER Conformity: CSR386_PPT Conformity: C SR196_ MODELLER Conformity: CSR197_ MODELLER Conformity: CSR198_ MODELLER Conformity: CSR199_ MODELLER Conformity: CSR200_ MODELLER Conformity: C

5.4.6.5.3 FunctionThe Files generation of the Modeller has three functionalities processed by three sub-components described hereafter: the Document generator, the type declarations generator and the format files generator.

The document generator provides the ability to generate documents in HTML, PDF or WORD/RTF formats for documenting the data models made with the Modeller.

The current OASIS is able to generate an ADA file containing the type declarations representing the types defined in a data model. This file is basically an ADA specification package that can be used directly by ADA user applications to accelerate the development of programs based on EAST.The goal of the Type Declaration generator component is to extend this function to support the generation of the type declaration not only in ADA, but also in C/C++ and Java (as some user projects use C/C++ and Java as well).

5.4.6.5.4 DependenciesThe Files generation component depends on the Data Manager component because it needs to use the data model containing in this component to generate the files.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxix

It depends on the semantic and syntax components to check the semantics and syntactic structure before generating the documentations.



traverses XML-IF structure

semantics check syntactic check


Syntax<<Component>>

Figure 5-116: Files generation component dependencies view.

5.4.6.5.5 InterfacesThe Files generation component generates documentation (HTML, PDF and RTF format) and type declaration files.

Html Document<<HTML File>>

PDF Document<<PDF File>>

RTF Document<<RTF File>>

Declaration File<<Type Declaration File>>


Figure 5-117: Files Generation Interface view.


5.4.6.5.6.1 Document generator


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxx

The document is generated from the syntactic and the semantics information stored within the XML-IF file (that gathers all the necessary information). This component is implemented using the XSLT and XSL-FO technologies.

XSLT (eXtensible Stylesheet Language for Transformation) is a declarative language based on template rules that specify how XML documents are to be processed. This technology is used to automatically transform XML documents into another XML documents (with a different structure). An XSL style sheet specifies what output should be produced when a pattern in the original XML document is matched. Used in conjunction with XSL-FO (XSL-Formatting Objects), it allows transforming XML documents into another format such as RTF, HTML, or PDF.

The document generator is built upon an existing XSL engine called FOP. This tool is capable of processing XSLT/XSL-FO inputs to generate the corresponding output format. FOP is an open source XSLT/XSL-FO processor developed by the Apache consortium. More information can be found at http://xml.apache.org/fop/.

Figure 5-118 document generator architecture

The XSL engine uses the XSLT style sheets to generate the documentation (in RTF, HTML or PDF) associated to the XML-IF data model.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxi

Three style sheets are provided by default by the Document generator: one for generating the documentation in HTML, the second one in PDF and the last in RTF/WORD. Moreover, users have the ability to add their own style sheet to produce documents following their own guidelines and closer to their needs.

5.4.6.5.7 Type declarations generatorThis generation process is directly performed on the object structure loaded in memory by the IF manager component.

The type generator traverses the object tree starting from the root and visiting each node: when a node is encountered, it is transformed into a type declaration according to the target language chosen by the user. Once the tree exploration is completed, the type declaration file is generated.

Figure 5-119 Type declaration generator architecture

The FilesGenerator class provides the generation of Format files, Documentation files and type declaration files. Theses generation are executed by specifics classes TypeGenerator, FrtGenerator and DocumentationGenerator. The DocumentationGenerator class uses three classes to generate documentation: RTFGenerator, PDFGenerator and HTMLGenerator.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxii


RTFGenerator

generateRTF()

(from documents)PDFGenerator

generatePDF()

(from documents)HTMLGenerator

generateHTML()

(from documents)

TypeDeclarationGenerator

generateTypeDeclarationFile()

(from typeDecalarations)

DocumentGenerator

generatePDF()generateHTML()generateRTF()

(from documents)

1

1

1

1

generates1

1

1

1

generates

1

1

1

1

generates

DataModelroot


FilesGenerator

generateFrtFile()generateTypeDeclarationFile()generateDocumentation()

1

1

1

1

uses

1

1

1

1

uses

1..n1 1..n1

uses

Figure 5-120: Files Generation class diagram

5.4.6.6 Syntax component

5.4.6.6.1 TypeThe Syntax component is implemented in the modeller.syntax.* package


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxiii

eastChecker

eastGenerator

syntax


Figure 5-121: Syntax component package view.


modeller.syntax.* This class provides the following services to the others components: syntax checking and EAST files generation.

SyntaxManager

modeller.syntax.eastChecker.* This class checks the syntax structure of the data.

SyntaxChecker

modeller.syntax.eastGenerator.* This class generates the EAST file and the format files

EastGenerator, FormatFileGenerator


SR156_ MODELLER Conformity: CSR192_ MODELLER Conformity: CSR193_ MODELLER Conformity: C

5.4.6.6.3 FunctionThe Syntax component has two functionalities processed by two components: the EAST checker and the EAST generator.

The EAST checker component is in charge of verifying that all the information required to generate the EAST description file has been correctly filled-in by the user.The verification consists in checking that: All the mandatory information has been entered (element name, type, bounds if

required, etc.).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxiv

The minimum is less than the maximum for the definition of integer or real bounds,

The size of the lists/arrays is greater than 0.

All the enumerations have at least one element.

The target machine has been chosen.

The EAST generator component is in charge of generating the EAST description conforming to the CCSDS EAST recommendation. The generation process takes place after the EAST checking is completed. It is also capable of generating a format file (FRT file) that defines how ascii-encoded numbers have to be written to a data product. These formatting specifications are used by the EAST core, and more precisely by the Data Generator.The format file contains the following information for each element to format: the full EAST path of the element and the format to apply (using printf conventions).

Example:

N1.RECORD1.A = %20fN1.RECORD1.B = %+3.5e

…

5.4.6.6.4 DependenciesThe Syntax component depends on the Data Manager component because it needs to use the data model to generate the EAST files.

creates XML-IF structureSy ntax<<Component>>


Figure 5-122: Syntax component dependencies view


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxv

5.4.6.6.5 InterfacesThe Syntax component generates the EAST files and the FRT files.

Syntax<<Component>>


Format File<<FRT File>>

Figure 5-123 : Syntax Component Interface view.

5.4.6.6.6 ProcessingThe verification is directly performed on the object structure loaded in memory by the IF manager component. The EAST checker traverses the object tree starting from the root and applying the checks to each node: if a node violates a checking rule, it is added to the list of the elements in error. Once the tree exploration completed, the list of the element in error is returned.

Figure 5-124 EAST checker architecture

The EAST generator traverses the object tree structure mounted in memory and generates the EAST file according to rules that allows transforming the internal model into EAST syntax. It starts with the generation of the logical package (types and variables of the description) and ends with the physical package (encoding of the types on the medium according to the target machine).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxvi

This logic is implemented in a set of Java classes that form the Syntax component. This component has three main classes:

the SyntaxManager class which provides the checking and the generation services to the others classes.

the EastGenerator which generates the EAST files

the EastChecker which checks the syntactic structure of the data

The EAST generator traverses the object tree structure mounted in memory and generates the format file according to the formatting information included in the visited nodes. When a given node is visited, the formatting information stored in memory (if any) is first read, before being written to the format file.

Figure 5-125 Format file generator


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxvii


EastChecker

check()

(from eastChecker)

DataModelroot


SyntaxManager

checkSyntax()generateEastFile()

1

1

1

1

uses

1..n1 1..n1

creates

FormatFileGenerator

generateFrtFile()

(from eastGenerator)

EastGenerator

generateEastFile()

(from eastGenerator)

1 11 1

checks

1

1

1

1

uses

uses

Figure 5-126 : Syntax Component class diagram.

5.4.6.7 Semantic component

5.4.6.7.1 TypeThe Semantic component is implemented in the modeller.semantic.* package

dedslGenerator(from semantic)

dedslChecker(from semantic)

semantic modeller(from debat)

Figure 5-127: Syntax component package view.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxviii


modeller.semantic.* This class provides the following services to the others components: semantics checking and DEDSL files generation.

SemanticManager

modeller.semantic.dedslChecker.* This class checks the semantics structure of the data.

DedslChecker

modeller.semantic.dedslGenerator.* This class generates the DEDSL file

DedslGenerator


SR195_ MODELLER Conformity: C

5.4.6.7.3 FunctionThe Semantic component has two functionalities processed by two sub-components: the DEDSL checker and the DEDSL generator.

The DEDSL checker component is in charge of verifying that all the information required to generate the DEDSL description file has been correctly filled-in by the user.The verification consists in checking that all the mandatory information has been entered (e.g. mandatory semantic attributes).

The DEDSL generator component is in charge of generating the DEDSL description (in PVL or in XML format) conforming to the CCSDS DEDSL recommendation. The generation process takes place after the DEDSL checking is completed.

5.4.6.7.4 DependenciesThe Semantics component depends on the Data Manager component because it needs to use the data model to generate the DEDSL files.



creates XML-IF structure

Figure 5-128: Semantic component dependencies view

5.4.6.7.5 InterfacesThe Semantics component generates DEDSL files


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxix


Dedsl Description<<DEDSL File>>

Figure 5-129 : Semantic Component Interface view.

5.4.6.7.6 ProcessingThe verification is directly performed on the object structure loaded in memory by the IF manager component. The DEDSL checker traverses the object tree starting from the root and applying the checks to each node: if a node violates a checking rule, it is added to the list of elements in error.

Figure 5-130 DEDSL checker architecture

The DEDSL generator traverses the object tree structure mounted in memory and generates the DEDSL file according to rules that allows transforming the internal model into DEDSL-PVL or XML syntax.

The Semantic component has three main classes: the SemanticsManager class that provides the checking and the generation services to

the others classes.

the DEDSLGenerator that generates the EAST files

the DEDSLChecker that checks the syntactic structure of the data


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxx


DedslChecker

check()

(from dedslChecker)DedslGenerator

generateDedslfile()

(from dedslGenerator)

1 11 1

uses

DataModelroot


SemanticsManager

checksSemantics()generateDEDSL()

1

1

1

1

checking

1

1

1

1

generation

1..n1 1..n1

traverses

Figure 5-131 : Semantics Component class diagram.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxxi

5.5 DEBAT Data Producer & Editor

5.5.1 Type

The Data Producer & Editor component is composed of six components as shown in the following decomposition view:


GUI<<Component>>

Search Capabilities<<Component>>

Data Storage<<Component>>



Data Checking<<Component>>

Figure 5-132 DPE Components Decomposition View

The Data Producer & Editor component is implemented in the dpe.* package.

gui dataGenerator search dataChecking dataManager dataStorage

dpe(from debat)

Figure 5-133 DPE Components Package View



GUI It gathers all the graphical user interfaces that provide means to generate, read and edit data products. In particular, it displays the data values of a product and allows to set-up the generation directives.

dpe.gui.*

Data generator It manages the reading / writing / checking of dpe.dataGenerator.*


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxxii


the directives file that contains the generation directives set-up by users in the graphical interface. It also runs the data block generation that is processed by the EAST core.

Search capabilities This component is the same as the Data Extractor & Querying one. It allows to search data using their syntactic and semantic attributes or to search data having a specific value.

dpe.search.*

Data checking It verifies that a data product is compliant with its associated EAST model. This component relies on the Data Checker utilities.

dpe.dataChecking.*

Data manager This component manages both the XML-IF and the data products. In particular, it allows to read data from a file or a stream and to edit data. It relies on the EAST core services for managing the data product.

dpe.dataManager.*

Data storage This component provides capabilities to store the data blocks that have been generated or edited. Data can be stored in a file or written in a stream.

dpe.dataStorage.*

The following table lists the classes of the dpe.* package.


dpe.* Class that enables to connect with the plug-in system and manages all main services allowed by the DPE

DpeManager

dpe.* Class that gathers all the services of the DPE accessible to other components (DEBAT or external components).

DpeServicesInterface

5.5.2 PurposeSatisfy: SR220_DPE Conformity: C

SR231_DPE Conformity: CSR249_DPE Conformity: CSR259_DPE Conformity: C

5.5.3 Function

The Data Producer & Editor (DPE) is a graphical tool that provides means to generate, read, check and edit data products that conform to an EAST description.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxxiii

The DPE provides several categories of functions: Data product handling

Data product consultation provides a graphical representation of data products and allows the navigation through this representation.

Data product generation provides advanced capabilities for the generation of data products.

Data product edition enables users to graphically edit the content of a data product.

Data checking allows to check if a data product is compliant with its associated EAST model and to display information about the checking results.

Data storage allows storing the data produced or modified by the DPE.

Search capabilities

This function provides advanced capabilities for searching elements in a data product.

Data model handling

This function is intended to read and display the XML-IF data model produced by the DEBAT Data Modeller. It provides a graphical view of the tree structure of the data model.

The figure here below summarizes the functions of the DPE tool. Provided that an XML-IF file is supplied, it manages existing data products and generates new data products using directives files as inputs.

Figure 5-134 DPE Component Functional Logic


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxxiv

5.5.4 Dependencies

5.5.4.1 External dependenciesThe DPE component is mainly a front-end MMI to the EAST core and Data Checker services: it is in charge of handling the user actions and forwarding the calls to the proper service. It receives the service results and displays them.It uses the Modeller component to load the XML-IF (data model) and to process the syntax & semantic search while the Data Extractor & Querying component is called for the values search processing.Finally, the Integrated Environment component provides means to access the project/files. The DPE is implemented as a plug-in and thus implements the PluginInterface interface of the Integrated Environment.

Figure 5-135 DPE Dependency General View

5.5.4.2 Internal dependenciesThe GUI component is in charge of handling the users’ actions and forwarding the calls to the proper DPE sub-components (“Search Capabilities”, “Data Manager”, “Data Storage”, “Data Generator” and “Data Checking”). Except the Data Checking component that relies on the Data Checker utility, all other components call an EAST core service to achieve their task. The results of the EAST core service (or Data Checker) are processed by the DPE components and eventually displayed in the GUI.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxxv

Figure 5-136 DPE Components Dependency Detailed View

5.5.5 Interfaces

The purpose of the DPE is to manage data that are described by an XML-IF file. Thus it first reads the XML-IF description file using the load service of the Modeller component. Then it is capable to read data from a data flow or stored in a file, and to modify, check, and search data.

The DPE is also able to generate data using generation directives as input. The DPE is responsible of the edition (reading and writing) of the file containing these directives (the format of this file is described in section 5.5.6.4.5). Once edited, the file is transmitted to the EAST core component, which processes the directives in order to generate a new block.

The DPE can save data in a data product file or on a data flow – standard output or socket.

Note: the DPE does not directly manage the data products. It simply calls the EAST core that is responsible for effectively processing the edition, reading, saving, generation.

Finally, the DPE reads the text file containing the check results. This file is sent by the Data Checker utility when calling its check service.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxxvi

Data Producer & Editor(from Component Decomposition)

<<Component>>

XML-IF<<XML File>>

Directives <<Directives File>>

Data<<Data File>>

Streamed Data<<Data Flow>>

check results<<Text File>>

Figure 5-137 DPE Component Interfaces View

5.5.6 Processing

The Data Producer & Editor support is itself implemented as a Java plug-in, so the DpeManager class (the main class of the DPE) implements the PluginInterface class. It uses the Project Management component to open descriptions and files managed by this component.

The DpeManager class uses several services of the General Features component: the printing function provided by the Printer class,

the online help display provided by the HelpManager class,

the screenshot function provided by the ScreenShot class,

the use of properties files provided by the Resource class. The use of properties files allows to configure GUI (internationalisation, size) and to store all GUI messages.

The DpeServicesInterface class provides the following services to other components: openDataProduct, selectDataBlock, getNumberOfBlocks: these functions enable to open

a data product and to select the block to be managed,

generateDataBlock: this function enables to generate a new block of data in a new data product file – it takes as input parameter the name of a directives file and the name of the data product file,

insertDataBlock, deleteDataBlock: these functions allow the insertion or deletion of a block in the opened data product,

save, saveAs: this function enables to save the opened data product,

saveBlockAs: this function enables to save the current block of the opened data product in a new file whose name is provided as input parameter of the function.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxxvii

DpeServicesInterface

openDataProduct()selectDataBlock()getNumberOfBlocks()insertDataBlock()deleteDataBlock()generateDataBlock()saveBlockAs()save()saveAs()

DpeMainFrame(from frames)



PluginInterface


<<Interface>>





Printer

run()printFile()printTable()printText()printComponent()printImage()

Resource

Resource()Resource()Resource()Resource()Resource()Resource()getString()getImageResource()getSoundResource()getFileResource()toString()setNullStringValueAllowed()setNullImageResourceAllowed()setNullSoundResourceAllowed()setNullFileResourceAllowed()

HelpManager

load()loadHelpSets()displayHelp()

DpeManager

run()generateDataBlock()saveDataBlock()

forwards call

sends MMI events

1

0..1

1

0..1

usesimplements

1

1

1

1

prints

11 11 set properties files

1

1

1

1 shows online help

Screenshot

doScreenShot()saveScreenShot()

1

1

mak es screenshots

1

1

Figure 5-138 DPE Component Class Diagram

The DPE component comprises: the GUI sub-component: it allows users to generate, access, edit, check and store data

contained in a data product,

the Data Generator sub-component: it provides the ability to create a file of generation directives that describe how the data products have to be generated by EAST. These directives are automatically read, interpreted and executed by the EAST core. Thanks to this file, users are able to generate data products without any code development by calling (through the DPE or directly by a command line invocation) the proper service of the EAST core.

the Data Manager, Data Storage and Data Checking sub-components: they are responsible for the management, storage and checking of the data.

The search capabilities sub-component: it allows to search data in a product.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxxviii


5.5.6.1.1 TypeThe GUI component is implemented in the dpe.gui.* package

dpe(from debat)

gui

frames(from gui)

panels(from gui)

Figure 5-139 GUI Component Package View


dpe.gui.frames.* Frames of the GUI DpeMainFrameSyntacticSemanticSearchFrameQueryWizardFrameDataStorageFrameCheckingResultsFrame

dpe.gui.panels.* Panels of the GUI ValuesDisplayPanelInformationPanelDescriptionPanelSyntacticPanelSemanticPanelGenerationPanelFileStoragePanelStreamStoragePanel


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : clxxxix

5.5.6.1.2 PurposeSatisfy: SR205_DPE Conformity: C

SR206_DPE Conformity: CSR207_DPE Conformity: CSR208_DPE Conformity: CSR210_DPE Conformity: CSR211_DPE Conformity: CSR212_DPE Conformity: CSR213_DPE Conformity: CSR216_DPE Conformity: CSR217_DPE Conformity: CSR218_DPE Conformity: CSR219_DPE Conformity: CSR220_DPE Conformity: CSR221_DPE Conformity: CSR222_DPE Conformity: CSR223_DPE Conformity: CSR233_DPE Conformity: CSR236_DPE Conformity: CSR237_DPE Conformity: CSR239_DPE Conformity: CSR241_DPE Conformity: CSR248_DPE Conformity: CSR251_DPE Conformity: CSR252_DPE Conformity: CSR253_DPE Conformity: CSR254_DPE Conformity: C SR255_DPE Conformity: CSR256_DPE Conformity: CSR260_DPE Conformity: CSR263_DPE Conformity: CSR264_DPE Conformity: C SR272_DPE Conformity: CSR273_DPE Conformity: CSR274_DPE Conformity: CSR275_DPE Conformity: CSR276_DPE Conformity: CSR277_DPE Conformity: C

5.5.6.1.3 FunctionUsers can execute all of the DPE functions through a graphical interface that makes the interaction between the software and users easier. All the graphical interface of the DPE is implemented in Java (SWING library). The DPE MMI is divided into five main parts described hereafter.

5.5.6.1.3.1 GUI Infrastructure

The GUI infrastructure is made up with a high-level frame containing a menu bar and a toolbar providing access to the functions of the DPE. It is split into several areas dedicated so the display/edition of each set of functions: model tree-view navigation and display, values display and edition, syntactic & semantic information display, generation information edition and display.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxc

Figure 5-140 DPE GUI infrastructure

5.5.6.1.3.2 Tree navigation GUI

This is a panel displaying the tree-structure view of both complete and non-complete data models. It is very similar to the Data Modeller tree navigation (it is implemented with the JGraph library).The tree navigation GUI provides the following capabilities:

Mouse handling capabilities : popup menus display and invocations, left/right mouse clicks, select node or group of nodes.

GUI functions : zoom, scroll up/down/right/left, expand/collapse tree, clone model view.

Information representation : the discriminated elements in the tree view are grayed when not present in the current data block, elements not compliant with the data models and elements matching a search criteria can be highlighted.

5.5.6.1.3.3 Data products GUI

This user interface provides a graphical display of a data product. Some navigation capabilities are available and interactions with the tree navigation are also provided so that users can easily switch between the data model and the data values. For instance, when selecting a node in the tree structure view, users can choose between displaying in the “data products GUI” either the child nodes or all the leaves present in the structure of the selected elements. Finally, the data products interface provides means to graphically edit and modify data. The copy / paste and undo / redo functions are available in order to make the data edition easier.

5.5.6.1.3.4 Syntactic and semantic GUI

The syntactic GUI and semantic GUI are exactly the same as the Modeller GUI except that no edition capabilities are provided.

5.5.6.1.3.5 Generation GUI

This user interface displays and enables the edition of any information about how the value of an element in the model has to be generated. Several options are available to users:

the default value can be used for the generation,


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxci

users can set a value or define the value as the result of a computation that can be a simple calculation expression or a Java function – in this case, a graphical Java editor is provided in order to make the function definition easier,

the generation engine can randomly set the value. The generation process takes into account the intervals of possible values or string patterns (depending on the elements’ types) specified by users in the generation interface.


GUI<<Component>>

request data search

display search results

Search Capabilities<<Component>> read / edit data product

display data blockcall save function

set generation directives

call generation function

display generation directives

display checking resultscall checking function





Figure 5-141 GUI software dependency view

The GUI sub-component is responsible for handling the users’ requests and forwarding them to the proper sub-components. These sub-components process the request, eventually call the EAST core or the Data Checker to achieve their task and return the results to the GUI. The GUI is responsible for displaying the results in a convenient way.

5.5.6.1.5 InterfacesThe GUI component has no specified interface with the others components.

5.5.6.1.6 ProcessingThe GUI component contains a lot of classes that implement frame and panels (Panels are low graphical components). The following class diagram describes:

DpeMainFrame: the main frame containing the others panels,

DescriptionPanel: it contains the tree representing the data model,

ValuesDisplayPanel: it is a panel that displays the data values. It provides advanced capabilities to navigate in the data (a double click on a structured element displays the values of the children),


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxcii

InformationPanel: this panel is split in the SemanticPanel, SyntacticPanel (both are the same as the Modeller GUI panels) and the GenerationPanel that contains the generation information of the element selected in the tree view,

SyntacticSemanticSearchFrame and QueryWizardFrame: these frames are the same as the DEQ ones,

DataStorageFrame: this frame enables users to select the medium on which the data shall be written and to process the storage,

CheckingResultsFrame: it displays the results of the data product checking.

SyntacticPanel

SemanticPanel

GenerationPanel

InformationPanel

1

1

1

1

contains

1

1

1

1

contains1

1

1

1

contains

DescriptionPanelValuesDisplayPanel

SyntacticSemanticSearchFrame

QueryW izardFrame

CheckingResultsFrame

DpeMainFrame

1

1

1

1

displays

1

1

1

1

displays

1

1

1

1

displays

1

1

1

1

displays

1

1

1

1

displays

1

1

1

1

displays

StreamStoragePanel

FileStoragePanel

DataStorageFrame

1

1

1

1 displays

1

1

1

1

contains

1

1

1

1

contains


Checker

check()run()

CheckResultsManager

read()getCheckResults()getCheckResultsOfPath()

getCheckResults

getCheckResultsOfPath


DataManager

readFile()readSocket()readStandardInput()expandPathToAllChildren()expandPathToAllLeaves()readElementValue()readChildrenValues()readLeavesValues()readDiscriminantsValues()getDataBlocks()getDataBlockAtIndex()setData()deleteBlock()insertBlock()

read / edit

DataModelManagercurrentDataModel

loadDataModel()getDataModel()loadDataModelFromFile()

loadDataModel - getDataModel


FileWriter

saveAs()save()saveBlockAs()

StreamW riter

writeData()

save - saveAs - saveBlockAs

writeData

Search Capabilities<<Component>>

SyntacticSemanticSearchexpression

executeExpression()createExpression()

ValuesSearchquery

executeQuery()createQuery()

search

search


DirectivesManager

read()write()addDirective()removeDirective()addExternalFunction()removeExternalFunction()getDirectives()getDirectiveByPath()getExternalFunction()

GenerationEngine

run()generateNewBlock()

runset / get directives

run

Figure 5-142 GUI component class diagram

All the graphical user interfaces of the Data Producer & Editor are implemented in Java (Swing) because of its high-level graphical capabilities and look & feel. In order not to block the graphical interface while executing actions (such as data block generation, data reading), the DPE is multi-


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxciii

threaded: the GUI and the actions are executed in separate threads. The GUI also provides users with the capability to stop any actions that have been launched.

5.5.6.1.7 Sketches of the GUIThe graphical interface of the DEBAT Data Producer & Editor is presented in the figure hereafter.

Figure 5-143 DPE frame

5.5.6.1.8 Menu treesMenu Menu Items Description

File Open description Opens an XML-IF description file

Close description Closes the current description along with the associated data product

New data product Creates a new data product by generating its first block

Open data product Opens a data product (only active if a description has been previously loaded)

Close data file Closes the current data productSave Saves the current data productSave as Saves the current data product in a new fileSave block as Saves the current block of the data product in a new file


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxciv

Menu Menu Items Description

Print Prints the data tree and all of the semantic, syntactic and generation information

Capture Makes a screenshot of the tree and saves it as an image or prints it

Quit Closes the Data Producer & Editor

Edit

Undo Cancels the last data editionRedo Redoes the last cancelCopy Copies the content of a text fieldCut Cuts the content of a text fieldPaste Pastes the content of a text fieldInsert block Generates a new block after the current blockDelete block Deletes the current block

FindSyntactic/Semantic search Opens the syntactic/semantic search frame.

Values search Opens the values search frame.

Tools Check Checks if the current data product is compliant with its associated description

HelpContents Displays the help GUI.

About Displays information about the DPE (version, authors, dates of the last version).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxcv


5.5.6.2.1 TypeThe Data Manager component is implemented in the dpe.dataManager.* package

dpe(from debat)

dataManager

xmlIFManager(from dataManager)

dataProductsManager(from dataManager)

Figure 5-144 Data Manager Component Package View


dpe.dataManager.xmlIFManager.* This package is responsible for the management of the XML-IF files.

DataModelManager

dpe.dataManager.dataProductsManager.* This package is responsible for the management (reading / writing) of the data products content.

DataManagerSocketReaderDataReaderDataBlockSetCommand


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxcvi


SR210_DPE Conformity: CSR218_DPE Conformity: CSR219_DPE Conformity: CSR220_DPE Conformity: CSR250_DPE Conformity: CSR225_DPE Conformity: CSR226_DPE Conformity: CSR227_DPE Conformity: CSR228_DPE Conformity: CSR229_DPE Conformity: CSR230_DPE Conformity: CSR257_DPE Conformity: CSR258_DPE Conformity: CSR206_DPE Conformity: C

5.5.6.2.3 FunctionThis component comprises two main functions:

The management of XML-IF: it is responsible for the reading of the XML-IF files and is based on the services of the Data Modeller.

The management of the data products: it is responsible for the reading and editing of data products. The edition encompasses the data values modification, the block deletion and the block insertion in a data product.

5.5.6.2.4 DependenciesThe Data Manager component relies on:

The services provided by the Modeller to read the XML-IF files: the Modeller parses the XML-IF files and builds the associated objects representation.

The services provided by the EAST core to read and edit data products: the EAST core is then responsible for returning the requested values of a data product and for modifying the values that have been edited in the GUI – the modifications are processed on the memory representation of the data block and not directly on the file.

The Data Manager component also manages the read / edit requests sent by the GUI and is responsible for providing the data values to the GUI in order to be displayed.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxcvii

GUI<<Component>>

display data block

read / edit data product



XML-IF loading set / get data values


Java API(from Component EAST core)

<<Component>>ModellerServicesInterface(from modeller)

Figure 5-145 Data Manager software dependency view

5.5.6.2.5 InterfacesThe Data Manager component reads the XML-IF that contains the data model. It also reads data (from both a data file or data flow – standard input or socket) and is able to modify data values of a product (the modifications are processed on the memory representation of the data product that is handled by the EAST core).

Data<<Data File>>

XML-IF<<XML File>>


read


read

read

modify

Figure 5-146 Data Manager Interface View


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxcviii

5.5.6.2.6 ProcessingThe DataManager is responsible for the loading of:

Data models: this is achieved by calling the ModellerServicesInterface of the Modeller component,

Data products: this is achieved by calling the DataGenerator component of the EAST core Java API.

DataReader

pathsToReadpercentAchievedblockNumber

run()getLengthOfTask()getPercentAchieved()isFinished()finish()

(from dataProductsManager)

DataBlock

blockNumberdataValues

getValues()setValues()getValueOfPath()setValueOfPath()clearValues()isPathRead()


SocketReader

portNumbertimeOutdataSocket

startSocketServer()stopSocketServer()run()


DataManager

readFile()readSocket()readStandardInput()expandPathToAllChildren()expandPathToAllLeaves()readElementValue()readChildrenValues()readLeavesValues()readDiscriminantsValues()getDataBlocks()getDataBlockAtIndex()setData()deleteBlock()insertBlock()


1

0..1

1

0..1

uses

0..n

1

-dataBlocksList

0..n

1

handles

0..11 0..11

uses

SetCommand

blockNumberpathnewValueoldValue

undo()redo()canUndo()canRedo()getPresentationName()




DataGenerator

setValueOfPath

readDataEntityBinary - readDataEntityAscii

selectDataProductFromSocket

selectDataProduct - selectDataProductFromStandardInput

setDataEntity - deleteBlockselectBlock

DataModelManager

currentDataModel

loadDataModel()getDataModel()loadDataModelFromFile()

(from xmlIFManager)




selectDDR - releaseDDR

loadXmlIf - generateEastFile

Figure 5-147 Data Manager Class Diagram


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cxcix

5.5.6.2.6.1 Data model reading

The DataModelManager processes the data model reading in several steps: First, it calls the loadXmlIf function of the ModellerServicesInterface in order to retrieve

the objects representation of a data model stored in the XML-IF file. The root class of the object representation is a DataModel that is stored as a private attribute in the DataModelManager,

Then, it calls the generateEastFile function of the ModellerServicesInterface in order to create the EAST file of the data model,

Finally, the generated EAST file is sent to the DataGenerator component of the EAST core Java API. This is done by calling the selectDDR function of the DataGenerator.

: DataModelManager : ModellerServicesInterface : DataGenerator

loadXmlIf

dataModel

generateEastFile

: (Use Case View::User)

: DpeMainFrame

open XML-IFforward call

selectDDRgetDataModel

display data model

Figure 5-148 “Read data model” sequence diagram

5.5.6.2.6.2 Data reading

The DataManager is able to read data from three different inputs: a file: the readFile method calls the selectDataProduct and selectBlock services of the

DataGenerator component of the EAST core Java API by providing the file name as input parameter,

the standard input: the readStandardInput method calls the selectDataProductFromStandardInput service of the DataGenerator component in order to get a whole block of data from the standard input,

a socket: the reading process consists in creating a SocketReader object (the creation is achieved by the readSocket function of the DataManager) that is responsible for starting a socket server, accepting a connection with the client that sends data and calling the selectDataProductFromSocket service of the EAST core DataGenerator component.

Once the input has been chosen, data can be read on the medium; this is achieved by calling the reading service (readDataEntityAscii or readDataEntityBinary) of the DataGenerator component of the EAST core Java API.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cc

The data are read on user request. It means that users do not load all values when opening a data product but only load the values they want to be displayed. Users are able to read data values element per element or to read a set of elements at the same time.

To achieve this goal, depending on the user’s request, the GUI calls one of the three reading functions of the DataManager: readElementValue, readChildrenValues, readLeavesValues. These functions enable to read the values of a single element (if the element is of a scalar type) or all its children or leaves (if the element is of a structured type). These functions simply create a DataReader object, which is a thread responsible for getting all the requested values from the EAST core. The values are then stored in a DataBlock object, which gathers the values of a particular block. The DataManager handles the list of DataBlock objects.

Note 1: the list of children or leaves of an element is built by the expandPathToAllChildren or expandPathToAllLeaves.

Note 2: the reading is processed in a separate thread in order to be able to interrupt it if it lasts too long (because the user is requesting the reading of a very large amount of data). The DataReader also provides means to get information about the completion status of the reading process. This information is managed by the GUI in order to display a progress bar.

The sequence diagram here below shows how the various components interact when a data product is read from a socket.


: DpeMainFrame : DataManager : SocketReader : DataGenerator

read data product from a socketreadSocket

run

startSocketServer

wait for client connection


accept client connection

Figure 5-149 “Read from socket” sequence diagram

The following figure shows how the various components interact when a data product file is read and when the user requests some data values.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cci


: DpeMainFrame : DataManager : DataReader : DataGenerator : DataBlock

open data product filereadFile

selectDataProduct

return success / failuredisplay 1st block

readDiscriminantsValues of the 1st block run

readDataEntity

setValueOfPathreading finished

select block #nreadDiscriminantsValues of

block #nrun readDataEntity


return success / failuredisplay block #n

read an element or a set of elements

readElementsValues, readChildrenValues,

readLeavesValuesrun

readDataEntity


return success / failuredisplay elements' values

Figure 5-150 “Read from file” sequence diagram

5.5.6.2.6.3 Data edition

The DataManger component also enables users to edit the blocks of a data product. The edition is realized block per block – it means that users have to save their changes on a block before modifying another block, otherwise the changes are not processed on the data product file. In the graphical view of the DPE, users can modify the elements’ values in two different ways:

Users can specify an ASCII value (which is eventually converted if the element is stored in binary in the data product) – in this case, only the ASCII characters greater than ‘/016’ are allowed,

For string elements, users can specify a string value containing hexadecimal characters – this is only possible for elements encoded in binary in the data product.

The values specified by the users in the graphical view are transmitted by the DataManager to the EAST core DataGenerator component that is responsible for the modification of the data product. This is achieved by calling the service “setDataEntity” of the EAST core DataGenerator component. Once the new value has been set, the EAST core returns it to the DataManager that stores it in the proper DataBlock object.

Note 1: If the modified element is a discriminant, the structure of the data block may change: elements can be deleted and others created (for instance, if users increase the size of a table, new


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccii

elements will be created). The elements are automatically generated or deleted when the new discriminant value is set. The new elements are generated:

using their default value if it exists,

randomly otherwise (the new value is randomly taken from the full range of possible values).

Note 2: The data product is effectively modified when the users call the save function of the DPE Data Storage component. Indeed, all the edition requests are processed on data loaded in memory by the EAST core and not directly on the data product file. The save method is then responsible for the writing of the modified data in the data product file.

5.5.6.2.6.4 Block deletion/insertion

Users can also delete a whole block or insert a new block in a data product. The deletion is simply realized by calling the service “deleteBlock” of EAST core DataGenerator component while the insertion of a block requires to generate a new block (this is done by the “DataGenerator” component – see section 5.5.6.4) and to write it in the data product after the current displayed block.

5.5.6.2.6.5 Undo/Redo

Finally, the DataManager is responsible for the storage of the set commands in order to allow the undo/redo of data edition. Every set command is stored in a SetCommand object that provides the undo and redo functions.

The undo/redo service is implemented using the package “javax.swing.undo” of the standard Java API. This Java package provides all convenient classes and interfaces for managing the undo/redo actions.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cciii

5.5.6.3 Data Storage component

5.5.6.3.1 TypeThe Data Storage component is implemented in the dpe.dataStorage.* package

dpe(from debat)

dataStorage

file(from dataStorage)

stream(from dataStorage)

Figure 5-151 Data Storage Component Package View


dpe.dataStorage.stream.* Gathers all classes that implement the writing of data block in a stream.

StreamWriterStdoutWriterSocketWriter

dpe.dataStorage.file.* Gathers all classes that implement the storage of data in a file.

FileWriter


SR259_DPE Conformity: CSR260_DPE Conformity: CSR261_DPE Conformity: CSR262_DPE Conformity: CSR263_DPE Conformity: C

5.5.6.3.3 FunctionThe Data Storage sub-component is intended to provide capabilities to store the data blocks that have been generated or edited. It provides two different storage capabilities:

Storage in a file of the local repository: this capability is provided by the “FileWriter”,

Data writing on an output stream: the “StreamWriter” provides this capability.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cciv

5.5.6.3.4 DependenciesThe GUI calls the Data Storage component when users want to save a data block. When it receives the request from the GUI, it simply calls the storage service of the EAST core (through the Java API of the EAST core).

EAST core(from Component EAST core)

<<Component>>

call storage service


call save function

GUI<<Component>>

Figure 5-152 Data Storage software dependency view

The Data Storage uses the following functions of the EAST core Java API: writeStandardOutput, flushStandardOutput, closeStandardOutput

write

5.5.6.3.5 InterfacesThe Data Storage component writes the data in a data file or in a stream (standard output or socket). In fact, it does not directly store the data on the medium since it is the EAST core that effectively processes the writing.


Data<<Data File>>


write data

store data

Figure 5-153 Data Storage Interface View


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccv


FileWriter

saveAs()save()saveBlockAs()

(from file)

StreamWriter

writeData()

(from stream)

StdoutWriter

writeData()

(from stream)SocketWriter

dataSocketportNumberipAddress

writeData()connectToSocketServer()disconnectFromSocketServer()

(from stream)



DataGeneratorwriteStandardOutput

write

write

Figure 5-154 Data Storage Class Diagram

The service provided by the “FileWriter” class is split into three functions called: Save block as: this function is applied to the block that the user is currently handling

(i.e. editing, reading or generating). As a result of the call of this function, the block is saved in a new data product file whose name is specified by the user. If the file already exists, the block erases its content.

Save: this function is applied to the data product that the user has opened and modified (one of its block has been edited or deleted, or a new block has been inserted). In this case, the function updates the data product content with the user’s modifications.

Save as: this function is also applied to the data product that has been opened but instead of updating the data product file, a new file is created with the data product updated content. The initial data product file keeps then unchanged.

When users call one of these functions, the “FileWriter” writes the data product file (whose name and location in the local repository are specified by users in the graphical interface) using the “write” service of the DataGenerator component of the EAST core Java API.

Instead of writing data in a new file, the “StreamWriter” writes the generated or edited data in an output stream. Depending on the users choice (which is made in the GUI), the output stream is flushed in the standard output or in a socket whose IP address and port are provided by the users. The StreamWriter is an abstract class that is realized by:

StdoutWriter class: it provides a single function (named writeData) that is intended to write the data in the standard output.

SocketWriter class: it provides functions to connect/disconnect with the socket server that receives the data, and a function (named writeData) that sends the data to the server through the socket connection.

Both writeData functions write the current data block (i.e. the block that the user is currently handling – editing or generating) in the stream. To achieve their task, they simply call the DataGenerator component of the EAST core (methods named writeStandardOutput and write).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccvi

5.5.6.4 Data Generator component

5.5.6.4.1 TypeThe Data Generator component is implemented in the dpe.dataGenerator.* package

dpe(from debat)

dataGenerator

directives(from dataGenerator)

engine(from dataGenerator)

Figure 5-155 Data Generator Component Package View


dpe.dataGenerator.engine.* Gathers all classes that implement the generation engine.

GenerationEngine

dpe.dataGenerator.directives.* Gathers all classes that manage the directives file containing the generation directives.

DirectiveRandomDirectiveStringRandomDirectiveGeneralRandomDirectiveDefaultDirectiveUserDirectiveListDirectiveExternalFunctionDirectivesManager


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccvii


SR232_DPE Conformity: CSR234_DPE Conformity: CSR235_DPE Conformity: CSR240_DPE Conformity: CSR238_DPE Conformity: CSR239_DPE Conformity: CSR244_DPE Conformity: CSR235_DPE Conformity: CSR239_DPE Conformity: CSR240_DPE Conformity: CSR245_DPE Conformity: CSR246_DPE Conformity: CSR234_DPE Conformity: CSR247_DPE Conformity: C

5.5.6.4.3 FunctionThis component provides advanced capabilities for the generation of data products.

Two modes of generation are available: a fully automatic generation or a user-controlled process. In the fully automatic mode, the software generates random values or takes into account the elements’ default values when set in the model. The other mode lets the users define all or a subset of the elements’ values. Users can also apply a simple calculation expression or an external function to compute the value of an element.

Moreover, in both cases, users may choose to generate valid data products where all values are corresponding to the syntactic information defined in the EAST description file or to generate wrong data products where some or all values may be incorrect (except the discriminants which must have a value compliant with the data model).

This function is processed in two steps: first a directives file that describes how the data product shall be generated, is created; then the generation service of the EAST core API is called with the directives file as input parameter.

5.5.6.4.4 DependenciesIn order to generate a new data block, the Data Generator creates a file that contains directives set-up by users in the GUI. Once the file has been created, users can call (in the GUI) the generation function. This request is forwarded to the Data Generator that simply calls the generation service of the EAST core and provides the directives file as input parameter of the service.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccviii

GUI<<Component>>

display generation directives

call generation function

set generation directives


call generation service

EAST core(from Component EAST core)

<<Component>>

Figure 5-156 Data Generator Software Dependency View

The following function of the EAST core Java API are used by the Data Generator: generateNewBlock

The figure below describes the interactions between the user and the DPE components involved in the data generation.


: GenerationPanel : DirectivesManager : GenerationEngine : EAST core

Configure elements' generation

call addDirective (set the directives

information)

call getDirectives (return the directives information)

display elements' generation

configuration

call generate function call run (forward user's request)

call write (save directives in file)call "generateNewBlock"

generate block in memory

return ok/koforward ok/kodisplay ok/ko

Figure 5-157 “Generate new block” sequence diagram

(1) In order to generate a data product, users define the generation directives of the elements. These directives are set-up in the DPE GUI (GenerationPanel) and written in a file by the DataGenerator component (DirectivesManager class). If users want to modify an existing directives file, this component is able to load the directives and to display them in the GUI.

(2) Once the directives have been defined, users can launch the generation process, which is managed by the DataGenerator component (GenerationEngine class). This component requests


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccix

the DirectivesManager to create the directives file and then calls the generation service of the EAST core Java API (it provides the directives file as input of this service). The EAST core generates the data. At the end of this step, the data are not written in a file but stored in memory.

(3) The generation success/failure message is sent to the GenerationEngine, which forwards it in order to be displayed in the GenerationPanel.

5.5.6.4.5 InterfacesThe “directives file” is the interface between the DPE and the EAST core in order to generate a new data block. Indeed, this file contains all information that the EAST core needs to generate the data. It is created and edited by the Data Generator which sends it to the EAST core when the user calls the generation function.


Directives <<Directives File>>

read

write

Figure 5-158 Data Generator Interface view

The format of the “directives file” is described hereafter.

The header contains both the date of creation (or last edition) of the file and the name of the associated EAST description file. The second part is intended to provide all the Java functions definition. This section is entirely written in Java.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccx

The rest of the file contains a set of elements and lists for which generation information have been set-up by users. In fact, generation directives can be defined for each element that is a leaf in the model. The elements / lists are identified by their full path. The generation information of the lists are only their size while all other elements define the following generation properties:

The generation mode is identified by an integer value (1 for “user-specified value”, 2 for “random value” and 3 for “default value”).

Depending on the generation mode, other pieces of information are stored:

Generation mode = 1: a parameter indicates whether the generated value shall be degraded or not, a second parameter indicates if the value is computed and finally the last parameter specifies the value to be set. The value is specified in ASCII and eventually contains characters in hexadecimal (in case of a string or a character) or a calculation formula (a Java expression or a Java function). The Java expression defines a mathematical calculation (+, -, *, /, etc) that can be used to specify an integer or real value while the Java function provides advanced capabilities (such as control structures e.g. loop, if/then/else) to calculate the element’s value since all the features of the Java language are available. In particular, the following items can then be used in both the Java expressions and functions:

Operators: +, -, *, /,


DATE = <dd/mm/yyyy>EAST = <name of the EAST description file>

JAVA = {

<Java code>

}

LIST = <path of the list in the EAST description>size = <number of indexes>

ELEMENT = <path of the element in the EAST description>generation mode = <1 | 2 | 3>

# if generation mode = 1degraded = <true | false>computed = <true | false>value = <value_definition> # a value or a formula depending on the computed value

# if generation mode = 2# if element type is stringpattern = <string_pattern>

# otherwisedegraded = <true | false>interval = <interval_definition>

…

Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxi

Public methods and attributes of the java.lang.Math class of the Java standard API: pi, sin, cos, tan, asin, acos, atan, pow, exp, log, etc

References to elements’ values preceding the calculated element in the data model,

A variable representing the data block number

References to the indexes of tables and lists (for instance the successive values of an element in a table can be defined as: “index * 2”).

Generation mode = 2: depending on the element’s type, different information are provided: Basic type Generation properties

Integer For these basic types, the users must specify the following properties: If the random value shall be compliant or not with the data model,

The intervals in which the integer, real or character1 data value shall be randomly taken

Real

Character

String Users must specify a pattern for the generation of a string.

Enumeration

The properties defining how to generate a random value of an enumeration are the ones of the physical representation of the enumerated values. For instance, if the physical representation is an integer, users can define the generation interval and specify whether the value shall be compliant or not with the data model If the physical representation is a string, then users can define a string pattern.

Generation mode = 3: no other information are provided.

Note 1: the order of the generation configuration information must be the same as the order of the elements and lists in the model.

Note 2: the intervals can be defined as the union of several separate intervals. Two specific values are also available: “full_range” or “out_of_full_range”. In the first case, it means that the value shall be randomly taken from the interval specified in the data model – the element is necessarily compliant with the data model. The second case is the opposite.

Note 3: data that are specified as degraded, have a value out of the full range defined in the EAST model. However, these data have a size compliant with the model.

Note 4: if the element is contained in a table or a list, the path of the element is of two kinds: The path does not indicate the table index (for instance: ROOT.TABLE().ELEM): in this

case, the generation configuration of the element is used for all indexes of the table/list.

The path indicates the table index (for instance: ROOT.TABLE(1). ELEM): in this case, the generation configuration of the element is applied to this single index. As a

1 The order relation used for the character is the integer order relation applied on the hexadecimal representation of the ANSI ASCII characters.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxii

consequence, all other indexes cannot share a common generation configuration (the ROOT.TABLE().ELEM is no more allowed for this table).

Note 5: the value definition of an element can contain: References to other elements: they are represented by their full-path in the definition,

The block number: it is represented by the keyword “BLOCK_NUMBER”

The table/list indexes: they are represented by the string “index” followed by the full-path of the table/list in parentheses (see example below).

Here is an example of a generation file for the following data model:

Figure 5-159 Data model of the example

The element “EXAMPLE.HEADER.A” is generated using its default value while the element “EXAMPLE.HEADER.B” is produced using the default generation configuration. The value of the element “EXAMPLE.HEADER.C” is calculated by the Java function called “myfunction” which takes an integer value as input parameter. This integer is the value of EXAMPLE.HEADER.A.

The user must specify the element “EXAMPLE.BODY.SIZE” as it discriminates the size of the table “EXAMPLE.BODY.TAB”. The elements of the table are generated in two ways:

Each element named ELEM1 has its own generation properties. The generation configuration of the elements at indexes 1 and 3 are user-specified while for all other indexes, the default generation properties are used. The element at index 3 is generated using a calculation formula based on both the block number and the value of the element EXAMPLE.HEADER.C,

The elements named ELEM2 share the same generation configuration. The EAST core randomly sets their values using a string pattern as input.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxiii

Finally, the size of the list “EXAMPLE.BODY.LIST” is defined and the elements of the list share the same generation configuration. Their value is twice the list index.

5.5.6.4.6 ProcessingThis component comprises two main classes:


DATE = 27/05/2003EAST = example.eas

JAVA = {public double myfunction (int a) {

if (a < 4)return 0.5* a+2;

elsereturn 2.5*a-6;

}}

ELEMENT = EXAMPLE.HEADER.Ageneration mode = 3

ELEMENT = EXAMPLE.HEADER.Cgeneration mode = 1degraded = falsecomputed = truevalue = myfunction (EXAMPLE.HEADER.A)

ELEMENT = EXAMPLE.BODY.SIZEgeneration mode = 1degraded = falsecomputed = falsevalue = 5

ELEMENT = EXAMPLE.BODY.TAB(1).ELEM1generation mode = 2degraded = falseinterval = full_range

ELEMENT = EXAMPLE.BODY.TAB(3).ELEM1generation mode = 1degraded = falsecomputed = truevalue = BLOCK_NUMBER * EXAMPLE.HEADER.C

ELEMENT = EXAMPLE.BODY.TAB().ELEM2generation mode = 2pattern = ab*

LIST = EXAMPLE.BODY.LISTsize = 3

ELEMENT = EXAMPLE.BODY.LIST()generation mode = 1degraded = falsecomputed = truevalue = index(EXAMPLE.BODY.LIST) * 2

Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxiv

The “DirectivesManager” which is able to read, write and check the directives file that contains all the directives set up by the users. Every directives read in the file are stored in one of the derived classes of the “Directive” class while the Java code is stored in the “ExternalFunction” class.

The “GenerationEngine” which is responsible for the generation of data products using the directives file as input.

DefaultDirective

generationMode = 3(from directives)

Directive

path

checkDirective()writeDirective()

(from directives)

DirectivesManager

read()write()addDirective()removeDirective()addExternalFunction()removeExternalFunction()getDirectives()getDirectiveByPath()getExternalFunction()

(from directives)

1

0..n

1

-directivesList

0..n

ExternalFunction

functionDefinition(from directives)

1

0..1

1 -function

0..1

GeneralRandomDirective

degradedintervalDefinition

(from directives)

ListDirective

generationMode = 0size

(from directives)

RandomDirective

generationMode = 2(from directives)

StringRandomDirective

pattern(from directives)

UserDirective

generationMode = 1degradedcomputedvalueDefinition

(from directives)

GenerationEngine

run()generateNewBlock()

(from engine)calls write function

Figure 5-160 Data Generator Class Diagram

5.5.6.4.6.1 DirectivesManager

The abstract class named “Directive” represents a generation directive of a particular element of the data model. In fact, a “Directive” object exists for each element (that is a leaf in the model) whose generation information has been set-up by users in the GUI. The association between the “Directive” object and the element in the model is realized by the “path” attribute that represents the full-path of the element.

The classes that derive from “Directive” implement a particular generation mode:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxv

ListDirective: it contains the information defining the size of an element of type “List”,

RandomDirective: it contains the information to randomly generate an element. As the information is different depending on the element’s type, two derived classes have been defined.

UserDirective: it contains the information about the value of the element that has been defined by the user. The attribute valueDefinition can contain a specific value, a Java expression or a call to an external function.

DefaultDirective: this object is created when the element shall be generated using its default value.

It is not necessary to have a “Directive” object for every leaves of the data model as the elements having no generation properties are generated using the following rules: (1) if the default value is defined in the data model, then it is used, (2) otherwise a random value compliant with the data model is generated (a random value in the full range).

However, as users must define the values of all the discriminants in the model (this kind of elements defines the structure of the block and the definition of the block structure is considered to be the user responsibility), a discriminant element can only be associated with a “UserDirective” or a “DefaultDirective” (if the default value is defined in the data model) object. Finally, note that the values of the discriminants cannot be degraded.

For the same reason, as the size of every lists have to be specified by the user, there must be as many “ListDirective” objects as lists in the model.

When writing or reading a generation configuration file, the “DirectivesManager” checks that the directives information is valid. The following checks are made:

A syntax check verifies that the directives file is well formed: checking of the keyword, verification of the Java code in mathematical expressions or in functions, the values of the generation mode, etc.

The content check verifies the following properties:

All discriminants have either been specified by the user or have a default value defined in the data model.

The size of the lists are defined,

When the generation mode is 1, the “degraded”, “computed” and “value” parameters are filled,

When the generation mode is 2, the proper information are provided according to the element’s type i.e. if the element is a string, the string pattern shall be defined, otherwise the “degraded” and “interval” information shall be provided.

The interval parameter cannot be equals to “full-range” (resp. “out_of_full_range”) when the parameter “degraded” is true (resp. false).

The referenced elements in a formula are preceding the calculated element,

In string patterns, there is no character in hexadecimal less than \016 when the element is generated in ASCII.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxvi

The ‘( )’ and ‘(i)’ notations are not mixed for the same table or list.

5.5.6.4.6.2 GenerationEngine

GenerationEngine is the class responsible for the generation of data products. It receives a valid directives file and calls the EAST core service that is responsible for the generation of a new data block using the directives file content as input.

The EAST core generation service is able to: Handle Java expressions and functions for calculating the user-specified values.

If the expression or the function contains paths to referenced elements, the EAST core replaces the paths by the elements’ values. Then, the Java code (expression or function) is processed using the “Dynamic Java” tool. Finally, the output value is set to the calculated element by the EAST core.

Handle intervals defining the range of possible values.

Depending on the element’s type, the generation engine shall be able to handle numerical intervals, handle character/enumeration intervals and singletons, handle union between intervals. Here are two examples: ‘a’ || [‘c’, ‘f’] ; [2, 10] || [13, 15]

Handle string patterns.

The string patterns that are available to users consist in a subset of the regular expressions patterns. The following ones are provided and handled by the component: characters (both in alphanumerical and hexadecimal representations), characters classes (for instance: [a-z]) and the most commonly used quantifiers: ?, *, {n}. In order to handle these string patterns, a parser is used to recognize matches to the grammar. Each pattern is processed by the generation engine and transformed into a random string that matches the pattern.

GenerationEngine is thus only responsible for: the sending to EAST of the generation configuration file,

the starting of the EAST generation process – this process is handled by the Data Generator component of the EAST core,

the handling of the messages (errors, warnings, return code, etc) that the generation process can output.

In order not to block the GUI while executing the generation, the GenerationEngine is implemented in a specific thread.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxvii

5.5.6.5 Data checking component

5.5.6.5.1 TypeThe Data Checking component is implemented in the dpe.dataChecking.* package


dpe.dataChecking.* Contains two classes that implement the checking of data and the management of the results.

CheckerCheckResultsManager


SR250_DPE Conformity: C

5.5.6.5.3 FunctionThis component is responsible for the data checking processing. It verifies that a data product is compliant with its associated EAST model. It is also able to identify the elements not compliant and to provide information about the consistency errors.

5.5.6.5.4 DependenciesThe GUI calls the Data Checking component when users want to check if a data product is compliant with its associated data model. When the Data Checking component receives the request from the GUI, it simply calls the Data Checker utility, which is in charge of processing the data verification and returning the results. This is achieved by calling the check function of the DataCheckerServicesInterface of the Data Checker component.The Data Checking component analyses the checking results and makes them available to the GUI in order to be displayed.


call check function

Data Checker<<Component>>

DataCheckerServicesInterface

check()

call checking function display checking results

GUI<<Component>>

Figure 5-161 Data Checking Software Dependency View


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxviii

5.5.6.5.5 InterfacesThe Data Checker utility sends the checking results in a file that is managed (read and parsed) by the Data Checking component.



Figure 5-162 Data Checking Interface view

5.5.6.5.6 ProcessingThe DataChecking component is composed of two classes:

Checker: this class is a thread that is started when the user calls the check function in the DPE GUI. The thread simply calls the check function of the DataCheckerServicesInterface. This function generates a file that contains the check results.

CheckResultsManager: this class is responsible for the reading / analysis of the check results file. It is able to get the check information of a specific element in the data model. The TreePanel (respectively CheckingResultsFrame) call the services of CheckResultsManager in order to highlight the wrong elements in the tree view (resp. display a checking summary in a specific panel).

CheckResultsManager

read()getCheckResults()getCheckResultsOfPath()

Utilities<<Component>>


Checker

check()run()


check()

check


generates

reads GUI<<Component>>

CheckingResultsFrame

getCheckResults

DescriptionPanelgetCheckResultsOfPath

Figure 5-163 Data Checking Class Diagram


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxix

5.5.6.6 Search capabilities component

5.5.6.6.1 TypeThe Search Capabilities component is implemented in the dpe.search.* package.

valueSearch(from search)

syntaxSemanticSearch(from search)

search

dpe(from debat)

Figure 5-164 Search Capabilities Component Package View


dpe.search.syntaxSemanticSearch.* All classes which allows the search engine to looking for syntactic or semantic information.

SyntacticSemanticSearch

dpe.search.valueSearch.* This package is responsible for searching elements using their values as criteria.

ValuesSearch


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxx


SR266_DPE Conformity: CSR267_DPE Conformity: CSR268_DPE Conformity: CSR269_DPE Conformity: CSR271_DPE Conformity: C

5.5.6.6.3 FunctionThis component provides advanced capabilities for searching elements in a data product. Several search criteria are available: EAST path, syntactic or semantic information, and data values. Users can also combine several criteria and use the * and ? metacharacters in their search requests.

The search capabilities are composed of two main independent functionalities detailed hereafter: The Syntax and Semantic Search offers the ability to search for elements (the search

result is a list of paths) using some of their syntactic attributes and/or their semantic attributes. This search is processed on the XML-IF model and is intended to make the model exploration easier.

The Values search engine offers the ability to search for elements’ values using elements’ paths or names as search criteria. This search can be processed on the whole data product or on any particular block (or list of blocks) of the data file

5.5.6.6.4 DependenciesThe Search capabilities component is responsible for handling the user’s search requests that are defined in GUI. Depending on the search request, the Search Capabilities component forwards the request to:

The Modeller component: this component is called when users search for elements having particular syntactic or semantic properties,

The DEQ component: this component is called when users search for elements having a specific value.

The Search Capabilities component receives the search results and sends them to the GUI in order to be displayed.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxi


ModellerServicesInterface syntax & semantic search Search Capabilities<<Component>>

request data search

display search results

GUI<<Component>>


DeqServicesInterface

values search

Figure 5-165 Search Capabilities Software Dependency View

5.5.6.6.5 InterfacesThe Search Capabilities component has no specified interface with the others components.

5.5.6.6.6 ProcessingThe Search Capabilities component comprises two classes:

SyntaxSemanticSearch: this class manages the search by syntactic and semantic attributes. It simply calls the ModellerServicesInterface to process the search.

ValuesSearch: this class manages the search by values. It simply calls the DeqServicesInterface to process the search.

SyntacticSemanticSearchexpression

executeExpression()createExpression()

ValuesSearchquery

executeQuery()createQuery()




searchElements



executeQuery()createQuery()loadDescription()loadDataFile()

(from deq)

executeQuery - createQuery

Figure 5-166 Search Capabilities Class Diagram


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxii

5.6 DEBAT Data Extractor & Querying

5.6.1 Type

The Data Extractor & Querying component is composed of seven elements as shown in the following decomposition view:

Figure 5-167 DEQ components decomposition view

The Data Extractor & Querying component is implemented in the deq.* package.

Figure 5-168 DEQ components package view


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxiii



GUI Gathers all MMI classes giving access to all the DEQ functions.

deq.gui.*

Extraction The role of this component is to insure the extraction of data values either from the graphical interface or resulting of a previous search/query.

deq.extraction.*

Search capabilities This component provides: The search by syntactic and semantic

attributes, The checking of the existence of a particular

element.

deq.search.*

Data manager Its role is to handle the XML-IF data models and the data products files.

deq.dataManager.*

Data storage Its role is to provide mechanisms to save data files on the file-system or in a stream.

deq.dataStorage.*

XML-like queries The role of this component is to construct and process XML queries based on the users’ search criteria.

deq.queries.*

Batch processing This component enables users to launch their processing (i.e. extraction and querying) at a defined time.

deq.batchProcessing.*


5.6.3 Function

The Data Extractor & Querying component provides users with the following functions.

XML views

The DEQ offers the ability to create XML views of the data products. XML views are simply views of the data files formatted in XML.

XML-like queries

The DEQ also provides the ability to create and process XML-like queries that are executed upon the data products. XML-like queries are used to “dig” in the data files to search for and extract specific values. It is possible to search through one or more products at the same time (instances of the same EAST description). The results of the search may be either a list of responding elements or a list of responding blocks of data (i.e. which contains elements responding to the search criteria).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxiv

Search functionalities

The DEQ tool supports search by syntactic or semantic attributes. These search capabilities support advanced features like wildcards, comparison operators and combination of search criteria.

Data extraction

The DEQ proposes the ability to extract elements from data products either graphically (in the data product graphical view) or by extracting elements resulting of a search. These elements can be stored on many supports (i.e. to disk, on standard output or in a socket).

Batch processing

This convenient functionality enables users to schedule data querying and data extraction at a later time.

IF file handling

The DEQ is able to read and interpret any XML-IF file and display it in a tree-like graphical view. The tool also offers the ability to navigate through the whole data model graphical view.

Data products handling

The DEQ provides the ability to read and display data products from many sources (i.e. disk, from standard input or from a socket). The tool also provides the ability to navigate through the whole data product graphical view.

Graphical user interface

All the functions provided by the tool are made accessible through a user-friendly interface.

The following schema describes the functional logic of the previous described functions:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxv

Figure 5-169 Data Extractor & Querying component functional logic

5.6.4 Dependencies

The Data Extractor & Querying component relies on the services offered by the other components: The EAST core component is used concerning the data reading (i.e. reading the data

values in the data products), existence checks and query functionalities (i.e. for processing and getting results). The services of the EAST core are accessed through the Java API component of the EAST core component.

The DEQ depends on the Ascii dump component (of the Utilities component) used to create XML views of the data products.

The DEQ depends on the Project Management component of the Integrated Environment component to access the virtual organisation of the files. Furthermore, the DEQ implements the PluginInterface provided by the Plug-in System of the Integrated Environment.

The DEQ uses the Modeller component to load the XML-IF data models in memory and to perform semantic and syntactic searches.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxvi





creates XML viewsEAST core

<<Component>>

EAST serv ices: read / existence check / process XML queries


access project/f iles - implements plugin interf ace


Figure 5-170 Data Extractor & Querying component dependencies

The following figure shows the internal dependencies of the Data Extractor & Querying component.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxvii

XML-like queries<<Component>>

Search capabilities<<Component>>

Extraction<<Component>>



Batch processing<<Component>>

Check elements' existence

XML v iews creation


Read XML IF f iles


Extract v alues f rom results

Process query

Create/Process extraction query

Get processing results

Make sy ntactic/semantic search

Get sy ntactic/semantic attributes

Data products reading

Get v alues f rom query results

GUI<<Component>>

Call extraction f unctionalities

Call batch processing f unctions

Get query f rom f ileSav e extracted v alues

Sav e query in f ile

Process queries

Sav e query results

Query processing

Read XML IF and data products Create XML v iewsCall search f unctionalities

Generate EAST f ile

Ascii Dump<<Component>>Process sy ntactic/semantic

search

exist / isDiscriminated

Figure 5-171 DEQ components detailed dependencies

5.6.5 Interfaces

The Data Extractor & Querying component deals with the following files: XML IF files,

Data files for data reading and data extraction,

Query files containing requests following the DEBAT query language,

XML data files that are generated based on an existing data file.

The DEQ can read the XML IF files and display their contents. It can also read data products corresponding to the read XML IF files. The DEQ can extract values from these data products to create new data packages.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxviii

Figure 5-172 DEQ component interfaces

5.6.6 Processing

The Data Extractor & Querying component is not a standalone tool but as a part of the DEBAT tool suite, it is considered as a plug-in. It implements the PluginInterface provided by the Plug-in system and offers a services interface (DeqServicesInterface) to all the other tools/plug-ins.

The main class of the Data Extractor & Querying component is the DeqManager. It is responsible for correctly handling the MMI events and launching the appropriate actions.

It communicates with the Project Management component through the ProjectManagementServicesInterface. This services interface is used to access to the various projects declared in DEBAT.

The DeqMainFrame is composed of three main panels: The TreePanel panel is responsible for displaying the XML-IF content in a tree view

form,

The ValuesDisplayPanel panel is responsible for displaying the values associated with the elements of the tree view,

The SyntacticSemanticDisplayPanel panel is used to present the syntactic and semantic information associated with the elements displayed in the tree view.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxix


executeQuery()createQuery()loadDescription()loadDataFile()

send MMI ev ents

TreePanel

(from panels)

ValuesDisplayPanel

(f rom panels)

DeqMainFrame

(from frames)

syntacticSemanticDisplayPanel

(f rom panels)



getProjects()getProjectBy Name()addProject()remov eProject()trigger()

(f rom projectMgt)

DeqManager

loadDescription()closeDescription()quit()createXmlViews()syntacticSemanticSearch()queryWizard()existenceCheck()queryForAdvancedUsers()loadDataFile()closeDataFile()valuesSearch()

forward call

uses

Plugin Sy stem<<Component>>

PluginInterf ace


(f rom interf ace)

implements

display / update

Figure 5-173 DEQ component classes diagram


5.6.6.1.1 TypeThe GUI component is implemented in the deq.gui.* package. It is composed of two main packages: the first containing the panels and the other containing all frames of the tool.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxx

panels(from gui)

frames(from gui)

gui

deq(from debat)

Figure 5-174 GUI component package view.


SR279_DEQ Conformity: CSR280_DEQ Conformity: CSR293_DEQ Conformity: CSR312_DEQ Conformity: CSR313_DEQ Conformity: CSR281_DEQ Conformity: CSR282_DEQ Conformity: CSR283_DEQ Conformity: CSR284_DEQ Conformity: CSR286_DEQ Conformity: CSR287_DEQ Conformity: CSR288_DEQ Conformity: C

5.6.6.1.3 FunctionThe main frame (DeqMainFrame) enables easy access to all of the functionalities of the DEQ and fast access to the mostly used ones through shortcuts. The main frame is split into three areas:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxxi

Figure 5-175 DeqMainFrame

A TreePanel displays the data model loaded. It provides the ability to navigate through the data model. It is to be noted that the whole model is displayed (i.e. like in the Modeller). However, in this case, some elements do not have any value and are deactivated (i.e. elements present in the data model and not present in the currently displayed data block are highlighted using a specific colour).

The ValuesDisplayPanel displays the elements values contained in the data products.

The SyntacticSemancticDisplayPanel displays the syntactic and semantic information contained in the XML IF file.

The GUI component provides also several frames to perform searches and queries:

The SyntacticSemanticSearchFrame provides the ability to perform a search on the data model based on semantic and syntactic attributes. This search returns a list of the responding elements (path, name) that is displayed to the user.

The ExistenceCheckFrame provides the ability to verify that a given element exists in the loaded data product. This function returns the list of the blocks in which the element exists. This list is displayed to the user.

The QueryWizardFrame is a wizard that helps the user to create XML queries. The user can also use directly the QueryFrame (in this case, he has to know the XML-query language used by the DEQ). The result of an XML-query execution is a list providing the following information (block number, path, encoding mode, binary value if any, ASCII value if any). The elements can be displayed block-by-block or element-by-


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxxii

element. In the first case, all elements are displayed for one particular block while in the second case all values are displayed for one particular element.

The XMLViewsFrame allows generating an XML view of a loaded data product.

5.6.6.1.4 DependenciesThe GUI component relies on the other components to provide the desired functionalities.

GUI<<Component>>


Batch processing<<Component>>




Call extraction f unctionalities

Process queries

Call existence check f unction

Call sy ntactic/semantic search f unctions

Call batch processing f unctions

Read data product


Sav e extracted v alues

Sav e query in f ile

Get query f rom f ile

Read IFDisplay query results

create XML v iews

Figure 5-176 GUI component dependencies

The GUI component transforms users actions into method calls based on all other components. The GUI component is responsible for managing users’ actions and forwarding the processing to the correct DEQ components (i.e. Extraction, Batch processing, XML-like queries, Data Storage, Search capabilities and Data Manager). Its role is also to display the results of the processing.

5.6.6.1.5 ProcessingThe graphical interface is composed of several frames and panels. They are depicted in the following diagram.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxxiii

Sy ntacticSemanticSearchPanel

(from panels)

XmlViewsPanel

(from panels)ExistenceCheckPanel

(from panels)

syntacticSemanticDisplay Panel

(from panels)TreePanel

(f rom panels)

ValuesDisplay Panel

(from panels)

Sy ntacticSemanticSearchFrame

(from frames)

XmlViewsFrame

(from frames)ExistenceCheckFrame

(from frames)

The role of the QueryWizardFrame is to guide the user through the selection of the components required to create a request (e.g. description f ile, data f iles, elements to search). On the contrary , the QueryFrame is f or users who already know the query language and simply ty pe it or load it f rom a f ile.

displays

displays

displays

displaysdisplays

QueryWizardPanel

(from panels)

QueryPanel

(f rom panels)

DeqMainFrame

(from frames)

QueryWizardFrame

(from frames)

QueryFrame

(f rom f rames)

ExtractionFrame

(from frames)

QueryResultsFrame

(from frames)

display sdisplay s

display s

Figure 5-177 DEQ graphical interface class diagram

The DeqMainFrame is composed of three panels: A tree view panel (TreePanel) that draws the graph corresponding to the loaded

description,

A syntactic/semantic panel (SyntacticSemanticDisplayPanel) that displays all syntactic and semantic information,

And finally a values panel (ValuesDisplayPanel) that displays the values associated with the elements of the graph.

All the graphical interfaces of the Data Extractor & Querying are implemented in Java using the Swing components to provide evolved capabilities and look & feel. More, the execution of the GUI and the processing is separated (in different threads), so that the user shall not be blocked when manipulating the tool.

5.6.6.1.6 Sketches of the GUIThe DeqMainFrame is shown in the following sketch.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxxiv

Figure 5-178 DeqMainFrame GUI

The QueryWizardFrame is shown in the following picture.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxxv

Figure 5-179 QueryWizardFrame GUI

The QueryWizardFrame helps the user to create requests without knowing the DEQ query language. The panel is divided in six main sub-panels:

The first panel (i.e. identified by the label “Description to search”) is used to precise the description to search,

The second panel (i.e. identified by the label “Data files to search”) enables the user to select the data files to query. It also precise all the data files that have been previously selected,

The third panel (i.e. identified by the label “Blocks to search”) enables to reduce the scope of the query by selecting blocks of the data files to look after (by default all blocks are looked after),

The fourth panel (i.e. identified by the label “Elements to search”) permits to select the elements to search. It gathers all the elements that are being searched for by the user,

The fifth panel is used to constraint the values of the searched elements by constraining their values. All elements values can be constrained and combined using the AND and OR operators,

The last panel (i.e. identified by the label “Search for…”) is used to present the search criteria in an intelligible form.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxxvi

The following picture shows a sketch of the QueryFrame. This frame is proposed for advanced users that have knowledge of the query language and that are able to type the request.

Figure 5-180 QueryFrame GUI

This frame has a text area in which the user types the request to be executed. The user has several choices: load a query from a query file, save the typed query in a file, launch the query, cancel the processing or defer the processing of the query.

When performing a search by value or an XML-query, the results are displayed to the user in the QueryResultsFrame. It enables the user to see the results sorted either by blocks number or by elements’ paths.

The following sketch present the query results sorted by elements:

Figure 5-181 QueryResultsFrame GUI (display by elements)

In this case, the user selects the “ELEMENTS” mode. This means that the results will be displayed element by element. For each element, a table gathers all its result values. The first column precise the data file in which the values have been found. The second column indicates in which blocks the


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxxvii

value was found (i.e. in which block it responds to the request) while the last column precise the value of the element for this particular block.

On the contrary the following sketch present the results sorted by blocks number:

Figure 5-182 QueryResultsFrame GUI (display by blocks)

In case of display by block, the user first selects the data file to be displayed (i.e. the results that will be displayed have been found in this data file). The user then selects the block to be displayed. A table gathers all the elements responding to the query for one particular block. These elements are classified according to their order in the description. The first column of the table indicates the path of the element. The second column shows the type of the elements. The last column presents the value of the elements.

More, once the results are displayed, the user has the choice to close the QueryResultsFrame or to extract values from these results to create new data packages with the ExtractionFrame.

Figure 5-183 – ExtractionFrame GUI

From the query results panels, the user has the choice to extract the values displayed to create a new data package. The list of all elements resulting of the search is displayed. The user selects the elements he wants to be extracted. The last part of the interface defines the scope of the extraction. The user can extract the elements in all blocks or chooses in which blocks the values have to be extracted (several blocks can be chosen at the same time). Once done, the user has to select to store the results either in a file or in a stream. In the first case, a dialog file chooser panel is displayed and


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxxviii

the user simply enters the name of the file and its location. In the second case, the user is asked for the target stream: standard output or socket. If socket is selected then the user is requested to enter an IP address and a port.

The XMLViewsFrame graphical is shown in the following sketch.

Figure 5-184 – XMLViewsFrame GUI

The user simply selects the XML views creation mode (i.e. FLAT or HIERARCHICAL) and the filename to store the XML view in.

5.6.6.1.7 Menu tree

The following table presents the items of the menu tree for the DeqMainFrame.

Menu Sub-menus Comments

File

Open This functionality is used to open XML-IF description file and display them in the tree view.

Open data file

This functionality is used to open a data file and display the contained values. It will only be active if a description has been previously loaded.

Close This functionality will close the currently displayed description along with the associated data files.

Close data file This functionality is used to close the currently displayed data file.

Quit This functionality is used to close the Extractor & Querying tool.

SearchExistence check This functionality will display the existence check frame.Syntactic/Semantic search

It will open the syntactic/semantic search frame.

QueryQuery Wizard

It will open the query wizard frame that will guide the users through the creation of a request by entering the request parameters (e.g. description file, data files, elements to search).

Query (Advanced Users)

This functionality is for advanced users who have knowledge of the DEBAT query language.

Tools XML views This functionality will open the XML views creation frame.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxxxix


5.6.6.2.1 TypeThe Data Manager component is implemented in the deq.dataManager.* package.

Figure 5-185 - Data Manager components package view



deq.dataManager.xmlIFManager.* This package is responsible for the loading of the XML-IF data models.

DataModelManager

deq.dataManager.dataProductsManager.* This package is responsible for reading of the data products

DataManagerSocketReaderDataReaderDataBlock

deq.dataManager.xmlViews.* This package is responsible for creating XML views of a loaded data product.

XmlViews


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxl


SR290_DEQ Conformity: CSR291_DEQ Conformity: CSR294_DEQ Conformity: C SR310_DEQ Conformity: C

5.6.6.2.3 FunctionThe role of the Data Manager component is threefold:

It is used to load the XML-IF files.

It is responsible for the reading of the data products from files or streams (socket or standard input)

It is also used to create XML views corresponding to a loaded data product. The generated XML can map the model (i.e. hierarchical mode) or the values can be generated in the XML at the same level (i.e. flat mode)


Figure 5-186 - Data Manager components dependencies

The Data Manager component depends on three external components: The EAST Core component is used to get the values contained in the data products.

The ASCII Dump component is used to create the XML views,

The Modeller component is used to load the XML IF files, and get the syntactic/semantic information associated with each element of the data model. It is also used to generate the EAST files corresponding to the XML IF (they are required to read the data products with the EAST core).

The following table details the functions of the external components called by the Data Manager:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxli

Target Component Functionality Functions called

Java API component of the EAST core

Data products reading SelectDDR()ReleaseDDR()SelectDataProduct()SelectDataProductFromSocket()SelectDataProductFromStandardInput()SelectBlock()LoadNextDataBlockFromFile()GetDataEntityAscii()GetDataEntityBinary()Start()Stop()

Ascii dump component (of the Utilities component)

XML views creation dumpToXML()

Data Modeller component

XML IF files reading LoadXmlIf()Syntactic/Semantic

searchSearchElements()

East file generation GenerateEastFile()

5.6.6.2.5 InterfacesThe Data Manager can read data models described in XML IF files and display their content. It can also read the data products associated with the XML IF from files or from streams (socket and standard input). Finally, this component also produces XML views of the data files.


XML IF<<XML f ile>>

Data file<<DATA File>> XML data f ile

<<XML File>>

Data f low f rom standard input<<DATA flow>>

Data f low f rom socket<<DATA flow>>

Figure 5-187 - Data Manager component interfaces view.


The DataManager is responsible for the reading of the XML IF files and of the generation of the corresponding EAST files. It is based on the Modeller component. Once the EAST file is generated, the DataManager calls the EAST core component to select the description to use.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxlii


EAST core(f rom Component Decomposition)

<<Component>>


ModellerServ icesInterf ace

loadXmlIf ()loadEastFile()loadOasisIf ()generateEastFile()generateDedslXmlFile()generateDedslPv lFile()generateHtmlDocumentation()generatePdf Documentation()generateRtf Documentation()generateFormatFile()generateAdaDeclarationFile()generateC_CppDeclarationFile()generateJav aDeclarationFile()generateXmlIf File()checkSy ntax()checkSemantic()getModellerCurrentDataModel()getModellerOpenedDataModels()sav eCurrentDataModel()searchElements()

Interpreter

DataModelManager

readDataModel()closeDataModel()getSy ntacticInf ormation()getSemanticInf ormation()getTy pe()exist()sy ntacticSemanticSearch()

loadXmlIf, generateEastFile

start, selectDDR

Figure 5-188 - DataModelManager class diagram (XML-IF loading)

The DataManager is also in charge of the reading the data values contained in the data products. Hence, it relies on the Java API component of the EAST core component to read the data products. Only reading functions are used (i.e. users can not modify nor generate data products with the DEQ).

The data are read on user request. It means that the data file is not fully parsed the first time it is loaded: only the values to display are read. The DataManager creates a DataReader object that is responsible for reading only the required values. The DataReader relies on the Interpreter reading services to get these values from the data product. These values are then stored in a DataBlock object gathering the values read for a particular block. Several DataBlock objects are then handled by the DataManager, one for each block of data already displayed to the user.

The SocketReader is used to read data products from a socket. It calls the Interpreter function selectDataProductFromSocket(). The reading mechanism is the same: the DataReader calls then the Interpreter to retrieve the data values.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxliii

EAST core(from Component Decomposition)

<<Component>>


SocketReader

startSocketServ er()stopSocketServ er()run()

DataManager

isDiscriminated()exist()readFromFile()readFromSocket()readFromStandardInput()readElementValue()selectBlock()selectNextBlock()readChildrenValues()readLeav esValues()

0..10..1

holds

Interpreter


selectDataProduct

DataBlockblockNumberdataValues

getValues()getValueOf Path()clearValues()isPathRead()

0..*

1+dataBlocksList

0..*

1

holds

DataReader

run()getLengthOf Task()getPercentAchiev ed()isFinished()f inish()

1

1holds

getDataEntityAscii, getDataEntityBinary

setValueOfPath

1

1

Figure 5-189 - DataManager class diagram (data reading)

The XMLViews class is responsible for generating the XML views of the data products loaded in memory (it relies on the Ascii dump component to perform this operation).


XmlViews

createXmlView()

AsciiDumpServicesInterface

dump()dumpToXML()

dumpToXML

Figure 5-190 - XMLViews class diagram

The XML views only require one function of the Ascii dump component to be called: the dumpToXML() method which generates the XML view of the data file.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxliv

5.6.6.3 Search capabilities component

5.6.6.3.1 TypeThe Search capabilities component is implemented in the deq.search.* package.

sy ntaxSemanticSearch

(from search)existenceCheck

(from search)

search

deq(from debat)

Figure 5-191 - Search capabilities component package view


Package Content Classes

deq.search.existenceCheck.* This package is responsible for the checking of elements’ existence.

ExistenceCheck

deq.search.syntaxSemanticSearch.* This package is responsible for searching elements in the data model based on its syntactic and semantic attributes.

SyntacticSemanticSearch


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxlv


SR295_DEQ Conformity: CSR296_DEQ Conformity: CSR297_DEQ Conformity: CSR298_DEQ Conformity: CSR300_DEQ Conformity: CSR302_DEQ Conformity: CSR301_DEQ Conformity: CSR303_DEQ Conformity: CSR304_DEQ Conformity: CSR305_DEQ Conformity: CSR306_DEQ Conformity: CSR307_DEQ Conformity: CSR308_DEQ Conformity: C

5.6.6.3.3 FunctionThe Search capabilities component provides three main functionalities detailed hereafter:

The Existence Check,

The Syntax and Semantic Search.

The Existence Check offers the ability to verify that an element exists in the data product using its path as parameter. The role of this module is to verify the existence of an element in a particular data product based on its path. It is to be noted that this search can be processed on one or several blocks (i.e. chosen by the user) or on the entire data product (i.e. all blocks will be searched). In both cases, the result details in which blocks the element is present. The first thing to verify is that the path specified by the user exists in the loaded description. Then, is must be verified if the element is discriminated or not. If not, then the element is present in all blocks of the data file. If it is discriminated, the data product must be looked after to check if the element is present in the specified blocks. These blocks are looked after one at a time.

The Syntax and Semantic Search offers the ability to search for elements (the search result is a list of paths) using some of their syntactic attributes and/or their semantic attributes. This search is processed on the XML-IF model and is intended to make the model exploration easier. The results are rendered as a list of elements (identified by their paths) whose semantic and/or syntactic attributes respond to the search criteria.


The Search capabilities component relies on the Data manager and on the EAST core. To perform the existence check, the following functions of the DataManager are used: exist() and isDiscriminated(). The EAST core is also used to navigate in the data product to verify the existence of the element in the data product.

The following table summarises the functions of the EAST core Java API called by the Search capabilities component:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxlvi

Functionality Target Component Functions

Existence Check EAST CORE Java API SelectDDR()ReleaseDDR()SelectDataProduct()SelectBlock()LoadNextDataBlockFromFile()PrepareAccessesForCurrentBlock()CloseFile()Exist()Start()Stop()

The Search capabilities component also relies on the Modeller component to perform semantic and syntactic searches.




Modeller<<Component>>Process sy ntactic/semantic

search

exist / isDiscriminated

Check elements' existence

Figure 5-192 -Search capabilities component dependencies


The existence check function is implemented by the ExistenceCheck class that offers only one method to other classes: checkExistence(). This method will first verify that the element is present in the model and discriminated (through the DEQ DataManager component). If these requirements are verified, then it will use the Interpreter of the EAST Core Java API to browse the data product to search this particular element.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxlvii



ExistenceCheck

checkExistence()

DataManager

isDiscriminated()exist()readFromFile()readFromSocket()readFromStandardInput()readElementValue()selectBlock()selectNextBlock()readChildrenValues()readLeavesValues()

(f rom dataProductsManager)

exist, isDiscriminated

Interpreter

selectBlock, exist

Figure 5-193 ExistenceCheck class diagram

The following figure details the sequence of operations for the existence check:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxlviii

: User : ExistenceCheck : DataManager (EAST CORE Jav aAPI) : Interpreter

: ExistenceCheckFrame

If the element exists in the model and is discriminated, then the user-def ined blocks are searched in the data f ile. This process is repeated f or each user def ined blocks of the data f ile.

check element's existence

exist( )

isDiscriminated( )

selectBlock( )

checkExistence( )

exist( )

boolean

display blocks l ist

Figure 5-194 - Existence Check sequence diagram

The user selects the existence check function through the ExistenceCheckFrame and enters the path of the element to search for. The MMI forwards the call to the ExistenceCheck class. The first action is to verify that the path exists in the model displayed. If it exists, it is verified that the element is discriminated. If not, then the element is present in the whole data file (i.e. in all blocks). If it is discriminated, then the data file is searched to verify the presence of the element in its blocks according to the scope defined by the user. A list of blocks where the element is present is then displayed to the user.

For what regards the syntactic and semantic search, the SyntacticSemancticSearchManager class is just a facade that forwards the call to the ModellerServicesInterface of the Modeller component.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxlix




SyntacticSemanticSearchManager

searchExpression : String

executeSearch()

searchElements()

Figure 5-195 - SyntacticSemanticSearchManager class diagram


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccl

5.6.6.4 XML-like queries component

5.6.6.4.1 TypeThe XML-like queries component is implemented in the deq.queries.* package.

Figure 5-196 – XML-like queries component package decomposition view



deq.queries.* Gathers all the classes required: to create the requests upon the

users’ search criteria,

to execute theses requests,

to parse the results to present them to the user.

QueryManagerQueryResultQuery


SR311_DEQ Conformity: C

5.6.6.4.3 FunctionThe goal of the query component is:

to create the queries bases on the criteria entered by the user,

to pre-process the queries to verify their correctness (verify that the elements’ path are valid),

to execute the XML queries using the Java API component of the EAST core,

to parse the results and prepare them for display/storage.

There are two types of queries:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccli

1. The user may search for elements’ values using only their names and types as parameter. The results consists as a list of values identified by the blocks where they belong and the paths of the corresponding elements along with ancillary information like the name of the corresponding element, its encoding mode (i.e. binary or ASCII), its ASCII value if any. If the name passed as parameter correspond to record elements, then only the path of the elements are returned (i.e. records have none immediate values). When the results are displayed, the user can extract the values and store them in a new data package.

2. The user may want to search for elements using their types, their values and their names (i.e. it can be the name of the element to search or its path to be more precise) as search criteria. For this kind of search, users are able to use comparison functions (i.e. =, <, >, ≤, ≥ and ≠) when looking for integer, character, real and enumeration elements. The ‘=’ and ‘!=’ operators are also available when dealing with string elements. More, the use of the ‘*’ and ‘?’ meta-characters are authorised when searching for string elements. This search can also be applied to arrays and lists if they contain valid elements (i.e. of integer, real, character or string type). All the elements of the array/list are looked after, one after the other.

Note: The user has the choice to precise the name of the element to search or its complete path. However, for processing the queries, the whole path of the elements has to be given. This way, the names are automatically transformed into complete paths. If a particular name corresponds to several paths in the model, then it is up to the user to select the paths to look after.Furthermore, all queries have a scope that can be:

The current data block (i.e. the block being displayed in the MMI),

All blocks contained in a data product,

A range of blocks numbers (to reduce search only to a subset of the original data file),

A frequency (to search for information every N blocks).

This search can be processed upon one or more data files at the same time provided they are instances of the same loaded description file. The data files are looked after one after the other. In this case, the same scope applies to all the data files selected by the user.

The query is processed in four main steps: The criteria filled-in by the user are verified,

A query is created using the search criteria. This query follows the DEBAT XML query language,

This request is transmitted to the EAST core (using the Java API) along with the required information (i.e. description and data files). The EAST core firstly analyses the request, processes it and return the results to the XML-queries component,

The XML-queries component displays the results as a browsable list to users.

The search results are displayed to users as a list of elements. This list contains the following information for each element:

The block number containing this element,


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclii

The path of the element

Its encoding mode (i.e. ASCII or BINARY) if the element is not an array, not a list and not a record,

The ASCII value of the element. If the encoding for this element is BINARY, the value is transformed into ASCII so users also have the value in an understandable form.

5.6.6.4.4 DependenciesThe XML-like queries component uses two components to fulfil its functionalities:

It relies on the EAST Core component (and especially on the Java API) to process the request and get the associated results,

It also relies on the DEQ Data Manager component to validate the criteria concerning the names/paths of the elements searched.

Figure 5-197 - XML-like queries component dependencies

This component uses the DEQ Data Manager component to verify that the elements searched by the user exists in the model and are fully qualified (i.e. their whole path is specified). If some of the elements do not exist, then the component displays an error. If some of the elements are not fully qualified, the component displays to the user a list of corresponding paths. The user has to select the right path in the list.

The component uses the following methods of the EAST Core Java API (QueriesHandler):

Target component Functionality Methods Names

Queries Handler class of the Java API component of the EAST core

Process query AnalyseQuery()FreeQuery()

Get query processing results NextDataRecords()IsColumPresent()VariableValue()FreeDataRecords()


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccliii

5.6.6.4.5 ProcessingThe XML-like queries component uses the QueriesHandler class of the Java API and especially the analyseQuery method. This method returns an id that will be used to get the results of the query by the QueryResult class.



QueryquerysearchedElementsquery Id

preProcess()

QueryManager

executeQuery ()preProcessQuery ()createQuery ()dispose()getResults()opname()

0..*

1

+list of

0..*

1

holds

QueryResultquery IdblocksHashMapdataFilesHashMapv aluesArray

getAsciiValue()getBinary Value()

0..*

1

+list of

0..*

1 holdsQueriesHandler

analy seQuery ()nextDataRecords()isColumnPresent()v ariableValue()f reeDataRecords()f reeQuery ()recordsCount()blockNumberOf Records()dataFilenameOf Records()

(from Component Java API)

calls

get query results

Figure 5-198 XML-like queries component class diagram

The QueryManager class holds a list of opened queries and another list for the queries results. The results are retrieved through the QueriesHandler class.

The following diagram presents the sequence of operations for the XML query processing:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccliv

: User : QueryManager : QueryResult ( EAST CORE JAVA API) : QueriesHandler

: QueryWizardFrame

analy seQuery ( )

processing ok?

If the processing of the query has not generated errors then the results are read.

This part is repeated until all results have been read from the QueriesHandler

f reeDataRecords( )

f reeQuery ( )

getResults(queryId)

nextDataRecords( )

v ariableValue( )

resuls reading ok?

Once the results have been read from the QueriesHandler, the resources are freed.

enter criteriacreateQuery ( )

return queryId

executeQuery ( )

display query results

Figure 5-199 - Query processing sequence diagram

The first action of the user is to fill in the query criteria. These criteria are filled using the QueryWizardFrame graphical interface or directly through the QueryFrame for advanced users. The first operation consists in creating the query based on these criteria. The QueryManager is in charge of creating the query objects and returns an id. From now on, all operations require this id to identify the query to be executed. The query is then executed by the EAST Core (through the Java API). If the processing is correct, then the values are retrieved from the EAST core. Once the results have been read, they are displayed to the user. The resources of the EAST core used to process the query are then released.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclv

5.6.6.5 Extraction

5.6.6.5.1 TypeThe Extraction component is implemented in the deq.extraction.* package.

Figure 5-200 - Extraction component package view



deq.extraction.* This package is responsible for the: Extraction of data values from

the graphical interface,

Extraction of data values from query results.

GraphicalExtractionResultExtraction


SR315_DEQ Conformity: CSR316_DEQ Conformity: CSR317_DEQ Conformity: C

5.6.6.5.3 FunctionUsers have two ways to extract elements with the Extraction component:

The extraction can be processed directly on the tree graphical view (i.e. on the TreePanel displaying the data model),

The extraction can be applied upon the results of a previous query (i.e. starting from the results displayed in a QueryResultsFrame).

In the first case, the user selects the elements to extract graphically in the tree graphical view using the mouse. Once, all the elements have been selected, the user can extract them from the data product displayed. The only thing left is to select the scope of the extraction (i.e. extract the elements in the whole file or simply in some user-specified blocks). The values are then searched for in the data product (using a query) and extracted.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclvi

In the last case, a query has been previously processed and the results are being displayed to the user. The user can choose to extract some or all of these results.

5.6.6.5.4 DependenciesThe Extraction component is only based on the XML-like queries components of the DEQ, which is used when the user wants to extract values. There are two modes to extract values from a data product:

Graphically: we mean here that the user selects the elements to extract in the graphical tree view (TreePanel). The user also selects the scope of the search (i.e. extract the values of the selected elements only in the displayed block or in the whole file or only in some blocks). With these information, the XML-like queries component is called to create and execute a query. The results are then retrieved and displayed by the QueryResultsFrame.

Extraction from query results: the results of a query are displayed in the QueryResultsFrame. The user can select the elements to extract and the scope of the extraction (the user can extract values in all results blocks or only in several of these blocks).

Figure 5-201 - Extraction component dependencies

5.6.6.5.5 ProcessingThe GraphicalExtraction class takes as input the elements to extract and creates a query with these elements. It then launches the query processing through the QueryManager class and uses the ResultExtraction class to extract the results of the query. The ResultExtraction class gets the query results from the ResultManager and extract the values.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclvii

Figure 5-202 - Extraction component class diagram

The following figure present a graphical extraction sequence diagram:

: QueryResultUser : ExtractionFrame : GraphicalExtraction : ResultExtraction : QueryManager

extraction()

getResults()

return QueryResult

The user graphically selects the elements to extract and also chooses the scope of the extraction (i.e. in which blocks to extract).

The result values are retrieved one by one in the query results.

select elements to extract

extract elements

createQuery ( )

executeQuery ( )

Display extraction results

Figure 5-203 - Extraction sequence diagram


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclviii

5.6.6.6 Data Storage

5.6.6.6.1 TypeThe Data Storage component is implemented in the deq.dataStorage.* package.

Figure 5-204 - Data storage components package view



deq.dataStorage.file.*This package is used to store the extracted data values in a file.

FileWriter

deq.dataStorage.stream.*This package is used to store the extracted data values in a stream (i.e. standard output or socket).

StreamWriterStdoutWriterSocketWriter


SR318_DEQ Conformity: CSR319_DEQ Conformity: CSR320_DEQ Conformity: C

5.6.6.6.3 FunctionThe goal of the Data storage component is to save/export the values extracted from the data products. If the user chooses to save the results, then a filename to store the values is asked for and the data are stored in this file. If the user chooses to export the values, two choices are available: to put values in a socket or on the standard output. All the data values are available directly as a result of an extraction process, resulting either from a XML query or from a graphical extraction.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclix

5.6.6.6.4 DependenciesThe Data Storage component uses the Extraction component to get the list of the elements to store. It also uses the Data Manager to get the encoding of the elements (i.e. ascii or binary) specified in the data model. Then, using the list of elements, the Data Storage component gets the values from the XML-like queries component in the appropriate encoding.

get list of the elements to extract



Get sy ntactic/semantic attributes



Get v alues f rom query results

Figure 5-205 – Data storage component dependencies

5.6.6.6.5 InterfacesThe Data Storage creates new data packages with the extracted values either in a file or in a stream (i.e. standard output or socket).

Data file<<DATA File>>


Save data values

Streamed data<<DATA Flow>>

Save data values

Figure 5-206 Data Storage interfaces



Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclx

SocketWriter

writeDataToStream()connectToSocketServer()disconnectFromSocketServer()

(from stream)SdtoutWriter

writeDataToStream()

(from stream)

QueryResult

queryIdblocksHashMapdataFilesHashMapvaluesArray

getAsciiValue()getBinaryValue()

(from queries)

DataModelManager

readDataModel()closeDataModel()getSyntacticInformation()getSemanticInformation()getType()exist()syntacticSemanticSearch()

(from xmlIFManager)

QueryManager

executeQuery()preProcessQuery()createQuery()dispose()getResults()opname()

(from queries)

StreamWriter

queryId

writeDataToStream()

(from stream)get query results

get values get syntactic information

get l ist of elements to save

FileWriter

fileNamequeryIdelementsToExtractList

saveValuesToFile()saveQueryStringToFile()

(from file)

get query results

get values

get syntactic information

ResultExtraction

query IdelementsToExtractListscopeencoding

extraction()

(from extraction)

get l ist of elements to save

Figure 5-207 Data Storage component class diagram

Both FileWriter and StreamWriter classes interrogate the ResultExtraction class to get the list of the elements to save/export. It then uses the QueryManager class to get the results associated with a particular query. Then, they get all the values to save/export from the QueryResult class based on the list of the elements to save/export.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxi

The following figure shows the sequence of operations required to save the values to disk:

This part is repeated for all elements to extract.

: User : QueryResultFrame : QueryManager : FileWriter : QueryResult : DataModelManager : ResultExtraction

getResults( )

getAsciiValue( )

The user indicates the elements to extract, the scope and the encoding mode

Get the value for all elements according to the encoding selected by the user.

getSyntacticInformation( )

Check the encoding (i.e. binary or ASCII) for each element.

getBinaryValue( )

Save value to fileEach value read in the query results is stored on disk.

store values to disk

saveValuesToFile( )

getElementsList()

Figure 5-208 – Query results file saving sequence diagram

At the beginning the user browses the results list (from the execution of a query) graphically and chooses to save the values. Then the user opts for a storage mode: file or stream. In the previous figure, the user selects a file storage. Then the user gives the scope (i.e. the user can extract the results in all results blocks/data files or only in the desired blocks/data files) and the encoding. By encoding, we mean that the user has the choice to save the results in their original mode (i.e. the one specified in the data model) or in ASCII.Then the processing is forwarded to the FileWriter class that interrogates the ResultExtraction to get the list of the elements to extract. It then asks the QueryManager for the results associated with this query. Each value to save is read according to the encoding required by the user and saved to disk.

This is quite the same process for the standard output writing except that each read value from the QueryResult is put on the standard output.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxii

The following figure shows the sequence of operations required to save the values to a socket:

: ResultExtraction: User : SocketWriter : QueryManager : QueryResult : DataModelManager : QueryResultsFrame

The user indicates the elements to extract, the scope and the encoding mode. He also enter the socket information : IP and port.

Get the value for all elements according to the encoding selected by the user.

Check the encoding (i.e. binary or ASCII) for each element.

Each value read in the query results is exported on the socket.

This part is repeated for all elements to extract.

connectToSocketServer( )

getSyntacticInformation( )

getResults( )

getAsciiValue( )

getBinaryValue( )

writeDataToStream( )

store values to socket

writeDataToStream( )

getElementsList()

Figure 5-209 - Socket storage sequence diagram

The main difference relies in the fact that the Data storage component has to connect to the socket server and send the data values read in the QueryResult (again with the encoding required).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxiii

5.6.6.7 Batch processing

5.6.6.7.1 TypeThe Batch Processing component is implemented in the deq.batchProcessing.* package.

deq(from debat)

batchProcessing

Figure 5-210 Batch processing components package view



deq.batchProcessing.* This package is used to defer the processing of queries.

SchedulerEvent


SR322_DEQ Conformity: C

5.6.6.7.3 FunctionThe Batch Processing component is just a convenient way to use the querying functionalities. The goal is to schedule these tasks later at a time where maximal resources are available (e.g. when the user is not using the computer). The user only has to precise the date and time when the query has to be executed and also the file where the results have to be saved.

For each query to defer, a background task is scheduled at the user-defined time in the Scheduler. A new entry is added with the following information: the date and time of execution, the filename where the results are to be saved and the query to be executed. At the desired date and time, the action is executed based on the stored parameters and the results stored to disk.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxiv


Figure 5-211 - Batch processing component dependencies

The Batch processing uses the XML-like queries module to process the queries and get the results. These results are stored on the file system using the Data storage component.


Figure 5-212 - Batch processing component interfaces


Scheduler

addEntry()deleteEntry()reSchedule()

QueryManager


(f rom queries)

FileWriter

fileNamequeryIdelementsToExtractList

saveValuesToFi le()saveQueryStringToFile()

(f rom f ile)

get query results

Eventlong delayquerydate : Datetime : Time

run()schedule()reSchedule()

1 0..*1

+pool of

0..*

holds

uses

save values to disk

Figure 5-213 - BatchProcessing component class diagram


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxv

5.7 DEBAT Utilities

5.7.1 Type

The Utilities component is composed of three components as shown in the following decomposition view:

Utilities<<Sy stem>>

Ascii Dump<<Component>>

Data Checker

<<Component>>

Comparison tool

<<Component>>

Figure 5-214 Utilities Component Decomposition view

The Utilities component is implemented in the utilities.* package.

uti l ities(from debat)

asciiDump dataChecker comparisonTool

Figure 5-215 Utilities Component Packages view

The following table shows the mapping between the logical decomposition of the component and the packages that implements the component.


Data Checker Verifies if a data product is compliant with its associated EAST description.

utilities.asciiDump.*

Ascii Dump Generates an ASCII representation of a data product in a simple tabular form or in XML.

utilities.dataChecker.*

Comparison Tool Computes and displays the differences between two data models (XML-IF files).

utilities.comparisonTool.*


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxvi


SR323_UT Conformity: CSR325_UT Conformity: CSR326_UT Conformity: CSR341_UT Conformity: CSR358_UT Conformity: CSR333_UT Conformity: C SR334_UT Conformity: CSR335_UT Conformity: CSR336_UT Conformity: CSR337_UT Conformity: CSR338_UT Conformity: CSR339_UT Conformity: CSR340_UT Conformity: C

5.7.3 Function

The Utilities component comprises mainly utility programs provided by default (such as the Ascii dump and the Data checker) or plug-ins provided by users.They are mainly standalone tools that can be run through a MMI or directly from the command line.

Three utilities are provided by default: the Ascii dump component, the Data checker component and a Comparison tool.

The Ascii dump is a small utility used to generate an ascii representation of a data product in a simple tabular form or in XML. This capability is often used for debugging purposes.

The Data checker is a standalone tool that takes as input a data product and an EAST description and is able to verify if the data product conforms to the given EAST description.

The Comparison tool is primarily intended to compute and display the differences between two data models.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxvii

5.7.4 Dependencies





EAST serv ices : dump/check


creates XML v iews

Figure 5-216 Utility component dependency view

The Utilities component relies on the General Feature component for installation, internationalisation, and on line help. It implements the PluginInterface provided by the Plug-in system of the Integrated Environment component. It also uses the Project Management component of the Integrated Environment to access the project organisation of the file system.

The Utilities component relies on the EAST core component: To perform the dumping (in text or XML) of a data file (Ascii dump component).

To implement the checking capabilities of the Data checker.

The Ascii dump component is used by the Data Extractor & Querying component to create XML views of the data products.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxviii

5.7.5 Interfaces


EAST description<<EAST Fi le>>

data<<Data File>>

XML-IF<<XML File>>

text dump<<Text File>>

xml dump<<XML File>>


dif f erence f ile<<XML File>>

Figure 5-217 Utilities component interfaces

The Ascii dump component takes as input an EAST description file, reads the data file, and generates a text dump or an XML dump of the data file.

The Data checker component takes as input an EAST description file, reads the data file, and generates a file containing the checking results.

The Comparison tool component reads two XML-IF data models and generates an XML file that describes the differences between the two models taken as input.

5.7.5.1 Data checker component

5.7.5.1.1 TypeThe Data checker component is implemented in the utilities.dataChecker.* package.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxix

uti l ities(from debat)

dataChecker

objects(f rom dataChecker)

gui(f rom dataChecker)

Figure 5-218 Data checker component package view



utilities.dataChecker.* High level and services classes DataCheckerDataCheckerServicesInterface

utilities.dataChecker.objects.* Business classes DataCheckerWrapperutilities.dataChecker.gui MMI classes DataCheckerFrame

DataCheckerResultsFrame


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxx

5.7.5.1.2 PurposeSatisfy: SR324_UT Conformity: C

SR342_UT Conformity: CSR343_UT Conformity: CSR344_UT Conformity: CSR345_UT Conformity: CSR346_UT Conformity: CSR347_UT Conformity: CSR348_UT Conformity: CSR349_UT Conformity: CSR350_UT Conformity: CSR351_UT Conformity: CSR352_UT Conformity: CSR353_UT Conformity: CSR354_UT Conformity: CSR355_UT Conformity: CSR356_UT Conformity: CSR357_UT Conformity: C

5.7.5.1.3 FunctionThe Data checker reads the EAST description, reads the data product, and verifies that the data product conforms to the data description.It generates a file that contains the results of the checking. This file is then displayed to the user.

Figure 5-219 Data checker functional logic

5.7.5.1.4 DependenciesThe Data checker component uses the General features component (internationalisation, installation, online help). It implements the PluginInterface provided by the Plug-in system component. It uses the Project Management component to access the file system.

It relies on the EAST core component (Interpreter class of the Java API component) to perform the checking of the data.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxi





PluginInterface


(from interface)



(from projectMgt)DataChecker

check()

(f rom dataChecker)

DataCheckerWrapper

check()loadEASTdescription()readDataFile()generateCheckResults()

(from objects)

1

11

1



Interpreter

start, selectDDR, selectDataProduct, checkNextRecordFromFile

Figure 5-220 Data checker component dependency view


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxii



DataCheckerServ icesInterf ace

check()

(from dataChecker)

DataCheckerWrapper


(from objects)

DataChecker

check()

(f rom dataChecker)

f orward call

1

1

1

1

This serv ices interf ace can be used by the other tools / plug-ins

EAST description

(f rom dataChecker)

<<EAST Fi le>>

data(f rom dataChecker)

<<Data File>>

check resul ts(f rom dataChecker)

<<Text Fi le>>

load

read

generates

Figure 5-221 Data checker component interfaces

5.7.5.1.6 ProcessingThe DataCheckerWrapper class is in charge of loading the EAST description, reading the data product and launching the checking process.

The DataCheckerFrame allows selecting the EAST description, the data file, and the path to the results file.

The DataCheckerResultsFrame displays the results to the user in a text area.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxiii

DataCheckerWrapper


(from objects)

DataChecker

check()

1

1

1

1

DataCheckerFrame

show()

(from gui)

DataCheckerResultsFrame

show()

(from gui)

display

displayforward call

User

Figure 5-222 Data checker class diagram

The next diagram shows how the various components interact when a user launches a checking process.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxiv

: User : DataCheckerFrame : DataChecker : DataCheckerWrapper : Interpreter : DataCheckerResultsFrame

check

check( )

check( )

loadEASTdescription( )

start( )

selectDDR( )

selectDataProduct( )

readDataFile( )

checkNextDataBlockFromFile( )for each data block

generateCheckResults( )

show( )

Figure 5-223 Data checking sequence diagram

5.7.5.1.7 Sketches of the GUIThe following picture is a sketch of the DataCheckerFrame.

Figure 5-224 DataCheckerFrame

5.7.5.2 Ascii dump component


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxv

5.7.5.2.1 TypeThe Ascii dump component is implemented in the utilities.asciiDump.* package.

uti lities(from debat)

asciiDump

gui(f rom asciiDump)

objects(f rom asciiDump)

Figure 5-225 Ascii dump component package view



utilities.asciiDump.* High level and services classes AsciiDumperAsciiDumpServicesInterface

utilities.asciiDump.objects.* Business classes AsciiDumpWrapperutilities.asciiDump.gui.* MMI classes AsciiDumpFrame

AsciiDumpResultsFrame


SR327_UT Conformity: CSR328_UT Conformity: CSR329_UT Conformity: CSR330_UT Conformity: CSR331_UT Conformity: CSR332_UT Conformity: C

5.7.5.2.3 FunctionThe Ascii dump component reads the EAST description, reads the data product, and performs the dumping of the data product in a text or XML file. This file is then displayed to the user.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxvi

Figure 5-226 Ascii-dump functional logic

Two output modes are possible for the XML dumping: In “flat” mode, the syntactic information about the elements (i.e. paths, name, type, and

value) are stored one after the other. The relationships between these information is not directly accessible but can be retrieved using the EAST path information associated with each element of the XML file. Here is an example where the elements are stored one after the other with no relationships:

<BLOCK NUMBER= "1"><DATA NAME="ELEMENT_NAME1">

<EAST_PATH> ELEMENT EAST PATH </EAST_PATH><VALUE> VALUE IN ASCII ENCODING </VALUE>

</DATA>

<DATA NAME=" ELEMENT_NAME2"><EAST_PATH> ELEMENT EAST PATH </EAST_PATH><VALUE> VALUE IN ASCII ENCODING </VALUE>

</DATA>

<DATA>…</DATA>

</BLOCK>… and so on for all elements of the model and blocks of the data file

In "hierarchical mode", the structure of the model is kept. All syntactic information about the elements are stored in the XML file. In this case, the relationships between the elements can then be retrieved easily when manipulating the XML file.

<BLOCK NUMBER= "1"><ELEMENT NAME=”ELEMENT1” TYPE = "RECORD" PATH="ELEMENT_PATH">

<ELEMENT NAME=”ELEMENT2” TYPE="INTEGER" PATH="ELEMENT_PATH">VALUE

</ELEMENT><ELEMENT NAME=”ELEMENT3” TYPE="RECORD" PATH="ELEMENT_PATH">

<ELEMENT NAME= "… " TYPE="…" PATH="…">….

</ELEMENT></ELEMENT>…

</ELEMENT></BLOCK>In both modes, the XML view file is created upon the whole data file. However, the user can change this to transform only a subset of this file by specifying the blocks to transform. It can be


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxvii

one or more ranges of block number, a list of blocks or a frequency (in this case blocks are processed every N blocks, N being the frequency chosen by the user).

5.7.5.2.4 DependenciesThe Ascii dump component uses the General features component (internationalisation, installation, online help). It implements the PluginInterface provided by the Plug-in system component. It uses the Project Management component to access the file system.

It relies on the EAST core component (Interpreter class of the Java API component) to perform the dumping of the data.





PluginInterface


(from interface)



(from projectMgt)



AsciiDumpWrapper

dumpToText()dumpToXML()

(from objects)

AsciiDumper(f rom asciiDump)

1 11 1

Interpreter

dump, dumpToXML

Figure 5-227 Ascii dump component dependencies


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxviii



AsciiDumpServ icesInterf ace

dump()dumpToXML()

(from asci iDump)This interf ace can be used by the other tools / plug-ins

AsciiDumpWrapper

dumpToText()dumpToXML()loadEASTdescription()readDataFile()

(from objects)

AsciiDumper

dump()dumpToXML()

(f rom asciiDump)

f orward call

1

1

1

1EAST description

(f rom asciiDump)

<<EAST Fi le>>

data(f rom asciiDump)

<<Data File>>

load

read

text dump(f rom asciiDump)

<<Text File>> xml dump(f rom asciiDump)

<<XML File>>

generatesgenerates

Figure 5-228 Ascii dump component interfaces

5.7.5.2.6 ProcessingThe AsciiDumpWrapper class is in charge of loading the EAST description, reading the data product and launching the dumping process.

The AsciiDumpFrame allows selecting the EAST description, the data file, the output mode (text or XML) and the path to the output file.

The AsciiDumpResultsFrame displays the results to the user in a text area.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxix

AsciiDumpWrapper

dumpToText()dumpToXML()loadEASTdescription()readDataFile()

(from objects)

AsciiDumper

dump()dumpToXML()

1

1

1

1

AsciiDumpFrame

(from gui)

AsciiDumpResultFrame

(from gui)

User

display

display

f orward call

Figure 5-229 Ascii dump class diagram

The next diagram shows how the various components interact when a user launches a “dump to XML” process.

: User : AsciiDumpFrame : Asci iDumper : AsciiDumpWrapper : Interpreter : AsciiDumpResultFrame

"dump to XML"

dumpToXML( )

dumpToXML( )

dumpToXML( )

show( )

Figure 5-230 Ascii dump sequence diagram


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxx

5.7.5.2.7 Sketches of the GUIThe following picture is a sketch of the AsciiDumpFrame.

Figure 5-231 AsciiDumpFrame

5.7.5.3 Comparison tool

5.7.5.3.1 TypeThe Comparison tool component is implement in the utilities.comparisonTool.* package.

uti lities(from debat)

comparisonTool

objects(f rom comparisonTool)

gui(f rom comparisonTool)

Figure 5-232 Comparison tool package viewThe following table shows the contents of each package and the classes that are part of it.


utilities.comparisonTool.* High level and services classes ComparatorComparatorServicesInterface

utilities.comparisonTool.objects.* Business classes XMLDiffDifference

utilities.comparisonTool.gui.* MMI classes ComparatorFrameComparatorResultsFrame


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxxi


SR359_UT Conformity: CSR360_UT Conformity: CSR361_UT Conformity: CSR362_UT Conformity: CSR363_UT Conformity: CSR364_UT Conformity: C

5.7.5.3.3 FunctionThe Comparison tool component reads the two data models (XML-IF files), computes the differences between the models and generates an XML file that describes the differences between the two inputs. This file is then displayed to the user.

Figure 5-233 Comparison tool functional logic

5.7.5.3.4 DependenciesThe Comparison tool component uses the General features component (internationalisation, installation, online help). It implements the PluginInterface provided by the Plug-in system component. It uses the Project Management component to access the file system.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxxii





(from projectMgt)


PluginInterface


(from interface)

Comparison tool<<Component>>

Comparator(f rom comparisonTool)

Figure 5-234 Comparison tool component dependencies


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxxiii


Comparison tool<<Component>>

ComparatorServ icesInterf ace

compare()

(from comparisonTool)

Comparator

loadDataModels()computeDif f erences()generateDif f erencesFile()

(f rom comparisonTool)

f orward call

XML-IF(f rom comparisonTool)

<<XML Fi le>>2 1

difference file(f rom comparisonTool)

<<XML Fi le>>

generates

This interf ace can be used by the other tools /plug-ins

Figure 5-235 Comparison tool component interfaces

5.7.5.3.6 ProcessingThe Comparator class is in charge of loading the data models, calling the XMLDiff class that computes the differences, and generating the XML difference file.

The ComparatorFrame allows selecting the data models and the path to the output file.

The ComparatorResultsFrame displays the results to the user in a text area.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxxiv

Comparator

loadDataModels()computeDif f erences()generateDif f erencesFile()

XMLDiff

computeDif f erences()

(from objects)

Difference

ty pelocat iontext$ ADD$ REMOVE$ UPDATE

(f rom objects)

0..*

11

0..*

uses

ComparatorFrame

show()

(from gui)ComparatorResultsFrame

show()

(from gui)

displays displaysforrward cal l

User

Figure 5-236 Comparison tool class diagram

5.7.5.3.7 Sketches of the GUIThe following picture is a sketch of the ComparatorFrame.

Figure 5-237 ComparatorFrame


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxxv

5.8 DEBAT Post Processing Tools

5.8.1 Type

The Post-Processing Tools component is composed of three components as shown in the following decomposition view:


2D Visualisation Tool<<Component>>

Quick look generator<<Component>>

Data transformer

<<Component>>

Figure 5-238 Post-Processing Tools component decomposition view

The Post-Processing Tools component is implemented in the ppt.* package.

ppt(from debat)

2d quicklook dataTransf ormer

Figure 5-239 Post-Processing Tools component package view



2D visualisation tool Provides a tool to plot/visualise data contained in a data product.

ppt.2d.*

Quick-look generator Provides a tool able to generate quick-look images.

ppt.quicklook.*

Data transformer Provides a tool to transform raw binary data into XML.

ppt.dataTransformer.*


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxxvi


SR375_DEBAT Conformity: C

5.8.3 Function

The Post-Processing tools component provides functions that are mainly applied after the data has been processed.

It comprises three components: A customisable 2D visualisation tool able to plot the data contained within a data

product.

A Quick-look generator able to generate quick-looks from raw image data.

A Data transformer able to transform raw binary data products into XML documents in a customisable way.

5.8.4 Dependencies

The next diagram shows the dependencies between the Post-processing tools component and the other components of DEBAT.

The Post-Processing tools component uses:

The EAST core component to generate quick-look images (Quick-look generator component) and to perform the transformation of raw data into XML (Data transformer component).

The JClass chart library (as a jar archive file) to implement the plotting capabilities of the 2D visualisation component.

The Integrated Environment component to access the virtual organization of the file system (Project Management component). The Post-Processing tools component also implements the PluginInterface defined by the Plug-in System component.

The General features component for online help, internationalisation, installation, print and screenshot functions.

External Quick-look generators to perform the generation of the quick-look images.

The Post-Processing tools component is used by the Data Extractor & Querying component that uses it to transform raw data into XML.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxxvii



EAST serv ices: quick look generation/transf orm to XML




transform to XML

Quick-look generator<<COTS>>

uses

JClass Chart<<JAR File>>

uses

Figure 5-240 Post-Processing Tools component Dependencies

5.8.5 Interfaces

The Post-processing tools component has the following interfaces: 2D visualisation component:

It reads/saves the graphs definitions that are stored in text files.

It loads the data to plot from “static” data (i.e. data files or databases).

It loads “live” data directly from memory.

It generates jpeg/png image files.

Quick look generator component:

It reads the raw data from where the quick-look data has to be extracted.

It reads the EAST description corresponding to the data to be read.

It generates quick-look images.

Data transformer component:

It reads the raw data to transform to XML.

It reads the EAST description corresponding to the data to be read.

It reads a configuration file that described how the transformation has to be done.

It generates the XML file resulting from the transformation.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxxviii


Graph def initions<<Text Fi le>>

jpeg, png f ile<<Image f ile>>

fi le, DB<<Static data>>

memory<<Liv e data>>

load

load

raw data<<Data File>>

quick-look image<<Image fi le>>

read

save

export

generate

read

0..n

Data transf ormer conf iguration<< Text File>>

read


read

XML data<<XML File>>

generate

Figure 5-241 Post-processing tools interfaces

5.8.5.1 2D visualisation tool component

5.8.5.1.1 TypeThe 2D visualisation component is implemented in the ppt.2d.* package.

ppt(from debat)

2d

gui(from 2d)

objects(from 2d)

Figure 5-242 2D visualisation component packages view



Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cclxxxix


ppt.2d.* High-level classes ChartManagerDataLoader2DServicesInterface

ppt.2d.objects.* Business object ChartChartDefGraphSetGraphSetDefGraphGraphDef

ppt.2d.gui MMI classes MainFrameChartFrameGraphSetFrameGraphFrame

5.8.5.1.2 PurposeSatisfy: SR365_PPT Conformity: C

SR366_ PPT Conformity: CSR367_ PPT Conformity: CSR368_ PPT Conformity: CSR369_ PPT Conformity: CSR370_ PPT Conformity: C

5.8.5.1.3 FunctionThe 2D visualisation component supports lines, pies, bars, and scatters plots. It offers graph manipulation capabilities (zoom and translations) and supports multi-axes graph sets. The following chart properties can be configured through a GUI: axes, colours, line styles, symbol styles, sizes.It allows printing and exporting the graphics in JPEG and PNG formats, and supports static (files or databases) and dynamic data sources (data coming from the memory).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxc

Figure 5-243 2D visualisation tool functional logic

5.8.5.1.4 DependenciesThe 2D visualisation component implements the PluginInterface provided by the Plug-in system component.It uses the Project Management component to access the virtual organisation of the file system. It relies on the General features component for the common functions and uses an external library (JClass chart) for the plotting of the data.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxci

2D Visualisation Tool<<Component>>

ChartManager

load()save()

(from 2d)


Project Management(f rom Component Integrated Env ironment)

<<Component>>



(from projectMgt)

JClass Chart<<JAR File>>

uses

Plugin System(f rom Component Integrated Env ironment)

<<Component>>

PluginInterface


(from interface)

Figure 5-244 2D visualisation component dependencies


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxcii


2D Visual isation Tool<<Component>>

DataLoader

loadDataFromFile()loadDataFromDB()loadDataFromMemory ()

(from 2d)

fi le, DB<<Static data>>

memory<<Liv e data>>

load load

Graph def initions<<Text Fi le>>

jpeg, png f ile<<Image f ile>>

ChartManager

load()save()

(from 2d)uses

load save

Chart

makeAxes()makeFooter()makeHeader()makeLegend()makeBgColor()make3D()show()print()export()

(from objects)

export

0..*

1

0..*

1

2DServ icesInterf ace

showChart()printChart()exportChart()

(from 2d)

This interf ace is used by the other tools/plugins

forward cal ls

Figure 5-245 2D visualisation component interfaces

5.8.5.1.6 ProcessingThe ChartManager class is in charge of loading the definition of the graphs to display (data sources, display configuration). Once the definition loaded, it builds the graph (its loads the data through the DataLoader component) and displays it. This component is also responsible for saving the graph definitions updated by the user.

The Data loader is responsible for loading the data to populate the graphs from static or dynamic data sources. Static data sources are files or relational databases from where data can be extracted. They are said to be 'static' because they represent a persistent storage of data. Dynamic/"Live" data sources are data that are not persistent, and are in memory only a given time.

A Chart object is composed of GraphSet objects; each of them being composed of several Graph objects. A Chart is defined by a ChartDef object; a GraphSet by a GraphSetDef; and a Graph by a GraphDef object. The Chart, GraphSet, and Graph objects hold the data values whereas the ChartDef, GraphSetDef, and Graph objects holds the ‘visual’ properties of the objects (e.g. legend, line styles, symbols, sizes, etc.).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxciii

DataLoader

loadDataFromFile()loadDataFromDB()loadDataFromMemory ()

ChartManager

load()save()

uses

MainFrame(from gui)

displays

GraphSet

GraphSet()getGraphAt()setGraphAt()getGraphs()getGraphsNumber()setValueLabels()getValueLabels()

(from objects)

Graph

Graph()setCoordsX()getCoordsX()setCoordsY()getCoordsY()

(f rom objects)

0..*

1

0..*

1has

Chart


(from objects)

1

0..*

1

0..*

holdsshows

0..*

1

0..*

1

has

ChartDef

headerSize : intf ooterSize : intlegend : booleanlegendPosition : int

(from objects)

defines

GraphDef

colX : intcolY : intlineSty le : intlineWidth : intsy mbolSty le : intsy mbolSize : intsourceX : intsourceY : int

(from objects)

GraphSetDef

chartTy pe : intlabels : booleanminX : doublemaxX : doublenumSpacingX : doubletickSpacingX : doubleprecisionX : intminY : doublemaxY : doublenumSpacingY : doubletickSpacingY : doubleprecisionY : intlineSty leX : intlineSty leY : int

(from objects)

1

0..*

1

0..*

has

defines

1

0..*

1

0..*

has

defines

Figure 5-246 ChartManager class diagram

The graphical interface is providedGUI is divided into two parts: the Display GUI and the Graph Edition GUI.The Display GUI is in charge of displaying the graphs and providing the user with full control on the graph (zoom, translations, resizing…)The Graph Edition GUI allows the user to change the graph definition (data sources, axes, colours, fonts, symbols, size, etc.) and forwards the changes to the Graph Set manager component.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxciv

GraphFrame

show()

GraphSetFrame

show()

ChartFrame

show()

Chart


(from objects)

MainFrame

1

1

1

1display

1

1

1

1

display

1

1

1

1

displayshows

Figure 5-247 MainFrame class diagram

5.8.5.1.7 Sketches of the GUIThe MainFrame displays the list of the charts, graph sets, and graphs. When a chart is selected in the chart list, the graph set list displays the list of the graph sets composing the chart. When a given graph set is selected, the graph list of the graph set is displayed in the graph list.

Figure 5-248 2D visualisation tool MainFrame

The ChartFrame is displayed to the user to create or modify a chart. It allows configuring the chart name, the header (title, background, foreground, size), the footer and the legend.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxcv

Figure 5-249 2D visualisation tool ChartFrame

The GraphSetFrame is displayed to the user for creating or editing a GraphSet. It allows specifying the properties of the X/Y axes.

Figure 5-250 2D visualisation tool GraphSetFrame

The GraphFrame allows defining the data sources, and the line/symbol style.

Figure 5-251 2D visualisation tool GraphFrame


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxcvi

5.8.5.1.8 Menu treesThe following functions are available from the menu bar of the MainFrame.


File Show Displays the selected chart in a new frame

Edit Edit the chart definition fileSave Save the selected chart

Save As Save the selected chart with a new namePrint Print the selected chart

Export Export the selected chart to jpeg or pngExit Exit the tool

Furthermore, the user has the ability to create a new chart/graph set/graph (New button), edit the selected chart/graph set/graph (Edit button) and delete the selected chart/graph set/graph (Delete button).

5.8.5.2 Quick-look generator

5.8.5.2.1 TypeThe Quick look generator component is implemented in the ppt.quicklook.* package.

ppt(from debat)

quicklook

objects(f rom quicklook)

gui(f rom quicklook)

Figure 5-252 Quick look generator component package view



ppt.quicklook.* High level and services classes

QuickLookGeneratorQuickLookGeneratorServicesInterface


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxcvii


ppt.quicklook.objects.* Business classes QuickLookWrapperppt.quicklook.gui.* MMI classes QuickLookGeneratorFrame


SR372_ PPT Conformity: CSR373_ PPT Conformity: C

5.8.5.2.3 FunctionThe Quick look generator component is able to read a raw image data and to generate the corresponding quick-look image. It uses the data extraction capabilities of EAST to extract the bytes of the raw image data from a data product (an EAST path is used to indicate the “location” of the raw image data), and launches an existing quick look executable able to generate the quick-look starting from the extracted data (the choice of the existing quick look executable is configurable).

Figure 5-253 Quicklook generator component functional logic

5.8.5.2.4 DependenciesThe Quick look generator component uses the General features component (internationalisation, installation, online help). It implements the PluginInterface provided by the Plug-in system component. It uses the Project Management component to access the file system.

It relies on the EAST core component (Interpreter class of the Java API component) to read the EAST description and associated data product, and to extract the raw image data.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxcviii



QuickLookGenerator

loadEASTdescription()extractData()generateQuickLook()

(from quicklook)



Interpreter


Project Management(f rom Component Integrated Env ironment)

<<Component>>

uses



(from projectMgt)

Plugin System(f rom Component Integrated Env ironment)

<<Component>>

start, selectDDR, selectDataProduct, getDataEntity Binary

launch

PluginInterface


(from interface)

Figure 5-254 Quick look generator component dependencies


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccxcix



raw data<<Data File>>


quick-look image<<Image fi le>>

QuickLookGenerator


(from quicklook)read

extract

generates

QuickLookGeneratorServ icesInterf ace

generateQuickLook()

(from quicklook)

f orward call

this interf ace can be used by the other tools / plug ins

Figure 5-255 Quick look generator component interfaces

5.8.5.2.6 ProcessingThe QuickLookGenerator is in charge of loading the EAST description and the raw image data, generating the quick-look image (this function is provided by the integrated component), and launching the quick look generator executable.

The QuickLookGeneratorFrame allows: selecting the EAST description,

selecting the data product and the EAST path to the raw image data,

specifying the external quick look generator executable to use (path, arguments),

and, launching the generation process.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccc

QuickLookGenerator


QuickLookWrapper

execute()

(from objects)

1

1has

1

1


encapsulates

QuickLookGeneratorFrame

show()

(from gui)

display

forward call

User

Figure 5-256 Quick look generator class diagram

The next diagram shows how the various objects interact when a user generates a quick look image.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccci

: QuickLookGenerator : User

: QuickLookGeneratorFrame : Interpreter : QuickLookWrapper COTS : Quick-look generator

generate quick look

generateQuickLook( )


selectDDR( )

extractData( )

start( )

selectDataProduct( )

getDataEntityBinary( )

execute( )execute external quick look generator

Figure 5-257 Quick look generation sequence diagram

5.8.5.2.7 Sketches of the GUIThe following picture is a sketch of the QuickLookGeneratorFrame.

Figure 5-258 QuickLookGeneratorFrame

5.8.5.3 Data transformer

5.8.5.3.1 TypeThe Data transformer component is implemented in the ppt.dataTransformer.* package.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccii

dataTransf ormer

ppt(from debat)

gui(f rom dataTransf ormer)

objects(f rom dataTransf ormer)

Figure 5-259 Data transformer component package view



ppt.dataTransformer.* High level and services classes

DataTransformerDataTransformerServicesInterface

ppt.dataTransformer.objecs.* Business objects TransformationFilterInformation

ppt.dataTransfomer.gui.* MMI classes DataTransformerFrame


SR385_PPT Conformity: CSR387_PPT Conformity: C

5.8.5.3.3 FunctionThe Data transformer provides the ability to transform raw binary data products into XML documents in a customisable way. This feature is peculiarly useful for projects/missions that have chosen to work internally with XML, but have to face and handle other and potentially binary formats.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccciii

Figure 5-260 Data transformer component functional logic

5.8.5.3.4 DependenciesThe Data transformer component uses the General features component (internationalisation, installation, online help). It implements the PluginInterface provided by the Plug-in system component. It uses the Project Management component to access the file system.

It relies on the EAST core component (Interpreter class of the Java API component) to read the EAST description and associated data product, and to retrieve the values contained in the data product.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : ccciv

Data transformer<<Component>>




PluginInterface


(from interface)



(from projectMgt)



Interpreter

DataTransformer

loadEASTdescription()readDataFile()loadTransf ormation()transf ormToXML()

(f rom dataTransf ormer)

uses

start, selectDDR, selectDataProduct, getDataEntity Binary , getDataEntity Ascii

uses

Figure 5-261 Data transformer component dependencies


Data transformer<<Component>>

raw data(f rom dataTransf ormer)

<<Data File>>

Transf ormation def inition

(from dataTransformer)

<< Text File>>

XML data(f rom dataTransf ormer)

<<XML File>>

DataTransformer


(f rom dataTransf ormer)

EAST description(f rom dataTransf ormer)

<<EAST Fi le>>

read

read

read

generate

DataTransf ormerServ icesInterf ace

transformToXML()

(from dataTransformer)

f orward call

This interf ace can be used by the other tools / plug-ins

Figure 5-262 Data transformer component interfaces


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccv

5.8.5.3.6 ProcessingThe DataTransformer class is in charge of reading the EAST description, the raw data to transform to XML and the transformation definition that defines how the XML transformation has to be done. It performs the transformation, and generates the XML output document.

The DataTransformerFrame allows selecting the EAST description, the raw data file to transform, the transformation definition file, and launching the transformation process.

The Transformation allows users to specify how the XML output is to be generated. It permits to define the XML vocabulary to use (tags within the resulting document), to apply filters to include/exclude some elements contained within the data product, to specify which information to embed in the resulting document (element names, paths, types, bounds), or to add extra information.

DataTransf ormerFrame

show()

(from gui)

DataTransformer


displayf orward call

Filter

inclusionListexclusionList

(f rom objects)

Transformation

pathsToTagsMappingextraInf ormationpathsToInf oMapping

(from objects)

11 11

0..*

1

0..*

1

Information

includeNameincludeTy peincludeBounds

(from objects)

0..*

1

0..*

1

User

Figure 5-263 Data transformer class diagram

The next diagram shows how the various objects interact when a user generates a XML file from a data product.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccvi

: User : DataTransf ormerFrame : DataTransf ormer : Interpreter

transform to XML

transformToXML( )


loadTransf ormation( )

readDataFile( )

generateXML( )

start( )

selectDDR( )

selectDataProduct( )getDataEntityBinary( )

getDataEntityAsci i( )

At this stage, the DataTransf ormer uses the Transf ormation def inition to generate the XML

Figure 5-264 Transform to XML sequence diagram

5.8.5.3.7 Sketches of the GUIThe following picture is a sketch of the DataTransformerFrame

.Figure 5-265 DataTransformerFrame


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccvii

5.9 DEBAT Packager

5.9.1 Type

The Packager component is implemented in the packager.* package.

packager(from debat)

gui objects

Figure 5-266 Packager component package view



packager.* High level and services classes PackagerManagerPakagerServicesInterface

packager.objects.* Business objects PackagerCompressor

packager.gui.* MMI classes PakagerFrame

5.9.2 PurposeSatisfy: SR388_DIST Conformity: C

SR389_ DIST Conformity: CSR390_ DIST Conformity: CSR391_ DIST Conformity: CSR392_ DIST Conformity: C

5.9.3 Function

The Packager component is intended to provide means to enable the dissemination of data products together with their documentation and descriptions.

The Packager component provides packaging and compression capabilities to ease the dissemination of data packages (data alone, data and descriptions, data and documentation, etc.).It provides mainly the ability to package files in an archive, to compress files, and to compress an entire package

The following diagram depicts the functional logic of the Packager component:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccviii

Figure 5-267 DEBAT packager functional logic

5.9.4 Dependencies

The Packager depends on the General Features and Integrated Environment component.It does not rely on another components.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccix




PackagerManager

load()compress()package()

(f rom packager)





(from projectMgt)

PluginInterface


(from interface)

Figure 5-268 Packager component dependencies

5.9.5 Interfaces

The Packager component takes as input a set of files. It is able to compress then, and to package them in a zip or jar archive. It defines a services interface that can be called by the other tools/plug-ins of DEBAT.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccx


fi le<<File>>

compressed file<<Compressed File>>

zip / jar archiv e<<Package>>

Compressor

compress()

(f rom objects)

Packager

package()

(f rom objects)

PackagerManager


(f rom packager)

1..n

1

1

1

1

1

1

1

1

PackagerServ icesInterf ace

compress()package()

(from packager)

forward calls

This interf ace can be called by the other tools / plug-ins

Figure 5-269 Packager component interfaces

5.9.6 Processing

The PackagerFrame allows the user to select the files to compress/package (models, data products, EAST and DEDSL documentation, etc.) and to launch the packaging/compressing process.

The PackagerManager is in charge of loading the files, compressing and packaging files in zip or jar archives. This tacks is achieved by calling the appropriate methods of the Packager or Compressor classes.

The compression and packaging mechanisms are implemented with the built-in mechanisms of Java that supports the zip and jar formats.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxi

PackagerFrame

show()

(from gui)

User

Packager

package()

(f rom objects)

PackagerManager


displays

forward call

1

1

Compressor

compress()

(f rom objects)

1

1

1

1

1

1

Figure 5-270 Packager class diagram


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxii

5.10 Web

5.10.1 Type

The Web component of the DEBAT environment is composed of two components as shown in the following decomposition view:

Web<<component>>

Web services<<Component>>


Figure 5-271 Web Components decomposition view

The web functionalities are implemented in the web.* package.

services

web(from debat)

site

Figure 5-272 - Web component package decomposition


Web site Provides services to users using a simple browser as interface.

web.site.*

Web Services Provides services that are used by remote applications and the web site to provide all the functionalities to the users.

web.services.*

5.10.2 Function

The Web interface gathers the Web services and the local Web site which both are intended to provide remote access to a subset of the DEBAT functions whatever the target platform and without


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxiii

any specific installation of DEBAT. On one hand, the Web services enable remote client applications to request some of the DEBAT functions through a SOAP interface. On the other hand, the local Web site is intended to provide users with a graphical access to some of the DEBAT functions using a Web browser as interface.

Web services are server-side components that can be requested by a remote client application. The DEBAT Web services are thus used as interfaces (or access points) between remote application and the EAST core functions.

Figure 5-273 DEBAT Web Services

The local Web site provides remote users with a graphical interface (displayed in a Web browser) that is intended to provide an easy access to some of the DEBAT functions by masking the functions calls to users.

The web services and the local web site are based on common components to request the EAST core functions. These components are grouped in the web services component.The table below summarises the available functions from the web site and from the web services:

Functions Web Site

Web Services

Des

crip

tions

han

dlin

g Descriptions upload and readingThis function enables client applications to upload a description (may it be in EAST or XML-IF format) on the server and to read it. In the XML case, the corresponding EAST file is automatically generated.

Description checkingIt verifies if a description is compliant with the EAST norm.

Dat

a pr

oduc

t ha

ndlin

g Data product upload and readingThis function enables client application to upload a data product and to read it (get the data values).


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxiv

Data product generationThis function provides convenient means to generate a data product that conforms to the EAST model.

Data product download This function provides the ability to download the generated data files.

Data searchThis function enables users to request data in a product. Two search capabilities are provided: existence check and values search.

ExtractionIt offers the ability to extract values from a data product and to store the extracted data in a new file.

Data product checkingThis function is intended to verify that a data product conforms to its associated description file.

XML transformationThanks to this function, a data product described with EAST can be transformed into the XML format.

Mis

cella

neou

s

User Authentication This function is used to identify the remote clients, verify that they have rights to use the other functions and insure that each user have a private files repository on the server.

Data visualisationThis function allows users to plot data stored in a data product and to display them. Several graphs are provided: bar, chart, etc.

On-line helpThis is a graphical online help accessible from a web browser.

5.10.3 Dependencies

The next diagram shows the dependencies between the Web component and the other components of DEBAT.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxv


Web<<component>>



read/generate/search/product/transform

East file generation

checks data/create XML views

Figure 5-274 Web dependencies views

The web component depends on the EAST core component to read/generate data products, process queries, check elements and validity of descriptions and read descriptions.It also depends on the modeller component to generate East file and on the utilities component to check the validity of data products and create XML views.

The next diagram shows the dependencies between the components of the Web component.






uses services




Figure 5-275 Web internal dependencies views

The web services component has the same dependencies than the web component. The web site component depends on the web services component to execute actions with the other components.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxvi

5.10.4 Interfaces

XML IF<<XML file>>

XML Data<<XML file>>

Extracted data<<DATA file>>

Data<<DATA file>>

EAST file<<ADA File>>

Web<<component>>

Read

Read

Read

Generate

create create

Generation directives<<TEXT file>>

create

Figure 5-276 Web component interfaces

The Web component has the following interfaces: It reads XML-If files and EAST files.

It reads data products after reading associated descriptions.

It generates data

It creates XML data and extracted data.

It creates directives files.

5.10.5 Processing

The software architecture of the web interface is based on the n-tiered principle. The different components of the web interface are identified to be in a particular tier according to their context.Each tier is independent and can easily be updated or changed with no impact on the others. Thus, it is possible to choose the best technical solutions for each component, independently.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxvii

Figure 5-277 Local Web Site global software architecture

On the client side, there is an application that requests services provided by the server. The communication protocol between the client application and the server is HTTP with XML encoded information (SOAP).

In the “Local web site” context, it is a web browser that displays data products and EAST models and that enables users to perform any of the actions presented in the previous section. Information is displayed either in html pages (in the case of static information such as the web site navigation tree or the online help consultation) or by a Java applet (in the case of dynamic content). Thanks to the Java features and capabilities, the applet provides a high level of interactivity and ergonomics. The client is “light” to minimise the download time required to use the system.The applet provides almost every functions accessible from the web site: EAST description upload and display, data generation, data reading and display, data search and extraction, data checking, XML transformation and finally data visualisation.

The server side is composed of three tiers as described in the figure above. The Web-server tier is a servlet/JSP engine named Tomcat (version 4.0) of the Apache

Software Foundation that handles communication between the client and the server. This free server has the following advantages: easy to install and maintain, reliable and secure. The servlet and JSP are able to treat user HTTP requests and to dynamically generate responses to the client. The SOAP requests are handled by AXIS (Apache project) that is a servlet that routes the SOAP messages between clients and the web services.

The application server tier is the software layer that monitors and manages the application components and their interactions. In particular it manages data products and EAST models: data generation, data checking, data search and extraction, etc. It comprises the EAST core and its Java API.

The session tier encapsulates a single session, which will typically be tied to a single user. This tier is responsible for the management of the user-dedicated workspace,

The data management tier is simply a file system where data products and EAST models are stored.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxviii

5.10.5.1 Services component

5.10.5.1.1 TypeThe web services component is composed of three components as shown in the following decomposition view :


User Authentication<<Component>>

Web services Interfaces<<component>>

Debat services interface<<component>>

Figure 5-278 Web Services Components decomposition view

The web services functionalities are implemented in the web.services.* package.

web(from debat)

services

debatServicesInterfacewebServices authentification

Figure 5-279 – Web services component package decomposition


web.services.webServices.* Contains all web services classes

DebatWebServices.

web.services.debatServicesInterface.* Contains all classes that execute DEBAT functionalities.

DebatServices.

web.services.authentication.* Contains classes that provide UserAuthentication.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxix


the remote users authentication.

5.10.5.1.2 Purpose Satisfy: SR78_WEB Conformity: C

SR97_WEB Conformity: CSR98_WEB Conformity: CSR99_WEB Conformity: CSR100_WEB Conformity: CSR101_WEB Conformity: CSR102_WEB Conformity: CSR103_WEB Conformity: CSR104_WEB Conformity: C SR105_WEB Conformity: C

5.10.5.1.3 FunctionThe Web services are just a facade to the EAST core functions. The role of the Web services is:

On one side, to decode the client applications requests and call the corresponding methods of the EAST core.

On the other side, to get the results of the EAST core processing and render it to the client application in an understandable format.

5.10.5.1.4 DependenciesThe following diagram shows the dependencies between the web services sub-components:


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxx


Debat services interface

<<component>>User Authentication

<<Component>>

Web services Interfaces<<component>>

EAST core<<Component>> Utilities

<<Component>>

usescalls




Figure 5-280: Services component internal dependencies.

The Debat services interfaces the User authentication component to authenticate remote users and the web services interfaces to use the DEBAT functionalities.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxi


create

XML IF<<XML file>>



Data<<DATA file>>

EAST file<<ADA File>>


ReadRead

Read

create create

generate


Figure 5-281 Web Services component interfaces

The Web services component has the following interfaces: It reads XML-If files and EAST files.


It generates data


It creates directives files.

5.10.5.1.6 ProcessingWeb Services are functions that can be called through the Web. "Web services" concept defines an architecture based on a transport protocol (XML/SOAP) and on "service descriptions" formalised in WSDL that can be declared in registries called UDDI:

SOAP (Simple Object Access Protocol) is a specialised XML format that facilitates the exchange of messages in an asynchronous, platform neutral manner.

WSDL (Web Services Description Language) allows to describe what a web service is capable of and how it can be located and invoked.

UDDI (Universal Description Discovery and Integration) allows to search for available web services by querying a Web service registry. It defines a standard mechanism for publishing and locating the existence of businesses and the services they provide. This


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxii

registry manages automatic addition and publishing, maintenance (update), removal of services.

The DebatServices class contains functions that can be used by remote applications. The following table describes these functions.

Function Purpose

checkData() This function is used to verify that the data products are valid instances of their associated EAST description.

generateData() This function is used to generate data values to create new data products

checkDescription()This function verifies that a description is valid against its norm. For XML IF, the validation will take place against the XML schema defined. For EAST descriptions, the validation will occur against the EAST norm.

readData() This function is exploited to read the content of the data products (previously uploaded on the server).

checkExistence() This function is used to verify that a particular element exist in a data product.

processQuery() This function is used to process the queries and extract the associated results. It is used for extraction purposes.

readEastDescription This function is used to read the EAST descriptions.readXmlIfDescription This function is used to read the XML-IF descriptions.generateXml() This function generates an XML view of a particular data product.uploadFile This function is used to upload the files to the server (users must be

authenticated first).downloadFile() This function is used to download the files from the server (users

must be authenticated first).userAuthenticate() This function is used to identify the users that want to access the

web services.search() This function is used to search element in the data product by type

and by name.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxiii

QueryManager


(from queries)






loadXmlIf()loadEastFile()loadOasisIf()...




DataGenerator

startSequenceRecording()...stopSequenceRecording()...removeSequence()...

Interpreter

selectDDR()setOnDDR()focusOn()...

UserAuthentication

authenticateUser()

DebatWebServices

checkData()generateData()checkDescription()readData()checkExistence()processQuery()readEastDescription()readXmlIfDescription()generateXml()uploadFile()downloadFile()userAuthenticate()search()


check()

AsciiDumpServicesInterface

dump()dumpToXML()

DebatServices


generate data

checks existence

read data product

check EAST descriptions

read EAST description

Authenticate users

uses

check data create xml view


loadXmlIf()loadEastFile()loadOasisIf()...

generateEastFile

readXmlIfDescription

QueriesHandler

analyseQuery()nextDataRecords()......

(from Component Java API)...)

process queries

Figure 5-282: Web services class diagram

5.10.5.2 Web Site component

5.10.5.2.1 TypeThe web site component is composed of three components as shown in the following decomposition view :


Applet<<Component>>

Server<<Component>>

Help<<Component>>

Figure 5-283 Web site Components decomposition view


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxiv

The web services functionalities are implemented in the web.site.* package.

web(from debat)

site

applet serveronlineHelp

gui dataManager

Figure 5-284 – Web site component package decomposition


web.site.onlineHelp.* Contains all help files Html files.web.site.applet.gui.* Contains all classes that provide

the graphical part of the applet.Panels files .

web.site.applet.dataManager.* Contains all classes that provide the data management in the applet.

DataManager, DataModel.

web.site.server.* Contains classes that provide the server. The server get the client (applet) request and execute actions on the East core.

HttpServer.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxv

5.10.5.2.2 Purpose Satisfy: SR79_WEB Conformity: C

SR80_WEB Conformity: CSR81_WEB Conformity: CSR82_WEB Conformity: CSR83_WEB Conformity: CSR84_WEB Conformity: CSR85_WEB Conformity: CSR86_WEB Conformity: CSR87_WEB Conformity: CSR88_WEB Conformity: CSR89_WEB Conformity: CSR90_WEB Conformity: CSR91_WEB Conformity: CSR92_WEB Conformity: CSR93_WEB Conformity: CSR94_WEB Conformity: CSR95_WEB Conformity: CSR96_WEB Conformity: C

5.10.5.2.3 FunctionThe figure below presents the logical model of the local web site. The boxes represent the web pages displayed to users in the browser while the diamonds depict the available functions.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxvi

Figure 5-285 Local Web Site logical model

It is to be noted that there are two different kinds of users : administrators and users. The only difference between the two lies in the fact that administrators can register and remove users. Then, users won’t be able to use the web site functionalities if the administrators have not registered them first.

5.10.5.2.4 DependenciesThe following diagram shows that the web site component depends on the web services component.


uses servicesWeb Site<<Component>>

Figure 5-286: Services component internal dependencies.


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxvii




Data<<DATA file>>

XML IF<<XML file>> Read Create

Generate data fileRead data file


Create


Extract values

Figure 5-287 Web site component interfaces

The Web component has the following interfaces: It reads XML-If files.


It generates data


It generates directives files.


The onelineHelp component contains the online help that is made by HTML pages.The server component contains a main class the HTTPserver class that provides a HTTP server where the applet is connected to transfer data and requests.The applet component contains all Java GUI panels needed to provide the following user interfaces, these panel are similar to the DPE, DEQ and the 2D visualization tool:

Generator Panel

Search Panel

Extractor Panel

Checking Panel

XML Transformation Panel


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxviii

Data Plotter Panel

All of theses panels are managed by a DebatApplet class.The AppletDataManager and DataModel classes represent the data objects load in the memory. This classes are similar to the modeler component classes.

The following class diagram represents the links between the applet component classes and the server class.

GeneratorPanel

SearchPanel

ExtractorPanel

CheckingPanel

XmlTransformationPanel

DataPlotterPanel

DataModelroot


DebatApplet

11

11

1

1

1

1

11

11

11


M

AppletDataManager

createDataModel()generateData()checkData()readData()checkExistence()processQuery()readEastDescription()readXmlIfDescription()generateXML()uploadFile()userAuthenticate()search()

0..n1 0..n1

uses

+requests

DebatServices


HttpServer

getRequest()executeRequest()SendResponse()

communicates

uses

Figure 5-288: Web site class diagram


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxix

6. Traceability matrix

SR Id Component Chapter of ADD

SR 1 DEBAT 3. FUNCTIONAL ARCHITECTURE,SR 2 DEBAT 5.1.2 Purpose,SR 3 DEBAT 5.1.2 Purpose,SR 4 DEBAT 5.1.2 Purpose,SR 5 DEBAT 5.1.2 Purpose,SR 6 DEBAT 5.1.2 Purpose,SR 7 DEBAT 5.1.2 Purpose,SR 8 DEBAT 3. FUNCTIONAL ARCHITECTURE,SR 9 DEBAT 3. FUNCTIONAL ARCHITECTURE,SR 10 DEBAT 5.4.2 Purpose,SR 11 DEBAT 5.4.2 Purpose,SR 12 DEBAT 5.4.2 Purpose,SR 13 DEBAT 5.4.2 Purpose,SR 14 DEBAT 3. FUNCTIONAL ARCHITECTURE,SR 15 DEBAT 3. FUNCTIONAL ARCHITECTURE,SR 16 DEBAT 3. FUNCTIONAL ARCHITECTURE,SR 17 DEBAT 5.3.5.2.2 Purpose,SR 18 DEBAT 5.4.2 Purpose,5.4.6.4.2 Purpose,SR 19 DEBAT 5.4.2 Purpose,5.4.6.4.2 Purpose,SR 20 DEBAT 3. FUNCTIONAL ARCHITECTURE,SR 21 DEBAT 3. FUNCTIONAL ARCHITECTURE,SR 22 DEBAT 3. FUNCTIONAL ARCHITECTURE,SR 23 DEBAT 3. FUNCTIONAL ARCHITECTURE,SR 24 DEBAT 5.4.2 Purpose,5.6.2 Purpose,5.7.2 Purpose,5.8.2 Purpose,SR 25 DEBAT 5.1.2 Purpose,SR 26 DEBAT 5.1.2 Purpose,SR 27 DEBAT 5.1.2 Purpose,SR 28 DEBAT 5.1.2 Purpose,SR 29 DEBAT 5.1.2 Purpose,SR 30 DEBAT 5.1.2 Purpose,SR 31 DEBAT 5.2.2 Purpose,SR 32 DEBAT 5.2.2 Purpose,SR 33 DEBAT 5.4.2 Purpose,SR 34 DEBAT 5.2.2 Purpose,SR 35 DEBAT 5.2.2 Purpose,SR 36 DEBAT 5.2.2 Purpose,SR 37 DEBAT 5.2.2 Purpose,SR 38 DEBAT 5.4.2 Purpose,SR 39 DEBAT 3. FUNCTIONAL ARCHITECTURE,SR 40 DEBAT 3. FUNCTIONAL ARCHITECTURE,SR 41 DEBAT 5.1.2 Purpose,SR 43 DEBAT 5.1.2 Purpose,SR 44 DEBAT 5.1.2 Purpose,SR 45 DEBAT 5.1.2 Purpose,SR 46 DEBAT 5.1.2 Purpose,SR 47 DEBAT 5.1.2 Purpose,


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxx

SR 48 INTEGRATEDENV 5.2.5.1.2 Purpose,SR 49 INTEGRATEDENV 5.2.5.1.2 Purpose,SR 50 INTEGRATEDENV 5.2.5.1.2 Purpose,SR 51 INTEGRATEDENV 5.2.5.2.2 Purpose,SR 52 INTEGRATEDENV 5.2.5.1.2 Purpose,SR 53 INTEGRATEDENV 5.2.5.1.2 Purpose,SR 54 INTEGRATEDENV 5.2.5.1.2 Purpose,SR 55 INTEGRATEDENV 5.2.5.1.2 Purpose,SR 56 INTEGRATEDENV 5.2.5.1.2 Purpose,SR 57 INTEGRATEDENV 5.2.5.1.2 Purpose,SR 58 INTEGRATEDENV 5.2.5.1.2 Purpose,SR 59 INTEGRATEDENV 5.2.5.2.2 Purpose,SR 60 INTEGRATEDENV 5.2.5.2.2 Purpose,SR 61 INTEGRATEDENV 5.2.5.2.2 Purpose,SR 62 INTEGRATEDENV 5.2.5.2.2 Purpose,SR 63 INTEGRATEDENV 5.2.5.2.2 Purpose,SR 64 INTEGRATEDENV 5.2.5.2.2 Purpose,SR 65 INTEGRATEDENV 5.2.5.2.2 Purpose,SR 66 INTEGRATEDENV 5.2.5.3.2 Purpose,SR 67 INTEGRATEDENV 5.2.5.3.2 Purpose,SR 68 INTEGRATEDENV 5.2.5.3.2 Purpose,SR 69 INTEGRATEDENV 5.2.5.3.2 Purpose,SR 70 INTEGRATEDENV 5.2.5.3.2 Purpose,SR 71 INTEGRATEDENV 5.2.5.3.2 Purpose,SR 72 INTEGRATEDENV 5.2.5.3.2 Purpose,SR 73 INTEGRATEDENV 5.2.5.3.2 Purpose,SR 74 INTEGRATEDENV 5.2.5.3.2 Purpose,SR 75 INTEGRATEDENV 5.2.5.3.2 Purpose,SR 76 INTEGRATEDENV 5.2.5.3.2 Purpose,SR 77 INTEGRATEDENV 5.2.5.3.2 Purpose,SR 78 WEB 5.10.5.1.2 Purpose,SR 79 WEB 5.10.5.2.2 Purpose,SR 80 WEB 5.10.5.2.2 Purpose,SR 81 WEB 5.10.5.2.2 Purpose,SR 82 WEB 5.10.5.2.2 Purpose,SR 83 WEB 5.10.5.2.2 Purpose,SR 84 WEB 5.10.5.2.2 Purpose,SR 85 WEB 5.10.5.2.2 Purpose,SR 86 WEB 5.10.5.2.2 Purpose,SR 87 WEB 5.10.5.2.2 Purpose,SR 88 WEB 5.10.5.2.2 Purpose,SR 89 WEB 5.10.5.2.2 Purpose,SR 90 WEB 5.10.5.2.2 Purpose,SR 91 WEB 5.10.5.2.2 Purpose,SR 92 WEB 5.10.5.2.2 Purpose,SR 93 WEB 5.10.5.2.2 Purpose,SR 94 WEB 5.10.5.2.2 Purpose,SR 95 WEB 5.10.5.2.2 Purpose,SR 96 WEB 5.10.5.2.2 Purpose,SR 97 WEB 5.10.5.1.2 Purpose,SR 98 WEB 5.10.5.1.2 Purpose,


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxxi

SR 99 WEB 5.10.5.1.2 Purpose,SR 100 WEB 5.10.5.1.2 Purpose,SR 101 WEB 5.10.5.1.2 Purpose,SR 102 WEB 5.10.5.1.2 Purpose,SR 103 WEB 5.10.5.1.2 Purpose,SR 104 WEB 5.10.5.1.2 Purpose,SR 105 WEB 5.10.5.1.2 Purpose,SR 106 EASTCORE 5.3.2 Purpose,SR 107 EASTCORE 5.3.2 Purpose,SR 108 EASTCORE 5.3.2 Purpose,SR 109 EASTCORE 5.3.2 Purpose,SR 110 EASTCORE 5.3.5.3.2 Purpose,5.3.5.4.2 Purpose,SR 111 EASTCORE 5.3.5.1.2 Purpose,SR 112 EASTCORE 5.3.5.3.2 Purpose,5.3.5.4.2 Purpose,SR 114 EASTCORE 5.3.5.3.2 Purpose,5.3.5.4.2 Purpose,SR 115 EASTCORE 5.3.5.3.2 Purpose,5.3.5.4.2 Purpose,SR 116 EASTCORE 5.3.5.3.2 Purpose,5.3.5.4.2 Purpose,SR 117 EASTCORE 5.3.5.3.2 Purpose,5.3.5.4.2 Purpose,SR 118 EASTCORE 5.3.5.6.2 Purpose,5.3.5.6.4.2 Purpose,SR 119 EASTCORE 5.3.5.6.2 Purpose,5.3.5.6.4.2 Purpose,SR 120 EASTCORE 5.3.5.6.2 Purpose,5.3.5.6.4.2 Purpose,SR 123 EASTCORE 5.3.5.6.2 Purpose,SR 440 EASTCORE 5.3.5.6.2 Purpose,SR 124 EASTCORE 5.3.5.6.2 Purpose,SR 125 EASTCORE 5.3.5.6.2 Purpose,SR 126 EASTCORE 5.3.5.3.2 Purpose,5.3.5.4.2 Purpose,SR 127 EASTCORE 5.3.5.3.2 Purpose,SR 128 EASTCORE 5.3.5.2.2 Purpose,SR 129 EASTCORE 5.3.5.3.2 Purpose,SR 130 EASTCORE 5.3.5.3.2 Purpose,SR 131 EASTCORE 5.3.5.3.2 Purpose,SR 132 EASTCORE 5.3.5.4.2 Purpose,SR 438 EASTCORE 5.3.5.4.2 Purpose,5.3.5.6.5.2 Purpose,SR 439 EASTCORE 5.3.5.4.2 Purpose,SR 133 EASTCORE 5.3.5.4.2 Purpose,SR 134 EASTCORE 5.3.5.4.2 Purpose,SR 135 EASTCORE 5.3.5.4.2 Purpose,SR 136 EASTCORE 5.3.5.4.2 Purpose,SR 137 EASTCORE 5.3.5.3.2 Purpose,SR 138 EASTCORE 5.3.5.3.2 Purpose,SR 139 EASTCORE 5.3.5.3.2 Purpose,SR 140 EASTCORE 5.3.5.3.2 Purpose,SR 141 EASTCORE 5.3.5.3.2 Purpose,SR 142 EASTCORE 5.3.5.3.2 Purpose,SR 143 MODELLER 5.4.2 Purpose,SR 144 MODELLER 5.4.2 Purpose,SR 145 MODELLER 5.4.6.4.2 Purpose,SR 146 MODELLER 5.4.2 Purpose,SR 147 MODELLER 5.4.6.1.2 Purpose,SR 148 MODELLER 5.4.2 Purpose,SR 149 MODELLER 5.4.2 Purpose,


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxxii

SR 150 MODELLER 5.4.6.1.2 Purpose,SR 151 MODELLER 5.4.2 Purpose,SR 152 MODELLER 5.4.2 Purpose,SR 153 MODELLER 5.4.2 Purpose,SR 154 MODELLER 5.4.2 Purpose,SR 155 MODELLER 5.4.6.6.2 Purpose,SR 156 MODELLER 5.4.6.6.2 Purpose,SR 158 MODELLER 5.4.6.1.2 Purpose,SR 159 MODELLER 5.4.2 Purpose,5.4.6.3.2 Purpose,SR 160 MODELLER 5.4.6.2.2 Purpose,SR 161 MODELLER 5.4.6.2.2 Purpose,SR 162 MODELLER 5.4.6.2.2 Purpose,SR 163 MODELLER 5.4.6.2.2 Purpose,SR 164 MODELLER 5.4.6.2.2 Purpose,SR 165 MODELLER 5.4.6.2.2 Purpose,SR 166 MODELLER 5.4.6.2.2 Purpose,SR 167 MODELLER 5.4.6.2.2 Purpose,SR 168 MODELLER 5.4.6.1.2 Purpose,SR 169 MODELLER 5.4.6.1.2 Purpose,SR 170 MODELLER 5.4.6.1.2 Purpose,SR 171 MODELLER 5.4.6.1.2 Purpose,SR 172 MODELLER 5.4.6.1.2 Purpose,SR 173 MODELLER 5.4.6.1.2 Purpose,SR 174 MODELLER 5.4.6.1.2 Purpose,SR 175 MODELLER 5.4.6.1.2 Purpose,SR 176 MODELLER 5.4.6.1.2 Purpose,SR 177 MODELLER 5.4.6.1.2 Purpose,SR 178 MODELLER 5.4.6.1.2 Purpose,SR 179 MODELLER 5.4.6.1.2 Purpose,SR 180 MODELLER 5.4.6.1.2 Purpose,SR 181 MODELLER 5.4.6.1.2 Purpose,SR 182 MODELLER 5.4.6.1.2 Purpose,SR 183 MODELLER 5.4.6.1.2 Purpose,SR 184 MODELLER 5.4.6.1.2 Purpose,SR 185 MODELLER 5.4.6.2.2 Purpose,SR 186 MODELLER 5.4.6.2.2 Purpose,SR 188 MODELLER 5.4.6.2.2 Purpose,SR 189 MODELLER 5.4.6.2.2 Purpose,SR 190 MODELLER 5.4.6.2.2 Purpose,SR 191 MODELLER 5.4.6.2.2 Purpose,SR 192 MODELLER 5.4.6.6.2 Purpose,SR 193 MODELLER 5.4.6.6.2 Purpose,SR 194 MODELLER 5.4.6.7.2 Purpose,SR 195 MODELLER 5.4.6.7.2 Purpose,SR 196 MODELLER 5.4.6.5.2 Purpose,SR 197 MODELLER 5.4.6.5.2 Purpose,SR 198 MODELLER 5.4.6.5.2 Purpose,SR 199 MODELLER 5.4.6.5.2 Purpose,SR 200 MODELLER 5.4.6.5.2 Purpose,SR 201 MODELLER 5.4.6.5.2 Purpose,SR 202 MODELLER 5.4.6.5.2 Purpose,


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxxiii

SR 203 MODELLER 5.4.6.5.2 Purpose,SR 205 DPE 5.5.6.1.2 Purpose,SR 206 DPE 5.5.6.1.2 Purpose,5.5.6.2.2 Purpose,SR 207 DPE 5.5.6.1.2 Purpose,SR 208 DPE 5.5.6.1.2 Purpose,SR 209 DPE 5.5.6.2.2 Purpose,SR 210 DPE 5.5.6.1.2 Purpose,5.5.6.2.2 Purpose,SR 211 DPE 5.5.6.1.2 Purpose,SR 212 DPE 5.5.6.1.2 Purpose,SR 213 DPE 5.5.6.1.2 Purpose,SR 216 DPE 5.5.6.1.2 Purpose,SR 217 DPE 5.5.6.1.2 Purpose,SR 218 DPE 5.5.6.1.2 Purpose,5.5.6.2.2 Purpose,SR 219 DPE 5.5.6.1.2 Purpose,5.5.6.2.2 Purpose,SR 220 DPE 5.5.2 Purpose,5.5.6.1.2 Purpose,5.5.6.2.2 Purpose,SR 221 DPE 5.5.6.1.2 Purpose,SR 222 DPE 5.5.6.1.2 Purpose,SR 223 DPE 5.5.6.1.2 Purpose,SR 225 DPE 5.5.6.2.2 Purpose,SR 226 DPE 5.5.6.2.2 Purpose,SR 227 DPE 5.5.6.2.2 Purpose,SR 228 DPE 5.5.6.2.2 Purpose,SR 229 DPE 5.5.6.2.2 Purpose,SR 230 DPE 5.5.6.2.2 Purpose,SR 231 DPE 5.5.2 Purpose,5.5.6.4.2 Purpose,SR 232 DPE 5.5.6.4.2 Purpose,SR 233 DPE 5.5.6.1.2 Purpose,SR 234 DPE 5.5.6.4.2 Purpose,SR 235 DPE 5.5.6.4.2 Purpose,SR 236 DPE 5.5.6.1.2 Purpose,SR 237 DPE 5.5.6.1.2 Purpose,SR 238 DPE 5.5.6.4.2 Purpose,SR 239 DPE 5.5.6.1.2 Purpose,5.5.6.4.2 Purpose,SR 240 DPE 5.5.6.4.2 Purpose,SR 241 DPE 5.5.6.1.2 Purpose,SR 244 DPE 5.5.6.4.2 Purpose,SR 245 DPE 5.5.6.4.2 Purpose,SR 246 DPE 5.5.6.4.2 Purpose,SR 247 DPE 5.5.6.4.2 Purpose,SR 248 DPE 5.5.6.1.2 Purpose,SR 249 DPE 5.5.2 Purpose,5.5.6.5.2 Purpose,SR 250 DPE 5.5.6.2.2 Purpose,5.5.6.5.2 Purpose,SR 251 DPE 5.5.6.1.2 Purpose,SR 252 DPE 5.5.6.1.2 Purpose,SR 253 DPE 5.5.6.1.2 Purpose,SR 254 DPE 5.5.6.1.2 Purpose,SR 255 DPE 5.5.6.1.2 Purpose,SR 256 DPE 5.5.6.1.2 Purpose,SR 257 DPE 5.5.6.2.2 Purpose,SR 258 DPE 5.5.6.2.2 Purpose,SR 259 DPE 5.5.2 Purpose,5.5.6.3.2 Purpose,


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxxiv

SR 260 DPE 5.5.6.1.2 Purpose,5.5.6.3.2 Purpose,SR 261 DPE 5.5.6.3.2 Purpose,SR 262 DPE 5.5.6.3.2 Purpose,SR 263 DPE 5.5.6.1.2 Purpose,5.5.6.3.2 Purpose,SR 264 DPE 5.5.6.1.2 Purpose,5.5.6.3.2 Purpose,SR 265 DPE 5.5.6.6.2 Purpose,SR 266 DPE 5.5.6.6.2 Purpose,SR 267 DPE 5.5.6.6.2 Purpose,SR 268 DPE 5.5.6.6.2 Purpose,SR 269 DPE 5.5.6.6.2 Purpose,SR 271 DPE 5.5.6.6.2 Purpose,SR 272 DPE 5.5.6.1.2 Purpose,SR 273 DPE 5.5.6.1.2 Purpose,SR 274 DPE 5.5.6.1.2 Purpose,SR 275 DPE 5.5.6.1.2 Purpose,SR 276 DPE 5.5.6.1.2 Purpose,SR 277 DPE 5.5.6.1.2 Purpose,SR 278 DEQ 5.6.6.1.2 Purpose,SR 279 DEQ 5.6.6.1.2 Purpose,SR 280 DEQ 5.6.6.1.2 Purpose,SR 281 DEQ 5.6.6.1.2 Purpose,SR 282 DEQ 5.6.6.1.2 Purpose,SR 283 DEQ 5.6.6.1.2 Purpose,SR 284 DEQ 5.6.6.1.2 Purpose,SR 285 DEQ 5.6.6.2.2 Purpose,SR 286 DEQ 5.6.6.1.2 Purpose,SR 287 DEQ 5.6.6.1.2 Purpose,SR 288 DEQ 5.6.6.1.2 Purpose,SR 290 DEQ 5.6.6.2.2 Purpose,SR 291 DEQ 5.6.6.2.2 Purpose,SR 292 DEQ 5.6.6.4.2 Purpose,SR 293 DEQ 5.6.6.1.2 Purpose,SR 294 DEQ 5.6.6.2.2 Purpose,SR 295 DEQ 5.6.6.3.2 Purpose,SR 296 DEQ 5.6.6.3.2 Purpose,SR 297 DEQ 5.6.6.3.2 Purpose,SR 298 DEQ 5.6.6.3.2 Purpose,SR 300 DEQ 5.6.6.3.2 Purpose,SR 301 DEQ 5.6.6.3.2 Purpose,SR 302 DEQ 5.6.6.3.2 Purpose,SR 303 DEQ 5.6.6.3.2 Purpose,SR 304 DEQ 5.6.6.3.2 Purpose,SR 305 DEQ 5.6.6.3.2 Purpose,SR 306 DEQ 5.6.6.3.2 Purpose,SR 307 DEQ 5.6.6.3.2 Purpose,SR 308 DEQ 5.6.6.3.2 Purpose,SR 309 DEQ 5.6.6.3.2 Purpose,SR 310 DEQ 5.6.6.2.2 Purpose,SR 311 DEQ 5.3.5.5.2 Purpose,5.6.6.4.2 Purpose,SR 312 DEQ 5.6.6.1.2 Purpose,SR 313 DEQ 5.6.6.1.2 Purpose,


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxxv

SR 314 DEQ 5.6.6.5.2 Purpose,SR 315 DEQ 5.6.6.5.2 Purpose,SR 316 DEQ 5.6.6.5.2 Purpose,SR 317 DEQ 5.6.6.5.2 Purpose,5.6.6.6.2 Purpose,SR 318 DEQ 5.6.6.6.2 Purpose,SR 319 DEQ 5.6.6.6.2 Purpose,SR 320 DEQ 5.6.6.6.2 Purpose,SR 321 DEQ 5.6.6.7.2 Purpose,SR 322 DEQ 5.6.6.7.2 Purpose,SR 323 UT 5.7.2 Purpose,SR 324 UT 5.7.5.1.2 Purpose,5.7.5.2.2 Purpose,5.7.5.3.2 Purpose,SR 325 UT 5.7.2 Purpose,SR 326 UT 5.7.2 Purpose,SR 327 UT 5.7.5.2.2 Purpose,SR 328 UT 5.7.5.2.2 Purpose,SR 329 UT 5.7.5.2.2 Purpose,SR 330 UT 5.7.5.2.2 Purpose,SR 331 UT 5.7.5.2.2 Purpose,SR 332 UT 5.7.5.2.2 Purpose,SR 333 UT 5.7.2 Purpose,SR 334 UT 5.7.2 Purpose,SR 335 UT 5.7.2 Purpose,SR 336 UT 5.7.2 Purpose,SR 337 UT 5.7.2 Purpose,SR 338 UT 5.7.2 Purpose,SR 339 UT 5.7.2 Purpose,SR 340 UT 5.7.2 Purpose,SR 341 UT 5.7.2 Purpose,SR 342 UT 5.7.5.1.2 Purpose,SR 343 UT 5.7.5.1.2 Purpose,SR 344 UT 5.7.5.1.2 Purpose,SR 345 UT 5.7.5.1.2 Purpose,SR 346 UT 5.7.5.1.2 Purpose,SR 347 UT 5.7.5.1.2 Purpose,SR 348 UT 5.7.5.1.2 Purpose,SR 349 UT 5.7.5.1.2 Purpose,SR 350 UT 5.7.5.1.2 Purpose,SR 351 UT 5.7.5.1.2 Purpose,SR 352 UT 5.7.5.1.2 Purpose,SR 353 UT 5.7.5.1.2 Purpose,SR 354 UT 5.7.5.1.2 Purpose,SR 355 UT 5.7.5.1.2 Purpose,SR 356 UT 5.7.5.1.2 Purpose,SR 357 UT 5.7.5.1.2 Purpose,SR 358 UT 5.7.2 Purpose,SR 359 UT 5.7.5.3.2 Purpose,SR 360 UT 5.7.5.3.2 Purpose,SR 361 UT 5.7.5.3.2 Purpose,SR 362 UT 5.7.5.3.2 Purpose,SR 363 UT 5.7.5.3.2 Purpose,SR 364 UT 5.7.5.3.2 Purpose,


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxxvi

SR 365 PPT 5.8.5.1.2 Purpose,SR 366 PPT 5.8.5.1.2 Purpose,SR 367 PPT 5.8.5.1.2 Purpose,SR 368 PPT 5.8.5.1.2 Purpose,SR 369 PPT 5.8.5.1.2 Purpose,SR 370 PPT 5.8.5.1.2 Purpose,SR 371 PPT 5.8.5.2.2 Purpose,SR 372 PPT 5.8.5.2.2 Purpose,SR 373 PPT 5.8.5.2.2 Purpose,SR 375 PPT 5.8.2 Purpose,SR 384 PPT 5.8.5.3.2 Purpose,SR 385 PPT 5.8.5.3.2 Purpose,SR 386 PPT 5.4.6.5.2 Purpose,SR 387 PPT 5.8.5.3.2 Purpose,SR 388 DIST 5.9.2 Purpose,SR 389 DIST 5.9.2 Purpose,SR 390 DIST 5.9.2 Purpose,SR 391 DIST 5.9.2 Purpose,SR 392 DIST 5.9.2 Purpose,SR 393 TMTC TM-TC activities are discardedSR 394 TMTC TM-TC activities are discardedSR 395 TMTC TM-TC activities are discardedSR 396 TMTC TM-TC activities are discardedSR 397 TMTC TM-TC activities are discardedSR 398 TMTC TM-TC activities are discardedSR 399 TMTC TM-TC activities are discardedSR 400 TMTC TM-TC activities are discardedSR 401 TMTC TM-TC activities are discardedSR 402 TMTC TM-TC activities are discardedSR 403 TMTC TM-TC activities are discardedSR 404 TMTC TM-TC activities are discardedSR 405 TMTC TM-TC activities are discardedSR 406 TMTC TM-TC activities are discardedSR 407 TMTC TM-TC activities are discardedSR 408 TMTC TM-TC activities are discardedSR 409 TMTC TM-TC activities are discardedSR 410 TMTC TM-TC activities are discardedSR 411 TMTC TM-TC activities are discardedSR 412 TMTC TM-TC activities are discardedSR 413 TMTC TM-TC activities are discardedSR 414 TMTC TM-TC activities are discardedSR 415 TMTC TM-TC activities are discardedSR 416 TMTC TM-TC activities are discardedSR 417 PERFORMANCE 3. FUNCTIONAL ARCHITECTURE,SR 418 PERFORMANCE 3. FUNCTIONAL ARCHITECTURE,SR 419 PERFORMANCE 3. FUNCTIONAL ARCHITECTURE,SR 420 PERFORMANCE 5.4.2 Purpose,SR 425 RESOURCE 3. FUNCTIONAL ARCHITECTURE,SR 426 RESOURCE 3. FUNCTIONAL ARCHITECTURE,SR 427 RESOURCE 3. FUNCTIONAL ARCHITECTURE,SR 428 RESOURCE 3. FUNCTIONAL ARCHITECTURE,


Architectural Design Document Reference: SS/DEBAT/ADD Issue. : 1.1 Date : 14/10/2003 Page : cccxxxvii

SR 429 RESOURCE 3. FUNCTIONAL ARCHITECTURE,SR 430 RESOURCE 3. FUNCTIONAL ARCHITECTURE,SR 431 RESOURCE 3. FUNCTIONAL ARCHITECTURE,SR 432 RESOURCE 3. FUNCTIONAL ARCHITECTURE,SR 433 DOCUMENTATION 5.1.2 Purpose,SR 434 RELIABILITY 3. FUNCTIONAL ARCHITECTURE,SR 435 CONSTRAINT 3. FUNCTIONAL ARCHITECTURE,SR 436 CONSTRAINT 3. FUNCTIONAL ARCHITECTURE,SR 437 CONSTRAINT 3. FUNCTIONAL ARCHITECTURE,


Date post:	09-Mar-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times