The SASSY Project - Introduction

The Super Sized Software page introduced the idea of the very large project. At
the end I lamented the lack of any decent support for building really large
systems. The Software Architecture Support System (or SASSY) is a project I have
undertaken to try and address this problem.

The basic idea is to build a knowledge database containing all the information
concerned with the architecture of the system. By having a single repository
we avoid the issues of having things get out of synch. We can then generate
all the architectural documentation from that repository.

My plan is to do the initial development as a personal project, and if it starts
to look promising, migrate it to Source Forge and open it up for others to assist.
Such projects will only take off if there is something solid to start
with - hence the initial private project.

While SASSY is not likely to become a hugely complex project, I though that it
might be interesting to use itself as its first project. This way I only have
to design the architecture for one system, not two.

The Vision Statement

The goal is to produce a software system that assists with the task of creating
an architecture for a software system.

The current process involves writing text documents, typically using a word
processor, and trying to embed into them a set of diagrams that describe the
proposed design at a high level. The results are generally not very satisfactory
for a variety of reasons.

Creating diagrams for inclusion into word processing documents is not easy.
Some word processors are quite poor at handling diagrams. There are serious
limits to the complexity that can be described in such a diagram. For a complex
system the diagram will either be too cluttered to be readable or such a high
level view that it is essentially meaningless.

Creating diagrams is often manually intensive. Even with diagramming editors
that have the appropriate symbols and an understanding of what the symbols
represent it is still necessary to place the symbols and label them. This
takes a considerable amount of tedious effort. The result is that diagrams can
quickly become out of date as the design evolves but there is not time to
revisit the diagrams. There is also a tendency to combine several aspects of
the design into the one diagram. This can make the diagrams confusing and
ambiguous.

The use of word processing documents to describe the system also has its
problems. When writing a document it is usual to target a specific audience
- perhaps the developers, perhaps the stakeholders, for example. It is very
difficult to write a single document for the use of a variety of audiences.
It will have too much detail that is not relevant for most of its readers,
and conversely each reader will have difficulty finding the information that
they need.

The rather obvious answer is to create numerous documents and diagrams each
tailored to a specific aspect of the design. However this brings with it
another problem, namely, how to keep a large collection of objects consistent
while the design goes through its inevitable evolution?

The current process for developing a software architecture does not scale very
well. For very large projects it becomes necessary to use a significant number
of 3rd party products (unless you have an extraordinarily large budget). This
range of products can easily exceed the knowledge of any single architect.
Moving to a team of architects presents its own problems since the
project will no longer have a single visionary to guide it.

The objective of this project is solve these problems. The approach is to
capture the design, the software architecture, in an ontology or knowledge
database. Being in a single repository it can be kept consistent, and in fact
the tools available for checking ontologies can be used to identify any
inconsistencies. We will then develop a set of tools that can generate the
documentation and diagrams for each aspect or view that is required. A single
repository, with multi-user access, can allow multiple architects to
collaborate on the design process by enabling each one to easily see the
information that is relevant to the part of the project that they are working on.

Software will then extract the data from the knowledge base and feed them
into programs that will generate the text and diagrams. A user interface
component will coordinate the process. The output format should be PDF so
that there is less temptation to edit the output documents rather than the
source knowledge base.

Next time we will look at the preliminary analysis for the SASSY project.


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