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.
REQ1 REVa
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.
All views of a model element shall be updated as soon as the model element is updated.
REQ2 REVb
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.
Editable views of the model should update the model on each keystroke and mouse click.
REQ11 REVa
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.
Any text fields that require validation should not be editable directly from a view.
REQ12 REVa
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.
REQ13 REVa
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.
The user shall receive some visual feedback during the edit process of textual UML to indicate whether the text represents valid UML syntax.
REQ14 REVa
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?
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.
REQ3 REVa
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.
All text fields shall have context sensitive help.
As follows:
- 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.
- 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).
REQ4 REVa
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.
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.
REQ5 REVb
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.
ArgoUML shall implement everything in the UML 1.4 model.
CategoryFix: We must start working on a plan to move to UML2.
REQ6 REVb
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.
About enforcement of well-formedness rules from the UML standard.
REQ15 REVa
WFR = Well-Formedness Rule. This matter was discussed in the dev list, in the thread following "http://argouml.tigris.org/servlets/ReadMsg?list=dev&msgNo=20622".
- Critics shall warn for any WFR violations (a critic for every WFR would be ideal).
- Generally, ArgoUML shall not enforce WFRs, except in certain cases.
- In such cases (where we enforce a WFR) we shall
- document this case, and b. be consistent about it.
- Even if a WFR is enforced, ArgoUML shall still be able to deal with a model that breaks it.
Rationale: since we can load an XMI that breaks the WFR.
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.
REQ7 REVb
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.
REQ8 REVa
Rationale: ArgoUML is an application that edits an UML model. There is no need to have any network defined while doing this.
Console output: Logging or tracing information shall not be written to the console or to any file unless explicitly turned on by the user.
REQ9 REVa
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.
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.
REQ10 REVa
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