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: 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: Many software designs are produced by combining and elaborating existing architectural design fragments. These fragments may be design patterns, partially thought-out ideas, or portions of some previously-developed system design. To provide mechanized support for this activity it is necessary to have a precise characterization of when and how two or more architectural fragments can be combined. In this paper we describe extensions to notations for software architecture to represent incomplete design fragments, and algorithms for combining fragments in a process analogous to unification in logic.

Abstract: Dynamically composed software systems are constructed as they execute. Although these systems are of increasing importance and arise in a number of application areas, configuration management tools do not provide much support for them. This paper presents progress towards providing enhanced configuration management techniques for dynamically composed systems. The paper commences with an example of dynamically composed systems, which is used to motivate the relevance of dynamically composed systems, and to highlight various design issues and requirements for configuration management in this domain. A model, and its associated notation DCDL, is then presented to describe particular aspects of the example. This model seamlessly integrates the notions of consistency, specified in terms of complete configurations, and version families, which are relevant to the incomplete configurations of crucial importance in understanding configurations of dynamically composed systems. DCDL is then used to provide insight into the requirements for configuration management tools for dynamically composed systems.

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: 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.