Guidelines for UML Diagram Development |
This document contains guidelines and hints (and lists common mistakes) for the development of UML diagrams.
Domain Modeling Hints and Mistakes |
The following list of "common domain modeling mistakes" is based on observed behavior of students in a study conducted by Rosenberg and Scott. Here's their list of what to avoid:
Implementation issues should be left until the physical design stage.
Easy-to-understand names enhance communication among members of a development team. Acronyms should be avoided until the implementation stage.
If you are reengineering a legacy system that uses a relational database, then the tables within the database are likely to be an excellent source of domain classes. However, be careful not to bring them over to your static model wholesale. Relational tables can have lots of attributes that might not belong together in the context of an object model. You should use "aggregation" to factor groups of attributes in so-called "helper" classes, which contain attributes and operations relevant to more significant classes.
Often, patterns only become apparent during robustness analysis where their connectivity to use cases become apparent. Design patterns can, however, be highly useful in the context of sequence diagrams and design-level class diagrams.
Use Case Diagram Hints and Mistakes |
The following list of "common use case mistakes" is based on observed behavior of students in a study conducted by Rosenberg and Scott. Here are their mistakes to avoid:
Requirements are not the same as scenarios. Requirements are generally stated in terms of what the system shall do. Usage scenarios, in contrast, describe the actions users take and the responses the system will generate (i.e. behavior).
Eventually, use case text/graphics will be used as a run-time behavioral specification for the scenarios that are described. (i.e. on the left-hand side of the sequence diagram). We want to be able to see how the system (shown with objects and messages in the sequence diagram) impliments the desired behavior as required in the use case test.
Use cases should describe system usage, using terms from the problem domain. The should not contain too many details about methods or attributes of the domain classes/objects.
Textual descriptions of use cases should contain all of the details of user actions and system responses. It's better to err on the side of providing too much detail, then leave something out.
One of the fundamental notions of "use-case driven" development is that the development team conforms to the design of the system from a user's perspective. You cannot do this without being specific about what actions a user will take. This includes discussing those features of the user interface that allow a user to tell the system to do something.
Boundary objects are the objects with which actors will interact. In the case of a software system, boundary objects can be graphical components such as pulldown menus, buttons, and so forth.
In keeping with the theme of providing ample detail and being explicit about user navigation, we submit that a use case should name boundary objects explicitly.
A use case is most effectively written from a user's perspective as a set of present-tense verb phases in active voice.
The narrative of a use case should be event-response oriented. For example,
"The system does ... when the user does ... "
A use case should capture a good deal of what happens "under the covers" in response to what an actor is doing, whether the system creates new objects, validates user input, generates error message, ... etc.
Right from the start of use case development, alternative courses of action should be weighed equally with desired action.
Pre- and post-conditions should be used only if they are really necessary. If not, keep use cases short and simple.
Choose one mechanism for describing commonality among use cases, and then stick to it.
Robustness Analysis Mistakes |
The purpose of these rules is to get your text into noun-verb-noun format and to help ensure you don't start allocating behavior to objects before you have enough information to make good decisions.
CHECKLIST
Checklist for systems planning and analysis:
Devalopment Activity/Task | Question |
Gather information | Do we have all of the information and insight needed to define what the system will do? |
Define system requirements | In what detail do we need to specify what the system will do? |
References |
Developed in March 2001 by Mark Austin
Copyright © 2001, Mark Austin, University of Maryland