Model and Data Management Tool for the Air Force Structure Analysis Model - Final Report

Transcription

1 Air Force Structure Analysis Model - Final Report D.G. Hunter DRDC CORA Prepared By: CAE Integrated Enterprise Solutions - Canada 1135 Innovation Drive Ottawa, ON, K2K 3G7 Canada Telephone: Fax: Technical Lead, Simulation Systems Contractor's Document Number: version 02 Contract Project Manager: W. Scott Guenther, PWGSC Contract Number: W CSA: D.G. Hunter, Defence Scientist, The scientific or technical validity of this Contract Report is entirely the responsibility of the Contractor and the contents do not necessarily have the approval or endorsement of the Department of National Defence of Canada. Defence Research and Development Canada CORA Contract Report DRDC CORA CR November 2013

2 IMPORTANT INFORMATIVE STATEMENTS The scientific or technical validity of this Contract Report is entirely the responsibility of the Contractor and the contents do not necessarily have the approval or endorsement of the Department of National Defence of Canada. Her Majesty the Queen in Right of Canada, as represented by the Minister of National Defence, 2013 Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale, 2013

3 Abstract.. This report provides the background to the development and a detailed description of the Model and Data Management Tool (MDMT). MDMT was created to provide a user-friendly wrapper for various versions of the Air Force Structure Analysis (ASTRA) model. Its primary function is to keep track of the model versions along with all input data, output data and associated meta-data for the models and for each execution of the model. Résumé... Le présent rapport décrit le contexte de développement de l outil MDMT (Model and Data Management Tool) et donne une description détaillée de l outil. Nous avons créé l outil MDMT (Model and Data Management Tool) afin d offrir une enveloppe conviviale pour diverses versions du modèle ASTRA (Air Force Structure Analysis). La fonction principale de l outil est de faire le suivi des versions du modèle ainsi que des données d entrée et de sortie et des métadonnées connexes associées aux modèles et à chaque exécution du modèle. DRDC CORA CR i

4 This page intentionally left blank.. ii DRDC CORA CR

5 CAE Integrated Enterprise Solutions Canada (CAE IES) MODEL AND DATA MANAGEMENT TOOL FOR THE AIR FORCE STRUCTURE ANALYSIS MODEL FINAL REPORT 1135 Innovation Drive Ottawa, Ont., K2K 3G7 Canada Telephone: Fax: CONTRACT #: W FOR GREGORY HUNTER 101 Colonel By Drive Ottawa, Ontario K1A 0K2 2 8 M a r c h Document No Version 02

6

7 R E V I S I O N H I S T O R Y Revision Reason for Change Origin Date Version 01 Version 02 Initial document issued Final document Incorporation of client feedback 19 March March March 2013 iii Version 02

8 T A B L E O F C O N T E N T S 1 INTRODUCTION Background Objective Outline MDMT SYSTEM DESCRIPTION System Architecture MDMT Perform Analysis Tab Scenario Tab Develop Model Tab Input Tab Output Tab Input/Output Metadata Tab Compatibility Tab Raw Tables Tab MATLAB Database Model IO Metadata Scenario Compatible Pairs Output Input External Files Technology Stack Implementation Notes and Issues User Warning Versioning MATLAB Interface CONCLUSIONS AND RECOMMENDATIONS Summary of Work Completed Recommendations for Future Work and Improvements ANNEX A ACRONYMS AND ABBREVIATIONS... A-1 28 March 2013 iv Version 02

9 L I S T O F F I G U R E S Figure 2-1: System Architecture... 4 Figure 2-2: Perform Analysis Tab... 5 Figure 2-3: Scenario Tab... 6 Figure 2-4: Develop Model Tab... 7 Figure 2-5: Input Tab... 8 Figure 2-6: Output Tab... 9 Figure 2-7: IO Metadata Tab Figure 2-8: Compatibility Tab Figure 2-9: Raw Tables Tab Figure 2-10: Database Entity Relationship Model Figure 2-11: MDMT Model Structure Figure 2-12: MDMT Scenario Structure March 2013 v Version 02

10 L I S T O F T A B L E S Table 2-1: MDMT Implemenation Technologies Table 2-2: Technology Versions Table 2-3 MDMT File Extensions Table A-1: Acronyms and Abbreviations...A-1 28 March 2013 vi Version 02

