Login | Register
My pages Projects Community openCollabNet

Proposed Cognitive Features

As described in Chapter 1, my basic research method has been to (1) find and understand published cognitive theories of design, (2) invent new design tool features that address the cognitive needs identified by the theories, (3) build design tools that include these features, and (4) evaluate the impact of these features on designers. I have tried to build design tools that are realistic test-beds for the cognitive support features, i.e., the latter two tools described below are full-scale, useful tools, not toy examples or prototypes.

To date, I have constructed four design tools with cognitive support. Argo/C2 ( See Argo/C2: a design tool for C2-style architectures ) is a software architecture design environment. Argo/C2 includes critics that remind software architects of the C2-style guidelines (Taylor et. al, 1996), a dynamic "to do" list, and a process model. Stargo is an object-oriented design tool using the OMT (Object Modeling Technique) notation (Rumbaugh et al., 1991). Stargo includes critics and a dynamic "to do" list. Prefer ( See Prefer: a requirements tool using the CoRE notation ) is a state-based requirements specification tool using the CoRE notation (Faulk et al., 1994), which is based on the SCR notation (Henninger, 1980). Prefer includes design critics and a dynamic "to do" list.

Argo/UML ( See Argo/UML: an OODA tool using the UML notation ) is the fourth and most ambitious tool. It is an object-oriented design tool using the UML (Unified Modeling Language) notation (OMG, 1997). Argo/UML's user interface consists of four panes named (clockwise from upper-right) the main pane, the details pane, the "to do" pane, and the navigator pane. The main pane is used for drawing design diagrams and editing tabular views of the design. The details pane contains several tabs. Most of the "details tabs" have an upward pointing arrowhead and show information about the currently selected object in the main pane. However, the first details tab has a left facing arrowhead and shows information about the currently selected object in the "to do" pane. The "to do" pane contains the designer's "to do" list (described below). The navigator pane allows the designer to see all the elements of the design and their relationship to other elements in the context of the selected navigational perspective (described below).

Argo/UML is a useful tool and a showcase for over a dozen cognitive support features. These features are covered in the following subsections and summarized in See Summary of proposed cognitive features . For each feature, I provide background information, describe how the feature is used, and explain its theoretical and experiential motivations. This chapter concludes with a discussion of how the features interact.

Summary of proposed cognitive features

Knowledge Support Features

§4.1.1.

Critics and Control Mechanisms

Implemented, Deployed, Evaluated

Catch design errors early and provide constructive advice

§4.1.2.

Non-modal Wizards

Implemented, Deployed, Evaluated

Provide procedural guidance to resolve identified problems

§4.1.3.

Context Sensitive Checklists

Implemented, Deployed

Help catch design errors early, less specific than critics

§4.1.4.

Design History

Partly Implemented

Helps review past criticisms, manipulations, and resolutions

Process Support Features

§4.2.1.

"To Do" List and Clarifiers

Implemented, Deployed, Evaluated

Presents criticism and advice in a usable, organized format

§4.2.2.

Opportunistic Search Utility

Partly Implemented, Deployed

Helps designers find requested design elements and additional related elements

§4.2.3.

Opportunistic Table Views

Implemented, Deployed

Dense, task-specific views that facilitate systematic scanning and data entry

Visualization Support Features

§4.3.1.

Navigational Perspectives

Implemented, Deployed

Tree-structured views of the design emphasizing alternative relationships

§4.3.2.

Broom Alignment Tool

Implemented, Deployed, Evaluated

Helps designers establish and maintain alignment as secondary notation

§4.3.3.

Model-based Layout

Described, Mock-up

Automatic diagram layout that emphasizes semantic properties of the design elements

Construction Support Features

§4.4.1.

Selection-Action Buttons

Implemented, Deployed, Evaluated

Context-sensitive buttons that provide easy access to common construction actions

§4.4.2.

Create Multiple

Described, Mock-up, Evaluated

Rapidly create design elements by instantiating reusable design fragments

§4.4.3.

Visual Blender

Described, Mock up

Inspires creative design decisions by visually combining design concepts

Knowledge Support Features

Design Critics and Criticism Control Mechanisms

Background

Critics are active agents that continually check the design for errors or areas needing improvement. Critics can deliver knowledge to designers about the implications of, or alternatives to, a design decision. Critics simply advise the designer; they do not prevent the designer from taking action. In this way, they support the designer in working through invalid intermediate states of the design. Designers need not know that any particular type of feedback is available or ask for it explicitly. Instead, they simply receive feedback as they manipulate the design. Feedback is often valuable when it addresses issues that the designer had previously overlooked and might never seek to investigate without prompting.

Each critic performs its analysis independently of others. Each checks one predicate and delivers one piece of design feedback. Critics encapsulate domain knowledge of a variety of types. Correctness critics detect syntactic and semantic flaws. Completeness critics remind the designer of incomplete design tasks. Consistency critics point out contradictions within the design. Optimization critics suggest better values for design parameters. Alternative critics present the designer with alternatives to a given design decision. Evolvability critics consider issues, such as modularization, that affect the effort needed to change the design over time. Presentation critics look for awkward use of notation that reduces readability. Tool critics inform the designer of other available design tools at the times when those tools are useful. Experiential critics provide reminders of past experiences with similar designs or design elements. Organizational critics express the interests of other stakeholders in the development organization. These types serve to aggregate critics so that they may be understood and controlled as groups. Some critics may be of multiple types, and new types may be defined, as appropriate, for a given application domain. See Examples of critics in Argo/UML shows some of the object-oriented software design critics implemented in Argo/UML.

Examples of critics in Argo/UML

Priority

Knowledge Type

Headline

High

Semantics

Remove {name}'s Circular Inheritance

Medium

Alternative

Consider Combining Classes

Medium

Completeness

Add Operations to {name}

Medium

Completeness

Add Trigger or Guard to Transition

Medium

Completeness

Choose a Name

Medium

Completeness

Define Class to Implement Interface {name}

Medium

Evolvability

Reduce States in Machine {name}

Medium

Presentation

Make Edge More Visible

Medium

Presentation

Revise Name to Avoid Confusion

Medium

Semantics

Remove Aggregate Role in N-way Association

Medium

Semantics

Remove Unneeded Realizes from {name}

Medium

Syntax

Capitalize Class Name {name}

Medium

Syntax

Revise Package Name {name}

Medium

Tool

Change Multiple Inheritance to Interfaces

Low

Alternative

Consider using Singleton Pattern

Low

Consistency

Singleton Stereotype Violated

Formalizing the analyses and rules of thumb used by practicing software designers could produce hundreds of critics. To provide the designer with a usable amount of information, a subset of these critics must be selected for execution at any given time. Critics must be controlled so as to make efficient use of machine resources, but our primary focus is on effective interaction with the designer. Specifically, designers should be able to easily view relevant and timely feedback items without having to sort through irrelevant items. Furthermore, the elapsed time between a design manipulation that introduces an error and the presentation of feedback identifying the error should be as short as possible, and ideally, should be short enough to maintain a feeling of inter-activity.

Criticism control mechanisms are predicates used to limit execution of critics to when they are relevant and timely to decisions being considered by the designer. Attributes on each critic identify what type of design decision it supports. Criticism control mechanisms check those attributes against the design goals and process model. Computing relevance and timeliness separately from critic predicates allows critics to focus entirely on identifying problematic conditions in the product (i.e., the partial design) while leaving cognitive design process issues to the criticism control mechanisms. This separation of concerns also makes it possible to add value to existing critics by defining new control mechanisms.

Description

Designers using Argo/UML do not usually interact with critics or criticism control mechanisms directly. Instead, they simply see the feedback produced by critics presented via the "to do" list and clarifiers (described below). However, designers can directly edit the user model that is used by criticism control mechanisms. See Decision model editor shows Argo/UML's decision model editor: designers can prioritize the types of decisions involved in object-oriented design, and the critics that support those decision types will be activated or deactivated based on that model. Also, designers can enable or disable individual critics by using the Critic Browser window ( See Critic browser window ).

Mapping to theory

Critics are motivated by the theories of reflection-in-action and opportunistic design. Critics provide automated support for reflection-in-action by doing some of the analysis work that would otherwise be the responsibility of the designer. This can help average designers work like expert designers because the critics prompt them to consider the same issues that expert designers consider. Critics can also help all designers avoid slips or oversights than can occur when working under pressure.

The theory of opportunistic design predicts that when a designer is blocked by not knowing how to solve a problem they encounter, they tend to switch to an alternative design task. Critics can help designers avoid context switches and follow through on their original design plans if the critic detects the problem and offers the designer advice leading to a solution. However, designers will naturally switch tasks opportunistically during the course of design. When they do, critics can provide a "safety net" that allows them to deviate from the specified process without fear of forgetting to complete all details and correct all problems as they go.

