Technology advances lead us to conclude that future applications in almost all domains will be distributed across many sites, access data from multiple sources, and have web-based interfaces [1, 11]. Developing and maintaining these applications involves a wide range of skills in distributed systems, databases, and web technology. This is in addition to the software engineering skills required by any application developer of large-scale software-intensive systems.

As a result, automated tools for building such applications are essential, and are becoming commercially available. We can identify three major sources of those tools:

• A plethora of small start-up companies have sprung up, producing a wide variety of tools that aid application developers in many aspects of web-based software development. However, these tools tend to suffer from typical first-generation software problems: instability, poor support, and concentration on single-user, small application development.
• The vendors of infrastructure technology (databases, messaging systems, browsers) have produced their own tools that help developers to apply their products. The main limitation of these tools is that they tend to be very closely tied to a particular infrastructure product, and may not allow use of a competitor's product, or a combination of products.
• The established CASE vendors are evolving their existing product bases to address the problems of falling sales in their established markets, and to embrace the opportunities opened up by the new distributed, web-based applications market. The problem with these tools is that they are so slow to reach the market place. The CASE vendors are performing an interesting balancing act between on the one hand evolving their products sufficiently quickly to address the market needs, while on the other maintaining their existing product base and customers.

While a detailed analysis of each of these three tool-producing communities would be valuable, in this paper we concentrate on the third category above, and consider the challenges facing the established CASE vendors as they attempt to address the distributed, web-based applications market. At first sight this community is perhaps in the best starting position of the three categories of tool producers, with an established customer base and marketing channels, experience in tool development, and a large body of development, maintenance, and research staff. However, on closer analysis the challenges to this community are particularly severe. Established CASE vendors must not only completely revolutionize their tools to support the creation and maintenance of distributed, web-based applications, they must also reengineer their own toolsets to be similarly architected. They must achieve this with an existing code base of many millions of lines of code, running on a variety of platforms that range from MVS to many flavors of Unix, and with an established methods and consultancy business based on 1980's-style structured methods producing traditional mainframe and client-server applications.

The remainder of this paper is organized as follows. Section 2 discusses the principle drivers for change and provides motivation for the key issues to be addressed by the established CASE vendors. Section 3 considers the past, present, and future evolution of CASE by describing the kinds of applications being developed and the CASE tool support available. Section 4 discusses 4 key areas that must be addressed in future CASE tools: creating and managing large-scale distributed systems architectures, component-based development, developing new methods and methodologies, and pragmatic issues for established CASE vendors. Section 5 contains a short summary of the paper.

It is difficult not to be overwhelmed by the speed at which new technologies are being announced - hardware price/performance ratio is increasing fast, web-based technologies are appearing at an astounding rate, and various distributed infrastructure standards and technologies for connecting independently-developed applications are now sufficiently mature that they are being used in large-scale mission-critical applications.

Fuelled by these technology advances, it is useful to consider the two critical change drivers for future applications, as these technologies are the basis for many of the new requirements being placed on future CASE tools.

The popularity of the world wide web has revolutionized computing. While there are many aspects to the impact the web is having in society as a whole, in terms of the requirements on application development and CASE tools it is useful to focus on four main areas.

First, the metaphor of "surfing the web" has become universally accepted as the way in which a user searches for relevant information, displays that information within a web browser, and interacts with applications though web-based forms. In a few short years it seems that web browsers are the de facto standard for user interface look and feel.

Second, the location of information and the underlying infrastructure that delivers the information to a user is becoming less visible, and consequently less important to the user. In most cases, the user can be unaware of whether the information is stored on a machine in the next office or on another continent (ignoring network latency of course!). In fact, users now accept that information will be distributed across many machines at many locations, but expect that such distribution does not change the nature of their task.

Third, it is no longer acceptable that information content consist solely of text and tables of numbers. Users expect rich multi-media display of information involving graphics, sound, video, animation, and so on. Web browsers handle many formats of data automatically, and know automatically how to compress and decompress such information for efficient transmission across a network.