11 E X E C U T I V E S U M M A R Y This document represents the final report for a project entitled Model and Data Management Tool (MDMT) for the Air Force Structure Analysis (ASTRA) Model. The purpose of this project was to design and implement the desired database and modelling object management tools for the Air Force Structure Analysis software. This report was completed by CAE Inc. under Task #137 for contract #W /001/SV to Defence Research and Development Canada (DRDC) Centre for Operational Research and Analysis (CORA). The purpose of Task #137 was to design and implement a database and modelling object management tool suite for the ASTRA software. The integration of the modelling object tool suite and the database are known as the MDMT. The MDMT manages the input and output data, provides version control for the models, and manages execution. With guidance from the Technical Authority (TA), the CAE team analysed the problem space and produced a MDMT architecture and design; this was documented in a separate document entitled Design and Implementation of the Model and Data Management Tool for the 1. Upon design approval, the team implemented the MDMT. During implementation, the team liaised closely with the TA to ensure that the intricate functionality required by the design and the implementation decisions made were according to the TA s expectations. The MDMT provides a graphical user interface (GUI) which enables the ASTRA models to be managed, stored, and executed. The GUI interfaces with MATLAB for the creation and execution of models, to provide a database for data storage and management, and facilitate the collection of external files (managed via the database) for storage of models, input data, and output data. The design and implementation of the MDMT supports extensibility to provide additional features and functionality. During MDMT development, CAE identified additional items for future development. The following improvements were recommended: A command line interface; An improved compatibility pairs feature set; An improved mechanism for generating scenario files; and A database search feature set. 1 Bahramifarid, N. (2012). Design and Implementation of the Model and Data Management Tool for the Air Force Structure Analysis Model. Technical report to DRDC CORA. (Task 137). 28 March 2013 vii Version 02

12 1 INTRODUCTION This document represents the final report for a project entitled Model and Data Management Tool (MDMT) for the Air Force Structure Analysis (ASTRA) Model. The purpose of this project was to design and implement the desired database and modelling object management tools for the Air Force Structure Analysis software. This report was completed by CAE Inc. under Task #137 for contract #W /001/SV to Defence Research and Development Canada (DRDC) Centre for Operational Research and Analysis (CORA). 1.1 Background The Directorate of Air Staff Operational Research (DASOR) created a number of force structure models over the past decade, in the form of various instances of the ASTRA model. Most of these instances were fleet-specific models designed in the Microsoft Access database software with a Visual Basic for Applications front-end. These versions capture much useful information and data concerning the organization and state of the applicable fleet at the time that they were created. The disadvantages of this format are manifold, the primary issues relating to data management, software development methods and its limited scope and lack for future growth. In an attempt to rectify this situation, DASOR developed a new generic prototype version of ASTRA in , dubbed ASTRA Mark II. It was developed in MATLAB/Simulink for the following reasons: MATLAB has well-developed data structuring and graphic presentation capabilities; A simple graphical user interface (GUI) could be created to facilitate data entry; Simulink provides a visual development environment, allowing most operations performed on the data to be represented as nested graphic objects. This enables the developer to understand the model holistically and to view the model details.; and Ranges and steps can be entered for all input variables and all possible combinations of the variables can be generated for brute-force processing in a single step. This approach alleviated some problems experienced with the first version of ASTRA, but made little headway in dealing with the problems of poor maintainability, limited personnel scope and the need for separate models for each platform. Ideally, ASTRA Mark III will mitigate these deficiencies by becoming a comprehensive Air Force Structure model development tool. An analyst will be able to specify the input 28 March Version 02

13 data and rules; the ASTRA MDMT will enable this by providing the ability to manage the data and model versions. 1.2 Objective The objective of Task 137 was to a) design and implement the desired database and modelling object management tools for the ASTRA software; b) include a database for the management of input and output data to the ASTRA models; and c) implement a type of version control and execution control for the ASTRA model objects. 1.3 Outline This document describes the work completed to create the MDMT for the ASTRA model. It provides the MDMT s technical specifications, database specifications, and suggestions for further improvement. The document consists of the following sections: Section 1 Introduction describes the project background objectives. Section 2 MDMT System Description provides an overview of the MDMT architecture, design concepts, and implementation. Section 3 Conclusion and Recommendations summarizes the work completed and provides recommendations for future work and improvements. Annex A Acronyms and Abbreviations lists the acronyms and abbreviations used in this document. The MDMT User Guide is documented separately 2 ; the user guide describes the operation of MDMT software and contains a list of references for all the software required to run the MDMT software. 2 Guo, J. and Guenther, S. (2013). Design and Implementation of the Model and Data Management Tool for the User Guide. Technical report to DRDC CORA. (Task 137). 28 March Version 02

