Abstract: As software systems become more complex the overall system structure -- or software architecture -- becomes a central design problem. An important step towards an engineering discipline of software is a formal basis for describing and analyzing these designs. In this paper we present a formal approach to one aspect of architectural design: the interactions between components. The key idea is to define architectural connectors as explicit semantic entities. These are specified as a collection of protocols that characterize each of the participant roles in an interaction and how these roles interact. We illustrate how this scheme can be used to define a variety of common architectural connectors. We further provide a formal semantics and show how this leads to a system in which architectural compatibility can be checked in a way analogous to type checking in programming languages.

Abstract: Software system builders are increasingly recognizing the importance of exploiting design knowledge in the engineering of new systems. One way to do this is to define an architectural style for a collection of related systems. The style determines a coherent vocabulary of system design elements and rules for their composition. By structuring the design space for a family of related systems a style can, in principle, drastically simplify the process of building a system, reduce costs of implementation through reusable infrastructure, and improve system integrity through style-specific analyses and checks. Like architectural style, object-oriented design patterns attempt to capture and exploit design knowledge to ease the process of designing software systems and reusing proven designs. There are, however, significant differences in the roles and capabilities of architectural styles and object-oriented design patterns, as there are between architectural design and object-oriented design. In this paper we illustrate the relationship between software architecture and object-oriented design, as well as the relationship between architectural styles and design patterns. We begin by defining our terms and then proceed to compare and contrast the various approaches with examples.

Abstract: The software architecture of most systems is usually described informally and diagrammatically by means of boxes and lines. In order for these descriptions to be meaningful, the diagrams are understood by interpreting the boxes and lines in specic, conventionalized ways. The informal, imprecise nature of these interpretations has a number of limitations. In this paper we consider these conventionalized interpretations as architectural styles and provide a formal framework for their uniform denition. In addition to providing a template for precisely dening new architectural styles, this framework allows for analysis within and between dierent architectural styles.

Abstract: For all but the most trivial software systems, you must pay close attention to its architecture - the conceptual glue that holds every phase of a project together for its many stakeholders. Without an architecture that is appropriate for the problem being solved, the project will at the very least stumble along, or most likely, fail. Even with a superb architecture, if it is not well understood and well communicated - in other words, well documented - the project cannot be considered a complete success. Although architecture is now widely recognized as a critical element in software development, there has been little guidance independent of language or notation about how to capture it. Based on the authors' extensive experience, Documenting Software Architecture, helps you to decide what information to document and then, with guidelines and examples (in various notations, including UML), shows you how to express an architecture in a form that everyone can understand. If you go to the trouble to create a strong architecture, you must also be prepared to describe it in enough detail, without ambiguity, and to organize it so that others can quickly find the information they need. As a guide for practitioners, the book covers: Seven rules for sound documentation The uses of software architecture documentation, including goals and strategies Architectural views and styles, with general introductions and specific examples Documenting software interfaces and software behavior Templates for capturing and organizing the information to generate a coherent package. 'This book is of immense value. It should save you months of trials and errors, lots of undeserved hassle, and many costly mistakes that could potentially jeopardize the whole endeavor. It will become an important reference on the shelf of the software architect.' - From the Foreword by Philippe Kruchten, Rational Software Canada.

Abstract: Over the past decade there has been considerable experimentation with the design of architecture description languages that can provide a formal basis for description and analysis of the architectures of component-based systems. As the eld has matured there has emerged among the software architecture research community general consensus about many aspects of the foundations for architectural representation and analysis. One result has been the development of a generic architecture description language, called Acme, that can serve as a common representation for software architectures and that permits the integration of diverse collections of independently developed architectural analysis tools. In this paper we describe the Acme language and tools, and our experience in using it to integrate architecture analysis tools and to describe component-based systems.

Abstract: An increasingly important trend in the engineering of complex systems is the design of component integration standards. Such standards define rules of interaction and shared communication infrastructure that permit composition of systems out of independently-developed parts. A problem with these standards is that it is often difficult to understand exactly what they require and provide, and to analyze them in order to understand their deeper properties. In this paper we use our experience in modeling the High Level Architecture (HLA) for Distributed Simulation to show how one can capture the structured protocol inherent in an integration standard as a formal architectural model that can be analyzed to detect anomalies, race conditions, and deadlocks.

Abstract: A critical issue for complex component-based systems design is the modeling and analysis of architecture. One of the complicating factors in developing architectural models is accounting for systems whose architecture changes dynamically (during run time). This is because dynamic changes to architectural structure may interact in subtle ways with on-going computations of the system.

