Latest Prank

ArgoUML Features

ArgoUML provides the following features. Each feature is described briefly below.

• 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
  • Reflection-in-action
    • Design Critics
    • Corrective Automations (partially implemented)
    • "To Do" List
    • User model (partially implemented)
  • Opportunistic Design
    • "To Do" List
    • Checklists
  • Comprehension and Problem Solving
    • Explorer Perspectives
    • Multiple, Overlapping Views

Install with Java Web Start

The ArgoUML website provides easy installation with Java Web Start.

Runs on any platform with Java5 or Java6

ArgoUML is written entirely in Java and uses the Java Foundation Classes. This allows ArgoUML to run on virtually any platform.

Standard UML Metamodel

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.

UML Profile support with profiles provided

ArgoUML has support for creating profiles, and distributing models that reference common online available profiles.
ArgoUML is delivered with profiles for:

• Java
• C++
• UML 1.4

UML Diagram Support

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:

• Adjustable font size.

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 Support

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.

Several diagram export formats

Diagrams can be saved as GIF, PNG, PostScript, Encapsulated PS, PGML and SVG.

Internationalization

ArgoUML has been internationalized to American English, British English, French, German, Italian, Portuguese, Spanish, Russian, Norwegian Bokmål and Chinese.

Diagram Editing

ArgoUML supports many diagram editing features that help you edit UML diagrams.

OCL Support

ArgoUML provides constraint modeling support on UML Classes and Features. 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!

Code Generation

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 - trip engineering.

Reverse Engineering

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

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.

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 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.

User Model (partially implemented)

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 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 vague, they serve to remind the designer, but it is the designer who must do most of the analysis and work.

Explorer Perspectives

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 perspective.

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.
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.