On the Necessary Conditions for the Composition of Integrated Software Engineering Environments

On the Necessary Conditions for the Composition of Integrated Software Engineering Environments

.

.

DAVID J CARNEY AND ALAN W BROWN Software Engineering Institute Carnegie-Mellon University Pittsburgh. Pennsylvania

Abstract This chapter explores the conditions necessary for integration in a software engineering environment. Integration is considered to be a primary “quality attribute” of an environment, and is defined by the mechanisms that implement it, the services that it provides. and the process constraints that provide its context. This chapter argues that if composition of integrated environments is to become a reality. the necessary first condition is the definition and eventual standardization of interfaces at many functional boundaries not cumntly exploited today. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 A Brief Description of a Software Engineering Environment . . . . . . . . . . 1.2 An Overview of the Integration Roblem . . . . . . . . . . . . . . . . . . 2. A Three-Level Model of Software Engineering Environments. . . . . . . . . . . . 2.1 Integration in Terms of the Three-Level Model. . . . . . . . . . . . . . . . 3. The Mechanism and Semantics of Integration . . . . . . . . . . . . . . . . . . 3.1 Integration Described as a Set of “Dimensions” . . . . . . . . . . . . . . . 3.2 Integration Described as a Relationship . . . . . . . . . . . . . . . . . . . 3.3 Integration Described by Its Semantics and Mechanism . . . . . . . . . . . . 3.4 Summary of Semantic and Mechanism Integration . . . . . . . . . . . . . . 4 Integration in Practice: Rocess Aspects of Integration . . . . . . . . . . . . . . . 4.1 Common Practical Means of Integration. . . . . . . . . . . . . . . . . . . 4.2 The Rocess Context of Integration . . . . . . . . . . . . . . . . . . . . . 4.3 Qualities of Successful Processes. . . . . . . . . . . . . . . . . . . . . . 4.4 APracticalExample. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 RagmaticSolutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 The Conditions Necessary for Integration . . . . . . . . . . . . . . . . . . . . 5.1 The Proper Locality of Software Interfaces . . . . . . . . . . . . . . . . . 5.2 The Search for Standards . . . . . . . . . . . . . . . . . . . . . . . . .

.

.

.

ADVANCES IN COMPUTERS VOL. 41

157

158 159 161 162 164 165 165 167 168 172 172 173 174 175 176 179 179 180 182

.

