Argo/UML Features

Argo/UML prvoides the following features. Each feature is described breifly below.

Runs on any platform with Java 1.1
Standard UML Meta-Model
UML Design Editing (partially implemented)
Code Generation (partially implemented)
Cognitive Support
- Reflection-in-action
- Opportunistic Design
- Comprehension and Problem Sovling
Customization

Runs on any platform with Java 1.1

Argo/UML is coded entirely in Java and uses the Java Foundation Classes. This allows Argo/UML to run on virtually any platform. Argo/UML has been tested in the following environments:

Windows NT 4.0 SP3. Symantec Visual Cafe 2.1 and 2.5.
Windows NT 4.0 SP3. Sun JDK 1.1.5.
Sun Solaris 5.5.1. Sun JDK 1.1.5.
Linux with Blackdown JDK.

Standard UML Meta-Model

Argo/UML represents designs using a Java version of the UML 1.1 meta-model as described in the UML Semantics specification. We have made extensive efforts to keep this meta-model implementation true to the standard. For more information, see the uci.uml home page.

UML Design Editing

Argo/UML uses GEF, the UCI Graph Editing Framework to edit UML diagrams. The following diagram types are supported:

Class diagrams
State machine diagrams (near future)
Use case diagrams (near future)
Other diagram types will be available in the future

Code Generation (partially implemented)

We are looking for someone to design, implement, contribute a powerful, flexible, and extensible code generation facility.

Design Critics

Design critics are simple agents that continuously execute in a background thread of control. They analyze the design as the designer is working and suggest possible improvements. These suggestions range from indications of syntax errors, to reminders to return to parts of the design that need finishing, to style guidelines, to the advice of expert designers. Many critics offer to automatically improve the design. Critics are controlled so that their suggestions are relavent and timely to the design task at hand, bsed on information in Argo's user model. Critics never interrupt the designer, instead they post thier suggestions to the designer's "to do" list.

Corrective Automations (partially implemented)

Critics identify specific problems in the design and may offer specific solutions in the form of wizards or other corrective automations. These automations allow design improvements to be made faster and more reliably than they could be done by hand. Also, designers need not recall how to use the tool to achieve the suggested change.

"To Do" List

One difficulty designers face is keeping track of all the myrid details of thier task. It is all to easy to skip a step in the design process, leave part of the design unspecified, of make a mistake that requires revision. Argo provides the designer with a "to do" list user interface that presents action items in an organized form. These items can be suggestions from critics, reminders to finish steps in the process model, or personal notes entered by the designer. The choice control at the top of the "to do" list pane allow the designer to organize items in different ways: by priority, by decision supported, by offending design element, etc. Items are shown under all applicable headings. The "to do" list may also be viewed as a flat list.

User Model (partially implemented)

Argo's user model maintains information about the designer and uses that information to make the tool my useful. One way that it does this is by controlling critics so that only critics that are timely and relevant to the task at hand can make suggestions. In the future, the corrective automations and explanations offered by critics will also be tailored to the designer.

Argo's user model consists of the following parts:

Decision Model: Lists types of decisions that must be made when doing object oriented design. Each decision is associated with an level of interest from 0 to 5. A critic will not be active if the designer's interest in the decision that it supports is 0.
Goals Model (partially implemented): Presents a list of questions related to goals for the design project. Critics that support active goals may present suggestions.
Work Breakdown Structure (future): Lists the tasks that must be performed when doing object oriented design. Each task is associated with a level of activity and several decisions. This model serves the designer as a resource when deciding what task to do next.
Skill Model (future): Each designer has their own strengths and weaknesses. Argo's skill model keeps track of the designer's self-reported level of knowledge related to the problem and solution domains. The estimated time to fix a problem found by a critic depends on the designer's knowledge of domain concepts, design techniques, and tool features.

Checklists

Checklists are currently widely used in design review meetings, in part, because they remind designers to cover all design details and avoid common design errors. Argo provides checklists that serve the same purpose, but have several advantages over passive printed lists:

Argo's checklists are made specific to the selected design element. Each type of design element (e.g., Class, Attribute, Operation, Association) has its own checklist.
Irrelevant checklist items are automatically removed from the list.
The text of the checklist items are made specific to the design element being reviewed. For example, Argo uses element names instead of the pronouns that would be used in a printed list.
(future) Checklist items can provide the designer with wizards that help complete a specified design change. For example, the checklist item "Should the attribute Age be moved to one of the super classes of Person (e.g., Animal)" could launch a wizard to help move the attribute up the class hierarchy.

Checklists are somewhat similar to critics (in fact, they share some of the same implementation), however they differ in the level of specificity so much that we feel that they should be presented separately to designers. Critics look for very specific problems and provide specific suggestions when those problems are detected. The designer still makes the final decision about any design changes, but the critic can automate much of the analysis and work. In contrast, checklist items are much more general and vauge, they serve to remind the designer, but it is the designer who must do most of the analysis and work. Checklists are easier to author (see below), and useful checklist items can be upgraded to critics if appropriate.

Work Breakdown Structure (future)

This feature is not described yet.

Navigational Perspectives

