CHI '95 ProceedingsTopIndexes

Integrating Task and Software Development for Object-Oriented Applications

Mary Beth Rosson and John M.Carroll

Virginia Polytechnic Institute and State University
Blacksburg, VA 24061, USA
Tel: 1-703-231-6470



We describe an approach to developing object-oriented applications that seeks to integrate the design of user tasks with the design of software implementing these tasks. Using the Scenario Browser -- an experimental environment for developing Smalltalk applications -- a designer employs a single set of task scenarios to envision and reason about user needs and concerns and to experiment with and refine object- oriented software abstractions. We argue that the shared context provided by the scenarios promotes rapid feedback between usage and software concerns, so that mutual constraints and opportunities can be recognized and addressed early and continuingly in the development process.


Prototyping, Design tools, Scenarios, Object-oriented programming, Software engineering, design rationale


In contemporary design practice for applications and user interfaces, task scenarios are a medium for reasoning about user activities; they are used for requirements capture and analysis, user-designer communication, system envisionment and development, documentation and training, usability evaluation. Scenarios have raised the hopes of many in human-computer interaction for an integrated design framework.

Nevertheless, scenario-based design methods are not a mature technology; currently they are not even a coherent methodology (see, e.g., the discussion in the April 1992 issue of SIGCHI Bulletin). For example, there is little consensus about the appropriate level or levels at which to couch scenario descriptions: is it the level of self-conscious human activity, the level of input and output transactions, or is it both? What implications arise from couching scenario descriptions at different levels? What are the procedures and representations for doing this? It is more than likely that at the current time no developer or practitioner of scenario-based methods would render the same answers to these questions.

Scenario-based methods also raise a serious -- indeed classic -- system development issue: Will scenario design representations increase the "gap" between specification and implementation? While much work in software engineering in past decade has been directed at narrowing this gap [9, 16], it seems prima facie that a focus on detailed narratives of user interaction may widen it anew.

Researchers studying object-oriented design (OOD) have developed scenario-based approaches that complement those used in the design of human-computer interaction: scenarios are often used in developing a problem domain model, which is then further elaborated and refined to build an object- oriented design [6, 10, 15, 17] By using scenarios as a source of important problem objects and their interactions, these approaches narrow the gap between specification and implementation. However, the OOD methods are not focussed on reasoning about user tasks -- they use the scenarios to gain insight into possible software models.

We are trying to integrate these complementary uses of scenarios in design. In this paper we describe our work with the Scenario Browser, an experimental design environment for Smalltalk applications, in which a single set of task scenarios is used both to envision and reason about user needs and concerns, and to model and refine object-oriented abstractions that implement these tasks. For concreteness, our discussion focuses on an example application (a bibliography utility) developed using the tool. We begin with an overview of how the applications are developed in the Scenario Browser environment, then consider in more depth the issues of scenario evolution, completeness, consistency, task prototyping and object-based task models that arise in this approach to application development.

Scenario-based development

We assume a view of scenarios as couched at the level people construe their work to themselves, the level at which tasks become meaningful to the people who carry them out. For a person building our example bibliography utility, example scenarios might be "making a note of an interesting multi-media education article from Jack", "looking up the Singley reference", "adding the Lange&Moher CHI paper on reuse", and so forth. Our design method involves generating scenarios -- narrative descriptions of specific task episodes -- to document requirements, problems, and goals, and from this to systematically envision reason about, and debate design solutions [4].

In the Scenario Browser environment, the designer uses a Scenario View to create and elaborate textual versions of the task scenarios. Figure 1 shows such a view being used to develop a bibliography scenario.

FIGURE 1: A Scenario View of the bibliography application.

In developing these task narratives, the designer might start with a few general situations, using them as a heuristic for generating a broad range of user concerns [4]. So, for example, a common situation involves the carrying out of straightforward procedures. The addition of a reference would normally be such a task (in Figure 1, this is indicated by the prefix HOW-TO); in contrast, browsing someone else's reference for interesting article reflects opportunistic behavior.

FIGURE 2: A Claims View of the conference paper scenario.

