9.9. The Critique Menu

This menu controls one of ArgoUML's unique features—the use of critics to guide the designer. The theory behind this is well described in Jason Robbins' PhD dissertation http://argouml.tigris.org/docs/robbins_dissertation/.

[Note]Note

A word about terminology: The critics are background processes, which evaluate the current model according to various “good” design criteria. There is one critic for every design criterion.

The output of a critic is a critique—a statement about some aspect of the model that does not appear to follow good design practice.

Finally a critique will generally suggest how the bad design issue it has identified can be rectified, by raising a to-do item.

[Note]Note

The critics run as asynchronous processes in parallel with the main ArgoUML tool. Changes typically take a second or two to propagate as the critics wake up.

9.9.1. Toggle Auto-Critique

This is a check box, controlling whether the critics are running. By default it is checked. If unchecked, then all critics are disabled, and any to-do items generated by critics (the only others being those the designer has added by hand) are hidden in the to-do pane.

9.9.2. Design Issues...

This menu entry brings up a dialog box controlling how critics associated with a particular design area are to be handled (see Figure 9.19, “The dialog for Design Issues....” ).

Figure 9.19. The dialog for Design Issues....

The dialog for Design Issues....

ArgoUML categorizes critics according the the design issue they address. There are 16 such categories. The critics in each category are discussed in detail in the chapter on critics (Chapter 14, The Critics).

The sliders may be set for each category to control the critics that trigger for that category. Setting a slider to Off will disable all critics in that category, and remove all associated to-do items from the to-do pane.

Setting a slider to a higher priority value will enable all critics at or above that priority level within the design issue category (Off being the lowest priority).

[Note]Note

The sliders are set by default to High for all design categories.

9.9.3. Design Goals...

This menu entry brings up a dialog box controlling how design goals are to be handled (see Figure 9.20, “The dialog for Design Goals....”).

Figure 9.20. The dialog for Design Goals....

The dialog for Design Goals....

ArgoUML has the concept that the designer will have a number of design goals to be achieved (for example good structural representation, detailed behavioral representation etc). Critics are associated with one or more goals.

This dialog allows the user to specify the priority of each design goal.

The sliders may be set for each design goal to control the critics that trigger for that goal. Setting a slider to zero will disable all critics in that goal, and remove all associated to-do items from the to-do pane.

Setting a slider to a higher value will enable all critics at or above that priority level within the design issue category (1 being the highest priority and 5 the lowest).

[Tip]Tip

It may be useful to think of this function as very similar to Design Issues... (see Section 9.9.2, “Design Issues...”), but with grouping of critics according to the outcomes of OOA&D rather than grouping according to the structure of UML.

[Warning]Warning

The V0.20 version of ArgoUML provides a single design goal, Unspecified, with its slider set by default to priority 1. However it contains no critics and so has no effect.

9.9.4. Browse Critics...

This menu entry brings up a dialog box controlling the individual critics (see Figure 9.21, “The dialog for Browse Critics....”).

Figure 9.21. The dialog for Browse Critics....

The dialog for Browse Critics....

This dialog controls the behavior of individual critics. To the left is a list of all the critics, to enable them to be switched on or off individually. For each critic there are three columns, labeled Active, Headline and Snoozed. The first of these is a check box, which may be toggled with button 1 click. The second is the headline name of the critic, the third indicates if the critic has been snoozed from the to-do pane (see Chapter 13, The To-Do Pane. A critic is only really active if the box in the first column is checked and the critic has not been snoozed.

Any critic for which the box in the first column is unchecked is inactive and will not trigger. In addition any to-do items associated with that critic will be removed from the to-do pane.

The V0.20 version of ArgoUML has a total of 90 critics, a few of which are incompletely implemented. They are described in detail by design issue category in the chapter on critics (see Chapter 14, The Critics).

To the right of the list are a series of fields, titled Critic Details, giving detailed control over individual critics. Selecting a critic in the list on the left will populate the fields for that critic.

The first field on the right is titled Critic Class: and then the full name of the class in ArgoUML that implements the critic. This name can be used as unique identifier of the critique, e.g. in conversations about the critic.

The first field below this title is a text box labeled Headline: giving the complete headline of the critic (which may be truncated in the list on the left).

[Note]Note

In the headline you may see the text <ocl>self</ocl>, which will be replaced by the name of the artifact in question when the critic is triggered.

The next field is a drop-down selector, labeled Priority:. The three options available are High, Medium and Low and specify the priority category of any to-do item generated by this critic. This does not alter the priority of the already existing todo items, only the newly generated ones. Changing the priority of a critic is not saved persistently.

The next field is labeled MoreInfo: and contains a URL pointing to further information with a button to the right labeled Go to navigate to that URL.

[Warning]Warning

In the V0.20 release of ArgoUML there is no further information available, and the Go button is always grayed out and disabled.

The next field is labeled Description: and is a text area with a detailed explanation of what this critic means. If the text is too large for the area a scroll bar is provided to the right.

[Note]Note

In this text area you may see the text <ocl>self</ocl>, which will be replaced by the name of the artifact in question when the critic is triggered.

The last field is a drop-down selector labeled Use Clarifier, with three options, Always, If Only One and Never.

Clarifiers are the icons and wavy red underlines drawn on the actual diagrams to indicate the artefact to which the critic refers. The original intention was to make the mapping from critics to clarifiers somewhat customizable.

For example one user might make a Missing Name critic show a red underline, another user might turn off the clarifier, or have it draw a wavy green underline or a blue questionmark. Critics with their clarifier's disabled would still produce feedback that is listed in the to-do pane.

[Caution]Caution

In the V0.20 release of ArgoUML this selector has no function whatsoever. It is for future development.

Underneath the fields are three buttons in a horizontal row.

  • Wake. It is possible to snooze a critic from the to-do pane (see Chapter 13, The To-Do Pane), which makes the critic inactive for a period. If the critic has been snoozed, this button is enabled and will wake the critic back up again. Otherwise it is grayed out.

    [Tip]Tip

    You can tell a snoozed critic, because in the list on the left it will be indicated in the third column.

  • Configure. This button is for configuring the critic.

    [Caution]Caution

    In the V0.20 version of ArgoUML this function is not implemented, and this button is always grayed out. It is for future development.

  • Edit Network. Right now critics are implemented in java code. That means end-users cannot add new critics.

    The idea of a critic network is that they would be a state machine like diagram with several steps. Each step would express a condition which, collectively with the other steps associated with that critic, articulates the “rule” that the critic is providing. If the rule fires, then remaining steps would define the steps of the wizard to help the user fix the problem.

    The ideas behind this are discussed in Chapter 4 of Jason Robbins PhD disseration ( http://argouml.tigris.org/docs/robbins_dissertation/diss4.html. In particular look at Figure 1-6 in this chapter and the related discussion.

    A suggested implementation is that the conditions could be written in OCL against the UML meta-model. A library of predefined conditions and steps would allow end-users to build new critics by combining those in novel ways.

    [Caution]Caution

    In the V0.20 version of ArgoUML this function is not implemented, and this button is always grayed out. It is for future development.

Finally the bottom right of the dialog contains a button labeled OK. Button 1 click here dismisses the dialog.