Component-Based Systems

vs. Concrete Descriptions The requirement to use abstraction in describing the behavioral aspect of a system’s interface leads to the following additional terminology: • A system’s interface description (structural plus behavioral) is called an abstract description of the system. • A description of a system’s interior, i.e., the subsystems that comprise it and their relationships to one another and to the interface of the system, is called a concrete description of the system. The instruction manual is an abstract description of a TV. A concrete description of a TV probably includes a wiring diagram that shows the internal connections between external connectors and controls and other internal pieces that are not mentioned in the instruction manual. It explains that there really are electronic circuits involved and how they fit together. There are, then, two quite distinct kinds of symbolic descriptions of systems. The differences in purpose and nature between abstract and concrete descriptions induce the need for different features in the languages used to write these descriptions. Writing an abstract description demands a language in which to express not just structure, but properties, behaviors, guarantees, obligations, assumptions, etc., that might be needed in a cover story about the system. Depending on the type of system and the nature of the cover story, a language for abstract descriptions must be quite powerful because it might be needed to say nearly anything. Natural languages such as English are commonly used for this purpose, but they are too ambiguous and imprecise for some purposes such as sound and rigorous reasoning about the behavior of a system from its abstract description 4 COMPONENT-BASED SYSTEMS alone. Engineers therefore routinely use mathematical models to characterize externally visible system behaviors of interest, although these models seldom appear undisguised in end-user instruction manuals. Writing a concrete description is quite different. It must explain the inventory of subsystems used inside a system and how they are related to each other. It also must say enough about how these subsystems are related to the abstract description of the enclosing system in order to reason about why the cover story is legitimate. Circuit diagrams, free-body diagrams, blueprints, and associated mathematical and natural-language notations are examples of languages used in traditional engineering to write concrete descriptions of systems. The Client-Implementer Contract Recall from Figure 1 that an interface is not like a one-way mirror. It is more like a firewall — a symmetric barrier that hides information both ways. Because it serves both clients and implementers, an abstract description has other names. Sometimes it is called the system’s interface specification, or its behavioral specification, or simply its specification. This document records a contract between a client and an implementer of the system (Meyer, 1997). It simultaneously defines two complementary aspects: • the structural and behavioral requirements the system places on its clients, or equivalently, the only assumptions a person implementing the interior of a system may make about the clients of that system; and • the guarantees the system gives in return to its clients, or equivalently, the only assumptions a person using the system as a client may make about the components of that system. Substitutability and Modular Reasoning The inability of clients to breach the interface means that inside a system may be any coordinated combination of subsystems that results in satisfying the interface specification. This substitutability property is what offers the option of buying any of a large number of TV models from any of a number of TV vendors, plugging your TV into the wall and connecting it to the same remote speakers and other audio/video systems, and expecting the whole combination to work as advertised. Systems such as modern audio/video systems that satisfy the substitutability property are sometimes called component-based systems because various vendors can supply subsystems to meet standard interface specifications. These systems generally do differ in internal details and, of course, in other ways (e.g., price) that are inessential in meeting the standard interface specifications. The dual abilities of a client to reason about a system’s behavior without peeking inside its interface, and of an implementer to reason about subsystem-to-subsystem behavior without peeking outside its interface, together are called the modular reasoning property. Another term for this is compositionality; but this term can be misleading because it suggests that merely structural, not behavioral, composition is the key question. Achieving the modular reasoning property is the central technical objective of using componentbased design in engineering. A common misconception is that the motivation for component-based design is economic. Indeed there are economic benefits when parts are standardized and can be supplied by different vendors to deliver the same functionality with different auxiliary characteristics (e.g., price). But these economic benefits accrue only when it is legitimate to replace one vendor’s concrete component with another’s, without worrying that the rest of the system might break as a result of the substitution. For an excellent discussion of economic issues in the COMPONENT-BASED SYSTEMS 5 context of modular computer system design, and insightful commentary on the theoretical importance of “modularity”, see (Baldwin and Clark, 2000). Component-Based Software Systems Many of the terms widely used by software engineers to talk about software systems are identical to those introduced above for physical systems, e.g., system, component, interface, abstract, concrete, contract, etc. The parallels between component-based systems in traditional engineering and in software engineering are most natural if one views a software system as a set of documents describing the behavior of a particular kind of physical system, namely some computer(s) and attached devices. Some of these documents are ordinary computer programs, e.g., procedure and function and class headers, and their code bodies: the concrete descriptions that explain the data structures and algorithms that produce the externally visible behavior. Other documents are specifications: the abstract descriptions that explain the structural and behavioral aspects of the interface. Following this direction, a software system is defined as a set of abstract and concrete descriptions of behavior of some computer(s) and attached devices. A software system is component-based if the concrete descriptions it contains include the identification of subsystems or components that are likewise described, down to some level where subsystems are considered primitive. The abstract descriptions are called abstract components; similarly, the concrete descriptions are called concrete components. The “components” in a component-based software system, then, are the documents that describe what subsystems and systems do and the source code that describes how they do it. In an OO software system, then, a class is a component, but a class instance (i.e., a run-time object) whose behavior is described by that class is not a component. Limits of Traditional System Diagrams Consider any set of abstract and concrete descriptions of a component-based physical system. The hallmark of a component-based system design is the potential to substitute any of a number of different concrete descriptions for some abstract description. The restriction is that the concrete description and the abstract description should fit together properly, or be compatible, in the sense that there is some physical system that might have both of those descriptions. Substitutability, then, inevitably leads to the need to distinguish between a system that exists, and the other systems that might be obtained from it by compatible substitutions. The impact of this observation becomes apparent when considering diagrams like Figure 1 that often are used to convey information about the nesting structure of physical systems. In a diagram of a specific physical system, such as a particular TV, the original notion of a system makes sense: a piece of the physical world with an exterior, an interface, and an interior. But a system diagram of this TV is misleading as a claim about the design of the TV, because it ignores the substitutability principle. Thinking of the interior of a particular system as a fixed thing, and not simply as one of the many possible interiors that might be compatible with the abstract description, simply overlooks the key reason for component-based system design. This means that while nested-box diagrams like the top left of Figure 1 are adequate for informally describing particular instances of physical systems — the kinds of physical systems they were intended to illustrate — these diagrams are inadequate for depicting physical systems that are explicitly component-based. In the latter there might be many compatible interiors for a given system interface, i.e., many potential particular systems. The only way to use traditional system diagrams to show the combinatorially many potential systems that can be built from a given set of subsystems is to exhibit individually the particular systems that could be constructed from them. This is tedious at best. So traditional system diagrams are not really satisfactory from the 6 COMPONENT-BASED SYSTEMS standpoint of component-based engineering design. They tend to be better for analysis tasks where a single fixed system is to be described and studied. Design-Time Relationships To overcome this problem, software engineers seem to be the first engineers to have identified the important relationships that might hold between the various documents describing a componentbased syste