ArgoUML provides the following features. Each feature is described
- All 9 UML 1.4 Diagrams supported
- Platform Independent: Java 5+
- Click and Go! with Java Web Start
- Standard UML 1.4 Metamodel
- UML Profile support with profiles provided
- XMI Support
- Export Diagrams as GIF, PNG, PS, EPS, PGML and SVG
- Available in ten languages - EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
- Advanced diagram editing and Zoom
- OCL Support
- Forward Engineering
- Reverse Engineering / Jar/class file Import
- Cognitive Support
- Opportunistic Design
- Comprehension and Problem Solving
The ArgoUML website provides easy installation with Java Web Start.
ArgoUML is written entirely in Java and uses the Java Foundation
Classes. This allows ArgoUML to run on virtually any platform.
ArgoUML is compliant with the OMG
Standard for UML 1.4.
The core model repository is an implementation of the
Java Metadata Interface (JMI) which directly supports MOF
and uses the machine readable version of the UML 1.4
specification provided by the OMG.
ArgoUML has support for creating profiles,
distributing models that reference common online available profiles.
ArgoUML is delivered with profiles for:
ArgoUML uses GEF, the
UCI Graph Editing Framework to edit UML diagrams. The following
diagram types are supported:
- Class diagram
- Statechart diagram
- Activity diagram (including Swimlanes)
- Use Case diagram
- Collaboration diagram
- Deployment diagram (includes Object and Component diagram in one)
- Sequence diagram
For all diagrams:
Features for specific diagrams:
- Diagram representation of stereotypes and datatypes
- Support for drawing Signals and Exceptions in class diagrams
- Configurable arrows for both-navigable associations.
XMI is an XML based exchange format between UML tools. ArgoUML
uses this as standard saving mechanism so that easy
interchange with other tools and compliance with open
standards are secured. Additionally, exporting the model to XMI is possible.
XMI version 1.0 was used for UML 1.3.
ArgoUML 0.20 imports XMI 1.0 (by converting UML 1.3 to UML 1.4).
And ArgoUML imports the UML1.4 formats XMI 1.1 & 1.2,
but only writes XMI 1.2.
Diagrams can be saved as GIF, PNG, PostScript, Encapsulated PS, PGML and SVG.
ArgoUML has been internationalized to American English, British English,
French, German, Italian, Portuguese, Spanish, Russian,
Norwegian Bokmål and Chinese.
ArgoUML supports many diagram editing features that help you edit UML
ArgoUML provides constraint modeling support on UML Classes and
The Dresden OCL toolkit
enables ArgoUML to perform syntax
and type checking on those constraints. OCL support has been provided
by and developed at the Technical University of Dresden, thanks!
ArgoUML provides code generation for Java, C++, C#, PHP4 and PHP5.
Other languages may be added since the code generation is a modular framework.
The Java code
generation works with the Java reverse engineering to provide basic round -
ArgoUML provides a modular reverse engineering framework.
Currently Java source code is provided by default and there are
modules for Java Jar and class file import.
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
relevant and timely to the design task at hand, based on
information in Argo's user model. Critics never interrupt the
designer, instead they post their suggestions to the
designer's "to do" list.
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.
One difficulty designers face is keeping track of the myriad of
details of their 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.
Argo's user model maintains information about the designer
and uses that information to make the tool more 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
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 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
- (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 vague, they serve to remind the designer,
but it is the designer who must do most of the analysis and
ArgoUML, like most tools,
provides a tree view to allow the designer to access the
various parts of their modeling project.
Unlike other tools,
ArgoUML provides 9 different
explorer perspectives and a simple editor to customize
these perspectives or author new ones. Each explorer
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 70 rules are available for designers to use
in explorer perspectives. A simple dialog box allows
designers to specify the rules that make up each
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.
ArgoUML allows multiple graphical representations of the same
design element to be used in different diagrams. In this sense,
the views are overlapping.
ArgoUML has 4 main views: Explorer, Diagram, Details, Critics.
Back to ArgoUML Home