Linking Usability to Software Architecture Patterns Through

Linking Usability to Software Architecture Patterns through General Scenarios* Len Bass Software Engineering Institute Carnegie Mellon University Pittsburgh, PA USA 15213 +1 412-268-6763 [email protected] Bonnie E. John Human-Computer Interaction Institute Carnegie Mellon University Pittsburgh, PA USA 15213 +1 412-268-7182 [email protected] * This work supported by the U.S. Department of Defense and NASA contract #????? ABSTRACT 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 system’s 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. Keywords Usability, software architecture, software patterns, scenarios INTRODUCTION The relationship between the eventual usability of a software product and the various phases and intermediate products of the software development process has been a concern in HCI and Software Engineering for decades. In particular, because the later a change is requested the more costly it is to make, the relationship between usability, the software design process, and early development artifacts is especially important. The earliest software artifact that impacts usability is the software architecture and it is also the artifact most difficult to change later in the development process. Consequently, it is essential to ensure that important usability features are supported within the software architecture. Historically, i.e., prior to 1980, neither usability nor architecture were of much concern to the builders of software systems. Most systems were monolithic and both the user interface and the architecture were more emergent than designed. Getting the computer to do useful work at all within the confines of memory and processor speed was the main challenge. It was very hard to change a system in any meaningful way after it was built, specifications were top-down using a waterfall method of development, and user-testing was used by only the larger and more enlightened organizations (e.g., IBM and the Bell System). In response to user testing results, system builders wanted to change the code, but this proved too difficult for a monolithic system. Thus, software architectures arose in the early 1980s that had three fundamental portions: the user interface, the core functionality of the system, and something to mediate between these two portions. The basic motivation was that separating the user interface into distinct components allowed it to be modified more easily and, hence, the changes indicated by user testing could be incorporated into the final system. The two primary usability architectures of the early 1980s were the Model-View-Controller [13] and the Seeheim architecture [18]. Both of these architectures still exist and they, or their decedents, are commonly used in practice today. The connections between usability and software architecture established twenty years ago have proved beneficial to both the quality of the end product and the development process itself. We have argued elsewhere [12] that, judging from the relative dearth of research into the relationship between usability and architecture in the last two decades, separating the UI from the application in support of iterative design seems to have been accepted as “the solution” to adapting the software development process to deal with usability problems both by software engineers and usability specialists. User Interface Management Systems (UIMSs; e.g., [2, 17]) were investigated a decade ago, but remained a relatively brief academic research topic. However, it is our observation that even if the functionality is designed in an enlightened and user-centered way, and even if the UI is cleanly separated from the core functionality to facilitate the inclusion of user testing results, decisions made about the architecture of the system can preclude building a truly usable system. Unfortunately, depending on separation and, by implication, iterative design exclusively, places attention on usability problems only very late in the development process. Problems that have been identified via usability testing that require substantial modifications to the architecture likely are not solved because of time and budget pressures. This paper presents the results of an investigation into the relationship between usability and software architecture that focuses on usability problems that require software architectural support early in the design process. The intent is that if the usability requirements for a particular system that are deeply embedded into the architecture are discovered early, then the architecture can be designed to support those requirements. Our investigation included identification of a collection of usability scenarios that have strong architectural implications, development of architectural patterns that provide solutions for each of the scenarios and application of the scenarios to the design of actual systems. GENERAL USABILITY SCENARIOS Quality scenarios have been widely used both in analyzing for software architectures [9] and for designing software architectures [5]. Our first step in investigating the relationship between usability and software architecture was to generate scenarios that expressed a general usability issue and seemed to have architectural implications. For example, a common usability scenario is that a user changes his or her mind about issuing a command and wants to cancel that command before it has completed. This is generally applicable to many software systems and has architectural implications because the system must be attentive to the cancel command and be able to restore state. We generated scenarios in several ways. We read several standard HCI textbooks and used their examples and definitions of usability to inspire scenarios (e.g., [11, 14, 15, 19]). We generated scenarios from our own experiences. We discussed scenarios with colleagues and we literally asked people we sat next to on busses “have you had any problems with computers lately?” Thus, the initial generation process was not systematic or comprehensive, but it was sufficient to produce substantial evidence that the link between usability benefits and architectural tactics is much deeper than simple separation of UI from core functionality. The full set of scenarios that we are currently considering can be found in Appendix A. Architectural patterns For each scenario we generated an architectural pattern [8] that describes an implementation tactic to achieve the scenario. The patterns are described fully in [4] for those who wish more details than we are able to present here. Our goal in presenting these patterns was to avoid a one-size-fits-all solution and provide only a minimum solution for the particular scenario at hand. One of the reasons for the failure of the UIMS research cited earlier was the attempt by its proponents to solve all of the usability problems that a system might ever have. This made the UIMSs inherently cumbersome and unattractive to developers. Figure 1 shows a module view of the pattern for the cancellation scenario. The key to this pattern is that a component cannot be responsible for managing its own cancellation because it may be blocked when the cancel command is issued. Hence, there is a Listener component that is always listening for the user to issue the cancel command and a Cancellation Controller that is responsible for actually performing the cancellation and cleaning up after the component that is being cancelled. Cancellation Listener Cancellation Controller Activity Components • Listen for user cancel • Terminate active thread • Cooperate with Cancellation request • Release resources Controller to provide resource • Inform user of eceiptr of • Return system to prior state and collaboration information request • Give user progress report • Have mechanism for preserving • Inform cancellation • Inform collaborators of state of system prior to command invocation controller termination Key Collaborators Component • Be receptive to information Data Flow about the termination of activity components Figure 1: Module view of the pattern for the cancellation scenario CHARACTERIZING THE SCENARIOS After generating about two dozen scenarios, we characterized them in two ways. We first looked at all the scenarios from the point of view of what usability benefits could be delivered to a user if a good solution to the scenario were implemented and then we looked at the scenarios from the point of view of characterizing the

Load more