This paper presents two strategies for supporting architectural concerns within UML. One strategy involves using UML "as is," while the other incorporates useful features of existing ADLs as UML extensions. We discuss the applicability, strengths, and weaknesses of the two strategies. The strategies are applied on three ADLs that, as a whole, represent a broad cross-section of present-day ADL capabilities. One conclusion of our work is that UML currently lacks support for capturing and exploiting certain architectural concerns whose importance has been demonstrated through the research and practice of software architectures. In particular, UML lacks direct support for modeling and exploiting architectural styles, explicit software connectors, and local and global architectural constraints

Over the past decade, software architecture research has emerged as the principled study of the overall structure of software systems, especially the relations among subsystems and components. From its roots in qualitative descriptions of useful system organizations, software architecture has matured to encompass broad explorations of notations, tools, and analysis techniques. Whereas initially the research area interpreted software practice, it now offers concrete guidance for complex software design and development. We can understand the evolution and prospects of software architecture research by examining the research paradigms used to establish its results. These are, for the most part, the paradigms of software engineering. We advance our fundamental understanding by posing research questions of several kinds and applying appropriate research techniques, which differ from one type of problem to another, yield correspondingly different kinds of results, and require different methods of validation. Unfortunately, these paradigms are not recognized explicitly and are often not carried out correctly; indeed not all are consistently accepted as valid. This retrospective on a decade-plus of software architecture research examines the maturation of the software architecture research area by tracing the types of research questions and techniques used at various stages. We will see how early qualitative results set the stage for later precision, formality, and automation and how results build up over time. This generates advice to the field and projections about future impact. Keywords: Software architecture, research paradigms 1.

Modifiability is an important quality for software systems, because a large part of the costs associated with these systems is spent on modifications. The effort, and therefore cost, that is required for these modifications is largely determined by a system's software architecture. Analysis of software architectures is therefore an important technique to achieve modifiability and reduce maintenance costs. However, few techniques for software architecture analysis currently exist. Based on our experiences with software architecture analysis of modifiability, we have developed ALMA, an architecture-level modifiability analysis method consisting of five steps. In this paper we report on our experiences with ALMA. We illustrate our experiences with examples from two case studies of software architecture analysis of modifiability. These case studies concern a system for mobile positioning at Ericsson Software Technology AB and a system for freight handling at DFDS Fraktarna. Our experiences are related to each step of the analysis process. In addition, we made some observations on software architecture analysis of modifiability in general.

Architecting distributed software applications is a complex design activity. It involves making decisions about a number of inter-dependent design choices that relate to a range of design concerns. Each decision requires selecting among a number of alternatives; each of which impacts differently on various quality attributes. Additionally, there are usually a number of stakeholders participating in the decision-making process with different, often conflicting, quality goals, and project constraints, such as cost and schedule. To facilitate the architectural design process, we propose a quantitative quality-driven approach that attempts to find the best possible fit between conflicting stakeholders ' quality goals, competing architectural concerns, and project constraints. The approach uses optimization techniques to recommend the optimal candidate architecture. Applicability of the proposed approach is assessed using a real system. 1.

Service-oriented architectures (SOA) provide a flexible and dynamic platform for implementing business solutions. In this paper, we address the modeling of such architectures by refining business-oriented architectures, which abstract from technology aspects, into service-oriented ones, focusing on the ability of dynamic reconfiguration (binding to new services at runtime) typical for SOA. The refinement is based on conceptual models of the platforms involved as architectural styles, formalized by graph transformation systems. Based on a refinement relation between abstract and platform-specific styles we investigate how to realize business-specific scenarios on the SOA platform by automatically deriving refined, SOA-specific reconfiguration scenarios.

This paper presents a framework for architecture alignment that can be positioned between approaches for software architecture, which concern software artefacts only, and strategic alignment models, which have a business focus. The framework is currently applied in case study research to find alignment patterns used in practice. First results presented in this paper indicate that the framework might yield an operationalization of strategic architecture alignment models. We also present an alignment pattern found that shows a difference between how architectures are designed at the application level and the infrastructure level. We think this difference is significant for practical alignment models.

Abstract: The available evidence in a legacy software system, which can help in its understanding and recovery of its architecture are not always sufficient. Very often the system’s documentation is poor and outdated. One may argue that the most reliable resource of information is the system’s source code. Nevertheless a significant knowledge about the problem domain is required in order to facilitate the extraction of the system’s useful architectural information. In this approach feature modeling is introduced as an additional step in a system’s architectural recovery process. Feature modeling structures the system’s functionality and supports reverse engineering by detecting the relations between source code elements and requirements. Tracing these relations may lead to a better understanding of the program’s behavior and the recovery of various architectural elements. In this way, by providing a mapping between source code and features, the system’s feature model supports program comprehension and architectural recovery. The approach is developed as first part of a migration methodology towards a component-based architecture of legacy systems. Recovered information about features and architecture is collected in a repository to enable a refactoring as next step. The approach is currently applied in a large project for reengineering of an industrial Image Processing System.

Software architecture is generally regarded as an important tool to achieve systems of higher quality. It is claimed that the foundation for a system's quality is laid by the decisions made in the software architecture. A question that is occupying both researchers and practitioners is in which areas should decisions be made in the software architecture? We believe architectural view models play an important role in the answer to this question. View models consist of a coherent set of architectural views. These view models have both a prescriptive and a descriptive role in the development process. Their prescriptive role is that they call for a number of aspects to be considered when defining a software architecture and their descriptive role is that they provide a framework to document a software architecture. Currently, a number of view models exist, the most important of which are the 4+1 View Model of Kruchten and the four views by Soni et al. In our experience with modif...

This project was sponsored by Technologiestichting STW and conducted within the

Introduction The summary of the First International Workshop on CBSE [BrWa98] contains the following definitions of a software component: 1. A component is a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component conforms to and provides the physical realization of a set of interfaces. 2. A run-time software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at run-time. 3. A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party. 4. A Business Component represents the software implementation of an "autonomous" business concept or business process. It consists of all the software artifacts ne