copyriph( Q 1995 by Audemic Rou Ine. AU rights of rrpmaunim in MY fm I C I Q V.~

158

DAVID J. CARNEY AND ALAN W. BROWN

5.3 The Interaction of Interfaces and Standards . . . . . . . . . . . . 6. Toward Engineered Environments. . . . . . . . . . . . . . . . . . . . . 7. Summary and Conclusions . . . . . . . . . . . . . . . . . . . . . . . . References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . ... ... ...

183 185 186 188

1. Introduction Integration of software components has been the subject of considerable attention over the last decade. Particularly in the domain of software engineering, integration of a set of useful engineering tools has been seen as a means both to improve the practice as well as to reduce the expense of building software. The tools are most often called computer-aided software engineering (CASE) tools, and the integrated collectionsof tools are generally called softwareengineering environments (SEES), or often just called “environments.” The notion of an integrated environment, while attractive, has proven remarkably difficult to implement in practice. Exemplified by the Ada-centric environments [the Ada Integrated Environment (AIE) and Ada Language Systems (ALS)] in the early 1980s (Momser al., 1992). many projects within government and industry have set out in pursuit of this goal: Aspect (Brown, 1991), Boeing Advanced Software Environment (BASE) ( Jolley and Gockel, 1988), Environment for Advanced SoftwareTechnology (EAST) (Bourguigon, 1989),Enterprise I1 (Long and Moms,1993), Software Life Cycle Support Environment (SLCSE) and Process SLCSE (ProSLCSE), (Strelich, 1988) the Special Working Group (SWG) on Ada Programming Support Environments (APSE) of the North Atlantic Treaty Organization (NATO) nations, and several other such projects were all, in one way or another, attempts to define and implement an integrated set of software engineering tools. Each of these projects had laudable features; yet real and genuine success-evidenced by an environment that measurably facilitates software engineering and that has a loyal and growing user base-eluded all of these efforts. Nonetheless, the perceived benefits of integrated environments have been desirable enough that the quest for them continues to drive many government and industry initiatives.’ There are several desirable features or attributes that an environment should exhibit. Integration is perhaps the most desirable attribute, as indicated by its staying power as the I, in such acronyms as Integrated Project Support Environment (IPSE), Integrated CASE (I-CASE), Integrated Software Engineering Environment (ISEE), etc. However, there are a number of other “quality attributes,” such as adaptability, reliability, maintainability, flexibility, and other such “ilities” (International Standards Organization, 1991) that are now perceived as of comparable significance in how they contribute to the goal of a useful engineering environment. Some of the latest directions in environment work-such as the development of process-centered or reuse-driven environments-pertain to the

COMPOSITION OF INTEGRATED SOFMlARE ENVIRONMENTS

159

increasing interest in new paradigms of software development? Other directions-principally interest in environments constructed largely of collections of commercial components-grow from a desire to change the current process of acquisition, to ease the ongoing maintenance burden, and to reduce the cost of introducing and using an environment. This recent emphasis on use of commercially available products rather than special-purpose components is paralleled by an increased interest in standards. Standards, particularly interface standards, are seen as having a beneficial effect on acquiring components that can easily be used in combination. Widely accepted standards have been suggested as a primary means of achieving “openness,” and several significant attempts have been made to assemble lists of standards [e.g., the National Institute of Standards and Technology (NIST) Application Portability Profile (1993)l.One goal of such lists is to find groups of compatible standards that span a range of necessary environment functionality. Further, although seldom explicitly asserted, the “open” quality that would result from the use of standards is usually assumed as somehow providing the ability to “plug-and-play” tools or components. An “open” environment is expected to permit new tools to be added or removed with little effort on behalf of the integrator, and with no effects on the remaining tools in the environment. It is the argument of this chapter that tool integrationand achieving “openness” through standards are only parts of a more complex problem; further, that to focus either on integration or standardization alone is inherently misguided. We argue that to achieve successful composition of integrated environments, it is first necessary to understand the interactions of the semantic, mechanistic, and process-related aspects of integration. We then suggest that this understanding will result in a focus on many software interfaces now considered “low-level.” Thus, exposure and eventual standardization of these low-level interfacesand the tacit assumption that software will be engineered according to this understanding-= the necessary conditions whereby integration, as well as such other quality attributes as flexibility and adaptability, can become real characteristics of commercially viable SEES.

1.1 A Brief Description of a Software Engineering Environment The role of a SEE can very clearly be stated in terms of the automated support for the development and maintenance of software systems. However, the characteristics of a SEE that fulfils this role are much more difficult to define. In particular, a SEE can be considered from many viewpoints, each of which highlights different characteristics of interest. Perhaps the most obvious, for example, is to consider a SEE to be a collection of commercial products that make use of operating system facilities to execute on one or more computers.

160

DAVID J. CARNEY AND ALAN W. BROWN

While such a view provides a product-oriented perspective on a SEE, in this paper we consider a SEE primarily from a service-oriented perspective. That is, a SEE is viewed as providing services that can be used in the development and maintenance of software systems. The services may be implemented in a variety of ways, and be used by many and varied software organizations. Furthermore, we make a basic distinction between two classes of services offered by a SEE: those that are provided primarily to support end-users in the tasks of developing and maintaining software systems (called end-user services), and those that are provided primarily in support of those end-user services (called framework services).This distinction is useful because it recognizes the different roles played by products that form a SEE. The separation of SEE services into end-user and framework is most clearly illustrated in the reference models supportedby the European ComputerManufacturers Association (ECMA) and NIST (ECMA & NIST, 1993; SEI & NIST, 1993). These services are summarized in Fig. 1. These reference models describe sets of services that may be found in any SEE. The models can be used (and have been used) as a checklist as part of an evaluation of SEE products, or as the basis for constructing a SEE acquisition strategy. It is important to emphasize, however, that a service-oriented view of a SEE is useful only insofar as it highlights the functionality that may be implemented in a SEE. Such a view must be augmented with other views that illustrate other SEE characteristics (e.g., the software and hardware components that implement the SEE and their detailed interactions).

~~

~~

Support Servlces (e.g., publishing, communication, administration)

Pro ect MaAagement Services (e.g., Planning, cost estimation)

Technlcal Management Servlces

.

(e.g., confi mgt, change ma.)

Technical Engineering Services (e.& system eng, so areeng.)

Framework Services (e.g., object mgt, process mgt, operating system) Fio. 1. A summary of SEE services.

COMPOSITION OF INTEGRATED SOFTWARE ENVIRONMENTS

161

1.2 An Overview of the Integration Problem We concentrate our attention on environments composed of collections of components drawn from different commercial sources. While environments can be constructed as single-party, proprietary, or “black box” solutions, we are interested in the more general problem faced by many organizations.As a starting premise, we take the view that integration is a desirable condition in an environment. Hence, in our view of an environment, integration implies cooperative interaction between the heterogeneous components. Integrated interaction of heterogeneous components can be observed as common in most engineering disciplines. It makes possible the engineer’s main task of specifying and composing a system, and in choosing appropriate parts and tools to accomplish this. Whether the components of the system axe small (e.g., screws, plugs) or large (e.g., girders, engines), it is generally the case that an engineer can select components and tools from a variety of possible sources. Multiple tools are available that exhibit comparable functionality; it is expected that a mix of tools will not (typically) cause fundamentalproblems; and replacement of one supplier’s components with another supplier’s components should not (typically) invalidate the tools that operate on them, nor invalidate the system being constructed. The proper joining of the components and tools is assured because they offer well-defined interfaces to each other (e.g., the plug has prongs and the socket has holes), and the makers of components on both sides of the interface abide by standardized agreements about the interface’s dimensions (e.g., the plug has a specific number of prongs, each of a specific shape and size, that fit the socket’s holes). A tool or component has a set of implicit and explicit uses; there is, whether stated or not, a set of assumptions about sequence,priority, and appropriateness (i,e,, some “process”) that underlies both the independent use of tools and components as well as the construction of the system. Finally, maintenance and upgrade of the system depend on the same assumptions and agreements. The point of this brief description is to indicatehow integration,a desirable goal, is inseparable from other factors. The harmonious interaction of heterogenous components (which is one way to view their “integration”) is essentially a product of these other factors-well-defined interfaces, whose definition is based on widespread agreements that eventually may become officially standardized; and interfaces that support an underlying defined process. Integration is the state or condition that results when these other factors properly cooperate. Thus, integrated environmentscannot be achieved simply by taking tools and “adding integration.” Similarly, the pursuit of standardsper se is fruitless without considering the locality of the software interfaces needing standardization, as well as the essential centrality of the processes that the interfaces will support. With

162

DAVID J. CARNEY AND ALAN W. BROWN

reference to the problem of building software engineering environments, these are all intrinsically related issues, and are not amenable to piecemeal solution. The remainder of the chapter examines the premise that integration is inseparable from these other factors. Section 2 defines a three-level model of a software engineering environment; this model provides a conceptualbasis for the following sections. Section 3 examines the semantic and mechanistic aspects of integration. Section 4 examines the process-related aspects of integration. Section 5 discusses how all of these aspects relate to the locality of interfaces and to standardization, and act as the necessary condition of integration. Section 6 summarizes the argument of the chapter.

2. A Three-Level Model of Software Engineering Environments In order to discuss any quality attributes of an environment, and particularly the notion of integration, we need an abstract model of an environment that is general enough to permit consideration of the environment’s components, their interconnections, and the circumstances in which the environment will be used. The model we propose distinguishes three levels at which an environment can be discussed. 0

0

0

At one level the environment consists of the services it makes available to environment users. We consider a service to be an abstract description of a discrete capability of a software engineering en~ironment.~ At another level the environment can be described in terms of the mechanisms that implement those services. Conversely, the services can be said to depend on some set of mechanisms. At yet another level the environment can be defined by the process being enacted, that is, the set of goals and constraints of a project or organization and the desired sequence of project activities. The environment’s services support the process being enacted; conversely, the process constrains the set of services provided by the environment.

Together, these three levels of description and their interrelationships provide the context in which many aspects of an environment can be described. Figure 2 illustrates this model. Looking at these three levels in more detail, we see that the mechanisms level includes the architectural concerns and the technology components that will comprise the integrated environment. Concerns at this level include implementation issues, such as the software interfacesprovided by the environment infrastructure (e.g., operating system interfaces), the software interfaces provided by individual tools in the environment, and the specific integration mechanisms that

COMPOSITION OF INTEGRATED SOFTWARE ENVIRONMENTS

163

FIG. 2. A three-level conceptual model of a SEE.’Abbreviations: BMS,broadcast message server; RDBMS. relational data base management system.

will be used to connect the various environment components. The mechanism level also includes many architecturalconcerns of the tools, such as their internal structure (e.g., cliendserver)and data management structure (e.g., data dictionary, database); this level is concerned with the technology available and with the techniques that can be applied to connect the different environment components. The services level corresponds to an abstract description of the functionality that the environment offers to its users. Concerns at this level include the specification of the services provided by an environment, and how (at an abstract level) those services relate to each other. Integration concerns at this level may include such things as defining the relationshipsbetween the version control and the data management services, or describing the way in which a specification and a design service are related through traceability design components. Note that we do not directly equate a “service” with the term “tool.” We avoid this partly because the term “tool” has lost any useful precision; it can span the spectrum from a two-line shell utility to a massive product that verges on a full environment? But more importantly, the notion of “service” is an abstract one; the actual implementationsof services in our model exist not here but at the mechanism level. At the service level, we are interested in the descriptions of the individual services provided and with their logical connections. At the mechanism level the principal interest is the provision of the individual service and the complexities of connection that the serviceprovider offers to other components. The processes level corresponds to how services cooperate in the context of a particular software development process. The focus of this level is the process

164

DAVID J. CARNEY AND ALAN W. BROWN

specification for how software will be developed. This specification can define a view of the process from many perspectives, spanning individual roles through larger organizational perspectives. For example, the way in which design documents gain approval before implementation begins is a process constraint that affects the way that services are integrated. Another example might be the bug tracking and version control process that must be followed when errors are found in existing code. There may be a wide range of activities supported, with many degrees of freedom in the use of the environment, or the environment may be restricted to a smaller number of well-defined processes. Although these levels are conceptually separate, there are important relationships between them. The relationship between the mechanism level and the services level is an implementation relationship: services may be implemented by different mechanisms, and conversely, a single mechanism may implement more than one service. In this way, the abstract functionality of an environment at the services level can be described in terms of the concrete mechanisms that implement those services, and on which the services depend. The relationship between the services level and the processes level is a supporting relationship. The processes that are to be supported act as a set of guidelines and constraints for the combination of services. For example, the way in which the design and the coding services interact is a function of the development process that is to be supported. Also, the way in which they interact in support of a classic waterfall style of software development may be very different from their interaction in support of a prototype-oriented style of development. The differences between these processes will constrain the environment’s services, and particularly how they are integrated.

2.1 Integration in Terms of the Three-Level Model By using this three-level model, many facets of an environment can be discussed. An environment’s functionality can be related to the tools and integration technology that realize it; the organizational and development processes that constrain and guide the use of environment services can be discussed in terms of their effects on those environment services. Most of all, however this model provides a conceptual framework for understanding environment integration, and we use it as a working context and expand on its meaning and application in the rest of this chapter.6To begin, we briefly summarize the integration concerns at each of the three levels. At the services level we are primarily concerned with behavioral aspects of an environment. That is, the services that an environment provides can be considered to be an abstract description of the functionality that the environment provides. In considering integration at this level, we focus upon the semantics of the integration, as found in the agreements that relate the supported operations

COMPOSITION OF INTEGRATED SOFTWARE ENVIRONMENTS

165

of the environment. For example, consider the configuration management (CM) services that an environment provides: when discussed at the service level, we can focus on the model of CM that is supported [e.g., composition model, or change set model (Cagan, 1990; Feiler, 1991)], on the definition of the CM operations that the environment supports (e.g., check in, check out), or on the relationship of CM support to other services (e.g., CM and data management). In the remainder of this chapter we shall use the term “semantics” when integration at the services level is discussed. Our main concern at the mechanism level is with implementation details. In discussing integration at this level we must be concerned with the details of the architecture of the environment (i.e., the logical and physical design of the environment, and the mapping between these two). Examples of the integration mechanisms of interest are the use of a software bus for event synchronization, and persistent shared data through a common database. The way in which combinations of such mechanisms interact in providing the services offered by the environment must be considered when designing or analyzing a SEE. At the process level the development methods (and their constraints)employed by an organization are of concern. There is a wide variety of elements that must be considered at this level. This includes the various engineering processes the organization follows (e.g., a bug tracking process, a design review process, and a product release process), the organizational process that guides the organization at an enterprise level (e.g., project management, and organizational process improvement), and the personnel issues that affect the success of introducing new tools and techniques into the organization (e.g., training needs, and organization culture and climate). The relationships between these many and diverse elements are the basis for considering integration at the process level. The services provided by the environmentmust be used in support of these process constraints and needs.

3. The Mechanisms and Semantics of Integration We begin by considering in more detail the issues of mechanisms and semantics of integration;the mechanisms that implement the environment’sintegration and the semantics that affect it. We must first examine how tools might be integrated in terms of the underlying mechanisms, then examine the required semantics for what is integrated. We begin by reviewing two classical approaches to defining integration, since these approaches have contributed significantly to our own ideas. We then describe our notion of the mechanisms and semantics of integration.

3.1 Integration Described as a Set of ”Dimensions“ A seminal paper by Wasserman (1990) viewed integration as a set of dimensions that can be applied to an environment. These orthogonal dimensions of

166

DAVID J. CARNEY AND ALAN W. BROWN

integration allow the environment to be assigned attributes in each of the dimensions, Wasserman proposed five dimensions of integration, three of which were discussed in detail, Control integration relates to intertool coordination, data integration relates to information sharing, and presentation integration refers to user interface consistency and sophistication. The essential idea of Wasserman’s paper is that any environment can be evaluated for its approach to integration in each of these dimensions. For example, in the data integration dimension, one environment may use a file system, while another uses a database. These would be said to have different data integration attributes. By examining an environment in each of the dimensions, it is then possible to define the set of integration attributes of that environment that characterizes its approach to integration. This allows some measure of comparison of different environments in terms of their integration approach. Figure 3 illustrates three of the integration dimensions proposed by Wasserman. The dimensions are shown as orthogonal, and have gradations marking various points along each of the axes. Wasserman subsequently refined and expanded his proposed integration dimensions to includeplatform integration (system support services) and process integration (support for a well-defined development process). While the dimensional view of integration has merit in separating a number of integration issues that previously had been confused, it is also somewhat problematic. One question that immediately arises is whether the dimensions are truly orthogonal, and whether they can (or should) be considered separately. For instance, it is at least arguable that there is a close and complex relationship between data and control integration that suggests that these two are not truly

Presentation

Standard tool kit Standard window manager

---

Shared

Shared

Control FIG. 3. Three integration dimensions.

Shared Object Management

COMPOSITION OF INTEGRATED SOFMlARE ENVIRONMENTS

167

separable. For example, restricting access to shared data is undoubtedly a form of control that synchronizes interaction with the data, while a control message sent from one tool to another will most often contain or refer to one or more data items, and is dependent on format of arguments, parameters, etc. Another problem with the dimensional view is that the items that populate each axis are commonly ranked in an arbitrary progression toward greater sophistication,leading to an interpretation that greater sophistication is equivalent to a “greater” or “better” level of integration. In fact this is not necessarily so. Certainly the mechanisms are more sophisticated in terms of the integration approaches they support. However, the important role played by the semantic agreements between tools (e.g., agreeing on what the shared data, messages, or screen icons actually mean) is not addressed in this view.

3.2 Integration Described as a Relationship Work by Thomas and Nejmeh (1992) focuses on integration as a properfy of the relationship between two or more environment components. They take this approach to highlight that integration addresses the way the components interact rather than describing characteristics of a single component. It is this assembly of components that is the key to a well-integrated environment. Thomas and Nejmeh identify several types of inter-component relationships that are of particular importance: 0

0

0

Tool-ro-roo1 relationships. Thomas and Nejmeh expand on Wasserman’s dimensions of integration by discussing the mechanisms through which individual tools interrelate. Tool-ro-frameworkrelationship. As the tools are hosted on some framework component (e.g., a database system or an operating system), the extent to which each tool makes use of the framework’s services is significant. Tool-to-process relationship. How well each tool supports the process being carried out is another relationship of interest. The relationship may be expressed in terms of a tool’s support for an individual step within the software life cycle (e.g., requirements definition), and its support for multiple steps (e.g., the requirements, design, and coding steps).

A useful distinction that is made in this work is between “well integrated” and “easily integrable.” An environment can be well integrated with respect to how end-users of the environment carry out their application development tasks. For example, there may be a consistent and intuitive user interface for interaction with all tools in the environment. On the other hand, a well-integrated environment is not necessarily easily integrable with respect to how easy it is for the environment builders and administrators to assemble the environment, tune it for particular needs, and replace one tool with another. To a large extent these two views

168

DAVID J. CARNEY AND ALAN W. BROWN

of integration are independent; there is no guarantee that an environment that is easy to assemble is enjoyable and productive to use, or vice versa. Thomas and Nejmeh’s view of integration is illustrated in Fig. 4, which shows their view of integration as a relationship between components, and which also shows the various kinds of relationships that may exist. While this view of integration is fruitful, it has at least two limitations. First, the integration relationships are expressed as “goals” that an environment may achieve. Unfortunately there is no discussion in their work about how to achieve these goals, what dependencies lie between them, and what tradeoffs must be made. Second, a tool is not equivalent to an end-user service. Rather, a tool may implement part of a service, or many services. But in using this approach to analyze an environment composed of a number of tools, there is no guidance on which of the many possible tool relationships are of most interest. While an integrator could use this approach to consider the potential relationships between every pair of tools in the environment, there is little direction in addressing the environment as a whole. And in reality, in an actual environment, the potential relationships between a pair of tools are heavily influenced by the other components of the environment.

3.3 Integration Described by Its Semantics and Mechanisms Having considered both of these valuable views, we now build on them to examine the semantic and mechanistic aspects of integration in greater detail. We start with a simple strategy: supposing that integration is concerned (at least) with the sharing of information,we must determine: What information is shared? How is the information shared? Who is sharing the information? When is the Process Interface

t

t

w

lifecycle stages

lifecycle steps

tool-tool control tool-tool data tool-tool presentation

tool-framework

Framework Interface

Fro. 4. Relationships among environment components.

COMPOSITION OF INTEGRATED SOFTWARE ENVIRONMENTS

169

information shared? For the moment, we concentrate on the first two questions (“What” and “How”), since they focus respectively on the issues of semantics and mechanisms of information sharing. The other questions (“Who” and “When”) will be considered in the following section when we discuss the issue of process definition and enactment.

3.3.1 Semantics: What Information Is Being Shared Of the types of information that may be shared, the range is obviously very broad, including application data, metadata (descriptions of the structure and relationships among data items), documents, electronic designs, graphics, hardware designs, product descriptions, and code. But whatever types are of concern, the question of “What is being shared” is not answered merely by describing the shared data; the question is actually more complex, being inseparable from the forms of agreements that exist between the components that do the sharing. The agreements might be as simple as agreeing which port number will be used in a remote procedure call access or as complex as an information model that defines the overall business functions of the whole organization. Given that this range of levels of agreement can exist, it is useful to categorize those levels in some way. The following five levels’ are not intended to form hard categories, but rather to suggest the range of possible agreements. 0

Carrier level-By analogy with the use of the term in electroniccommunications, carrier level agreements allow data to be communicated between two agents (i.e., tools or users) without any agreementon the syntax or semantics of the data being shared. An example is the use of a common byte stream between tools. Lexical levels-When the agreement includes a common understanding of the basic tokens of data being shared, we can say that a lexical level of agreement exists. Comma separated lists of items are an example of a particularly simple form of lexical agreement that can be used. Similarly, an agreement over how many bits constitute a byte, whether there is odd, even, or no parity, and so on. Syntactic level-if the agreement extends to a common syntax for the shared data, then we can say there is a syntactic level agreement. Some of the structure of the data being transmitted is agreed, but the meaning and implied behavior is not shared. An interface such as the Structured Query Language (SQL) is an example of a syntactic level agreement. Semantic level-For a more meaningful exchange of information to take place there must be semantic level agreement. Here, there is a shared under-

170

0

DAVID J. CARNEY AND ALAN W. BROWN

standing of what the data items being shared actually mean. A common data schema used by a set of tools is an example of a semantic level agreement. Method level-At times the agreement extends to the point where there is a shared understanding of the method, or context, in which the agreement has taken place. This is called method level agreement. The agreements being drawn up by the American National Standards Institute (ANSI)X3H6 group is representativeof the attempts being made to define a set of common semantics for events that allow tools to expect certain behaviors from others with which they communicate.

As noted above, these categories do not have hard boundaries, nor are they necessarily independent. In fact, it is probable that any actual sharing of information between two tools will involve agreements at more than one of these levels. It is tempting to conclude from these levels that integration in an environment should always take place at as high a level as possible (i.e., at the method level). However, there are important consequences that must be considered as the sophistication of the level of agreement increases. In particular, higherlevel agreements are likely to be more complex and more closely related to the specialized needs of the tools. As a consequence, they suffer from a number of drawbacks; the making of such detailed agreements between different tools (and consequently different tool vendors) can be very difficult, the agreements can be slow to evolve over time, and the agreement can be so specific to the needs of a small group of tools that they have limited appeal. In fact, it has been noted that increased levels of agreement between integrated tools can often be a major inhibitor to the openness that environments seek (Brown and McDermid, 1992).

3.3.2 Mechanisms: How Information Is Shared The approaches for how information sharing is accomplished, i.e., the mechanisms that accomplish it, fall into four common classes-direct tool communication, direct data transfer, common data store, and event coordination mechanism. We briefly review each of these in turn.

3.3.2.7 Direct Tool Communication. Direct tool communication is the most common way that tools exchange information. Most often the communication takes place via unpublished, vendor-specific interfaces. Typically, a tool developer identifies an area of functionality that its tool does not address and forms what is often called a strategic alliance with another tool developer. They then collaborate to share knowledge about their tools, provide or tune interfaces to their tool’s functionality, and develop any additional code they require to enable the tools to work together. This approach has been seen between software design and documentationtools, software requirements and software design tools,

COMPOSITION OF INTEGRATED SOFTWARE ENVIRONMENTS

171

software design and coding tools, and so on. Documented details of the internal interfaces used are seldom made public, but are considered to be the “value added” from purchasing the integrated tools. Where the interfaces are publicly known, the tool developers rely on the fact that detailed knowledge on how to use those interfaces must be acquired before they can be effectively used. The specific mechanismsin question could include Remote Procedure Calls, broadcast messages [e.g., Hewlett-Packard’s (HP‘s) Broadcast Message Server (BMS) (Cagan, 1990)], or object requests [e.g., an implementation of the Common Object Request Broker Architecture (CORBA) (STARS Program Office, 1992)l.

3.3.2.2 Direct Data Transfer. In this approach, when information sharing is required between two tools, the data is written out by one tool in an agreed format and read in by the other tool. The tools can maintain information in an internal form appropriate to the tool’s function and translate data to and from the external format for communication with other tools. As a result, the tools can individually maintain data in different specialized formats, increasing the speed and efficiency at which they perform their particular tasks. A consequence of this approach is that each of the tools must provide services that allow the conversion to and from the external format. Depending on the complexity of the transfer format, the parsing and translating of data may be a nontrivial task in terms of time and system resources. This may have an impact on the tools’ overall performance and also may constrain the frequency and quantity of information transfer. 3.3.2.3 Common Data Store. Another approach is to maintain data structures and formats as a separate artifact under external control; a common data store can be provided that is external to the tools that wish to share information. The main difference between this approach and the direct data transfer approach is that the common representation that is used to share data now persists in this form in secondary storage.The expectation is that this persistent, canonical form is used as the primary means of data storage for each tool. The specific mechanisms could vary from simple use of the native file store to a sophisticated data repository together with a set of agreed-on schema definitions [e.g., an implementationof the PortableCommon Tool Environment (PCTE)with a shared set of schema definition sets (Wakeman and Jowett, 1993)l. 3.3.2.4 Event Coordination Mechanism. The basis of this approach is that tools inform other interested tools when important events are occurring, thereby ensuring appropriate coordination between the tools. For example, the check-in of a new source module may be of significance to a metrics tool, to a source code analysis tool, to a project management tool, and so on. Knowing that this event has occurred enables information sharing to take place at the

172

DAVID J. CARNEY AND ALAN W. BROWN

appropriate times. Specific mechanisms that could implement this include semaphores, operating system signals or interrupts, or the notification mechanisms provided by some repository implementations. This approach is orthogonal to the three noted above: there is still the necessity for some agreement about format and structure, both of the data to be shared as well as for the messages that provide the coordination of events.

3.4

Summary of Semantic and Mechanism Integration

In this section we have considered a number of semantic and mechanistic aspects of environment integration. Though these two aspects are often inseparably connected, it is useful to conceptually distinguish between them in order to gain deeper insight into the overall problem of tool integration. We also note that distinguishing these two aspects of integration has direct relevance for the environment builder or implementer. From the perspective of the semantics and mechanisms of tool integration, implementation of an environment can be viewed as a complex design exercise. The goal of the designer must be to consider the various choices that are possible, consider the advantages and disadvantages of each, and then document the decisions that are made. The basis for making each decision will be the effect the decision will have on the quality attributes of the environment. For example, if the designer considers an attribute such as flexibility to be of greater importance than performance (e.g., if the environment is expected to change frequently over time), then a decision may be made to be satisfied with simple, low-level agreements of data semantics between tools. Thus, as the environment components are replaced over time there may be a reduced amount of effort involved. The consequencesof such a decision, however, will be that the level of integration of the tools is reduced because the tools will need to parse the data that is shared and reconstruct much of the semanticsat each data transfer. Different choices at the semantics and mechanisms level might be made if the priorities of flexibility and data-sharing performance are reversed. Hence, the task of the environment designer and implementer is largely one of selecting quality attributes, identifying the relative priorities of those attributes, and then making choices of the semantics and mechanisms of integration in terms of the ways in which they affect those quality attributes. While this process sounds relatively straightforwardin abstract terms, in practice there are few welldefined guidelines and metrics to assist the environment designer in making these tradeoffs.

4. Integration in Practice: Process Aspects of Integration The importance of process definition and enactment for software development and maintenance has had ample discussion in the past few years, and needs little

COMPOSITION OF INTEGRATED SOFlWARE ENVIRONMENTS

173

justification here. However, the relevance of process definition and enactment for tool integration has been little mentioned. We examine here some of the ways in which these issues are interrelated, and why consideration of the process aspects are of fundamental importance for integrating tools. A key element of our three-level model is that process-principally in its definition and enaction-provides a necessary context for integration. We argue that any consideration of “real” integration, i.e., any instance of an actual integrated toolset, must include consideration of the process (or processes) that provide the context and background against which the tools are integrated.

4.1 Common Practical Means of Integration Before examining the process notions themselves, it is useful to briefly touch on some of the actual practices used in integrating software components. These will be revisited below when we look at a practical example of integration and the effects that process constraints can have on it. One common situation occurs when a project or organization decides that two or more “standalone” tools (i.e., commercially separate products) should be “put together” in some manner. The “putting together” might simplistically mean that the output data of one tool is automatically fed into the second; it could mean that one tool invokes another, or other similar types of relationship. The semantic aspects are often minimal; e.g., the tools could already agree on the nature of the common data. Typically, the desired integration is essentially aimed at reduction of redundant data entry, or at enhanced control flow. One dependable mechanism for this “putting together” is a shell script; the script freezes the series of command-line invocations that would occur if the tools were run in interactive, standalone mode. Scripts can provide temporary files and variables for use as ad hoc data stores, and invocation of tools is convenient. Another means, somewhat more sophisticated, is seen in messaging systems. Using these mechanisms, tools send notifications (e.g., about starting or stopping) to each other at certain point in their executions. Messaging systems can be used in a very simple way, by “encapsulating” a standalone tool with a wrapper that sends and receives messages. A more complex manner of use involves rewriting a given tool to incorporate the power of the messaging system into the tool’s working. (While this latter manner of use is more powerful, we note that it is not an option for a third-party integrator, since it requires alteration of the tool’s source code.) In either case, whether script or message system, there is an implied order of events. There are assumptions made by the integrator about sequencing, about data and control flow, about the party or parties that are interested in certain events; in short, the “putting together” of the tools, even by a simple shell script, implies a form of process definition and the means for enaction of a process.

174

DAVID J. CARNEY AND ALAN W. BROWN

4.2 The Process Context of Integration Process definitions deal (among other things) with the “Who is sharing the information” and “When is it shared” questions posed above. Process definitions provide context for information sharing by specifying the actors and the sequences of activities relevant to a chosen paradigm of software development. Process definitions typically find expression in some diagramming technique. For this chapter, we shall use a modified form of the notation called IDEFO, although many others could be used equally effectively.’ In this notation, there are boxes (labeled with verbs) and arrows (labeled with nouns) connecting them. Using IDEFO, processes are defined through decomposition into progressively lower subprocesses. For example, Fig. 5 shows how an arbitrary process might be expressed and decomposed one level. The process at the top level is indicated by a single box with one input, one output, and one control (for instance, in the form of some requirements). The process decomposes at the next level into five subprocesses (here named 1-5). The input, output, and control from the top-level diagram are also shown in the decomposition; in addition, new (lower-level)inputs, outputs, and controls appear in the decomposition. The arrows labeled A and B are the data outputs of subprocesses 1 and 2 that become inputs to subprocesses 3, 4,and 5; and the arrows labeled X and Y are outputs from subprocesses 3 and 4 that form controls on 2, 4,and 5. They could assert control either in the sense of allowing other subprocesses to begin or as feedback loops for other subprocesses. They would Some-control

To level Dehion

Some-wntrol

First-level Decomposition

(internal inputs, outputs, and controls)

\

FIG. 5. An example process definition in IDEFO.

COMPOSITION OF INTEGRATED SOFTWARE ENVIRONMENTS

175

be things such as notifications of success or failure, or specifications for sets of actions to be carried out.

4.3 Qualities of Successful Processes Given any process definition, there are at least two qualities necessary for its success. The first is that it be flexible, i.e., the process will permit itself orderly change. A second quality is that the process will permit metrics to be gathered during its enactment. We consider both of these qualities to be required for the process aspect of an integrated environment.These qualities can be paraphrased more simply by refemng to the IDEFO notation: the presence of an arrow (of any sort) suggests that:

0

To evolve the process description, someone may wish to reposition the arrow somewhereelse on the diagram (i.e., to represent a modified process); To monitor the process, someone may want to make some measurement while an arrow is being traversed (i.e., during process enactment).

Now, when an organization has defined its engineering processes, it creates process diagrams such as the IDEFO example above and then seeks means to enact those processes, usually through the support of automated software tools. T h i s is where the problem begins, because the definition of subprocesses that are significant to any given process definition may or may not bear a relationship to the workings of tools that could support them. Specifically, the tools’ interfaces may or may not be consistent with the inputs, controls, and outputs defined in the process description. For instance, in the above example, tools might exist that have a good fit with steps 1.4, and 5 : their functional operations correspond to whatever the functional descriptions of the three steps, and their inputs and outputs also correspond to the inputs and outputs named in the process description. But it is conceivable that the only available automated support for steps 2 and 3 is a product that combines these two process steps. In this case, one or more of the following may be true: 0

0

0

It is possible that the tool will not permit arbitrary metrics gathering at the connection between 2 and 3 (the feedback loop from 3), or over the independent output from 2 (which serves as input to 4). The output from 2 is input to 4; the output from 3 is control over 4. The tool may or may not permit this distinction in its output (i.e., the granularity of output may not be fine enough to distinguish the data from the control factors in the succeeding process steps. If the process description evolves, for instance, so that both 3 and 4 provide a controlling feedback loop to 2, it is unlikely that this will be implementable using that product.

176

DAVID J. CARNEY AND ALAN W. BROWN

In any of these cases, the end result is that automated support-in the form of an integrated toolset-is either weakened or impossible using this collection of tools. The process will be enactable only by such means as manual file copying or even redundant data entry. This introduces a probable loss of process monitoring and traceability and a corresponding rise in the risk of data error.

4.4 A Practical Example The point of the above example is to demonstrate in an abstract sense how process constraints may affect tool integration. Here we transform this example into a real one that might be faced by an actual software-producingorganization. Let us imagine a project whose process description includes creating source code with an editor, compiling the source, running the (successfully compiled) source file through a standards checker, and then entering the final result into the configuration management system. (We omit a debugging phase for simplification.) The standards checker is one that flags poor coding practices such as one-character variable names, excessive function length, presence of gotos, and similar practices deemed unacceptable by the organization. The IDEFO description of this process is shown in Fig. 6.9 It is possible to conjecture that at some time, a different project manager might insist on a slightly different sequence of these process steps, namely that all code must be run through the standards checker before compilation. This revised process description is shown in Fig. 7. We observe that in both cases, the project manager wishes to keep a detailed account of all activities: track the time that a programmer spends in an editor,

I

1

\

I

ZjZi code

module

FIG.6. An illustrative example using IDEFO.

COMPOSITION OF INTEGRATED SOFTWARE ENVIRONMENTS

\

177

\

organization's

standards ASCII file

t

fail

language rules

1

module

FIG. 7. An updated example using IDEFO.

record the number of times the compiler is invoked, and so forth. Company policy also dictates that use of the standards checker (in either version of the process) is mandatory and that the programmer should not have the option of sidestepping it. Many tools and products exist to enact either of these processes, though with differing degrees of integration and automated support. A typical (and nonintegrated) way to enact either might be to acquire four separate tools [e.g., the emacs editor, a C compiler, a homegrown standards checker, and Unix's source code control system (SCCS)] and to use each independently; this is probably done in a great number of organizations today. While there are drawbacks (e.g., metrics on use of the tools must be recorded manually), there are also benefits (e.g., there are no problems in moving from the original process definition to the updated one in Figure 7). But this type of solution is a prime candidate for integration. For instance, the way that the programmer must use the editor and compiler in standalone mode is very painful: invoke the editor, then invoke the compiler, save a separate file of compile-timeerrors, step through the error file while editing the source file (e.g., in two windows), etc. This toolset could be minimally integrated in a number of ways. For instance, through use of a messaging system the compiler and the standards checker could be encapsulated so that the compiler notified the standards checker on successful compilations; a script could provide the same functionality. Reversing the order of those two tools would be trivially easy. It would be equally easy to add metrics-gathering code to either mechanism, thus giving us the two required

178

DAVID J. CARNEY AND ALAN W. BROWN

capabilities for successful process integration (i-e.. the process can evolve and it can be monitored). However, the inconvenience of the editkompile cycle noted above is still present, and might not be as easily addressed by a script or message approach. To answer this need, some more sophisticated products offer a “compilation environment,’* typically including an editor integrated with a compiler, and possibly such other tools as a debugger, static analyzer, etc. In these products, when the compiler encounters an error, the editor is automatically invoked with the cursor positioned on the failing line of source. Products of this type are common both in the personal computer (PC)world (e.g.. Borland’sTurbo compilers) as well as the workstation world (e.g., HP’s SoftBench toolset). For the original process description, products such as these appear to offer excellent integrated support. There is no question that the “preintegrated” editor/ compiler products save time and effort, as well as probably helping to produce a sounder result. Integrating such a product with any standards checker and any configuration management tool could then be accomplished by shell scripts, encapsulation, etc. However, the project manager’s goal of obtaining metrics on compiler invocation or duration of editing sessions may or may not be attainable. For instance, the product may be structured so as to make counting compiler invocations impossible. The automated reinvocation of the editor may not permit accurate tracking of time-related metrics. If these (or other such examples) are the case, then “preintegrated” products such as these will provide automated support for the functional steps of the process only; their integration does not provide (and may not permit) automated support for the monitoring or tracking of the process. When the process definition evolves, however (i.e., the standards checker is to be invoked before compilation), the situation may be even worse, since the process now demands that the product used will permit arbitrary tool invocation from the editor, rather than the preordained sequence of “edit-compile.” Unless such a capability exists, the process cannot be supported at all by the “preintegrated” type of product-at least, not in an automated manner. The user must, on completing the editing phase, resort to: opening a second window on the screen, saving the source file, invoking the standards checker (in the second window), and so forth.” As in the first process definition, monitoring the process and collecting metrics becomes more difficult. Further, the company policy of mandating the use of the standards checker is even less likely to succeed, since the use either of scripts or encapsulations to integrate the standards checker is very likely to be impossible. As an even simpler example, a user of one of these “editodcompiler” products might wish to substitute a different editor for the one packaged with the product. This will again depend on the individual product: Hp’s Softbench does permit

COMPOSITION OF INTEGRATED SOFTWARE ENVIRONMENTS

179

the substitution of another editor, as long as the user provides an encapsulation. However, as far as the authors can determine, it is not possible to decouple the text editor from the Borland Turbo products in order to substitute another editor of choice. This difference does not in any way imply that one product is superior to the other, but only that two products that exhibit similar functional behavior can offer quite different types of integration potential for a third-party integrator.

4.5 Pragmatic Solutions It is tempting to answer problems of this type thus: “Select a different product, one that does provide the appropriate flexibility.” But this is very often not an option; the product may be mandated, or there may be no existing product that quite does the desired job. In reality, what typically occurs in such a situation is one of the following: 0

0 0 0

The process is enacted without using automated support, by manual means as described above. The process is rewritten to accommodate the product. The organization writes its own automated tool that conforms to the defined process. The product’s vendor is persuaded to incorporate the needed functionality.

While all of these pragmatic choices solve the problem at hand, they are all intuitively unattractive. The root of the problem is that there is currently no correspondencebetween the interconnectionsexposed in a process decomposition and the interfaces presented by the available CASE tools and products. This results either in doing the task manually, in corrupting the defined process, in expanding the vendor’s product to support the desired process step, or in abandoning entirely the notion of using commercially available components for an integrated environment. Of these unattractive solutions, the first and second, or some permutation of both, is the most practical one, and is most often done in actuality. The third solution (creating a “homegrown” tool with appropriate flexibility) depends on the precise nature of the process steps in question and the cost of creating a tool for that functionality. The fourth solution (where a vendor’s product is revised to encompass greater functionality) is a frequent occurrence, as it is attractive to vendors to increasetheir tools’ potential market. It also has the greatest potential for harm, an issue we consider in the next section.

5. The Conditions Necessary for Integration We have adapted our three-level model of an environment to isolate different aspects of the integration problem. One aspect concerns the broad range of

180

DAVID J. CARNEY AND ALAN W. BROWN

possible semantic understandings of integration. A second is concerned with the mechanisms whereby components share data or control. The third concerns the importance of process, its constraints, and the context that it provides for integration. Having examined these aspects individually in detail, we now examine how they interact. This interaction is seen in two domains, namely, that of the locality of interfaces and that of standardization. We consider that in these two domains can be found necessary conditionsthat must exist if composition of truly integrated environments is to become a reality.

5.1 The Proper Locality of Software Interfaces We can generalize that interfaces are the boundaries of a component; they are the entry points to its functionality and the exit points of its output.” Interfaces thereby provide the fundamental means through which components can connect with each other, i.e., be in some way integrated. Therefore, assuming some set of components needing to be integrated into an environment, the locality of the interfaces that each displays to the outside world-i.e., the functional “places” where a component’s actions can be invoked or its data read-is paramount. We again interpret this problem in the context of our three-level model: for any candidate component, it is necessary that the mechanisms of its interfaces (e.g., invocable functions), their semantics (e.g., the meaning and format of required input data), and the process constraints that govern those interfaces (e.g., whether the component’s functionality accepts some external control at a certain point) determine whether or not the integration of this component with other components is useful or even possible. While this appears to be a reasonable scenario. it is also the case that unless the candidate tools to be integrated are all written with mutual knowledge of each other’s particular interfaces, integration will be difficult or impossible. There must be some preexisting and commonly shared understanding of those boundaries, namely, some reasonable understanding in advance of where a tool can be expected to provide external interfaces, and of what operations are typical at those interfaces for a tool or class of tools. This is certainly not the case today. On the contrary, there exists no generally accepted notion of the appropriate “boundaries” of a tool, of where one tool should “end,” or at least offer an external interface. Products tend to offer a multiplicity of services and to combine functionality that represents, at least conceptually, several “tools.” For instance, a compiler is arguably a tool that provides a single service. But, as we described in the examples in the previous section, many compiler products now also include editors and debuggers as well. Such tailoring of functionality within a single product is clearly beneficial-the components of the product are well integrated and often extremely useful.

COMPOSITION OF INTEGRATED SOFTWARE ENVIRONMENTS

181

But this tailoring is not without cost. First, the word “tool” loses its precision: what we really have are products that provide services spanning a set of tools. (This in itself is not a great loss, since the software community has never been able to agree on a definition of what a “tool” is anyway.) Second, the welldefined interface to each functional component of the product tends to be lost; public access to the various “internal” services is often obscured, and sometimes hidden entirely. From a technical perspective, products of this sort tend to be ad hoc collections of functionality, and the task of integrating them with other products, if possible at all, will be equally ad hoc. Consider the example from the previous section when the process definition evolves and a user wishes to modify the integrated toolset to support the revised process. Whether this is possible will depend on the product used to implement the process scenario: some will permit it, but others disallow it. Earlier, we noted that one possibility to solve the problem can be seen when a tool vendor extends his tool to provide the extra capability needed by the user. While this is useful in the short term, we argue that while this solves the problem at hand, it may actually cause greater problems than it solves. This is because the problem is expressed incorrectly: the evolutionof the user’s process definition implies not the need for greater functionality, but rather the need for access to a different functional interface. When the tool vendor expands his tool to accommodate that greater functionality, the situation is actually made worse, since the expanded tool is usually still a black box, and one more functional interface has been obscured. The solution we argue for is not new; it was considered over a decade ago, as part of the early work on the STARS program:

This approach is somewhat dependent on breaking the large tools that we typically think in terms of today, such as compilers, into tool piece parts. If this is not done, then the wide variability of requirements for specific environments will result in few of the tools being selected and the need to build a large number of new tools. . . . For many traditional tools, the piece parts into which they should be broken are fairly obviousjust from our general experiences. For example, breaking a compiler into a lexical analyzer, a parser, a code generator, and an optimizer is an obvious division that provides piece parts of general utility. This general knowledge that we have from working with traditional tools can be effectively used to break up a large variety of differenttypes of tools into reusable piece parts. (DeMillo etal., 1984) We do not go quite this far: it is not necessary actually to break the tools (products) apart. But it is necessary that their functionality be modular, that this modularity be based on some community-wide agreement on functional boundaries, and that the interfaces to the modular sections be made public. If we return to Figure 5 where some needed tool spanned two process steps in a “blackbox” manner (Lea,of the functions we called 2 and 3). this would

182

DAVID J. CARNEY AND ALAN W. BROWN

imply decoupling the tool’s functionality enough to make the interface between the two modules public, for instance, as a specified invocation with arguments, options, etc. The aggregate product could be sold in much the same way it presently is, but with the specification of the interface now documented. The entire product could work in the same way; but it now permits a tool integrator to make the sort of process-directed changes we noted above, i.e., to gather whatever metrics required at the interface between 2 and 3, or to substitute some other tool that does the work of 3, providing it makes use of the publicly specified interface. The tool integrator now bears the responsibility of creating a new integrating mechanism (the typical quick solution is a shell script; other more complex solutionsare easy to imagine); but the integrator is aware of the semantics that govern the shared data or control, and how has the flexibility to support this evolved process, since the interface has been properly located and made public. In summary, regardless of the size of products and tools, they should be constructed from components that are ideally very small (by today’s “tool” standards). The boundaries of functionality should be well-defined in the same sense that hardware components are well defined. And finally, these boundaries that provide the interface to the component’s functionality must be public interfaces. The question of their standardization is considered in the next section.

5.2 The Search for Standards As noted above, interface standards are seen by many as the principal key to solving the problem of CASE tool integration. And it is certainly the case that interface standards are a necessary condition for this goal. Proof of the benefit of standards can be seen in the widespread use of the various communicationand network protocols that are presently providing near-seamless access to worldwide networks; it is also offered by such humble format standards as the American Standard Code for Information Interchange (ASCII). But there are severe shortcomings in the attempts to create standards for software engineering (in fact, standards for any engineering discipline). One cause of this is the notion that these standards can be created in advance of a user community. This stems from a belief that the pedigree of a standard is the first item of significance: in this view, standards are formalized specifications produced by formal standards-making organizations such as IEEE or ANSI. Taking this view, pedigree rather than ubiquity is of greatest significance. Because of this belief, considerable time, expense, and effort has been spent in producing ANSI or IEEE standards for a variety of needs: language, repository interface, and data format. Examples of this include Ada, the Common Ada Programming Support Environment Interface Set (CAN), CAIS-A, PCTE 1.5, ECMA-PCTE, ANSI-Information Resource Dictionary System (IRDS), International StandardizationOrganization(IS0)-IRDS, and the CASE Data Interchange

COMPOSITION OF INTEGRATED SOFTWARE ENVIRONMENTS

183

Format (CDIF). Each of these standards shares certain traits. It was developed in advance of a using community.It followed the sequenceof “develop standardimplement standard-find a user for the standard.” And none of these standards is in widespread commercial use, even after a decade of existence in some cases. The failure here is not standardizationper se, but standardizationat the wrong time. The better solution, and the real need in the community, is to have broad, public agreements. The formal pedigree of these agreements, while not unimportant, should be the lust item of concern, not the first. As an example of this, consider the current standardizationefforts carried out by the Posix.1 and Posix.2 working groups. These efforts have no less a pedigree than the others already mentioned. But they have been carried out in the context of a very large community that has been using Unix for many years. For that reason, examples of broad and public agreements about Unix are ubiquitous, and areJinally-not initiallybeing formalized by the Posix working groups. The key point is that they have been broad and public agreements, tried by use for many years. It is very unlikely that the Posix.1 and Posix.2 standards, which have a clear connectionto “historical” Unix, will suffer the same fate as CAIS or IRDS. Discussion concerning the relative merits of early standardization versus late standardizationcan be long and vehement. However, it is interesting to note that recent years have seen a much greater interest in the environmentsarea in industryled consortia defining common interface definitionsthat the consortium members will agree to use [e.g., Common Open Systems Environment (COSE), CORBA, CASE Communique]. These are typically based on market-driven needs to provide greater interoperability and consistency between existing vendor products. The consortium may submit the agreed interface definitions to a formal standards body once its work is complete, but this is something of an afterthought, not its primary means of operation.

5.3 The Interaction of Interfaces and Standards The locality of interfaces and the issue of standardization are distinct but interrelated,and we considerthat their interactionis central to achievingintegrated environments. This interaction can be expressed as a requirement: the task of integratingheterogenouscomponentsrequires not the software interface standards available today, but rather standardized sofrware interjiaes at appropriately low levels offunctional modularity. This statement means that the tool interfaces need to be exposed at a lower level of granularity than is common today. It means that the community of tool users and integrators must insist that process constraints determine the locality of those interfaces, rather than letting the tool vendors’ decisionsdeterminethe end-users’ processes. There is the need for these interfaces to become common and ubiquitous. And finally, there is eventually the

184

DAVID J. CARNEY AND ALAN W. BROWN

need for the conventions and protocols that arise surrounding these interfaces to become formalized by recognized standards bodies. In this view, the focus should not be on the pedigree of the standardization process (though a good pedigree is obviously desirable), but rather on the ubiquity and currency of the thing to be standardized. The focus should not be on obscuring the interfaces through bigger and bigger “blackbox” products, but rather on exposing lower-level interfaces and partitioning functional behavior of products accordingly. In a sense, this is nothing more than the software equivalent to the general agreement that even in large machines, individual screws are replaceable; or that the screws will not contain a hidden electrical fuse necessary for the machine’s operation. Yet agreements such as these represent the most difficult (and most necessary) step if CASE tool integration is to become a reality. In this view, it will then not matter whether products offer single services (in the old sense of a “tool”) or provide the user with entire suites of services crossing whole functional domains. The key point is that these services are appropriately modularized, and are accessible through externally visible interfaces. Tool vendors will then succeed or fail on the qualities that their products exhibit (efficiency, dependability) and on such marketing factors as customer service and cost. In the domain of software engineering environments, we can see that much work must be done if integrated environments are to attain a comparable degree of success. The need is for end-users, vendors, and integrators of environment products jointly to begin the work of: 0

0 0

Working cooperatively to understand more about environment architectures, the appropriatepartitioning of functionalityin an environment,the important interfaces that exist between those partitions. Developing agreements on the appropriate interfaces that have the effect of increasing interoperability of vendor products. Producing tools that provide greater access to their internal structure and behavior to increase the integration possibilities of those tools.

To achieve this there must be action on behalf of each of the communities involved. End-users of environments must start demanding integrability as a first-degree requirement of a commercial tool. This must be based on a deeper understanding and expression of integration characteristics, and founded on an experience base of data that can be used to illustrate the value of different integration approaches. Vendors have to respond by opening up their internal interfaces to provide the integrability that is demanded. Standards bodies must focus on consensus building by standardizing the best of current practice, particularly at the lower levels of the tools.

COMPOSITION OF INTEGRATED SOFTWARE ENVIRONMENTS

185

6. Toward Engineered Environments Much of the work carried out by the environments community is focused on how an environment can be designed and assembled with its integration characteristics in mind. In particular, the aim has been to develop an approach that considers integration as a key factor that influences many of the design decisions that take place while assembling an environment. If this view is adopted, then the most important factors in constructingthe environmentare considerations of how integration is embodied within the environment, decisions concerning what tradeoffs need to be made in its assembly, recording the reasons for the design decisions that are made, and measuring the results of the design activities when compared to the stated needs for the environment. The basis of this view is a separation of the mechanistic issues (how the interrelationships among components are implemented), the semanticissues (what services are provided, and how those services are related) and a description of the context-a description of the software development processes being supported-in which the environment will operate. With this view of integration as a design activity in mind, and having the conceptual framework provided by the three-level model, it is possible to sketch the outline of a method for engineering an environment. The first step in this approach is to analyze and record the processes that are to be supported and the constraints on the organization in carrying out these processes. For example, an organization may have a suitable approach to designing, coding, and testing individual softwaremodules that has been institutionalized throughout the organization. This approach must be documented to produce a process model of the description of the practices as they currently take place. Connections between this process and related practices (e.g., the methods for system building and system integration testing) must then be defined. Given this context in which to work, the next step involves the description of required environment services that will be used in support of these processes. At an abstract level, the environment services can be discussed and the interrelationships defined. For example, design, coding, and software module testing services may be required from the environment. Based on the processes being enacted by an organization, the ways in which these services must interact to support those processes can be defined. The next step is to choose environment componentsthat can realize the services required and that provide the interfaces that the process description demands. CASE tools would thus be acquired not simply based on their functional description, but also with a detailed knowledge of the processes that need to be supported and the necessary connections that are required with other CASE tools. For example, instead of the imprecise statement, “I need a testing tool,” an organiza-

186

DAVID J. CARNEY AND ALAN W. BROWN

tion is now able to express its needs in more detail: “I need a testing tool that will support these activities, and that will allow these services it provides to interface with these other services from my design and coding tools.” Integration technology such as databases and message passing systems may be required to facilitate the construction of the environment. Again, these can be selected and evaluated with a much clearer understanding of the requirements that they must satisfy. While these steps are described in sequential fashion and in a simple manner, in actual practice there will be significant feedback and iteration between the steps. For example, no matter how much technology is at hand, it may still be necessary to change the processes in order to accommodate the restrictions of the available tools. However, the important point to note is that such changes can now take place within a context that has documented why such changes are necessary, provides a basis on which such decisions can be rationalized, and maintains a history of why the environment architecture has evolved to be how it is. In most current environments,the conceptual framework necessary to facilitate these actions does not exist. We have made use of this approach to the engineering of an environment in a number of detailed case studies. Our results show that this design approach to integration does allow the integration characteristics of an environment to be better understood, and the resultant environment to be more predictable in its support for those characteristics (Brown et al., 1994). More in-depth studies are planned, and the results of these studies will be published as they become available.

7. Summary and Conclusions Understanding integration in an environment is important for all those concerned with the development and maintenance of large-scale software applications. The way in which the environment used to develop and support those applications is engineered can have a significant effect on the applications throughout their lifetime. Previous attempts at developing conceptual models for understanding integration aspects of an environment concentrated on static approaches to analyzing the properties and relationships of existing systems. While much can be learned from these models, what is needed is not only the ability to analyze certain integration characteristics of an existing environment, but also the ability to construct an environment to suit a variety of integration needs and to be able to evolve that environment in a controlled way as those needs change. The three-level model described in this chapter separates three different integration concernsservices, mechanisms, and process-and allows each of these to be examined

COMPOSITION OF INTEGRATED SORWARE ENVIRONMENTS

187

in isolation.It also allowsrelationshipsamong these threeconcernstobe discussed and analyzed. The main concern of this chapterhas been the way in which current environment components partition the functionality of an environment, the interfaces that those components make available to others, and the implications of this for the engineering of an environment. A primary theme of the chapter is that standardizationof appropriate interfaces can have a major influence on the engineering of open, integrated environments in the future. There are many indications that many of the ideas discussed in this paper will be adopted in the future. Three in particular are worthy of note. First, the major computer and tool manufacturers are working in a number of consortia to define standards for tool interoperability that build on the strengths of their existing products and overcome many of the weaknesses. The work of the Object Management Group (OMG) (1992) and the Open SoftwareFoundation (OSF) is perhaps foremost in this effort. Second,environment builders seem to be recognizingthat the needs of environment users must be the major driving force in the work that they carry out. For example, the European Aerospace Systems Engineering Environment (EASEE) initiative is an attempt to collect together environmentusers in a particular domain to elicit their requirements, and to understand more clearly what needs they have for supporting the applications they develop. Third, interest in gaining a greater understanding and appreciation for software architectures has spawned a number of initiatives. Programs focused on understanding more about domain-specific software architectures, and the development of languages and notations for defining software architectures are two examples of the work in this area. A heightened awareness and understanding of software architecture issues in general can have very important positive effects for the engineering of software engineering environments in particular. ACKNOWLEWMENTS We would like to thank the following people for their comments on previous drafts of this chapter. Tricia Obemdorf, Kurt Wallnau. and Marv Zelkowitz. The Software Engineering Institute is sponsored by the U.S. Department of Defense. ENDNO~ZS

’

Some recent approaches to government-sponsored environments include both the SoftwareTechnology for Adaptable, Reliable Systems (STARS) Program (1992) and the Integrated-CASE (I-CASE) program (Bragg, 1994). Since these programs are still currently in progress, it is premahrre to assess their degree of success. * The STARS Program is notable in this respect. Although it began as a program whose goal was to develop a group of environments,STARS is now largely focused on the centrality of process and

188

DAVID J. CARNEY AND ALAN W. BROWN

reuse; the environmental component of STARS is now captured by the notion of “technology suppo~Vfor reuse and process mechanisms (STARS Program Office, 1992). A full definition of the term “service,” as well as many other terms relevant to environments, is found in SEI and NIST (1993). Note that this figure illustrates examples of the elements at each level, and is not intended to be exhaustive. The question of the term “tool” and its lack of precision will be revisited below in Section 5 . We note that in actual practice, existing integration technology and implementation architectures do not match this idealized model of integration. CASE tools typically embed process constraints that limit the ways that they can be used, rather than permitting the tools to be combined in multiple ways supporting many processes. and the services supported by a CASE tool are often locked into that tool’s particular implementation techniques. This approach was previously been developed by Brown and McDermid (1992).They distinguished five levels at which tool integration takes place within an environment. This approach was subsequently refined in the work of the U.S. Navy’s Next Generation Computer Resources program (Naval Air Warfare Center, 1993). We reinterpret these levels and use them as the basis for a categorization of data-sharing agreements. Where IDEFO is itself a modified form of Structured Analysis and Design Technique (SADT) (Marca, 1988). Note that this IDEFO example is intentionally simplified. It omits such items as compilation errors that provide a data feedback from the compilation step to the editor, etc. lo Thus, following the same type of standalone scenario that used to be typical when a progknmer used the Unix *‘spell” facility, as opposed to the current use of automated spell checkers in tools like FrameMaker or InterLeaf. The IEEE Standard 610.12-1190,IEEE Standard Glossary of Sofhvare Engineering Technology definition is: “A shared boundary across which information is passed; (2) A hardware or software component that C O M ~ Ctwo ~ ~ or more other components for the purpose of passing information from one to the other; (3)To connect two or more components for the purpose of passing information from one to the other: To serve as a connecting component as in (2):’

’ ’

’

’

REFERENCES

Application Portability Profile (APP) (1993). “The US. Government’s Open System Environment Profile O W 1 Version 2.0,May 1993,” NIST Spec.Publ. 500-xxx. NIST, Washington, DC. Bourguignon, J. P.(1989). The EAST Eureka Project: European software advanced technology. In “Software EngineeringEnvironments:Research and Practice, Durham, U.K., April 11-14,1989,” pp. 5-16. Ellis Horwood, Chichester, UK. Bragg. T. W. (1994). A casefor defense: The defense department’s 10-year integrated CASEproject. Am. Programmer 7(7), 16-23. Brown, A. W.. ed. (1991).“Integrated Project Support Environments:The Aspect Roject.”Academic Press, London. Brown, A. W., and McDermid, J. A. (1992). Learning from IPSE’s mistakes. IEEE Software 9(2), 23-28. Brown. A. W., and Carney, D. J. (1993). Towards a disciplined approach to the construction and analysis of software engineering environments. In “Proceedings of SEE ’93.” IEEE Computer Society Press, Los Alamitos, CA. Brown, A. W., Moms,E. J., Zarrella, P. F., Long, F. W., and Caldwell, W. M. (1993). Experiences with a federated environment testbed. In “Proceedings of rhe 4th European Software Engineering Conference, Garmisch-Partenkirchen,Germany. 1993.”

COMPOSITION OF INTEGRATED SOFTWARE ENVIRONMENTS

189

Brown, A. W., Carney, D. J., Moms, E. J., Smith, D. B., and Zarrella, P. F. (1994). “Principles of CASE Tool Integration.” Oxford University Press, New York. Cagan, M. R. (1990). The H p softbench environment: An architecture for a new generation of software tools. Hewlett-Packard J. 41(3). Dart, S. (1990). “Spectrum of Functionality in Configuration Management Systems,” Tech. Rep., CMU/SEI-WTR- 1 1. Software Engineering Institute, Camegie-Mellon University, Pittsburgh, PA. DeMillo R. A. et al. (1984). “Software Engineering Environments for Mission Critical Applications-STARS Alternative Programmatic Approaches.” IDA Pap. P-1789. Institute for Defense Analyses, Alexandria, VA. ECMA & NIST (1993). “A Reference Model for Frameworksof SoftwareEngineeringEnvironments (Version 3).” ECMA Rep. N. W 5 5 Version 3, NIST Rep. N. SP 500-211. NIST, Washington,DC. Feiler, P. (1991). “Configuration Management Models in Commercial Environments,” Tech. Rep., CMU/SEI-91-TR-7. Software Engineering Institute, Carnegie-Mellon University, Pittsburgh, PA. International Standards Organization (199 1). “Information Technology-Software Product Evaluation-Quality Characteristics and Guidelines for their Use,” ISO-9126. ISO, Washington, DC. Jolley, T. M., and Gockel, L. J. (1988). Two year report on BASE method and tool deployment. In (S. hbylinski and P. J. Fowler, 4s.). “Transferring Software Engineering Tool Technology.” IEEE Computer Society Press, New York. Long, F. W., and Moms, E. J. (1993). “An Overview of PCTE: A Basis for a Portable Common Tool Environment,” Tech. Rep. CMUEEI-93-TR-1, ADA265202.Software Engineering Institute, Carnegie-Mellon University, Pittsburgh, PA. Marca, D. (1988). SADT Structured Analysis and Design Technique. McGraw-Hill, New York. Moms, E., Smith, D., Martin, D., and Feiler, P. (1992). “Lessons Learned from Previous Environment Efforts,” Spec. Rep. Software Engineering Institute, Camegie-Mellon University, Pittsburgh, PA. National Bureau of Standards(1988). “A TechnicalOverview of the InformationResource Dictionary System, 2nd ed., NBSIR 85-3164. NBS, Gaithersburg, MD. Naval Air Warfare Center (1993). “A Report on the Progress of NGCR PSESWG. Draft Version 1.0,’’ U.S. Navy NGCR Program. Naval Air Warfare Center, Aircraft Division, Warminster, PA. Object Management Group (1992). “The Common Object Request Broker: Architecture and Specification.” OMG, Framingham, MA. SEI & NIST (1993). “A Reference Model for Project Support Environment Standards. Version 2.0,” Tech. Rep. CMU/SEI-TR-93-23, NIST Rep. N. SP 500-213. NIST. Washington, DC. STARS Program Office (1992). “Proceedings of STARS’92: “On the Road to Megaprogramming.” STARS Program Office, Washington, DC. Strelich, T. (1988). The Software Life-Cycle Support Environment (SLCSE): A computer-based framework for developing software systems. In “Proceedings of ACM SIGSOFT/SIGPLAN Sofirware Engineering Symposium on Practical Sofhvare Engineering Environments, Boston. ” Thomas,I., and Nejmeh. B. (1992). Definitionsof tool integration for environments.IEEE Sofnvare 9(3), 29-35. Wasserman, A. (1990). Tool integration in software engineering environments. In “ S o h a r e Engineering Environments” (F. Long, ed.), Lect. Notes Comput. Sci., No. 467, pp 138-150. SpnngerVerlag, Berlin. Wakeman, L., and Jowett, J. (1993). “PCTE:The Standard for Open Repositories.” Prentice-Hall, Heme1 Hempsted, UK.