Prediction-Enabled Component Technology
Our approach to achieving the PACC objectives is to use prediction-enabled component technology (PECT). As its name suggests, a PECT is an enhanced component technology. What is a component technology? There is no answer to this question that won’t provoke an argument, any more than there is a universally agreed-upon answer to the question “what is a component?” Nonetheless, there is growing agreement on the following rough definitions:
- A software component is an implementation, ready to execute on some (possibly virtual) machine, with well-defined interfaces that enable third-party composition (roughly, integration with other components).
- A component technology is a component model and runtime environment
where
- the component model specifies what interfaces a component must provide, and how components are allowed to interact with one another and their runtime environment
- the runtime environment is a container in which component behavior executes and in which components interact. The runtime environment may also provide useful services—persistence, transactions, etc.
There is a similarity between this definition of component model and the usual definition of architectural style (or pattern) as a collection of component types and their allowable patterns of interaction. Even though they may differ in many respects, a component model and architectural style both specify invariants that must be satisfied by any instance of that model/style. These invariants are exactly those “well-formedness” rules that we impose on component assemblies to ensure that they can be analyzed, and therefore to ensure their predictability.
Seen in this light, a component technology can be thought of as an infrastructure for designing, developing, and deploying applications that adhere to a particular architectural style. The infrastructure does restrict the freedom of developers and designers, but in compensation it enforces design and implementation invariants that, in this case, ensure predictability. The tradeoff between restricted freedom and predictability has been seen before—in the development of strongly typed programming languages, now considered an essential element of modern software engineering practice. The long-awaited shift to a higher level of abstraction—from functions and classes to components—is underway.
The following figure models a PECT as a component technology and one or more validated reasoning frameworks and their interpretation. In this figure, abstract component technology specifies the invariants imposed on by a specific component and a collection of reasoning frameworks (each which may impose their own additional invariants). A PECT can and generally will support several analysis models, each of which is “packaged” in its own automated reasoning framework. An interpretation defines an automated translation from assemblies of components specified in the construction language to the reasoning framework. A brief presentation provides a step-by-step development of the PECT.
A more comprehensive treatment of PECT is found in Volume III: A Technology for Predictable Assembly from Certifiable Components.