14 2 MDMT SYSTEM DESCRIPTION This section presents the MDMT architecture, describes its components, and identifies the factors that influenced its design. The implementation of the MDMT is also described, highlighting the technologies employed during implementation. This section also describes issues encountered during the implementation phase of the task. 2.1 System Architecture The purpose of the MDMT is to manage and track MATLAB files and their interactions. The MATLAB files are grouped into two categories: models and inputs. A MDMT user can combine models and inputs, and place them within a single MATLAB context (or workspace) to be executed by the MDMT tool. The results of that execution are saved as output files. A record of the model and inputs selected together with their resultant output is stored as a scenario. The content of a model and the input is generally outside the scope of the MDMT and controlled by the user; these files are not directly created or edited within the MDMT. The MDMT expects that a model will contain a MATLAB.mdl file, and an input will contain MATLAB.mat and.m files, with one file named prepastra.m. However, this is not directly enforced by the MDMT. The only relevant rules are that only one.mdl file exists per run, and that the only.m file run is prepastra.m. Another option is that the prepastra.m file can load other files (such as.mat or.m files), but it should not execute the.mdl file as this is done by the MDMT. A model can have input/output (IO) metadata linked to it. IO metadata describes input and output, and can be used to ensure values are acceptable; for example, if a given input variable is within a set range. IO metadata is stored as extensible Markup Language (XML). Sections 2.4 and 2.5 provide additional detail regarding the content and structure of the database and external files. Figure 2-1 illustrates the system architecture of the MDMT system. The central component of the system is the MDMT itself, which interfaces with all other components. Each component is described in the following sections. Note that the Database GUI component in Figure 2-1 has been integrated into the MDMT component. 28 March Version 02

15

16 Figure 2-2: Perform Analysis Tab Scenario Tab The Scenario tab enables a user to examine previous executions of models, input and output data, known as scenarios. Within this tab, a user can rename scenarios, add notes, or export scenario data. When a scenario is selected in the Resources pane and the Select button is clicked, the relevant models, inputs, and outputs are loaded in the Perform Analysis tab, Input tab, Develop Model tab, and Output tab. Figure 2-3 depicts the Scenario tab. 28 March Version 02

17 Figure 2-3: Scenario Tab Develop Model Tab The Develop Model tab permits a user to create a new model entry in the database with the Add button (bottom left). The new model will be linked to an empty zip file, to which a model can be appended using the Append button. An alternative method for assigning files to a model is importing a zip file using the Import Button. If removing a file from the selected model is desired, it can be done with the Splice button. The model can be exported as a zip using the Export button. The Name, Version, Notes, and History fields can be altered which will change the model s information in the database. Finally, a model can be linked to a single existing IO metadata entry using the IO metadata list. Figure 2-4 depicts the Develop Model tab. 28 March Version 02

18 Figure 2-4: Develop Model Tab Input Tab The Input tab allows a user to create and modify input data. It essentially provides the same functionality as the Develop Model tab, but rather than working on model data, it functions on input data. Figure 2-5 depicts the Input tab. 28 March Version 02

19 Figure 2-5: Input Tab Output Tab The Output tab permits a user to add notes and versioning information to the output data. Figure 2-6 depicts the Output tab. 28 March Version 02

20 2.2.6 Input/Output Metadata Tab Figure 2-6: Output Tab The IO Metadata Tab provides a user with a mechanism to describe and validate variables that are passed to a model. Even though IO Metadata is attached to a model, in practice, a user is more concerned with validating the input files to ensure that the input is compatible with a model. IO metadata, variables and corresponding information are stored within an XML file. Figure 2-7 depicts the IO Metadata tab. 28 March Version 02

21 Figure 2-7: IO Metadata Tab Compatibility Tab The Compatibility tab provides a user with a mechanism to annotate which inputs are compatible with a model, or which models are compatible with an input. This is accomplished by selecting an item from one column, and then selecting or deselecting one or more items from the subsequent column. Validation of the input s compatibility with the model occurs at run time. Figure 2-8 depicts the Compatibility tab. 28 March Version 02

