Hasker's SWE 2410 UML Standards

All Diagrams

This section gives the general requirements; requirements for specific types of diagrams are below.

• Use CamelCase for class names, meaning use upper-case letters for the first word and all following words, lower case for all other letters. The exception would be class names in some libraries (for example, the C++ STL).
• 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. For the same reason, avoid spelling errors, especially for words within names.
• All classes should be associated with at least one other class.
• Avoid redundancy. For example, if class A relates to B and B relates to C, there is rarely any need for A to relate directly to C. As another example, avoid showing a relationship to another class and listing an instance of that class in the box. The relationship implies the instance.
• Avoid the aggregation symbol (open diamond) on associations. Many people believe there is a strong distinction between this and other associations, but in fact the UML standard gives no meaning to this notation.

In general, be careful on how you use UML notation. UML is very carefully designed to convey key information without unnecessary redundancy. Non-standard notation adds confusion, defeating the purposes of drawing diagrams in the first place. This is especially important in the core notation: using open triangles for generalization, open (v-shaped) arrows for direct association, solid lines for associations, etc. Learning to use the correct notation can be very important for interviews because it's one way people sort out those who have learned basic software engineering concepts from those who have not.

Domain Level Class Diagrams

In addition to the requirements for all 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 3..6 if there is a requirement for three to six items of something).
• Use 0..1 for an optional item, 1..* for one or more.
• Never write 0..*; this is always written as simply *.
• Show role names when they add information, such as when there are two distinct associations between the same classes. For example:
• Show directionality if there is a natural direction; for example, every working automobile has an engine. However, directionality is often a design issue and you can use just a plain line instead. For example, the above airline example does use directionality, but undirected would be fine as well since one could easily be more concerned about determining the flights coming into or leaving an airport.
• Domain-level 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 Passengers).
• 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. That is, do not list an attribute in a class box when it would be redundant with an association.
• On domain diagrams, 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. However, these are important stereotypes for the other diagrams.
• 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.

Minimal Solution Diagram

This is called an abstract solution diagram in some contexts.

In addition to the requirements for all diagrams, minimal solution diagrams capture the domain and the design decisions. They exist in the solution space: that is, they capture details that are not typically visible to clients such as containers and design patterns. In particular, a minimal solution diagram includes the following:

• Domain classes which appear in the solution. If a domain class has no responsibilities that are relevant to the rest of the application, then it may not be needed. Be careful about removing domain classes; lack of responsibilities may indicate missing requirements!
• Attribute and method types where known and relevant to understanding the design, but not all types. Types for simple attributes are often very useful, but types for methods are often too detailed for this diagram.
• When known, Java container classes that appear in the solution. For example, if your solution will contain a map from student id numbers (integers) to student objects, include a class Map<int, Student> in your diagram and add a one-to-many association from this class to class Student. You likely do not need to document the attributes and methods in these classes since they are just those in the standard Java library. It is acceptable to not specify the container if that design decision has not been made at the time the diagram is being created.
• Design patterns applied to the solution. That is, those classes that implement design patterns that appear in the solution.

Note that setters, getters, and constructors are not included. See the Ice Cream Cone Decorator example for a sample minimal solution diagram.

Contract Diagrams

"Contract" diagrams give full details needed by other developers, including type information. These must also follow the general requirements for all diagrams.

• 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).

This diagram differs from reverse-engineered diagrams in that it omits a number of superfluous elements such as named constants and duplicating associations as attributes.

Reverse-Engineered Diagrams

Use Enterprise Architect (EA) to generate a reverse-engineered diagram. See this page for directions. 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. These diagrams will not satisfy the above requirement for avoiding redundant attributes, but you are not expected to fix this problem.