NEWS AT SEI
This library item is related to the following area(s) of work:Predictability by Construction
This article was originally published in News at SEI on: June 1, 2003
In September 2002 the SEI launched a new initiative, Predictable Assembly from Certifiable Components (PACC). This new initiative is developing technology and methods that enable software engineers to predict the runtime behavior of assemblies of software components from the properties of those components. This requires that the properties of the components are rigorously defined and trusted and can be certified by independent third parties.
PACC builds on past and, in some cases, ongoing SEI research in software architecture and in the use of commercial off-the-shelf (COTS) software. The work reflects clear industry trends toward greater use of software-component technology and increasing concern with the quality of software systems.
Nothing serves so well as an illustration, so that’s where I’ll start. Then I’ll introduce the key principles and technologies underlying our approach, which is called prediction-enabled component technology (PECT). I’ll wrap up by describing what we’re currently doing, open challenges, and next steps.
In PACC our concern is to predict the runtime behavior of assemblies of components. By runtime behavior we mean any behavior of a system that is directly or indirectly observable on the executing system. For convenience, we refer to any such observable behavior as a runtime property.
In this illustration I’ll use execution latency, i.e., the time it takes an assembly to perform a task, as the runtime property we wish to predict (our work on automatic verification of reliability properties through model checking will be the subject of a future article). The illustration is drawn from a proof of feasibility of PACC for power transmission and distribution (see Predictable Assembly of Substation Automation Systems: An Experiment Report for details).
A power substation serves several purposes, among which is protection and control of primary equipment, such as transformers, circuit breakers, and switches. Our task is to develop, from software components, a controller for a high-voltage switch. One function of the controller is to provide an interface that allows operators to manually open and close the switch. We wish to predict the time it takes a controller to process operator requests, and the time it takes the controller to report on the change in switch status.
The illustration in Figure 1 presents the gestalt of the software engineering task in terms of PACC. We assume that a set of software components already exists, and that the service time of these components (defined as the time it takes the component to do its work, assuming no blocking or preemption) has been obtained (1 in the figure). The software engineer selects a set of candidate components, and composes their specifications to produce a model of the controller assembly, which is analyzed and from which latency is predicted (2 in the figure). If the predicted latency satisfies requirements, the components (rather than their specifications) are composed and the resulting assembly is deployed. Predictions are only predictions if there is a possibility that they are wrong, so some validation is required of the deployed assembly (3 in the figure).
Figure 1: A Predictable Substation Assembly
This much might have been guessed from the name of the PACC initiative. However, technology being developed by the SEI aims to increase the level of automation in the assembly, prediction, and composition processes, and to provide an objective and quantified basis for trusting component properties and the predictions that are based on these properties. In particular, using this example:
We are concerned with more than just the timing properties of assemblies—e.g., reliability (an area of current work) and security (an area for future work). Therefore, the technology being developed by the SEI to enable PACC can be applied to many analysis models.
Our approach to achieving the above objectives is to use prediction-enabled component technology (PECT). Here I will limit the description of PECT to the simple core ideas. Readers interested in the more comprehensive treatment are referred to Volume III: A Technology for Predictable Assembly from Certifiable Components.
As its name suggests, a PECT is an enhanced component technology. What is a component technology? There is no answer to this question that won’t provoke an argument, any more than there is a universally agreed-upon answer to the question What is a component? Nonetheless, there is growing agreement on the following rough definition:
Regular readers of this column will notice the similarity between this definition of component model and the usual definition of architectural style (or pattern) as a collection of component types and their allowable patterns of interaction. Even though they may differ in many respects, a component model and architectural style both specify invariants that must be satisfied by any instance of that model/style. These invariants are exactly those “well-formedness” rules that we impose on component assemblies to ensure that they can be analyzed, and therefore to ensure their predictability.
Seen in this light, a component technology can be thought of as an infrastructure for designing, developing, and deploying applications that adhere to a particular architectural style. The infrastructure does restrict the freedom of developers and designers, but in compensation it enforces design and implementation invariants that, in this case, ensure predictability. The tradeoff between restricted freedom and predictability has been seen before—in the development of strongly typed programming languages, now considered an essential element of modern software engineering practice. The long-awaited shift to a higher level of abstraction—from functions and classes to components—is underway.
Figure 2 provides a concise description of the structure of a PECT in the Unified Modeling Language (UML). Even readers not fully familiar with UML should be able to use this model to follow along, as there are only a few points to make that have not already been stated explicitly.
Figure 2: A UML Model of the Structure of a PECT
The SEI PACC initiative has developed several prototype demonstrations of PECT, and as a result we are gaining experience in the methods and technology infrastructure needed to achieve the levels of automation and trust we are seeking.
We are developing methods and tools that will enable the software industry to introduce predictable assembly from certifiable components into practice. Although the initiative is less than a year old, we are already working with an industrial sponsor, the ABB Group (Asea Brown Boveri, Ltd.), to demonstrate PECT feasibility in challenging industrial settings, currently in the domain of industrial robotics. Our current focus is on demonstrating PECT in incrementally more demanding and larger scale industry and DoD settings, and in documenting the methods we use to develop and validate PECTs. We are also broadening our repertoire of reasoning frameworks to include a variety of performance-analysis models, as well as automated verification (through model checking) of specific component and assembly-reliability claims.
Although we believe that we have demonstrated the potential of PECT, there are several challenges that must be met if the ideas are to find widespread use and acceptance:
Although these are serious challenges, the needs addressed by PACC are real and immediate. Moreover, progress is being made, and not just at the SEI. Academic research and industrial practice are moving in the direction of predictable assembly, and the guaranteed component quality is demanded by the marketplace, by societal needs, and by our own quest to establish rigorous foundations for software engineering practice.
If PACC were to be summed up in a single sentence, it would be that it allows us to shift our focus from predicting the runtime properties of assemblies to building only assemblies whose properties we can predict.
For more information about PACC or to inquire about opportunities to collaborate with the SEI in this research, see the Predictability by Construction Web site.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.