2.9 Software Design-Level Model

To facilitate problem solving, it is useful to find ways to separate design concerns-design elements that are implicitly responsible for resolving all potential concerns, those that are potentially unstable (when subject to scrutiny), and those that may require voluminous documentation to justify the design. Explicit reference models for separation of concerns have been proposed for software engineering and other fields of engineering endeavor.

Figure 2.16 also contains a software design-level model proposed by Shaw and Garlan showing three levels [Shaw 1996]. In comparison, the software community does not have a sophisticated view of how to separate design concerns, and it is also not known which components comprise each of these levels. In the software design model, the machine level represents the binary software that is part of the operating system and commercial products that cannot be modified by the application developer. The code represents the program that is the domain of application development, and the third level is the architecture, which provides a model of how the system is partitioned and how the connections between the partitions communicate. The shortcomings of this simple model are that it does not represent any significant separation of concerns and that important properties such as interoperability between systems are not considered.

Figure 2.17 shows the software design-level model proposed in CORBA Design Patterns [Malveau 1997]. This model was originated by one of the founders of the design pattern movement, Richard Helms, and describes in a recursive fractal fashion what the various levels of software design are in terms of objects. At the microlevels are individual objects, and the design principles that apply to those individual objects are usually object specific. A class of patterns called idioms represents design guidance for language-specific issues. These issues are fairly fine grained.

The next level up is called microarchitecture patterns. In microarchitectures, small configurations of objects are used to provide sophisticated ways of organizing software structure to support variability in other qualities of design. The framework level then takes a number of microarchitecture patterns and combines them into a partially completed application with reusable software. Above the microlevel are applications and systems. The application level represents the application of zero or more frameworks to provide an independent program. Here, issues such as user interface programming are encountered; they are significant in software development. At the system level is a collection of applications that play the role of subsystems and integrate applications to create a working system environment. The system level is where many of the design forces applicable to programming are changed in terms of their priorities. Management of complexity and change becomes critical at the system level and above.

At the enterprise level, a collection of different systems are integrated across an organization or virtual enterprise of organizations working in conjunction. The enterprise level is the largest scale of internally controlled operating environments.

The global industry level is represented by the Internet, the commercial market, and the standards organizations, which comprise the largest scale of software systems. Figure 2.18 represents the separation of design forces that occurs throughout the various software design levels. Overall, the management of risk is a force that applies at all levels when making software decisions. At the finer-grained levels, management of performance and functionality issues is very important and perhaps dominates any of the other design forces that apply horizontally across all the levels. Looking at the system level, the key design forces here include the management of change and the management of complexity. This conclusion was derived from the writings of other authors in the software field. In particular, Horowitz writes that the adaptability of systems is the primary quality missing where the majority of system cost is the result of changes in requirements reference [Horowitz 1993]. Shaw and Garlan identify the management of complexity as the key design force at the system architecture level [Shaw 1996].

Above the system level, the environment changes on a more frequent basis. Each system must be modified to support individual business processes; at an enterprise level with multiple systems, the change accumulates as people move and the organization evolves on a daily basis. Management of the resources at the enterprise level and of technology transfer to support capabilities such as design and software reuse becomes more significant and important. At the global and industry levels, the management of technology transfer becomes predominant. When something is published on the Internet, it is instantly accessible on a global basis to virtually any organization or individual. It is important to manage both the information that the enterprise discloses in terms of software intellectual capital and the information that the organization exploits with the management of technology transfer design force.

Figure 2.19 shows the overall priorities for these horizontal design forces as they apply to the coarser-grained levels. At the system architecture level, the management of change is the predominant force because it is linked directly to the cost of the system in published works. As a second priority, the management of complexity is identified because it is a design force emphasized by academic authorities in software architecture. Priorities at the other levels are indicated to show how the perspective of each of the architectural designers at these levels varies by the scale of software design. These are guidelines for making sure that the appropriate priorities are allocated to decisions that are made at each of these levels. The reference model helps to organize patterns knowledge and identify priorities for design forces that are horizontal across the software design levels.