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: A critical aspect of the design for any large software system is its gross structure represented as a high-level organization of computational elements and interactions between those elements. Broadly speaking, this is the software architectural level of design. The structure of software has long been recognized as an important issue of concern. However, recently software architecture has begun to emerge as an explicit field of study for software engineering practitioners and researchers. Evidence of this trend is apparent in a large body of recent work in research such as module interface languages, domain specific architectures, architectural description languages, design patterns and handbooks, formal underpinnings for architectural design, and architectural design environments. This IEEE Transactions on Software Engineering Special Issue on Software Architecture presents seven papers that illustrate many of these emerging research areas.

Abstract: As the size of software systems increases, the algorithms and data structures of the computation no longer constitute the major design problems. When systems are constructed from many components, the organization of the overall system -- the software architecture -- presents a new set of design problems. This level of design has been addressed in a number of ways including informal diagrams and descriptive terms, module interconnection languages, templates and frameworks for systems that serve the needs of specific domains, and formal models of component integration mechanisms.

In this paper we provide an introduction to the emerging field of software architecture. We begin by considering a number of common architectural styles upon which many systems are currently based and show how different styles can be combined in a single design. Then we present six case studies to illustrate how architectural representations can improve our understanding of complex software systems. Finally, we survey some of the outstanding problems in the field, and consider a few of the promising research directions.

Abstract: Dynamically bound systems are those software systems which are able to incorporate executable components into themselves during execution. Such systems are clearly very flexible; however they suffer from problems associated with this flexibility. These problems, which are similar to some of the problems addressed by configuration management, include how to locate and select components, how to manage change to components, how to verify the consistency of configurations of the systems and how to determine the actual system configuration. This paper describes some of the systems which support dynamic binding and discusses some of their associated prob- lems. An approach to the design of configuration management facilities for dynamically bound systems is then outlined. This approach involves the detailed modelling of dynamic binding in a range of systems supporting this notion and the integration of this model with the relevant aspects of a model of configuration management developed by Wiebe. Finally, the paper foreshadows some ways in which the previously mentioned problems with dynamically bound systems can be addressed.

Abstract: Software architecture is the level of software design that ad- dresses the overall structure and properties of software systems. It provides a focus for certain aspects of design and development that are not appropriately addressed within the constituent modules. Architectural design depends heavily on accurate specications of subsystems and their interactions. These specications must cover a wide variety of properties, so the specication notations and associated methods must be selected or developed to match the properties of interest. Unfortunately, the available formal methods are only a partial match for architectural needs, which entail description of structure, packaging, environmental assumptions, representation, and performance as well as functionality. A prerequisite for devising or selecting a formal method is sound understanding of what needs to be formalized. For software architecture, much of this understanding is arising through progressive codication, which begins with real-world examples and creates progressively more precise models that eventually support formalization. This paper explores the pro- gressive codication of software architecture: the relation between emerging models and the selection, development, and use of formal systems.

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: A central aspect of architectural design is the use of recurring organizational patterns and idioms- or architectural styles. Examples include generic system organizations such as those based on dataflow or layers, as well as specific organizational structures such as the classical decomposition of a compiler, the OSI communication stack, and the MVC user interface paradigm.

The principled use of architectural styles has a number of practical benefits. First, it promotes design reuse: routine solutions with well-understood properties can be reapplied to new problems with confidence. Second, it can lead to significant code reuse: often the invariant aspects of an architectural style lend themselves to shared implementations. Third, it is easier for others to understand a system's organization if conventionalized structures are used. For example, even without giving details, characterization of a system as a 'client-server' organization immediately conveys a strong image of the kinds of pieces and how they fit together. Fourth,use of standardized styles supports interoperability. Examples include CORBA object-oriented architecture, and event-based tool integration. Fifth, by constraining the design space, an architectural style often permits specialized,style-specific analyses. For example, it is possible to analyze pipe-filter systems for schedulability, throughput, latency, and deadlock-freedom. Such analyses might not be meaningful for an arbitrary, ad hoc architecture - or even one constructed in a different style. Sixth, it is usually possible to provide style-specific visualizations: this makes it possible to provide graphical and textual renderings that match engineers' domain-specific intuitions about how their designs should be depicted.