Figure 2 displays a Claims View of the conference paper scenario described above. Designers use this view to record usability rationale associated with individual scenarios, in the form of claims [4]. A claim is a causal hypothesis about some aspect of the scenario; it relates features of the system in use to one or more possible consequences for the user (positive consequences appear in the middle pane, negative in the bottom). Early in development, these claims may reflect analytic work by the designers; later on, they may incorporate observations obtained through usability testing. At any point in development, however, the claims analyzed for a scenario represent the designers' current best guesses about the usability issues pertaining to that particular use situation.

In the example scenario -- adding the Lange and Moher CHI'89 paper -- we considered that users might want to create a personal nickname for the reference. As the scenario suggests, this feature could have various consequences for a user: The user might benefit from being able to make use of personal experience and article content to build a more meaningful citation name. On the other hand, people are often unreliable at designing names, and the user might have difficulties, might even create a quirky nickname that is rapidly forgotten, necessitating wasteful search. By recording these hypothesized consequences, we identified this scenario as one context for considering usability issues associated with the nicknaming feature.

Our design approach concentrates on developing a coherent set of basic tasks first and only then developing an effective user interface to these tasks. One consequence of this is that most of the early scenarios are of the "How-to" variety -- this situation includes the basic tasks a user can perform with a system. The other situations emerge once the system has been elaborated enough to evoke or facilitate particular goals or problem-solving strategies in the user. For example, "Why" scenarios normally describe situations in which the user is trying to understand an unexpected or problematic response from the system; envisioning such situations requires that a fairly detailed progression of user actions and system responses has been specified.

As soon as a task has been described -- at any level of detail -- the designer can begin building software to implement this specification. In Smalltalk, this consists of creating and refining an object model of the scenario: Smalltalk objects are created, connected to one another, and given scenario-relevant behaviors. Depending on the degree of elaboration provided by a scenario, this object model may be more or less complete. However, even if just one object can be modeled, the designer can begin experimenting with this part of the scenario implementation, sending test messages to the object, and refining its characteristics and behavior.

FIGURE 3: Implementation, Bittitalk Browser and Software Claims Views for the conference paper scenario.

Incremental software development in the Scenario Browser environment is supported by the Implementation View (on the left in Figure 3), Bittitalk Browser (upper right in Figure 3) and Software Claims View (lower right in Figure 3). The designer can either instantiate classes already existing in the system (e.g., creating an instance of OrderedCollection to serve as the "refs" object) or create and instantiate new classes to represent new abstractions (e.g., a Name class that structures the text components of author names). The objects created to implement a scenario are graphed in the lower pane of the Implementation View, so that the designer can see a visual representation of the various cooperating Smalltalk objects and their relation to one another (Smalltalk objects "point" to one another via instance variables, and these are graphed as arcs). The Bittitalk Browser provides access to the class definitions behind the instances in the object model -- this tool is identical to the standard Smalltalk/V class browser, but instead of providing access to the entire (and very large) Smalltalk/V class hierarchy, it lists only the classes currently being used to implement a scenario [14].

