The data structure for the ACANGold database is given here.
This says what we think is involved in implementing the requirements spec, and how it should be naturally ``carved at the joints''.
The Developers.
Global data structure and format
Most applications involve data in some way or other---even static web pages have content that needs to be managed. Database systems will obviously demand a data dictionary.
Data access
Interface to the data repository from the code. This is a special case of a ``pervasive library'' (below) which is often particularly pervasive and easy to get wrong.
Pervasive libraries
These are the libraries we identify as underpinning large parts of the project; the litmus test is ``Will I have to change vast amounts of other code if I change this?''. The plan is that we do these first.
Pervasive graphic designs
Similarly, we need to think if there are design issues, or actual designs, which must be pinned down early on. Does this ever happen?
Packages
A carving of the non-pervasive parts of the system into independent parts so as (1) to minimise the ``surface'' area of interface between them and (2) to make each piece doable by one or at most two developers---I take it that we are never going to do a project in which we have to make further subdivisions in order to achieve this. The interfaces offered by each package are made concrete, as are its dependencies on other packages/libraries.
Graphic designs are treated as packages too; the way they must relate to each other and to the code is pinned down as far as that is possible (consistency of look, space usage, anything else?).
Generally important issues
Security; performance.
Document Dated: Tue Apr 27 13:01:03 1999 by TimP
Modify this document
Previous Version