Hasker's SE 2811 UML Standards

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.
• Generally, multiplicities will be either 1 or *, and 1 is assumed if there is no indication. However, if a problem statement explicitly gives numbers, use those numbers (like 0..5 if there is a requirement for up to five items of something).
• 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.
• Do not show directionality; this is also a design 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.
• Do not mark classes as abstract or interface. These are implementation issues, and frequently parent classes in domains will be abstract so the extra notation provides little value.
• Do not specify types or constructors, getters, or setters; 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.

Abstract Solution Diagram

Abstract solution diagrams capture design decisions - decisions that would not be visible to clients - but contains minimal detail. This is the type of diagram that typically appears in the notes.

Contract Diagrams

"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.
• Mark abstract classes using the notation of your target language. For example, Java developers will distinguish between abstract classes and interfaces.
• 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

Use Enterprise Architect (EA) to generate a reverse-engineered diagram. See this page for directions for EA 13. EA 15 is similar; ask if you run into problems. After reverse engineering a class diagram in EA, 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 fit on a single page if at all possible.