Providing Open Architecture High Availability Solutions

This view implies a hierarchy that describes the composed-of relationship between a system, its

components, and their components. More levels in the hierarchy provide more detail, and hence,

smaller components are present in the system model.

While this depiction is useful for the understanding of the hierarchical aggregation of components

that comprise a system, the understanding of the relationships between components is not revealed.

A system view including relationship information is critical to the understanding of the influence

one component has on another. A component has a specific relationship with other components in

the system. Components may supply a service, or may consume a service (it may do both as well)

from another component. Overall, in the macro view of our system, the system provides one or

more services to its consumers (users). To better depict this relational context one can employ a

“uses” diagram instead of a “composed of” diagram, as illustrated in Figure 5.

In this figure, the dependency of one component on another is shown. For example, C1 uses the

services provided by C3 and C4. Note that C4 depends on the services of C2 and the components

referred to here are either hardware or software components.

Finally, another view of a system is considered. The relational ‘uses’ view described above is often

lost when a system is realized. For example, consider the case of software components. The

components are a logical grouping of source code, but when compiled by a compiler, these

artificial boundaries are destroyed and a more monolithic product is produced. Even when writing

layered software, the layers are dissolved away after the compiler creates machine code

instructions. Components and layers are convenient and effective ways for managing the source

code of software but are not representative of the running system that needs to be modeled. In

‘Fault Tolerance — Principles and Practice,’ Anderson introduces another type of relation called

the interpretive interface [Ande81]. It suggests that a system may be viewed as a hierarchy of

Figure 4. Tree View of System Decomposition

Subsystem 1 Subsystem 2

System

C1 C2 C3 C4 C5 C6 C7

Figure 5. Relational Component Diagram

Subsystem 1

Subsystem 2