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: One increasingly important technique for improving system dependability is to provide mechanisms for a system to adapt at run time in order to accommodate varying resources, system errors, and changing requirements. For such 'self-repairing' systems one of the hard problems is determining when a change is needed, and knowing what kind of adaptation is required. In this paper we describe a partial solution in which stylized architectural design models are maintained at run time as a vehicle for automatically monitoring system behavior, for detecting when that behavior falls outside of acceptable ranges, and for deciding on a high-level repair strategy. The main innovative feature of the approach is the ability to specialize a generic run time adaptation framework to support particular architectural styles and properties of interest. Specifically, a formal description of an architectural style defines for a family of related systems the conditions under which adaptation should be considered, provides an analytic basis for detecting anomalies, and serves as a basis for developing sound repair strategies.

Abstract: A large financial company, struggling with legacy systems that did not interoperate, performed a pilot project to teach software architecture to an enthusiastic application development team. Experienced mentors, including the author, worked with the application team for seven months who completed their engineering goal successfully. However, the mentors were unsuccessful in their attempt to train any of the six members of application team to create architecture models on their own, though they were able to create them collaboratively with the mentors. This surprising result is due to the application team's strong preference for concrete artifacts over abstract ones. Even more surprising, an application developer from a different project, 'Developer X', read the architecture modeling documentation on an internal website and, without mentoring, created good architecture models within a few days. In light of this failure to teach software architecture, two short-term strategies are suggested for the use of software architecture in companies and long-term strategies are discussed.

Abstract: While publish-subscribe systems have good engineering properties, they are difficult to reason about and to test. Model checking such systems is an attractive alternative. However, in practice coming up with an appropriate state model for a pub-sub system can be a difficult and error-prone task. In this paper we address this problem by describing a generic pub-sub model checking framework. The key feature of this framework is a reusable, parameterized state machine model that captures pub-sub runtime event management and dispatch policy. Generation of models for specific pub-sub systems is then handled by a translation tool that accepts as input a set of pub-sub component descriptions together with a set of pub-sub properties, and maps them into the framework where they can be checked using off-the-shelf model checking tools.

Abstract: 'Time is money', or so goes the old saying. Perhaps influenced by this aphorism, some strategies for incorporating costs in the analysis of software design express all costs in currency units for reasons of simplicity and tractability. Indeed, in theoretical economics all costs can, in principle, be expressed in dollars. Software engineering problems, however, often present situations in which converting all costs to a common currency is problematical. In this paper we pinpoint some of these situations and the underlying causes of the problems, and we argue that it is often better to treat costs as a multidimensional value, with dimensions corresponding to distinct types of resources. We go on to highlight the differences among cost dimensions that need to be considered when developing cost-benefit analyses, and we suggest mechanisms for mediating among heterogeneous cost dimensions.

Abstract: Increasingly systems are composed of parts: software components, and the interaction mechanisms (connectors) that enable them to communicate. When assembling systems from independently developed and potentially mismatched parts, wrappers may be used to overcome mismatch as well as to remedy extra-functional deficiencies. Unfortunately the current practice of wrapper creation and use is ad hoc, resulting in artifacts that are often hard to reuse or compose, and whose impact is difficult to analyze. What is needed is a more principled basis for creating, understanding, and applying wrappers. Focusing on the class of connector wrappers (wrappers that address issues related to communication and compatibility), we present a means of characterizing connector wrappers as protocol transformations, modularizing them, and reasoning about their properties. Examples are drawn from commonly practiced dependability enhancing techniques.

Abstract: As intelligent devices become affordable and wireless infrastructure becomes pervasive, the potential to combine, or aggregate, device functionality to provide a user with a better experience grows. Often, there will be multiple devices providing similar functionality that the user will have to choose from for the aggregation. This paper presents the design and prototype implementation of a system for automatic selection of devices for aggregation in a dynamic environment. It allows a user to express trade-offs between the quality of device attributes, user distraction, and aggregation stability. This approach enables a user to have a richer experience without having to constantly worry about the device and the environment details.

Abstract: Computing environments of the future should enable mobile users to take full advantage of the computing capabilities available at each location, while allowing them to focus on their real tasks, rather than being distracted by dealing with the configuration and reconfiguration of computer systems to support those tasks. The Aura infrastructure performs automatic configuration and reconfiguration of Ubicomp environments, according to the user s task and intent. This report describes the software architecture of the Aura infrastructure, and discusses the underlying rational. It describes the architecture from a layered perspective, detailing the partition of responsibility and shared assumptions, as well as from a component-connector perspective, detailing the protocols of interaction between the components (APIs and sequencing). The contents and format of the exchanged messages is extensively discussed, as well as the details pertaining service interconnection and decomposition. This report proposes a utility-based approach for modeling user preferences, and details how such models can be exploited for both coarse-grain automatic (re)configuration, and fine-grain adaptation to resource change.

Abstract: Architectural modeling and analysis is a critical phase in developing large and complex software systems. The usefulness of multiple views has likewise long been recognized. In this experience report, we explain how we used two ADLs to model a system initially described in UML. The system (SCRover) itheir Mission Data System technology. We describe (a) the processes that we used to extract architectural models from the UML description, (b) the way in which each ADL was used to model the system, (c) a classification of the architectural defects we uncovered, and (d) a comparison of the relative benefits of the two ADLs in terms of the different classes of defects they uncovered.