SASSY- Analysis, Part 9

Interfaces

In this last blog on the preliminary analysis for the SASSY project we look at the interfaces between our software architecture system and the surrounding environment.

Input Interfaces

The inputs to the software architecture process are the vision statement, the preliminary analysis document, the data dictionary and the functional and quality requirements documents.

The software architecture process also contains a body of its own knowledge. Currently this is mostly held in the expertise of our software architects, but for this project we aim to capture as much as we can into a core software architecture ontology.

For a general project there may not be much control over the format of the inputs since they may come from a client who will simply provide the requirements etc. as a set of word processing documents. We can either accept these documents as the input, or transcribe them into the ontologies described in the previous blog. It may be that the act of transcribing them will uncover gaps which the preliminary analysis can attempt to resolve.

Output Interfaces

The outputs from the software architecture are a set of documents and diagrams that describe the system from a range of viewpoints.

Glossary

From our vision statement we intend to use knowledge engineering, specifically ontologies, to store the software architecture, and we also understand that we intend for this to be used when creating very large systems. One of the tasks in building a system, and an output of the preliminary analysis, is the glossary or data dictionary for the project's terminology. For a very large system it would seem logical to use an ontology to store this data dictionary.

Given that the aim of this project is to produce documentation from the contents of an ontology, it would seem reasonable to extend the project to the generation of the glossary ontology.

Requirements

It is often useful to know how all the parts of a software system are related. In particular it is often useful to know what functional or quality requirements drove various aspects of the design, code, testing, documentation, etc. If we were to relate all the components of a system together into an ontology then it might be possible to readily deduce such information and thus be in a better position to maintain the system.

Hence the requirements for the system should be drawn into the software architecture ontology, or perhaps exist as an ontology of their own which can then be referenced from the SASSY ontology.

Quality Attributes

Also from the vision statement we can expect our system to have a core Software Architecture ontology, and part of this will be a collection of quality attributes. These would be of interest when creating the Quality Requirements document, so it would appear to be a useful extension to the system to be able to print out such a list from the Software Architecture ontology.

Document Format

There are a variety of possible formats for the documents, ranging from plain text, to HTML, Word Processing and to PDF.

While plain text might be the easiest to generate, and it has advantages if you want to do further processing with it, it does not present very well to those that expect to see a high quality product.

HTML is fine for on-line viewing, but generally does not print well. If XHTML is used it can still be further processed if necessary.

The internal format of most word processing documents is quite complex, and sometimes not well documented. This makes generating the documents quite difficult. The other problem with word process documents is that they can be subsequently edited. There is, therefore, a danger that the output documents will be maintained, rather than the underlying ontology. This could lead to confusion as documents get out of step.

One option that produces high quality output, in PDF, is to generate LaTex. This is a well documented format that is easy enough to generate.

Diagram Format

The natural choice for diagrams is SVG. This is easy to generate, both manually and with various tools.

It is also easy enough to further process if necessary, since it is just XML.

While simple diagrams can be, and probably should be, embedded into the documents to which they refer, larger, more complex diagrams might be better left as separate documents.

If we allow separate documents for the diagrams it opens up some additional possibilities. We might introduce a third dimension and create a 3D model that can show more complex relationships than would be practical for a 2D diagram. Alternatively we might use animation to show how things change over time.


This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.