Furthermore, the automatic application of critics addresses the confirmation biases and fixation effects that designers may experience during construction of designs. Alternative critics prompt designers to consider specific alternatives to decisions they have made. Ideally, the suggested alternative is itself an improvement. However, considering the alternative can cause the designer to activate previously inactive memory structures and bring new parts of his or her knowledge into play. This can help designers break out of the cyclic memory activations associated with fixation, even if the critic does not directly offer a better solution.

Possible extensions

No widely useful critic implementation language has been proposed to date. A potential extension to this dissertation would explore the possible advantages of special purpose critic languages as compared to the use of general-purpose languages like Java. Many researchers have investigated end-user programming (e.g., Girgensohn, 1992; Riesbeck and Dobson, 1998). However, no critic language has been successfully demonstrated as useful to practicing designers. One key goal and point of comparison is the capability for practicing designers to easily specify improvements to critics. See Proposed graphical specification of critics and wizards shows my proposed graphical notation for specifying critics and wizards. The flow of control starts at the left-most node and proceeds to the right, taking all branches, until a condition is not satisfied. Rounded rectangles indicate conditions that must be satisfied. If control reaches a bull's-eye node, the critic fires and generates feedback. Rectangular nodes describe user interface panels presented to the user as a step in the wizard. Parallelogram nodes are actions that modify the design or user model. It is expected that practicing designers using this notation will be able to easily propose changes that add a new case where the critic should fire or that place a new restriction on an existing case.

Non-modal Wizards

Background

Critics that simply identify problems leave the full responsibility for fixing those problems with the designer. Often, when a critic identifies a specific problem, there is a specific, automatable solution to that problem. For example, one critic identifies class names that begin with lowercase letters as unconventional in UML; one simple and automatable solution to this problem is to capitalize the first letter of the class name. Not all solutions can be implemented in a single step, however. Some solutions will require the designer to make decisions about how the problem should be resolved. For example, one Argo/UML critic identifies multiple inheritance as incompatible with Java code generation; the suggested fix involves several steps to convert one superclass into an interface and move method definitions down into subclasses. Argo/UML's non-modal wizards aid designers in solving identified problems by guiding them through the steps of the solution without unnecessarily constraining them.

Description

Argo/UML uses non-modal wizards to aid designers in carrying out suggested design improvements. Argo/UML's wizards are similar to wizards found in other development tools and desktop applications: they guide the designer through a sequence of steps and decisions in a predefined task (Dryer, 1997). A wizard typically performs design manipulations on the designer's behalf; but in some cases, suggested fixes consist solely of step-by-step instructions (i.e., cue cards) to the designer. The designer uses "Next" and "Back" buttons to move among steps, and branches are taken based on the state of the design and the values entered into the wizard. As the designer progresses through the steps, a blue progress bar is drawn on the PostIt note icon for the affected feedback item in the "to do" list.

Unlike wizards found in other tools, Argo/UML's wizards are non-modal and apply changes immediately rather than at the final step. The designer is free to leave the wizard at any time to perform direct manipulations on the design or use another wizard. The designer may return to a partially completed wizard at any time. The ability to directly manipulate the design is necessary for wizards that simply direct the designer through a series of manual steps. Non-modal wizards also allow designers to opportunistically perform other design manipulations that are logically related to the steps of the wizard. For example, in working through a wizard for removing multiple inheritance, the designer may choose to work outside of the wizard to move some methods to an entirely different location in the inheritance hierarchy. Once the designer has begun using a wizard, the "to do" item that gave rise to the wizard will not be removed until the wizard is finished or canceled.

Non-modal wizards in Argo/UML provide a spectrum of investment choices ranging from low effort cue cards to traditional wizards with substantial automation to push-button corrections. As with checklist and critics, the tool builder and the organization using the tool can make the decision to invest more effort in knowledge support based on feedback from designers using the initial low investment versions. Those cue card wizards that are found useful then become candidates for further investment in automation. If a given wizard proves very often useful and requires no additional information from the designer, it may even be applied automatically to correct problems without explicit confirmation.

Argo/UML's support for non-modal wizards is also motivated by a concern for the authoring cost needed to build them. Argo/UML provides several options for wizard authoring with a range of cost and value. Simple suggestions on how to solve the identified problem can be authored as textual cue cards without programming. From there, partial automation and some wizard user interface elements can be provided by reusing existing wizard steps. Custom user interface elements or new automated design manipulations can be built by extending the existing framework. Finally, "push-button" automated solutions may be developed for some kinds of design problems. The decision to invest more effort in additional automation can be made based on experience with earlier versions.

Mapping to theory

Wizards in Argo/UML and other tools address the fact that designers have limited knowledge. While the problem descriptions generated by critics augment designers' analytical knowledge, wizards augment designers' procedural knowledge of how to fix problems. This procedural knowledge exists at two levels: general design manipulation strategies and specific tool commands. Each of these levels of procedural knowledge is discussed below. The cognitive theories of reflection-in-action, opportunistic design, and comprehension and problem solving also helped inspire this feature.

At the strategic level, experienced designers are likely to posses a well-stocked library of design manipulation strategies. For example, when replacing a design element with a new one, it is usually best to configure the new element while referring to the existing one, then delete the old element rather than deleting the old element first and relying on one's short-term memory to construct a corresponding new element. Wizards can contain knowledge about effective strategies and guide designers in following them. This supports less experienced designers who may not possess appropriate strategies, and it helps all designers execute strategies under stress or when distracted. As discussed in Section 2.2.4, Guindon, Krasner, and Curtis (1987) identified the lack of knowledge about design strategies as one of the main difficulties facing large software design projects.

At the tool-specific level, even experienced designers may lack knowledge of new or rarely used design tool features. For example, if a wizard tells the designer to access the pop-up menu on a certain design element, the designer will learn that a pop-up menu is available; this might not have been obvious otherwise. In addition to teaching designers about the design tool's user interface on demand, wizards may also provide special-purpose user interfaces that are not otherwise available. For example, if one step in a wizard requires the designer to move methods from one class to another, it can present a user interface with two scrolling lists of methods and method movement buttons. Keeping such rarely used, special-purpose user interface panels in wizards and out of the main menus and toolbars helps to reduce the apparent complexity of the tool and may lower initial learning costs. The usefulness of special-purpose, task-based user interfaces is also indicated by the theory of comprehension and problem solving. In particular, a wizard step can aid designers' comprehension of their design if it brings together design elements to highlight an interaction or design trade-off that is not clear in task-independent views.

Based on the theory of reflection-in-action, I chose to make Argo/UML's wizards take action in each step so that the designer can reflect on the implications of each design decision as it is being made. Since design decisions interact, it is likely that a change to one part of the design will force the designer to consider a cross-cutting issue that affects other parts as well. Once the designer is considering the cross-cutting issue, it may be easier for him or her to make a design excursion to deal with all the affected design elements before continuing on with the initial wizard. Based on the theory of opportunistic design I suspected that normal, modal wizards might force the designer to follow through on a potentially costly train of thought. By making wizards non-modal, Argo/UML allows designers to switch tasks to pursue those with lower cognitive costs. Non-modal wizards and the "to do" list help designers return from design excursions by keeping partially resolved items in the "to do" list and indicating them with a visible progress bar.

Context Sensitive Checklists

Background

Conducting design reviews and inspections is one of the most effective ways of detecting errors during software development. In a recent editorial, Glass (1999) reviewed the results of controlled studies on the effectiveness of inspections and summed up the three best software engineering practices as "inspections, inspections, inspections." A design review typically consists of a small number of designers, implementers, or other project stakeholders holding a meeting to review a software development artifact. Many development organizations have developed checklists of common design problems for use in design review meetings. Porter and Johnson (1997) found that reviewers inspecting code without meeting were just as effective as design review meetings. I have added a checklist feature to Argo/UML that is much in the spirit of design review checklists. However, Argo/UML's checklists are integrated into the design tool user interface and the design task.

Description

A software designer using Argo/UML can see a review checklist for any design element. The "Checklist" tab presents a list of check-off items that is appropriate to the currently selected design element. For example, when a class is selected in a design diagram, the checklist tab shows items that prompt critical thinking about classes ( See Context sensitive checklist ). Designers may check off items as they consider them. Checked items are kept in the list to show what has already been considered, while unchecked items prompt the designer to consider new design issues. Argo/UML supplies eleven different checklists with two hundred possible items in total.

