Volume III: Aiechhology for Predictable Assembly from Certifiable Components

This report is the final volume in a three-volume series on component-based software engineering. Volumes I and II identified market conditions and technical concepts of componentbased software technology, respectively. Volume III (this report) focuses on how component technology can be extended to achieve predictable assembly fi-om certifiable components (PACC). An assembly of software components is predictable if its runtime behavior can be predicted from the properties of its components and their patterns of interactions. A component is certifiable if its (predictive) properties can be objectively measured or otherwise verified by independent third parties. This report identifies the key technical concepts of PACC, with an emphasis on the theory of prediction-enabled component technology (PECT),

This report describes one means of achieving predictable assembly from certifiable components (PACC). An assembly of software components is predictable if its runtime behavior can be predicted from the properties of its components and their patterns of interactions. A component is certifiable if its (predictive) properties can be measured or verified by independent third parties. In our context, component and assembly properties are objective and susceptible to rigorous empirical and/or formal verification.
The goal of the Software Engineering Institute (SEI^^)* PACC Initiative, which was launched in 2002, is to develop and transition the engineering methods and tools necessary to reliably predict the behavior of assemblies of components, and to certify the properties of components necessary to trust these predictions.
The SEFs approach to PACC is prediction-enabled component technology (PECT). A PECT is a development infrastructure that guarantees that critical runtime properties of assemblies of components are objectively analyzable and predictable. A PECT comprises a component technology and one or more analysis technologies. Composition tools ensure that component assemblies satisfy analytic assumptions, thus ensuring that assemblies are predictable by construction.

About This Series
This report is the third-and final-volume of a three-volume series that documents the results of an internal research and development (IR&D) activity of the SEI. This IR&D involved two phases of exploratory research, spanning three years of effort.
The first phase of the IR&D, carried out in 1999-2000, examined the broad outlines of software component technology. In particular, this phase • surveyed, in Volume I, market conditions underlying industry adoption of software component technology [Bass 01] • identified, in Volume n, technical concepts of software component technology, with an emphasis on application development infrastructure [Bachmann GO] These reports concluded that successful adoption of software component technology was inhibited by (1) the indeterminate (and often poor) quality of software components and (2) the lack of engineering techniques to predict the behavior of assemblies of components. Combined, these problems result in a heavy reliance on rapid prototyping in place of analysis and design, and on expensive integration testing and its concomitant late discovery of defects.
Regardless of prototyping and test results, there was a reported expectation that componentbased solutions involve decreases in system quality and increases in project risk.
The second phase of the IR&D, carried out in [2000][2001][2002], was premised on the idea that the specification of components and the prediction of assembly behavior are codependent. In short, the properties of software components that must be trusted should be precisely those properties that support reasoning about assembly behavior. If supported by technology and appropriate business models, this codependency might form the basis of a virtuous cycle between component certifiability and assembly predictability, with advances in one area stimulating advances in the other. An emblematic representation of this premise, on which PACC is predicated, is depicted in Figure 1.

Limits what we can know about assemblies
Specification and measurement of certifiable component properties l\

Reasoning frameworks that enable the prediction of assembly-level properties
Defines what we need to know about components

Figure 1: The Fundamental Premise of PACC
The objective of the SEI's PACC research during 2000-2002 was to define a technological and methodological basis for PACC, specifically linking predictability and certifiability. Examined chronologically • In 2000-2001, the major technological and methodological elements of PECT were defined and demonstrated in a simple laboratory experiment, as described in the paper titled "Packaging Predictable Assembly" [Hissam 02a].
• In 2001-2002, with an industry partner, the SEI applied PECT to a more realistic application area-power grid substation automation-as described in Predictable Assembly of Substation Automation Systems: An Experiment Report [Hissam 02b].
On October 1, 2002, PACC was established as an emerging initiative at the SEI. This report describes the key technical ideas underlying PACC and PECT, in effect defining an agenda for applied research and technology transition for this new initiative.

About This Report
In principle, this report could describe PACC in the abstract and then motivate PECT within this abstract context. However, for reasons of expediency, no attempt is made to find a bright line separating PACC from PECT. Instead, the key concepts of PACC are made material in the form of PECT. A positive aspect of this approach is that this report provides a basis for understanding the SEI's approach to PACC. A negative aspect is that the report is undeniably parochial.

Objectives
The primary objective of this report is to outline the key concepts of PECT. The intent is to describe these concepts in a rigorous way without sacrificing their intuitive appeal. This report provides a theoretical and technological basis to answer the following questions: • What characteristics of an assembly make it predictable, and what kinds of assembly properties can be predicted?
• What characteristics of a component make it certifiable, and what kinds of component properties can be certified?
• How can we achieve objective and measurable confidence in certified component properties and predicted assembly properties?
• Can a technology infrastructure that provides answere to these questions be systematically developed and transitioned into practice?
Answers to these four questions are provided in Chapter 9, It should be noted that this report describes work in progress. It is definitive of the SEI's approach in some cases, and speculative in others. Another objective of this report, then, is to generate constructive criticism of our ideas by exposing them to the scrutiny of the software engineering and computer science research communities, and to interested practitioners.
• This report is not a primer on software component technology, language semantics, formal analysis, empirical analysis, measurement, or certification. Rather, this report addresses their integration to form a PECT.

Audience
This report is intended for a technical audience interested in predictable assembly and component certification in general, but more specifically in the SEI's approach to these topics. It is assumed that the reader has at least surface knowledge of software architecture, formal verification, and measurement theory. Some familiarity with real-time analysis techniques, fault tolerance, and software reliability would be helpful, but is not required.
This report makes occasional use of the Unified Modeling Language (UML) [Booch 99] and the UML Object Constraint Language (OCL) [Warmer 99]; for example. Figure 12 on page 23. Some familiarity with UML and OCL is useful, but because only their simple features are used in this report, no special expertise is required.

Relation to Other Reports
Familiarity with Volume I of this series is not essential [Bass 01], but familiarity with Volume II is assumed [Bachmann 00].^ A straightforward application of the concepts presented in this report to a simple model problem can be found in the paper Packaging Predictable Assembly [Hissam 02a]; indeed, this may be considered a companion report to the present volume. A more comprehensive illustration of the ideas to a nontrivial application area can be found in Predictable Assembly of Substation Automation Systems: An Experiment Report [Hissam 02b], which introduces the notation and terminology of a composition language, CL, and its underlying construction model, Pin. A formal treatment of CL can be found in A Basis for Composition Language CL [Ivers 02], but is not required to appreciate the main points of this report.
All three volumes document, in varying degrees of rigor, the essentials of the SEI's view of PACC and our thinking about PECT. Various workshop papers are also available, some of which address topics not given adequate attention in this report [Stafford Ola], [Stafford 01b], [Wallnau 01], [Stafford 02], [Moreno 02], [Li 02]. Although those papers provide insight into PACC and PECT, they are by intent speculative. Naturally, some speculations have fared the test of time better than others. In short, caveat emptor?

Typographic Conventions
The first defining occurrence of terms that can be found in the glossary are underlined. Formal notations are italicized. Example specifications appear in courier. Important points are highlighted in boldface. Footnotes are used extensively and in two ways: (1) for additional explanation of ideas that may be obvious to most but not all readers, and (2) for ideas that will be of interest to some readers, but otherwise digress from the main flow of the report.

Structure of This Report
The report is organized in three main parts.
Part 1, comprising Chapters 2 through 5, focuses on the technological aspects of PECT. Chapter 2 motivates the main ideas. Chapter 3 describes construction frameworks, which constitute the "component technology" aspect of a PECT. Chapter 4 describes reasoning frameworks, which constitute the "prediction-enabled" aspect of a PECT. Chapter 5 provides a concise summary of how construction and reasoning frameworks are combined to form a PECT.
Part 2, comprising Chapters 6 and 7, focuses on theoretical and, in places, speculative aspects of PECT. Chapter 6 deals with different types of relationships that arise among reasoning fi-ameworks during the construction and use of a PECT. Chapter 7 deals with the crucial topic of compositional reasoning, and, in particular, distinguishes compositional reasoning from reasoning about compositions.
Part 3, comprising Chapters 8 and 9, closes the report. Chapter 8 describes the current status of PECT and areas where further development is planned. Chapter 9 answers the four motivating questions posed earlier. The key to a component technology is its component model, A component model, in effect, imposes design and implementation rules on component developers and application integrators (assemblers). To date, component models have focused mainly on the construction aspects of development-application progranmiing interfaces (APIs), memory management conventions, concurrency management conventions, component and application deployment processes, and so forth. These aspects may all be thought of as imposing constructive constraints on developers; if the constraints are satisfied, an assembly can be constructed, that is, its components can be compiled and linked, integrated, deployed, and so forth.

