Architecture, language, and non-compositional constraints

In the realm of building construction and computer hardware, the word "architecture" means a set of features shared by a class of designs, or equivalently, a set of constraints on a class of designs (e.g. gothic architecture or RISC architecture). But in the realm of software, the meaning of "architecture" has changed to be more or less synonymous with "design." This is unfortunate because the concept of architecture- as- constraint is potentially useful: properly chosen constraints can guide engineers towards good designs and away from bad ones (and, of course, poorly chosen constraints can have the opposite effect). We can identify two distinct classes of architectural constraints. Compositional constraints are constraints on the structure of a software system, while non-compositional constraints are constraints on the mechanisms for constructing that structure. On this view, "structured programming", for example, is an architecture that imposes non-compositional constraints on the use of the GOTO statement. The concept of non-compositional constraints has been largely ignored by the software engineering community. This has been in some cases a serious impediment to progress. For example, the JPL Mission Data System (MDS) is an architecture based on the non-compositional constraint that spacecraft should be controlled using goals, which are defined as constraints on state variables over time intervals. This is a very simple and straightforward concept with significant benefits, but because it is a non-compositional constraint and therefore unfamiliar, MDS has not been received with unalloyed enthusiasm. This paper offers an informal discussion of non-compositional constraints (NCC) in hopes of making the concept more familiar and accessible. It describes the relationship of NCC and programming languages, and the applicability of the concept to the problem of verification and validation of spacecraft autonomy software.