Software-based systems today are increasingly expected to dynamically self-adapt to accommodate resource variability, changing user needs, and system faults. Recent work uses closed-loop control based on external models to monitor and adapt system behavior at run time. Taking this externalized approach, the Rainbow framework we have developed uses software architectural models to dynamically monitor and adapt a running system. A key goal and primary challenge of this framework is to support the reuse of adaptation strategies and infrastructure across different systems. In this poster, we show that the separation of a generic adaptation infrastructure from system-specific adaptation knowledge makes this reuse possible. 1.

Architecture frameworks are methods used in architecture modeling. They provide a structured and systematic approach to designing systems. To date there has been little analysis on their roles in system and software engineering and if they are satisfactory. This study provides a model of understanding through analyzing the goals, inputs and outcomes of six Architecture Frameworks. It characterizes two classes of architecture frameworks and identifies some of their deficiencies. To overcome these deficiencies, we propose to use costs, benefits and risks for architecture analysis. We also propose a method to delineate architecture activities from detailed design activities. 1.

The artifacts constituting a software system are sometimes unnecessarily coupled with one another or may drift over time. As a result, support of software partitioning, recovery, and restructuring is often necessary. This paper presents studies on applying the numerical taxonomy clustering technique to software applications. The objective is to facilitate those activities just mentioned and to improve design, evaluation and evolution. Numerical taxonomy is mathematically simple and yet it is a useful mechanism for component clustering and software partitioning. The technique can be applied at various levels of abstraction or to different software life-cycle phases. We have applied the technique to: (1) software partitioning at the software architecture design phase; (2) grouping of components based on the source code to recover the software architecture in the reverse engineering process; (3) restructuring of a software to support evolution in the maintenance stage; and (4) improving cohesion and reducing coupling for source code. In this paper, we provide an introduction to the numerical taxonomy, discuss our experiences in applying the approach to various areas, and relate the technique to the context of similar work.

This paper discusses a base UML profile for architecture description as supported by existing Architecture Description Languages (ADLs). The profile may be extended so as to enable architecture modeling both as expressed in conventional ADLs and according to existing runtime infrastructures (e.g., system based on middleware architectures). 1

. In this paper, we give our view on the software architecture phase in the development process. During this phase, we distinguish modeling and structuring activities. A system is modeled according to a certain approach, and this model is used to instantiate a certain architectural style. In general, the activities are intertwined. The choice for a certain software architecture has implications on the nonfunctional properties of the system. We illustrate our view with a case study of a software controller for a (toy) railroad system which we have available in our software lab. Several models of this system, expressed in formal specification languages, were made in the past, so we are able to produce a software architecture for the system while carrying out both activities separately. The resulting software architectures are evaluated with respect to timing aspects, scalability, fault-tolerance, and extendibility. Extendibility of a software system is especially important for domains we...

Architectural mismatch occurs when two or more software components are connected to form a system and those components make differing and incompatible assumptions about their interactions or the environment in which they exist. The biggest question relating to this is what are the assumptions a component can make and how can we make them explicit. We believe that architectural styles have much to offer in this respect as they can provide a vocabulary of architectural elements and paremeters for the architect to follow and constraints to check the validity of the values and system configuration. In this paper we lay the groundings for our work in detecting architectural mismatches between web services by generating a minimal web service architectural style, where minimal refers to a component that adopts the minimum set of specifications required to be considered a web service. First we look at web services informally, then summarise the findings before showing how the resulting elements and constraints were implemented in the architectural description language Acme. We then show how this style can help detect mismatches in the Acme Studio tool with a simple example.

Despite considerable attention paid on software architecture, the organizational aspects of architecture design remain largely unexplored. This study analyses the stakeholders participating in architecture design in three software companies, their problems in relation to architecture, and the rationale for architecture description they emphasize. This qualitative, grounded-theory-based, study shows how the stakeholders' rationales for describing architecture exceed the plain programming-in-the-large metaphor, emphasizing such issues as organizational communication, and knowledge creation and management. Whereas designers alone highlighted architecture as the basis for further design and implementation, the other stakeholders emphasized architecture mostly as a means for communication, interpretation, and decision-making. The results suggest a need for further research on practices and tools for effective communication and collaboration among the varying stakeholders of the architecture design process.

With Serviceflow Management we put the service nature of inter-organizational processes into the center of modeling, design and architectures. The underlying conceptual distinction between the serviceflow, the portion of the process where the customers concern is evaluated and cared for, and background processes, guides in (1) providers as well as designers to focus on service design and delivery, (2) to provide support for serviceflows with enhanced flexibility and service configuration and (3) to design service points where service workers and customers meet. By this, the original workflow metaphor, which directs the design of process support from a mass production point of view, is questioned and replaced by a more suitable concept, which considers social and quality aspects in service delivery.

www.elsevier.com/locate/datak

A design pattern is a grouping of a small number of objects that is likely to be useful again and again. In multi-threaded software, it is a grouping of active and passive objects. A pattern language is a system of patterns organized in a structure that guides their application. This paper proposes a pattern language intended to capture the best practices in the architectural design of multi-threaded software. The language consists of a number of well-known patterns and is intended to be sufficient for a class of applications. It enforces a restrictive use of threads and an intuitive architecture based on concurrency in the problem domain.