[ Up ] [ PISA ] [ Composition/Integration ] [ Domain Eng. ] [ Product Lines ] [ Certification ] [ Early Artifacts ] [ OO & DA ] [ Org. Principles ] [ Add. Info. ] [ References ]

Introduction

Our group was one of the three groups that emerged after the originally proposed working groups on "Rigorous Behavioral Specification as an Aid to Reuse" and "Component Certification Tools, Frameworks and Processes" met together for about half an hour and refocused their interests. We began our discussion by listing the main topics that each participant was interested in. After all participants expressed their interests, we were pleased to discover that our interests converged to three main topics:

• Semantic models of component relationships, dependencies and interconnection. Our goal here was to understand what terms such as component, connector, dependencies and component interconnection mean to each of us and how formal specifications can be used to describe them.
• Designing and combining specifications. The objective of this topic was to understand how we can design specifications with the aim of combining them with other specifications to produce new specifications that describe a composite system. We were also interested in understanding how each of us defined the process of combining specifications.
• Specification of non-functional properties of components. Behavioral specifications focus on describing the interface and behavior of operations offered by a component. In order to be able to successfully reuse a component, designers need to understand a number of other non-functional properties of components, such as quality and performance measures, patterns of interaction with other components, etc. We were interested in better understanding how each of us perceived such non-functional properties and how such properties can be captured in component specifications.

We were able to discuss all three topics in varying degrees of depth. Below is a summary of the most important insights that came out of our discussions.

Are Connectors Just Components? Wrong Question!

Should one consider architectural connectors to be simply another kind of component, or to form a distinct class of entity in their own right? This issue is currently the subject of debate among researchers in the field of software reuse and software architecture. A connector is usually, but not always, considered to denote a protocol that enables components to work together. Examples of research that takes the position that connectors are distinct entities include the work of Shaw [Shaw94], and Allen and Garlan [AG94]. Examples of considering connectors just another kind of component include the work of Luckham [Luckham95], and Stovsky and Weide [SW88].

Our discussions on the nature of connectors produced an interesting perspective that might suggest that the question of whether connectors are components is not really the issue. Chris Dellarocas suggested that although connectors can technically be considered to be yet another kind of component, looking at them as a different class of citizen has great potential value in advancing the state-of-the-art in component-based software development.

Most researchers perceive connectors as elements that facilitate the integration of software components by implementing communication or resource allocation protocols, by performing data translation, and generally by bridging the assumptions each interconnected component makes about the "rest of the world." Such issues are orthogonal to the application domain implemented by the interconnected components. Connectors thus form a relatively narrow "horizontal" domain that can conceivably be systematically mapped out. Coming up with a systematic domain analysis of connectors then becomes a much more interesting issue than whether or not connectors are components.

A systematic taxonomy of connectors will aid software reuse in a number of ways:

• It will facilitate and perhaps help us to automate the resolution of component mismatch problems.
• It will make designers of new components more aware of the interconnection assumptions their components are making and will assist the design of better reusable components.

Chris Dellarocas’ work on developing a "design handbook" for integrating software components [Dellarocas97] is a step in the direction of mapping out the domain of software connectors.

Behavioral Specifications Can Be Usefully Augmented with Operational Examples

Traditional model-oriented specifications are based on pre-conditions and post-conditions. Essentially, they encode the interfaces of components and the behavior of each operation provided by components. Steven Atkinson brought up the point that, although such specifications might be technically sufficient, they are not cognitively sufficient. In other words, although they accurately describe what a component is able to do in isolation, they do not provide information that might assist users of such components in understanding how they can profitably reuse that component in conjunction with other components.

In order to enhance the power of specifications, we discussed a number of elements that can be added to traditional specifications. Such elements include:

• Operational, task-oriented examples of using a component in the context of larger applications.
• Common patterns of interaction of a component with other components.
• A "mini-cookbook" of examples of using a component.

We agreed that both traditional behavioral specifications and operational examples are necessary. Both add value for different types of problems. The main research questions, however, are:

• How can we formalize such "examples of use" at a level comparable to that of behavioral specifications?
• How can we integrate the two kinds of specifications?

Protocol Choices Can Bias Component Specifications

Every software component provides a set of core "production" services. For example, a sorting component provides a basic service, which is the generation of a sorted version of its input. In addition to its ostensible function, however, every component embeds a fragment of a protocol for interconnecting with other components. For example, a sorting component implemented as a filter embeds fragments of a pipe protocol for receiving and sending data. A similar sorting component, implemented as a server embeds fragments of a client/server protocol and exposes a very different interface to the rest of the system.

In the course of our discussion we noted that the interconnection protocols which are embedded inside components can create a bias in the way the components are specified. Consider, for example, two sorting components, one implemented as a filter and another as a server. Although the core service provided by both components is the same, the specifications of the components would most likely be very different. In fact, an entirely different way of designing a sorting component—by "recasting" sorting from being an algorithm to being an abstract data type—makes the protocol required for interacting with the component an explicit part of its specification [WOS94].

The most important research questions related to this observation are:

• Should we decouple the specification of the core service provided by a component from the specification of the protocols it embeds, and if so, how should we do this?
• How can we use the specification of the protocols embedded inside a component in order to detect mismatches with other components and, most importantly, to get guidance on how to bridge component mismatches?

Specifying Different Facets of Components

Yonghao Chen raised the point that a software component can be specified from many different viewpoints. From a functional perspective, there can be multiple viewpoints of clients who are interested in different functions provided by the component. In addition, there can be a number of non-functional perspectives for describing a component, such as space, time, resource usage, maintainability, etc.

Two interesting research questions related to this observation are:

• What are the facets of components that can most usefully be included in a component specification?
• How can we merge the various facets of component specifications while maintaining consistency?

Design Dependencies versus Integration Dependencies

In order to reason about the behavior of software systems built from reusable components, David Gibson proposed distinguishing between design dependencies and integration dependencies. When isolated from the context of a specific system, a well-designed component may be defined in terms of other components. When one component is coupled to another specific component as a result of its design, this forms a design dependency. When integrated into a software system, a component must be coupled to other components in the system in order to serve its purpose. The binding of one component’s operations to the imported context of another component may take place statically, when parts of the system are compiled and linked, or it may take place dynamically, at run time. Dependencies that arise from integration of components into a system are integration dependencies.

Consider a library of reusable software components. All dependencies between individual components in the library are design dependencies—dependencies that, in general, should be minimized to improve understandability, maintainability, and reusability. Since an individual component in the library may be built from other components, it may be viewed as an integrated system of components. The dependencies between the sub-components that form a single library component are integration dependencies. Assuming a component and its sub-components are well-designed, there is no compelling reason to minimize integration dependencies. The integration dependencies are just those dependencies necessary to construct the system.

For component-based software reuse to be viable, software engineers must be able to reason about how the behavior exhibited by a component affects the behavior of a system into which it is integrated. When a software component is designed and implemented with all design dependencies clearly expressed, software engineers can reason about many aspects of a component’s post-integration behavior independent of specific systems into which the component might be used. The RESOLVE discipline for software component design requires explicit statement of all design dependencies and supports minimizing design dependencies through parameterization. This approach results in systems about which it is possible to reason modularly, based primarily on design dependencies and not integration dependencies [SW94].

[ Up ] [ PISA ] [ Composition/Integration ] [ Domain Eng. ] [ Product Lines ] [ Certification ] [ Early Artifacts ] [ OO & DA ] [ Org. Principles ] [ Add. Info. ] [ References ]