All Diagrams
This section gives the general requirements; requirements for specific
types of diagrams are below.
- Avoid non-standard abbreviations. "App" is fine, but most other
abbreviations are not. They make code hard to maintain because other
developers have to remember which abbreviations you prefer.
- All classes should be associated with at least one other class.
- Use CamelCase for class names, meaning use upper-case letters for the
first word and all following words, lower case for all other letters.
- Make sure words within names are spelled correctly.
Note that non-standard cases, misspelled names, abbreviations, and related
issues result in difficult-to-maintain code because developers then have to
remember the odd way of writing identifiers.
Domain Level Class Diagrams
Domain-level class diagrams must meet the following requirements:
- Show inheritance, attributes, methods, relationships,
and multiplicities.
- Show role names when they add information, such as when
there are two distinct associations between the same classes.
- Designs need to be independent of a programming language; do not
include Java-specific classes
- This means you would not use Java-specific classes
like LinkedList or Map. Just use a one-to-many
relationship between an object (like a Bus) and the objects it contains
(like a Passenger).
- Also, do not include a class that simply contains a static
main; this is also a Java-specific concept.
- Use generic associations. Aggregation vs. composition is an
design issue (reflecting data lifetimes), not a
problem-description issue.
- List just simple attributes inside the class box. Complex
attributes - that is, ones that are instances of other domain classes - need
to be shown by explicit associations instead.
- Mark abstract classes; ones that must be refined for additional
behavior. You can also use interfaces; this comes close to be
language-specific, but the concept is reasonably universal.
- Do not show directionality; this is also a design issue.
- Do not specify types; they add clutter and obscure the important
concepts for clients.
- Do not include constructors, getters, and setters.
Very high level domain diagrams may even omit attributes and operations;
ask if you are not sure if they should be included.
Contract Diagrams
This portion is in draft state.
"Contract" diagrams give full details needed by other developers, including
type information.
- Show inheritance, attributes, methods, relationships,
and multiplicities.
- Make all associations directed. If an association is bi-directional
(two classes both have a reference of the other), show that as two
separate, directed associations.
- Missing multiplicities are assumed to have the value 1.
- Prefer generic associations. Marking an association as composition
(filled-in diamond) can be important, but is rarely important in
Java. There is no reason to use the empty diamond (aggregation) since it
has no true meaning in the standard.
- Unless directed otherwise, include all setters, getters,
constructors.
- Unless directed otherwise, include all type information, both for
attributes and for parameters.
- Show role names when they add information (as discussed above).
Reverse-Engineered Diagrams
This portion is in draft state.
After reverse engineering a class diagram in Enterprise Architect, the only
change you need to make is to reorganize the classes to minimize the number
of crossing lines and the amount of white space. The diagram is to at
least fit on a page, if possible.