From the perspective of object-oriented design, an important characteristic of our approach is that the software development is instance-centered: the designer develops new abstractions (classes) and behaviors (methods) by creating and experimenting with instances playing various roles in a scenario, rather than focussing on the more abstract task of writing class definitions and methods in a class hierarchy browser [7]. The testing and refinement of objects in the model is driven by the needs of specific scenarios. So, for example, in working on the conference paper scenario, we first used strings to model author names (i.e., ‘Beth M. Lange'); as we elaborated the scenario to include visual feedback to the user, these string implementations were replaced by instances of the new class Name, which contained more intelligence about the structure of names.

The concrete situations provided by individual task scenarios promote the analysis of object responsibilities, a fundamental aspect of OOD [6, 15, 17]. But from the perspective of usability, they also create a focus on tasks during the implementation of an application. Thus any software design issues or alternatives that arise can be considered in light of specific tasks that they might impact, at the time that the issues first surface. Designers can use the Software Claims View to encode an explicit analysis of such issues. In the example, we have noted some trade-offs associated with holding the bibliographic entries in a separate "storage" object.

The scenario framework also supports communication between the designer and "user" of the bibilography (the first author used the Scenario Browser to build the bibliography utility, with requirements obtained in conversation with the second author). Designer-user communication has long been recognized as a problem in development, in that designers tend to think and talk about design objects, while users think and talk about tasks [8]. A number of researchers have argued that building object-oriented design models should ease this communication, in that the main elements of the software model will be objects from the problem domain [1, 12]. We found that task scenarios did provide a concrete medium for questions and clarifications concerning the user's needs and preferences: bits of functionality could be described or demonstrated and alternatives considered (with reference to the current usability or software rationale), with the relevant scenario serving as a shared context for discussion.

To sum up, object-oriented applications are developed in the Scenario Browser environment through an integrated process of scenario specification and implementation. Tasks are specified and analyzed for usability issues in parallel with the development and analysis of object models that implement the tasks. We now turn to some of the general issues raised by this approach to application development.

Scenario Evolution

Developing an application through the creation and elaboration of task scenarios is an evolutionary process in which analysis and experimentation with individual scenarios reveals increasingly more about task and software requirements. In the simplest cases, scenarios develop through accretion -- successively more of the problem requirements are specified and implemented. For the task specifications, this involves adding textual description. But for the scenario implementations, it means adding or altering computational objects.

As long as the designer has anticipated the nature of the relevant software abstractions, additional objects can be instantiated and integrated seamlessly into the developing object model for a scenario. However, designers cannot anticipate all of the elements needed in an object model, and some refinements will require changing the abstraction (class) behind one or more objects already in the model; in Smalltalk/V, such a modification is difficult.

For example, our initial object model of the conference paper scenario did not include the date and location of the conference. Later, while working on a formatting scenario, we recognized that some reference formats require this information, and so needed to elaborate the conference paper object accordingly. In the standard Smalltalk environment, we would have been forced to destroy the conference paper object already in the model, add the new structural information (to the class definition for that object), and then re-build the object. The Scenario Browser environment eased this object model evolution by allowing us to add to (or remove) an existing object's attributes, so that we were able to add elements to a scenario without destroying and rebuilding the existing context.

The Scenario Browser also supports cases in which design objects are re-engineerd (i.e., not merely added to an object model). Any object in the implementation of a scenario can "mutate" to a new kind of object (i.e., class), without disrupting its current role in the model. For example, the conference paper was originally modeled as a relatively simple object, whose state consisted largely of strings and collections of strings (e.g., title, authors, proceedings title and editors). At a later point, we reconceptualized conference papers as objects that contain information specific to a paper (e.g., title, authors), but whose conference information (e.g., proceedings title, editor) is held by a second reference object, a conference proceedings. Again, in most object-oriented environments, the original object model would have been thrown away and re-implemented to reflect the new abstraction. However, we were able to use the tools in the Scenario Browser environment to "split" the original conference paper object into two objects -- instances of the revised conference paper class and the new conference proceedings class.


A development process that relies heavily on scenarios must be very sensitive to issues of completeness: How many scenarios are sufficient as a specification for a system? Should we expect that the scenario set covers all of the intended functionality? In our earlier work, we have have found that a dozen or so key scenarios have provided a good specification for systems under design. [4]. Clearly, however, we would not recommend that designers implement exactly and only these dozen or so tasks; the software solution to a problem must be a general one.

In our bibliography utility scenarios, the object model we built for any given scenario was much more general than its specification. This appears to be a natural consequence of moving to a more symbolic and abstract representation (i.e., the domain of algorithmic entities). Whereas a task narrative focusses on the detailed goals and experiences of the user in a particular situation, the object model implicitly covers many variations of a scenario, for example, strings of varying length, typing errors, missing data and so on. In this sense, the "scenario" that we implemented can be seen as a kind of use case in the sense of Jacobson et al. [10]. Some of the considerations bearing on this generalization process are captured in a scenario's software claims; others are captured more informally as textual notes (e.g., in the workspace section of the Implementation View).


Another critical issue for scenario-based design methods is maintaining consistency across scenarios. Scenario elaboration can be viewed as a bottom-up approach to design problem-solving, with an emphasis on the rich context provided by specific task situations. However, modeling the details of each particular task setting might introduce inconsistencies in the overall design. For example, we began our work on the conference paper object in the context of reference-entry tasks, and the view we developed reflected our analysis of how users think of references when adding them to a database (e.g., with components ordered in the fashion they are normally seen, with the option of a personalized encoding). In contrast, a designer working initially on another scenario -- browsing OOD design papers perhaps -- might have come up with a rather different concept of a reference, one that was heavily weighted with attributes representing relations among references.

An explicit integration of scenario descriptions and their implementations can promote consistency in the overall design. For example, an important aspect of OOD is the development of abstraction hierarchies -- abstract classes are used to define shared characteristics of related objects; subclasses then "inherit" the shared behavior, leading to a more efficient design. For designers modeling an object in a specific scenario, then, one design issue concerns the attributes or behavior this object might share with objects in other scenarios. Our first bibliography scenario modeled just one reference item, a conference paper. When we moved to other scenarios involving different kinds of reference items, however, we began to create a "BiblioReference" hierarchy (see the Bittitalk Browser in Figure 3); as additional scenarios were designed, this hierarchy was expanded and refactored.

The Scenario Browser environment also supports the reuse of pieces of object models developed in different scenarios. At any point, the designer can "grab" any object modeled in an existing scenario implementation, and incorporate it into a new scenario. Thus, several of our object models used the Lange and Moher conference paper, but in different roles (e.g., creating it, citing it in a document, updating it). Rather than building a new conference paper instance for each case, we simply carried our original object from scenario to scenario, elaborating it as needed for the new settings. Through such reuse we ensured that we always had a single, consistent implementation for this problem entity.

Of course, changing the implementation of an object in a second scenario can cause a scenario implemented earlier to "break": the other objects in this earlier scenario may no longer be able to communicate correctly with the changed object. When we "split" the Lange & Moher conference paper object into two objects (the paper and its proceedings), we went back to other scenarios whose implementations used this object and updated them as necessary. The Scenario Browser anticipates such a re-engineering process by providing direct access to all other scenario implementations using ann given object.

A more analytic approach to consistency management is to withdraw periodically from work on individual scenarios, to take a more cumulative view of the developing application. In the Scenario Browser environment, views of the objects, classes, and rationale developed across all scenarios are available. The designer can analyze a cumulative object graph for related but inconsistent objects, or for missed opportunities for abstraction. Our bibliography application was developed by one designer, but a system developed by a group of designers, or over a more extended time period, would be more prone to inconsistencies and redundancies (e.g., two different instantiations of the "same" conference proceedings object, one named chi89, the other chi1989). By analyzing the objects in a cumulative graph and the roles that they are playing, a designer may discover objects whose functionality is identical or overlapping, and carry out appropriate modifications (e.g., breaking up one object into two or more others, replacing one object with another, combining one or more objects into a single new object).

Task Prototyping

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 [2]. 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 out" on users [11]. The approach we have described can be seen as a refinement of rapid prototyping: it encourages early and continued testing of a design specification, even before a conventional "user interface" has been implemented. However it goes beyond the purely empirical feedback of prototyping with its parallel creation and evolution of design rationale for the tasks and supporting software.

An important characteristic of our approach is that we prototype tasks. We are seeking to support a process in which designers experiment early and often with software abstractions, but always in the context of specific task requirements. So, for example, when generating an object model for the conference paper scenario (see Figure 1), we worked directly from a usage description and analysis reflecting hypotheses about the user's concept of a reference (e.g., references contain components such as authors and title, and reference-entry consists of specifying these parts). This motivated and rationalized a software design in which these components were easily identifiable and manipulable. This is a common sort of dependency between user tasks and the software supporting them, where some aspect of the user's task structure must be respected or reified in the software model.

From the perspective of object-oriented software engineering, our approach can be seen as an extension of an emerging family of scenario-based analysis and design methods [6, 10, 15, 17]. These methods argue that analysis of task scenarios is a useful technique for developing a problem domain model, a fundamental task in object-oriented design. Like these researchers, we have argued that scenarios are the right starting point for constructing a model of cooperating problem objects [13]. However, these scenario-based approaches to OOD have focussed only on the goal of developing good software models. Our work extends this goal to include parallel development of useful and usable tasks [3, 4].

Most development projects will uncover tradeoffs between usability and implementation concerns, and the discovery and resolution of these tradeoffs is an important aspect of task prototyping. The formatting scenarios provide an example from the bibliography project. One of our first descriptions of a formatting scenario described an author citing references in a familiar style, with the added ability to use nicknames. When implementation began, however, a number of issues arose dealing with how the document was to be parsed (e.g., recognizing a variety of citation forms, distinguishing between citations and other parenthesized material, recognizing and responding appropriately to prior mentions of a reference author). These issues were then considered, but in the context of the affected scenarios, so that consequences for usability and for implementation could be considered jointly. The usability and software claims developed at this point documented these concerns, marking the issue as one to be carefully tracked.

Object Responsibilities in a Task

Most developers are familiar with the constraints that user requirements place on software and vice versa. A less familiar -- but perhaps even more important -- form of interaction between tasks and software occurs when reasoning about a software model suggests new opportunities for users' tasks. Users conceptualize their tasks in certain ways and their understanding of task requirements typically reflects this conceptualization. However, computerizing a task can significantly change the way it is carried out, enabling or suggesting activities that had been difficult or even impossible to achieve [2]. If designers hope to generate innovative solutions to users' needs, they must recognize, exploit and refine such opportunities early and continuingly in application development.

Application of the object-oriented pardigm is one vehicle for discovering possible extensions to existing tasks. In OOD, problems are decomposed into computational objects and their responsibilities; when a problem entity is conceptualized as an "active" agent, it is often given responsibilities normally carried out by humans or other agents [12]. Thus our object-oriented analysis of the bibliography suggested that the various reference types should be "responsible" for their own formatting rules: a conference paper should contain knowledge about how to format itself in IEEE style, in ACM style and so on. This is in contrast to the non-computerized version of the task, where formatting rules are stored in the author's head, or in a reference manual of some sort. This object-oriented view of the formatting task tied formatting knowledge intimately to the object being formatted. It suggested a task model in which doing the formatting was integrated with specifying the rules for the formatting; a user should have access to (and thus be able to experiment with) an object's format at any time, rather than being forced to leave a particular formatting job and move to a distinct formatting "rules" task.

An example of how we documented such task extensions can be seen in our reasoning about conference proceedings. Our initial model of a conference paper did not include a separate component for the proceedings containing the paper; authors do not normally cite an entire proceedings or journal issue, so items such as these did not appear in our task analysis. But as we developed the object models for the various conference paper scenarios, we recognized that an individual conference paper should not be responsible for information about its containing volume. This pointed to the need for separate volume objects, which in turn suggested a task enhancement: creation or modification of a volume reference through work on any of the papers it contains. We immediately explored usability and software rationale for such an enhancement in the context of the affected scenarios. Our conclusion was that while the user's conceptual model would now be more complex (journal articles, book chapters and conference papers would be "compound" references), the additional power provided by the new model warranted the change. We recorded the usability and software claims that that we had developed in reasoning about these tradeoffs; an explicit link between the two sets of claims was created to document this input from the software model to the task design.

These examples argue for particular contributions of the object-oriented paradigm to scenario-based development. Certainly there is nothing in principle that prevents the interleaved development of task scenarios and a non-object-oriented software design. However, we believe that the integration of task and software development will produce the greatest payoff in the design of object-oriented systems: the use- oriented descriptions offer a rich and concrete context for the analysis of object responsiblities, while at the same time this responsibility analysis can suggest new ways of envisioning elements of users' tasks [12].


Our work on the Scenario Browser embodies a new perspective on the gap between task specification and implementation. Rather than rely only on the empirical feedback available through a rapid prototyping process, we propose that tasks and implementation be developed jointly, within an analytic framework that supports recognition and management of their interdependencies. Specifically, we have created a design tool that might integrate use-oriented reasoning with reasoning about software abstractions, using scenarios as the unit or context of analysis and design. In this we are integrating two converging areas of research, that on scenario-based design of human-computer interaction, and that on the use of scenarios in object- oriented analysis and design.

Our research has been guided by the principle that an application's usefulness and usability is inherently constrained by the problem domain model embodied in the application software [5, 12]. It may be possible to "paper over" (i.e., via a user interface optimized through continued iteration) slight mismatches wuth the software's task model, but if a system is to evolve and grow as a user's requirements and skills evolve, it must be founded on well-engineered software abstractions that reflect a task's structure. The most fundamental stage in object-oriented analysis is the enumeration of the problem domain objects, their individual responsibilities, and their collaborations [17]. Our design approach proposes that this enumeration can also play a key role in understanding and extending user tasks.

In sum, our work investigates the proposition that scenarios of the same sort we have been collecting and constructing to guide envisionment of the "external" system, the system as directly experienced by the user, can provide a use-oriented context for object-oriented analysis and design. Our focus is on design situations in which the task model is evolving, situations in which the designer is trying (or at least willing) to get beyond merely making a good model of an extant situation. We want to help designers develop a first-pass analysis of the "right" set of task scenarios, and the "right" set of objects and behaviors. We want to support a fluid exchange of reasoning between the task level and the software level, such that user tasks can inspire software models and software models can extend user tasks.


A partially overlapping discussion of this research will appear in the proceedings of a workshop on scenario-based design.


1. Bruegge, B., J. Blythe, J. Jackson, and J. Shufelt. Object-oriented system modeling with OMT, in OOPLSA'92: Object-Oriented Programming, Systems and Applications. 1992. New York, NY: ACM, pp. 359-376.
2. Carroll, J. M. and R. L. Campbell. Artifacts as psychological theory: The case of human-computer interaction. Behavior and Information Technology 8, (1989), 247-256.
3. Carroll, J. M. and M. B. Rosson. Human-computer interaction scenarios as a design representation, in HICSS-23: Hawaii International Conference on System Sciences. 1990. Los Alamitos, CA: IEEE Computer Society Press, pp. 555-561.
4. Carroll, J. M. and M. B. Rosson. Getting around the task-artifact cycle: How to make claims and design by scenario. ACM Transactions on Information Systems 10, (1992), 181-212.
5. Fischer, G. Domain-oriented design environments, in KBSE'92: The 7th Annual Knowledge-Based Software Engineering Conference. 1992. Los Alamitos, CA: IEEE Computer Society Press, pp. 204- 213.
6. Gibson, E. Objects -- Born and bred. Byte (1990), 245-254.
7. Gold, E. and M. B. Rosson. Portia: An instance-centered environment for Smalltalk, OOPSLA'91: Proceedings. 1991. New York, NY: ACM, pp. 62-74.
8. Greenbaum, J. and M. Kyng. Design at Work: Cooperative Design of Computer Systems. 1991, Hillsdale, NJ: Lawrence Erlbaum Associates.
9. Harrison, M. and H. Thimbleby, ed. Formal Methods in Human-Computer Interaction. 1989, Cambridge University Press: New York, NY.
10. Jacobson, I., M. Chriserson, P. Jonsson, and G. Overgaard. Object-oriented Software Engineering: A Use-case Driven Approach. 1992, Reading, MA: Addison-Wesley.
11. Myers, B. A. and M. B. Rosson. Survey on user interface programming, in CHI'92: Human Factors in Computing Systems. 1992. New York, NY: ACM, pp. 195-202.
12. Rosson, M. B. and S. R. Alpert. Cognitive consequences of object-oriented design. Human- Computer Interaction 5 (1990), 345-379.
13. Rosson, M. B. and J. M. Carroll, Extending the task-artifact framework: Scenario-based design of Smalltalk applications, in Advances in Human-Computer Interaction, ed. H.R. Hartson and D. Hix. 1993, Ablex: Norwood, NJ. pp. 31-57.
14. Rosson, M. B., J. M. Carroll, and R. K. E. Bellamy. Smalltalk scaffolding: A case study in Minimalist instruction, in Human Factors in Computing Systems, CHI'90 Conference. 1990. New York, NY: ACM, pp. 423-429.
15. Rubin, K. S. and A. Goldberg. Object behavior analysis. Communications of the ACM 35, 9 (1992), 48-62.
16. Wasserman, A. I. Rapid prototyping of interactive information systems. ACM Software Engineering Notes 7, (1982), 171-180.
17. Wirfs-Brock, R., B. Wilkerson, and L. Wiener. Designing Object-oriented Software. 1990, Englewood Cliffs, NJ: Prentice Hall.