Abstract: The Rainbow framework uses software architectures and a reusable infrastructure to support self-adaptation of software systems. The use of external adaptation mechanisms allows the explicit specification of adaptation strategies for multiple system concerns.

Abstract: Recently there has been increasing interest in developing systems that can adapt dynamically to cope with changing environmental conditions and unexpected system errors. Most efforts for achieving self-adaptation have focused on the mechanisms for detecting opportunities for improvement and then taking appropriate action. However, such mechanisms beg the question: what is the system trying to achieve? In a given situation there may be many possible adaptations, and knowing which one to pick is a difficult question. In this paper we advocate the use of explicit representation of user task as a critical element in addressing this missing link.

Abstract: A common approach to adding self-management capabilities to a system is to provide one or more external control modules, whose responsibility is to monitor system behavior, and adapt the system at run time to achieve various goals (configure the system, improve performance, recover from faults, etc.). An important problem arises when there is more than one such self-management module: how can one make sure that they are composed to provide consistent and complementary benefits? In this paper we describe a solution that introduces a self-management coordination architecture and infrastructure to support such composition. We focus on the problem of coordinating self-configuring and self-healing capabilities, particularly with respect to global configuration and incremental repair. We illustrate the approach in the context of a self-managing video teleconference system that composes two pre-existing adaptation modules to achieve synergistic benefits of both.

Abstract: Over the past decade a number of architecture description languages (ADLs) have been proposed to facilitate modeling and analysis of software architecture. While each claims to have various benefits, to date there have been few studies to assess the relative merits of these approaches. In this paper we describe our experience using two ADLs to model a system initially described in UML, and compare their effectiveness in identifying system design flaws. We also describe the techniques we used for extracting architectural models from a UML system description.

Abstract: Software architectural modeling is crucial to the development of high-quality software. Software engineering tool support is required for this activity, so that models can be developed, viewed, analyzed, and refined to implementations. This support needs to be provided in a flexible and extensible manner so that the tools can fit into a company s process and can use particular, perhaps company-defined, domain-specific architectural styles. Early architecture development environments were restricted to supporting particular architectural styles, and were not easy to tailor to other styles or domains. In this research demonstration, we describe AcmeStudio, a styleneutral architecture development environment that can (1) allow architects to tailor the environment for particular domains; (2) be used as a framework for integrating domain-specific architectural analyses; and (3) can be extended to integrate with other tools that are used in a company s software development process. We illustrate the main features of AcmeStudio and provide some insight into how we have tailored it to real-world domains specific to NASA and Ford Motor Company.

Abstract: One of the challenging problems for software developers is guaranteeing that a system as built is consistent with its architectural design. In this paper we describe a technique that uses run time observations about an executing system to construct an architectural view of the system. With this technique we develop mappings that exploit regularities in system implementation and architectural style. These mappings describe how low-level system events can be interpreted as more abstract architectural operations. We describe the current implementation of a tool that uses these mappings, and show that it can highlight inconsistencies between implementation and architecture.

Abstract: An important emerging requirement for computing systems is the ability to adapt at run time, taking advantage of local computing devices, and coping with dynamically changing resources. Three specific technical challenges in satisfying this requirement are to (1) select an appropriate set of applications or services to carry out a user s task, (2) allocate (possibly scarce) resources among those applications, and (3) reconfigure the applications or resource assignments if the situation changes. In this paper we show how to provide a shared infrastructure that automates configuration decisions given a specification of the user s task. The heart of the approach is an analytical model and an efficient algorithm that can be used at run time to make near-optimal (re)configuration decisions. We validate this approach both analytically and by applying it to a representative scenario.

Abstract: Modern software engineering environments provide programmers with contextual information on methods and classes in their software system. However, programmers increasingly encounter frameworks such as Microsoft Foundation Classes or Enterprise Java Beans whose required plug-in mechanisms cannot be adequately described with method or class documentation. The needs of programmers using frameworks are different from the needs when using libraries. Software engineering environments should be augmented with tools to aid programmers in understanding the demands of using frameworks.

Abstract: One crucial aspect of high quality software engineering is the development of a welldefined software architectural model. Despite advances in using software architectural models to clarify system design, there remains the problem of determining whether the system as implemented has the architecture as designed? One approach is to to this is to monitor the running system and translate observed events to events that construct and update an architectural model that reflects the actual running system. One can then compare this dynamically-determined model to the correct architectural model. Discrepancies can be used to flag implementation errors, or, possibly, to effect run-time adaptations to correct certain kinds of flaws. At Carnegie Mellon University, our research group has been investigating the use of system monitoring and reflection using architectural models. In the process of exploring this area we have identified a number of significant research challenges. In this paper we outline our experience, and use that as a way to lay out an agenda for architecture-based approaches to system monitoring and system self-repair.

Abstract: In conjunction with Ford Motor Company, we built a tool to support multilevel architectural design. The tool, called Synergy, allows Ford to visually design architectures of vehicle control components. The components are imported from existing Simulink models; then the tool automatically generates a detailed view showing all required connections and ports. The resulting model is exported to Simulink for further analysis. In this paper we describe the conceptual and technical challenges encountered in building Synergy and our design choices for solving them.

Abstract: An attractive approach to architecture-based design is to structure the development process into two tiers. The top tier represents the abstract design (or architecture) of a system in terms of abstract components. The bottom tier refines that design by making specific implementation decisions, such as platform, middleware, and component implementations. While attractive in principle, there has been relatively little industrial-based experience to shed light on problems and solutions involved in such an approach. In this paper we describe our experience in developing tools to introduce a two-tiered model-based approach to the design of Ford Motor Company s automotive control systems, highlighting the principle challenges, and evaluating the effectiveness of our solutions for them.

Abstract: This paper is an experience report on a first attempt to develop and apply a new form of software: a fullservice testbed designed to evaluate alternative software dependability technologies, and to accelerate their maturation and transition into project use. The SCRover testbed includes not only the specifications, code, and hardware of a public safety robot, but also the package of instrumentation, scenario drivers, seeded defects, experimentation guidelines, and comparative effort and defect data needed to facilitate technology evaluation experiments. The SCRover testbed’s initial operational capability has been recently applied to evaluate two architecture definition languages (ADLs) and toolsets, Mae and AcmeStudio. The testbed evaluation showed (1) that the ADL-based toolsets were complementary and costeffective to apply to mission-critical systems; (2) that the testbed was cost-effective to use by researchers; and (3) that collaboration in testbed use by researchers and the Jet Propulsion Laboratory (JPL) project users resulted in actions to accelerate technology maturity and transition into project use. The evaluation also identified a number of lessons learned for improving the SCRover testbed, and for development and application of future technology evaluation testbeds.

Abstract: One of the challenging problems for software developers is guaranteeing that a system as built is consistent with its architectural design. This report describes a technique that uses automatically generated runtime observations of an executing system to construct an architec- tural view of the system. In this technique, mappings are developed that exploit regularities in system implementation and architectural style. These mappings describe how low-level sys- tem events can be interpreted as more abstract architectural operations. In addition, this report describes the current implementation of a tool, called DiscoTect, that uses these mappings, and it shows how DiscoTect can highlight inconsistencies between implementations and ar- chitectures. Furthermore, two case studies are provided that illustrate how DiscoTect works and how it can be applied to real-world systems.

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.