The items in the list are phrased in concrete and specific terms whenever possible. For example, "Does the name `Student' clearly describe the class?" and "Is `Student' a noun or noun phrase?" In contrast, paper-based checklists must use generic terms (e.g., "Is the name of the class a noun or noun phrase?") and rely on human interpretation of those terms. Clearly humans are able to interpret generic terms; however, doing so is an additional cognitive operation that can be avoided with tool support.

Each checklist item can have a guard condition that determines if the item is appropriate based on the design context. A checklist item is only shown to the designer if its guard expression evaluates to true; this helps keep checklists of manageable size and increases their perceived relevance. For example, one checklist item for Attributes (i.e., instance variables of a class) prompts the designer to consider breaking complex variables down into parts (e.g., a telephone number could be represented as a single attribute, or it could be broken down into area code, prefix, number, and extension). The guard condition for this item checks that the selected attribute's type is not boolean, since booleans cannot be broken down into smaller parts. Unlike a critic's predicate, the guard condition of a checklist item is optional. Checklists without guard conditions are used to prompt the designer to consider issues that are frequently useful but that cannot be evaluated by the system.

Mapping to theory

Checklist items are motivated by many of the same cognitive needs that motivate critics and the dynamic "to do" list (described below). Like critics, checklists support reflection-in-action by asking questions about the design that the designer might not ask on his or her own. Like "to do" lists, checklists support opportunistic design by listing out issues and allowing the designer to choose which issue to address next.

Checklist items tend to be generic prompts for the designer to apply their own knowledge. In contrast, critics typically identify more specific problems and supply knowledge that the designer may lack. These generic prompts can lead to distraction by raising issues that require knowledge that is very different than what the designer has in mind. This potential disadvantage is mitigated by making checklists less intrusive. The presentation of checklist items ( See Context sensitive checklist ) is much less intrusive than the clarifiers (described below) and "to do" list items that are used to present feedback from critics.

Checklists are also motivated by the need for a low cost way to build up Argo/UML's knowledge base of advice. None of the critiquing systems discussed in Chapter 3 included large knowledge bases, in part because critiquing systems require the critic author to fully specify each critic at considerable effort. In contrast, Argo/UML supports several authoring options with a range of effort and value. Checklist items that do not have guards can be authored with the lowest cost since they are simply textual. I expect that in many cases an organization's existing design review checklists can be put into Argo/UML by simple cut and paste. Once a checklist item has been defined, a guard condition can be added with a single line of code. The next step up in terms of effort and value is a critic with an initial predicate. From there the predicate can be refined to increase the critic's relevance. Additional value in the form of detailed explanations, special clarifiers (described below), cue cards, or wizards can be achieved with incremental effort. The decision to invest effort in refinement can be based on experience and feedback from designers.

Possible extensions

Checklists could be made more useful by collecting and summarizing the results of informal design reviews. For example, designers might specify a confidence level rather than a simple checkmark for some checklist items. These confidence levels would then be summarized and ranked so that the parts of the design with the lowest designer confidence could be examined again. Checklists might also be extended by adding support for wizards that help the designer understand the details of the issue raised, and that provide automation to aid the designer in achieving the desired design quality. These checklist wizards would have many of the same advantages as the wizards associated with critics; namely, they would provide many task-specific user interfaces without complicating the normal user interface and would also be non-modal.

Design History

Background

Because design decisions are interrelated, rationale for past decisions is a key part of the design context of new decisions. For example, a software architect building an HTML editing application might initially choose the most full-featured implementation of a table editing component, only to find that it is incompatible with the spell-checking component. In deciding how to resolve the problem, the architect must know why that particular spell-checking component was used. Blindly replacing the spell-checking component with a more flexible one risks violating the implicit assumptions of related decisions.

Design history is a time-ordered list of the events leading up to the current state of the design, including design manipulations, criticisms offered, and criticisms resolved. I intend a design history to include less information than a design rational in that a history focuses on what happened and need not address in detail why things happened. Certainly, knowing why past design decisions were made would provide stronger support for current decisions; however, the cost of recording what happened is much lower, and seeing what happened can cue the designer's memory of why certain decisions were made. Furthermore, including criticism and criticism resolutions in the history helps to capture some of the reasons why certain design changes were made.

In addition to informing current decision-making, design history is also needed to avoid repeating any criticism that is resolved by actions outside of the design tool. For example, if the spell-checking component is a "beta" version rather than a fully tested product, then an organizational critic might advise the designer that all use of beta components require special commitments from the quality assurance manager. The designer might discuss it with the manager and agree that it would be acceptable to use the beta version in this case. The designer would then dismiss the critic's "to do" item, possibly entering a brief explanation. The same criticism should not be presented again for the spell-checking component, despite the fact that the design is in the same state that caused the critic to fire initially.

One challenge faced by design rationale systems is that designers may not take the time to enter information (Lee, 1997). Critics help elicit design rationale as part of the normal design process by acting as foils that give designers a reason to explain their decisions. A recent evaluation of a critiquing system found that experienced designers often explained their decisions in response to criticism with which they disagreed (Sumner, Bonnardel, and Kallak, 1997).

Description

The "History" tab at the bottom of the Argo/UML main window shows a time-ordered list of design history items. Items are recorded for each "to do" item raised, each design manipulation performed, and each "to do" item resolved. These "to do" items normally contain criticisms from design critics, and their resolutions normally contain comments from designers that justify decisions or links to history items for manipulations that resolved the problem.

The history list can display all history items in time order or it can be focused on just those history items that relate to the selected design element. The designer can review design history by selecting an item in the history list on the left side of the "History" tab. Doing so displays a description of the history item in the text area at the right and updates a list of related design elements. Clicking on a related design element will select that element in the diagram pane and allow the user to view its properties.

In addition to building a design history, resolutions to identified problems are sometimes used to adjust Argo/UML's user model and goals model. For example, if the system under design is only intended for experimental use, the criticism that beta components require special testing commitments might be resolved by the architect pressing the "Dismiss" button and choosing "It's not relevant to my goals" ( See Argo/UML's feedback item dismissal dialog ). In response, Argo/UML immediately opens the goals model window so that it may be updated. If the architect chooses "It's not of concern at the moment," Argo/UML opens the decision model window. Keeping the user model and goals model accurate requires frequent updates. Yet, we cannot assume designers will make the effort to update them without prompting.

Mapping to theory

Argo/UML's design history feature is inspired by the observations that design decisions are interrelated, that designers may have difficulty recalling past design decisions when that knowledge is needed, and that providing the right cues can aid in associative memory retrieval. Furthermore, to the extent that a design history support building a design rationale, the design history can help inform new decisions with knowledge about past decisions that the designer would not otherwise possess.

Possible extensions

Future extensions to this feature might include a way for the tool to infer causal links between the design manipulations and the problems that they cause or resolve. Also, the design history user interface could provide better views of the design history that better suit specific recurring tasks. The same basic ideas used in the navigational perspectives on the design itself, could be used to construct task-specific views of the design history.

Process Support Features

Dynamic "To Do" List and Clarifiers

Background

Once a critic generates design feedback, that feedback must be presented to the designer in a usable form without unduly distracting the designer from the task at hand.

Some current CASE tools, such as Rational Rose, follow the familiar paradigm of textual compiler error messages. The difficulty with textual feedback logs is that they are usually structured linearly in the order the messages were generated and cannot be organized according to the designer's interests. Furthermore, textual error messages are either too short or too long: they cannot be used effectively to both teach concepts to designers who lack needed knowledge and to conveniently prompt designers who have the needed knowledge but were not able to recall it at the time needed. Also, textual error logs are normally presented in a scrolling text widget that is distinct from the design diagram drawing area. Section 7.1 summarizes the result of a pilot Argo/UML user study which indicated that designers tend not to move their eyes from the design diagram to other panes of the same window.

Description

In Argo/UML, the "to do" list user interface presents feedback to the designer. The "to do" items on the list are grouped into categories, for example, by priority, by design decision type, by offending design element, or by critic knowledge type. The designer can choose the categorization scheme from a menu above the "to do" list. A count of items on the "to do" list is displayed next to this menu. If the number of items is above 50 or 100, then the count is displayed on a yellow or red background to make it more evident. When the designer selects a pending feedback item from the lower left pane, the associated (or "offending") design elements are highlighted in all diagrams and details about the identified problem and possible resolutions are displayed in the "ToDoItem" tab. If the designer double-clicks on a "to do" item, Argo/UML jumps to the offending design elements: the diagram with the offenders becomes the currently displayed diagram.

