Experiments in Environment Integration

In assembling a CASE environment from a collection of commercial off-theshelf (COTS) tools, tool users must find ways to connect the tools such that they provide adequate support for their particular software development approach. This task takes place in the context of limited knowledge of the tools, limited access to the source or internal structures of the tools, limited resources with which to perform and maintain the tool connections, and evolving understanding of the needs of the tool users. This places severe restrictions on what can be attempted in terms of tool interconnection. Environment framework technologies (e.g., ECMA PCTE, ATIS, BMS, ToolTalk, or CORBA) claim to provide a set of common integration services that aid in the tool integration process. There have been numerous discussions about the value, maturity, and complexity of these framework technologies. Such discussions are characterized by three points: general agreement that framework technology per se is a valuable goal to pursue; moderate disagreement as to whether the current level of framework technology is a sufficient basis for production quality CASE environments; and considerable disagreement about which of the current technologies are the most likely to mature and succeed. Notable about these discussions, however, is that there has not been extensive use of the technologies in question. This stems from several sources: their expense, their unfamiliarity and complexity to current tool users, and a widespread concern about their immaturity. This lack of use is perhaps understandable, but it has had the additional effect that partisans of one or another technology have made assertions based on little factual information about the relative merits of the technology in question. To expand our own expertise in tool integration and framework technologies, and to answer the question, “What tool integrations are possible for third-party tool users given the current state of COTS tools and integration technology?” we performed a set of experiments involving the integration of a collection of common COTS tools with environment framework technologies in support of a typical development scenario. Our selection of these tools and technologies was based on common availability and application to the development scenario(s) of interest.

Control Integration Mechanisms

Controlling and coordinating tool interactions in a CASE environment require an approach to tool integration that is sufficiently flexible and adaptable to suit different user needs, as well as simple and efficient. These conditions will ensure that new tools can easily be integrated and that their productivity is not significantly impaired. As discussed in the previous chapter, one traditional approach toward tool integration has been based on data sharing, often through a common database in which all tools deposit their data. While this approach can provide a high level of control and coordination between tools, it also imposes a significant overhead on the tools, both because of poor performance of existing database mechanisms when used in this way, and because of the necessary agreement required between the tools to define a common syntax and semantics for their data (e.g., a common data schema). Another approach to integration has been called the control integration approach. This approach is based on viewing a CASE environment as a collection of services provided by different tools. Actions carried out by a tool are announced to other tools via control signals. The tools receiving such signals can decide if the other tool’s actions require that they take any actions themselves. For example, when an editing tool announces that changes have been made to a source file, a build tool may receive this information and initiate a new system build. In addition, one tool may directly request that another tool perform an action by sending it a control signal. For example, the build tool may request that the source file be compiled by a particular compiler. Hence, the primary means of coordination between tools is through the sending and receiving of control signals. In the rest of this chapter, we examine the notion of control integration in a CASE environment, review a number of existing systems, and analyze those systems to identify their differences and to reveal interesting future directions for this work. The reviewed systems do not represent an exhaustive examination of systems implementing a control integration approach.

Properties and Types of Integration Mechanisms

A central theme of this book is the three-level approach to CASE environment design and construction that distinguishes conceptual issues (the services) from implementation issues (the mechanisms) and stresses the need for a design context (the process) that the CASE environment must support. Previous chapters have discussed this theme, as well as provided insight into a conceptual model that identifies and classifies the services that might be found in a CASE environment. However, regardless of the service model or conceptual approach selected, environment builders must eventually face the bottom-line decision of how to actually carry out tool integration. The choices they face in terms of potential mechanisms are numerous and include a full range of selections that provide varying degrees of effort and integrated capability. In this chapter, we first consider the properties of integration by continuing the discussion of integration as a relationship (see Section 2.2). In this discussion (Section 5.2), we highlight properties that are addressed by various integration mechanisms. Later sections of this chapter focus on the specific relationship between two particular classes of integrating mechanisms: those based on the sharing or transfer of data between tools (data integration), and those based on synchronization and communication between tools (control integration). In Section 2.2 we introduced the concept put forward by Thomas and Nejmeh that integration can be considered by defining the properties required of the relationships between different environment components. Their definition of integration is exclusively a conceptual view, and is independent of the particular technology being used to implement that integration.

Previous Approaches to Understanding CASE Tool Integration