Fourth, as the technology of the web is becoming more deeply understood by a wider constituency, a commodity market has developed in all kinds of tools and components for creating and manipulating web content. Users expect to be able to obtain a wide variety of resources for free or at very low cost, and to be able to combine those resources effectively to create sophisticated data content, or data manipulation applications.

As a result, these four areas have had a significant impact on the attitudes and expectations of users developing and using applications in terms of how they view information, where that information resides, the format of that information, and what it is expected to cost to build and evolve applications using that information.

Enterprise-level application development in the late 1980's was characterized by a move away from monolithic, single-machine applications toward client-server computing. In most cases this meant using the graphical capabilities of a users' desktop personal computer (PC) to provide remote access to an application across a local area network. Typically, the desktop client programs provided local display processing and command interpretation, while the central server program performed the compute-intensive activities, maintained shared databases, and so on. This has sometimes been called the "thin client, fat server" model of computing [13].

However, over a short period of time the rapid improvement in performance and reduced cost of PCs began to change the kinds of processing that was performed on the client versus the server. The client PCs could now be used for operations such as query optimization, and could be customized to perform user-specific data visualization and analysis. This migration of functionality from server to client, together with increasingly more reliable, high bandwidth networks, led to software architectures that provided a great deal of flexibility over what functionality was performed on which machine.

The result of this evolution is a change in the way such applications are perceived, designed, implemented, and updated. An application is now considered to be an interacting set of services in which each service is as self-contained as possible, accessed through a well-defined interface. Such a modular approach has many advantages, but relies on a number of elements to be in place:

• design approaches, methods, and tools that support service-based software architectures;
• a shared infrastructure that facilitates specification of service interfaces, allows potential service providers to be identified, and brokers interconnections among service providers;
• a marketplace of services from third party suppliers in the form of components that can readily be connected through the shared infrastructure.

The key to these elements is a set of common agreements concerning service interface specifications, and the availability of a range of products that support service interconnection using those interfaces. Two dominant approaches to providing this have arisen.

The first approach is to make the infrastructure a specific product or platform. This is seen in the Microsoft products. Over the past few years a wide range of encapsulated executables have been made available in the form of Visual Basic Controls (VBXs) and ActiveX Controls (renamed from what was previously called Object Linking and Embedding (OLE) Custom Controls (OCXs)). A large market place has been created for VBXs and ActiveX Controls, with over a thousand VBXs available that sell for anywhere from $25 to $3000. Essentially, a VBX is a packaged set of functions that can be used as an add-on to Visual Basic. These functions can be as simple as visual buttons, or as sophisticated as a database front-end and report generator. Many leading tools can import VBXs into their pallets and use them to construct visual forms and client front-ends [13].

The second approach is to create an industry-consortium which defines public standards and encourages vendors to create products that conform to those standards. This has been provided by the Interface Definition Language (IDL) and the Common Object Request Broker Architecture (CORBA) developed by the Object Management Group (OMG). This large consortium of companies has cooperated to define CORBA and IDL, and at least 5 CORBA implementations are now commercially available. With the availability of these CORBA implementations, a range of services common to many applications are being provided, design methods for developing CORBA-based applications are becoming available, and large-scale applications beginning to appear [14].

Given the changing technological infrastructure available to software developers, it is not surprising that application development support has been required to evolve substantially to generate applications that are able to take advantage of these changes. Here, we illustrate the evolution of CASE tools as they try to keep up-to-date with application developers' needs. We do this by contrasting CASE tool support of the past (in the late 1980s) with current CASE tool support (mid 1990s), and speculating on the support that will be needed in the future (by the year 2000).

Application development in the 1980s was characterized by a move from mainframe-based to client/server applications. While this move has been implemented in many ways, the approach is characterized by data-intensive applications which were re-engineered by separating remote database services from local desktop display functions. The functions that manipulated the data were initially executed on the server, but migrated to the desktop as the performance of desktop machines improved. This architecture is illustrated in Figure 1.