The designer may use the toolbar buttons in the "ToDoItem" tab to add a new item as a personal reminder, follow links to background domain knowledge relevant to the issue at hand, snooze the critic (disable it for a limited time), send e-mail to the person who authored the critic, or dismiss the feedback item. Links to background information and e-mail contact with expert designers provide a design context that the designer can use to resolve the issue at hand. Providing contact information for relevant stakeholders helps to situate the problem and possible solutions in the context of the development organization.

User testing with an early version of Argo/UML demonstrated that designers are likely to focus on the diagram pane to the exclusion of the "to do" list pane. Designers were observed to build on incorrect design decisions despite the fact that criticism of those decisions was listed in another pane in the same window. Clarifiers were added to Argo/UML to make criticism more evident to designers engaged in design construction. Clarifiers are icons or other visual indications of errors that are displayed directly on the design diagram. Argo/UML uses wavy, red underlines (a familiar indication of spelling errors) to indicate errors that occur at a specific part of a design element. A yellow PostIt note icon is used to indicate errors that relate to an entire design element. Errors related to missing or invisible design elements currently do not have clarifiers. Visual cutter is limited by only displaying clarifiers on the currently selected design element. Designers will encounter clarifiers in the normal course of manipulating the design with the mouse and keyboard. A feedback item headline is displayed as a tool-tip if the designer briefly positions the mouse pointer over a clarifier.

Mapping to theory

The dynamic "to do" list user interface supports cognitive needs identified by the theories of reflection-in-action and opportunistic design. According to the theory of reflection-in- action, when designers reach a breakdown (a point in the design session where they are not immediately able to move forward), they may instead reflect on the current state of the design. Argo/UML's dynamic "to do" list helps designers evaluate the current status of the design by listing potential errors.

The presentation of the outstanding item count and its color are indications of how confident the designer should be in his or her design. This makes accessible an important aspect of the design that is not visible in the design document itself, and cues designers to make meta-cognitive decisions, such as when to switch from construction to reflection.

Argo/UML's dynamic "to do" list also supports opportunistic design. As mentioned in the discussion of critics, the "to do" list aids designers in opportunistically switching between tasks by providing a list of suggested tasks to choose from and by providing a "safety net" that allows designers to more freely switch tasks with less fear of skipping needed steps.

Clarifiers serve the same basic purpose as the dynamic "to do" list and address the same cognitive needs of designers. Clarifiers help address the limited visual scope of the human eye by providing visual feedback in a location where the designer is focusing his or her attention.

Related work

Rogers (1995) describes an automatic "to do" list used in the CORRECT requirements tool that is very similar to the "to do" list used in Argo/C2. The window consists of two panes: an upper pane that lists all pending "to do" items and a lower pane that shows the details of the selected item. Rogers also suggests that the details should include instructions on what the designer should do to fix the problem and that the tool might offer to fix simple problems automatically. The dynamic "to do" list in Argo/C2 has these capabilities. It also allows the designer to send email feedback to experts, add personal reminders, and to dismiss or hush particular items. Argo/UML takes several steps further by providing alternative perspectives on the "to do" list and automatically customizing the text of each item to the particular identified problem. Clarifiers and non-modal wizards are closely linked to Argo/UML's "to do" list items and provide additional support not found in CORRECT.

Opportunistic Search Utility

Background

Design documents are complex webs of design elements and relationships. These relationships include explicit relationships for the structure and behavior of the system being designed. However, design documents also include implicit constraints and dependencies between design elements that must be maintained. In some cases these implicit relationships can be made explicit in the design document, but that approach can only be carried so far before the document becomes cluttered and difficult to work with.

Many software analysis tools have been built to produce dependency graphs as output. Two difficulties with these tools is that their graphs rapidly become out-of-date as the software is changed, and there is some effort involved in knowing how to use the analysis tool, recognizing that its results are needed, and interpreting the results.

The related element generation rules used in Argo/UML's opportunistic search utility stand in the same relationship with traditional dependency analysis tools as design critics do with traditional design error detection tools. Both cognitive support features address the same basic goals as their traditional counterparts. However, both cognitive support features are much better integrated into the design tool and the design process.

Description

Argo/UML provides a search utility that works in a way familiar to MS Windows (tm) users: the top part of the search window consists of several tabs where different search criteria are entered; the bottom part of the search window shows search results. Clicking once on a query result selects it. Double clicking on a query result causes the main Argo/UML window to display a diagram that contains the selected design element.

The main special feature of Argo/UML's opportunistic search utility is the list of elements shown below the query results ( See Argo/UML's opportunistic search utility window ). This list contains design elements that are related to the query result selected in the upper list. The related design elements include those that are likely to need updating if the selected query result is updated, or that should be checked before modifications are made. The set of related design elements are generated using predefined rules provided by a domain expert. These rules could include executing external software analysis tools to produce dependency graphs; however, such rules have not been implemented in Argo/UML.

One other interesting aspect of Argo/UML's search utility is that it stores multiple sets of answers. The bottom half of the window is a tab widget and a new tab is added to store the results of each search. Tabs can also be deleted by pressing the "Clear Tabs" button or "torn off" by double clicking on the tab label.

Mapping to theory

At a practical level, Argo/UML's opportunistic search utility can prompt designers to consider related model elements that they would otherwise be very likely to skip. Like several of Argo/UML's visualization features, the opportunistic search utility makes explicit some design relationships that are needed for specific design tasks but that are not visible in the design notation itself.

On the cognitive level, Argo/UML's opportunistic search utility supports opportunistic design by offering designers alternatives that are likely to be related to their current mental context. The cognitive theory of opportunistic design predicts that designers will often prefer to pursue related design tasks immediately if they require the same mental context, i.e. they have low cognitive cost.

On the other hand, presenting design elements that are weakly related to the current task can distract designers from their current task by prompting them to change their mental context, causing many mental context switches and the associated cognitive cost. To mitigate this potential disadvantage, Argo/UML presents the related elements via a user interface that keeps the original query results visible. This was done to aid the designer in returning from small design excursions.

The opportunistic search utility may also help average designers work more like experts if it prompts them to activate the same memory structures that experts activate. The various features of Argo/UML that help designers think more like experts are discussed more in scene 4 of the usage scenario in Chapter 5.

Possible extensions

An interesting future extension to this feature would be to automatically infer the related element generation rules from logs of expert usage. This would make the feature similar to "recommender systems" found on the internet, such as Yenta (Foner, 1997). Inferring related design elements based on experience might lower authoring costs while increasing the relevance of provided elements. At the least, it would provide a way to check the related element rules offered by experts.

Opportunistic Table Views

Background

Most widely used software design notations, including the Unified Modeling Language, are primarily diagrammatic notations. Diagrams are effective ways of communicating designs because they have immediate visual impact and several secondary notation possibilities. However, diagrams have low visual density, which has been identified as a limiting factor in the adoption of visual programming languages. Furthermore, diagrams tend to be rather difficult to edit and systematically scan. The high effort needed to construct a diagram in most CASE tools encourages designers to use a given diagram for more design tasks than those for which it is well suited. Several of the features described in this dissertation address the weaknesses of diagrams by improving the way diagrams are constructed or by complementing them with non-diagrammatic design views.

Description

Argo/UML supports UML class diagrams, state diagrams, use case diagrams, activity diagrams, and collaboration diagrams. It complements these diagrammatic representations with task-specific table views. Each table view selects relevant attributes of design elements and presents them in a dense format. For example, one table view of a state machine shows states as rows with the name, entry, and exit actions of each state in columns. Another table view shows the transitions as rows with the trigger, guard, effect, source, and destination as columns ( See Tablular view of state machine transitions ).

As with familiar spreadsheet interfaces, one cell is considered the active cell at any given time and the cursor keys and mouse can be used to move the current cell. In addition to highlighting the active cell, the entire current row or column may be highlighted to help the designer keep track of the type of systematic scanning he or she is doing. The "Instant Replay" button provides an "instant replay" of recent activity: it briefly highlights the most recently active cells and their entire rows or columns in the same order that the designer accessed them.

Mapping to theory

As with navigational perspectives (described below), one of the goals of Argo/UML's tabular view feature is to provide views that support common design tasks. In particular, tables are easier to systematically scan or fill in than are most diagrams.

However, designers work opportunistically as well as systematically. For example, if a designer is systematically checking that each state has sensible entry and exit actions and finds one with a problematic assumption, he or she may opportunistically switch to looking over the entire design for other elements which depend on that same assumption. In the best case, a design excursion may merely cause the designer to switch from horizontal to vertical scanning in the same table. In the more general case, the excursion may cause the designer to access other diagrams or tables. These design excursions are natural and common; unfortunately, returning from an excursion imposes the cognitive difficulty of recalling one's prior plans. "Instant replays" are one kind of visual prompt that can help the designer recall a previous mental context.

