The Editing Pane - Practices

The Editing pane is the designer’s main work area, where UML diagrams are displayed and edited. A diagram-specific toolbar shows common operations and elements that can be added to the active diagram. You’ll learn about the operations and elements relevant to the creation of the models for the TCMS system throughout the rest of the chapter.

The Details Pane

The Details pane shows specific properties for the diagram or a selected model element. It’s presented as a tab pane with tabs for the following:

• To-Do Items: Shows outstanding critic-generated and user-generated items for the selected model object. This pane allows the user to add new to-do items, resolve a to-do item (wizards guide you through the process), snooze the critic (temporarily ignore the item), or email a human expert for advice on how to resolve a critic-generated to-do item (partially implemented).

   

• Properties: Displays the main, model-related properties of a model object such as name, stereotype, namespace, visibility, and association.

   

• Documentation: Allows the designer to enterJavaDoc tags for items such as author, version, or whether an item is deprecated.

   

• Style: Controls the appearance of the model object. Characteristics such as line and fill colors as well as size and shadow depth can be controlled from this pane.

   

• Source: Displays the equivalent Java or UML definition of the selected item.

   

• Constraints: Contains the UML Constraints Editor. UML constraints are invariants written (preferably) using the OCL.

   

• Tagged Values: Contains the Tagged Values Editor. Tagged values are name-value pairs that can be associated with a model’s element. A property that has been tagged with a given name will be assigned the value associated with the tagged value. There are several predefined UML tags provided that can be used in a model.

   

• Checklist: Will eventually provide a “user-level” to-do list. In the current release of ArgoUML this tab is currently grayed out.

   

The most important tab, and the one you’ll use the most is the Properties tab, which displays and enables you to edit any major features of the selected model element.

The To-Do Pane

The To-Do pane displays all to-do items (see the “Design Critics” section later in this chapter) in a tree-based view that can be dynamically sorted and grouped by priority, decision, goal, offender, poster, or knowledge type. To-do items can be of high, medium, or low priority. To-do items are categorized by design issue according to 16 predefined decision categories including Class Selection, Design Patterns, Code Generation, and others.

As you’ll learn later in this chapter, the To-Do pane also holds the output of the design critics. The grouping options By Decision, By Goal, By Offender, By Poster, and By Knowledge Type are intimately related to the work of the design critics.

The Menu Bar and Toolbar

The menu bar or main menu is organized around the following categories, and the toolbar offers shortcuts to commonly used menu items.

• File: From here you can manage your ArgoUML projects and import source code to be reverse engineered into UML class diagrams. You’ll also find other utility functions like printing, saving a graphic of a given diagram, and others.

   

• Edit: Provides the typical edit functions applied to the selected artifact(s) of the active diagram.

   

• View: This menu provides navigation features like tab pane navigation, and enables you to switch to a given diagram. It also provides the more familiar view controls like zooming and diagram grid management. There is also an option to toggle notations between UML 1.3 and Java.

   

• Create Diagram: From this menu you can create class, use case, state, activity, collaboration, deployment, and sequence diagrams.

   

• Arrange: Provides functions for the alignment, distribution, z-order, and fine positional adjustments of diagram artifacts.

   

• Generation: From this menu you can generate code for a class or all classes in a diagram.

   

• Critique: From this menu you can control ArgoUML’s unique Design Critics feature as explained later in the chapter.

   

• Tools: Currently unavailable, it will eventually provide a plug-in point for external tools.

   

• Help: System information and the About screen. ArgoUML doesn’t ship with a program-accessible documentation set or a context-driven help system.

   

Initial State

Once started, ArgoUML will create a brand new project or open the last saved project automatically, as long as you configure it to do so by choosing Edit -> Settings and selecting Reload Last Saved Project on Startup.

ArgoUML provides some powerful features not found in any other UML CASE tools. Many of these features stem from the field of cognitive psychology and attempt to make the software adapt to the working habits of the designer and in many areas it assists by making predictions on what the designer might do next.

The cognitive features of ArgoUML can be categorized as follows:

• Reflection in action: Acknowledges that complex systems evolve and designers heavily reflect on their designs. To support reflection in action ArgoUML contains features like Design Critics, Corrective Automations, To-Do Lists, Checklists, and the partially implemented User Model.

• Opportunistic design: Is based on the concept that designers follow a path of the least “cognitive cost”¹³ rather than a structured, hierarchical path. To support opportunistic design ArgoUML features To-Do Lists and Checklists and in the near future, a feature called Work Breakdown Structure. These tools help designers’ natural tendency to evolve their designs via a path of least resistance.

   

• Comprehension and problem solving: ArgoUML includes multiple views or perspectives of the working model in order to help designers rapidly gain an understanding of a model and help them discern new connections between model elements. Features of ArgoUML supporting this theory include the navigational perspectives as shown in the Navigator and To-Do panes as well as many wizards.

   

Design Critics

Design Critics are an automated user interface feature that provides assistance to a designer. Design Critics are a process that works in the background as the design process is being carried out by the designer. Using a series of heuristics, Design Critics provide feedback on the decision-making process. You can think of them as a set of rules that are applied by a rule engine to the state of a model, which produces a set of actions in a form that the user can choose to ignore. It’s a very unobtrusive feature. Feedback from the Design Critics is called critiques and appears as to-do items in the To-Do pane.

Design critics act as a guide and automated mentor. It’s expected that as the designer gains more experience the number of critiques will diminish. Design Critics can flag perceived anomalies in a model and automatically correct them at the user’s request. Critics can also integrate with other expert human designers via email. This feature is currently partially implemented and it will default to sending an email to the discussion list for users of ArgoUML.

Each critic monitors a specific design criterion and the result of its work is called a critique, which is a recommendation or statement about an aspect of a model that doesn’t appear to follow good design practices.

ArgoUML Design Critics are configured via the Critique menu item. By default the option is turned on, but you can turn it off by selecting Critique -> Toggle Auto-Critique. The Critique menu also contains the following options that you’ll need to configure:

• Design issues: Design issues have different categories and priorities assigned to them. In this particular window a list of the decision types with priorities ranging from zero to five (zero being off and five being the highest priority) is shown. The setting here is applied globally to all critics. Setting all decision priorities to zero will effectively deactivate the critics. The decision types available include Class Selection, Naming, Storage, Planned Extensions, State Machines, Design Patterns, Relationships, Instantiation, Modularity, Expected Usage, Methods, Code Generation, Stereotypes, Inheritance, and Containment.

   

• Design goals: Higher-level guidance for the application of critiques. The same priority system used for the design issues applies to the goals of a critic. The setting on this window applies globally to all design goals. Currently there is only one design goal category: Unspecified. Setting the priority of this category to zero will effectively deactivate all critics.

   

ArgoUML also provides an option for browsing the existing critics by selecting Critique -> Browse Critics. In this window you can modify certain properties of a critic such as headline (name), priority, and long description. You can also turn a critic on or off (“snoozing” a critic in ArgoUML terms).

Critics also manifest themselves graphically on certain modeling elements. For example, in the case of a class element, a yellow note symbol will appear in the upper-left corner of the class when there are critiques associated with the class.

For example, on a newly added class, a critique telling you to name the class will appear.. To view the critique you can right-click the class and select Critiques -> Choose a Name. This will select the critique in the To-Do pane.

There are 85 built-in critics in ArgoUML. Some of them watch over the naming of model elements as well as the aesthetic aspects of the model—for example, in preventing overlapping graphical elements. Other critics watch for places in a model where a pattern like the singleton can be applied or decide whether two or more classes should be combined. Still other critics check more fundamental flaws and the correctness features of a model, such as, for example, circular composition, illegal generalization, nonpublic interface operations, and interfaces with attributes.