CASE tool support for client/server architectures typically revolved around the generation and maintenance of the database on the server side, and a series of user interfaces to access and update that database on the client side. Some CASE tools also provided support for database optimizations, inter-operation between databases from different vendors, and synchronization of replicated data sources.

With the advent of the internet and the world-wide web, application developers are demanding 2 major changes in the way in which current applications are developed:

• Web browser interfaces to data retrieval and update. As a consequence of the popularity of the web, browser interfaces are now a familiar and comfortable metaphor for accessing all types of data. This provides a common look and feel for all applications.
• Commonality of interface across heterogeneous client platforms. Today it is common in any organization to have a large investment in a variety of desktop machines running different operating systems and support software. Applications should be able to execute on any of these without requiring custom changes for each desktop configuration.

To achieve this, CASE tool vendors are extending their products to combine the enterprise-level services of client/server architectures, with the platform independence and commonality of interface provided by a web server. An example of such an approach, adapted from [15], is illustrated in Figure 2.

In the example illustrated in Figure 2, an application end user views an application as a series of interconnected web pages from a browser on any machine connected to the internet/intranet. The user interacts with the web browser by selecting links or by entering information into fields on a web-based form. This information is transmitted across the internet to the web server which recognizes requests for external data and passes the request to an application proxy on the web server who's task is to map data requests to application queries on the server. The application server services the request, and the proxy converts the returned information into a web page which it passes to the web server for display to the end user.

In this example, the CASE tool in now responsible for providing the proxy application server that maps between web-based requests and application services, and vice-versa. Typically, the CASE tool provides a set of templates for this which the application developer can use to create user dialog screens in HyperText Markup Language (HTML) or Java.

The result of this approach is not only an application which can be accessed from a browser anywhere on the internet (security restrictions permitting). Additionally, high-performance local clients can still be developed using the client/server approach illustrated in Figure 1.

In the future, organizations would like to move toward greater reuse of the results of previous development efforts, leading to application development primarily through component-based assembly. To achieve this requires a number of changes both in the way applications are developed, and in the resultant architecture of developed applications.

Applications must be developed as independent sets of interacting components, offering well-defined interfaces to potential users of the services provided by the components. Similarly, supporting technology must be available to allow application developers to browse collections of components, select those of interest, and assemble those components to create the desired functionality. Such an approach is illustrated in Figure 3.

The illustration in Figure 3 shows a supply of reusable components available to the application developer. These may be drawn from local sources such as previous development projects, or may be acquired externally by browsing the internet, or purchased from a third-party supplier. In any case, having gathered the components a CASE tool must provide support for browsing, querying, and assembling the components within the context of the current application.

Note that the architecture of the applications may be significantly more complex that the simple client/server model of computing typical of the late 1980s. In particular, shown in Figure 3 is an example in which a service provider is accessible somewhere across the internet. In this example the application makes use of external components from that service provider on a fee-for-service basis. Such approaches to distributed systems may become common as a component-based development marketplace is established.

In summary, we see that application developers for any large-scale system know that their applications must be distributed over many sites, access commercial database management systems (both relational and object-oriented), interact with legacy applications and data, and be web-enabled to allow a browser interface for display and query on heterogeneous machines across the internet. This seems to be true whatever the application domain, whether the system is a real-time command and control system, an enterprise management system, or a materiel tracking system.

Given these characteristics, the developer is faced with a bewildering set of choices. The questions to be addressed include:

• What architectural possibilities exist for a distributed system, and what are their advantages and disadvantages?
• What should the architecture of my solution look like, given the specific requirements of my domain?
• What is a good method of designing my system? Should I use an OO analysis method? A structured method? Do these work for developing web-based applications?
• How can I make use of the existing data and applications I have around? Can I reuse them? How do I wrap them?
• I've heard that all the functionality I need is available either somewhere on the net, or as commercial packages. How do I find them, evaluate them, integrate them, and test them to build my system?
• What support tools and technologies are around to help me? Are there good toolkits? Good libraries of design templates? Useful examples?