Many design tools and IDEs (integrated development environments) use project files to contain all the elements of the system beind designe or built. Argo, like most tools, provide a tree widget to allow the designer to access the various parts of the project. Unlike other tools, Argo 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.

Multiple, Overlapping Views

Complex designs are made up of hundreds of elements with complex relationships to each other. Designers are better able to understand the design and make changes when they can see the elements and relationships that affect a certain design issue. No single diagram can clarify all design issues. Instead multiple diagrams and other presentations must be used.

Argo allows multiple graphical representations of the same design element to be used in different diagrams. In this sense, the views are overlapping.

Alternative Design Representations: Graphs, Text, or Table

Diagrams are the main way of presenting object-oriented designs. Argo can also provide tabular presentations of the design and textual presentations in the form of source code, and (future) english language explanations. Argo allows (future) editing in any of these presentations, and all of them are kept consistent.

Model-based Graph Layout (future)

In the future, we will investigate issues of graph layout. Much of the previous work on graph layout is motivated by very simple understandings of the cognitive needs of designers. For example, a graph is considered more readable if it has fewer edge crossings. These layout techniques typically do not take into account the conventions of the problem or solution domains or the task at hand. For example, if a designer is interested in memory allocation, he or she might benefit from seeing part of the class hierarchy laid out as a scatter plot with object size on one axis and expected number of instances on another axis. Or the size of the class icon could be used to indicate memory cost, while its color indicates expected lifetime. An infinite number of presentations are possible and the designer should be able to choose one that supports the task at hand, and then move on to another task and a new visualization.

Customizable User Model (partially implemented)

Designers can add new items to each part of Argo's user model.

Customizable Process Model (partially implemented)

Designers can add new tasks to Argo's process model.

Critic Editor (future)

Critics can be represented as a network of predicates and actions. An upcoming version of Argo will include a diagram editor for authoring critics.

Checklist Editor (future)

Checklists are made up of short pieces of text that serve to remind the designer to address specific issues or common problems. Additional program logic can be used to costumize the item to the design element at hand. An upcoming version of Argo will support authoring checklist items that contain only text.

Corrective Automation Editor (future)

Critics may offer corrective automations once a specific problem has been detected. In an upcoming version of Argp, designers will be able to author these corrective automations using the same graphical editor used to author critics.

Navigational Perspective Editor

The current version of Argo/UML provides over a dozen different navigational perspectives and a simple editor to customize these perspectives or author new ones. Each navigational perspective is made up of a set of rules. Each rule defines the possible children of a given design element. When rules are combined they yield the union of the children produced by each rule. About 20 rules are available for designers to use in navigational perspectives. A simple dialog box allows designers to specify the rules that make up each perspective.

