The aim of this round of development is to tidy up some of the rough edges
from the first round. Our first cut was done with the aim of getting
something done from which we could base the subsequent development. In the
rush it was easier to copy and paste similar code, and there were a few
bugs in the way diagrams were displayed.
To organise the work I used the Mantis bug tracker program and noted down
all the things that needed attention. Again, for this increment the aim
was not to extend the functionality, but rather to focus on the quality.
The following bugs were addressed:
- Empty boxes in diagrams
- The diagram building code got additional checks to ensure the diagrams were OK.
- Diagrams the wrong size
- The temporary file name given to the diagram's eps text turned out to be not unique. This resulted in some diagrams being scaled twice, and others not at all. A better file naming algorithm cured the problem.
- Hyperlinks flowed into the margins
- The LaTeX processor in dvips was not able to handle hyper-links adequately. I found, and installed a newer package, called dvipdfm, that could correctly break a hyper-link.
- Table of Figures
- The architecture document has a lot of diagrams, and it really needed a table of figures to appear after the table of contents. A few changes to the boiler-plate had that included easily.
- Formatting Issues
- Some paragraphs needed to be indented, so I constructed a LaTeX command to provide the required formatting. Also fixed the boiler-plate for things like the revision history and copyright notice. Finally I added a new SASSY logo.
- Quality Attributes
- The Requirements document was listing the quality requirements correctly, but these were worded in a way that referenced the corresponding quality attribute, which was not being shown. Some modifications to the code soon fixed that issue, and now the requirements are quite readable.
- Requirement Priorities
- I had put some support in for handling the priority of a requirement but it was unused. This meant that you could not separate the mandatory from the important or the "nice to have" requirements. I added a classification to each requirement, and added the code to display this information in the generated requirements document.
- Code Refactoring
- Common code was separated out, paramaterised where necessary, and placed into the appropriate parent classes.
Conclusion
The programs now form a solid basis for the rest of the project. We have
something from which we can build on and which will usually be in a working
state if we need to show it off.
My main concern is that the code to generate the documents is too
dependent on the structure of the ontologies. This is something we will
address in the next increment where that aim is to incorporate SPARQL-DL
into the design.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
