In an increasing number of domains software is now required to be self-adapting and self-healing. While in the past such abilities were incorporated into software on a per system basis, proliferation of such systems calls for more generalized mechanisms to manage dynamic adaptation. General mechanisms have the advantage that they can be reused in numerous systems, analyzed separately from the system being adapted, and easily changed to incorporate new adaptations. Moreover, they provide a natural home for encoding the expertise of system designers and implementers about adaptation strategies and policies. In this paper, we show how current software architecture tools can be extended to provide such generalized dynamic adaptation mechanisms.

The end of the tunnel is actually here! Now is the time to start the next stage, and I would like to do so by first recognizing the people that made the difference throughout my Ph.D. study years. First and foremost I must thank Nauro, my better half, for always being there, making it all possible and worthwhile. This whole process has brought us even closer. Both of our families deserve recognition for caring, cheering, and trying to understand the various stages involved. Barry Boehm, my advisor, has been a very special person to me. Not only has he supported me throughout the years, mentoring me when I needed, but he has also been a good friend. I deeply appreciate that. My committee members Dave Wile and Eb Rechtin must also be acknowledged. I must thank Dave for his deep involvement, actually bringing up new ideas and helping me evolve them, as well as for the occasional pub stops during various workshops. Dr. Rechtin was probably the most involved and knowledgeable outside committee member in history. He not only devoted his time to reading the material I gave him, but always

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—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 runtime observations about an executing system to construct an architectural view of the system. In 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 and are formally defined using Colored Petri Nets. In this paper, we describe a system, called DiscoTect, that uses these mappings and we introduce the DiscoSTEP mapping language and its formal definition. Two case studies showing the application of DiscoTect suggest that the tool is practical to apply to legacy systems and can dynamically verify conformance to a preexisting architectural specification. Index Terms—Software architecture discovery, reverse engineering, architecture design tools and analyses. Ç

Abstract not found

Service-discovery systems aim to provide consistent views of distributed components under varying network conditions. To achieve this aim, designers rely upon a variety of self-healing strategies, including: architecture and topology, failure-detection and recovery techniques, and consistency maintenance mechanisms. In previous work, we showed that various combinations of self-healing strategies lead to significant differences in the ability of service-discovery systems to maintain consistency during increasing network failure. Here, we ask whether the contribution of individual self-healing strategies can be quantified. We give results that quantify the effectiveness of selected combinations of architecture-topology and recovery techniques. Our results suggest that it should prove feasible to quantify the ability of individual self-healing strategies to overcome various failures. A full understanding of the interactions among self-healing strategies would provide designers of distributed systems with the knowledge necessary to build the most effective self-healing systems with minimum overhead.

Abstract. Current trends suggest future software systems will comprise collections of components that combine and recombine dynamically in reaction to changing conditions. Service-discovery protocols, which enable software components to locate available software services and to adapt to changing system topology, provide one foundation for such dynamic behavior. Emerging discovery protocols specify alternative architectures and behaviors, which motivate a rigorous investigation of the properties underlying their designs. Here, we assess the ability of selected designs for service-discovery protocols to maintain consistency in a distributed system during catastrophic communication failure. We use an architectural-description language, called Rapide, to model two different architectures (two-party and three-party) and two different consistency-maintenance mechanisms (polling and notification). We use our models to investigate performance differences among combinations of architecture and consistencymaintenance mechanism as interface-failure rate increases. We measure system performance along three dimensions: (1) update responsiveness (How much latency is required to propagate changes?), (2) update effectiveness (What is the probability that a node receives a change?), and (3) update efficiency (How many messages must be sent to propagate a change throughout the topology?). We use Rapide to understand how failure-recovery strategies contribute to differences in performance. We also recommend improvements to architectural-description languages.

Current trends suggest that future software systems may appear as collections of distributed components that combine and recombine dynamically in response to changing conditions. Such dynamic environments will require new analysis approaches and tools for software design. In this paper, we investigate an architecturebased approach to evaluate and compare designs for service discovery protocols operating under network and node failures. We elaborate our approach, using Jini as a specific example, and show how Jini can be analyzed using Rapide, an Architecture Description Language (ADL). Our analyses take two forms: property analysis and event analysis. We use property analysis to investigate robustness to dynamic change, while we use event analysis to discern underlying causes of observed behavior and performance. We evaluate how well Rapide supported our modeling and analyses. We also recommend improvements in ADLs to help test and analyze designs for distributed systems.

A dynamic system is one that changes its configuration as it runs. It is a system into which we can drop new components that then cooperate with the existing ones. We are concerned with formally defining architectures for such systems and with realistically validating designs for applications that run on those architectures. We describe a generic architecture based on the familiar registry services of CORBA, DCOM and Jini. We illustrate this architecture by formally describing a simple point-of-sale system built according to this architecture. We then look at the sorts of global properties that a designer of applications would wish a robust system to have and discuss variations on the architecture which make validation of applications more practical. Keywords Architecture Modelling, Dynamic Systems, Reconfigurable Systems, Formal Models, Validation 1

Many tools and techniques are available to help understand and analyze a system at the architectural level. Each of these provides its own perspective of the key architectural elements of the system. We introduce the process of architectural synthesis to deal with the problem of integrating these different architectural perspectives. The four steps of the synthesis process form an iterative cycle and include acquiring different perspectives (extraction), grouping related perspectives (classification) , combining all perspectives that apply to the same architectural view (union), and finally composing views to determine consistency (fusion). We apply the synthesis process to the architecture of a software visualization tool. Our preliminary investigation shows that synthesized architectural perspectives provide a more complete and consistent representation of a real system. We conclude with directions for future research in this area. 1. Introduction Although the exact percentage vari...