Back to Argo/UML Home

	Runs on any platform with Java 1.1
			Argo/UML is coded entirely in Java and uses the Java Foundation Classes. This allows Argo/UML to run on virtually any platform. Argo/UML has been tested in the following environments: Windows NT 4.0 SP3. Symantec Visual Cafe 2.1 and 2.5. Windows NT 4.0 SP3. Sun JDK 1.1.5. Sun Solaris 5.5.1. Sun JDK 1.1.5. Linux with Blackdown JDK.

	Standard UML Meta-Model
			Argo/UML represents designs using a Java version of the UML 1.1 meta-model as described in the UML Semantics specification. We have made extensive efforts to keep this meta-model implementation true to the standard. For more information, see the uci.uml home page.

	UML Design Editing
			Argo/UML uses GEF, the UCI Graph Editing Framework to edit UML diagrams. The following diagram types are supported: Class diagrams State machine diagrams (near future) Use case diagrams (near future) Other diagram types will be available in the future

	Code Generation (partially implemented)
			We are looking for someone to design, implement, contribute a powerful, flexible, and extensible code generation facility.

	Design Critics
			Design critics are simple agents that continuously execute in a background thread of control. They analyze the design as the designer is working and suggest possible improvements. These suggestions range from indications of syntax errors, to reminders to return to parts of the design that need finishing, to style guidelines, to the advice of expert designers. Many critics offer to automatically improve the design. Critics are controlled so that their suggestions are relavent and timely to the design task at hand, bsed on information in Argo's user model. Critics never interrupt the designer, instead they post thier suggestions to the designer's "to do" list.

	Corrective Automations (partially implemented)
			Critics identify specific problems in the design and may offer specific solutions in the form of wizards or other corrective automations. These automations allow design improvements to be made faster and more reliably than they could be done by hand. Also, designers need not recall how to use the tool to achieve the suggested change.

	"To Do" List
			One difficulty designers face is keeping track of all the myrid details of thier task. It is all to easy to skip a step in the design process, leave part of the design unspecified, of make a mistake that requires revision. Argo provides the designer with a "to do" list user interface that presents action items in an organized form. These items can be suggestions from critics, reminders to finish steps in the process model, or personal notes entered by the designer. The choice control at the top of the "to do" list pane allow the designer to organize items in different ways: by priority, by decision supported, by offending design element, etc. Items are shown under all applicable headings. The "to do" list may also be viewed as a flat list.

	User Model (partially implemented)
			Argo's user model maintains information about the designer and uses that information to make the tool my useful. One way that it does this is by controlling critics so that only critics that are timely and relevant to the task at hand can make suggestions. In the future, the corrective automations and explanations offered by critics will also be tailored to the designer. Argo's user model consists of the following parts: Decision Model: Lists types of decisions that must be made when doing object oriented design. Each decision is associated with an level of interest from 0 to 5. A critic will not be active if the designer's interest in the decision that it supports is 0. Goals Model (partially implemented): Presents a list of questions related to goals for the design project. Critics that support active goals may present suggestions. Work Breakdown Structure (future): Lists the tasks that must be performed when doing object oriented design. Each task is associated with a level of activity and several decisions. This model serves the designer as a resource when deciding what task to do next. Skill Model (future): Each designer has their own strengths and weaknesses. Argo's skill model keeps track of the designer's self-reported level of knowledge related to the problem and solution domains. The estimated time to fix a problem found by a critic depends on the designer's knowledge of domain concepts, design techniques, and tool features.

	Checklists
			Checklists are currently widely used in design review meetings, in part, because they remind designers to cover all design details and avoid common design errors. Argo provides checklists that serve the same purpose, but have several advantages over passive printed lists: Argo's checklists are made specific to the selected design element. Each type of design element (e.g., Class, Attribute, Operation, Association) has its own checklist. Irrelevant checklist items are automatically removed from the list. The text of the checklist items are made specific to the design element being reviewed. For example, Argo uses element names instead of the pronouns that would be used in a printed list. (future) Checklist items can provide the designer with wizards that help complete a specified design change. For example, the checklist item "Should the attribute Age be moved to one of the super classes of Person (e.g., Animal)" could launch a wizard to help move the attribute up the class hierarchy. Checklists are somewhat similar to critics (in fact, they share some of the same implementation), however they differ in the level of specificity so much that we feel that they should be presented separately to designers. Critics look for very specific problems and provide specific suggestions when those problems are detected. The designer still makes the final decision about any design changes, but the critic can automate much of the analysis and work. In contrast, checklist items are much more general and vauge, they serve to remind the designer, but it is the designer who must do most of the analysis and work. Checklists are easier to author (see below), and useful checklist items can be upgraded to critics if appropriate.

	Work Breakdown Structure (future)
			This feature is not described yet.

	Navigational Perspectives
			Many design tools and IDEs (integrated development environments) use project files to contain all the elements of the system beind designe or built. Argo, like most tools, provide a tree widget to allow the designer to access the various parts of the project. Unlike other tools, Argo 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.

	Multiple, Overlapping Views
			Complex designs are made up of hundreds of elements with complex relationships to each other. Designers are better able to understand the design and make changes when they can see the elements and relationships that affect a certain design issue. No single diagram can clarify all design issues. Instead multiple diagrams and other presentations must be used. Argo allows multiple graphical representations of the same design element to be used in different diagrams. In this sense, the views are overlapping.

	Alternative Design Representations: Graphs, Text, or Table
			Diagrams are the main way of presenting object-oriented designs. Argo can also provide tabular presentations of the design and textual presentations in the form of source code, and (future) english language explanations. Argo allows (future) editing in any of these presentations, and all of them are kept consistent.

	Model-based Graph Layout (future)
			In the future, we will investigate issues of graph layout. Much of the previous work on graph layout is motivated by very simple understandings of the cognitive needs of designers. For example, a graph is considered more readable if it has fewer edge crossings. These layout techniques typically do not take into account the conventions of the problem or solution domains or the task at hand. For example, if a designer is interested in memory allocation, he or she might benefit from seeing part of the class hierarchy laid out as a scatter plot with object size on one axis and expected number of instances on another axis. Or the size of the class icon could be used to indicate memory cost, while its color indicates expected lifetime. An infinite number of presentations are possible and the designer should be able to choose one that supports the task at hand, and then move on to another task and a new visualization.

	Customizable User Model (partially implemented)
			Designers can add new items to each part of Argo's user model.

	Customizable Process Model (partially implemented)
			Designers can add new tasks to Argo's process model.

	Critic Editor (future)
			Critics can be represented as a network of predicates and actions. An upcoming version of Argo will include a diagram editor for authoring critics.

	Checklist Editor (future)
			Checklists are made up of short pieces of text that serve to remind the designer to address specific issues or common problems. Additional program logic can be used to costumize the item to the design element at hand. An upcoming version of Argo will support authoring checklist items that contain only text.

	Corrective Automation Editor (future)
			Critics may offer corrective automations once a specific problem has been detected. In an upcoming version of Argp, designers will be able to author these corrective automations using the same graphical editor used to author critics.

	Navigational Perspective Editor
			The current version of Argo/UML provides over a dozen different navigational perspectives and a simple editor to customize these perspectives or author new ones. Each navigational perspective is made up of a set of rules. Each rule defines the possible children of a given design element. When rules are combined they yield the union of the children produced by each rule. About 20 rules are available for designers to use in navigational perspectives. A simple dialog box allows designers to specify the rules that make up each perspective.