CASE tools typically support individual users in the automation of some task within a software development process. Used thus, CASE tools have undoubtedly helped many organizations in their efforts to develop better quality software to budget and within predicted time scales. Further, if tool technology matures according to the current expectations of many industry analysts, then CASE tools offer the potential to revolutionize the way in which much of our software is currently developed. However, the success of integrated sets of CASE tools — i.e., CASE environment — is a more complex issue. The potential for success is great, but is dependent on many factors. Perhaps the most urgent need is for an improved indepth understanding of the meaning and role of integration in a CASE environment. This is important because it will form the foundation for many of the tasks that will follow. For example, without a common understanding of inte gration, we will continue to struggle to have the necessary shared concepts and terminology to allow integration products to be described and compared, standard interfaces to CASE environment components to be agreed upon, and objective measures of the effectiveness of integration approaches to be produced. The focus of this chapter is a review of previous approaches toward defining a common understanding of integration in a CASE environment. We begin by examining the conceptual models of integration that have been developed and that help to understand the main concepts being addressed in an integrated CASE environment. We then look at the main architectural approaches that have been used in constructing a CASE environment, concentrating on the integration that is supported by those architectures. The problem of integrating software components to produce a CASE environment is the central focus of this book. It is a problem that has resisted easy solution and offers a highly difficult challenge to the software community. In attempting to resolve some of the complex issues in CASE tool integration, researchers have sought a conceptual framework through which these issues can be more easily understood and communicated between different people.

Integration of CASE Tools with CM Systems: Lessons Learned

The problem of CASE tool integration has several concerns that overlap with those of configuration management (CM), so much so that a discussion of one topic is often difficult to separate from a discussion of the other. To illustrate, we note that when choosing a solution to a problem in configuration management, we often must make choices that involve understanding process requirements, examining the services available (and their semantics), and analyzing implementation constraints. We also note that these activities are done simultaneously with making design trade-off decisions related to the integration of these process, service, and mechanism concepts. These factors are applicable to CM, but are not particular to CM: most of these same issues underlie any set of decisions one makes about combining a set of CASE tools into an integrated environment. However, CM and its relationship to CASE tool integration in general poses a unique set of problems. This is most apparent when we realize that CM is sometimes considered as a service (or set of services) provided by the environment or its framework, sometimes as a service provided by a separate stand-alone tool, and sometimes as an integral aspect of each individual CASE tool. These competing views lead to overlaps in functionality and responsibility between individual tools and the environment’s (or framework’s) CM capabilities. For instance: • A fundamental issue for CM is data redundancy. This results when different tools store the same data in separate repositories. Correspondingly, different data models may make data sharing (a fundamental issue for tool integration) difficult. • Version management (VM) and CM services provided by individual tools are frequently linked with private tool data model and data management services. These VM and CM services are not always delegable — sometimes these services are an intricate part of tool function (e.g., for multi-user support and build). • The VM and CM services provided by individual tools may imply or enforce vendor-specific VM/CM policies, as opposed to the CM policies of the environment.

The Role of Process In Integrated CASE Environments

Early work on CASE environment integration concentrated on the mechanistic aspects of integration between tools. The process context in which those integrated tools would be used was less of a concern. In recent years, however, the process aspect of integration has grown in importance in the eyes of most members of the software community. The role of process, and hence of process integration, is now generally regarded as critical. Such issues as determining the impact of process on the choice of tools to be integrated, how those integrations should be implemented, and how a CASE environment will be used in the overall life of an enterprise are now increasingly seen as being of paramount importance. As an example, while one could assert that a particular analysis tool should be integrated with a documentation tool, this is of little real value. A more meaningful assertion is that the analysis tool must make use of documentation services to generate documentation in some standard life-cycle model form (e.g., DoD-STD-2167 document sets). The three-level model of integration proposed in this book reflects this interest in process. In our three-level model, process integration is orthogonal to mechanism- level integration and service-level integration. In this view, we see that integration is not just an amalgamation of related tools, but is the combination of several integrating mechanisms, used over some set of services (as implemented by tools) to achieve some specific process objective. Put another way, we view software processes as defining a design context, i.e., a set of integration requirements. When implemented, they can be expressed as a coordinated set of environment services, i.e., unified through a combination of control, data, and presentation mechanisms. In this chapter, we explore the broad subject of process integration in more detail. We first consider several divergent views on the nature of process integration itself, and particularly the question of process in the context of “process improvement.” We then examine the relationships between process integration and CASE tools and environments. We next look at some idealized examples of how processes and tools interact, and some issues raised by these examples.

Data Integration Mechanisms

Data integration is a basic need for a CASE environment because individual tools operate on data that are of interest to other tools. For example, many CASE analysis and design tools produce code templates representing the interfaces between system components. These templates are of interest to tools that assist in code generation since they specify an interface between system components that ideally is maintained during the implementation process. Likewise, changes made to these interface descriptions during the implementation process often have an impact on the design of the system as reflected in the analysis and design tool. Many approaches have been developed to facilitate the sharing of data between components of a CASE environment. These approaches differ both in the mechanisms used to provide this support and in the degree of support provided. In this chapter we consider some concepts central to the problem of data integration, discuss the major strategies adopted to provide data integration, and analyze the strengths and weaknesses of these strategies. Finally, we discuss particular mechanisms that reflect these strategies. If environment components are to share data, then two issues must be addressed. First, agreements must be made between components concerning what data are stored, where, and how they are accessed. Second, the components must share a common understanding of the meaning of the data. We refer to the first issue as data persistence, and the second issue as data semantics. These two issues provide the backdrop for our discussion of the principal types of mechanisms for data integration. One type of mechanism focuses on different storage strategies, and the second type of mechanism focuses on semantic agreements. Although we consider each separately, no mechanism exclusively addresses only data persistence or data semantics. In practice, all mechanisms address both data persistence and data semantics to varying degrees. There are two basic strategies that support storage and sharing of persistent data. The first involves data import and export, whereby tools maintain separate databases for their unique data, and sharing is accomplished by some translation from an internal form to an external form to make it available to other tools.

