Article Experience with performing architecture tradeoff analysis Share on Authors: Rick Kazman Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PAView Profile , Mario Barbacci Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PAView Profile , Mark Klein Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PAView Profile , S. Jeromy Carrière Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PAView Profile , Steven G. Woods Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PAView Profile Authors Info & Claims ICSE '99: Proceedings of the 21st international conference on Software engineeringMay 1999 Pages 54–63https://doi.org/10.1145/302405.302452Online:16 May 1999Publication History 103citation1,056DownloadsMetricsTotal Citations103Total Downloads1,056Last 12 Months16Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

This paper presents the Architecture Tradeoff Analysis Method (ATAM), a structured technique for understanding the tradeoffs inherent in the architectures of software-intensive systems. This method was developed to provide a principled way to evaluate a software architecture's fitness with respect to multiple competing quality attributes: modifiability, security, performance, availability, and so forth. These attributes interact-improving one often comes at the price of worsening one or more of the others-as is shown in the paper, and the method helps us to reason about architectural decisions that affect quality attribute interactions. The ATAM is a spiral model of design: one of postulating candidate architectures followed by analysis and risk mitigation, leading to refined architectures.

Software specification, modeling and prototyping activities are often performed at different stages in a software development project by individuals who use different specialized notations. The recent development of commercial executable specification tools represents a potential semi-automated link between specification, modeling and prototyping activities. Unfortunately, these tools can be inadequate for analyzing the performance of complex real-time systems. These problems are largely due to the fact that the formalisms upon which most executable specification tools are based represent too high a level of abstraction. The authors feel that to effectively link specification, modeling, and prototyping activities, integration must occur at the level of a technical architecture. They believe that Durra currently under development can provide this integration. Durra is a non-procedural language designed to support the development of distributed applications consisting of multiple, concurrent large-grained tasks executing in a heterogeneous network. Durra provides a framework through which one can specify the structure of an application in conjunction with its behavior, timing and implementation dependencies.>

The use of a declarative language, called Dura, designed to support application-level programming is illustrated by distributed avionics system. The authors show how the language is used to describe the application, its components and structure; how the run-time executive provides support for fault-tolerance by reconfiguration of the application; and how an interactive interface to the executive supports debugging and monitoring of the application.>

The description of structural aspects of a digital system presents certain requirements that are not covered by the semantics of ISPS or other behavioural description languages. To this end we have designed and implemented a specialised language based on the PMS level of design first introduced by Bell and Newell. The PMS notation described in this paper allows the specification of instances of components, their interconnections, and the validation of these interconnections. The notation blends easily with ISPS, and systems described in PMS can incorporate ISPS description of components whose structural aspects are to remain hidden or unspecified. To illustrate the use of both notations in the description of a complex system, we describe a computer consisting of a central processor, memory units, and peripheral units, connected through a DEC PEP-11 UNIBUS.

The Instruction Set Processor Specifications (ISPS) computer description language is an evolutionary step towards the formalization of the digital design process at the higher or behavioral levels. It has been used as a design tool, which covers a wider area of application than any other hardware description language. Thus, besides simulation and synthesis of hardware, software generation program verification, and architecture evaluation and control are among the current applications based on ISPS. The range of current and contemplated application areas are proof of the usefulness of the notation and its extension mechanisms. ISPS supports a wide range of applications, rather than a wide range of design levels. Thus, this paper is divided into two parts. The first part describes the notation, its intended use, and the extension mechanisms which allow multiple applications or areas of research to co-exit and share machine descriptions. The second part describes some of the current applications for ISPS.

The microprogrammed filter engine (MICE) is a fast, microprogrammable processor built with ECL bit slices (Motorola ECL 10800 series) intended primarily to be used as an on-line data filtering engine for high energy physics experiments. In this note we describe the use of a hardware description language used to model and simulate the hardware during its development. We treat the problem of describing a pipelined, horizontal (112 bits wide) host machine, implemented using bit slices with considerable potential for parallelism. Several levels of modeling are conceptually applicable to a problem of this nature and the note describes the thorough process followed before we decided on a particular style of description and simulation.

Different notations have been proposed over the years to describe register transfer (RT) systems. They have met with varying degrees of success and to provide a direct comparison of them is a difficult task. One of the reasons for this is the different views of the RT level of design held by the proponents of the languages.

A Design Automation System for the RT level of design is described. The System explores the design space by finding alternative implementations for a user given behavioral specification. The alternative solutions are obtained by transformations on a graph model. These transformations effect trade-offs between the cost of the hardware and the speed of the algorithm. Heuristic routines are used to reduce the design space by exploring only those alternatives whose characteristics approach a user given set of goals.