|
While architecture is undoubtedly a vital part of system development that is enjoying widespread attention at the moment, it must be pointed out that the field is plowing old ground in several areas. In many ways we are "discovering" fundamental principles that were laid out eloquently and convincingly over a quarter-century ago by Fred Brooks, Edsger Dijkstra, David Parnas, and others.
In programming, the term architecture was first used to mean a description of a computer system that applied equally to more than one system. It still carries this meaning today. In 1969, Fred Brooks and Ken Iverson called architecture the "conceptual structure of a computer … as seen by the programmer" [Brooks 69]. A few years later, Brooks (crediting G. Blaauw for the term) defined architecture as "the complete and detailed specification of the user interface" [Brooks 75]. A careful distinction was drawn between architecture and implementation. Quoting Blaauw, Brooks writes, "Where architecture tells what happens, implementation tells how it is made to happen." This distinction survives today, and in the era of object-oriented programming, it thrives.
The term architecture is still used today in some communities to refer to the user view of a system, but that is not what we mean by software architecture. The structure(s) contained in a software architecture is invisible to the system's end user. However, the conceptual separation between the what and the how applies. Software architecture is not concerned with how elements do what they do, just as the end user is not concerned with how the system does what it does. The notion of architecture as a common description of a class of systems (i.e., an abstraction, where all the instances are said to exhibit the architecture) remains at the heart of what we call software architecture today.
Also in 1968, Edsger Dijkstra was telling us to be concerned with how software is partitioned and structured as opposed to simply programming to produce a correct result [Dijkstra 68]. He was writing about an operating system and introduced the idea of a layered structure, in which programs were grouped into layers and programs in one layer could communicate only with programs in adjacent layers. Dijkstra pointed out the elegant conceptual integrity exhibited by such an organization, resulting in increased ease of development and maintenance.
David Parnas advanced this line of observation with his fundamental contributions to software engineering in the early 1970s. In his work, more than anyone else's, is to be found many of the fundamental tenets and principles behind software architecture, including the following:
A design principle for how to break a system into elements to increase maintainability and (as we will see in Chapter 5) re-usability. If architecture has a fundamental principle, it is this one, which Parnas called information hiding [Parnas 72]. The principle of using an element via its interface only, the conceptual basis of all object-based design [Parnas 72]. An observation of the various structures to be found in software systems, with an admonition not to confuse them-a lesson often forgotten by today's "architecturists" [Parnas 74]. Introduction of the uses structure, a principle for controlling the connections between elements in order to increase the extensibility of a system, as well as the ability to field subsets quickly and easily [Parnas 79]. The principle of detection and handling of errors (now called exceptions) in component-based systems, which is the underlying approach of most modern programming languages [Parnas 72, 76]. Viewing every program as a member of a family of programs, with principles for taking advantage of the commonalities among the members and ordering the design decisions so that the ones that need to be the easiest to revise are made last. The coarse structuring of the program-part of its architecture-comprises the set of early, family-wide design decisions [Parnas 76]. Recognition that the structure of a system influences the qualities (such as reliability) of that system [Parnas 76].
Now it is true, and Parnas would agree, that not all of the ideas in his papers were invented by him from whole cloth. About information hiding, for example, he has said that he was writing down what good programmers had been doing for a long time (especially operating systems programmers writing device drivers). However, taken as a body, Parnas's work is a coherent statement of the theme of software architecture: Structure matters. His insights form the backbone of software architecture as a study area, and no book on the subject would be complete without acknowledging his fundamental contributions.
Recently a colleague and I had a fine architectural discussion about what exactly constitutes the interface to a software element; clearly it is much more than the names of the programs you can call and the parameters they take. My colleague worked out that it is actually the set of assumptions that you can safely make about the element, and that these assumptions vary according to the context of the element's use. I agreed and pulled out Parnas's paper [Parnas 71] in which he said precisely the same thing. My friend looked a little crestfallen for a moment and then said, "Now I know how Scott felt when he reached the South Pole and found Amundsen's flag already planted. He probably said, 'Oh, damn. And now I've got to eat my dogs.' "
Parnas's flag is planted deeply, and often, in our field. In the next chapter, we will present a case study of an architecture created by Parnas to put his ideas into practical use in a demanding real-world application. Even though it ran its course long ago, we know of no other single project that so clearly laid out and faithfully followed architectural principles such as engineering and maintaining separate structures to achieve quality goals; strict information hiding to achieve re-usable elements and a re-usable architecture; and painstaking specification of that architecture, its elements, and their relationships.
While Parnas and others laid the foundations, the field has taken its own turns in the interim. Experience with basic ideas leads to the refinement of those ideas, to embellishments rooted in practicalities, and to entirely new concepts. Thus, while Parnas wrote about program families a couple of decades ago, we will see in Chapter 14 that organizational, process, and managerial concerns predominate in the successful development of product lines, their conceptual descendant. While Dijkstra wrote about separation of concerns about a quarter-century ago, objects (the conceptual descendant) have only fairly recently come into their own as a standard, widely accepted design approach. And while Brooks and Blaauw wrote about architecture even longer ago, we've already seen that architectures cannot be understood except in light of the business issues that spawned them, and we will see ways to analyze architectures without waiting for the system to be built.
Today, architecture as a field of study is large and growing larger, primarily because it has left the realm of deep thinkers and visionaries and made the transition into practice. The early ideas have been refined and applied enough so that it is becoming an accepted state-of-the-practice approach to system building.
- PCC
|