Visualization Support Features

Navigational Perspectives

Background

The UML standard defines several different diagram types: each of these presents related design elements in an appropriate notation and supports specific design tasks. The set of UML diagram types is based on experience with previous object-oriented design notations and the practical needs of designers. I chose to use the UML standard set of diagram types rather than invent new ones. Designers may spend a significant fraction of time working with one diagram. Nonetheless, different diagrams in the same design document relate to each other, and when building complex designs, the designer will eventually need to build mental structures that combine elements from multiple diagrams. For example, designers may need to mentally relate elements in two diagrams of different types. Also, related elements may be divided among multiple diagrams simply to keep each diagram a reasonable size.

Many design tools and IDEs (integrated development environments) use interfaces that include a large tree widget that presents a "table of contents" of the design document and allow fairly direct access to any design element, regardless of how the design document is broken down into diagrams. These "table of contents" views support designers in finding individual design elements regardless of which diagram the elements reside in; however, standard "table of contents" views provide little help for visualizing semantic structures in the design.

Argo/UML augments these standard, task-independent views of the design with task specific ones. In particular, this subsection discusses the "navigational perspectives" cognitive support feature. Beyond providing a simple "table of contents," Argo/UML's navigational perspectives highlight tree structured relationships in the design document that may be difficult to understand from looking at design diagrams themselves. Argo/UML gives the designer a much richer set of alternative tree-structured views of the project, and provides a language for designers to customize those perspectives or add new ones.

Description

A designer using Argo/UML initially sees the package-centric navigational perspective but choose a new navigational perspective from the menu above the navigation tree ( See (a) "Package-centric" navigational perspective, (b) "State-centric" navigational perspective, (c) "Transition-centric" navigational perspective a). For example, if the designer is working to define the possible states of a particular class, the state-centric navigational perspective shows states as the children of classes and state transitions as the children of states ( See (a) "Package-centric" navigational perspective, (b) "State-centric" navigational perspective, (c) "Transition-centric" navigational perspective b). This emphasizes the states and makes the transitions secondary. Once the designer has a firm understanding of the states, he or she may wish to emphasize the transitions. The transition-centric navigational perspective shows the transitions as the children of the class and the states as the children of the transitions ( See (a) "Package-centric" navigational perspective, (b) "State-centric" navigational perspective, (c) "Transition-centric" navigational perspective c).

Argo/UML contains several predefined navigational perspectives that support various tasks in object-oriented software design. For each of these tasks I have identified questions about the design that the designer must answer during that task. One such perspective is the transitions-paths perspective: it shows initial states as the children of classes and successor states as the children of states. This helps the designer answer the question "if the object leaves this state, where can it go?" A related question is "how can the object get into this state?" Argo/UML does not provide a predefined perspective to answer this question, but the designer can use a configuration window to define new perspectives to answer new questions as they arise.

Argo/UML's navigational perspective configuration window is shown in See Argo/UML's navigational perspective configuration window . The top pane lists currently defined perspectives. The lower left pane lists all predefined navigation rules, while the right pane lists those navigation rules that are included in the selected perspective. Each navigation rule generates children of tree nodes. For example, the rule "Class->Initial States" will be applied to any tree node that represents a class and will generate one tree node for each initial state in the state machine for that class. The set of possible navigation rules is large but finite; the UML standard meta-model (i.e., design representation) includes about 100 associations, each of which can have a corresponding navigation rule. Navigational perspectives are generated by applying all applicable rules whenever a tree node is expanded by the user.

Mapping to theory

The cognitive theory of comprehension and problem solving indicates that designers need visualizations that are specific to the design task they are working on. This applies to both the diagrams and other design visualizations, such as the navigation tree and table views (described above).

When designers do not have design views that present all the elements and relationships needed for a given design task, they must combine elements from different design views to build a mental structure suitable for the task. Building such a structure in short-term memory (STM) requires mental effort and uses up STM resources needed for storing task plans and relevant knowledge. Mental visualization of complex structures can be error-prone if items are lost from STM. In fact, if the designer does a moderate amount of work on each element of the design element structure in his or her STM, elements are likely to be "pushed out" as STM resources are used in considering the first few elements.

For example, consider a designer who is checking that each class in an object-oriented design has a "save to disk" method that properly takes into account all composite and aggregate classes. The is-part-of hierarchy of a complex system is likely to involve elements and relationships from several class diagrams. The designer is further burdened by the need to determine whether each aggregate class should be saved as part of another class (by value) or independently (by reference). Since keeping a large is-part-of hierarchy in STM taxes limited resources, the designer is likely to need to refresh memory by repeatedly scanning all the diagrams involved. Such repeated scanning is itself a time-consuming and error-prone process.

In contrast, Argo/UML's predefined navigational perspective for aggregation automatically constructs and presents the structure in question. The designer can simply expand the tree structure to the desired level of detail and progress systematically, line-by-line, with very little STM load.

Possible extensions

Navigational perspectives are an exciting and potentially very useful feature. Rather than pursue this particular feature as far as possible, I have opted to explore a broad set of proposed features. A possible extension to this dissertation would be to implement and evaluate the following enhancements to Argo/UML's navigational perspectives. First, the navigation pane could be split to show two trees with the second tree rooted at the selected node in the main tree. This might allow designers to see details of part of the tree without losing sight of the context of the parent node. Alternatively, the lower half of the navigation pane might show a list of the most-recently-used design elements to aid designers in flipping back and forth between two elements when comparing them. Also, the composition of navigational perspectives from rules might be made more powerful by allowing hidden tree levels, i.e., levels that are traversed on the way to the desired elements but that are not shown themselves. Finally, on-line documentation describing each perspective is likely to greatly help designers in selecting the proper perspective for their task, as would a task-oriented listing of available perspectives and rules.

The Broom Alignment Tool

Background

Designers typically prefer diagrams that look neat and orderly. Careful alignment of diagram elements can also serve as a form of secondary notation, as discussed below. Most design tools provide features to help align diagram elements with each other. Such features include nudging, grids, gravity, constrained movement, alignment commands, and guidelines. Nudging allows precise manual positioning of diagram elements. Alignment grids are found in virtually all drawing tools, and are used to restrict movement of elements to evenly spaced coordinates. Grids help align objects with each other by aligning each of them with invisible grid lines. Gravity causes an element being moved to snap to nearby stationary elements. Computer Aided Design (CAD) tools and high-end illustration programs often define gravity points at the corners, centers, and other geometrically important points on shapes. Gravity mainly helps establish adjacency (i.e., touching) relationships, but it can also be a step in aligning objects. Horizontally or vertically constrained movement allows users to interactively change one coordinate without accidentally changing the other. For example, if the tops of two objects are aligned using gravity, a constrained movement command can separate them horizontally while keeping the tops aligned. Alignment commands are found in the menus and toolbars of most drawing tools (e.g., align tops, align left edges, align centers). These commands explicitly move the selected objects into alignment with each other. Lastly, guidelines are typically found in page layout tools and are non-printing diagram elements that cause other elements to snap to them. Argo/UML provides nudging, grids, alignment commands, and a novel "broom" tool.

Each of the standard alignment features has its own disadvantages. For example, alignment commands demand that designers select the objects to be aligned then issue an alignment command. Selecting objects may require multiple selection actions. These selection actions may accidentally change the spacing between objects, and in some UML tools it may accidentally activate editing of the labels on a target object. Issuing an alignment command requires designers to imagine the resulting positions of the objects based on command names and icons. Some tools provide an alignment dialog box with a preview function but this introduces additional modality into the user interface. Argo/UML provides these standard alignment features and tried to mitigate their disadvantages (e.g., label editing is disabled if multiple objects are selected). Moreover, Argo/UML also provides a novel alignment feature that avoids these disadvantages.

Argo/UML's broom alignment tool is specialized to support the needs of designers in achieving the kind of alignment used in UML diagrams. It is common for designers to roughly align objects as they are created or by using simple movement commands. The broom is an easy way to precisely align objects that are already roughly aligned. The broom also takes advantage of the fact that, in design diagrams, objects are typically aligned along the X- or Y-axis rather than along arbitrary, diagonal lines. Furthermore, the broom's distribution options are suited to the observed needs of UML designers: making related objects appear evenly spaced, packing objects to save diagram space, and spreading objects out to make room for new objects. The broom also makes it easy to change from horizontal to vertical alignment or from left-alignment to right-alignment. While the broom is useful in a UML design environment, several of its aspects may also suit the needs of diagramming tasks in other design domains.

Description

