Decisions

#Decisions Information about decisions made that do not affect tools, process, etc.

#Decided to implement the XDF file first Most of the team is more comfortable with XML than binary. It was decided to implement the XDF story first in order to learn the spec in a more comfortable standard. Confirmed that this was acceptable with Chris 1/25/2012.

#Ditching Interfaces We decided to scrap the interfaces. Initially we had decided to use interfaces to define the spec in code. We realized that this was only adding maintenance overhead without adding any value. We may add the interfaces later, but for now we are removing them.

#Verification and Validation Each setter will be responsible for validating data as it is set. The setter is responsible for validating everything that is in the scope of the field. For example, that the value is a UINT32, is in the accepted range, but will not check if the field is correct with respect to another field. Validation that requires multiple fields will be done by the first object that is the parent of both fields.

#Reading and Writing Binary Files Given the requirement to read and write binary files in a random access manner, we decided to use the RandomAccessFile class in Java. One caveat is that this file reads and performs all operations in memory. We believe that these files will be relatively small, so we are not concerned with this. However, if performance issues arise, this may be a culprit.

#Strings in BDF will not escape special XML characters Special XML string characters '<', '>', and '&' stored in the BDF will not be escaped as is done in the XDF file.

#CRC Implementation Examined the java CRC 16 and 32 bit implementations described in the following links. 16 and 32-bit CCITT CRCs (http://introcs.cs.princeton.edu/java/51data/CRC16CCITT.java.html) (http://introcs.cs.princeton.edu/java/51data/CRC32.java.html) The java implementations were fast and similar to the custom implementation provided in the ARINC 838 Spec, however the resulting integers did not match. The team decided to port the custom crc from C to java

#Validation of input files If the XML or binary is not well formed, the program will indicate that the file cannot be read. No further validation or verification will be attempted. Once the input files are determined to be well formed, further verification will be done to indicate that the files match the spec.

#Big Refactor We encountered an issue with the verification story. It caused a large refactor of the application. Our mid-semester presentation centered around this issue.

#Path for Files The spec is not explicit regarding the path of the files that are defined within the spec. We created a gap bug for this for clarification. We believe that the path issue is either not relevant given aerospace architecture, or so common an issue that the spec writers did not clarify. We are going to add a path parameter to our SoftwareFileDefinitionDao object to alleviate the issue.