Developers of CASE tools and technologies must provide solutions which directly address these questions. These solutions must be well-crafted, and provide a reasonable return on investment for a software purchasing community that is increasingly becoming used to buying and installing low-cost shrink-wrapped software from their local computer superstore.

In this section we analyze three key aspects of future software applications which we believe CASE tools must directly support to be successful: the architecture of large-scale distributed systems, the move toward component-based software development, and the changing requirements for appropriate methods and methodologies. To conclude the section we discuss some of the pragmatic issues which are often the cause of considerable concern for established CASE vendors.

As a consequence of recent advances in network technology, future applications will more frequently be constructed from collections of discrete functionality distributed across a range of machines. For application developers this can bring a number of new problems to the fore. In particular, designing, implementing, and managing large-scale distributed applications is a complex, error-prone task. CASE tools supporting future application development must address the challenge of simplifying the task of creating appropriate architectures for large-scale distributed systems.

Making things more concrete, for a large-scale distributed system an application developer typically has to make decisions at three levels of abstraction [16]:

• At the most abstract level, which we call the architecture level, the developer must decide on the basic "shape" of the solution. That is, the "architectural style" of a solution which determines the primary characteristics of the application's non-functional properties [2]. While Garlan and Shaw analyze these styles based on their inherent qualities, pragmatic factors seem to play a preeminent role in a developer choosing from among them. Typically, the fact that the developer has previously built a similar system dictates that the new system will have a similar style, or will differ in response to that experience. The resulting architecture must be examined with respect to the required functional (i.e., what the system must do), and non-functional (e.g., fault-tolerance, usability, portability, performance) attributes, as dictated by the specific application domain, the users' needs, and what the users are willing to pay to get them.
• At a services level the developer has to consider the interfaces among the major architectural pieces and how they will interact. This level of thinking must consider the operations, their signatures, and their abstract behavior. However, this level must also be concerned with the coordination, or structure, of the way in which they communicate. For example, it may be determined that two components of the architecture (regardless of their function) must synchronize in a particular way, communicate results via certain channels, or allow access to intermediate results through a shared persistent data area (i.e., blackboard). Also dealt with at this level are issues such as replication of service, tolerance to certain faults, unavailability of data, and so on.
• At a mechanism level the developer really does have to choose specific products, languages, platforms, etc. and make the system work. Even here the choices are numerous. For example, having chosen, say, to use Orbix, Oracle, Netscape, Java, etc. the simple question of "where do I start?" is far from straightforward. Each of these products claims some sort of integration with some subset of the others. Yet each does so on its own terms - "I integrate with ABC as long as I am in charge, you don't use features XYZ, and you compile in exactly this order!".

One of the most intriguing and challenging problems is that the designer of a large-scale distributed system must think at these three levels at the same time. Each level directly influences and shapes the others. For example, choosing to use an infrastructure product such as a particular CORBA implementation has a significant impact the services you design and how they interact. While software is sufficiently malleable that you can do almost anything with any product, the products make some things so difficult that the system you have designed is just too brittle, too hard to build, or too complex to maintain.

Currently the topic of software architectures is a major research area, with many technologies being developed including architectural description languages (ADLs), collections of specific styles and their inherent properties, and analysis techniques for determining appropriate architectures given a set of specific domain needs [12]. Much of this work is still in the research and prototyping stage. However, there is the promise that these ideas will be supportable by CASE tools in the very near future [4].

For more than a decade the dream of software engineering managers has been to have "software factories" where standard components are selected from a catalog, assembled with some value-added local pieces or castigations, and sold on to a willing public. In the 1980s this vision was pursued by considering relatively broad application domains, gathering components (or more generally "assets"), and waiting for the flood of customers to make use of them [4, 5]. It didn't work. The majority of "reuse initiatives" did not succeed, and in hindsight it is for all of the obvious reasons: cataloging was hard, the assets were diverse and of varying quality, the interfaces and behavior of assets was poorly defined, and the culture of reuse undervalued and insufficiently rewarded by organizations.