22 Figure 2-8: Compatibility Tab Raw Tables Tab The Raw Tables tab provides a mechanism for a user to view the contents of the MDMT database, the database tables. Selecting one of the six sub-tabs displays the contents of the selected database table. The tables can be modified directly by clicking in the data fields and overtyping the contents. Figure 2-9 depicts the Raw Tables tab. WARNING: CHANGES TO THE DATABASE TABLES ARE EFFECTIVE IMMEDIATELY UPON ENTRY. THERE IS NO UNDO FUNCTIONALITY. THE MDMT SHOULD EXERCISE CAUTION WHEN MAKING CHANGES USING THE RAW TABLES TAB. 28 March Version 02

23 Figure 2-9: Raw Tables Tab 2.3 MATLAB MATLAB is the external software which is used for model creation, modification, and execution. Simulink is a block diagram environment for multi-domain simulation and model-based design. It supports system-level design, simulation, automatic code generation, and continuous test and verification of embedded systems. It is integrated with MATLAB, enabling users to incorporate MATLAB algorithms into models and to export simulation results to MATLAB for further analysis. The MDMT was designed and developed to support MATLAB version R2012b and Simulink Database The database component contains all system data or links to the external files necessary for the MDMT to function. The database also maintains all data association, in addition to providing versioning. 28 March Version 02

24 Data is structured into six major elements, each held in a separate database table. Figure 2-10 illustrates the major data elements and their interrelationships Model Figure 2-10: Database Entity Relationship Model The Model data element contains all the model relevant information and links, such as Model Name, History, Version, and the link to the model file. A model, in the context of the MDMT, consists of a Simulink file (*.mdl), a primary MATLAB script file (*.m), and a group of MATLAB data files (*.mat). The primary MATLAB script file can also be associated with other MATLAB script files or data files. The model structure is illustrated in Figure The primary MATLAB script file in a model may be a root file of a tree structure comprising a collection of sub-script files and their descendent-script files. Each MATLAB script file (*.m) in a model may also be linked to a group of input data template files (*.mat). The sub-model (*.mdl) files in a model may also associate with their own MATLAB script files, input templates, and sub-models. All the linked files in a model may be under a single folder or multiple folders under a specified project folder. 28 March Version 02

25 Figure 2-11: MDMT Model Structure IO Metadata The IO metadata data element contains information used to describe and validate input and output variables used by models Scenario The Scenario data element contains a record of the model and associated inputs and outputs. A scenario, in the context of the MDMT, refers to an instance of a model specified by: 1. A Simulink model file (*.mdl); 2. A primary MATLAB script file (*.m); 3. A set of real input data; and 4. The output from model execution using the specified input data. This structure is illustrated in Figure March Version 02

26 2.4.4 Compatible Pairs Figure 2-12: MDMT Scenario Structure The Compatible Pairs data element contains data that correlates models with valid inputs Output The Output data element contains links to the output data files created by an execution instance of a model and input set Input The Input data element contains links to the input data files required by a model for execution. Input records will contain.mat and.m files. 2.5 External Files A design decision was made to not store all data locally to the database to ensure the database data model maintains its flexibility for future extensibility. The database is used only to structure the data; most of the raw data is stored in external files using standard formats. This makes the raw data easily accessible to external tools such as Microsoft Excel or other databases for further custom analysis and visualization. 2.6 Technology Stack Table 2-1 identifies the technologies used in the implementation of the MDMT. 28 March Version 02

27 MDMT Component MDMT Database GUI Database Table 2-1: MDMT Implemenation Technologies Technology Java Swing Matlabcontrol Java Swing MySQL Server MySQL Workbench Model and Data Management Tool for the Notes Primary programming language Swing is a Java GUI development toolkit Open source MATLAB control library for Java Primary programming language Swing is a Java GUI development toolkit. External Zip Files Java Creation and manipulation External XML files Java Architecture for XML Binding (JAXB) Database development and implementation Database schema (model and entity relationship model) Creation and manipulation Table 2-2 details the technology versions used in the implementation of the MDMT. Table 2-2: Technology Versions Technology Version Notes Java 1.6 Swing JDK 1.6 matlabcontrol JAXB n/a Included with Java 1.6 MATLAB R2012b Simulink 8.0 MySQL Server Implementation Notes and Issues User Warning WARNING: USERS MUST EXERCISE CAUTION WHEN EDITING DATA FIELDS IN THE SYSTEM S FUNCTION TABS. THE CHANGES ARE COMMITTED TO THE DATABASE INSTANTANEOUSLY. THERE IS NO UNDO BUTTON. 28 March Version 02