In this paper we argue that it is possible and valuable to provide a modeling approach that accounts for the interactions between architectural reconfiguration and non-reconfiguration system functionality, while maintaining a separation of concerns between these two aspects of a system. The key to the approach is to use a uniform notation and semantic base for both reconfiguration and steady-state behavior, while at the same time providing syntactic separation between the two. As we will show, this permits us to view the architecture in terms of a set of possible architectural snapshots, each with its own steady-state behavior. Transitions between these snapshots are accounted for by special reconfiguration-triggering events.

Abstract: Numerous architectural description languages (ADLs) have been developed, each providing complementary capabilities for architectural development and analysis. Unfortunately, each ADL and supporting toolset operates in isolation, making it difficult to integrate those tools and share architectural descriptions. ACME is being developed as a joint effort of the software architecture research community as a common interchange format for architecture design tools. ACME provides a structural framework for characterizing architectures, together with annotation facilities for additional ADL-specific information. This scheme permits subsets of ADL tools to share architectural information that is jointly understood, while tolerating the presence of information that falls outside their common vocabulary. In this paper we describe ACME's key features, rationale, and technical innovations.

Abstract: The HLA RTI is a complex artifact, supporting several classes of interaction (e.g., federation management, object management, time management). A critical challenge in producing an RTI architectural framework (and its associated simulation interface specifications) is to develop confidence that its specification is well-formed and complete. In this paper we describe on-going work in formally modelling the HLA both to document the standard more precisely, as well as to analyze it for anomalies, omissions, inconsistencies, and ambiguities. The technical basis for this work is the use of a formal architectural description language, called Wright, and its accompanying toolset.

Abstract: Software architecture is receiving increasing attention as a powerful way to deal with the complexity of large software systems. It has emerged as a distinct form of abstraction for software systems with its own set of design issues, vocabulary, and goals. Like designers in other disciplines, software architects can gain significant leverage by using powerful design environments and tools. Powerful design tools generally encapsulate a relatively small amount of design expertise that provides the important functionality of the tool within a relatively large support infrastructure. In this position paper I argue that in order to make the development of specialized architectural design tools practical it must be relatively easy and inexpensive to capture and make use of the desired design expertise. I then briefly describe an emerging approach for capturing this design expertise so that it can be used to incrementally configure architectural design environments.

Abstract: Although numerous mechanisms for promoting software reuse have been proposed and implemented over the years, most have focused on the reuse of implementation code. There is much conjecture and some empirical evidence, however, that the most effective forms of reuse are generally found at more abstract levels of software design. In this paper we discuss software reuse at the architectural level of design. Specifically, we argue that the concept of 'architectural style' is useful for supporting the classification, storage, and retrieval of reusable architectural design elements. We briefly describe the Aesop system's Software Shelf, a tool that assists designers in selecting appropriate design elements and patterns based on stylistic information and design constraints.

Abstract: Software architecture is receiving increasingly attention as a critical design level for software systems. However, the current practice of architectural description is largely informal and ad hoc, with the consequence that architectural documents serve as a poor communication mechanism, are difficult to analyze, and may have very little relationship to the implemented system. In an attempt to address these problems several researchers have experimented with formalisms for architectural specification and modelling. One such formalism is Wright. In this paper we show how Wright can be used to provide insight into an architectural design by modelling a prototype implementation of part of the AEGIS Weapons System.

Abstract: Increasingly, developers look to software architecture to help them control the complexity of their systems. When developing a particular system, designers tend not to explore all possible alternatives for its architecture. Instead, they use specific patterns and idioms that are effective for the domain in which they are working. We term such a collection of patterns and idioms an architectural style.

Unfortunately, with few exceptions current exploitation of architectural style is informal and ad hoc. In this paper we consider an alternative to the ad hoc description of architectural styles, a formal description based on the inherent structure of software architectures. We explore this solution by describing Justo and Cunha's message passing style in Wright, an architecture description language based on CSP.

Abstract: As the design of software architectures emerges as a discipline within software engineering, it will become increasingly important to support architectural description and analysis with tools and environments. In this paper we describe a system for developing architectural design environments that exploit architectural styles to guide software architects in producing specific systems. The primary contributions of this research are:

- A generic object model for representing architectural designs;
- The characterization of architectural styles as speculations of this object model;
- A toolkit for creating an open architectural design environment from a description of a specific architectural style.

We use our experience in implementing these concepts to illustrate how style-oriened architectural design raises new challenges for software support environments.

Abstract: Large software systems require decompositional mechanisms in order to make them tractable. Traditionally, MILs and IDLs have played this role by providing notations based on definition/use bindings. In this paper we argue that current MIL/IDLs based on definition/use have some serious drawbacks. A significant problem is that they fail to distinguish between 'implementation' and 'interaction' relationships between modules. We propose an alternative model in which components interact along well-defined lines of communication - or connectors. Connectors are defined as protocols that capture the expected patterns of communication between modules. We show how this leads to a scheme that is much more expressive for architectural relationships, that allows the formal definition of module interaction, and that supports its own form of automated checks and formal reasoning.

