Software architecture analysis methods aim to predict the quality of a system before it has been developed. In general, the quality of the architecture is validated by analyzing the impact of predefined scenarios on architectural components. Hereby, it is implicitly assumed that an appropriate refactoring of the architecture design can help in coping with critical scenarios and mending the architecture. This paper shows that there are also concerns at the architecture design level which inherently crosscut multiple architectural components, which cannot be localized in one architectural component and which, as such, can not be easily managed by using conventional abstraction mechanisms. We propose the aspectual Software Architecture Analysis Method (ASAAM) with the aim to explicitly identify and specify these architectural aspects and make these transparent early in the software development life cycle. ASAAM introduces a set of heuristic rules that help to derive architectural aspects and the corresponding tangled architectural components from scenarios. The approach is illustrated for architectural aspect identification in the architecture design of a window management system.

Software architecture evaluation has been proposed as a means to achieve quality attributes such as maintainability and reliability in a system. The objective of the evaluation is to assess whether or not the architecture will lead to the desired quality attributes. Recently, there have been a number of evaluation methods proposed. There is, however, little consensus on the technical and non-technical issues that a method should comprehensively address and which of the existing methods is most suitable for a particular issue. This paper presents a set of commonly known but informally described features of an evaluation method and organizes them within a framework that should offer guidance on the choice of the most appropriate method for an evaluation exercise. In this paper, we use this framework to characterise eight SA evaluation methods.

Abstract. For two years, we have been involved in a challenging project to develop a new architecture for an industrial transportation system. The motivating quality attributes to develop this innovative architecture were flexibility and openness. Taking these quality attributes into account, we proposed a decentralized architecture using multiagent systems (MASs). A MAS consists of multiple autonomous entities that coordinate with each other to achieve decentralized control. The typical advantages attributed to such decentralized architecture are flexibility and openness, the motivating quality attributes to apply MAS in this case. The Architecture Tradeoff Analysis Method (ATAM) was used to provide insights wether our architecture meets the expected flexibility and openness, and to identify tradeoffs with other quality attributes. Applying the ATAM proved to be a valuable experience. One of the main outcome of applying the ATAM was the identification of a tradeoff between flexibility and communication load that results from the use of a decentralized architecture. This paper describes our experiences in applying the ATAM to a MAS architecture, containing both the main outcomes of the evaluation and a critical reflection on the ATAM itself. 1

We compare five industrial software architecture design methods and we extract from their commonalities a general software architecture design approach. Using this general approach, we compare across the five methods the artifacts and activities they use or recommend, and we pinpoint similarities and differences. Once we get beyond the great variance in terminology and description, we find that the 5 approaches have a lot in common and match more or less the “ideal ” pattern we introduced. 1.

Modular system architectures, such as integrated modular avionics (IMA) in the aerospace sector, offer potential benefits of improved flexibility in function allocation, reduced development costs and improved maintainability. However, they require a new certification approach. The traditional approach to certification is to prepare monolithic safety cases as bespoke developments for a specific system in a fixed configuration. However, this nullifies the benefits of flexibility and reduced rework claimed of IMA-based systems and will necessitate the development of new safety cases for all possible (current and future) configurations of the architecture. This paper discusses a modular approach to safety case construction, whereby the safety case is partitioned into separable arguments of safety corresponding with the components of the system architecture. Such an approach relies upon properties of the IMA system architecture (such as segregation and location independence) having been established. The paper describes how such properties can be assessed to show that they are met and trade-offs performed during architecture definition reusing information and techniques from the safety argument process.

ICT has become a key business enabler and a competitive factor for enterprises. Enterprise architecture, developed by ICT consultants and ICT end-user organizations, is emerging as the management tool for intertwined business and IT planning. For managerial decisions, there is a need to evaluate the business value of architecture development results, but only a few models for this have so far been presented. Here we present the V-model for EA testing and validation that marks the evaluation points in EA management, and guides which evaluation tools could be used. 1.

Abstract — One might expect that after nearly 50 years of research in robot manipulation and mobile robotics the architectural design of robot systems has converged to a small set of best practice solutions, very much like in the area of operating systems, where the world is dominated by less then a handful systems. Quite the opposite is the case. It is only a small overstatement to say that almost every lab has brewed its own solution for robot control architecture, middleware and software integration concepts. One reason for this situation is the fact that the complexity and variety of systems and applications has grown considerably since then leading to a diversity of approaches. Another reason is clearly the lack of any sound methodology to measures and compare architectural designs. This article tries to address the problem by proposing a comparison and evaluation methodology for robotics software systems. The methodology facilitates an assessment of software systems through experimentation and takes into account the possible operational profile and quality attribute requirements of the robotic application. The approach is validated through the evaluation of three software systems, i.e. GenoM, ORCA2 and GO. The results suggest possible applicability domains of each system and show the efficiency of the approach. I.

Software engineering community has proposed several methods to evaluate software architectures with respect to desired quality attributes such as maintainability, performance, and so on. There is, however, little effort on systematically comparing such methods to discover similarities and differences between existing approaches. In this paper, we compare four well known scenario-based SA evaluation methods using an evaluation framework. The framework considers each method from the point of view of method context, stakeholders, structure, and reliability. The comparison reveals that most of the studied methods are structurally similar but there are a number of differences among their activities and techniques. Therefore, some methods overlap, which guides us to identify five common activities that can form a generic process model.

Abstract. There is a recognized gap between requirements and architectures. There is also evidence that architecture evaluation, when done at the early phases of the development lifecycle, is an effective way to ensure the quality attributes of the final system. As quality attributes may be satisfied at a different extent by different alternative architectural solutions, an exploration and evaluation of alternatives is often needed. In order to address this issue at the requirements level, we propose to model architectures using the i * framework, a goal-oriented modelling language that allows to represent the functional and non-functional requirements of an architecture using actors and dependencies instead of components and connectors. Once the architectures are modelled, we propose guidelines for the generation of alternative architectures based upon existing architectural patterns, and for the definition of structural metrics for the evaluation of the resulting alternative models. The applicability of the approach is shown with the Home Service Robot case study. 1

Abstract. Software architecture (SA) evaluation is a quality assurance technique that is increasingly attracting significant research and commercial interests. A number of SA evaluation methods have been developed. Most of these methods are scenario-based, which relies on the quality of the scenarios used for the evaluation. Most of the existing techniques for developing scenarios use stakeholders and requirements documents as main sources of collecting scenarios. Recently, architectures of large software systems are usually composed of patterns and styles. One of the purposes of using patterns is to develop systems with predictable quality attributes. Since patterns are documented in a format that requires the inclusion of problem, solution and quality consequences, we observed that scenarios are, though as informal text, pervasive in patterns description, which can be extracted and documented for the SA evaluation. Thus, we claim that the patterns can be another source of collecting quality attributes sensitive scenarios. This position paper presents arguments and examples to support our claim. 1