28 2.7.2 Versioning The MDMT suite provides versioning. The aim of versioning is twofold: a) to provide a mechanism to ensure that previous executions of models can be replicated; and b) to provide a mechanism to track new variations of existing entities (inputs, IO metadata, models, and output). Versioning is handled by zipping files and obscuring them from the user (these files will be zip files, but the MDMT will change the extension as identified in Table 2-3). This will allow the MDMT to treat versions atomically. Different versions of files are specified in the database. Table 2-3 MDMT File Extensions.mmo.min.mou MDMT Extension File Type MDMT model MDMT input MDMT output MATLAB Interface The MDMT suite was developed for use with MATLAB 2012b and Simulink 8.0. The MDMT has not been tested for other versions, and may consequently be incompatible. 28 March Version 02

29 3 CONCLUSIONS AND RECOMMENDATIONS Model and Data Management Tool for the This section provides a summary of the work completed and provides recommendations for future work and improvements. 3.1 Summary of Work Completed CAE analysed the problem space and produced a MDMT architecture and design. This is documented separately in a report entitled Design and Implementation Model and Data Management Tool for the. 3 Upon design approval, the team implemented the MDMT. During implementation, the team liaised closely with the TA to ensure that the intricate functionality required by the design and the implementation decisions made were according to the TA s expectations. The MDMT provides a graphical user interface (GUI) which enables the ASTRA models to be managed, stored, and executed. The GUI interfaces with MATLAB for the creation and execution of models, to provide a database for data storage and management, and facilitate the collection of external files (managed via the database) for storage of models, input data, and output data. 3.2 Recommendations for Future Work and Improvements The design and implementation of the MDMT supports extensibility to provide additional features and functionality. During MDMT development, CAE identified additional items for future development. The following improvements were recommended: Command Line Interface. As implemented, the MDMT provides a user with a GUI to control the execution of ASTRA models. The modular design of the MDMT suite lends itself to have a non-graphical, command line interface. It would be beneficial to develop a command line interface for the MDMT to enable some functionality of the present version, but without the GUI. The command line interface would provide a mechanism for batch processing of models that could enable chain processing; for example the output of an ASTRA model run could be used as an input for a different model. Compatibility Pairs Implementation Improvements. Presently, the implementation of the compatibility pairs functionality deletes and creates a new pair every time the user interacts with the user interface. This may result in a large number of identification keys being created in the database over a large timeframe. While the delivered implementation is fully functional, and should not encounter issues in the 3 Bahramifarid, Nima (2012). Design and Implementation Model and Data Management Tool for the Air Force Structure Analysis Model. Technical Report to DRDC CORA (Task 137). 28 March Version 02

30 near- to mid-term, CAE recommends modifying this piece of functionality to ensure no issues arise with long-term use of the MDMT. Generation of Scenario Files. Presently, scenario files are generated on request. An improved solution would be to generate scenario files on execution as this would improve the robustness of the MDMT. A potential issue is if a model or input is changed prior to the scenario file generation, the scenario would not accurately represent the model and input data as run. Database Searching. The present design of the MDMT database did not provide a database search. A search capability could be added to the MDMT suite to assist users to search for specific content within models, input, output, or scenarios. 28 March Version 02

31 APPENDIX A ACRONYMS AND ABBREVIATIONS The following table defines the acronyms and abbreviations used in this report. Table A-1: Acronyms and Abbreviations Acronym or Abbreviation ASTRA CORA DASOR DB DRDC GUI IO JAXB JDK MDMT SO TA XML Definition Air Force Structure Analysis Centre for Operational Research and Analysis Directorate of Air Staff Operational Research Database Defence Research and Development Canada Graphical User Interface Input/Output Java Architecture for XML Binding Java Development Kit Model and Data Management Tool Standing Offer Technical Authority Extensible Markup Language 28 March 2013 A Version 02

32 This page intentionally left blank.