A Service-Based Model of a CASE Environment

We have already described our three-level model of CASE tool integration in which services, mechanisms, and process all participate. In this chapter, we focus on the services aspect, and examine what we actually mean by “service.” We also consider the variety of services typically found in an environment, and the interrelationships between services and other aspects of an environment (i.e., interfaces between services). The vehicle for this examination is an abstract description called a “reference model.” We use the term reference model to characterize a model of a system taken from a purely conceptual standpoint. Such a conceptual model permits consideration of alternative implementations of a service, adding new implementations, and so on. We note the potential for confusion here, since the term reference model is often implicitly concerned with the notion of architecture; in many cases a reference model is understood to refer to a reference architecture. We do not use the term in this way. Our understanding of the term is closer to the concept of a “feature catalog”; it is explicitly not intended to identify an architecture, but rather is intended to provide a common reference point from which the functional capabilities of actual implementations can be described. This view is consistent with our separation of services (described in the reference model) both from the mechanisms that provide those services and also from the processes that they support. The reference model we use as our exemplar is the one developed by the U.S. Navy Next Generation Computer Resources (NGCR) Program. As part of the work of the NGCR, the Project Support Environments Standards Working Group (PSESWG) defined an environment reference model as its starting point for selecting interface standards. The working group examined many existing efforts (e.g., the Software Technology for Adaptable, Reliable Systems (STARS) Program, the National Institute of Standards and Technology (NIST) Integrated Software Engineering Environment (ISEE) working group), synthesized many aspects from them, and eventually created an entirely new document called A Reference Model for Project Support Environments [63].

Toward a Better Understanding of Integration

The need to provide better automated support for software engineering activities has led people to concentrate attention on the problems of integrating the many different components that can be found in a typical CASE environment. In the previous chapter we reviewed some of the work that has taken place to try to provide a greater shared understanding of the meaning of integration, and to build integrated CASE environments. We have synthesized some of the best aspects of this previous work to develop a model that helps to provide a more comprehensive view of integration, and can be readily applied to different environment needs. The model attempts to provide a set of concepts for understanding a range of integration issues, a vocabulary that can be used to clearly separate different integration aspects, and an organizing framework that helps to relate many of the important issues in CASE tool integration. An attraction of our model of integration is that it also can be used as the basis of a CASE environment architecture in which the integration characteristics of the environment are defined, understood, and amenable to change. In this chapter we describe this model in detail, discuss how it can help in considering the design and construction of a CASE environment, and analyze the kinds of CASE environments that will result from realizing implementations of this model. The previous chapter highlighted a number of shortcomings with previous conceptual models of integration in a CASE environment. The discussion pointed to the need for a better understanding of the issues involved in designing, constructing, and using an integrated software development environment, regardless of the available technology. Here we propose a new conceptual model for understanding integration in a CASE environment that we believe can be used to improve our understanding in this area. In this model we distinguish three levels at which we are concerned with the integration of a CASE environment. The central one consists of the services available to environment end-users. The second level consists of the mechanisms that implement the end-user services.

Summary and Conclusions

This book has taken the reader on a long journey through terrain that is at times difficult to negotiate. There are aspects of the integration problem that are open to interpretation, a source of heated debate, or perhaps undergoing great change in terms of people’s perceptions of the problems and solutions. We hope that the reader now has a better understanding of the range of issues that must be addressed and the viewpoints that are possible when the phrase “integrated CASE environment” is used. In this final chapter, we look back at the major points discussed earlier, and look ahead toward the future. Section 13.2 reviews the major themes that have been presented in this book. Section 13.3 highlights a number of avenues of work that provide hope for the future in this field. Section 13.4 concludes with a few final thoughts and observations. The three overall themes that have been used to provide a structure to the book are the following: • Understanding of CASE environment integration is enhanced by considering three levels at which integration occurs — end-user services, mechanism, and process levels. • CASE environment architectures are evolving toward a hybrid approach that combines elements of framework-centered and CASE tool-centered approaches. • The construction of an integrated CASE environment can usefully be viewed as a design activity in which design decisions are made based on a number of trade-offs that must be made. For the purposes of recapitulation, these themes are brought together and summarized briefly below. One of this book’s main conceptual tools for improving understanding of the many issues connected with CASE environment integration is a three-level model that distinguishes end-user services, mechanism, and process aspects of a CASE environment. By way of a summary of this model and its utility, we consider two tools that are integrated within a CASE environment. At the conceptual level, integration of the two CASE tools implies that the overlap, or coordination, between the functionality offered by those tools is well understood. For example, if one tool is a requirements capture tool and the other is a design and analysis tool, then the relationships between the functionality offered by those tools can be analyzed and discussed.