Software architectures shift the focus of developers from lines-of-code to coarser-grained architectural elements and their overall interconnection structure. Architecture description languages (ADLs) have been proposed as modeling notations to support architecture-based development. There is, however, little consensus in the research community on what is an ADL, what aspects of an architecture should be modeled in an ADL, and which of several possible ADLs is best suited for a particular problem. Furthermore, the distinction is rarely made between ADLs on one hand and formal specification, module interconnection, simulation, and programming languages on the other. This paper attempts to provide an answer to these questions. It motivates and presents a definition and a classification framework for ADLs. The utility of the definition is demonstrated by using it to differentiate ADLs from other modeling notations. The framework is used to classify and compare several existing ADLs, enabling us in the process to identify key properties of ADLs. The comparison highlights areas where existing ADLs provide extensive support and those in which they are deficient, suggesting a research agenda for the future.

Continuous availability is a critical requirement for an important class of software systems. For these systems, runtime system evolution can mitigate the costs and risks associated with shutting down and restarting the system for an update. We present an architecture-based approach to runtime software evolution and highlight the role of software connectors in supporting runtime change. An initial implementation of a tool suite for supporting the runtime modification of software architectures, called ArchStudio, is presented. 1

Existing ADLs typically support only static architecture specification and do not provide facilities for the support of dynamically changing architectures. This paper presents a possible solution to this problem: in order to adequately support dynamic architecture changes, ADLs can leverage techniques used in dynamic programming languages. In particular, changes to ADL specifications should be interpreted. To enable interpretation, an ADL should have an architecture construction component that supports explicit and incremental specification of architectural changes, in addition to the traditional architecture description facilities. This will allow software architects to specify the changes to an architecture after it has been built. The paper expands upon the results from an ongoing project-- building a development environment for C2-style architectures. 1 I.

This paper describes an approach to module composition by executing "module expressions" to build systems out of component modules; the paper also gives a novel semantics intended to aid implementers. The semantics is based on set theoretic notions of tuple set, partial signature, and institution, thus avoiding more difficult mathematics theory. Language features include information hiding, both vertical and horizontal composition, and views for binding modules to interfaces. Vertical composition refers to the hierarchical structuring of a system into layers, while horizontal composition refers to the structure of a given layer. Modules may involve information hiding, and views may involve behavioral satisfaction of a theory by a module. Several "Laws of Software Composition" are given, which show how the various module composition operations relate. Taken together, this gives foundations for an algebraic approach to software engineering. 1.1 Introduction The approach to module compos...

Existing software architecture research has focused on static architectures, where the system architecture is not expected to change during system execution. We argue that the architectures of many systems, especially long running or mission critical systems, evolve during execution, and thus cannot be accurately modeled and analyzed using static architectures. To overcome these problems, we propose the use of dynamic architectures, where the system architecture may change during execution. In this paper, we identify the issues involved in supporting dynamic architectures. Although some of these issues may be addressed by augmenting current models (i.e., adding constructs that support dynamism to existing architectural description languages), many are new to dynamic architectures (i.e., runtime support for modifying architectures). We describe an initial implementation of our tool, ArchShell, that supports the runtime modification of C2-style software architectures. 1

This paper discusses an approach to software architecture based on concepts from parameterized programming, particularly its language of "module expressions." A module expression describes the architecture of a system as an interconnection of component modules, and executing the expression actually builds the system. Language features include: modules parameterized by theories, which declare interfaces; a number of module composition operations; views for binding modules to interfaces; and both vertical and horizontal composition. Modules may involve information hiding, theories may declare semantic restrictions with axioms, and views assert behavioral satisfaction of axioms by a module. Some "laws of software composition" are given, showing how various module composition operations are related. We also show how a variety of architectural styles can be supported, and how this approach can be extended to support evolution and traceability. All this is intended to ease the development of large systems, and in particular, to make reuse more effective in practice.

Successfully applying formal methods to software development promises to move us closer to a true engineering discipline. The authors offer suggestions for overcoming the problems that have hindered the use of formal methods thus far. Today's fast-moving technology demands ever quicker and more reliable ways to develop software systems that meet user needs. Although industry spends billions of dollars each year developing software, many software systems fail to satisfy their users. Moreover, many systems once thought adequate no longer are, while others are never finished or never used. The September 1994 issue of Scientific American gives some sobering examples and concludes that "despite 50 years of progress, the software industry remains years⎯perhaps decades⎯short of the mature engineering discipline needed to meet the demands of an information-age society. " 1 Software development failures have reached staggering proportions: an estimated $81 billion was spent on canceled software projects in 1995 and an estimated $100 billion in 1996. 2 Many computer scientists have suggested that formal methods can play a significant role in improving this situation. Although these methods have achieved impressive successes, they have also produced disappointments. Formal methods do not yet effectively handle large and complex

The COIL Project is an effort to design a module interconnection language specifically for managing database integration and evolution. This project is a significant part of a larger effort to build a database integration and evolution environment called Sanctuary. COIL will make a significant contribution to module interconnection language research by providing interface symmetry, application-level module composition, and syntactic analysis capabilities for systems constructed with the Object Management Group's Common Object Request Broker Technology (CORBA). Since CORBA is the state-of-the-art in distributed, object-based technologies, and since it has been adopted by over 800 software vendors, software developers and end users, this research will have immediate and high impact. This paper presents a discussion of the motivation, background, and fundamental module interconnection language issues and goals for the COIL project. 1. Motivation Modern persistent applications typically ...

has been defined as: • "an assemblage of software components, special-ized for a particular type of task (domain), generalized for effective use across that domain, composed in a standardized structure (topol-ogy) effective for building successful applica-tions " [Hay94] or, alternately • "a context for patterns of problem elements, solution elements, and situations that define mappings between them [Hid90]. The following small example 2 illustrates these defini-tions as well as provides the reader with some insight into the types of processes and tools needed to support the creation and use of a DSSA. 1