The mid-1990s has seen a massive revival of reuse initiatives under the banner of "component-based development" [10]. There appear to be two separate stimuli to this. First, the economic push of moving toward greater use of commercial off-the-shelf (COTS) products. Particularly in government the use of COTS is seen as a way to reduce costs, speed up technology refreshment, and improve interoperability [6]. Second, the popularity of the world wide web and easy-to-use browsers lead to the belief that "if you want it, it will be somewhere on the net!". Indeed it is true that you can find a great deal of free software in many languages, in every application domain.

Of course, both of these stimuli are fundamentally flawed. Composing a system from COTS applications often requires a great deal of specialized integration code, and in many examples has led to systems that are brittle, impossible to upgrade, and hence very expensive. Similarly, obtaining software from the net is very much a hit-and-miss affair. There is some very good software, but after a lot of effort to find, download, and evaluate, most of it is found to be useless.

But all is not lost. There are some reasons why CBD may be more effective in the mid 1990s than it was in the 1980s. These reasons include:

• Object-oriented languages have a better structure for facilitating CBD than traditional 3GLs. C++ and Ada95 are in the best position to have an impact. As these OO languages gain a foothold in the mainstream software development community the libraries of classes available will increase.
• Into this we must also factor in Java. It's OO structure makes it ideal for creating Java component libraries, and building Java applets and applications from them. It has the added advantage that Java byte code is portable, and contains sufficient information that interface and inheritance details can be determined from a Java component even when you don't have the component's source. Standards concerning the structure of Java applets such as JavaBeans further increases the ease with which Java components can be interchanged and assembled.
• Domain-specific libraries and frameworks are starting to appear. Concentrating on domain-specific component libraries means that a number of assumptions can be made about the likely architectures of applications in the domain, and the ways in which components usually interact. This will make the cataloguing and composition of components much easier to manage. It may also mean that the integration code can be pre-defined to some extent to include some intelligence about its tasks.
• The current CBD initiatives are being vendor-led and supported. Inevitably this means some of what is produced is hype and market positioning. However, it also means that robust technology support, an established market and distribution channels, and near-term orientation will provide usable tools in a reasonable timeframe. These will underwhelm the research community, but are likely to provide some measure of simple, effective tools and techniques for developers writing applications. CBD strategies and tools have already been announced by companies such as TI, PowerSoft, Centura, and NeuronData.
• The web infrastructure is maturing. While there is a great deal of chaos and competing technology, there is also some basic shape to the infrastructure that allows collections of independently-developed software applications to be searched, remotely invoked, communicate, and share data. There is at least a hope that the technologies will converge, or at least interoperate sufficiently well that selecting among them will be based on price and performance rather than which integration strategy you want to be tied to.
• There finally appears to be some real interest and research from the academic community that is leading toward a deeper understanding of component interfaces, component integration, and the ways to detect, avoid, and repair mismatches among components. Papers by Garlan [2], Wallnau et al [8], and Kaiser [9] are good examples.

For established CASE vendors, the move to CBD will be an evolution from their current strategy and tool base. This is far from straight forward, and will probably proceed in iterative fashion. For example, a first step may consist of simply trying to "componentize" existing applications generated using the CASE tool by reengineering them to conform to a set of "component integration guidelines". This may simply be a set of naming conventions, specific required annotations on design elements, and so on. However, this will be sufficient to allow user of the CASE tool to share and exchange application designs. Additionally, this will allow users to develop new discrete pieces of applications that can be catalogued and reused (although purely within the context of that specific CASE tool).

The second step may be to take one of the major competitor's applications and allow them to be imported into that CASE tool by automatically converting them to conform to the integration guidelines. Then add another competitor's applications, and try to make the guidelines and the solution more general. The result of this evolution will be a set of translation filters for the component integration guidelines that have been shown to work with a reasonable set of applications, and experience with the processes that are carried out when developers follow a component assembly approach involving a "select and integrate" rather than "design and build" philosophy.

