Since class diagrams are used for many different purposes, such as making stakeholders aware of requirements to highlighting your detailed design, you need to apply a different style in each circumstance.

The points that are going to be covered are indicated as follows:

1. General issues
2. Classes
3. Interfaces
4. Relationships
5. Inheritance
6. Aggregation and Composition

General Issues

This section describes style guidelines that are relevant to various types of class diagrams.

1. Show visibility only on design models
2. Assess responsibilities on domain class diagrams
3. Highlight language-dependent visibility with property strings
4. Highlight types only on design models
5. Highlight types on analysis models only when the type is an actual requirement

• - Design class diagrams should reflect language naming conventions. In the “Analysis and design version of a class” image you see that the design version of the Order class uses names that conform to common Java programming conventions such as placementDateand calculateTaxes().

• - Model association classes on analysis diagrams. The image that shows the “Modelling association classes” indicates the association classes that are depicted as class attached via a dashed line to an association – the association line, the class, and the dashed line are considered one symbol in the UML.
• - Do not name associations that have association classes.
• - Center the dashed line of an association class.

Class Style

A class is basically a template from which objects are created.  Classes define attributes, information that are relevant to their instances, operations, and functionality that the objects support.  Some of the more important guidelines pertinent to classes are listed down below.

1. Put common terminology for names
2. Choose complete singular nouns over class names
3. Name operations with a strong verb
4. Name attributes with a domain-based noun
5. Do not model scaffolding code.  Scaffolding code refers to the attributes and operations required to use basic functionality within your classes, such as the code required to implement relationships with other classes.  The image above depicts the difference between the OrderItem class without scaffolding code
6. Never show classes with just two compartments
7. Label uncommon class compartments
8. Include an ellipsis ( … ) at the end of incomplete lists
9. List static operations/attributes before instance operations/attributes
10. List operations/attributes in decreasing visibility
11. For parameters that are objects, only list their type
12. Develop consistent method signatures
13. Avoid stereotypes implied by language naming conventions
14. Indicate exceptions in an operation’s property string.  Exceptions can be indicated with a UML property string, an example of which is shown in the above image.

Interfaces

An interface can be defined as collection of operation signature and/or attribute definitions that ideally defines a cohesive set of behaviors.  Interfaces are implemented, “realized” in UML parlance, by classes and components. In order to realize an interface, a class or component should use the operations and attributes that are defined by the interface.  Any given class or component may use zero or more interfaces and one or more classes or components can use the same interface.

1. Interface definitions must reflect implementation language constraints.  In the above image, you see that a standard class box has been used to define the interface PersistentObject (note the use of the <<interface>> stereotype).
2. Name interfaces according to language naming conventions
3. Apply “Lollipop” notation to indicate that a class realizes an interface
4. Define interfaces separately from your classes
5. Do not model the operations and attributes of an interface in your classes. In the above image, you’ll notice that the shipment class does not include the attributes or operations defined by the two interfaces that it realizes
6. Consider an interface to be a contract

Aggregation and Composition

As it is known an object is made up of other objects. If you were to consider as examples where an airplane consists of wings, a fuselage, engines, flaps, landing gear and so on. A delivery shipment would contain one or more packages and a team consists of two or more employees. These are all examples of the concept of aggregation that illustrates “is part of” relationships. An engine is part of a plane, a package is part of a shipment, and an employee is part of a team. Aggregation is a specialization of association, highlighting an entire-part relationship that exists between two objects. Composition is a much potent form of aggregation where the whole and parts have coincident lifetimes, and it is very common for the whole to manage the lifecycle of its parts. If you were to consider a stylistic point of view, aggregation and composition are both specializations of association where the guidelines for associations do apply.

1. You should be interested in both the whole and the part
2. Depict the whole to the left of the part
3. Apply composition to aggregates of physical items

Inheritance

Inheritance models “is a” and “is like” relationships, enabling you to rather conveniently reuse data and code that already exist. When “A” inherits from “B” we say that “A” is the subclass of “B” and that “B” is the superclass of “A.” In addition to this, we have “pure inheritance” when “A” inherits all of the attributes and methods of “B”. The UML modeling notation for inheritance is usually depicted as a line that has a closed arrowhead, which points from the subclass right down to the superclass.

1. Plus in the sentence rule for inheritance
2. Put subclasses below superclasses
3. Ensure that you are aware of data-based inheritance
4. A subclass must inherit everything

Relationship

At this particular juncture, the term “relationships” will encompass all UML concepts such as aggregation, associations, dependencies, composition, realizations, and inheritance. In other words, if it’s a line on a UML class diagram, it can be considered as a relationship. The following guidelines could be considered as “best practices” and and effort should be made to adhere to them at all times.

Figure A

Figure B

Figure C

1. Ensure that you model relationships horizontally
2. Collaboration means a need for a relationship
3. Model a dependency when a relationship is in transition
4. Depict similar relationships involving a common class as a tree.  In Figure A you see that both Delivery and Order have a dependency on OIDGenerator. Note how the two dependencies are drawn in combination in “tree configuration”, instead of as two separate lines, to reduce clutter in the diagram.
5. As a rule it is best to always indicate the multiplicity
6. Avoid a multiplicity of “*” to avoid confusion
7. Replace relationships by indicating attribute types.  In Figure C you see that the customer has a shippingAddress attribute of type Address – part of the scaffolding code to maintain the association between customer objects and address objects.
8. Never model implied relationships
9. Never model every single dependency
10. Center names on associations
11. Write concise association names in active voice
12. Indicate directionality to clarify an association name
13. Name unidirectional associations in the same direction
14. Word association names left-to-right
15. Indicate role names when multiple associations between two classes exist
16. Indicate role names on recursive associations
17. Make associations bi-directional only when collaboration occurs in both directions. The lives at association of Figure B is uni-directional.
18. Redraw inherited associations only when something changes
19. Question multiplicities involving minimums and maximums

Image from - http://www.digestivehealth.com.au/referral-guidelines.htm