Chapter 3. ArgoUML requirements

Linus Tolke

Table of Contents

3.1. Requirements for Look and feel
3.1.1. When multiple visual components are showing the same model element they shall be updated in a consistent manner throughout the application.
3.1.2. All views of a model element shall be update as soon as the model element is updated.
3.1.3. Editable views of the model should update the model on each keystroke and mouse click.
3.1.4. Any text fields that require validation should not be editable directly from a view.
3.1.5. With dialogs, the model is not updated until the dialog is accepted by the user with valid fields.
3.1.6. The user shall receive some visual feedback during the edit process of textual UML to indicate whether the text represents valid UML syntax.
3.1.7. 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.
3.1.8. All text fields shall have context sensitive help.
3.2. Requirements for UML
3.2.1. ArgoUML shall be a correct implementation of the UML 1.3 model.
3.2.2. ArgoUML shall implement everything in the UML 1.3 model.
3.3. Requirements on java and jvm
3.3.1. 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.
3.3.2. Download and start
3.3.3. Console output: Logging or tracing information shall not be written to the console or to any file unless explicitly turned on by the user.
3.4. Requirements set up for the benefit of the development of ArgoUML
3.4.1. Logging: The code shall contain entries logging important information for the purpose of helping Developers of ArgoUML in finding problems in ArgoUML itself.

This chapter 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 on why this is important, a stakeholder that is one of the stakeholders in the vision for who this is important.

3.1. Requirements for Look and feel

This describes how the ArgoUML look and feel shall behave.

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

Stakeholder: User of ArgoUML

3.1.2.  All views of a model element shall be update 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.

Stakeholder: User of ArgoUML

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

Stakeholder: User of ArgoUML

3.1.4.  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. TODO: Is this the correct stakeholder?

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

Stakeholder: User of ArgoUML.

3.1.6.  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 a correct syntax of anything 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 to as quickly as possible, get the syntax right. TODO: Is this the correct motivation for this?

Stakeholder: User of ArgoUML.

3.1.7.  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 loose interest in ArgoUML as a tool because he percieves it as not working correctly.

Stakeholder: User of ArgoUML

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

Stakeholder: User of ArgoUML