Abstract: The software architecture of most systems is described informally and diagrammatically. In order for these descriptions to be meaningful at all, figures are understood by interpreting the boxes and lines in specific, conventionalized ways. The imprecision of these interpretations has a number of limitations. In this paper we consider these convetionalized interpretations as architectural styles and provide a formal framework for their uniform definition. In addition to providing a template for precisely defining new architectural styles, this framework allows for the proof that the notational constraints on a style are sufficient to guarantee the meanings of all described systems and provides a unified semantic base through which different stylistic interpretations can be compared.

Abstract: Researchers, practitioners, educators, and students of software architecture would benefit from having online access to quality information about the state of research and practice of software architecture. In recent years, Wiki technology has enabled distributed and collaborative editing of content using only a Web browser. To explore whether Wiki technology would be effective in facilitating the ongoing discussion and evolution of ideas on software architecture, we hosted the WICSA Wiki WAN Party (WWWP) during the 4th Working IEEE/IFIP Conference on Software Architecture (WICSA 2004). We used a history tool developed at IBM Research to monitor site activity and provide daily feedback to conference participants. This report recounts experience hosting this Wiki site and summarizes the site activity.

Abstract: A practical approach for documenting software architectures is presented. The approach is based on the well-known architectural concept of views, and holds that documentation consists of documenting the relevant views and then documenting the information that applies to more than one view. Views can be usefully grouped into viewtypes, corresponding to the three broad ways an architect must think about a system: as a set of implementation units, as a set of runtime elements interacting to carry out the system's work, and as a set of elements existing in and relating to external structures in its environment. A simple three-step procedure for choosing the relevant views to document is given, and applied to the problem of documentation for a large, complex NASA system.

Abstract: As software systems become more complex, the overall system structure---or software architecture---becomes a central design problem. A system's architecture provides a model of the system that suppresses implementation detail, allowing the architect to concentrate on the analyses and decisions that are most crucial to structuring the system to satisfy its requirements.

Unfortunately, current representations of software architecture are informal and ad hoc. While architectural concepts are often embodied in infrastructure to support specific architectural styles and in the initial conceptualization of a system configuration, the lack of an explicit, independently-characterized architecture or architectural style significantly limits the benefits of software architectural design in current practice.

In this dissertation, I show that an Architecture Description Language based on a formal, abstract model of system behavior can provide a practical means of describing and analyzing software architectures and architectural styles. This dissertation demonstrates this claim through Wright, an architectural description language based on the formal description of the abstract behavior of architectural components and connectors. Wright provides a practical formal basis for the description of both architectural configurations and of architectural styles. It is distinguished by the use of explicit, independent connector types as interaction patterns, the ability to describe the abstract behavior of components using a CSP-like notation, the characterization of styles using predicates over system instances, and a collection of static checks to determine the consistency and completeness of an architectural specification. We introduce techniques to support the analysis of large-scale systems, and demonstrate Wright's expressiveness and practicality through three case studies.

Abstract: The widespread presence of the Unified Modeling Language (UML) has led practitioners to try to apply it when documenting software architectures. While early versions of UML have been adequate for documenting many kinds of architectural views, they have fallen somewhat short, particularly for documenting component and connector views. UML 2. 0 has added a number of new constructs and modified some existing ones to address these problems. In this report, we explore how changes in this version affect UML’s suitability as a notation for docu- menting component and connector views.

Abstract: Armani is a language for capturing software architecture design expertise and specifying software architecture designs. This document describes the Armani language in detail with specifications for the language syntax and semantics, as well as examples illustrating common usage.

Abstract: This comprehensive handbook outlines how to produce high-quality documentation for software architectures.

Abstract: As software systems become more complex the overall system structure -- or software architecture -- becomes a central design problem. An important step towards an engineering discipline of software is a formal basis for describing and analyzing these designs. In this paper we present a theory for one aspect of architectural description: the interactions between components. The key idea is to define architectural connectors as explicit semantic entities. These are specified as a collection of protocols that characterize each of the participant roles in an interaction and how these roles interact. We illustrate how this scheme can be used to define a variety of common architectural connectors. We further provide a formal semantics and show how this leads to a system in which architectural compatibility can be checked in a way analogous to type checking in programming languages.

Abstract: An important goal in software engineering is to describe complex software systems at an architectural level of abstraction. While there are many useful architectural paradigms (pipes, blackboards, etc.) they are typically understood only idiomatically and applied in an ad hoc fashion. We show how a formal model allows us to say precisely what we mean by a software architecture, explore its properties, and systematically describe instances of the architecture. We illustrate the approach using the well-known example of pipe-filter architectures.