CHI 2000 • 1-6 APRIL 2000 Interactive Posters Achieving Usability Through Software Architectural Styles Len Bass and Bonnie E. John Software Engineering Institute Carnegie Mellon University Pittsburgh, Pa 14213 { ljb,bej } @ sei.cmu.edu ABSTRACT Design decisions at the architecture level can have far- reaching effects on the qualities of a computer system. Recent developments in software engineering link architectural styles to quality attribute analysis techniques to predict the effects of architectural design decisions on the eventual manifestation of quality. An Attribute-Based Architecture Style (ABAS) is a structured description of a particular software quality attribute, a particular architectural style, and the relevant qualitative and quantitative analysis techniques. Thus, it is a description that is meaningful to software engineers as they design or analyze proposed software architectures. We are producing a collection of ABASs that speak to the usability quality attribute. These ABASs will enable software engineers make early architectural design decisions that achieve specific usability functions. Keywords Software design, architectural styles, usability evaluation INTRODUCTION Despite almost two decades of research exploring usability and usability design methods, barely usable computer systems are still appearing on our desktops and elsewhere in our lives. The CHI community advocates design processes that bring usability considerations to early design decisions, but most of these processes stop short of explicitly mapping usability quality to specific software design patterns. This leaves the mapping to a software engineer who may not know much about usability, to a usability specialist who may not know much about software engineering, or to a multi-disciplinary team whose members have difficulty communicating. In other words, the mapping may often remain incomplete, or implicit in architectural decisions and thereby unexamined. We propose to explicitly map usability considerations to design constructs in language familiar to software engineers and, thus, bridge this communication gap. Recent developments in software engineering explicitly link architectural styles [5] to software quality attributes like performance, reliability, and modifiability. The link is established through analysis techniques that predict the effects of architectural design decisions on the eventual manifestation of quality. An Attribute-Based Architectural Style (ABAS) is a structured description of a measurable quality attribute, a particular architectural style, and the relevant qualitative and quantitative analysis techniques [3]. Some aspects of usability fit well into this framework. Therefore, we are producing a collection of ABASs that address these usability aspects of computer systems. Usability ABASs can fill several rolls in an analysis or design process. They provide an enumeration of specific usability features, serving as a checklist for consideration by a design team. They present implementation solutions for those features. Finally, they include methods for performing a cost/benefit analysis for particular usability features. Thus, an ABAS speaks to software engineers about measurable aspects of usability in terms that allow the information to be inserted into the architectural design process. In the remainder of this paper, we propose some aspects of usability that are candidates for ABASs and summarize one particular ABAS. CHARACTERIZATION OF THE USABILITY QUALITY A'I-FRIBUTE To generate ABASs, we must first characterize the usability quality attribute into stimuli (typically what users want to do) and responses (measurable behavior of a computer system). To do this, we are distilling the definitions and characteristics of usability presented by many authors over the past two decades. From Nielsen's heuristics (e.g. provide "clearly marked exits") [4] to the properties enumerated by IFIP's Working Group 2.7 [2], these sources have suggested many stimuli and responses that are specific enough to be written as operational requirements for software engineers and are likely to have architectural-level solutions. Thus, we are not proposing new aspects of usability, rather, we are compiling the collective wisdom of the field, choosing those usability aspects with architectural implications, and putting them in the language of operational requirements. © Copyright on this material is held by the author(s). This work supported by the U.S. Department of Defense ~ FuTu~ zS ~C~ 1 71Interactive Posters CHI 2000 • i-6 APRIL 2000 For example, we have identified several types of users who should be considered when architectural decisions are being made, including end-users, system maintainers, and developers. Each user type may have similar needs (e.g., to be able to undo actions) and each may have some special needs. Some stimuli we have identified are: users will sometimes want to cancel their last operation at some point prior to the operation's completion, users will sometimes want to undo prior operations, and users will need to do repetitive commands on groups of items. Typical responses include: the ability to fulfill these user needs, the time to provide feedback to user about the status of their commands, and the accuracy and salience of feedback. SUMMARY OF A USABILITY ABAS The Cancel ABAS is used to reason about whether a proposed software architecture will facilitate users being able to cancel their last operation. The ABAS itself is over eight pages long, so we have only space here to capture the main ideas. There are four parts in an ABAS. Problem Statement. The problem statement includes a brief statement of the problem, in this case, that a user wants to stop an operation he or she has requested before it is complete. It also includes a description of when it is appropriate to consider this ABAS in architectural decisions. In this case, people will always make mistakes and/or change their mind, so as long as the system
View Full Document
Unlocking...