Motivation for PECT
Volume 11 of this series observed that component models share characteristics with architectural styles."* Both define component types,^ patterns of interaction, and other design constraints. The significance of this observation is that a system's properties^ (e.g,, reliability and performance) correlate strongly to its architectural structure; a style is in essence a structural 4. Shaw and Garlan provided one of the earilest and most extensive treatments of architectural style [Shaw 96b]. The sense of "style" adopted in this report and in Volume II ( pattern [Bass 98]. In particular, Klein and associates showed that the assumptions of certain qualitative and quantitative theories for analyzing quality attributes can be expressed using design patterns such as styles [Kazman 99], [Bachmann 02], what we call "property theories." In effect, these patterns define analytic constraints that, if satisfied, ensure that the design will be analyzable in the constraining property theory, and the behavior of the resulting system will therefore be predictable. A good way to understand the complementary roles of constructive and analytic constraints is to think of a component model as a language that defines well-formedness rules for components and their assemblies. Figure 2 depicts this mode of thinking and introduces some terminology. The box on the left in Figure 2 represents the universe of all assemblies that are well formed with respect to the constraints of some component model. The box on the right represents the universe of all models % in some property theory-a theory that can be used to predict some kind of assembly behavior. The validity of Crests on some assumptions about the systems it models; for example, resource management policies. These assumptions are the analytic constraints imposed by 7^s property theory, ^.j^ is the set of all assembly specifications that satisfy these analytic constraints in addition to satisfying the constraints of the component model. An interpretation 9 maps assembly specifications to analyzable models in the property theory; to relate the results of analysis back to the original assembly specification, the inverse 6. The term "quality attribute" is used In most SEI literature on software architecture. The more generic term "property" Is used in this report. The emphasis in PECT is on runtime quality attributes only (e.g., availability instead of modlflability), and attributes that have objective rather than subjective definition (e.g., latency Instead of usability). Of course, these distinctions can be debated-a system that is unable to perform a runtime reconfiguration might become unavailable, and the usability of an interface can be studied using experimental subjects. Nonetheless, these distinctions have practical significance.
interpretation T^ is defined. Each assembly specification in ^^is analyzable and predictable, with respect to the property theory underlying "TK.
This discussion spotlights two fundamental theses underlying the theory of PECT: 1. A component technology imposes constructive and analytic constraints, and provides tools and environments that enforce these constraints. As a resuh, component assemblies have predictable behavior by construction.
2, Interpretations are defined to component and assembly specifications for analyzable models of assembly behavior. As a result, component properties^ required for predictability are unambiguously defined, establishing a basis for trust and certiflcation.
In more practical terms, the above theses declare that rather than trying to predict the behavior of arbitrary assemblies of components (e.g.,/0, we should construct only those assemblies whose behavior is predictable (e.g., ^. Further, rather than defining subjective notions of component quality, we should rigorously define those component properties that have meaning in some validated, predictive theory.
So far, the discussion has focused on the theory of PECTs rather than the technology itself. Before shifting to a more concrete focus on the latter, it is worth emphasizing that it is not our objective to develop PECT insofar as this implies a single component technology and a particular suite of property theories. That objective would be untenable for at least two substantial reasons. First, there will never be a "one size for all" component technology-^as noted earlier, the key concepts of component technology can be applied to solve widely varying problems, ranging from embedded real-time to distributed enterprise systems. Second, and for an analogous reason, there will never be a "one size for all" property theory.
For these (and other) reasons, it makes little sense for the SEI to define PECT theory in terms of a particular component technology and suite of property theories. Moreover, many software development organizations will be similarly motivated to preserve some conceptual distance between the theory of PECT and the specific software component and analysis technologies 7. This is yet another use of the term 'property." Earlier, the temi was used to denote the subset of quality attributes that are manifested at runtime and objectively observable; they are the properties that are the subject of prediction. Here, the temi '^re^erty" denotes things that are known rather than predicted about a component; these properties are the subject of certification. It might be argued that it Is better to have two temis to denote these two concepts. In Section 3.7, however, a single (formal) definition will be given to "property" that will accommodate both concepts.
used to realize the concept. This motivation provides the rationale for the generic structure of PECT that is described in this report and illustrated in Figure 3.

Prediction-Enabled Component Technology
Abstract

Figure 3: Logical Structure of Prediction-Enabled Component Technology
A PECT has two key ingredients, a construction framework and one or more reasoning frameworks. Each reasoning framework is linked to the construction framework by means of an interpretation.
The construction framework supports the construction activities of component-based software development. The abstract component technology is a proxy for one or more component technologies. It defines a conceptual vocabulary and notations for specifying components, assemblies, and their runtime environments^ in a component-technology-independent way; it also specifies the properties, imposed by reasoning frameworks, that must hold on these component technologies for predictions to be valid. Tools provide automation support for construction activities such as writing assembly specifications, checking well-formedness of assemblies, and generating code.
Reasoning frameworks support the prediction activities of component-based software development; they encapsulate the property theories mentioned earlier. A property theory is a proxy for, and is likely to be a specialization of, some computational theory. It defines a property-specific conceptual vocabulary and notation for reasoning about, and predicting, the behavior of assemblies of components. Each property theory has an associated automated reasoning procedure. Automation is stressed not as its own end, but as a practical means of ensuring that a property theory is explicit and computationally tractable.
Last, interpretations map specifications in the "construction world" to and from specifications in the "analysis world." Interpretations are formally defined; they are complete and consistent translations from the notations defined by construction and reasoning frameworks. Again, formal rigor and automation is stressed not as its own end, but as a practical means of ensuring that there is a sound correlation between constniction and analysis.

Construction Framework
An abstract component technology (ACT) defines a vocabulary and notation for specifying components, assemblies, and their runtime environments in a component-technology independent way, and for specifying the constraints, imposed by reasoning frameworks, that must be satisfied for predictions to be valid. A construction framework is an ACT and the tools that support its use (e.g., editors, constraint checkers, repositories). This chapter focuses on ACT, The following discussion serves two purposes. The first is descriptive: it explains the essential concepts and defines their terminology and notation. The second is prescriptive: it strongly suggests what is required of a concrete component technology if it is to be a suitable foundation for predictable assembly.

Components
Components are the building blocks of predictable assembly, although, as you will see, a substantial amount of component substructure must be exposed in the interest of certifiability and predictability. Components The term implementation distinguishes components from design abstractions in software architecture and architecture description languages [Bass 98], [Clements 96], which also use component as a primitive concept. The term final form means that the implementation is delivered in a form ready to be executed rather than as source code. This is more geneml than the term "binary form" [Bachmann (K)], [Szyperski 97], although it conveys the same idea.' The term binding label refers to linking mechanisms embedded in components to enable their interaction with other components.'^ The interface of a component includes (among other 9. Language interpreters and "just-in-time" compilation biur but do not eliminate the usefulness of this distinction. things) a set of publicly defined binding labels; these labels are used by some composition mechanisms to "bind" the labels of one component to those of another, and therefore enable the components' runtime interaction through those bindings. "Public" definition of these labels allows third parties to compose components on them.
The term "units of independent deployment" is quite subtle, more than is apparent at first glance," with the result that it is quite difficult to propose a completely satisfactory definition. For the purpose of this report, it is sufficient to emphasize one particular aspect of independent deployment: a component is a unit of independent deployment if all its dependencies on external resources are clearly specified, and if it can conceivably be a substitute for, or substituted by, some other component. Each pin has an associated label that denotes its name. Roughly speaking, incoming pinscalled sink pins-denote incoming events to a component, and outgoing pins-called source pins-denote outgoing events, although they may represent other interaction mechanisms as well, such as procedure calls.'^ It is useful to make explicit concurrent behavior in components. Therefore, sink pins also indicate whether they execute on their own thread of control, or on their caller's thread; threads may be shared by sink pins within a component but not across components.'^ Here "thread" does not denote a particular implementation concept, but rather any unit of concurrent execution in the component technology. A component defines a naming scope for (among other things) pins. We use dot notation to scope names. In Figure 4 for example, erg denotes pin TQ of component c. However, fully scoped pin names are used only where ambiguity would otherwise result.

Reactions
Clearly, predicting the runtime behavior of assemblies of components requires that we know something about the runtime behavior of the components themselves. This requires additional specification mechanisms beyond pins, and certainly beyond what passes for interface specification in the vernacular of software developers-the API. The behavior of components is specified as reactions. A reaction specifies the behavioral dependencies between the stimulus of a component and ite possible responses (i.e., between its sink and souice pins). Roughly speaking, a component reacts to an event arriving on a sink pin by emitting one or more events on its source pins.
The simplest form of reaction is a simple dependency relation sRr on component pins such that (s, r)& R indicates that a component will react to stimulus on pin s by generating a response on pin r. This is the minimal characterization of component behavior required to predict any meaningful assembly property. Still, the consensus is that computational models that are richer than a simple dependency relation are needed in practice. We have, in the past, used the CSP process algebra [Hoare 85] to specify reactions.''* Although CSP is a complex specification language, only the simplest features of it will be used in the following illustrations.
Note that reactions can be either complete or abstracted descriptions of component behavior, and can be specified in a "formal" language (such as CSP) or in an "implementation" language (such as Java). The only requirement is that a reaction has a pareable syntax, as is discussed more fully in Chapter 4.
In Figure 5, the reaction RSQ shown inside component c (on the left) specifies that c can receive stimulus on SQ (i.e., RSQ = %..), and its reaction will be to respond through source pins rg and rj (i.e.,...S(]r^rg-^rj...), after which it will be prepared again to receive stimulus on sg (i.e., ...rj-^Rsg). The other reactions are similar. We require that each sink pin appeare in exactly one reaction (although several sink pins can appear in the same reaction), and that each source pin appears in at least one reaction rule. Component behavior is specified as an inter-13. Some restrictions apply to thread allocation. Pins also specify a type signature to accommodate parameters. These and other minutiae are not discussed further in this report.
14. We are currently exploring less complex process algebras such as FSP [Magee 99] and alternatives to process algebra altogether, such as one of Its many variants or statecharts [Harel 951. leaved (indicated by the ||| symbol) and/or parallel (indicated by the || symbol) composition (in the CSP sense) of these reactions. In the example, overall component behavior Re is defined using interleaved composition, indicating that there is no synchronization among the component's reactions. The reaction RSQ, shown inside the simpler component c', is specified directly as a labeled transition system; its meaning is the same as the CSP reaction in c.

Figure 5: Component Interface with Pins and Reactions
As a notational convention, R{s^] is the reaction associated with sink pin s.^, and R[Sji,Sy} is a reaction shared by sink pins s^ and Sy and so forth. R{y} is the overall behavior of component y. Braces ({}) are omitted if confusion will not result, and dot notation is used to disambiguate reactions; for example, C.RSQ and c'.R^o-

Interactions
Where reactions specify the behavior of components, interactions specify the behavior of interacting components. To be a bit more precise, an interaction specifies the composite behavior of two or more reactions. An interaction may only occur between components that have been composed. Two components are composed when their labels (i.e., pins) have been bound.^^ Note that such a binding only specifies that an interaction may occur between two components, not that it must. Note also that the definition of component composition is given in terms of a binding mechanism and not in terms of some abstract operator.
15. In this report, we assume that all Interactions are binary and involve some form of "handshake" between the two interacting components. In general, n-ary interactions are possible (e.g., broadcast interaction), although It is possibly a matter of philosophy whether all such n-ary interactions comprise n-1 binary interactions. Figure 6 illustrates the main ideas. Here components cl and c2 are composed on c/.r and c2.p. Graphically, this composition, or enabled interaction, is shown as a solid line connecting the composed pins. The semantics of composition is defined so that the behavior of composed reactions can be inferred from the reactions themselves. In the illustration, a very simple CSP semantics has been assumed: Rs and Rp synchronize on the shared events, which is achieved by renaming both cl. r and c2.p to x {[xSr] and [xSp], respectively), and then using CSP parallel composition (Rs || Rp).
Again, the details of CSP are less important than the requirement for a defined mechanism for inferring the behavior of composed components. Composition semantics is discussed in the next section.

Enabled interaction
Interaction (

Runtime Environment
As asserted in Volume 11 of this series, a component technology mcludes a runtime environment [Bachmann 00]. That runtime environment (called environment below) is a prominent feature of a component technology, although terminology varies; for example, framework, container, and platform are frequently used. In each case, the environment plays an analogous role: provider of services (e.g., transaction and security services), manager of resources (e.g., thread pools and database connections), and controller of component life cycles (e.g., initialization, preservation, and execution*^). It is quite consistent to think of the component runtime envu-onment as a kind of high-level, component-aware, possibly application-specific virtual machine. * 16. Here, too, terminology varies substantially. Life-cycle terms analogous to the one cited include activation, passivation, and persistence, and they hardly exhaust the alternatives.
Environments, likewise, play a critical role in PECT. However, the PECT notion of environment is more general than the one discussed above. Rather than referring to a specific virtual machine, the PECT notion of environment refers to all relevant aspects of the execution environment that can influence the runtime behavior of components. Specifically, a component runtime environment 1. provides runtime services that may be used by components in an assembly. That is, environments can be thought of as a distinguished type of component with which (or in which) other components, and other environments, may interact.
2. provides an implementation for one or more interaction mechanisms, each supporting its own characteristic interaction protocol (e.g., blocking or non-blocking, buffered or unbuffered, and ordered or unordered interactions) 3. provides a closure for, and containment of, all assumptions made by a reasoning framework about the component runtime environment that can influence assembly behavior. The graphic in Figure 7 introduces terminology and graphical conventions. First, environments, like components, are represented as boxes. Also, like components, environments have interfaces (in this illustration represented by the ♦ symbol-junctions on the environment boundaries), although later illustrations will extend this iconography to different types of environment services. Unlike components, though, environments have internal structure: they can contain components and other environments (a discussion of containment is deferred until Section 3.5).
The graphic in Figure 8 shows the main ideas of item (2) above and, likewise, introduces terminology and graphical conventions. The interaction mechanisms provided by an environment are encapsulated by connectors. A "connector" is best thought of as an environment-provided component whose behavior enforces an interaction protocol, or discipline, on the participants of an interaction or sequence of interactions.

Graphic Connector Behavior (Informal)
Asynchronous (e.g., event-based) interaction." Unbounded priority queue. The priority of events is taken from the priorities of the reactions that emit them.
Asynchronous (e.g., event-based) interaction. Bounded first-in, first-out (FIFO) queue of length n = maximum number of events. Oldest events are discarded on queue overflow.
Synchronous (e.g., call-return) interaction. Semaphore acquired by calling reaction (i.e., the reaction on s is a [protected] critical section).
Gateway from environment E to containing environment Ef. Synchronous interaction is preserved. No semaphore is required (i. e., r is reentrant).
a. Reaction on source r does not wait for reaction on ^nl< s to complete.

Figure 8: Connectors Provided by IHypottietical Environment
The graphical notation of connectors has already been encountered, at least in part-^the line connecting the component pins in Figure 6 on page 17 denotes a connector. Additional connector information can be encoded on the lines or in the symbols used to denote pins. Examples of the former are the pri for "priority queue" and [n] for "bounded queue" connectore in Figure 8 (the first two entries). Other examples are the use of the > symbol to denote connectors for event-based interaction (the first two entries) and the >l symbol to denote connectors for protected critical sections (the third entry).
The behavior of each connector in Figure 8 is specified in such a way that the composite behavior of the participants in an interaction can be inferred from the behavior (reactions) of the participants themselves. The informal behaviors described in Figure 8 convey only a sense of what a complete connector specification must describe; in some circumstances, details such as threading and caching may also be required. Ivers and associates provide a detailed example of connector specifications (in CSP) for a mix of interaction protocols [Ivers 02].

Assemblies
The abstractions discussed in the preceding sections provide the necessary machinery to define what we mean by assembly. An assembly is a set of components and their enabled interactions. Since interactions are enabled by environments, each assembly is associated, through deployment, with exactly one environment.
Components are deployed to rantime environments; deployment defines where (ultimately, on which machine) behavior is executed. It is also sometimes useful to think of an assembly as being deployed on an environment, although, strictly speaking, assemblies have no behavior other than that provided by their constituent components. A:E denotes the assembly A deployed in environment E.
Components and assemblies are contained by other assemblies. Containment introduces hierarchy, with A.c denoting component c contained in assembly A,A1.A2 denoting assembly A2 contained by assembly A], and so forth. Containment defines a constructive closure-that is, the scope of all component interactions is restricted to (or closed within) the component's immediately containing assembly.
The following illustrations are meant to appeal to the reader's intuition; they are intentionally abstract and, in various ways, incomplete. For example, details such as allocation of environments to processors are ignored.'^ Assume, for the present, that each environment denotes a distinct running instance of some (as yet anonymous) environment type; analogously, consider each component in Figure 6 to be a runtime instance of some anonymous component type.
assembly name current_teinp _20ms_Alarin I change_pos Figure 9: A Simple Controller Assembly Figure 9 shows a simple two-component assembly. Controller, whose components are deployed in the runtime environment, RTOS. The environment provides three services: one service generates an alarm every 20 milliseconds (ms) (_2 Oms_Alann), one provides system temperature (current_temp), and one changes the position of some device (change_pos). Although reactions are not shown, one scenario for the behavior of Controller is that the Sensor component reads the current temperature of some external system every 20ms and, based on what has been read, issues a command to the Actuator component. Figure 10 illustrates another form of hierarchy. Controller'^ from Figure 9 has been replicated, and each replicant is deployed into its own RTOS environment; these environments are, in turn, linked, via gateways, to the Voter component.   Figure 11. In Figure 10, the three controllers were deployed assemblies. In Figure 11, the Controller_iV assemblies and Voter component are partial assemblies. Like assembly, a partial assembly defines a scope of interaction. In this case, however, the scope is not associated with its own runtime environment; it "inherits" the runtime environment of its immediately containing assembly. Partial assemblies hide their contained components, but can expose selected pins through null junctions. A null junction has no behavior, it simply "unhides" selected pins. In Figure 11, Controller_2 is shown; the other controllers arc, of course, not requircd to have identical internal structure. The notion of hierarchy via partial assembly seems, on the surface, to be quite simple and natural. However, there are subtleties-in particular concerning analytic closures. An analytic closure defines a scope for assumptions that underlie predictions of assembly behavior. It is important to note that scopes defined by constructive and analytic closures do not always coincide; nor, in fact, do the scopes defined by different analytic closures (for different reasoning frameworks) always coincide.

Assembly Constraints
The previous sections described, in effect, a graphical language for an ACT consisting of components, reactions, interactions, environments, and assemblies. However, that description has not been particularly formal or complete. For example, the rules for well-formedness in the language are, for the most part, implicit. This informality is a necessary compromise, because a complete and formal description of a visual language is nontrivial, and its exposition would certainly distract from the objectives of this report.
In any event, to specify an ACT there must be at least one intended (target) component technology, and, insofar as ACT is specific to PECT, one intended reasoning framework. In particular, recall, from Chapter 2, that an ACT serves to make explicit constraints imposed by a component technology and one or more reasoning frameworks. In practice, then, well-formedness constraints will exist on components and their assemblies in addition to those discussed in Sections 3.1-3.5, which describe only the essential features of component technology. l^r*rs*io<^<-<-k»- Figure 12 illustrates well-fonnedness constraints that might be imposed by a component technology or reasoning framework:*'

Figure 12: Extending the Well-Formedness Rules of an ACT
• An assembly must have at least two components.
• Each component must have at least one sink pin and at least one source pin.
• Each sink and source pin must be connected exactly once.
• A component cannot be connected to itself (see the OCL annotation on Connector), • An assembly is well formed if and only if all pins are connected (see the OCL annotation on Assembly).
This particular set of well-formedness constraints is easy to specify and underetand, since it concerns syntactic (or topological) aspects of components and assemblies. Other constraints may go beyond well-formedness, specifying behavioral rather than syntactical constraints. For example, a reasoning framework might require that the component runtime environment enforces a specific scheduling discipline (e.g., the earliest deadUne first) or that components conform to a particular start-up and shut-down sequence.
Assembly constraints include the well-formedness and behavioral constraints imposed on an ACT by one or more component technologies and one or more reasoning frameworks. A construction framework comprises an ACT, tools to enforce the constraints imposed by an ACT, and other tools useful to automate the specification, development, and deployment of components and their assemblies.

Properties
Referring back to Figure 1, PACC is concerned with predicting what is unknown-assembly properties-from that what is known-component properties. A flexible but uniform treatment of both kinds of properties is desirable.
A property is an «-tuple <name, value,... >, where name and value refer to the name of some property and the value it takes, respectively. The "..." portion of the definition refers to arbitrary and, perhaps, property-specific information. For example, it is often necessary to include a confidence interval with a property value.^^ However, at this level of generality, property types, hierarchies of property types, and the value sets of property types are not needed. Such details may ultimately be important, of course, but it is best to sidestep these complexities for as long as possible.
An annotation associates a property with a referent. An association of property P with referent R means that "R has property P" and is denoted as R.R Although Figure 1 on page 2 implies only two kinds of referents-components and assemblies-that is far too restrictive. In fact, several kinds of referents have already been introduced: component, assembly, pin, reaction, environment, and environment service. Generally speaking though, properties of assemblies 20. Our notion of property annotation is an amalgam of Ideas found in the Acme architecture description interchange language [Garlan 97]-which uses annotations to support extensible analyses-and credentials [Shaw 96a]-a proposal for treating architectural annotations as conjectures modified by the evidence to support the conjecture.

24
CMU/SEI-2003-TR-009 are predicted, while all other properties are asserted. That is, assembly properties are the purview of prediction, while all others are the purview of certification.  Figure 14 shows an annotation with a slightly more complex structure than that shown in Figure 13. The annotation appears to be attached to the alarm junction of the RTOS environment, but the actual referent is the series of interactions beginning with a response by the RTOS envu-onment-alarm-^and ending with a stimulus on the RTOS environment-cliange_pos. One interpretation of this annotation is that the predicted end-to-end latency of the series of interactions is 139ms, a 95% tolerance interval, with an upper bound of 155ms and a confidence of 80%. This is, however, just one possible interpretation of the latency annotation. In fact, all of the annotations in Figures 13 and 14 are undefined, because they have not been assigned an interpretation in some reasoning framework. Assigning meaning to component annotations is discussed in Chapter 4.

Construction Language
The graphical notation and concepts discussed above constitute an informal language for describing an ACT. A more formal definition is required to serve as a basis for automated interpretation from assembly specifications to analyzable models of assembly behavior. A construction language defines a concrete syntax for specifying ACTs, and for specifying components and assemblies of components that are well formed in ACTs. Each interpretation defined on a well-formed assembly can be thought of as assigning a semantics to the assembly.
The new jargon ("construction language") adds to a field already crowded with composition language, architecture description language, coordination language, and module interconnection language. Admittedly, the boundaries among these different classes of notations are imprecise, and, in fact, particular notations are often classified in several ways.^' The introduction here is motivated by distinctions between what is needed to specify an ACT and what is provided by these existing classes of notation, such as the following: • Components in architecture description languages tend to be design abstractions, rather than independently deployable component implementations in final form.
• Module interconnection languages tend to assume a fixed and limited repertoire of component interaction mechanisms, and do not represent "style" or "pattern" constraints.
• Coordination languages tend to ignore constructive issues such as module boundaries and focus instead on abstract behavioral specifications and their compositions.
• Composition languages tend to emphasize their roots in object-oriented (OO) programming languages, largely because their early formulations emerged from OO research.
Nonetheless, there is also significant overlap between these classes with one another and with the construction language concept discussed in this report. For example, the semantics for composing behaviors in the Piccola composition language [Achermann 01] is an earlier-speci-fied 7t-calculus variation of the CSP semantics defined by Ivers and associates [Ivers 02]; and the Acme architecture description interchange language [Garlan 97] defines syntactic elements for components, connectors, and annotations. In short, the new term "construction language" may not be justified in the long term; in the near term it is used to emphasize the distinctions.
A concrete syntax for one possible construction language has been specified. The construction and composition language (CCL) fragment in Figure 15 specifies the CSWI component used to implement a high-speed switch controller (see the substation automation case study for details [Hissam 02a]). Note that the sample specification assumes the use of CSP to specify reactions,^^ (The meaning of the annotation is discussed later in Section 4.4 on page 33.) annotate react <SwitchR, claim: string = "!E["(output = _sbosel_on) U (output = _sbopos_open)]"> end CSWI.

Figure 15: Component Specification in CCL
The CCL syntax also allows for the specification of environments (their services and connectors) and assemblies, and for the attachment of semi-stractured annotations to an explicitly defined set of syntactic referents (component, assembly, pin, reaction, etc).

Reasoning Frameworks
We want to reason about, and ultimately to predict, the behavioral properties (hereafter, simply properties) of assemblies. Our concern is with properties such as: the time it takes an operation to complete (latency); whether an operation exhibits erroneous behavior, and, if so, how frequently (reliability); whether an operation can always respond to a certain stimulus (liveness); and whether an operation invariably preserves certain conditions (safety). This is not a closed or precisely defined list, but it serves as a broad indicator of the different types of properties that are of interest to practicing software engineers.
Invariably, reasoning about complex systems requires the use of models. In general, a model is an abstraction that exposes some aspects of a system while simultaneously suppressing (or abstracting) others. A scientific theory provides models that objectively describe^^ the observable phenomena of natural or artificial systems,^* and predict future observations in those systems. A scientific theory is always susceptible to falsification-^that is, its predictions can be subjected to tests designed specifically to refute (falsify) the theoi^.^^ Property theories in PECT can be thought of as scientific theories about a particular runtime behavior, or property, of assemblies-^they must be objective, predictive, and testable. Prop-23. A scientific theory need not explain the cause of a phenomenon. For example, Newton's laws of motion described the effects of a hypothesized attractive force called gravity, but an explanation of these phenomena was not offered until Einstein fonnulated his general theory of relativity. Analogously, the ideal gas laws describe, but do not explain, the relation of pressure, temperature, and volume to each other.
24. This distinction is discussed at length by Herbert Simon in his classic The Sciences of the Artificial [Simon 96]. Natural systems are the purview of the traditional natural sciences such as physics, biology, and geology, while artificial systems are the result of human artifice. Simon argued that the scientific method developed for natural systems was applicable to, and required for, reasoning about modern artificial systems. A strong argument can be made that computing systems are artificial systems in the purest sense of that term, with complexity rivaling, If not exceeding, that of any other class of artificial system.

The falsif lability of scientific theories Is the subject of Kari Popper's classic The Logic of Scientific
Discovery [Popper 92]. Note that scientific models need only be falsifiable in principle. That is, an approach to falsification may be well defined but not technically feasible; for example, because of the limits of experimental apparatus. For example, there are models of quantum physics whose falslfiability, even in principle, is a matter of doubt. erty theories must also be susceptible to automation so that their complexity can be, to the maximum practical extent, hidden from the end user-the practicing software engineer.
A PECT reasoning framework comprises a property theory, an automated reasoning procedure, and a validation procedure. These parts are discussed in Sections 4.1^.3. The overall concept is illustrated with three reasoning frameworks, in Sections 4.4-4.6.

Property Theory
The design of an effective property theory can, and usually does, require significant theoretical knowledge and intellectual effort.^^ In short, its development requires a feat of ingenuity and skill no less than that implied by the development of any scientific theory. It is a research activity that, with luck and persistence, might eventually bear fruit in practice.
As discussed in Chapter 2, our objective is not to develop new property theories, but rather to specialize (restrict) existing ones to particular sets of systems, and, in this specialization, to satisfy required accuracy while also obtaining ease of use through automation. To understand how to achieve this, we must be more precise about the structure of a property theory. The basic elements of a PECT property theory are • a calculus, which is "a system or arrangement of intricate or interrelated parts" [Merriam- Webster 93], where, in this context, the parts are symbolic • a logic, which defines rules for transforming one sequence of symbols to another, establishing "principles and criteria of validity of inference and demonstration" [Merriam-Webster 93] • an abstract interpretation, which is a map from the symbols of a calculus to elements of a (not necessarily component-based) computing system The generality of this definition of property theory reflects the broad range of such theories that can be used in a PECT, while its formality reflects the emphasis placed by PECT on automated reasoning.^^ 26. The following description of a property theory is based loosely on Hoare's paper, "Algebra and Models" [Hoare 93]. In that paper, Hoare outlines an approach to developing algebraic models for reasoning about systems. The adaptation of Hoare's ideas in this report generalizes from algebraic models to arbitrary calculi and logics; limiting PECT reasoning frameworks to algebraic models would be too restrictive. The generalization does no violence to Hoare's ideas, however. It is also worth noting that Milner observed, in the introduction to his process algebra, that nonalgebraic calculi, such as first-order logic, have their usefulness in conjunction with algebraic models [Milner 89].

Automated Reasoning Procedure
An automated reasoning procedure has three distinct elements, each of which must, in principle, be automatable: a decision procedure, a definite interpretation, and an definite inverse interpretation, where • A decision procedure is a function that evaluates claims made on assemblies described in the property theory to the values "true" or "false." • A definite interpretation maps assemblies specified in a concrete syntax of a construction language to strings in the input language of the decision procedure, • A. definite inverse interpretation maps the results of the decision procedure back to the concrete syntax of the construction language.
Limiting decision procedures to evaluate claims to boolean values is not as restrictive as it might appear, A quantitative prediction of end-to-end latency of interactions can always, for example, be expressed as a boolean claim that latency does not exceed some value. The real effect of the definition, however, is to rule out decision procedures (and, indirectly, property theories) that cannot be used to express claims that are verifiable or, at a minimum, falsifiable.
Decision procedures must, of couree, be computable, but there are no other restrictions on the type of algorithms used. In particular, a decision procedure could compute the value of a closed-form expression or compute its approximation using iterative means, do an exhaustive search, or perform a simulation. In general, complete decision procedures are preferred to partial procedures, but are not required. The only requirement is that if the procedure terminates, it yields a verifiable or falsifiable claim.

Validation Procedure
The most accurate predictions are of little use if they are not trusted. This trust is indispensable to achieving a fruitful separation of concerns among component developers, component certifiers, and application assemblere. Without trust in component properties, excess effort will be expended revalidating claims about components. Without trust in assembly predictions, excess effort will be expended in integration testing. Without trust in both, there will be little hope of establishing a value proposition for certified components or predictable assembly. A robust value proposition is needed, because the technical and social infrastructure for "trust" will require up-front investment that must be justified in terms of future efficiencies.
A validation procedure provides objective evidence for trusting the validity and soundness of a reasoning framework; it also defines its required component properties with sufficient rigor to provide an objective basis for trust in assertions of component behavior. A reasoning framework is valid if its predictions match observations and sound if its theorems, relations, and so on can be mathematically demonstrated.
As observed by Meyer and associates, trust is a social phenomenon likely to be achieved through a mix of technical and nontechnical means [Meyer 98]. These same authors also observed that trust is not absolute except in matters of religious faith. Looking beyond Meyer's concern with trusting that a component implementation is correct, the means for establishing trust depends on qualities inherent to the • property theory-for example, is it a stochastic or deterministic theory?
• to the problem domain-for example, is human safety of concern?
• and to the business context-^for example, how much value accrues with additional evidence?
Minimally, the weight of objective evidence must justify a value proposition for component certification and other infrastructure development.
There are, however, two classes of objective evidence that are worth distinguishing: empirical evidence and formal evidence (in Polya's terminology-plausible and demonstrable evi-denced^), because different schools of thought place more trust in one form of evidence than the other. However, to the extent that these forms of evidence are truly distinct, both are needed. Empirical evidence is acquired through direct observation, preferably under controlled circumstances, with results reported in well-defined units of measure. Empirical evidence is therefore provisional, as any other observation might have been diiferent; hence, conclusions based on empirical evidence are, to a lesser or greater extent, only plausible. Formal evidence is acquired through mathematical proof and is therefore irrefutable, as all such proofs are tautological; hence, conclusions based on formal evidence are inevitable or demonstrable.
In fact, both empirical and formal evidence have roles in providing objective confidence in property theories and in the asserted values of component properties. Different types of theo- ries and properties will result in different emphases on one or the other. For example, properties with established measures of magnitude, such as time and space, are more susceptible to empirical treatment than are properties with less obvious measures, such as reliability. The following statements illustrate the mix of reasoning used to establish trust: • A reasoning procedure for predicting the absence of a behavior in an assembly might be defined in automata theory and temporal logic; the resulting claims will be demonstrable. However, establishing that a particular automata describes the behavior of a particular component will involve, ultimately, observation.
• A reasoning procedure for predicting the execution latency of an operation in an assembly might be defined as equations involving the measured time of components; the resulting claims will be plausible. However, the equations themselves might be derived from theorems whose validity must be formally demonstrated.
It is well worth repeating that the level and kind of objective evidence required to establish trust in predictions will vary from situation to situation.^' Note that the problems of establishing trust in component properties and predictions are strongly interrelated, as premised in the introduction to this report (and implied by Figure 1 on page 2). This report is focused primarily, however, on PECT. A full treatment of how empirical and formal property theories are validated and how component properties arc certified will be the topic of a future report. Only a passing treatment of the topic is provided through the following illustrations.

Illustration 1: Temporal Logic Model Checking
Temporal logic model checking (hereafter simply called model checking) is a technique for formally verifying system properties such as safety (informally, a certain condition never occure) or liveness (informally, a certain condition eventually occurs).^'' 29. In fact, it has been argued that the notion of a demonstration in a proof is also subject to different degrees of rigor, ranging from fully fomial (mechanized) proof in the Hilbert style, to sketches of proof templates In which more can be assumed about the social context of a proofs audience [DeMillo 77].
30. Model checking has been used widely and successhilly to verify hardware design; significant effort has been made recently to apply it to software design as well. There are many books and articles on the subject of temporal logic model checking. See Huth's woric for a gentle but thorough introduction [Huth 00] or the work of Clarke and associates for a more In-depth and theoretical treatment [Clarke 99].

Property Theory
The property theory for model checking combines automata theory and temporal logic-in model checking literature, property theory is usually described as a combination of a computational model and a specification language for a particular class of temporal logic claims. There are many variations in the automata theory and temporal logics used, and each combination is equipped with its own rigorously defined (i.e., purely formal) calculus and logic. Although the distinctions among these property theories are theoretically important, they all bear strong family resemblances to one another. The illustration sidesteps distracting nuance.

Automated Reasoning Procedure
The decision procedure used in Illustration 1 is provided by the SMV model checker.^' The top half of Figure 16 shows a state machine corresponding to the CSWI. SwitchR reaction shown in Figure 15 on page 27. There, the temporal logic claim was expressed, in the annotation, directly in the notation of SMV; ideally, a neutral syntax would have been chosen.
In natural language, the claim reads, "it is never possible for the switch to be opened (_sbopos_open) before it has been selected (_sbosel_on)." 31. See <http://www.cs.cmu.edu/-modelcheck/smv> for details on this model checker.
The bottom half of the graphic shows a fragment of the input string to the SMV model checker. The last line of the SMV is the annotated temporal claim; the rest corresponds to the SwitchR component reaction.

Figure 16: An Interpretation for Model Checking
The scheme for translating the component behavior specified in CSP into SMV involves considerable complexity. The translation scheme for composing reactions specified in CSP was worked out in A Basis for Composition Language CL [Ivers 02]. The translation from composed CSP reactions to the input language of SMV was not formalized, although the outlines of an interpretation can be gleaned from CSP event names in the CSWI. SwitchR reaction, and the state and variable names used in the input string passed to SMV.
The key points are (I) a mechanical translation from CCL to SMV is possible, in principle, but its definition is complex, and (2) the resulting SMV is not easily comprehended by the end user. However, the complexity is apparent only once, when the definite interpretation is defined, and the resulting SMV input does not have to be made visible to the end user, any more than the internal results of any "code generation" process need to be exposed. All that is required, instead, is the inverse interpretation that maps the results of a decision procedure, SMV in this case, back to the original specification in CCL.

Validation Procedure
Model checking is a form of verification; the soundness of the model-checking algorithm is demonstrated by proofs involving; for example, the fixed-point semantics of the temporal logic operators.'''^ Therefore, the basis for trusting the results of model checking depends on confidence 1. in the implementation of the model checker itself 2. that the finite models of component behavior used in the model checker are satisfied by the components (i.e., the implementations) they represent Confidence in item (1) above is generally obtained by testing the model checker. Whether or not it's justified, most users trust the implementation of a model checker.^^ University-developed software might be regarded with some skepticism, but some model checkers are supported by commercial vendors, helping to obtain a level of trust.
Confidence in item (2) above is a more difficult matter. Some research prototypes extract state machines directly from source code [Corbett 00]. In that case, the formal translation process from source code to state machine (in fact, a definite interpretation in the PECT sense) reduces the question of trust to one of trusting the translator's implementation; an analogous situation arises in the reverse case, where components are derived from state machines. Some form of testing is required where state machines are not "formally" linked to components; for example, where state machines and components are implemented manually [Havelund 01]. Rate monotonic analysis (RMA) is a technique for determining, among other things, whether a set of tasks can be scheduled for execution in such a way as to guarantee that hard-real-time deadlines are always satisfied.^^ Actually, RMA is a system for constructing property theories, although it does include results (such as the Lui Layland theorem discussed below) that can be thought of as property theories in their own right.

Property Theory
In addition to the usual symbols of classical algebra and finite mathematics, the RMA calculus defines symbols for tasks, parallel and sequential composition of tasks, task priority, period, task execution time, processor utilization, queues, and so forth. The underlying logic of RMA is based in classical algebra, with key principles and results expressed algebraically. This illustration makes use of the Liu and Layland theorem, which states that a set of n independent periodic tasks, when scheduled using a rate monotonic algorithm, will always meet its deadlines, for all task phasings, if Eq.l =i + ... + -2<U(n) = n(2^/"-l) ^1 ^n where Q = worst-case task execution time of taskj, 7} = period of tos% and U(n) = utilization bound for n tasks.
RMA was used as a basis for the X^g A property theory discussed extensively in the substation automation case study (see [Hissam 02b]). This property theory predicted the latency (X) of the longest execution path in an assembly, for the Average case latency, where components could Block one another, and including Asynchronous interactions (ABA). A preliminary form of the property theory predicted worn case latency with blocking for synchronous interactions only (X^B); this simpler theory is more convenient for illustrative purposes. The formula in Eq. 2 predicts the worst-case latency L,-for the i task. Q is the execution time of the j'^ task; Tj is the period of the rth task. Tasks 1 through i-l are assumed to be all the tasks whose priorities are higher than the priority of task /. The iterative calculation starts by using C,-as the first guess for the worst-case latency by setting Lj to Q, and it then computes L"+] using the formula. It continues until L" = L,,^.;, at which time the fixed point has been reached, and L"+7 is the worst-case latency.
Automated Reasoning Procedure Figure 17 shows yet another variant of the controller assembly. Two sensors are in that assembly, each connected to its own actuator, but both connected to the same temperature gauge. In this figure, the reactions on asynchronous sink pins (>) are assumed to execute on their own threads of control, and are therefore schedulable tasks with fixed priorities, while the reactions on non-blocking synchronous sink pins (>) execute on the caller's thread of control.
The interpretation is straightforward. First, observe that, in contrast to Figure 16, this interpretation requires annotations: the period of the alarm service (7} in Eq. 1), the priority of threads Senl .wake: t and Sen2 .wake: t,^^ and the execution time of reactions (C,-in Eq. 1). Since Actl. set and Act2 . set are not threaded, they are not schedulable in RMA, and they have no priority assignment. The execution time for the Rset reactions is simply added to the execution time of the calling reaction.
The decision procedure for A-^VB was more complex, but fully automated (again, unlike Figure  16, which was automated only "in principle"). The interpretation scheme translated assemblies specified in CCL^^ to an input string of a simulator developed especially for the property theory. The simulator used a combination of analytic and iterative means to compute the fixed point of a set of tasks sharing the same processor, and from that fixed point, the latency was derived.

Validation Procedure
Unlike model checking, RMA theories depend explicitly on measured (emphical) phenomena: execution time-an explicit parameter of the property theory-and blocking time-^the property that is predicted (i.e., latency = execution time + blocking time). While many of the basic results of RMA are demonstrable (e.g., Lui-Layland), trust in the overall effectiveness of the property theory rests on empirical, experimental evidence.
Trust in the effectiveness of X^g depends on statistical trust in the 1. quality of X^B predictions

measures of component execution time
Confidence in the quality of X^g predictions required the development of a measurement infrastructure for collecting timed traces of component and assembly execution in a controlled environment. Also required was a statistically valid (representative) sample of assemblies, so that a confidence interval for the property theory could be obtained. The technique used to generate this sample combined elements of random graph generation and topology constraints to restrict the random assemblies to those that were, in some predefined way, "stereotypical" of the intended application.
Confidence in the measures of component execution time also required the development of a measurement infrastructure-this time for collecting traces of component execution time in a controlled environment, where the total blocking time of a component under all execution traces could be eliminated. As with the property theory itself, a statistical measure of confidence was obtained that reflected an inherent quantum of nondeterminism (random measurement error) introduced by the runtime environment and additional measurement apparatus.
In both cases, trust was established using statistical means for A^VB statistical confidence in the representativeness of the random sample and for component measures' statistical confidence that the component execution time established in a measurement environment would be equivalent to the execution time in the deployed runtime environment.

Illustration 3: n-Version Majority Voting Analysis
Many design patterns have been developed to make systems more resilient to hardware and software failure.^^ Most (if not all) of these patterns are based on some underlying notion of redundancy. The form that this redundancy takes in Illustration 3 is the n-version majority voting (NVV) pattern. In the NVV pattern, a reliable voting component chooses the majority response from a set of n unreliable components, where each component computes the same function but has a different implementation (i.e., n versions).
Note that, unlike Illustrations 1 and 2, the NVV reasoning framework is more a thought experiment than reality. It is introduced here as a foil for exposing different aspects of PECT theory. Nonetheless, while NVV is a thought experiment, doubts about its realism can be challenged, as will be discussed in Section 6.2 on page 47.

Property Theory
A simple calculus is defined for this example. In addition to the usual symbols of classical algebra and discrete probability theory, the symbol n is defined to denote the probability of component failure. As with most theories of reliability and fault tolerance, the underlying 37. Musa's Software Reliability Engineering is widely cited as being authoritative [Musa 98 logic is based in probability theory. In this contrived property theory, the reliability of an assembly of components using the NVV pattern is given as where pFail = the probability that an assembly will fail, n = the number of unreliable components, m = (n + 1) / 2 for odd n, and n = the probability of component failure. Of course, this is nothing more than the sum of simple binomial distributions of the probability that a majority k out of n components will experience a failure on some event, where k e {m, m+1,..., n].
Although the theory is undeniably simple, it captures the essence of the voting pattern.

Automated Reasoning Procedure
The illustration in Figure 18 reprises Figure 11 with minor modifications. In this example, the failure rate of unreliable components is specified as an annotation on the partial assemblies, cl, c2, and c3. The reliability claim is the topmost, boldfaced annotation in the figuiB.^^ It asserts that the probability that the end-to-end interaction starting with one of the three RTOS alarms and ending on RTOS.temp will fail (pFail) is less than or equal to 1x10'^.
38. The notation for the interaction omits pin names for brevity. As with CSP, the symbol || denotes parallel composition. The intent is that the reactions composed by -^ in (aMj) || (c-^) execute concurrently.

Figure 18: An Interpretation for Reliable Voter Pattern Reliability Analysis
The interpretation uses the sink annotations to fill in the value of n in Eq. 3 and the assembly topology to fill in the values of n and m. The decision procedure for the property theory, as formulated, is a trivial mathematical function and interpretation. More complex decision procedures (e.g., using Monte Carlo simulations of failure rates with probability distribution functions) can be envisioned.

Validation Procedure
Similarly to RMA-based property theories, the NVV property theory is parameterized by, and predicts, an empirical (observable) phenomenon: rate of failure. Accordingly, confidence in the NVV property theory will be based in part on demonstration (e.g., the applicability of basic probability theory) and experimental evidence. However, while time is, for all practical purposes, a universally understood phenomenon, the failure rate of software components is not. Still, it is possible to fix on a particular definition of failure rate (e.g., the number of "hard crashes" per invocation for each reaction) and obtain a statistical measure of a property defined in this way through established testing procedures.

Concise Summary of PECT
A PECT extends the notion of a component technology with one or more reasoning frameworks, such that assemblies of components are predictable with respect to those reasoning frameworks. In Figure 19, a UML class diagram illustrates how a component technology relates to reasoning firameworks in a PECT. A component technology is incorporated into a PECT by means of a construction framework. Such a framework consists of an ACT and a construction language. An ACT is a description of a particular component technology in a construction language. ACTs are described using a common language-a construction language-to allow the same tools to be used with PECTs containing different component technologies.
The construction language is also used to describe assemblies constructed in accordance with the ACT and associated reasoning frameworks. A construction language includes the syntactic elements needed to capture three kinds of information: 1. the topology of an assembly (the composition of components that defines the structure of the assembly) 2. the behavior of each component in the assembly, the interaction mechanisms defined by the component model, and the services provided by the component technology's runtime environments 3. arbitrary property descriptions that are required by specific reasoning frameworks and attached to various syntactic elements, such as components or interactions Each reasoning framework included in a PECT embodies the concepts and theories needed to analyze, and hence predict, properties of an assembly of components. An interpretation is defined for each reasoning framework of a PECT that relates the concepts of the ACT to the concepts of the reasoning framework. An interpretation is used during development to translate an assembly specification, as documented using the construction language, to a specification that can be used with the interpretation's reasoning framework.

Multiple Reasoning Frameworks
The value of PECT will be enhanced as reasoning frameworks are developed, validated, and, possibly, certified. However, additional complexity also attends the introduction of multiple reasoning frameworks. Questions will arise, for example, about the consequences of using one reasoning framework in place of another, or about whether reasoning frameworks that have contradictory assumptions (assembly constraints) can be safely used together.
The situation is shown informally as a Venn diagram in Figure 20, which refines the earlier depiction in Figure 2 on page 8. Figure 20 shows several reasoning frameworks, and the space of possible assemblies has been subdivided into a number of distinct sets, each containing the assemblies that are well formed with respect to a reasoning framework theory whose models (input to its decision procedure) are in the set^. To illustrate, perhaps % and % model different properties; for example, security and performance (what will later be defined as heterogeneous properties). Since the well-formed assemblies for these reasoning fi^meworks are equivalent in extent (/fj = ^). all is well. However, what if we now add M^ that models, say, reliability? How will it be ensured that only the intersection n{^2»^3' ^5) is constmcted? Alternatively, given an assembly, is it possible to infer which reasoning frameworks are applicable?
We do not yet have robust answers to these questions. However, the concepts elaborated in the earlier chapters appear to provide a good foundation for providing answers-and indeed some progress has been made already. This chapter outlines, in Sections 6.2 through 6.4, what we already know about several key issues introduced when considering multiple reasoning frameworks, and how these issues can be addressed. Section 6.2 addresses the question "when does a simple theory become too simple?" This discussion is a precursor to Section 6.3, which discusses co-refinement-the process by which an optimal balance is achieved among various qualities of property theories, including simplicity. Section 6.4 discusses the issue of incompatibilities among reasoning frameworks, while Section 6.5 discusses some still speculative approaches to dealing with these incompatibilities. This last is an area for needed research.
Before embarking, though, formal definition of some key terms (in Section 6.1) will prove useful. Readers not formally inclined may skip Section 6.1 and refer to it only when encountering unfamiliar terms or notation.

General Definitions
• Let/^= {al, a2,..., ak} be the set of assembly specifications, in CCL, that are well formed with respect to the constructive constraints of some ACT.
• Let T= {Tj, T2,..., Tx) be the set of property theories, embedded in reasoning frameworks, that are integrated in the same ACT.
• Let%x = {mix, '"^x,..., mkx) be the set of models in (or input strings to) the decision procedures of property theory Tx.
• Let 1= : /^xTbe the "satisfies" relation such that a N T^x <=^ ^P^^x ^ ^x' P^yS<^)-that is, an assembly a satisfies property theory X if and only if a satisfies X's analytic constraints.
• Let ^x^ -^ X ^x be the "interpretation" relation such that {a, m) e ^x <=** ^ •" ^x' ^^^ ^ derives m through some sequence of syntactic transformations.
• Let/fx = {^x I 3w(flx, m) e ^x) be the set of assembly specifications that satisfy and have interpretations in Tx. We say "assembly a is well formed with respect to Tx" if and only if aG/^x-

Simplistic Versus Realistic Property Theories
Practitioner and theorist alike will be skeptical of the NVV pattern and its accompanying equation in Eq,3, referred to as TNW, or "the [reliability] theory" in the following discussion.
In fact, the theory might be dismissed out of hand as being simplistic, perhaps justifiably so.
Still, being explicit about the basis for this dismissal highlights useful aspects of the theory of PECT.
The reliability theory can be mooted in a number of ways; for example, the vagueness of the definition of failure rate. However, our concern is not with reliability theory itself; assume that "failure rate" has a precise meaning and is measurable on components. Instead, our concern is with whether Tjjvv i^ "simplistic" in the sense that it is unrealistically simple. To address this concern, it helps to look at analytic assumptions that are implicit in the theory.^' A small selection of assumptions is presented in Table 1 (there are many assumptions in this and any other property theory); a. This assumpfion simplifies ttie voting protocol.
39. The issue is not that tlie assumptions are Implicit-that Is a by-product of the necessarily attenuated description of the theory itself. As already noted, a complete description of any reasoning framework, while necessary In some contexts, would overwhelm the main points of discussion in this report.
The basic question is, "which assumption, or set of assumptions, brands the reliability theory as simplistic?" More to the point, what criteria can be used to make this assessment? One reasonable test is whether an assumption is overly constraining: in short, is it realistic to assume that systems of interest-that is, systems likely to be built in practice-will satisfy the assumption? If the answer is "no," any theory based on that assumption is likely to be simplistic. If, conversely, the answer is "yes," then the theory can be considered as "realistic," at least for the satisfying system.
The assumptions in Table 1 can be characterized in PECT terms by defining each f"' assumption as a predicate Pi on assemblies that evaluates to "True" if the assumption / is satisfied by the assembly, and "False" otherwise; in this way, assumptions are converted to well-formedness constraints. Then, the reliability of FTController (from Figure 18)  It is possible, even in the absence of specific application requirements, to conduct a thought experiment on whether a sufficiently large set of assemblies can be constructed that is well formed with respect to these predicates. After all, if no such experiment is possible, the original critique of the reliability theory as simplistic must be discounted. The results of the experiment are presented in Table 2. By virtue of the ACT, it is a simple topology.

P2 is satisfiable.
By assumption (see earlier assumption about the validity of failure rate)

P3 is satisfiable.
Even though the design pattern "assumes" that each component has a different implementation, the failure rate n = .001 might be a minimal norm for components. Eq.3 can also be generalized, without altering the theory, to handle unique failure rates.

P4 is satisflable.
The binomial distribution can be generalized easily to handle additional sources of failure events. It is also plausible that the correctness of a voter component can be formally verified. Failure-free connectors can be assumed in some (but not all) situations.
The temperature sensor in the example might report temperature t e {safe, caution, critical]; a switch sensor might leponpositionp e {closed, closing, opening, open}.

P6 is satisfiable, with loss of precision.
If components exhibit a range of failure rates over their input ranges, the worst rate can be chosen, yielding a worst-case (pessimistic) estimate for the assembly. Assigning a distribution to failure rates would require substantial changes to the theory (a new theory), especially if the distributions were nonstandard.
P7 is satisflable, assuming RMA schedulability as a precondition.
The NVV pattern requires synchronization to ensure that voting refers to the same event. This could be done by tagging sensor output or through some other interaction protocol. In this illustration, the approach is to guarantee that sensor deadlines are never missed. Adding the RMA schedulability precondition,^ in effect, defines the ordering TRMA^^NVV This is a key assumption of most reliability theories;'' its satisfaction is the primary motivation for n-version programming. However, even the assumption that the sensors are independent versions is not sufficient-erroneous assumptions may be found in the shared specification for sensors. The FTController assembly, as depicted, likely executes on one processor-another single source of failure. A distributed assembly could be constructed, but distributed interprocess communication will not be 100% reliable (see P4).
a. The schedulability claim for FTController Is an explicit annotation on Figure 18 on page 42. b.
The term "common mode failure" is often used in reliability literature to denote ttie condition in which the assumption of independent failure events is not satisfied.
To summarize the results of Table 2: assumptions 1, 3, and 4 are readily satisfiable; assumptions 6 and 7 are satisfiable, assuming that a pessimistic estimate of reliability is acceptable, and assuming that TRMA is a valid theory. The satisfiability of assumptions 2 and 8 is no more (or less) questionable here than in any other reliability theory. This leaves only assumption 5, which is satisfiable in any assembly in which sensors have a limited output range, a common scenario.
It appears that peremptory dismissal of T^vv may not be justifiable. As simple as the theory is, its viability appears to be dependent only on the application setting (i.e., assumption 5) and not due to anything intrinsically weak about the theory itself In more general terms, a property theory, however simple It appears, can be dismissed as sfanplistic only if the set of assemblies well formed in that theory is a small subset of the assemblies likely to arise in practice.

Optimizing Qualities of Reasoning Frameworlcs
The discussion in the previous section concerned the quality of property theories called "simplistic," or put another way, with the question of judging when a particular property theory Tx exhibits (the quality called) "realism." The criterion for making this judgement was reduced to relating the set/^ of analytically well-formed assemblies in Tx to the set of stereotypical assemblies in some potential solution set, call it/^g. In this view of the matter, a necessary condition for judging a theory to be "simplistic" is ^g 3 ^.
There are other qualities of property theories, several of which reflect different aspects of the the "complexity" quality The subsumes relation (indicated by the > symbol) was defined in the introduction to Section 6. Assuming that Tx and Ty address the same property (e.g., latency), the subsumes relation can be thought of as a preference relation-that is, "all else being equal, Tx is preferable to Ty if and only if Ty>T\{" Similar ordering relations can, in principle, be defined for each of the above itemized qualities, each with an analogous meaning in "preference" to that of subsumes.
The key phrase for each preference relation, though, is "all else being equal." Not surprisingly, the above qualities of theories interact with one another. For example, a decrease in the enduser complexity of a property theory (a desirable result) might be achieved by abstracting some phenomenon from the theory, which leads to nondeterminism-that is, behavior not predicted by the theory-and this, in turn, reduces the accuracy and stability of the theory (an undesirable result).^^ In this characterization, a classical multi-objective'^' optimization solution is required to integrate a new property theory into a PECT. In general, this is a hard problem; however, the emphasis on formal (or at least explicit) representation of ACTs and reasoning frameworks and on automated interpretation and reasoning imposes a helpful constraining influence on the integration process. These constraining influences are harnessed through "co-refinement." The co-refmement process derives its name from the coincident and iterative corrections (or "refinements") made to an ACT and property theory. The main concepts are shown, in Figure  21, as a trace over four iterations (steps 0 through 3) of the co-refinement process.
40. Assuming of course that the abstracted phenomenon is not extraneous to begin with.
41. There is an enormous body of literature on multi-objective decision theory, also known as "multiattribute decision theory," "multi-objective optimization," "multi-objective design," and other synonyms and their permutations. Roy provides a concise but accessible formalization of preference relation, preference structure, and families of decision procedures [Roy 91].

ABSTRACT COMPONENT '®^^* constrained ^x TECHNOLOGl
target definition of well-formedness for stereotypical assemblies initial definition of well-formedness for basis step 1 maximum U (7) Step 3

Figure 21: Time Sequence of a Series of Co-Refinement Steps
The vertical arrow on the left side of Figure 21 represents the level of restrictiveness of assembly constraints, perhaps quantified (intuitively) as the cardinality of the set of well-formed assemblies. The vertical arrow on the right side represents the state of the multi-objective optimization problem; the hypothetical ftmction U: T-^M assigns an integer score to a property theory to quantify its level of optimality or utility ^^ All else being equal, fewer constrained well-formedness rules are preferred to more constrained rules, since fewer constraints translate to a greater number of possible assemblies, and therefore a more general property theory. Likewise, greater values of U are preferred to lesser values, since the former translate to better tradeoffs of theory qualities.
There are different strategies for converging on the right balance between restrictiveness and utility. The one illustrated in Figure 21 begins with highly restrictive assembly constraints and proceeds by systematically relaxing these constraints while adding utility to the property the-42. There is nothing special about this function, which can take many forms. It is a standard component of the vast majority of multi-objective decision aids. Strictly speaking, the utility function should be defined on a vector of valuations assigned to each objective, rather than on the theory as a whole.
ory. An alternative is to start with target assembly constraints and a property theory with little or no utility, and then add assembly restrictions as needed, while improving theory utility.
In Figure 21, the co-refinement process begins with the basis step.
Step 0, that involves defining highly restrictive well-formedness rules-which can, in fact, restrict well-formedness to a single model assembly-and specifying a property theory that "solves" the model problem posed by the model assembly(ies). The crucial element of the basis step is that it establishes an interpretation from the model assembly(ies) to the property theory. The only invariant between steps in any co-refinement process is that an interpretation is defined as the post-condition of each step.
Each;* step after the basis step is guided by a primary objective and a secondary objective.
The primary objective is that Tj subsumes 7^_i, that is, 7^ > Tj_j, as defined earlier. This subsumption is valid only because of the invariant on the defined-ness of interpretations. That is, if/4:'D/f:_i, the interpretation '?: ensures Tj > T"_j, by definition. The secondary objective is that U.{T:) > L((7^_]). The intent is that the primary objective takes precedence over the secondary objective.
However, neither objective is sacred; in some circumstances, the secondary objective may have priority; in others, regression in one or both objectives may be warranted in the interest of "one step backward, two steps forward." The possibility of regression on utility is shown at Step 1 in Figure 21, as Tl > Tt), but IXiTO) > liiTl). Such pragmatic decisions have been encountered in practice (see Predictable Assembly of Substation Automation Systems: An Experiment Report for a case study of co-refinement [Hissam 02b]).
An interesting question is how to define the termination condition (or exit criteria) for corefinement. Figure 21 suggests that some target set of stereotypical assemblies was defined, perhaps prior to Step 0. This might be the case if a PECT were developed for an established product line. Even so, there will likely be normative requirements imposed on the property theory-perhaps a required accuracy or confidence interval that must be achieved by a property theory (again, see Predictable Assembly of Substation Automation Systems: An Experiment Report for a case study of normative requirements on property theories [Hissam 02b]).

Incompatibility Among Reasoning Frameworks
Even assuming that Tj > 7j_i is a primary objective for successive steps in co-refinement, it is possible for incompatibilities to arise, that is, Tj -7j_i or T-=Tj_i. To illustrate, a performance theory at Step; might be modified to rely on a task-scheduling policy different from the policy assumed at Step;-1; for example, a change from "fixed-priority scheduling" to "earliest-deadline-first scheduling." Since tasks in an assembly cannot be scheduled simultaneously with two different policies, the two property theories (whatever they are) cannot be valid simulta-neously, hence Tj_i ~7], However, this incompatibility is not problematic since, by definition, 7^_j and Tj would never be applied simultaneously to the same assembly.
For the purpose of this discussion, let reasoning frameworks that are defined as a consequence of a particular co-refinement activity be called homogeneous: assume that, at most, one of these reasoning frameworks will be used to reason about the same assembly.*^ Also, let reasoning frameworks that span different co-refinement activities be called heterogeneous: assume that one or more of these frameworks can be used simultaneously to reason about the same assembly. For the following discussion, Greek subscripts are used to distinguish heterogeneous from homogeneous reasoning frameworks-that is, T" and Tp are heterogeneous, while Tj and 7^ are homogeneous.
In the case of co-refinement, the incompatibilities 7] ~7]_i and 7] =7^_i are not, in general, problematic to the end user of a PECT, since 7] and Tj_i are homogeneous. However, complications do arise with incompatibilities among heterogeneous theories, and in particular where 7a=7p-In this case, the two properties may be susceptible to interference. Interference arises when, for example, changes to an assembly specification are made to optimize predicted properties in T", but where those changes violate the well-formedness constraints imposed by some other property theory Tp. Figure 22 depicts a canonical form of interference, using analogous Venn diagram and naming conventions used in Figure 20. To illustrate interference, imagine a PECT that supports some security theory-Tg^Q. Say that TsEC can be used to predict the probability that the confidentiality of message traffic can be compromised within a specified time interval. Further, to be well formed in T^^Q, an assembly 43. It is possible, and may be desirable, for more than one homogeneous theory to be embedded in its own reasoning framewoit and integrated into the same PECT.
must encrypt messages explicitly with the encryption component Crypto, or implicitly with the (security environment-specific) connector -^crypto-^" ^^^^ illustration, T^EQ W'" ^^ ^^^'^ '" conjunction with r^w and we assume TSEC-^NVV Now, let assembly al be Controller, as depicted in Figure 14 on page 25. Assume that our objective is to ensure that al satisfies specific reliability and security requirements that are predictable in T^^c ^"^ T^y\. Unfortunately, al is not well formed to either TSEC or T^w With luck, tools will provide diagnostics that provide clues about how to repair the specification. As a practical matter, al might first be modified to be well formed in Tj^w', assume that the resulting al assembly is FTController, as depicted in Figure 18 on page 42. At this point, a2 is modified yet again to be well formed to T^^Q; assume that the resulting assembly a3 is FTSecController, as depicted in Figure 23.
Unfortunately, there are various ways in which FTSecController is no longer well formed with respect to TNVV-Por example, it probably violates any naive definition of the voter topology. Only a bit more subtle is the violation of the T^vv assumption about independent failure modes-Crypto is a single source of failure (see P8 in Table 2 on page 48). To complete the scenario, assembly aS is modified to replace Crypto with an encrypted connector, resulting in a4 assembly in Figure 22, which is well formed to both T^vv and TgEC-This is, admittedly, a rather simple illustration-it is just as easy to imagine that, with only two property theories to accommodate, the initial sequence of assemblies {al, a2, a3} might never have been specified, or al could be transformed directly into a4. On the other hand, the scenario would look more likely if the hypothetical PECT had supported a dozen or more heterogeneous property theories, with several homogeneous alternatives for each such theory. Although this more complicated scenario has not yet arisen, it is inevitable should the PECT concept achieve widespread industrial use.

6,5 Dealing with Incompatibility
Incompatibilities among heterogeneous reasoning frameworks are almost certainly inevitable, but they must be managed and, where possible, eliminated. PECT is as yet an immature technology, and as such, a sufficient number of reasoning frameworks don't exist to make this a pressing near-term issue. However, as the issue directly affects end users and issues of scale, it is vital that sound and practical approaches to dealing with incompatibility be developed. Three approaches are described below, from the least to the most speculative.

Multi-Refinement
One way to minimize the potential for heterogeneous incompatibility is by introducing a "multi-refinement" process that has as its primary objective maximizing the extent of fV*, where * ranges over the set of heterogeneous theories being integrated.
Multi-refinement might yield one or more intersection theories. For example, the new reliability theory T^w' might be defined, T^w ^ '^NVV'^ that requires a reliable filter to be interposed between unreliable components and the Voter component. Similarly, a new T^^Q' might be defined, Tg^-> Tggc, that requires the use of Crypto and disallows the use of "^crypto-Then, Tggc = Tj^yy, where both can be thought of as intereection theories designed "in the context" of one another. Here, though, TgEC' seems a bit too restrictive. An alternative is to leave T^^Q as it is and define T^vv' -^NVV to allow, but not require, cryptographic CMU/SEI-2003-TR-009 topologies such as in FTSecController. Tiien, although T^EQ =^NVV'' ^^ least matters have improved somewhat, since TSEC '^^NVV'3 ^SEC '^^NVV-In brief, as with co-refmement, selecting a mix of intersection theories for a set of heterogeneous property theories will almost certainly involve multi-objective optimization. Although this is certainly achievable for a reasonably small number of reasoning frameworks (say, fewer than five), the process will be messy and ad hoc if many theories, with overlapping constraints, are introduced. In the long run, a more rigorous approach will be required.

Expert Tool Assistance
The interference between the reliability and security theories also strongly implied the importance of automated detection of theory incompatibility, as well as detection of the introduction of incompatibilities where previously there were no incompatibilities. However, achieving automation will be challenging.
For example, defining well-formedness constraints for a single property theory, with sufficient formality to support automated checking, is nontrivial. However, identifying contradictory constraints over heterogeneous reasoning frameworks, where each will likely have its own "domain of discourse," will be doubly challenging. A large number and variety of automated constraint management tools have been developed to develop artificial intelligence applications. Such tools, in concert with some form of type system for property theories and other construction-language-sensitive tools, may well form the core of automated tool support for PECT users.
The notion of tactics for quality attribute design [Bachmann 02], currently being investigated by Bachmann, Bass, and Klein, is also intriguing and appears to have bearing on interference. The authors sketch a decision procedure that operates on analyzable design fragments known as tactics and produces refinements of those fragments.^ In terms of the above scenario, the procedure manages design dialogues leading to the sequence of refinements {al^, a22,..., a2j} to improve reliability, and refinements {a3j, a32, -, aSj^} to improve security.'*^ As currently defined, the procedure regards these dialogues as independent; it does not yet address refinement over multiple interacting theories. An extension to manage an agenda of design tactics 45. This description takes liberties with the concept of a design tactic that operates at a more primitive level of abstraction than property theories. One motivation for design tactics is for them to serve as building blocks for attribute-based architecture styles (ABASs) [Kazman 99]. The NVV pattern and its property theory 7^gvv can be defined as an ABAS.

A Type System for Reasoning Frameworks
A speculative alternative to multi-refinement is to define a type system for reasoning frameworks that would permit them to be selected on the basis of a well-defined subtype relation. That is, rather than adapting an assembly to meet the well-formedness requirements of a property theory, it might be possible to select, or even infer, the "best fit" reasoning framework for a given requirement or assembly.
For example, the decision procedure for r^vv might be defined as eval: M^yy x F^vv where FNW is the probability of failure-that is, Vve FNVV'O < V < 1, Since ^^vv is derivable, we can instead use eval: ^yy x V^yy.. With this notation, a conventional contravariant/covariant subtype relation X<:Y (pronounced "Z is a subtype of F') on homogeneous reasoning frameworks can be defined in a straightforward way: T^. <: % <=> ^^ c^*. A V^ C F*. That is, %> is a subtype of % if and only if it applies to a superset of assemblies and yields a subset of behaviors. This can be further generalized; for example, by also encoding in F^vv the notion of confidence. In this case, %, is a subtype of n if and only if it applies to a superset of assemblies and yields a subset of predicted behaviors with at least as much confidence.
This discussion, of course, risks trivializing the task of defining such a type theory. For one thing, conventional type theory assigns one domain of values to each syntactic phrase (i.e., its semantic domain); in a construction language, each phrase would have several semantic domains, one for each reasoning framework. Further, a typing scheme along the lines described above would requke that reasoning firameworks be compositional; as discussed in Chapter 7, this is not always possible. Nonetheless, the potential benefits of treating "nonfunctional" properties on a par with functional properties (as in the type theory of modem programming languages) is certainly intriguing. Compositional Reasoning It is almost (but not quite) a tautology that components are valuable insofar as they are composable with other components. In the parlance of software component technology, "compositionality" is simply assumed. As observed in Chapter 2, however, current parlance tends to focus almost exclusively on the constructive aspects of composition-namely, on the binding of component labels to enable their runtime interaction.
Compositionality is also desirable for the analytic aspects of component-based development; however, unlike constructive compositionality, it cannot be assumed. It is also not an easy or straightforward topic-a substantial body of research literature under the general heading of "compositional reasoning" has been developed since the early 1980s. To the extent that there is a general underetanding of compositional reasoning and the closely related notion of modular reasoning, this understanding appears to be limited to particular research communities, such as those concerned with formal (demonstrable) verification and, more particularly, with verification of concurrent systems. In fact, even within diese research niches, there is continued interest in developing first principles of compositionality.
To state the conclusion first: Support for compositional reasoning is a desirable property of reasoning frameworks. However, PECT does not always support compositional reasoning. It does, however, always support reasoning about compositions. The following discussion will clarify and substantiate this conclusion.
The following discussion is based on a survey paper by de Roever that also served as an introduction to the proceedings of a conference devoted to the firet principles of compositional reasoning [de Roever 98]. The terminology and definitions used by de Roever have been adapted to better fit the terminology and definitions provided in this report. There is, therefore, some risk that this adaptation does violence to de Roever's intent.

Compositional and Modular Reasoning
According to de Roever: "The purpose of a compositional verification approach is to shift the burden of verification from the global level to the local component level, so that global properties are established by composing together independently (specified and) verified component properties." [de Roever 98] This is entirely consistent with the objectives of a PECT, modulo its restriction to demonstrable reasoning (i.e., verification)-an important proviso and one that must be generalized to accommodate plausible reasoning, if the purpose of compositionality is to be achieved by PECT.
Setting aside for the moment the distinction between component and assembly, the following outlines a compositional proof scheme. To compositionally demonstrate that a component C satisfies some property P, written C 1= P 1. If C cannot be further decomposed, then demonstrate C 1= P directly on C.
2 Interestingly, the above (widely accepted) compositional proof scheme works "top-down"that is, it is a decompositional proof scheme. Modular proof schemes, in contrast, work "bottom up"-that is, they begin with non-decomposable components and their demonstrated properties. The task is to show that a composite property on a composite component is entailed by these previously established component properties and so on, in a "bottom-up" fashion.
It can be observed, however, that while the distinction between compositional and modular reasoning may be significant to the theory of PECT in the long run (with modular reasoning apparently closer to what is needed where systems are composed from preexisting components), the description of reasoning frameworks in this chapter does not expose this distinction. In particular.
Step 1 above is delegated to component certification, and Step 2a is delegated to the design and validation of a reasoning framework; Step 2b, however, has not been assumed to be a valid reasoning step for all reasoning frameworks.
In fact, "component" was not given an inductive definition in Section 3.1, and the different forms of hierarchy defined for assembly in Section 3.5 flow from the fact that Step 2b is not always a valid reasoning step for every property theory (although it might be valid for some property theories). This is one reason why compositionality and modularity-as currently formulated-impose conditions that are too strong in practice, even if they are ideal in theory. A justification of this important assertion is discussed next.
46. Recall that even plausible (i.e., empirical) properties can be expressed as factual assertions. Thus, casting the following discussion into the terms of formal logic does not restrict the applicability of the discussion to demonstrable reasoning. Note also that in this discussion, the notion of "C satisfies p" (or "C N p") refers to the usual definition of this term in formal logic, and not to that given in the general definitions of Section 6.

Why Compositionality Is Too Strong
As observed by de Roever, the proof Steps 2a and 2b lead to the following technical requirements, recast in PECT terms. For each n-ary connector -^ in (a CCL specification of) an ACT, an n-ary operator -^^ exists in (a calculus and logic of) a property theory 7 such that Requirement 1: If Cf Pj, 1 < j < n, then ^Cj, Cj,..., C") ¥ -WTCP,, PJ, ..., P").
Requirement 2: If -w(Ci, C2,..., €") 1= P, then some Pj exists for each Cj, 1 < j < n, such that Cj^ Pj and -^^P,, P2,..., P") => R These requirements flow quite naturally from the compositional proof scheme. The first states that each connector has some corresponding property theory that describes the semantics of the connector. The second states that properties can be decomposed into wholly independent subproperties.
These conditions are too strong, however, and exclude property theories that are nonetheless quite useful. In fact, none of the three property theories illustrated in Sections 4.4 -4.6 satisfy these requirements: • Neither 7xABA (discussed Section 4.5) nor 7NVV (Section 4.6) are defined on individual connectors-7XABA is defined on sequences of interactions beginning with periodic stimuli, while 7NVV is defined on its own topological arrangement;'^^ this fact violates requirement 1.
• The timing properties of an assembly of components (discussed in Section 4.5) cannot be decomposed into independent subproperties-^the timing behavior of one component may (and will likely) influence the timing behavior of others; this fact violates requirement 2.
• It is, in general, impossible to reason compositionally about liveness properties in temporal logic (discussed in Section 4.4)-^the "rely/guarantee" reasoning procedure is compositional, but, in general, works only for safety properties; this fact violates requirement 2.
This is not to say that no compositional (or modular) theory for reasoning about liveness, timing, or reliability is possible. Of course, such theories must exist, since the assembly-level behaviors exist and since computation is deterministic. But the effort to develop or use such theories might outweigh the benefits of compositionality. For example, there is an interaction between components and a shared central processing unit (CPU) that is abstracted by 7XABA-47. It is interesting to speculate about the objection to the compositionality of l^jy. The NVV pattern of interaction could, in principle, be encoded as an n-ary connector for m unreliable components, 1 voter and 1 client. A corresponding polyadic operator, -^NW. would be defined to take as its argument one or more failure probabilities and return a failure probability. This would satisfy requirement 1.
The CPU is a global resource; changes in the timing behavior of one component are transmitted through this global resource, leading to a loss of compositionality. However, this loss is offset by a simplification in the reasoning procedure, both in terms of human and computational complexity.
Before deciding if the loss of compositionality is worth the gain in simplicity, it is worth reflecting on the value of compositionality.

Why Compositionality Is Important
Compositionality implies all the benefits inherent to the "divide and conquer" problem-solving strategy, namely, significant reductions in complexity. Where automated reasoning is used (e.g., in model checking), a lack of compositionality leads to exponential growth complexity, either in the number of states in a model, or in the number of propositions in a temporal logic claim. At this time an objective for research in model checking is to discover an adequate resolution to exponential complexity, and no wholly satisfactory compositional approach has yet been defined to address this complexity.
Also, without compositional reasoning to link components to assembly properties, the long sought-after goal of independently substitutable component parts will remain chimerical. Until design theories permit reasoning about the behavior of components (and assemblies) compositionally-that is, in a way that is independent of other components (and assemblies)-unexpected interactional behaviors^^ among components will remain an open-ended source of undocumented intercomponent dependencies. As long as these dependencies exist, one component can never be substituted for another without the expectation of unpredictable results.
Consider the analogy between module types in higher order functional languages such as ML [Harper 94] and a theory of component types based upon compositional component properties. In ML, a subtype relation on modules'*^ Mj <: M2 is defined such that Mj can always be 48. Unexpected and unexplained interactional behaviors are usually also undesirable, as is any source of unpredictability in an engineering discipline. Such behavior is sometimes denoted as emergent behavior. Any effort to understand or control emergence is an effort to achieve predictable assembly. Earlier reports on PECT went as far as to assert that the terms "assembly property" and "emergent property" were synonymous. However, because the term "emergent property" has been widely associated with "unpredictable property," it is probably better to concede the term and move on.
49. Essentially, a module in ML is a set of functions, each of which has its own type signature and exists within a well-defined type lattice. The analogy being drawn here is between modules in ML and components in CCL. Of course this does not do justice to the theory of higher order module types, but it is sufficient to situate the analogy.
"safely" substituted for any module M2-that is, no function in M, will be "surprised" by a value it receives from the environment in which it is deployed, and no function in M] will compute a value that "surprises" its environment. Achieving a similar feat for software components will require that, in addition to the ML sort of functional-type theory, an extra-functional-type theory be defined for each of the assembly-level properties of interest to application assemblers. That is, by analogy with type theory Cj<: Cj if and only if VPCi.P <: C2.P, where P includes the functional interface and all extra-functional properties of a component.
Compositional property theories might be abandoned in the near term for reasons of expediency, but, ultimately, such theories are required to achieve the degree of scalability and flexibility that is so often promised to be the inevitable accompaniment to software component technology.

Status and Future Work
The major elements of PECT have been demonstrated in progressively more demanding proofs of feasibility [Hissam 02a], [Hissam 02b]. The overall design structure of a PECT has proven sufficient for these initial trials, and several parts of a generic PECT development infrastructure are currently being developed-^for example, a trace-based execution monitor, and tools for specifying and processing CCL specifications. Currently, a more ambitious proof of feasibility in industrial robotics is underway that incorporates automated model checking and performance theories based in both RMA and real-time queuing theory.
Other areas of near-term effort are described below: • The PECT concept, as described in this report, focuses mainly on a theory and infrastructure for predictable assembly. Of equal importance is a theory and infrastructure for certifiable components. The technology for functional certification, perhaps along the lines of contracts [Meyer 97], extended to software components [Meyer 98], is a precondition to PECT, Future work will be more explicit about this assumption, and generalize it to address certification of properties defined and required by reasoning fi-ameworks. ' • The emphasis of PACC research, to date, has been on the science and technology of predictable assembly. Although PECT is relatively immature and although the theory of PECT will continue to evolve, a body of experience with the main ideas is accumulating, and the basic elements of a development method arc emerging-^for example, co-refinement and statistical validation of property theories. Future work will capture those elements, initially as method fragments, and later as an integrated method.
• The emphasis of PACC research, to date, has been on systems with highly deterministic, periodic, and reactive behavior, and property theories that are either verifiable (e.g., model checking) or present a clear falsification strategy (e.g., latency). Future work will extend the focus to systems exhibiting increasingly stochastic behavior (e.g., behavior sensitive to the distribution profiles of stimuli) and property theories whose falsification strategies are not inherently clear (e.g., reliability theories based on statistical testing of component reliability).
Areas for longer range research include developing • sound value propositions for certifying components for predictable assembly • automation for simultaneously optimizing assemblies for one or more properties • type systems for component specifications extended to nonfunctional properties

Conclusions
Expressiveness arises from strictures: restrictions entail stronger invariants. Flexibility arises from controlled relaxation of strictures, not from their absence.

-Robert Harper
This report has described the structure and underlying theory of PECT. Answers to the questions that were posed in Section 1 are now provided, in the terminology of PECT, Which characteristics of an assembly malce it predictable, and which kinds of assembly properties can be predicted? An assembly is predictable if it is well formed with respect to the assembly constraints imposed by one or more property theories. An assembly is then said to be predictable with respect to the properties addressed by these theories. Property theories can be developed for any property that can be shown, in an objective way, to adhere to (well-formed) assemblies. Objective evidence can be demonstrable-in the form of verifiable proof-or plausible-in the form of empirical observation.

What characteristics of a component malce it certifiable, and what kinds of component properties can be certified?
A component is certifiable if it has properties that can be demonstrated, in an objective way, to adhere to the component. As before, objective evidence can be demonstrable or plausible. Any such property can be the subject of certification, but only those properties that are parameters to a property theory are of direct interest to a PECT. In this case, the property theory always jJrovides a definition of component properties in sufficient detail, and with sufficient rigor, to enable their certification.
How can we achieve objective and measurable confidence In certified component properties and predicted assembly properties? All property theories provide an explicit and objective basis for confidence, both in the predictions themselves, and in the 50. This quotation is from ttie invited presentation titled 'The Practice of Type Theory in Programming Languages," Dagstuhl 10th Anniversary Symposium. Saarbruecken, August, 2000. Available online at <http://www-2.cs.cmu.edu/~nNh/talks/Dagstuhl%202000.ppt>. component properties on which they depend (as described in the previous two answers). Measurable confidence, in the form of statistical labels, attends any component or assembly property that depends directly on empirical evidence. Even formally demonstrated properties are amenable to statistical treatment, where proof results depend on assumptions that can be validated through observation.
Can a technology infrastructure that provides answers to these questions be systematically developed and transitioned into practice? A PECT provides for two parallel frameworks, one for specifying and deploying well-formed assemblies of components (the construction framework), and one for imposing well-formedness constraints and providing automated analysis tools that exploit these constraints. A discipline for systematically developing and integrating these frameworks, and for validating the resulting integration, has been demonstrated in increasingly realistic industrial proofs of feasibility. binding label component a vocabulary and notation for specifying components, assemblies, and their runtime environments in a component-technology-independent way, and for specifying the constraints, imposed by reasoning frameworks, that must be satisfied for predictions to be valid a map from the symbols of a calculus (in a property theory) to elements of a (not necessarily component-based) computing system. See also definite interpretation.
the minimum scope of component interactions for which the assumptions of a particular reasoning framework can be satisfied constraints imposed by one or more reasoning frameworks on an abstract component technology a property P associated with a referent R, meaning that "R has property P," denoted as R.P a set of components and their enabled interactions behavioral and topological rules of well-formedness imposed on components and assemblies by one or more (i^al) component technologies, and one or more reasoning frameworks a decision procedure, a definite interpretation, and a definite inverse interpretation, each susceptible to ftill automation. See also property theory.
a linking mechanism embedded in components to enable their interaction with other components. See also pin.
an implementation in final form, modulo bound binding labels, that provides an interface for third-party composition and is a unit of independent deployment connector a mechanism provided by the runtime environment that enforces an interaction protocol, or discipline, on the components that are participants in an interaction construction framework an abstract component technology, tools to enforce assembly constraints, and other tools used to automate the specification, development, and deployment of components and their assemblies construction language a language for specifying abstract component technologies (ACTs) and their well-formed components and assemblies constructive closure See containment.

compose, composed, composition
components that have interactions enabled through some connector are composed; composition (n): is a set of such enabled interactions; compose (vb): to enable component interaction. See also assembly.

contained, containment
All interactions among components are restricted to the scope of the most immediately enclosing ("containing") assemblies and partial assemblies.
co-refinement a process for developing reasoning frameworks, and in particular, for finding an acceptable tradeoff among various qualities of a reasoning framework, such as generality, complexity, and stability decision procedure a function that evaluates claims made on assemblies, described in the property theory, to the values "true" or "false" definite interpretation a map fi-om assemblies specified in a concrete syntax of a construction language to strings in the input language of the decision procedure. See also property theory.

definite inverse interpretation
a map of the results of a decision procedure back to the concrete syntax of the construction language. See also property theory. deploy defines where (in which instance of a runtime environment, and, ultimately, on which physical computing device) component behavior is executed empirical evidence evidence acquired through direct observation, preferably under controlled circumstances, with results reported in well-defined units of measure. Empirical evidence is therefore provisional, as any other observation might have been different. See also formal evidence.
final form a software specification that is ready for execution on a physical or virtual machine. See also component.
formal evidence evidence acquired through mathematical proof. Formal evidence is therefore irrefutable, as all such proofs are tautological. See also empirical evidence.
gateway a connector that enables interactions among components deployed in diffei«nt environments heterogeneous reasoning frameworlc property theories developed in different co-refinement activities.
One or more heterogeneous theories can be used simultaneously to reason about the same assembly. See also homogeneous reasoning framework.
homogeneous reasoning framework property theories developed in a particular co-refinement activity.
In general, only one homogeneous theory will be used to reason about the same assembly. See also heterogeneous reasoning framework.
interaction a composition of two or more reactions, from distinct components, using a runtime-environment-provided connector interpretation multi-refinement See abstract interpretation, definite interpretation.
a generalization of co-refinement for finding an acceptable tradeoff among various qualities of heterogeneous reasoning fi-ameworks null Junction a graphical notation on partial assemblies that indicates which pins of components contained in the partial assembly are visible outside the assembly partial assembly a (recursively defined) abstraction that aggregates a set of components and their enabled interactions, and exposes selected component pins through null junctions. Logically, a partial assembly is a component implemented entirely in terms of other components. See also assembly.
prediction theory property synonym for property theory an «-tuple <name, value,... >, where name and value refer to the name of some property and the value it takes, respectively. See also annotation.
property theory a calculus, logic, and abstract interpretation that provides an objective, rigorous, and verifiable or falsifiable basis for predicting the properties of assemblies. See also prediction theory. binding labels in the construction and composition language (CCL). See also source pin, sink pin, connector provides runtime services that may be used by components in an assembly, provides an implementation for one or more connectors, and enforces assembly constraints a pin that accepts interactions with the environment of a component (i.e., from other components or the runtime environment). See also pin, source pin.
a pin that initiates interactions with the environment of a component (i.e., from other components or the runtime environment). See also pin, sink pin.
A component is independently deployable if all its dependencies on external resources are clearly specified (e.g., as pins), and if it can be substituted for, or substituted by, some other component. See also deployment.