Web pages for the ArgoUML project.

From the ArgoUML wiki at
Wiki: ArgoUML requirements

This wiki page contains a description on how ArgoUML should work and behave for the users.

These things might not be implemented yet and the solutions might not even be clear but it is a definition of the goal.

The fact that it is not implemented or doesn't work as stated here should be registered as a bug in the bug registering tool.

Every requirement has a number (REQ1, REQ2, REQ3, ...) that never changes, a revision (REVa, REVb, REVc, ...) that changes when the requirement change, a text that is the requirement text to implement, a rationale that is the description of why the requirement is important, and a stakeholder, i.e. a person or group that the requirement is important to.

Requirements for Look and feel

This describes how the ArgoUML look and feel shall behave.

When multiple visual components are showing the same model element they shall be updated in a consistent manner throughout the application.


Rationale: There is no way of telling where the user is looking while working with ArgoUML. For this reason he might be terribly confused if some other view that happens to show the same element is not showing the same thing.

Stakeholder: User of ArgoUML

All views of a model element shall be updated as soon as the model element is updated.


Rationale: If a user makes an update of a part of the model, an immediate feedback in all other parts that are currently showing might help him to get it right.

Stakeholder: User of ArgoUML

Editable views of the model should update the model on each keystroke and mouse click.


Rationale: If a user makes an update of a part of the model, an immediate feedback in all other parts that are currently showing might help him to get it right.

Stakeholder: User of ArgoUML

Any text fields that require validation should not be editable directly from a view.


Rationale: If a text field requires validation there exists, by definition, a possibility that the text field is in an invalid state at any time during editing. Therefore the model cannot be updated until the field is completed in a valid state or rejected.

Stakeholder: User of ArgoUML
CategoryFix: Is this the correct stakeholder?

With dialogs, the model is not updated until the dialog is accepted by the user with valid fields.


Rationale: It is a common feature of GUIs that a dialog displays a snapshot of its model at the time of creation and only updates that model on the user acceptance of the entire dialog. This is a familiar look and feel for users.

Stakeholder: User of ArgoUML

The user shall receive some visual feedback during the edit process of textual UML to indicate whether the text represents valid UML syntax.


Rationale: Writing anything in the correct syntax is complicated. Good compilers are helpful in pinpointing where the problem is (what line and what token is in error). The text fields in ArgoUML are not developed in the same way as source code and we have no compiler step to verify it all. Instead this validation needs to be done while editing meaning that the user needs all the help he can get, as quickly as possible, to get the syntax right.
CategoryFix: Is this the correct motivation for this?

Stakeholder: User of ArgoUML

There shall be no indication of an exception on the screen or in the log if it has occured merely because of a user mistyping or not being aware of UML syntax.


Rationale: An exception in the log or on the screen is always the sign of a serious error in the application that should be reported as a DEFECT. If a mistyping generates such a problem the user might lose interest in ArgoUML as a tool because he percieves it as not working correctly.

Stakeholder: User of ArgoUML

All text fields shall have context sensitive help.

As follows:

  1. A tooltip that explains the data and format expected by the particular field. This can be omitted when there is a header stating the data of the field and the format is obvious.
  2. Pressing F1 or choosing help from the menu shall display a popup window explaining the data and format required by the current input field. Input focus shall be left on the field during any user interaction with the popup (dragging, scrolling or closing).


Rationale: Throughout a complex application like ArgoUML there are lots of text fields. Unless there is a possibility to always get this kind of help the user might not be able to make out what he is actually supposed to do in that field.

Stakeholder: User of ArgoUML

Requirements for UML

ArgoUML shall be a correct implementation of the UML 1.4 model.

CategoryFix: We must start working on a plan to move to UML2.


Rationale: The vision of ArgoUML is to provide a tool that helps people work with an UML model. The UML model might later on be used in some other tool. If the implementation is not correct then ArgoUML will not be compatible with that other tool or the user will be confused. There might be a lot of tough decisions when it comes to if it is ArgoUML or some other tool that deviates from the UML 1.4 but there shall never be any doubt that the intention of ArgoUML is to implement UML correctly.

Stakeholder: User of ArgoUML

ArgoUML shall implement everything in the UML 1.4 model.

CategoryFix: We must start working on a plan to move to UML2.


Rationale: The ambition is to implement all of UML. This means that no matter how you use UML ArgoUML will always be a working tool.

Stakeholder: User of ArgoUML

About enforcement of well-formedness rules from the UML standard.


WFR = Well-Formedness Rule. This matter was discussed in the dev list, in the thread following "".

  1. Critics shall warn for any WFR violations (a critic for every WFR would be ideal).
  2. Generally, ArgoUML shall not enforce WFRs, except in certain cases.
  3. In such cases (where we enforce a WFR) we shall
    1. document this case, and b. be consistent about it.
  4. Even if a WFR is enforced, ArgoUML shall still be able to deal with a model that breaks it.
  5. Rationale: since we can load an XMI that breaks the WFR.

Stakeholder: User of ArgoUML

Requirements on java and jvm

Choice of JRE: ArgoUML will support any JRE compatible with a Sun specification of any JRE from Sun that has not begun the Sun End of Life (EOL) process.


Rationale: The JREs and the adjoining libraries (especially swing) are always improving to include new features and new ideas. The developers of ArgoUML would like to use these new features.

Note: J2SE 1.3.1 begun its Sun End of Life (EOL) process on October 25, 2004.

Stakeholder: Developers of ArgoUML

Download and start

It shall be possible to install ArgoUML locally on the machine and use without Internet connection.


Rationale: ArgoUML is an application that edits an UML model. There is no need to have any network defined while doing this.

Stakeholder: User of ArgoUML

Console output: Logging or tracing information shall not be written to the console or to any file unless explicitly turned on by the user.


Rationale: ArgoUML is an application that edits an UML model. Any information written to anywhere but the files that the user specifies the user won't know what to do with and it will be perceived as garbage generated by the ArgoUML application.

Stakeholder: User of ArgoUML

Requirements set up for the benefit of the development of ArgoUML

Logging: The code shall contain entries logging important information for the purpose of helping Developers of ArgoUML in finding problems in ArgoUML itself.


Rationale: When the developers are searching for some problem or when they ask any of the users to help them pinpoint some problem such logging messages are very helpful.

Stakeholder: Developers of ArgoUML


ArgoUML requirements (last edited 2009-03-15 09:03:23 -0700 by linus)