5.1 Architecture Versus Programming

Software design levels have been a topic of academic discussion. Representing the software architecture research community, Shaw and Garlan [Shaw 1996] propose a three-level model, comprising:

The machine level comprises unmodifiable binary software, including the operating system and linkable modules. The code level is a modifiable source code. The architectural level is a higher level of abstraction. In their model, architecture comprises software partitioning, software interfaces, and interconnections.

The three-level model establishes a useful frontier for academic research on software architecture. However, it does not have enough levels to provide a sufficient separation of design forces. In addition, this model cannot explain key object-technology benefits, such as interoperability and reuse. Interoperability and reuse require at least one more level in the model-enterprise, an architecture of system architectures.

The Fractal Model of Software

Another way to view software levels is in terms of scale (Figure 2.17). Objects and classes are the finest grain level. This is the level defined by programming languages (C++, Java) and infrastructures (e.g., CORBA, J2EE). The next level comprises microarchitectures, which are simple configurations of objects. This is the level addressed by most design patterns. Configurations of microarchitectures form frameworks (in the Taligent sense). Groups of frameworks form applications (or subsystems), and groups of applications form systems.

The idea for the fractal model was proposed by Richard Helm, co-author of Design Patterns: Elements of Reusable Object-Oriented Software [Gamma 1994]. A missing element from the fractal model is the separation of concerns (or forces).

Major Design Forces

There is surprising agreement about the major design forces on the part of various communities of software researchers. Much of the work is driven by a single major force at a particular design level, although the particular force and design level vary by group.

Many identify adaptability as the key design force. Adaptability is alternately called management of change or variation-centered design. Others focus on management of complexity. Management of complexity is the major driv-ing force of the academic software architecture community, as well as much of the software metrics community.

The Effect of Scale on Forces

Management of change is one of the major design forces in object-oriented architecture. Its importance varies greatly with the scale of software and design level. As the scale of software increases, so does the frequency of change.

For example, an individual application may need to be upgraded only occasionally. A system may comprise many applications, each requiring upgrade. The effect of change is cumulative. At an enterprise level, change is very frequent, with new applications, systems, peripherals, and employees moving every day.

There is a similar effect of scale on other major design forces. This realization leads to a separation of forces between design levels.

Software Design Levels

The Software Design-Level Model (SDLM) builds upon the fractal model (Figure 2.17). This model has two major categories of scales-Micro-Design and Macro-Design. The Micro-Design levels include the more finely grained design issues from application (subsystem) level down to the design of objects and classes. The Macro-Design levels include system-level architecture, enterprise architecture, and global systems (denoting multiple enterprises and the Internet).

The Micro-Design levels are those most familiar to developers. At Micro-Design levels, the key concerns are the provision of functionality and the optimization of performance. At the Macro-Design levels, the chief concerns lean more toward management of complexity and change. These design forces are present at finer grains but are not nearly of the same importance as they are at the Macro-Design levels.

An interesting boundary in the SDLM model is between the enterprise and the global levels. Forces that are important to resolve inside the enterprise are very different from the forces that are important externally. Inside the enterprise, control of information technology and resources is challenging, but feasible. At the global level, issues of technology transfer, control of intellectual property (licensing), and security are key issues between enterprises (and individuals).

Using Design Levels

Design levels are an important and useful intellectual tool. Design levels help to simplify design problems by separating design forces. Each design level limits the number of forces that need to be resolved by any given design decision. Design levels have been in use for dozens of years in digital hardware engineering, and it is time for object technology to adopt a similarly effective conceptual discipline.

Design levels are a key issue for object-oriented architecture because they define the problems and forces that architecture must resolve.