It is an unfortunate fact that structured methods as defined today are rarely used in any consistent, concerted way by the majority of software developers. Studies have found that such methods use abstractions which don't relate to the designers' perceptions of the system, are too inflexible with respect to changing the design, require too much effort to maintain once coding begins (so aren't), and do not tell maintainers of the system what they need to know to evolve the applications.

These problems are likely to become more acute with the changes in technology, and the need to develop large-scale distributed systems with significant use of CBD. The challenge for method definers is to more closely couple the methods to a development approach that:

• encourages and supports CBD as the primary approach to building an application. Hence it is the component interfaces, interactions, and dependencies that are the focus for the method.
• is more closely aligned to what designers really do when they design: a continuous cycle of "conjecture, explore, evaluate" based on experiential knowledge of what has worked before. (This cycle concludes when the money runs out, the deadline is reached, or the requirements are sufficiently scaled-back to claim you are done -- which ever comes first!).
• documents what maintainers really need to know; design rational and decision points rather than graphical representations of call graphs and inheritance trees (which can more accurately be generated from the code).

It is encouraging to see some recent technology advances which are directly addressing each of these challenges.

Addressing the first challenge, the Unified Modeling Language (UML) is proving to be an interesting focus for creating a notation which can accommodate the modeling of components and interfaces as first class objects [17]. As the UML develops, it is likely that there will be even greater pressure for it to become the standard for component modeling, responding to the influential voices of contributors to UML such as Texas Instruments and ICON Computing.

Addressing the second challenge, a new wave of development methods is being defined centered upon the notions of CBD, modeling component interconnextions, and reusing patterns of component collaboration. Methods such as Catalysis [18] and Synopsis [19] exemplify these new approaches.

Addressing the third challenge, has been a long line of work which can now take advantage of the many developments in multimedia to produce tools which weave documentation, code, audio, and video artifacts to create a complete picture of a product’s design and manufacture. Some of these features are now available in most software development tools. The n-dim system at Carnegie-Mellon University is an innovative research example of a system modeling and design environment which captures many aspects of the design process for later analysis and review [20].

However, in addition to these challenges, any practical CBD method must exhibit another important set of characteristics essential to their success. It would seem that any such method must support at least the following:

• Multiple entry points. The method must support the full life cycle from software design, construction, testing, and so on. It must also support organizations starting an application development from scratch in a traditional development, those involved in a series of rapid application developments, and those wishing to update a large existing system.
• Scaleability to different size tasks. There is a wide variety of possible usage scenarios for CBD, ranging from small-scale reuse of class libraries, to large-scale mission-critical application building from commercial off-the-shelf (COTS) packages. It must be possible apply the method for either of these extremes, and at points in between.
• Documentation of engineering decisions and trade-offs. CBD is based on selection, integration, and evolution of available components. Hence, the method must support the documentation and analysis of the engineering decisions that form the heart of such an approach.
• Specification and analysis of component interfaces. Understanding and controlling the interfaces among components is key to CBD. Rather than simply allowing interface signatures to be defined, a CBD method must allow modeling of component interfaces to include modeling of behavior. It seems likely that some formal language may be required to allow reasoning about the behavior and about compatibilities among different component behaviors.

Viewed from a high level, a method satisfying these needs would involve at least the activities illustrated in Figure 4.

It is important to note that the activities in Figure 4 could be carried out in any order. In fact, for a CBD method the user may engage in all of these activities simultaneously throughout the project. The key to a CBD method (and any CASE tool supporting such a method) is the support it provides for managing this concurrent design, the decisions that are made, and the impact of a decision made in one activity on the other activities.

Another key idea from Figure 4 is that business rules and logic are a separate entity that should be managed and maintained in their own right. While the expert systems initiatives of the 1970s and 1980s may have been greatly over-sold, their basic notion of separately managing business logic as a key corporate resource is very valuable.

A final comment on Figure 4 relates to the central role played by the system architecture. It can be claimed that the system architecture forms the backbone of any application. The choices made in defining this architecture dictate to a large extent many of the system's properties (e.g., performance, fault-tolerance, modifiability). If this architecture is poorly chosen, inadequately documented, or unstable, then the resulting application will likely be poorly suited to its task, and difficult to maintain and evolve.

Any CASE tool supporting CBD must provide explicit support for these features. However, the situation is more complex because it is unlikely that a single CBD method will be appropriate for all situations. There may well be at least three different kinds of CBD requiring three different kinds of method:

In addition to the three primary technical areas of concern for future CASE tool support, there are some particular problems facing established CASE vendors. These are essentially pragmatic issues that inhibit an established CASE vendor from competing in a new market. A few of them are highlighted here.

Competing with the small tool companies

There seem to be an endless stream of small, 2-10 person companies that can quickly produce new CASE tools supporting the latest languages, technologies, and development methods. For an established CASE vendor the life-cycle from concept to product is measured in years and the cost in millions of dollars. At first sight it seems impossible to compete in such a market.

Of course, what the established companies trade on is their reputation, the marketing and support infrastructures they have in place, and the "software engineering" aspects of the tools they develop - support for multiple users, versioning, and so on. Unfortunately, this important separation between the tools is diminishing as the technology changes. In particular, on the surface it seems that the whole premise of CBD is to eliminate that separation completely!

Defining appropriate marketing strategies for tools is a major challenge. This is illustrated by the current approach in many organizations where some pieces of the tools cost many thousands of dollars, smaller versions of those tools (which consist of the main product with some features switched off!) cost only hundreds, and other add-ons are given away free. Simply deciding which part of the tools to sell, which to give away, and in which markets to compete are becoming even more difficult.

There is also an interesting change in development, testing, and release policy that is taking place. Organizations such as Netscape and Microsoft are under such pressure to release new versions of their tools that they reduce their beta testing and field testing to a minimum. Their policy of "release now, fix later" may infuriate some users, but allows them to continually add new functionality to their tools (even at the cost of robustness). Releasing a tool as soon as possible in a narrow window of opportunity is paramount. For established CASE vendors, commitment to quality may be a drawback in obtaining initial market sales! Dealing with legacy platforms and code

In developing new tools, having an established user base is both an asset and a hindrance. While it provides a ready-market for new products, it also brings obligations with respect to supporting existing methods, platforms, code generators, and so on. The organization may wish to invest heavily in developing new tools that support CBD, new implementation languages, and web-based input and display. However, it has an obligation to make bug fixes to existing products running on MVS, OS/2, and a myriad of Unix operating systems.

The result is that established CASE vendors cannot commit as much resources to developing new products as they would like. Furthermore, any new products must provide a migration path for existing customers. Not doing so severely dents the reputation of the organization in the eyes of existing customers.

Taking on a new mindset

There is always a tendency to stick with what you know. This form of "separation anxiety" is true in every walk of life. For established CASE vendors there is a vast corporate knowledge of how to build, maintain, apply, and consult using the existing tools and techniques. Changing that involves a massive re-education of the workforce.

This problem is amplified if the organization is trying to move into new markets. For example, moving from the enterprise-level CASE tool market to the small application development market requires a completely different approach to how designers work, how the tool is marketed, what is important to long-term revenue, and so on. A significant amount of reeducation is required to overcome these problems.

This paper has examined the future profile of application developers' needs and the changing technology base that will be used to develop and maintain the resultant applications. The paper has described the kinds of applications that will be developed in the future, and the implications for established tools and tool vendors. The response to these challenges will be a major determining factor in the future success of established CASE vendors.

While the rapidly-evolving technology poses many threats, there are also many opportunities for established CASE vendors. Such vendors have an excellent base of tools, knowledge and skills, distribution and marketing channels for future products, and an existing user base that can be an important provider of requirements and new ideas for future products.

There are also significant unanswered challenges to be addressed. In particular, established CASE vendors must address the challenges of:

• understanding the distributed systems design life-cycle, the skills required to build large-scale distributed systems, and the requirements for subsequent tool support;
• investigating how CBD can be realized in practice through appropriate methods and tools;
• analyzing and comparing existing CBD methods and tools, both as a showcase of technology for the software engineering community and as a basis for determining competitive advantage for future CASE offerings.

As the CASE industry continues to consolidate, each of these challenges must be addressed to create a more mature, robust marketplace for the rapid creation of high quality, large-scale, distributed applications.

I am grateful to the following people for their comments and feedback on earlier versions of this paper: Fred Long, David Marshall, Doug McCammish, Rajko Milovanovic, Tom Shields, and the anonymous referees.

1. G. Booch, "The Future of Software", Presentation slides, http://www.rational.com, 1996.
2. D. Garlan and M. Shaw, "Software Architectures: Perspectives on an Emerging Discipline", Prentice-Hall, Englewood Cliffs, NJ, 1995.
3. D. Garlan et al., "Architectural Mismatch: Why its Hard to Build Systems From Existing Parts", Proceedings of the 17th International Conference on Software Engineering, pp170-185, ACM Press, 1995.
4. P.C. Clements, "A Survey of Architectural Description Languages", Proceedings of the 8th International Workshop on Software Specification and Design, Paderborn, Germany, May 1996.
5. "ASSET: Source for Software Engineering Technology", see http://source.asset.com.
6. J. Solderitsch et al., "The Reusability Library Framework: Leveraging Software Reuse", available at http://source.asset.com/stars/lm-tds/Papers/sses-rlf/symp.html, November 1992.
7. A.W. Brown, D.J. Carney, M. McFalls, Proceedings of the SEI/MCC COTS Symposium, SEI/CMU Technical Report, January 1995.
8. K.C. Wallnau et al, "Correcting, Identifying, and Avoiding Interface Mismatch: Theory and Practice", Software Engineering Institute, Carnegie Mellon University, Submitted to ICSE'97, August 1996.
9. G. Valetto and G. Kaiser, "Enveloping Sophisticated Tools into Computer-Aided Software Engineering Environments", pp40-48, Proceedings of the 7th International Workshop on CASE, IEEE Computer Society Press, July 1995.
10. A.W. Brown (ed.), "Component-Based Software Development", IEEE Computer Society Press, 1996.
11. E. Yourdon, "CASE Update", Application Development Stratiegies, V8, #10, October 1996.
12. P.C. Clements and L.N. Northrop, "Software Architecture: An Executive Overview", pp55-68 in [10].
13. R. Orlafi et al., "The Essential Distributed Object Survival Guide", John Wiley Press, 1996.
14. J. Seigel, "CORBA: Fundamentals and Programming", John Wiley Press, 1996.
15. "WebCenter: Internet for the Enterprise", Texas Instruments White Paper, Version 3, TI Part Number 264117-0001, December 13, 1996.
16. A.W. Brown et al., "Principles of CASE Tool Integration", Oxford University Press, 1995.
17. The Unified Modeling Language (UML), http://www.rational.com/uml.
18. D. D’Souza and A. Wills, "Component-Based Development Using Catalysis", To Appear, Prentice-Hall, 1997. A pre-publication version is available at http://www.iconcomp/catalysis.
19. C. Dellarocas, "Towards a Design Handbook for Integrating Software Components", Proceedings of the 5^th Symposium on Assessment of Software Tools (SAST97), IEEE Computer Society Press, June 1997.
20. J. Robertson, E. Subrahmanian, M. Thomas, A.W. Westerberg, "Management of the Design Process: The Impact of Information Modeling", Technical Report, Engineering Design Research Center, Carnegie Mellon University, Pittsburgh, PA, EDRC 06-179-94, 1994.