Each of the styles in this chapter can be traced to a foundational paper in the annals of the software engineering literature. An architect interested in the roots of the discipline may find the original ideas refreshing in their simplicity and purposefulness. These papers, seen as a group, express the then-revolutionary idea that there is more to a computer program than getting the right answer: how it is structured also matters.
Edsger Dijkstra wrote about designing an operating system as a set of abstract virtual machines, giving us the concept of layers, in 1968 [Dijkstra 68]. David Parnas showed how decomposing a system into modules based on likely changes, as opposed to steps in the processing, resulted in systems vastly easier to modify [Parnas 72]. Parnas also introduced the "uses" relation, and showed how it could lead to software that was easy to extend or to develop incrementally [Parnas 79].
In the early 1960s the fundamental concepts of object-oriented programming, including objects, inheritance, and dynamic binding were invented by Ole-Johan Dahl and Kristen Nygaard at the Norwegian Computing Center in Oslo [NygaardDahl 81]. The concepts were introduced in the programming language Simula-67, which, although never widely used itself, laid the foundation for the development of popular object-oriented languages such as Smalltalk and C++. In 19861987, two widely influential papers by Alan Snyder and Barbara Liskov, respectively, tied together two concepts that had been drifting apartinheritance and encapsulation [Snyder 86] [Liskov 87]. Liskov in particular argued convincingly that undisciplined inheritance that violated objects' abstractions was harmful. Between them, they set the object-oriented community on its present path.
A software engineering demonstration project that paid special attention to the use of separate architectural structures was the A-7E avionics system built by the U.S. Navy in the 1980s. A case study of the A-7E avionics software system is presented in [Bass+ 98]. The example employs decomposition (using information-hiding as the criterion), layers, uses, and allowed-to-use relations, and shows how a subset is built from the uses relation.
The information-hiding-based decomposition of the A-7E system is the focus of a paper showing how that view is documented using a hierarchically structured document, called a module guide. The paper includes an extract from a software module guide [Clements+ 85], from which the A-7E decomposition example in this chapter is drawn.
More details of the UML notation can be found in [Booch+ 99]. Classes, packages, subsystems, and their relationships are especially relevant to styles in the module viewtype.
Software Architectures and Documentation
Part I. Software Architecture Viewtypes and Styles
The Module Viewtype
Styles of the Module Viewtype
The Component-and-Connector Viewtype
Styles of the Component-and-Connector Viewtype
The Allocation Viewtype and Styles
Part II. Software Architecture Documentation in Practice
Documenting Software Interfaces
Choosing the Views
Building the Documentation Package
Other Views and Beyond
Rationale, Background, and Design Constraints