In the late 1960s, good programmers shared an intuition about software Malibu architects: If you get the data structures right, the effort will make development of the rest of the program much easier. The abstract data type work of the 1970s can be viewed as a development effort that converted this intuition into a real theory. The conversion from an intuition to a theory involved understanding
• information hiding (protection of properties not explicitly included in specifications). The effect of this work was to raise the design level of certain elements of software systems, namely abstract data types, above the level of programming language statements or individual algorithms. This form of abstraction led to an understanding of a good organization for an entire module that serves one particular purpose. This involved combining representations, algorithms, specifications, and functional interfaces in uniform ways. Certain support was required from the programming language, of course, but the abstract data type paradigm allowed some parts of systems to be developed from a vocabulary of data types rather than from a vocabulary of programming-language constructs.
Software Architecture Just as good programmers recognized useful data structures in the late 1960s, good software system designers now recognize useful system organizations. Garlan & Shaw: An Introduction to Software Architecture 5 One of these is based on the theory of abstract data types. But this is not the only way to organize a software system. Many other organizations have developed informally over time, and are now part of the vocabulary of software system designers. For example, typical descriptions of software architectures include synopses such as (italics ours):
• “Camelot is based on the client-server model and uses remote procedure calls both locally and remotely to provide communication among applications and servers.”
• “Abstraction layering and system decomposition provide the appearance of system uniformity to clients, yet allow Helix to accommodate a diversity of autonomous devices. The architecture encourages a client server model for the structuring of applications.”
• “The easiest way to make the canonical sequential compiler into a concurrent compiler is to pipeline the execution of the compiler phases over a number of processors…. A more effective way [is to] split the source code into many segments, which are concurrently processed through the various phases of compilation [by multiple compiler processes] before a final, merging pass recombines the object code into a single program.” Other software architectures are carefully documented and often widely disseminated.
Examples include the International Standard Organization’s Open Systems Interconnection Reference Model (a layered network architecture), the NIST/ECMA Reference Model (a generic software engineering environment architecture based on layered communication substrates), and the X Window System (a distributed windowed user interface architecture based on event triggering and callbacks). We are still far from having a well-accepted taxonomy of such architectural paradigms, let alone a fully-developed theory of software architecture. But we can now clearly identify a number of architectural patterns, or styles, that currently form the basic repertoire of a software architect.