The T-shaped icon in Argo/UML's diagram toolbar invokes the broom alignment tool. When the mouse button is pressed while in broom-mode, the designer's initial mouse movement orients the broom to face in one of four directions: north, south, east, or west. After that, mouse drag events cause the broom to advance in the chosen direction, withdraw, or grow in a lateral direction. Like a real-world push broom, the broom tool pushes diagram elements that come in contact with it. This has the effect of aligning objects along the face of the broom and provides immediate visual feedback (see See Aligning and distributing objects with the broom ). Unlike, a real-world broom, moving backwards allows diagram elements to return to their original position. Growing the broom makes it possible to align objects that are not near each other. When the mouse button is released, the broom disappears and the moved objects are selected to make it easy to manipulate them further.

If the designer presses the space bar while using the broom, objects on the face of the broom are distributed (i.e., spaced evenly). Argo/UML's broom supports three distribution modes: objects can be spaced evenly across the space that they use, objects can be packed together with only a small gap between them, or objects can be distributed evenly over the entire length of the broom's face. Repeatedly pressing the space bar cycles among these three distribution modes and displays a brief message indicating the operation just performed (see See Aligning and distributing objects with the broom ).

The fact that the broom pushes objects that it touches relieves the designer of the need to select target objects. This reduces the number of mouse movements needed and avoids accidental movement or editing of target objects. Argo/UML further reduces mouse movement by allowing users to invoke the broom by a control-drag rather than by using the toolbar button. Since objects are moved interactively, designers can see and judge the results of their actions immediately, without the need to interpret geometric terms (e.g., "align left edges"). The fact that objects return to their original positions when the broom withdraws allows designers to quickly undo undesired movements. Cycling through distribution commands also gives immediate visual feedback and reduces the need for designers to interpret geometric terms.

Mapping to theory

Alignment and spacing are important aspects of the secondary notation of design diagrams. Although the precise positions of diagram elements on the screen do not hold formal semantic meaning in UML, it is a powerful visual cue that humans follow when reading UML diagrams. For example, the alignment and spacing of states in implies a temporal correspondence between certain parts of two parallel state machines, although the formal syntax of UML does not provide any formal means of representing or conveying that relationship.

Overall, the straightforward physical analogy between the broom alignment tool and real-world push brooms aids designers in understanding and anticipating the results of their actions. Shneiderman finds that users delight in using tools that provide "visibility of the objects and actions of interest; rapid, reversible, incremental actions; and replacement of complex command-language syntax by direct manipulation" (Shneiderman, 1998). At the cognitive level, users may find interfaces with Shneiderman's characteristics to require less planning, thus preserving short-term memory resources for task-level plans and relevant domain knowledge.

Alignment and spacing are two of the most practical visual aspects of a UML diagram to use for secondary notation. They do not rely on color, which may be difficult to print. They allow the sizes of diagram elements to be small, thus saving space. Alignment can clearly represent two informal aspects of the design: in , X-axis alignment implies temporal correspondence while Y-axis alignment implies group membership. Alignment and spacing of diagram elements in a group is visually localized and thus reusable in different parts of the diagram for different meanings: ten groups of aligned objects on one page is readable, whereas ten color-coded or size-coded groups would be difficult to read.

Possible extensions

The broom mode can be enhanced by adding new types of alignment and distribution that are appropriate for a given diagram type. For example, pushing a class hierarchy upward might align classes in the bottommost row of the hierarchy along the face of the broom, but push superclasses in advance of the broom face so as to maintain the tree shape of the hierarchy. Also, the broom could be improved by using information about the connectivity of diagram nodes when breaking distribution ties. For example, if a set of horizontally aligned states is pushed leftward until they are all on top of each other and then spread out by pressing the spacebar, the resulting order of states is essentially random since they all had the same coordinates at the time of the distribution. This may cause many state transitions to cross each other. Connectivity information could help select an ordering that avoids edge crossings.

Related work

Raisamo and Raiha (1996) describe an alignment feature called the alignment stick that uses the same basic metaphor as Argo/UML's broom. However, Argo/UML's broom is unique in its ability to easily undo accidental movements and its support for both alignment and even spacing. Also, the intent of the alignment stick research was to explore the use of two-handed input mechanisms: a mouse is used to control the position of the stick, while a trackball is used to control the length and orientation of the stick. In contrast to the UML diagram focus of Argo/UML's broom, the alignment stick is not domain-specific and does not emphasize rectilinear alignment over diagonal alignment. Raisamo (1999) later extended his work on the alignment stick to produce several other interactive tools related to artistic drawing, for example, the carving stick removes some of the area of shapes when it touches them.

Model-based Layout

Background

Many current CASE tools provide a feature to automatically lay out diagram elements. Dozens of layout algorithms have been devised (e.g., Bertolazzi, Di Battista, and Liotta, 1995). The layout algorithms are typically domain-independent and seek to optimize domain-independent metrics, such as reducing the number of line crossings. Some layout algorithms can be customized with constraints (e.g., Graf and Neurohr, 1995; Ryall, Marks, and Shieber, 1997) that can be used to maintain domain-specific layout conventions. For example, class diagrams in UML are usually drawn with superclasses above subclasses.

The design process is made up of episodes in which the designer addresses different aspects of the design. Within each episode, task-specific questions about the design must be answered. For example, when considering an error condition in which a state machine should transition to a fail-safe state, the designer must answer the question as to which states can give rise to the error.

The domain-independent layouts provided by current tools do not support designers in answering task-specific questions. Designers must visually scan diagrams looking for elements involved in their current task. Continuing the example above, the designer must look at each state in the state diagram, recall the meaning of that state, and consider whether the error could arise in that context. This kind of visual scanning is somewhat error-prone because the designer may skip a diagram element accidentally, especially if the short-term memory load of evaluating a given element is high. Furthermore, since the scan order is not correlated with the semantic properties of the elements, considering successive diagram elements may require different parts of the designer's knowledge to be activated, leading to a short-term memory effect analogous to thrashing in computer memories. As noted in Section 2.2.2, high short-term memory loads can induce procedural errors, namely super-goal kill-off, which can cause the designer to fail to completely scan the diagram.

Description

Model-based layout is a proposed feature for Argo/UML that is intended to help designers answer task-specific questions about the design. It is an automated layout feature which makes use of standard layout algorithms, but adds further constraints that position diagram nodes in diagram regions based on semantic properties relevant to the task at hand.

See (a) Standard automated layout of a state diagram, (b) Model-based layout of a state diagram a shows an example of a state machine diagram for an alarm clock as it might appear after a standard automated layout. Each state is shown with its state invariant condition. If the designer wanted to check each state in which the alarm was ringing, he or she would have to visually scan each state in the diagram and interpret the meaning of each invariant. Verifying completeness of non-existence properties, e.g., that no state allows both ringing and snoozing, always requires a complete scan. Furthermore, designers are likely to mentally factor the search criteria to simplify initial scans and come back to candidate states. For example, a designer might first scan for all states where ringing is allowed and then reconsider them in terms of whether snoozing is allowed. When using this strategy, short-term memory loads and the associated risk of skipping important elements increases with the complexity of the search criteria.

See (a) Standard automated layout of a state diagram, (b) Model-based layout of a state diagram b shows how the same state diagram would appear after model-based layout. Each row and column is labeled with the name of one of the variables used in the state invariants or the negation of that variable. The intersection of each row and column defines a rectangular region. States are constrained to appear within all appropriate regions. As long as the region constraints are satisfied, standard layout algorithms are used to improve readability by, e.g., reducing edge crossings. In this example, the rows and columns are arranged as they would be in a Karnaugh map (Ercegovac and Lang, 1985). To answer questions about states in which the clock is both ringing and snoozing, the designer need only scan states within the ringing and snoozing region. Furthermore, in contrast to the global scanning approach, increasingly narrow search criteria tend to make scanning easier with model-based layout. Even if the designer must scan the entire diagram for some reason, diagram nodes are grouped by relevant semantic properties, thus helping to reduce the potential for short-term memory thrashing.

Layouts constrained to the cells of Karnaugh-maps are possible only when the constraining model attributes are a small number of boolean variables or conditions. In the more general case, any diagram region can be associated with an arbitrary condition; conditions are joined with logical-and where these regions overlap; and diagram nodes that satisfy the condition for a given region are placed within that region. Diagram nodes that satisfy the conditions of two disjoint regions are shown in both of them, while nodes satisfying two adjacent regions are positioned to straddle the common boundary. Diagram nodes that do not satisfy any region constraint are placed outside of any region. For example, a UML class diagram could be arranged on a Venn diagram with three circles labeled with the names of three members of the unit testing team.

