Code-based metrics such as coupling and cohesion are used to measure a system’s structural complexity. But dealing with large systems—those consisting of several millions of lines — at the code level faces many problems. An alternative approach is to concentrate on the system’s building blocks such as programs or modules as the unit of examination. We present an approach that uses information in a release history of a system to uncover logical dependencies and change patterns among modules. We have developed the approach by working with 20 releases of a large Telecommunications Switching System. We use release information such as version numbers of programs, modules, and subsystems together with change reports to discover common change behavior (i.e. change patterns) of modules. Our approach identifies logical coupling among modules in such a way that potential structural shortcomings can be identified and further examined, pointing to restructuring or reengineering opportunities. 1

Abstract: Software architecture is one of the most important tools for designing and understanding a system, whether that system is in preliminary design, active deployment, or maintenance. Scenarios are important tools for exercising an architecture in order to gain information about a system’s fitness with respect to a set of desired quality attributes. This paper presents an experiential case study illustrating the methodological use of scenarios to gain architecture-level understanding and predictive insight into large, real-world systems in various domains. A structured method for scenario-based architectural analysis is presented, using scenarios to analyze architectures with respect to achieving quality attributes. Finally, lessons and morals are presented, drawn from the growing body of experience in applying scenario-based architectural analysis techniques.

vii 1 Introduction 1 1.1 What is the Purpose of the ATAM? 2 2 The Underlying Concepts 5 3 A Brief Introduction to the ATAM 7 4 Quality Attribute Characterizations 9 5 Scenarios 13 5.1 Types of Scenarios 13 5.2 Eliciting and Prioritizing Scenarios 16 5.3 Utility Trees 16 5.4 Scenario Brainstorming 18 6 Attribute-Based Architectural Styles 19 7 Outputs of the ATAM 21 7.1 Risks and Non-Risks 21 7.2 Sensitivity and Tradeoff Points 22 7.3 A Structure for Reasoning 23 7.4 Producing ATAM's Outputs 23 8 The Steps of the ATAM 25 8.1 Step 1 - Present the ATAM 25 8.2 Step 2 - Present Business Drivers 26 8.3 Step 3 - Present Architecture 27 8.4 Step 4 - Identify Architecture Approaches 29 8.5 Step 5 - Generate Quality Attribute Utility Tree 29 ii CMU/SEI-2000-TR-004 8.6 Step 6 - Analyze Architecture Approaches 29 8.7 Step 7 - Brainstorm and Prioritize Scenarios 33 8.8 Step 8 - Analyze Architecture Approaches 36 8.9 Step 9 - Present Results 37 9 The Two Phases of ATAM 39 9.1 Phase 1 Activit...

AbstractÐThe purpose of the architecture evaluation of a software system is to analyze the architecture to identify potential risks and to verify that the quality requirements have been addressed in the design. This survey shows the state of the research at this moment, in this domain, by presenting and discussing eight of the most representative architecture analysis methods. The selection of the studied methods tries to cover as many particular views of objective reflections as possible to be derived from the general goal. The role of the discussion is to offer guidelines related to the use of the most suitable method for an architecture assessment process. We will concentrate on discovering similarities and differences between these eight available methods by making classifications, comparisons and appropriateness studies. Index TermsÐSoftware architecture, analysis techniques and methods, quality attributes, scenarios. 1

Understanding the architecture of a program requires determining both the major components into which the system is broken and the ways in which the components interact to accomplish the program’s goals. Both static and dynamic analyses of the software can aid in obtaining this understanding. This paper describes an analysis technique for gaining such understanding and a visualization tool, called ISVis, that supports it. The technique is applied to the problem of enhancing the Mosaic web browser by both visualizing its architecture and finding the components of the browser into which an enhancement should be inserted.

Large software systems evolve slowly but constantly. In this paper we examine the structure of several releases of a telecommunication switching system (TSS) based on information stored in a database of product releases. We tracked the historical evolution of the TSS structure and related the adaptations made (e.g. addition of new features, etc.) to the structure of the system. Such a systematic examination can uncover potential shortcomings in the structure of the system and identify modules or subsystems that should be subject to restructuring or reengineering. Further, we have identified additional information that would be useful for such investigations but is currently lacking in the database.

Since the architecture of a software system constrains the non-functional requirements, the decisions taken during architectural design have a large impact in the resulting system. An architectural design method is presented that employs iterative evaluation and transformation of the software architecture in order to satisfy the nonfunctional requirements (NFRs). Architecture evaluation is performed by using scenarios, simulation, mathematical modelling and reasoning. The architecture can be transformed by imposing an architectural style, imposing an architectural pattern, using a design pattern, converting an NFR to functionality and by distributing NFRs. The method has, in various forms, been applied in several industrial projects. Keywords Software architecture design, non-functional

“No scene from prehistory is quite so vivid as that of the mortal struggles of great beasts in the tar pits... Large system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it... “Everyone seems to have been surprised by the stickiness of the problem, and it is

Abstract: Changes to a software system during implementation and maintenance can cause the architecture of a system to deviate from its documented architecture. If design documents are to be useful, maintenance programmers must be able to easily evaluate how closely the documents conform to the code they are meant to describe. Software architecture recovery, which deals with the extraction and analysis of a system’s architecture, has gained more tool support in the past few years. However, there is little research on developing effective and efficient architectural conformance methods. In particular, given the increasing emphasis on patterns and styles in the software engineering community, a method needs to explicitly aid a user in identifying architectural patterns. This paper presents a semi-automatic method, called ARM (Architecture Reconstruction Method), that guides a user in the reconstruction of software architectures based on the recognition of patterns. Once the system’s actual architecture has been reconstructed, we can analyze conformance of the software to the documented design patterns. 1.

Non-functional requirements, such as modifiability, performance, reusability, comprehensibility and security, are often crucial to a software system. As such, these non-functional requirements (or NFRs) should be addressed as early as possible in a software lifecycle and properly reflected in a software architecture before committing to a detailed design. The purpose of this paper is to discuss how the treatment of NFRs as goals (which may be synergistic or conflicting) serves to systematically guide selection among architectural design alternatives. During the architectural design process, goals are decomposed, design alternatives are analysed with respect to their tradeoffs, design decisions are made rationalised, and goal achievement is evaluated. This process can be supported by by a body of organised knowledge. This paper outlines an approach by which such knowledge can be organized. This approach is illustrated by a preliminary study of architectural design for a KWIC (Key Word i...