7.4 Back-End: Other Tests
7.4.1 Requirements
It was found that, even when the data files were all deleted, the conversion took place in under 10 seconds.
As can be seen, the back-end passes all of its requirements apart from FR 2(b)i, which has been thoroughly documented as a design decision based on second appearing in two Content Dictionaries.
7.5
Front-End
All the error messages, apart from ConversionFailed, DuplicateUnit and UnknownDimen- sion were generated; the last two can no longer occur, and for the former we have not found a conversion that causes this—it requires the program to find a route but fail traversing it. It was found that the significant figures control has no effect on results in unit standards. This was expected as it has not been decided what to do in this situation.
The bug found in the front-end, although potentially irritating, is not a huge problem, as all functionality still works, it just means that one method of accessing a small part of this functionality is not available.
7.5.1 Usability Guidelines
As can be seen, it fits most of the accessibility guidelines, although there are a few issues with dynamic content which is not accessible, and the issue of being unable to upload files if JavaScript is disabled. These should be rectified, especially the latter.
7.5.2 Requirements
CHAPTER 7. TESTING 75
7.6
System
Most of the System Testing results had already been seen with the Front-end testing, and nothing new was found.
7.6.1 Requirements
It was found that overall the system met most of its requirements—it did not prevent the user from supplying a CD which contained the same unit name as another, but the reasoning behind this has been discussed at length in Section 5.8. The system also did not offer such choices as between displaying 0.5 km and 500 m, but this was only a minor part of the functionality. The system also made no attempt to override the user’s unit choice with a prefix, as it was felt that they could use the standards conversions for this. The system was found to pass the rest of its requirements, or they were found to no longer be applicable.
Chapter 8
Content Dictionary Corrections
CHAPTER 8. CONTENT DICTIONARY CORRECTIONS 77 The Content Dictionaries were found to have several errors and omissions during the course of the project. These were corrected, and the resultant CDs are found in Appendix C. To demonstrate the program working with an entirely new CD, units beer1 was created, which contains the various sizes of beer container: firkin, kilderkin, barrel and hogshead. As can be seen from the testing, the system could convert between these and the other volume units correctly. Additionally, two CDs of obsolete units were created, and these were also used during testing.
8.1
Temperature
The initial problems noticed with the Content Dictionaries were in the temperature con- versions. There were two issues noticed. One was that the conversion for Fahrenheit was incorrect—instead of being specified as C = 5
9 × (F − 32), as would have been correct,
it was specified as C = 0.5556 × F − 32, which was inaccurate. However, during imple- mentation it occurred to us that this was also incorrect in a deeper way. We realised that there are in fact two kinds of temperature conversion; based conversion and relative con- version. For example, 10◦C is 10 × 9
5+ 32 = 50◦F, but an increase of 10◦C is an increase
of 10 × 9
5 = 18◦F. This meant that as well as correcting the 0.5556, we needed to add new
temperature definitions for relative temperature. This led to us considering which other dimensions need such different versions, and led to quite extensive changes to the way units are stored, with new Monoid and Non-Monoid STS definitions, which all dimensions are assigned one or other of, in place of the old PhysicalDimension. For more details on this change, see Section 4 of H.
8.2
Other Changes
It was also decided that, besides examples like Fahrenheit, where using an OMF is incorrect, all of the units where the OMF used is “architected”1 should be replaced by elements of
Q. Therefore, this was carried out for every OMF that was deemed to be architected.
8.2.1 Definitions Added
It was found that units imperial1 was missing several units, such as inch, stone and gallon, which it was felt should be present. These were duly added. In addition, the support for U.S. units appeared to be limited, so several new units were added. Finally, a problem was noticed whereby the unit Watt was defined to have the dimension power in dimensions1, but this particular symbol did not exist, so it was added.
CHAPTER 8. CONTENT DICTIONARY CORRECTIONS 78
8.2.2 Units Moved
As a result of the discussion in H, litre pre1964 was moved to a new units metric obsolete1 CD. Additionally, a units imperial obselete1 CD was created, with the units rod, pole, perch, chain and league
8.2.3 Units Removed
There were several compound units in the CDs, and, as previously stated, these were removed. However, where such a compound unit has a specific name, such as litre being a variation of metre cubed, and acre being a variation on yard sqrd, these were left in, as otherwise the system would not be able to recognise them, and they also required an additional multiplier.
Chapter 9
Conclusions
CHAPTER 9. CONCLUSIONS 80
9.1
Introduction
What began as an implementation-based project developed into an investigation to de- termine what can be achieved in the area of unit conversion using OpenMath, with less emphasis on our actual implementation. We learnt a lot about the difficulties of unit con- version, and encountered a variety of hurdles. Many of these we managed to overcome, but several remain. Some involve OpenMath itself, while others are specific to our system or are more general to unit conversion. Overall, the project showed that unit conversion using OpenMath is feasible, but further work is needed to develop OpenMath’s support for units in order to improve the functionality. There are also various areas in the system developed that could be improved, both for efficiency reasons and to increase the number of conversions possible. Firstly, we will examine the conclusions for OpenMath.