Designers specify how these layouts are constructed by using one of the tabs in the model-based layout window. The first tab contains on-line documentation for this feature. The second tab assumes a row and column layout and prompts the designer to enter the conditions for each row and column. Exact sizes are not specified; rather, they are determined by the nodes that fall within any given region. That is to say, a cell will be exactly wide enough to comfortably fit the nodes that logically belong there. The third tab ( See Configuring model-based layout with arbitrary constrained regions ) allows the designer to take more control by specifying the size and location of rectangular, circular, and polygonal regions and their conditions. In each tab, several predefined layout options are provided based on experience with object-oriented design and new layouts may be saved for later reuse. The automated layout algorithm will do the best that it can to position nodes within these specified regions. If a region is too small for all the nodes that belong there, then some of the nodes will overlap others. Both tabs contain a preview of the resulting layout with a number shown in each region indicating how many nodes will be positioned there.

Once the designer indicates that all layout constraints have been specified then a new diagram is generated with the requested layout. In this diagram, each node may be manually moved, but only within the constraints of its logical region. Row and column layouts may be adjusted by changing the size of a row or column. In turn, this will cause nodes in subsequent rows and columns to shift.

Mapping to theory

The reasoning leading to this feature is described above. To sum up, model-based layout allows designers to more effectively answer task-specific questions that arise during design. Designers working with diagrams arranged via model-based layout are expected to scan semantically defined regions rather than scanning the entire diagram. This is expected to allow them to answer task-specific questions more quickly, using fewer short-term memory resources, and with fewer oversights.

Construction Support Features

Selection-Action Buttons

Background

Argo/UML provides a toolbar of diagram elements that works very much like those found in other CASE tools. For example, the class diagram toolbar contains buttons for making new classes, new interfaces, new relationships between classes, and others. This is familiar to people who have used other CASE tools or drawing applications, but it is actually a rather poor interface for constructing structured diagrams because small targets that are far from the central work area are hard to select with the mouse. Furthermore, toolbar actions are typically too fine-grained and must be combined to achieve basic design manipulations. Although these difficulties with toolbars are straightforward, the ubiquitous use of toolbars may have prevented CASE tool developers from pursuing better interfaces. Argo/UML provides a new feature that builds on the familiar concept of a toolbar but avoids its disadvantages.

Description

When the user selects a node in a UML diagram, several handles are draw on it to indicate that it is selected and to provide user interface affordances to resize the node. Argo/UML also displays some "selection-action buttons" around the selected node. See Selection-action buttons on a UML class, interface, and state shows the handles and selection-action buttons on a UML class.

Selection-action buttons offer common operations on the selected object. For example, a class node has a button at 12-o'clock for adding a superclass, one at 6-o'clock for adding a subclass, and buttons at 3-o'clock and 9-o'clock for adding associations. These buttons support a "click or drag" interaction: a single click creates a new related class at a default position relative to the original class and creates a generalization or association; a drag from the button to an existing class creates only the generalization or association; and, a drag to an empty space in the diagram creates a new class at the mouse position and the generalization or association. Argo/UML provides some automated layout support so that clicking the subclass button three times will position the new classes so that they do not overlap.

Selection-action buttons are transparent. They have a visibly recognizable rectangular shape and size and they contain an icon that is the same as the icon used for the corresponding type of design element on the standard toolbar. However, these icons are unfilled line drawings with many transparent pixels. This allows selection-action buttons to be overlaid onto the drawing area without overly obscuring the diagram itself. Also, the buttons are only drawn when the mouse is over the selected node; if any part of the diagram is obscured, the mouse can simply be moved away to get a clearer view of the diagram.

Most CASE tool user interfaces are inspired by MacDraw-style drawing tools. These tools give the user total control over the order of their actions, but no support for ordering actions effectively. Typically, the toolbar buttons correspond to tiny actions, and it is up to the designer to form a plan that combines these tiny interface actions to achieve a task-level goal. For example, the designer might think, "I want a base class with a subclass." The plan for doing that requires three normal toolbar clicks, two diagram clicks, and a drag. But if the designer wants a base class with five subclasses, he or she is likely to change the plan to reduce from eleven toolbar clicks to only two toolbar double-clicks (one to lock class mode and one to lock generalization mode). Expert users do this easily, but beginners have trouble and get distracted from the larger design task. With selection-action buttons, the tool "knows" that once you have a class it is likely that you will add a subclass. Adding subclasses can be done with as little as one selection-action button click per subclass, and there is much less need to plan or optimize user interface actions.

Mapping to theory

At the cognitive level, selection-action buttons are a real improvement over existing toolbars for two reasons.

First, Fitts' Law basically says that the time it takes to move the hand or mouse from one region to another depends on the distance moved and the size of the target region. Current toolbars are very poor in this respect since they are frequently used, far away from the work area, and have small target regions. In contrast, selection-action buttons are located very near the location in the diagram where the mouse is positioned. Also, it is reasonable to have bigger buttons since they are translucent and do not require dedicated screen area.

Second, simpler user interface interactions distract less from the design task. Byrne and Bovair (1997) describe an experiment that showed that people who have other things on their mind are likely to make procedural errors in complex user interface tasks. In particular, they commit super-goal kill-off errors: i.e., they finish one difficult part of the task and then forget about their overall goal.

Create Multiple

Background

Creation of design elements is a task that occurs at the beginning of every design project and recurs often throughout the project. In fact, email conversations with several Argo/UML users have indicated that they encountered difficulties in constructing their design diagrams before they get the benefit of Argo/UML's other cognitive support features. The create multiple feature proposed in this section is a novel user interface feature that automates and informs low-level construction activities.

One form of domain knowledge that can be applied to aid designers in construction is design patterns. The basic idea of design patterns is that certain design fragments have been found to be frequently useful in a wide range of design problems (Gamma et al., 1995). If a given fragment is known to be frequently useful, then it is reasonable that a designer will want to include it in the design at hand. In addition to the recurring design fragment itself, a design pattern includes an explanation of why the fragment is useful and the situations where it is applicable. Making design patterns easy for designers to choose and apply is expected to reduce the overall knowledge burden of designers during construction tasks.

The user interfaces of most current CASE tools provide equal access to all features of the tool. For example, standard toolbars are a user interface element that provides equal access to all features and does not take advantage of the task-specific context or knowledge of the design domain. Also, most CASE tool user interfaces force the designer to frequently switch between keyboard and mouse input devices to alternatively place design elements and specify their names and properties. The create multiple feature helps designers specify design fragments by using just the keyboard to fill in a form. This is expected to reduce interaction time and effort for a common task as well as the feeling that arises of fighting with the tool when tools have difficult interfaces.

Description

"Create multiple" is a proposed Argo/UML feature that is intended to help designers easily create design fragments rather than individual design elements. These design fragments consist of multiple design elements and their relationships.

A designer opens the "Create Multiple" window via a menu command. The window consists of several tabs. The first tab offers on-line help on how to use this feature. The second tab, "By Name" ( See Mock-up of window to create multiple elements by pattern name ), allows the designer to select a design fragment by name and to enter customization parameters. The set of design fragments offered by Argo/UML depends on the type of the current diagram. For example, if the designer is working on a class diagram and chooses "Class Inheritance Hierarchy", the customization section will prompt the designer to enter the names of the classes in the hierarchy, and pressing the "Create" button will add the new classes and the proper inheritance relationships to the current diagram.

The third tab, "By Form", support better visualization of specific design fragments and their combinations ( See Mock-up for creating design fragments by form filling ). In this tab, several design elements are shown in the context of one or more interwoven design fragments. For example, See Mock-up for creating design fragments by form filling shows classes in both an inheritance hierarchy and a containment hierarchy, along with the composite pattern (Gamma et al., 1995). Although the tab shows a diagram, the position of the diagram elements cannot be changed and items cannot be removed or added. Instead, emphasis is placed on editing the names and properties of the available elements. Initially, all elements are shown with gray outlines and empty names. Whenever a name or other property is filled in, the element's color is changed to black. When the designer presses the "Create" button, all black elements are created and added to the current diagram. The names of design patterns are shown near the elements that participate in those patterns. Clicking on one of these names brings up on-line help describing the design pattern and explaining its applicability.

Regardless of which tab is used, the bottom of the "Create Multiple" window shows a summary of the elements that will be created when the designer presses the "Create" button. For example, in See Mock-up for creating design fragments by form filling the summary indicates that the designer has specified four new classes and two existing ones. Whenever a name in the "Create Multiple" window matches the name of an existing design element it is assumed that the existing element should be used rather than creating a new one. This allows the designer to graft new fragments onto the existing design. The name fields use combo boxes to aid the user in entering the names of existing design elements; the list of offered names is filtered to include only appropriate elements, and the names of any appropriate elements that were selected appear at the top of the list.

Some elements in the presented design fragment use check boxes to indicate whether they should be created or not. This allows for the creation of unnamed design elements. Also, some elements of the design fragment may be mutually exclusive alternatives. For example, in a fragment that could include a direct connection or a mediator class, a "Use Mediator" checkbox would insert a class in the middle of the diagram if checked; otherwise, the mediator class is shown in gray and black associations are drawn directly between the cooperating classes.

Mapping to theory

The "Create Multiple" feature is inspired by the theories of designers' limited knowledge, reflection-in-action, associative memory, Fitts' Law, and limited short-term memory. These are discussed, in order, below.

Design patterns are a form of knowledge that is specific to the domain of object-oriented software design. Patterns can also be identified in specific application domains. However, a given designer has limited knowledge and is unlikely to be aware of all the design patterns that are applicable to the design at hand. Even an expert designer may have difficulty recalling known design patterns at times when they are applicable. Forms in the "Create Multiple" window prompt designers to consider applicable patterns in the normal course of construction. The links to on-line documentation provide further knowledge support. Several design support tools have been built to help detect or document design patterns (e.g., Seemann and von Gudenberg, 1998; Keller et al., 1999). However, none of these tools effectively use patterns to aid construction.

Some tools offer design template files as a form of knowledge support for construction. However, these design templates are difficult to combine with each other and with elements of the design at hand. The grafting behavior of the "Create Multiple" feature addresses the fact that designers will not know what design patterns are appropriate until they have partially specified the design. The need to make design decisions in the context of a partially completed design rather than at the start of the design process is identified by the theory of reflection-in-action.

When design patterns are offered, they provide a visual cue to the designer to consider how that pattern might fit into the design at hand. For example, when the designer sees the composite design pattern offered, he or she is cued to recall or imagine the composite relationships that belong in the design at hand. Each element with an empty name is a prompt for the designer to think of candidates for that position in the design fragment.

Since the "Create Multiple" window consists of standard widgets for text entry, it can be operated entirely via the keyboard rather than the mouse. This provides an important alternative to standard diagram creation features that are heavily mouse-oriented. Most software designers are experienced typists and are expected to appreciate the keyboard-only option. Since the designer may select target fields by using the tab key, rather than the mouse, the size and location of the fields is not so critical and small elements can be used. This is in contrast to mouse-centric editing interfaces in which smaller target areas increase selection time as described in Fitts' Law (Fitts, 1954).

Furthermore, since the positions of nodes cannot be changed in the "Create Multiple" window, there is no need to provide distinct user interface modes for diagram editing and property editing. Instead, a single, familiar form-filling interaction mode is used. It is expected that using a "mode-less" interface will reduce the need for the designer to plan his or her interactions with the tool, and thus will keep more short-term memory resources available for task-level planning.

Possible extensions

One possible extension to this feature would be to build more knowledge about the applicability of each design pattern into the tool itself. This could be done by augmenting each pattern with a guard condition that would disable patterns that are inappropriate for the design goals or the initially selected design elements. Those patterns that are appropriate could be grouped or automatically ranked according to their suitability for achieving specific design goals.

Two other possible extensions would be to supply wizards that prompt the designer for additional pattern creation parameters as needed, and to define critics that are related to the pattern as a whole rather than the individual design elements that comprise it.

Related work

The literature on design patterns has focused on collecting patterns into pattern catalogs (e.g., Gamma et al., 1995). Ideally, the resulting collections define a "pattern language" consisting of the key design patterns for a given domain (Alexander et al., 1977). This approach serves to document the patterns used in a given design community, and it builds agreement among those designers who choose to study the pattern language, but it does not strongly support designers in applying design patterns. To be more effectively used, design patterns must be more readily available to designers at the time when they are needed. Also, the pattern language approach requires that designers learn the patterns before they are needed. In contrast, the "Create Multiple" feature offers design patterns directly in the tool that designers use to build the design, and it offers designers the ability to choose from the visually offered patterns rather than recall one by name.

Coad and colleagues (1999) proposes a set of design patterns for business applications. Coad has built support for these design patterns and others into the Together/J UML tool. Constructive pattern support in Together/J is similar to the "By Name" method of pattern selection proposed for Argo/UML. In each feature, the tool contains knowledge about available design patterns and offers them to the designer. However, Together/J presents only the names of each design pattern rather than offering them visually. This helps automate the design construction task, but it assumes that the designer has fairly complete knowledge of the available patterns and their applicability. In contrast, Argo/UML's form filling method offers design patterns visually, in a way that prompts designers with potentially useful design fragments without requiring foreknowledge of a pattern language. Furthermore, Together/J grafts new elements into the design in a preprogrammed way that cannot be specified by the designer. In contrast, Argo/UML considers grafting as a key part of pattern application.

Visual Blender

Background

Design is a creative activity. Creativity in object-oriented design need not be the bold creativity found in the arts or the paradigm shifts needed for major scientific discoveries. It is simply the daily creation of solutions to design problems.

Designers often come up with new ideas for solutions while brainstorming with other stakeholders using a whiteboard. Whiteboards fit the Geneplore theory in that they allow for generation of ideas without evaluation. However, whiteboards are passive and do not help designers who need help in being creative. Discussing designs with other stakeholders can lead to novel combinations of ideas that neither person would have thought of alone. However, such meetings require at least two designers to work together, and they might be made more effective if the participants brought more creative ideas that they generated independently before the meeting.

Description

Argo/UML's proposed visual blender feature is intended to help individual designers generate creative ideas by exploring combinations of existing ideas. It does this by presenting visual images that emphasize the combination or interaction of design concepts. The various parts of each image are labeled with terms taken from the partially specified design or a list of terms entered by the designer.

Designers activate the visual blender window ( See Mock-up of the visual blender window ) via a menu command. The window consists of several tabs. The first tab contains on-line documentation for this feature. The second tab lists a set of terms to display on the images. These terms are initially taken from the names of elements in the current design, but the designer is free to edit the list. The third tab and any additional tabs show the images. The "New Tab" button inserts a new tab where new images will be shown and shifts existing tabs to the right. Inserting tabs provides a convenient way to save and access images that the designer might want to review later.

Each image contains a predetermined set of label locations that can be filled in with terms from the term list or other text entered by the designer. Each label is displayed in a text field that allows the designer to manually change the term to another from the term list or enter new text. Each label can also be locked to prevent accidental change. The "Change Image" button replaces the image on the current tab with a new image from the image library. Changing the image will automatically add some random terms from the list if the new image has more predefined locations that the previous one. The "Randomize Terms" button will replace all unlocked terms in the current image with new terms selected randomly from the term list. As the terms are randomized, they are briefly animated in a way that suggests the rotating wheels of a slot machine. The text field at the bottom of the window is intended for the designer's notes and is shared among all tabs.

Mapping to theory

The proposed visual blender feature is primarily inspired by the Geneplore theory of creativity and, specifically, the visual combination method of generating new ideas. The cognitive theories of associate memory and fixation also play a role. The end result is a feature that is fairly similar to the suggested exercises for curing writers' block discussed in Section 2.1.3.

The visual blender feature uses a window that is independent of the main Argo/UML window to emphasize that the designer is free to generate new ideas without the constraints that normally apply. In the visual blender window, design critics are not active and the formal UML syntax is not enforced.

The images displayed in the visual blender window are intended to suggest a wide range of logical relationships between the items labeled with design terms. These images serve as cues for the designer to recall or imagine the ways that the suggested relationships apply to the design at hand. The images themselves are drawn as rough sketches to avoid suggesting vivid colors or forms that may cue the recall of distracting memories of real world people or objects. Instead, the design terms themselves are the most visually compelling elements of each image, and are expected to help designers focus on the concepts and relationships of the design at hand.

The potential for cognitive fixation should be considered when presenting the designer with cues that take the form of examples or suggestions. As discussed in Section 2.2.3, designers are likely to fixate on examples that seem appropriate, even if they are not in fact appropriate. The visual blender feature mitigates the risk of fixation in two ways: the images presented are visually rough to imply that they are not finished examples, and the selection of design terms is done in an obviously random way to avoid any assumption that they are prepared examples.

Several aspects of the visual blender feature are also found in the suggested cures for writers' block. In both cases, the activity is an exercise that takes place outside the normal constraints of the design task. Also, both activities employ obvious randomness to help separate them from the main design task and to mitigate the risk of fixation. However, the proposed visual blender feature differs from the writers' block exercises in that the terms used in the visual blender images are drawn from the partially specified design rather than being completely random.