Yonghao Chen and Betty H. C. Cheng
Department of Computer Science
Michigan State University
East Lansing, MI 48824
Email:
chenyong@cps.msu.edu,
chengb@cps.msu.edu
URL:
http://www.cps.msu.edu/groups/serg/serg.html
Knowing how a component can be used is as important as knowing what functionality it provides. It is common to consider a component as a collection of functions and data that can be directly invoked or accessed by other components, but there are many other kinds of interactions among components, such as client/server, or a pipeline composed of filters. In these cases, explicitly specifying the ways that a component may interact with other components, that is, the packaging of a component, becomes crucial for reusing the component. We claim that because formal specifications are amenable to automated reasoning in analyzing component properties, software reuse can be greatly facilitated by formally specifying components. We are exploring the use of formal methods in specifying both functionality and packaging of components.
Keywords: formal specification, software component, architectural and functional properties
Workshop Goals: investigate how formal techniques can facilitate software reuse.
Working Groups: rigorous behavioral specification as an aid to reuse, domain engineering tools
Many approaches have been proposed to specify the functionality of reusable components. However, the packaging of a component, that is, the ways that the component may be used with other components may play a critical role in implementing reuse. For a given component, there typically exist assumptions about the structure of the system in which it will function. These assumptions, called architectural assumptions, constrain the ways the component can be used. For example, in a client/server system, the client expects to interact with the server in a specific way that is very different from what a filter expects in a pipeline system. Thus, a filter in a pipeline system may not be used as a client in a client/server system, even though it may have the required functionality. This conflict is so-called architectural mismatch [1], recently identified as a serious obstacle in implementing reuse. Furthermore, these architectural assumptions are usually implicit and not documented, and there appears to be a lack of explicit terminology for describing these architectural assumptions.
We believe that in order to achieve effective reuse it is important to specify both functional and architectural properties of a component in terms of formal specifications. Formal specifications are amenable to automation in analyzing component properties and thus facilitate the determination of reuse.
The formal description technique LOTOS [2] was originally designed to specify the interactions among communicating processes, thus making it suitable for capturing the architectural (interaction) properties of components. Furthermore, LOTOS also incorporates the algebraic specification language ACT ONE for specifying data and related operations. With ACT ONE specifications, we can capture the functional aspects of a component. In addition, LOTOS is an ISO standardized formal specification language and has the rich support of industrial tools, such as TOPO [3] and LOLA [4] that can be used to analyze LOTOS syntax and semantics, as well as verify and simulate LOTOS specifications.
We model a component as a blackbox with a set of input and output gates (or channels), where visible events occur. Instead of describing the static functionalities that a component provides, we specify the set of (dynamic) behaviors that a component may exhibit in constituting a system. Each behavior is encapsulated by a syntactic unit, termed port. A port describes not only a capability, but also the way the capability is provided (or used) by a component, or more precisely, the protocol governing the interactions of the component with other components for offering or requiring the capability. All ports, together with constraints that may be imposed upon the ports, constitute the interface of a component.
The interface of a component specifies the computational commitments that the component can make and describes the constraints on the way the component is to be used. A template for a component interface specification using LOTOS is depicted in Figure 1. The specification of a component starts with the definitions of data types, specified in ACT ONE, that will be used in the following specification. Ports are the visible points of a component to users. The behavior of a port is defined by a LOTOS behavior expression. Following the keyword WHERE are local definitions of LOTOS processes that are used in the behavior specification. A component may have overall constraints imposed upon the ports. Each constraint is specified in the same fashion as a port.
Figure 2 is an example specification that specifies a server component. This component has only one port, server, which, according to the port specification, repeatedly accepts an integer x from channel request, and then sends back f(x) to channel reply. The function f is specified as an operator over data types defined in the data type specification. In this example, f(x) simply returns x+1.
Figure 3 specifies a filter in a pipeline architecture. The filter has two ports, in and out. At the in port, the component repeatedly reads an integer x from channel instream (which, in this case, is a stream), until the end of channel is encountered. At the out port, the component either outputs an integer to channel outstream, or chooses to close the channel outstream and terminate. The events at ports in and out are concurrently occurring. The constraint c specifies the synchronization between them. According to the constraint specification, the component will first input a value x from instream, then output f(x) to outstream before inputting another value from instream. In addition, the constraint states that only when eof is encountered in the in port and the instream is closed, does the out port choose to close the outstream and terminate. The functionality of the component is also specified in the constraint by specifying that the output value is the function g(x), where x is the input value.
The in and out ports of the component filter represent two different behaviors that filter may exhibit in constituting a system. The in port describes the behavior of filter as the sink of a stream, and the out port describes the behavior of filter as the source of a stream. The two behaviors are exhibited independently, thus explaining why filter was not specified to have only one port as was the case with the component server.
The use of the formal description technique LOTOS renders the benefits of rich tool support for automated reasoning and analysis of software components. In the following discussion, we use LOLA [4], a LOTOS transformational and state exploration tool to reason about the properties of a component. In particular, we show how the testing functionality of LOLA can be used to assist in the retrieval of appropriate components that satisfy specific requirements.
Testing is a means to analyze the properties of a LOTOS behavior, in particular, to determine whether a specification accepts (or rejects) a set (or a sequence) of interactions specified by a test process. A test process is a LOTOS process with a special termination event (e.g., success) that indicates the successful termination of a test run. The application of a test to a behavior specification is a parallel composition of the behavior specification with the test process, as given below.
BehaviorUnderTest [<gates>] | <gates> | Test [<gates>, success]The response of a behavior specification to a test (process) is computed by a state exploration of the test composition. Three types of responses are possible: may, must, and reject. Given a specification L and a test T, T has a may response if it terminates for at least one execution of the test composition when applied to L. If T terminates for every execution of the test composition when applied to L, then T has a must response. Otherwise, T has a reject response.
Consider the retrieval of components that provide the functionality of a server, and when given an integer x as a request, the server will send back x+1 as a reply. We may characterize this requirement as a LOTOS test process. Below is an acceptance test process that determines if a specification accepts a given set of interactions.
In order to determine whether a component is appropriate for the requirement, we test each port of the component using the above test process. Given the behavior specification of a port and the test process as inputs, LOLA will compose them and execute the composed process. For example, while testing the server port of the component server in Figure 2, the must response is obtained, whereas the reject response is obtained while testing either the in port or the out port of the component filter in Figure 3.
Clearly, if a component does not have a port, which, when tested using the acceptance test, has a must response, then the component cannot be the appropriate one to reuse. For example, the server component in Figure 2 is an appropriate candidate for the previous requirement, whereas the filter process in Figure 3 is not. Therefore, the acceptance test helps to reduce the space of candidate components during the component search and retrieval process.
A LOTOS-based formalism has been presented to specify software components. This formalism provides a means to record the architectural properties of components. Benefiting from the rich support of analysis tools, this formalism may facilitate software reuse. In particular, we are using this formalism and related LOTOS tools to facilitate the selection of reusable components in an architecture-based reuse and integration system. We also plan to augment a previously developed formal specification-based component classification scheme [5] by incorporating component architectural properties.
Several projects have applied formal methods to specifying and retrieving reusable components [5, 6, 7]. The formal specifications used in these projects are limited to functional specifications. The only (implicit) way that the components can be used is data sharing and/or function invocation.
The UniCon architectural specification language [8] specifies the interface of a component as a set of players that the component can support in interactions with other components. Each player is specified by a type, optional attributes, such as signature, functional specifications, constraints on use, and so on. Conceptually, the player is similar to the port construct in our component specifications. However, different from our specification, UniCon does not take a formal approach. Instead, it depends more on the use of types to capture the architectural and functional properties. In addition to the player types, UniCon also introduces component types. The component type encapsulates the general class of properties of the component, such as the numbers, types, and specifications of the players defined by the component.
Wright takes a formal approach (using CSP) to specifying software architectures [9]. In Wright, a component is specified in a similar way to our approach. The difference is that Wright does not address the functionality of a component. In our approach, we use LOTOS to specify both functional and architectural properties of a component, rather than just capturing high-level interactions. In addition, LOTOS is an ISO standardized specification language with the support of industrial tools.
Yonghao Chen received his B.S. and M.S. degrees from Xi'an Jiaotong University of China. He is currently a doctoral student in the Department of Computer Science at Michigan State University. His research interests include formal methods and software reuse.
Betty H.C. Cheng is an Associate Professor in the Department of
Computer Science at Michigan State University. Dr. Cheng received her
B. S. in Computer Science from Northwestern University and her
M. S. and Ph. D. degrees in Computer Science from the University of
Illinois at Champaign-Urbana in 1987 and 1990, respectively. She
conducts research in the areas of formal methods applied to software
engineering and applications to parallel and distributed computing,
software development environments, object-oriented development, and
multimedia computing. Dr. Cheng was a
faculty fellow at the Jet Propulsion Laboratory at the California
Institute of Technology, where she investigated the application of
formal methods to the space shuttle software.
Dr. Cheng is a member of the IEEE Computer Society and ACM.
She may be contacted electronically at chengb@cps.msu.edu.
Further information regarding the Software Engineering Research
Group and Dr. Cheng may be found at URL:
http://www.cps.msu.edu/groups/serg/serg.html
.