For Further Reading

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

Advanced Concepts

Documenting Software Interfaces

Documenting Behavior

Choosing the Views

Building the Documentation Package

Other Views and Beyond

Rationale, Background, and Design Constraints


Documenting Software Architectures(c) Views and Beyond
Documenting Software Architectures: Views and Beyond
ISBN: 0201703726
EAN: 2147483647
Year: 2005
Pages: 152 © 2008-2020.
If you may any questions please contact us: