10.5. Configuring Perspectives

The explorer is designed to be user configurable, to allow the designer to view in his or her preferred way.

10.5.1. Perspectives Tag

button 1 click on the NavConfig icon () brings up the explorer perspectives dialog (see Figure 10.2, “Explorer perspectives dialog box”).

Figure 10.2. Explorer perspectives dialog box

Explorer perspectives dialog box

The dialog box has at the top two tabs, labeled Perspectives and Panes. The first of these is the default, but can be selected explicitly by button 1 click on the tab.

The top half of the dialog contains a text area with a list of all the currently defined perspectives and to the right three buttons stacked vertically. Button 1 click can be used to select a perspective, with CONTROL and SHIFT keys used for multiple perspectives.

  • New. This creates a new perspective from scratch with no rules selected.

  • Remove. This removes the selected perspective(s).

  • Duplicate. This copies the selected perspective(s) so it/they can be used as the basis of a new perspective.

    [Warning]Warning

    In the V0.14 release of ArgoUML this function, although not grayed out, has no effect.

The lower half of the dialog contains two text areas. The one on the left, labeled Rules Librarycontains possible expansion rules to be expanded in turn to create the hierarchy. The one on the right contains the actual rules chosen for the hierarchy.

[Warning]Warning

In the V0.14 version of ArgoUML, the left bottom area which should show the "Rules Library", but remains empty at all times. Hence it is impossible to add any rule to any perspective.

Separating the two areas are buttons labeled >> and <<. The first of these transfers rules selected on the left to the text area on the right—i.e. it adds rules to the perspective. The second transfers rules selected on the right to the text area on the left—i.e. it removes rules from the perspective.

The rules are applied in turn to the overall project (UML model) to create the top level list. They are then reapplied in turn to each of the elements in the top level list to create the next level hierarchy, and so on until no further expansion is possible.

At the very bottom right is a button labeled OK to indicate that all changes are complete. button 1 click on this button will close the dialog window.

[Note]Note

There is no Cancel button, because all changes take immediate effect.

10.5.2. Panes Tag

This dialog is obtained by using button 1 to select the Panes tab after button 1 click on the NavConfig icon () has brought up the explorer perspectives dialog (see Figure 10.3, “explorers dialog box”).

Figure 10.3. explorers dialog box

explorers dialog box

The explorer was conceived as being able to offer multiple views simultaneously, with up to three panels of hierarchy. This dialog offers control of these panels, with an option to show or not show each panel, and the option of the second and third panels to be rooted at the selection on the previous panel, or to show the previously used hierarchy.

[Caution]Caution

This functionality is not yet implemented in ArgoUML. Only the first panel is ever shown, which is always rooted at project. All other options are grayed out and unavailable.

When using the explorer, it is worth bearing in mind that this is a useful visualization of the model, it is not solely for navigation and selection. It is also useful for users to easily (meaning a few mouse clicks without having to arrange a diagram) visualize the model structured according to some perspective. For example, show me the state nesting, or show me the class inheritance tree, or show me the package nesting, or show me the list of actors.

The idea with the second and third nav tree panes, is that sometimes it is easier to explore the tree to a certain level in one tree and then continue expanding in a second tree . Since each tree will not be so deep, it will look more like a list.

For example, look at the way javadocs are viewed with frames: the packages are selected from one list, and interfaces, classes, and exceptions in that package are shown in a second pane. In the case of javadocs, the second pane has a tree with three roots that are always expanded, but it is visually presented as three lists with three headers.

The other suggested use of a second or third nav panel is to list recently visited model elements. This is simliar to the recently visited files listed on the File menu of most applications, but for model elements rather than files.

The motivtion is the fact that designers frequently “interrupt” themselves: they are thinking of working on one part of the design, and then they make a decision that needs a change in some other part, and then that has an implication on some other part, and… and… and… the designer forgets what it was they were originally trying to accomplish. They need to “pop their mental stack” to come back to finish what the started. If they fail to do that, they leave half-finished fragments all over the design which always seem to come out as soon as it is presented to someone else.

A recently visited list should be LIFO (stack) ordered, or FIFO (queue) ordered. The goal would be to help designers come back to finish what they were doing, or simply to help them switch between two or three related parts of the design. The Navigate Back and Navigate Forward buttons in the toolbar serve the same basic purpose and use a lot less screen space.

ArgoUML's tear-off tabs (see Section 7.4.2, “Looking at Different Diagrams Simultaneously” also help with alternating between views, but sometimes users don't want to work with so many separate windows.

This is the theory that motivates the idea of multiple nav panes. For more information see Jason Robbins' PhD dissertation http://argouml.tigris.org/docs/robbins_dissertation/. One practical usability concern is available screen space and another is visual complexity. For this reason the multiple panes have yet to be implemented in ArgoUML while more pressing issues are addressed.