User tasks and the software designed to support them are interdependent. Tasks set requirements for new systems; as systems are developed, their software and hardware characteristics create constraints or opportunities for the tasks. Many development projects manage this mutual interdependency through tight feedback loops between task specification and implementation, codifying specifications in prototypes early and repeatedly to “try it out” on users. We have argued for a more direct integration of the design of user tasks and their corresponding software design, an integration provided through object-oriented analysis and design (OOAD) of user interaction scenarios [10].
The user interaction scenarios at the center of this integration process can be contrasted to the notion of scenarios used in other design methods. They are similar to instances of use-cases [5], in that they capture a single thread of execution in a given usage context. However, they are more elaborate than use-case instances because they narrate not only the interaction events but also the experience of the user(s)—the usage goals, expectations, and reactions that convey information about the system’s usefulness and usability [3]. User interaction scenarios are also similar to the task descriptions developed and analyzed in cooperative design [7], but focus less on organizational relationships and workflow, and more on users’ cognitive activities.
Our approach offers a specific technique for merging analysis and design in OO development. We assume that requirements analysis is used to define a starting set of scenarios, but argue that OO models of user interaction scenarios can be used both to refine the functional requirements for a system (that is, by developing more detailed interaction scenarios) and to produce a prototype of an OO design that satisfies these requirements. Through simultaneous elaboration and analysis of the user experience and the object model, a design team may be better able to appreciate and leverage the mutual constraints and opportunities raised by these complementary perspectives.
One view of this proposal is as a refinement of rapid prototyping, in that it emphasizes early and continued elaboration and testing of a design concept. However, the intent is to begin prototyping activities as soon as possible, well before functional requirements have been finalized. As conveyed by the diagram in Figure 1, the process involves parallel and iterative development of several representations—a set of user interaction scenarios, usability rationale for these scenarios, object models that enumerate a set of computational entities and their responsibilities in a given scenario, and instantiated object networks that can be used to “run” the proposed scenarios. As the set of scenarios is extended and elaborated, the union of the scenarios’ content represents an increasingly comprehensive description of the envisioned functionality. As object classes are identified, instantiated, tested, and refined in support of individual scenarios, the underlying OO code becomes an increasingly complete implementation of the OO software design. The scenario-specific usability rationale is used to capture and reason about design decisions that may impact a user’s experience in either positive or negative ways. Of course, the extent of this interleaved process is likely to depend on project characteristics such as size, complexity, team composition, and so on. For small exploratory projects, the net result may be the first version of a system; for larger, more controlled projects the result may be a suite of vertical prototypes that illustrate examples of use while at the same time embodying a partial high-level software design.
In the balance of this article we elaborate and exemplify this proposal. We describe the representations that support each point of the interleaved process: user interaction scenarios; an object’s point-of-view describing its responsibilities for a given scenario; a network of collaborating objects that can enact a scenario; and usability rationale documenting usability trade-offs in a scenario. These representations and analyses have been explored through a set of simple hypermedia tools for Smalltalk development, the Scenario Browser [10]. Throughout we illustrate the approach with a design problem concerning scheduling and notification of community meetings as part of a virtual town hall.
A Scenario for a Virtual Town Hall
As a design problem, consider the activities that might take place as part of a virtual town hall (VTH)—an online service that might be provided by a community network, designed to support the creation, sharing, and discussion of community information, as well as the organization and publicity of community events. We will focus on one particular scenario in which a community member uses the VTH to organize, schedule and publicize a meeting to discuss a power-line proposal:
Harry Homeowner is worried about the new power-line plans. He uses VTH to organize a town meeting to discuss his concerns. He fills in the fields of a meeting form, indicating “power-line” as a topic, Thursday, July 9 as a date, and a short paragraph describing his concerns; he also verifies his name and contact information have been listed correctly. He remembers hearing about a planning document, and a quick search of the community archive using “power-line” retrieves it; he attaches it to his meeting request. When he is offered a room at the high school, he OKs it, even though he’s never been in this room before; he asks for directions to be provided. Finally he sends out the notice, labeling it as an event of general interest.
Our development of this example scenario is deliberately simplified to emphasize the possible connections between usage and software concerns. Thus we have ignored many aspects of business meeting scheduling that have been analyzed in other work, for example assuring optimal room selection, or resolving schedule conflicts—see, for example, www.info.ucl.ac.be/research/projects/AVL/ReqEng.html. Of course, this particular scenario would also be just one of various situations analyzed early in the design process; other examples might include looking for interest groups on a particular topic, responding opportunistically to a volunteer request that flashes on users’ screens, determining why you have received an unrequested notice of some event, or filling out an online survey. Issues and techniques for the generation of scenarios have been discussed at length elsewhere [3]; the focus here is on how and why a user scenario might be simultaneously elaborated from usage and software perspectives.
Note that the description of how Harry goes about setting up his meeting is “functional” in character—the narrative specifies what Harry wants to do and why, says what basic steps he follows to achieve his goal, but it provides no detail on what a meeting form looks like, or what user interface actions are needed to fill out the form. We agree with the recommendations of other OOAD methodologists that analysis should focus on first building problem domain descriptions, before constraining the design with specific user interface features [4, 12].
Scenario-Based Object Analysis and Design
From the perspective of OO software engineering, our approach can be seen as an extension of scenario-based methods for OOAD [5, 11, 12]. As a concrete representation of specific activities in a problem domain, scenarios refer to problem entities that may be candidates for computational objects; in contrast to the static analysis of class hierarchies, scenarios also give designers a view into dynamic relationships among domain objects, which is crucial to understanding and modeling object collaborations. We acknowledge these important roles of scenario analyses in OOAD. However, we argue that scenarios also provide a natural integrative context for reasoning about usage and software concerns.
In our Scenario Browser environment, the analysis of user tasks begins by defining a set of preliminary usage scenarios (see the scenario listing on the left of Figure 2). This set of scenarios then serves as an index into more elaborate views of the design as it develops. For example, as soon as a scenario is proposed the analysis of an associated object model can begin. We focus on the major problem entities in a specific scenario as potential computational objects; these are the problem domain objects typically analyzed first in OO modeling efforts [4]. For the example meeting scenario, these initial objects might include Harry, the meeting, the room where the meeting will be held, the town hall itself, and so on (see the POV browser on the right of Figure 2).
After one or more objects have been identified, the object model is elaborated by developing a point of view (POV) for each object—an object-centric version of the user interaction scenario that conveys the object’s responsibilities, parts, and collaborators. This object analysis is similar to the CRC card technique of Beck and Cunningham [1] and to the responsibility-driven design methods developed by Rebecca Wirfs-Brock and her colleagues [12]. However the reasoning activity is more concrete, focusing on a specific object (instance) in a specific use context; we deliberately encourage the use of anthropomorphism as an aid to this initial assignment of functionality to objects. At this early phase of analysis, an object’s “parts” comprise other objects over which it will have some degree of control (the meeting may have a time and topic), while “collaborators” are objects with which it needs to interact to carry out its responsibilities (the meeting may carry out an exchange of information with various rooms in the high school).
Notice that even the scenario narratives have elements of both a problem situation and a possible system design: the description conveys many aspects of the meeting problem under analysis (what meetings are like, how residents think about them), but also suggests design features under consideration (Harry uses a form to specify the meeting features). However, it is in the generation of POVs that software issues gain salience. The object-specific narrative forces attention to an object’s responsibilities, and to consideration of what will or will not be encapsulated within an object. The conversion of familiar problem entities (rooms, meetings) into active agents collaborating to provide a scheduling service also emphasizes the shift from problem analysis to system design.
The POV browser on the right of Figure 2 shows a POV for the room that is scheduled in the meeting scenario. The narrative documents how this particular object might contribute to the scenario: it interacts with a meeting object to determine that it can serve as a meeting place and subsequently to record the meeting on its internal appointment book. At this point, not all parts have been identified (for example, size or equipment in room), but the designer has proposed a room-specific appointment book to use in determining and tracking availability. This exemplifies how POV analysis may help to identify “hidden” objects: the original user interaction scenario contained no information about how use of the room was to be scheduled, but analyzing the possible behaviors of a room object has suggested a particular design approach. This in turn may provoke elaborations of the source scenario, perhaps for example considering other sorts of functionality that might be provided by an appointment book object.
POV analysis is similar to the actor-system “conversations” proposed by Wirfs-Brock [12]. These conversations are used to elaborate a user’s actions on one side, and the system’s responses on the other; like POV analysis, the technique can be useful in uncovering objects, assigning object responsibilities, and outlining interactions among objects. However, the user scenarios we elaborate through POV analysis are concrete, with specific details about the user and the user’s situation; Wirfs-Brock’s conversations are an elaboration of more generic action-response sequences (use-cases). We argue that concrete use settings will promote a sustained focus on user concerns, even as software designs are being proposed [10]. We also advocate an object-by-object analysis rather than a combined analysis of collaborating objects; this reinforces the key OO concept of encapsulation.
As object models are developed for individual scenarios, the designer may also begin to build associated abstractions, in the form of Smalltalk class definitions and methods. Using the POV tool, any object description can be linked to a Smalltalk class. In some cases an existing library class may be used (for example, OrderedCollection might be used as an abstraction for a VTH documents folder); in other cases, a new class may first be defined (for example, Meeting or Room; note that this may involve design of superclass hierarchies as well). If the designer has analyzed different portions of one entity in multiple scenarios (the VTH object itself is a good example of this), the tool automatically links the POV variants to the same class.
The POV classification process results in a problem-specific class hierarchy that can then be elaborated using standard Smalltalk development tools (that is, to add instance variables, method names, method code). As shown on the left of Figure 3, a specialized browser is used to keep track of this emergent class hierarchy; each class is annotated with information about the source POV(s) and scenario(s). This problem-specific view of the hierarchy and the explicit annotations regarding source scenarios maintain an emphasis on the motivating usage context, even as detailed Smalltalk programming begins.
Once several collaborating classes have been defined and given a modicum of behavior, the designer can test them by instantiating parts of the scenario. For this purpose, a network and workspace tool are provided (on the right in Figure 3). Scenario objects can be created and interconnected by evaluating Smalltalk expressions in the workspace. As objects are created and initialized, the network is updated (black arcs in the graph depict instance variable relations; green arcs depict collaborations defined in POV analysis that have not been reified as instance variables). Test messages can be sent, methods refined or added, objects inspected, and so forth, just as one might do in a conventional Smalltalk development environment. Using the workspace, scenario objects can also be “mutated” (transformed into one or more instances of new or revised classes1) if the iterative refinement suggests a change in class design. Note that a natural consequence of the development of classes and methods is that the object model becomes more abstract—defining a class and its behaviors leads the designer to think more generally about the possible behaviors of the scenario objects under analysis. However, the simple object graph referring to scenario entities (for example, harry, hsRoom, meeting—see Figure 3) provides a constant reminder of the specific use setting that the software model is intended to support.
Task and Object Interactions
To this point we have focused on the path from user scenarios to instantiated scenario objects (the leftmost arrows of Figure 1). A key assumption, however, is that the design of user tasks and object models will also be interleaved with analysis of possible interactions between these two design domains. To some extent this will simply involve recognition of constraints imposed by user requirements, which in the Scenario Browser are conveyed implicitly through the scenarios (if Harry wants to specify certain attributes of his meeting, they must all be supported by the form). Scenarios also typically include implicit rationale for functionality (the scenario suggests that a fill-in form is helpful in guiding Harry’s request process). To make such rationale explicit and open to discussion, we provide a tool for capturing usability claims, text structures that relate features of a scenario to possible positive and negative user consequences [3]. An HCI designer can use claims to document the trade-offs implicit in a scenario, as well as to reason about variants of a scenario (for example, what if Harry didn’t have all the meeting details worked out). Figure 4 shows a claim capturing user concerns related to Harry’s use of the meeting form. As with the other representations, this claim view can be evoked and elaborated at any time during development, and provides a record of usage issues contextualized by the use context in which they arose.
Analyzing claims for specific scenarios allows explicit consideration and tracking of “usability rationale.” Claim features (top pane in Figure 4) enumerate design elements that are thought to have usability consequences; the positive and negative consequences enumerate hypothesized impacts of this feature and thus provide rationale for or against this particular design decision. The fact that the feature has been incorporated into the design indicates the designers’ current decision point with respect to these trade-offs. Claims analysis can also be seen as a technique for addressing nonfunctional requirements (see the article in this issue by Mylopoulos, Chung, and Yu): the positive consequences of the claims articulate a number of usability goals that the design hopes to achieve, while the negative ones acknowledge conflicts with other usability outcomes. Elsewhere claims have been used to document other sorts of nonfunctional requirements, for example, software quality [10] and organizational structures [2].
Another important interaction between user tasks and the software model can occur when features of the software design suggest new opportunities for how a task might be carried out. Computerizing a task can significantly change the way it is carried out, enabling or suggesting activities that previously had been difficult or even impossible to achieve. If designers hope to generate innovative solutions to users’ needs, they must recognize, exploit and refine such opportunities early and continuingly in application development.
OOAD is one vehicle for conceiving new task functionality [9]: When problem entities are cast as computational objects with problem-specific responsibilities, some of these responsibilities may have been previously carried out by humans or other agents. Thus a notice in a virtual town hall might be made “responsible” for publicizing itself, realized through procedures for distributing itself as an item on a bulletin board, an email to a community listserv, a message in a town chat, and so on. This is in contrast to physical town halls, where distribution rules are stored in an organizer’s mind or in reference materials of some sort.
Clearly such “active agent” extensions to users’ existing conceptual models should not be adopted without reflection—in our approach developers capture such reflection in usability claims. Our earlier POV analysis of the meeting scenario suggested that the high school room be given responsibility for scheduling itself; this led in turn to identification of a supporting object, the room’s appointment book (see Figure 2). Such a model may make good sense from the perspective of OO software engineering (a room manages it own resources, delegating the scheduling itself to an appropriate helper object), but its pros and cons should also be considered from the perspective of users’ conceptual models (see Figure 5). A room that schedules itself is an unfamiliar notion: it may simplify Harry’s task and reduce his need to learn the details of different rooms, but at the same time he may feel a loss of control, or he may be concerned that a nonoptimal room will be selected.
The design of user tasks and object models will also be interleaved with analysis of possible interactions between these two design domains.
Beyond this first-order consequence, related possibilities may arise in considering how much of the underlying software model to communicate to Harry: making clear to him that it is the room that is doing the scheduling may be disconcerting to Harry, but it may also promote an extended concept of the rooms associated with a virtual town hall (he might think to go to the room to see what facilities it contains; he might expect the room to alert him if any problems develop prior to the meeting). We argue that it is useful to acknowledge and reason about similar consequences early in task analysis, before software decisions have been made which assume or enforce a particular conceptual model. Attaching the claims to the relevant source scenarios provides a concrete use context for this reasoning process.
Many sources of task-object interaction will be realized during initial object analysis (that is, when developing POVs). However, some details of the model may not be determined until objects are instantiated and test methods are developed (see Figure 3). For example, Harry has the goal of publicizing his meeting widely, reflected in the user scenario by him labeling it as of “general” interest. At this point, the mechanism for accomplishing a general broadcast is unspecified. POV analysis might uncover hidden objects such as a user profile with an associated interest list used to collect or filter notices. But the details of interest-matching may well be postponed until implementation—even though these details may have important usage implications (for example, a mechanism that uses “general” as a default might make it difficult for recipients to indicate they do not want to receive notices intended for the general public). Exploring object implementations at this early phase of system development forces designers to make tentative decisions about such issues, again within the context of a specific use situation.
Middle-Out and Model-First Design
The approach we have described can be characterized as “middle-out.” That is, we iteratively elaborate a set of user tasks in two directions: toward networks of collaborating computational objects on the one hand, and toward detailed user-interaction episodes on the other. This is in contrast to the view implicit in many popular user interface prototyping tools (for example, Visual Basic), which we would characterize as “outside-in,” with a focus on screen design and user-system dialog. Such tools may produce attractive and effective interaction designs, but a focus on external appearance may lead designers to ignore opportunities raised by computational models of the problem domain, or may result in user interface prototypes that are not replicable or feasible in the final development phase.
Our approach is also “model-first.” That is, we advocate first designing and testing a simple functional model for a scenario before designing and testing its corresponding user interface. This is not because we believe that the user interface is secondary; rather we believe that a design team is in a better position to propose and explore appropriate user interface constructs after they have developed a coherent model of a task’s base functionality. From a software engineering perspective, it also encourages at least some degree of separation or de-coupling between the underlying application objects and their interactive views and mechanisms.
Conclusion
We have proposed a scenario-based approach to OOAD that closely integrates concerns about use and software in the early phases of system development. Our research has been guided by the principle that an application’s usefulness and usability are inherently constrained by the problem domain model embodied in the application software. User interface designers may be able to disguise slight mismatches between a user’s view and the task model inherent in the software, but if a system is to evolve and grow as its users’ requirements and skills evolve, it must be founded on well-engineered software abstractions that reflect a task’s structure.
If a system is to evolve and grow as its users’ requirements and skills evolve, it must be founded on well-engineered software abstractions.
Our use of scenarios in system development is similar to the work by Leite and his colleagues [8], in which scenarios are part of the model developed to capture and trace development of external requirements. Kaindl’s RETH framework (Requirements Engineering through HyperText [6]) also uses scenarios to integrate requirements capture with OO analysis. However, the scenarios used in these requirements engineering frameworks are more structured representations and do not include elements of the users’ experience. Our approach is quite lightweight with respect to scenario creation, though at the cost of manual maintenance and cross-checking. Leite et al. analyze problem entities to create a lexicon, a process not unlike POV analysis. Because their analysis is focused on external requirements, it does not involve the key design move of considering problem objects as active computational agents with scenario-specific responsibilities.
We should caution that the methods described here have been applied only to exploratory research development contexts. For large projects using many team members working in diverse roles, it may be impractical to expect the high level of communication implied by the simultaneity of analysis and design. The suite of Smalltalk tools has been used by small groups, in which each member was capable of both user task analysis and OO design. If such tools are to be deployed more generally, they may benefit from a more formal scenario representation (as in [8]) that could support consistency-checking and versioning. However, we believe that if the approach is adopted even for a short while during the early stages of requirements analysis, both the resultant task and software designs will profit from consideration of their mutual constraints and opportunities.
Figures
Figure 1. An overview of the interleaved process of elaborating and analyzing user interaction scenarios and their corresponding object models
Figure 2. On the left is a simple editor for defining and writing narratives for user scenarios, which then serve as links to more elaborated views. On the right is the POV browser illustrating a scenario narrative from the room’s point of view.
Figure 3. A project-specific class hierarchy browser (left window) provides standard code development functionality, as well as links back to the scenario objects giving rise to the abstractions. The workspace and network view allow designers to instantiate and interconnect Smalltalk objects as a means of testing and refining their roles in the scenario.
Figure 4. Usability claim documenting possible positive and negative consequences of providing a form for Harry to make his meeting request
Figure 5. Usability claim documenting possible positive and negative consequences of having the virtual town hall (with delegation to the room) manage room scheduling
Join the Discussion (0)
Become a Member or Sign In to Post a Comment