Leonard J. Bass

Scenario-based analysis of software architecture

Despite advances in clarifying high level design needs, analyzing a systems ability to meet desired quality criteria is still difficult. The authors propose using scenarios to make analysis more straightforward. In their case study report, they analyze lessons learned with this approach. They developed the Software Architecture Analysis Method, an approach that uses scenarios to gain information about a systems ability to meet desired quality attributes. Scenarios are brief narratives of expected or anticipated system uses from both user and developer views and they provide a look at how the system satisfies quality attributes in various use contexts.

Managing variability in software architectures

This paper presents experience with explicitly managing variability within a software architecture. Software architects normally plan for change and put mechanisms in the architecture to support those changes. Understanding the situations where change has been planned for and recording the options possible within particular situations is usually not done explicitly. This becomes important if the architecture is used for many product versions over a long period or in a product line context where the architecture is used to build a variety of different products. That is, it is important to explicitly represent variation and indicate within the architecture locations for which change has been allowed. We will describe how the management of variations in an architecture can be made more explicit and how the use of variation points connected to the choices a customer has when ordering a product can help to navigate to the appropriate places in the architecture.

Linking usability to software architecture patterns through general scenarios

Usability is an important quality attribute to be considered during software architecture design. Up to this point, usability has been served only by separating a systems user interface from its functionality to support iterative design. However, this has the effect of pushing revisions to achieve usability toward the end of the software development life cycle. Many usability benefits link directly to a variety of architectural tactics in addition to separation of the user interface and these benefits can be discovered early in the life cycle. For each of 27 scenarios, we identified potential usability benefits a user could realize and an architectural pattern that supports achievement of those benefits. We organized the scenarios into an emergent hierarchy of potential benefits to the user and into an emergent hierarchy of architectural tactics used in the supporting patterns. The range of architectural tactics identified in this hierarchy demonstrates that separation is far from the only architectural tactic necessary to support usability. We present techniques that permit important usability issues to be addressed proactively at architecture design time instead of retroactively after user testing.

Attribute-Based Architecture Styles

Architectural styles have enjoyed widespread popularity in the past few years, and for good reason: they represent the distilled wisdom of many experienced architects and guide less experienced architects in designing their architectures. However, architectural styles employ qualitative reasoning to motivate when and under what conditions they should be used. In this paper we present the concept of an ABAS (Attribute-Based Architectural Style) which includes a set of components and connectors along with their topology, but which adds to this a quality attribute specific model that provides a method of reasoning about the behavior of component types that interact in the defined pattern. We will define ABASs in this paper, show how they are used, and argue for why this extension to the notion of architectural style is an important step toward creating a true engineering discipline of architectural design.

The design of a wearable computer

The design process used to produce an innovative computer system is presented. The computer system that resulted from the process uses a circular motif both for the user interface and the input device. The input device is a dial and the user interface is visually organized around the concept of a circle. The design process itself proceeded in the presence of a great many constraints and we discuss these constraints and how an innovative design was achieved in spite of the constraints.

Adtranz: a mobile computing system for maintenance and collaboration

The paper describes the mobile information and communication aspects of a next generation train maintenance and diagnosis system, discusses the working prototype features, and research results. Wearable/Mobile computers combined with the wireless technology improve efficiency and accuracy of the maintenance work. This technology enables maintenance personnel at the site to communicate with a remote helpdesk/expertise center through digital data, audio, and image.

Classifying architectural elements as a foundation for mechanism matching

Building a system at the architectural level can be thought of as decomposition into components followed by a series of exercises in matching. Components must be composed with each other via matching mechanisms; matching signatures within those mechanisms ensures that data and control flows through the system; and matching semantics among the components ensures that the system meets its behavioral requirements. The standard concepts of software architecture (components, connectors, styles) have been widely used with little more than intuitive understanding of their meaning. Mechanism matching is currently an ad hoc exercise that relies on the peculiarities of programming language facilities. This paper presents a set of well-known but informally described software architectural elements used in system composition, and taxonomizes them under a basic set of characteristic features. This classification allows us to describe legal combinations of architectural elements by performing a simple matching exercise on the relevant features of the member elements. This classification also allows us to identify architectural elements that can be substituted for each other and satisfy the same mechanism matching requirements. This leads to delayed binding of architectural mechanisms, which in turns provides increased flexibility and greater opportunities for reuse of units of computation.

Making architecture reviews work in the real world

This article explores the nontechnical aspects of formal architecture reviews-social, psychological, and managerial. Architecture reviews differ from other technical reviews because of their close relationship to a systems business goals, so they need to be approached differently. The authors draw lessons from their experiences in reviewing and evaluating software and system architectures in a wide variety of application domains. They discuss the issues architects face when running such reviews, common pitfalls to avoid, and ways of increasing an organizations chances of a successful review.

Supporting usability through software architecture

Software engineers should consider usability as a quality attribute in their architectural a designs. Usability determines how effectively and comfortably an end-user can achieve the goals that gave rise to an interactive system. It is an important attribute to consider during all phases of software design, but especially during architectural design because of the expense involved in adding usability aspects after users have tested the system. Since the 1980s, ongoing work on supporting usability through software architectural constructs has focused on the iterative design process for the user interface, which involves initial design, user testing, re-design to correct detected flaws, re-testing, and so on. The traditional software architectural response to repeated and expected modifications to the user interface is to use separation, encapsulation and information hiding to localize the user interface.

Bridging the gaps between software engineering and human-computer interaction

The First International Workshop on the Relationships between Software Engineering and Human-Computer Interaction was held on May 3-4, 2003 as part of the 2003 International Conference on Software Engineering, in Portland, OR, U.S.A. This workshop was motivated by a perception among researchers, practitioners, and educators that the fields of Human-Computer Interaction and Software Engineering were largely ignoring each other and that they needed to work together more closely and to understand each other better. This paper describes the motivation, goals, organization, and outputs of the workshop.