OITools Documentation

Data Model class diagram (general structure)

class diagram

  • Data Model is an abstract model that organizes elements of data and standardizes how they relate to one another and to real world properties. This diagram represents a part of our structures and the relations between them.

Failures and DataModel documentation

failures diagram

  • Failure diagram represents a part of our structures and the relations between them.

  • Rule is an enumeration (65 rules) which contains all information (ID, description, paragraph in the OIFITS 2 standard, message template) defined by the OIFITS standard or JMMC (supplementary rules). Rule has extra fields to store their scope (applyTo & standard sets) to indicate part of the OIFITS data model are verified by the Rule (the table / keyword / column, where this rule applies).
  • RuleFailure instances represents concrete Rule violations (1 failure per case) with the following key information: rule, file & HDU references, (optional) member. Each instance acts as a key in the OIFitsChecker.failures map to gather all occurences for the same key and associate their contextual data in
  • DataLocation instance contains concrete data (row, col, values ...) to later define the failure severity, generate the user message and display failures to the user

  • OIFitsChecker contains ruleFailed(Rule + data) methods to create RuleFailure + DataLocation instances when validating the OIFits structure: see OIFitsFile.check(OIFitsChecker)

  • DataModel generates reference files: DataModelsV1.xml & DataModelsV2.xml (Rule list and Table description), and Failures.xml.

    • DataModel is a class which runs all the OITools code (covers all features ...) with the magic flag OIFitsChecker.setInspectRules(true) to gather all Rule (applyTo & standard sets) and possible failures. The InspectRule flag (in the code) enforces entering all code paths (if cases) and will trigger every Rule failure with any data. Note: Failures.xml will contain also valid data (just example data)

    • Approach:
      • Specific cases in OIFitsLoader: use loadOIFits() to load at least an OIFITS 1 & 2 files
      • 2 memory structures in OIFITS 1 & 2 versions.

    • Special cases: modified OIFITS file.
      • FILE_LOAD rule: use truncated OIFITS file.
      • rule : tables V2 in OIFITS 1 !

Loader class diagram

load_write diagram

  • Class diagram represent classes used for OIFits/FitsImageWriter and OIFits/FitsImageLoader organization. At left there is OITools/FitsImage package and at right there is Nom.tam.fits package.

load diagram

  • Class diagram represent methods used for load Fits and OIFits files. This diagram makes it possible to understand the organization of the methods of the classes OIFitsLoader and FitsImageLoader. Some of these methods are called and are shared between the two classes (processHDUnits).

Junit Tests

  • TODO: Test update ? (History order) / (Hierarch) *see strict compare Nom.tam.fits

Tests documentation

  • Creation of the first test files DumpOIFitsTest and LoadOIFitsTest. These are test files for checking the OIFitsLoader:
    • DumpOIFitsTest displays file information and loads the contents file in the oifits folder and saves all information that we think is important to OIFits files (keywords, columns, values, ...) in a .properties file. This information is stored in a reference folder (which is supposed to not be modified).
    • LoadOIFitsTest loads the .properties information and compares it with our files in the oifits folder.
  • So we can see if changes in our code could alter the recovery of information from files.

  • Added about thirty OIFits files to the oifits folder to test.
    • They were chosen for their differences (Nwave = 1, Multi Table, Various instruments, file version 2, image ...) with a small search algorithm: FindFilesTool.

  • Creation of the files for the mutualization of the test code: JUnitBaseTest and AbstractFileBaseTest (child class)
    • JUnitBaseTest is the class that manages the recovery of files and folders as well as the paths of these.
    • AbstractFileBaseTest is the abstract class that handles the common code between Dump & Load OIFitsTest.

  • Creation of two classes DumpFitsTest and LoadFitsTest, which are the addition to DumpOIFitsTest and LoadOIFitsTest for image management.

  • Creation of WriteOIFitsTest and its counterpart for images WriteFitsTest. This test loads the OIFits files and creates a copy, and then compares the copy to the file that is loader again. This test permits to test the rewrite of the files, since the files are load a number of small fixes and improvements are made.

  • Creation of two classes CreateOIFileV1Test and CreateOIFileV2Test. These two classes of tests make it possible to create a complete file in version 1 or version 2. The two OIFits files created are very good bases for the other tests. They allow to test the writing of an OIFits file

  • Creation of OIFitsViewerTest test to export csv, xml (OIDB).

  • Creation of FormatTest, this is a small test that checks the validity range of the dates of an OIFits file.

  • Creation of FitsValidatorTest, this is the test of validation of OIFits files. It is being rewritten.

  • Creation of DumpDataModelTest, it's just a call to the hand of DataModel to create it at the same time as the launch of the tests and also performs a better code coverage.

  • Creation of MoreCoverageTest, it's just a call to functions that were not covered by other tests in order to have better code coverage and prevent regression.

-- CharleenKemps - 20 Oct 2017

Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2018-02-07 - CharleenKemps
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback