Login | Register
My pages Projects Community openCollabNet

Usage Scenario

The goals of this chapter are to demonstrate that Argo/UML is a useful and usable object-oriented design tool and to demonstrate the use of its cognitive support features in the context of a plausible design session.

Design of any real-world software system is a long-term process consisting of many hours of work spread over several design sessions. Opportunities for different kinds of cognitive support are distributed over the entire design process. The scenario in this chapter is composed of five scenes, each demonstrates how cognitive support may be provided at different stages of design. Each scene is presented using a condensed timeline to quickly reach the point of cognitive support; actual usage is not expected to be so densely packed with cognitive support opportunities.

The example design problem addressed by the designer in this scenario is the design of a university telephone enrollment system. This is a fairly standard design exercise that has been used in introductory books on UML (e.g., Quatrani, 1998; Booch, Rumbaugh, and Jacobson, 1999).

This scenario assumes that the designer is already familiar with the application domain and object-oriented design techniques, and that he or she has had some experience with Argo/UML. Furthermore, it is assumed that he or she has a general solution approach in mind.

Scene 1: Initial Construction, Error Detection, and Correction


In this scene, the designer dives right into construction of the design by placing design elements into a design diagram. Argo/UML supports construction in many of the same ways as standard CASE tools, but provides extra support for construction as well as error detection, error correction, and reminding.


See Argo/UML initial screen shows the screen that a designer first sees after starting Argo/UML. Argo/UML provides the standard type of CASE tool interaction that object-oriented designers are familiar with. The designer can place design elements into a diagram by clicking on a toolbar button and then clicking in the diagram. Relationships can be defined by selecting the type of relationship from the toolbar and then dragging from one design element to another.

The designer knows that classes will be needed to represent students, classes, and rooms. These are easily created via the toolbar buttons. After the designer names one of the new class icons "Class", a wavy red underline clarifier is shown under the name. The designer moves the mouse pointer over the wavy red underline and sees a small pop-up window stating "Change Class to a Non-Reserved Word." In this case, the headline of the detected problem is enough to prompt the designer to change the name to "Course". The designer names the other classes "Student" and "Room".

Additional wavy red underlines are shown in the other compartments of each class icon and a yellow PostIt note appears at the top left of each class. The designer moves the mouse cursor to check out these other errors and sees, for example, "Add Attributes to Student" and "Add Associations to Student." The designer recognizes both of these as prompts to specify additional aspects of the model.

The designer uses the familiar toolbar button style of interaction to define associations between Course and Room to model course locations. Then he or she adds an association from Course to Student to model course enrollment. Building the model to this point has required a fair amount of clicking and dragging, so the designer decides to use the selection-action buttons on Course to define the waiting list relationship between Course and Student.

At this point, the designer recalls the requirement that three types of students need to be treated differently, so he or she uses the subclass selection-action button on Student to define three subclasses with three mouse clicks. After the new classes are named "ugrad", "Grad", and "Extension", the design appears as shown in See After placing initial classes .

The designer continues to build the model by creating a new class for professors. Since using selection-action buttons seems easier than using the toolbar, the designer decides to drag from the association selection-action button on Course to create a new class and then names it "Prof". Then, the designer recalls the requirement that graduate students may also teach classes and renames the current class "Teacher". Next, the designer clicks the subclass selection-action button on class Teacher to create a new subclass for professors and the designer drags on the subclass selection-action button to make a new generalization edge to the existing Grad class.

At this point, the designer feels that substantial work has been done quickly and that it is now time to fill in some of the blanks that were left. While class Grad is selected, several clarifiers are shown, prompting the designer to point at them with the mouse. Pointing at the yellow PostIt note in the upper left of the Grad class produces a pop-up window with the text "Change Multiple Inheritance to Interfaces." In this case, the prompt is not enough to tell this particular designer what to do. So he or she uses a pop-up menu to get a list of all outstanding criticism on class Grad and selects the one labeled "Change Multiple Inheritance to Interfaces." This item is the first item on the pop-up menu because the designer opened the pop-up menu with the mouse over its yellow PostIt note.

When the item is selected from the pop-up menu, the ToDoItem tab at the bottom section of the screen now changes to show the detailed description of the detected problem (see See "To do" item description ). The designer does not understand the steps described in the third paragraph but thinks that the item is probably not relevant at this stage in the design process. He or she decides to investigate the provided wizard to see if resolving the item can be done easily. Pressing the "Next>" button at the bottom of the ToDoItem tab produces the first step of the wizard. The designer notices that the blue progress bar on the "Change Multiple Inheritance to Interfaces" item in the "to do" list has only moved a small amount, and decides that fixing this particular problem might require more learning and effort than he or she wants to spend on it at this time. Instead, the designer presses the "Add Item" button on the ToDoItem toolbar and enters a personal reminder to learn more about multiple inheritance in Java before it is time to implement the design.


In this scene, Argo/UML allowed the designer to directly manipulate the design in familiar ways. Meanwhile, Argo/UML provided knowledge support that helped detect errors and incompleteness in the design and guided the designer in resolving identified problems. Furthermore, selection-action buttons supported construction by providing a style of interaction that better matched the goal structure of the design construction task. In the final part of this scene, the designer added a reminder to Argo/UML's "to do" list to defer a decision for which he or she lacked needed knowledge.

Scene 2: Cleaning up the Design to Communicate Intent


Now the designer has placed a number of design elements and relationships in the design diagram. But the visual organization is unclear. In this scene, the designer cleans up the design diagram to more clearly communicate its intent.

In this design problem it is assumed that class Course is a central concept and its importance should be indicated as such in the design diagram. In contrast, it is assumed that rooms in this system are secondary. Likewise, the enrollment relationship is more fundamental to the design than is the waiting_list relationship. Furthermore, rooms must relate to facilities records that are supplied daily via a file transfer from a facilities management system, while course information can be edited at any time via an applet on a web page.


The designer moves class Course to be slightly above the center of the design diagram. This visually implies that class Course is a central concept of the design. It also puts some of the classes too close together and makes some associations diagonal rather than rectilinear.

The designer then uses the mouse to move the other classes into their proper positions around class Course. Dragging the classes into position causes them to be somewhat misaligned with each other. The designer then uses the broom alignment tool to restore the visual groupings as shown in See Reorganized class diagram . In particular, since the classes for undergraduate students, graduate students, and university extension students all fulfill the same role in the framework, the designer establishes a visual group for them. This is done by pushing them upward with the broom until they are horizontally aligned, then pressing the space bar to make them evenly spaced.

One convention of object-oriented design diagrams is that important relationships should be drawn with short, straight edges, while less important relationships are often drawn using bent edges. The designer accomplishes the straight edge effect for the enrollment association by dragging on a point on the association to add a new vertex. When the vertex being dragged is near a node, such as class Course, the segment of the edge between the node and the mouse is automatically kept straight or rectilinear. The new vertex is automatically removed on mouse release because it is collinear with the endpoints of the edge. For the less important waiting_list association, the designer drags a point on the association to the left. The result is a two-segment angled association that appears secondary to the straight association.

Based on prior experience, the designer feels that the means by which data will be supplied will play an important role in upcoming design decisions. Since the UML notation does not define a way of documenting information sources, the designer uses two unstructured graphical elements to indicate these sources. A UML comment node could be used to textually describe the data source, but the graphical annotations shown in See Class diagram with annotations describing data sources illustrate the concurrency and data volume of each source in a way that will make a more immediate impression on the designer's colleagues.


In this scene, the designer used the broom alignment tool to help establish visual properties that emphasize some aspects of the design over others. This helped to communicate the intent of the design by adding new information in the form of secondary notation. In this case, the secondary notation was expressed with the position of elements on the page, alignment, spacing, and the straightness of edges. Informal annotations helped to add further information that was important to this design, even though it could not be expressed using the standard design notation.

Scene 3: Answering Questions that Arise During Design


As the design process progresses, a multitude of design decisions must be made. Each of these decisions must be informed by the designer's understanding of the problem domain, solution domain, and the state of the partially completed design. Designers formulate and reformulate their understanding of the state of the design as different design issues are addressed. Previous work on program comprehension has proposed a hypotheses-driven model in which programmers alternatively form questions and answer those questions (Brooks, 1983; Koenemann and Robertson, 1991). This scene demonstrates some of the questions that can arise while working with a UML design and how Argo/UML's cognitive support features might support designers in answering them.

In this scene, the designer has been working on the design for some time and its complexity has grown to, say, fifty classes and fifty associations spread over several class diagrams. See One class diagram of many after the design has grown shows one of these diagrams. At this stage in the design process, visually scanning design diagrams is no longer a reasonable way for the designer to answer his or her questions about the state of the design.


One of the critics offers the advice that the designer should consider combining two classes. The designer is puzzled as to why that advice is offered and looks at its detailed description. The critic suggests combining the Room and Reservation classes because instances of class Room will always be allocated in a one-to-one correspondence with instances of class Reservation. The designer realizes that the multiplicity of the held_in association is not specified correctly: each room should be able to have zero or more reservations. This prompts the designer to fix the problem at hand and then ask the broader question, "Does every association have the right multiplicity?"

Opportunistic table views help answer this question by presenting the design in a dense format that encourages systematic scanning. The designer clicks on the "As Table" tab at the bottom of the main editor window and selects the "Associations vs. Properties" table view ( See Table view of associations and their properties ). Using this view, the designer considers each row of the table by looking at the name of the association, its source multiplicity, and its destination multiplicity. As an aid to systematic scanning, the designer turns on Argo/UML's row highlighting option and moves the selected cell down the table, row by row. Moving the selection causes each row to be highlighted in turn, thus helping the designer keep his or her place.

While scanning the associations, the designer finds that the enrollment association has the right multiplicity, but its aggregation is wrong. This prompts the designer to ask the question, "What about the aggregation of the other associations?"

To answer this question, the designer can simply scan down the table again, this time looking at a different column. The designer begins to do this visually, without moving the currently selected cell or changing the highlighted row. However, at some point the designer may need to refer to requirements or project-related email that is outside the Argo/UML tool. If that happens the designer is likely to move the selected cell to the current row of interest to avoid losing his or her place. From there, systematic scanning can continue either visually or by continuing to use row highlighting as an aid. Once the designer completes the design excursion to satisfactorily answer the second question, he or she must return to the original question of multiplicity. Argo/UML's "instant replay" feature helps the designer recover from the design excursion by rapidly repeating the sequence of recently highlighted rows. This tells the designer how much progress was made on the first scan of the table and where to pick up again.

Eventually the designer feels that it is time to implement persistence. A natural question that arises in this recurring design task is "what are the aggregation hierarchies in the design?" This question is hard to answer if aggregation relationships are not emphasized in a diagram or if they are spread over multiple diagrams. Navigational perspectives help answer this question by presenting tree views of tree-structured relationships in the design. Aggregation of classes is one of the predefined navigational perspectives because it is known to be frequently useful in object-oriented design. The designer can simply select the "Aggregate Classes" item from the list of available perspectives above the navigation tree. This results in the tree view shown in See Aggregate classes navigational perspective .

Another design issue that relates to aggregation hierarchies is how objects can be serialized and communicated between distributed components. In addition to understanding aggregation, the designer must ask "Which classes reside on both the client and the server?" Model-based layout is a proposed feature that could help to answer this question by reorganizing the layout of diagram elements but still presenting them in the same context. For example, model-based layout could make the client/server division visually clear, while still showing associations between classes. It does this by automatically positioning elements while constraining them to appear in diagram regions based on model properties. In this example, the designer could choose the "Layout Diagram..." menu command and fill out a dialog box as described in Section 4.3.3. A mock-up of how the resulting diagram might look is shown in See Mock-up of model-based layout .


In this scene, the designer asked several questions about the state of the partially completed design and answered them with the help of cognitive support features. Opportunistic table views helped the designer systematically scan the table and recover from certain kinds of design excursions. Then, navigational perspectives made important hierarchical structures in the design clearly evident. Finally, model-based layout helped make hidden properties of the design visible, while still maintaining the overall context of the design diagram.

Scene 4: Considering the Important Issues


Sometimes designers don't ask the right questions about their design because of oversights or lack of expert knowledge. This scene consists of four short interactions that each show how Argo/UML might prompt the designer to work more like an expert. The emphasis here is on the ways the tool can communicate guidance to designers; the contents of the provided guidance is assumed to be insightful and informative, but it need not always be authoritatively correct.


Simplicity is one design quality valued by many object-oriented design experts. As the design document grows, expert designers tend to look for ways to simplify the design to make it more understandable, maintainable, and extensible. In contrast, novice designers are less able to recognize and combat unneeded design complexity. Unneeded complexity can become evident when the designer reflects on the partially completed design after having worked hands-on with the design and increased his or her understanding of the design issues. Revisiting the example used in previous scenes, the designer will at some point notice the criticism of class Room. The suggestion to "Consider combining classes" prompts the designer to simplify the design where possible. In this case, the designer may change the multiplicity, as described above, or the designer could decide to simplify the design by having a single RoomReservation class. The actual decision should be based on the designer's understanding of the problem domain and the relative importance of different aspects of the system.

Another thing that differentiates expert from novice designers is that experts know the limits of their tools and languages and know where they break down and when to step beyond them. For example, when looking at the design checklist items provided for the cummulativeUnits attribute of class Student, the designer will see the checklist item "Does any other value need to be updated when this value is changed?" This prompts the designer to keep in mind the dependencies that are not represented in the standard UML design notation. Specifically, the designer is prompted to consider whether an attribute such as classStanding should be updated whenever cummulativeUnits is changed.

Expert designers also know to keep in mind how their task fits into the overall development process and their own role in the development organization. Organizational critics can prompt designers to consider issues that are important to the designer's organization, regardless of whether they are important to the designer. For example, one potential organization-specific critic might warn designers that incorporating untested components requires approval from the testing lead. This criticism cues the designer to consider how his or her design decisions will affect other project stakeholders, namely the testing staff. Taking the time to change the design or consult with the testing lead may not be in the designer's short-term interests, but more accurate planning and coordination is in the overall interest of the development organization.

When expert designers work hands-on with a design, they tend to keep in mind a great number of relationships and design details that are then used to inform design decisions. Less experienced designers may have difficulty keeping in mind the same information or recognizing the value of recalling certain details when making future decisions. For example, when reviewing the design of the server side of the university enrollment system, the designer might use Argo/UML's search utility to find all classes that reside in server components 1 . If the designer selects the row for class Course in the main query result table, then class Prerequisite will also be listed in the related result table. Seeing class Prerequisite prompts the designer to recall the relationship between Course and Prerequisite, and to consider whether class Prerequisite should be on the client or server.


These four short interactions have shown how features of Argo/UML can help all designers work more like expert designers. Design critics and checklist items convey expert advice to designers engaged in the design process. In particular, organization-specific critics inform the designer of the implications of design decisions to the larger development process. Furthermore, Argo/UML's opportunistic search utility helps designers notice the same relationships that expert designers keep in mind when working with the design.

Scene 5: Resolving Open Issues Before Reaching a Milestone


The design process usually progresses in a very complex, iterative way; however, there are some clear milestones along the way. This final scene gives an example of how Argo/UML can support the designer in resolving open issues to reach a design milestone.


Eventually, the designer will feel that the structural aspects (classes and associations) of the design are nearly done. In this scenario, it is assumed that the next phase of the design will address a very different set of issues related to the dynamic behavior of the system. Before making the switch to thinking about these behavior issues, the designer wants to finalize the structural issues as much as possible. As the design nears this milestone, the designer asks, "What is left for me to do?" This question might also arise when the designer is approaching a deadline or even the end of the workday. Alternatively, when the designer realizes that the design is far from reaching the next expected milestone, the designer might ask, "What needs to be fixed or finished?"

Argo/UML's "to do" list helps answer both of the questions above by displaying all outstanding criticisms in an organized way. Furthermore, Argo/UML can help the designer realize that the design is far from being complete and correct: if the number of outstanding criticisms gets too large, Argo/UML will change the color of the item count above the "to do" list. This provides a meta-cognitive prompt for the designer to switch from constructing new design elements to reflecting on the design and resolving identified problems.

In trying to reduce the number of outstanding items, the designer systematically moves down the list of items and considers each one in turn. Some "to do" items identify errors or incomplete parts of the design. The designer corrects some of these immediately while others require more thought. Some items on the "to do" list contain advice that the designer chooses not to follow in this case or suggested corrections that the designer feels are too risky or difficult. The designer skips past some of these items, leaving them on the list; other items are explicitly declined by pressing the Resolve button on the ToDoItem toolbar. Personal reminders that the designer added previously are now reviewed and some of them are resolved. Over time, the "to do" list is reduced to a few items that are not relevant to the milestone.

Once the explicitly identified criticisms have been resolved, the designer continues to look over the design to try to detect any remaining issues. When considering each design element, the designer looks for common problems based on past experience. Design checklists help augment the designer's own experience with that of expert designers. One example of this is presented in Scene 4.

After the designer has covered each element of the design document, he or she can gain further confidence in the state of the design by reviewing the design decisions that led up to this point. The history tab contains a time-ordered list of all criticisms raised and how they were resolved. The designer browses the list, giving particular attention to item resolutions that introduced new problems and how those secondary problems were resolved. The designer also uses the design history to check decisions that were not covered by earlier reflection on the design document because they did not result in design elements. For example, the designer's decision to not include a university administrators class might be documented only in the history. While reviewing past decisions, the designer asks "Why did I do it that way?" Comments entered into design history can help answer that question.

By this point, explicit criticisms have been resolved, checklist items have been considered, and the design history has been reviewed. The designer has also reflected on his or her own decisions and may be better able to apply that experience in the future. Now the designer feels ready to move on to the next set of design issues.


In this scene, several Argo/UML cognitive support features helped the designer to resolve outstanding design issues, and to feel confident about the structural aspects of the design. Design critics pointed out errors, incompleteness, and other issues that are mechanically detectable. The "to do" list allows opportunistic browsing of outstanding items, but in this scene it was used to systematically browse and resolve those items. Then, design checklists helped prompt and guide reflection on broader design concerns by being at-hand, by supporting systematic review, and by containing items authored by experts. Finally, Argo/UML's design history feature helped the designer review the decisions that lead up to the current state of the design.


The five scenes of the usage scenario presented in this chapter demonstrate how Argo/UML's cognitive support features can help designers in carrying out common design activities. These activities include design construction, error detection, error correction, reminding, clarifying the intent of the design, answering questions that arise during design, asking the types of questions that expert designers ask, cleaning up the design by resolving outstanding issues, and reviewing design decisions. Two other cognitive support features were not discussed in the scenario: the create multiple feature could have be used during construction (scene 1) and the visual blender feature could have been used to answer questions about creative alternatives (scene 3).

As noted at the beginning of this chapter, each scene is condensed to quickly get to the point of support. In actual design tasks, support opportunities are expected to be more widely spread out over time. However, one key aspect of many of the proposed cognitive support features is that they play an active role in identifying, or even creating, support opportunities. For example, design critics and clarifiers prompt designers to correct errors and create an opportunity for procedural support in error correction. Also, the highlighted number of outstanding items above the "to do" list serves to prompt the designer to switch to reflection on the design, thus identifying the need to systematically address open issues and creating an opportunity to support that need. Another example is the opportunistic search utility which prompts the designer to think of related elements when the designer requests a simple search, thus turning a normal design activity into an opportunity for cognitive support.

1. Argo/UML's search utility has not been implemented enough to perform the particular query in this example.