Our approach to creating self-healing systems is based on software architecture, where repairs are done at the level of a software system’s components and connectors. In our approach, event-based software architectures are targeted because they offer significant benefits for run-time adaptation. Before an automated planning agent can decide how to repair a self-healing system, a significant infrastructure must be in place to support making the planned repair. Specifically, the self-healing system must be built using a framework that allows for run-time adaptation, there must be a language in which to express the repair plan, and there must be a reconfiguration agent that can execute the repair plan once it is created. In this paper, we present tools and methods that implement these infrastructure elements in the context of an overall architecture-based vision for building self-healing systems. The paper concludes with a gap analysis of our current infrastructure vs. the overall vision, and our plans for fulfilling that vision. 1.

Most applications developed today rely on a given middleware platform which governs the interaction between components, the access to resources, etc. To decide, which platform is suitable for a given application (or more generally, to understand the interaction between application and platform) , we propose UML models of both the architectural style of the platform and the application scenario. Based on a formal interpretation of these as graphs and graph transformation systems, we are able to validate the consistency between platform and application.

We have developed an infrastructure for end-to-end run-time monitoring, behavior / performance analysis, and dynamic adaptation of distributed software applications. This feedback-loop infrastructure is primarily targeted to pre-existing systems and thus operates outside the application itself without making assumptions about the target system's internal communication/computation mechanisms, implementation language/framework, availability of source code, etc. This paper assumes the existence of the monitoring and analysis components, presented elsewhere, and focuses on the mechanisms used to control and coordinate possibly complex repairs/reconfigurations to the target system. These mechanisms require lower-level actuators or effectors somehow attached to the target system, so we briefly sketch one such facility (elaborated elsewhere). The core of the paper is the model, architecture, and implementation of Workflakes, the decentralized process engine we use to tailor, control, coordinate, respond to contingencies, etc. regarding a cohort of such actuators. We have validated our approach and the Workflakes prototype in several case studies, related to different application domains. Due to space restrictions we concentrate primarily on one case study, elaborate with some detais a second, and only sketch others.

Existing approaches to differencing and merging architectural views are based on restrictive assumptions such as requiring view elements to have unique identifiers or exactly matching types.

Autonomic Computing is a concept that brings together many fields of computing with the purpose of creating computing systems that self-manage. In its early days it was criticised as being a “hype topic” or a rebadging of some Multi Agent Systems work. In this survey, we hope to show that this was not indeed ’hype ’ and that, though it draws on much work already carried out by the Computer Science and Control communities, its innovation is strong and lies in its robust application to the specific self-management of computing systems. To this end, we first provide an introduction to the motivation and concepts of autonomic computing and describe some research that has been seen as seminal in influencing a large proportion of early work. Taking the components of an established reference model in turn, we discuss the works that have provided significant contributions to that area. We then look at larger scaled systems that compose autonomic systems illustrating the hierarchical nature of their architectures. Autonomicity is not a well defined subject and as such different systems adhere to different degrees of Autonomicity, therefore we cross-slice the body of work in terms of these degrees. From this we list the key applications of autonomic computing and discuss the research work that is missing and what we believe the community should be considering.

In this paper, the authors share their experience gathered during the design and implementation of a runtime environment for the SOFA component system. The authors focus on the issues of mapping the SOFA component definition language into the C++ language and the integration of a CORBA middleware into the SOFA component system, aiming to support transparently distributed applications in a real-life environment. The experience highlights general problems related to the type system of architecture description languages and middleware implementations, the mapping of the type system into the implementation language, and the support for dynamic changes of the application architecture.

The use of product lines is recognized as beneficial in promoting and structuring both component and architecture reuse throughout an organization. While the business practices of using product lines are well-understood and representations for specifying and capturing the underlying architecture of a product line are coming of age, support environments for managing the evolution of a product line architecture are still lacking. In this paper, we present Mnage, an environment specifically designed to alleviate this problem. Key features of Mnage are its support for: (1) specifying variation points in a product line architecture as optional and/or variant elements, (2) tracking the evolution of a product line architecture and its constituent elements through explicit versioning techniques, and (3) selecting one or more product architectures out of an overall product line architecture by applying user-specified criteria. In this paper, we introduce the approach underlying Mnage, discuss its detailed functionality, and demonstrate its use with a product line architecture for entertainment systems.

Like source code, architectures change. The use of product line architectures provides a particularly rich source of changes: new products are introduced, existing products are enhanced and modified, and old products are retired.

Abstract. The topic of software architecture (SA) based testing has recently raised some interest. Recent work on the topic has used the SA as a reference model for code conformance testing, to check if an implementation fulfills (conforms to) its specification at the SA level. In this context, on previous papers, we have analyzed: i) how suitable test cases can be “selected ” from the SA specification and ii) how they may be “refined ” into concrete tests executable at the code level. While the selection stage has been done systematically, the refinement step has been left to be done manually, based on the software engineer knowledge on how to map “abstract values of the specification to the concrete values of the implementation”. In this paper, we extend previous approaches, by providing a systematic way to perform the refinement step. We show how choosing a specific architectural style, which supports implementation and facilitates the mapping among SA-based and code-based test cases, a completely systematic SA-based testing approach can be delivered. 1

Abstract. SAs provide a high-level model of large, complex systems using suitable abstractions of the system components and their interactions. SA dynamic descriptions can be usefully employed in testing and analysis. We describe here an approach for SA-based conformance testing: architectural tests are selected from a Labelled Transition System (LTS) representing the SA behavior and are then refined into concrete tests to be executed on the implemented system. To identify the test sequences, we derive abstract views of the LTS, called the ALTSs, to focus on relevant classes of architectural behaviors and hide away uninteresting interactions. The SA description of a Collaborative Writing system is used as an example of application. We also briefly discuss the relation of our approach with some recent research in exploiting the standard UML notation as an Architectural Description Language, and in conformance testing of reactive systems. 1