33 DOCUMENT CONTROL DATA (Security markings for the title, abstract and indexing annotation must be entered when the document is Classified or Designated) 1. ORIGINATOR (The name and address of the organization preparing the document. Organizations for whom the document was prepared, e.g. Centre sponsoring a contractor's report, or tasking agency, are entered in section 8.) 2a. SECURITY MARKING (Overall security marking of the document including special supplemental markings if applicable.) CAE Integrated Enterprise Solutions - Canada 1135 Innovation Drive Ottawa, ON, K2K 3G7 Canada Telephone: Fax: UNCLASSIFIED 2b. CONTROLLED GOODS (NON-CONTROLLED GOODS) DMC A REVIEW: GCEC APRIL TITLE (The complete document title as indicated on the title page. Its classification should be indicated by the appropriate abbreviation (S, C or U) in parentheses after the title.) Model and Data Management Tool for the - 4. AUTHORS (last name, followed by initials ranks, titles, etc. not to be used) Hunter, D.G. 5. DATE OF PUBLICATION (Month and year of publication of document.) November a. NO. OF PAGES (Total containing information, including Annexes, Appendices, etc.) 34 6b. NO. OF REFS (Total cited in document.) 0 7. DESCRIPTIVE NOTES (The category of the document, e.g. technical report, technical note or memorandum. If appropriate, enter the type of report, e.g. interim, progress, summary, annual or final. Give the inclusive dates when a specific reporting period is covered.) Contract Report 8. SPONSORING ACTIVITY (The name of the department project office or laboratory sponsoring the research and development include address.) Defence Research and Development Canada CORA 101 Colonel By Drive Ottawa, Ontario K1A 0K2 9a. PROJECT OR GRANT NO. (If appropriate, the applicable research and development project or grant number under which the document was written. Please specify whether project or grant.) 9b. CONTRACT NO. (If appropriate, the applicable number under which the document was written.) W a. ORIGINATOR'S DOCUMENT NUMBER (The official document number by which the document is identified by the originating activity. This number must be unique to this document.) version 02 10b. OTHER DOCUMENT NO(s). (Any other numbers which may be assigned this document either by the originator or by the sponsor.) DRDC CORA CR DOCUMENT AVAILABILITY (Any limitations on further dissemination of the document, other than those imposed by security classification.) Unlimited 12. DOCUMENT ANNOUNCEMENT (Any limitation to the bibliographic announcement of this document. This will normally correspond to the Document Availability (11). However, where further distribution (beyond the audience specified in (11) is possible, a wider announcement audience may be selected.)) Unlimited

34 13. ABSTRACT (A brief and factual summary of the document. It may also appear elsewhere in the body of the document itself. It is highly desirable that the abstract of classified documents be unclassified. Each paragraph of the abstract shall begin with an indication of the security classification of the information in the paragraph (unless the document itself is unclassified) represented as (S), (C), (R), or (U). It is not necessary to include here abstracts in both official languages unless the text is bilingual.) This report provides the background to the development and a detailed description of the Model and Data Management Tool (MDMT). MDMT was created to provide a user-friendly wrapper for various versions of the Air Force Structure Analysis (ASTRA) model. Its primary function is to keep track of the model versions along with all input data, output data and associated metadata for the models and for each execution of the model Le présent rapport décrit le contexte de développement de l outil MDMT (Model and Data Management Tool) et donne une description détaillée de l outil. Nous avons créé l outil MDMT (Model and Data Management Tool) afin d offrir une enveloppe conviviale pour diverses versions du modèle ASTRA (Air Force Structure Analysis). La fonction principale de l outil est de faire le suivi des versions du modèle ainsi que des données d entrée et de sortie et des métadonnées connexes associées aux modèles et à chaque exécution du modèle. 14. KEYWORDS, DESCRIPTORS or IDENTIFIERS (Technically meaningful terms or short phrases that characterize a document and could be helpful in cataloguing the document. They should be selected so that no security classification is required. Identifiers, such as equipment model designation, trade name, military project code name, geographic location may also be included. If possible keywords should be selected from a published thesaurus, e.g. Thesaurus of Engineering and Scientific Terms (TEST) and that thesaurus identified. If it is not possible to select indexing terms which are Unclassified, the classification of each should be indicated as with the title.) Air Force Structure Analysis; ASTRA; MDMT; Model and Data Management Tool