Achieving Usability Through Software Architecture

The goal of this work is to achieve better system usability through design decisions embodied in the software architecture. These decisions are the most difficult to change as the design progresses through the life cycle. Hence, understanding the relationship between software architecture and usability is important to ensure that the system ultimately achieves it. Equally important, however, is expressing this relationship in terms that can be understood by both software engineers and usability specialists. Usability specialists determine which aspects of usability are appropriate for a given task or application. Software engineers evaluate these aspects of usability within the context of the architecture and implement them within time, cost, performance, availability, security, and other constraints (Figure 1).

Architecture is one aspect of a system to be designed, as well as the presentation of information and the functionality of the system. Achieving better usability through software architecture is not a new goal. For the last twenty years, both researchers and practitioners have been concerned with the software architecture design techniques required to support usability. These techniques have focused on selecting the correct overall system structure, then showing how this structure will deliver the modifiability needed, while still supporting performance and other functionality. A review of these techniques can be found in Chapter 6 of Software Architecture in Practice [Bass 1998].

The architectures of the 1980s and early 1990s assumed that usability was primarily a property of the presentation of information. Therefore, simply separating the presentation from the dialog and the application made it easy to modify that presentation after user testing. However, that assumption proved insufficient to achieve usable systems. A more popular belief in the 1990s was that usability concerns greatly affected system functionality (application) as well as presentation. This new emphasis took away attention from architectural support (beyond separation of presentation and application). Achieving the correct functionality for a given system became paramount.

It is our observation that even if system presentation and functionality are designed extremely well, system usability can be greatly compromised if the underlying architecture does not support human concerns beyond modifiability. Many modifications only come to the fore after an initial design and implementation. As is well known to software engineers, the later in the life cycle that a problem is detected, the more expensive it is to fix. Furthermore, the architectural separation of presentation from application is insufficient to achieve usability because many usability concerns reach deep into the application, beyond the presentation layer. Cost and schedule pressures, then, often prevent many modifications from being implemented.

In this report, we take a proactive approach. Specifically, we present a series of connections between specific aspects of usability, such as the ability for a user to "undo," and software architecture. Our contribution is to couple specific aspects of usability and architecture, rather than attempting to come up with the software architecture that satisfies all aspects of usability. Designers can use this information both to generate solutions to those aspects of usability required for their systems and to evaluate their systems for specific aspects of usability.

In addition to identifying the connections between aspects of usability and software architecture, we identify "general scenarios" (Section 2) that define those architecturally sensitive aspects of usability [Bass 2000]. We also categorize these scenarios into a hierarchy of human benefits (Section 3 and Section 4) so that the design teams or stakeholders can evaluate their applicability to the system being constructed. We take a similar approach to architectural patterns. We provide a hierarchy of architectural mechanisms and then, for each scenario, we provide an architecture pattern that implements the scenario. We categorize these patterns according to their appropriate architecture mechanisms (Section 5 and Section 6). Finally, we position the scenarios within a matrix of benefits and architecture mechanisms (Section 7).

The architecture patterns we provide will enable usability specialists to evaluate the impact of the proposed solution on other quality attributes, such as performance, availability, and security. In this way, we hope to give these specialists the tools necessary to decide which aspects of usability should be included in the beginning of the design process. We also hope to give software engineers the tools necessary to understand particular aspects of usability and their impact on total system quality.

Caveats: Collaboration and Ubiquitous Computing
Thus far, we have only applied usability benefit categories for individuals performing tasks on a desktop computer. However, increasing numbers of systems are being built to support collaborative groups. As a result, the benefits and general scenarios we describe need to be re-examined within the context of collaborative applications. In addition, increasing numbers of systems, such as laptops, personal digital assistants (PDAs), wearable computers, whiteboards, and other devices are being built to support ubiquitous computing. As a result, the benefits and general scenarios that we generated need to be reconsidered in non-desktop systems and applications. New general scenarios or benefits that arise in this context also need to be generated and cataloged. Suggestions are most welcome. This work is being done in an attempt to understand architectural mechanisms and to categorize software quality attributes. While it represents our thinking at this point, our ideas may evolve over time.