A few months back, we gave you a heap of informative articles on UML design that started with this. If you have not read it, we do urge you to do so since it does offer a nice introduction to class diagrams, which is the focus of this post. When it comes to system construction, a class diagram is the most widely used diagram. A class diagram generally consists of interfaces, classes, associations and collaborations. Such a diagram would illustrate the object-oriented view of a system, which is static in nature. The object orientation of a system is indicated by a class diagram.
In this post we’ll discuss the numerous guidelines that are present when it comes to class diagrams. But before we dig into the details of the guidelines, it makes sense to begin by highlighting the points that are going to be covered:
- General issues
- Classes
- Interfaces
- Relationships
- Inheritance
- Aggregation and Composition
Due to the extensive nature of the subject, we thought it would be apt to break this down into two parts. In this specific post, we will indicate the guidelines that will relate to the areas of General Issues, Classes and Interfaces as has been mentioned above.
1. General issues
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. 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
1. 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().
1. 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.
2. Do not name associations that have association classes.
3. Center the dashed line of an association class.
2. Class Style Guidelines
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.
3. Guidelines for 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
It’s true that UML design is a vast and complicated subject that needs quite a bit of respect. While this whole subject may seem rather complex in nature, we have tried out best to simplify it, so that both professional software engineers and those who are just getting into UML design will find this whole post useful. As always, we are more than happy to field in any questions or doubts you may have. Till our concluding post, which we will release this week, keep those UML diagrams coming!
Reference: http://www.agilemodeling.com/style/classDiagram.htm
Thank you for the guidelines. It is useful to refresh my mind.
I’m used to Enterprise Architect but I’m going to try Creately.
Sir, i want to know about the, UML standard that creately is using?
UML 2.0 . Thanks for the comment.
[…] we continue from where we left off on the topic Guidelines for UML class diagrams ~ part 1. We spoke about the relevant guidelines for General issues, Classes and Interfaces; in this post we […]