Table of Contents
Introduction
According to the official documentation a class diagram models the static structure of classes, interfaces and their relationships. This post is a quick overview of the graphics, symbols and what they stand for.
Example Class Diagram
Relationships exist in a context and are to a certain degree interpretable. Also, the use of symbols in UML is not set in stone. As long as you stay consistent, other uses of symbols is fine.
Relationships Overview
| Type | Line Style | Description | Analogy / Example |
| Dependency | Dashed line, open arrowhead | “Uses a” | A Course uses Book(s) |
| Association (one-directional) | Solid with open arrowhead | “Has a” / “knows a” | A Teacher has knowledge of a Course |
| Association (bi-directional) | Solid | “Has a” / “knows a” | Class knows which teacher Teacher knows which class to teach |
| Association (reflexive) | Solid | “Has a” / “knows a” | Book references Book |
| Aggregation | Hollow diamond | “Owns a” | A Department has Teachers |
| Composition | Filled diamond | “Is made up of a” | Building owns Departments |
| Generalization | Solid line, closed arrowhead | “Is a” | A Classroom is an AbstractClassroom |
| Realization | Dashed line, closed arrowhead | “Implements” | An AbstractClassroom implements the IClassroom interface |
Relationships Explained
The relationships are explained in context of the example diagram. Different relationships between the Classes could have been the case if another “reality” had been modeled. This is a fictional diagram of course. What I mean is that the relationship between Classroom and Teacher technically could have been a Dependency instead of an Association as well.
Dependency
A Dependency is a weak, non-structural relationship. A Course uses Book(s). Basically, the dependency relationship is more temporal in nature than the association relationship. In this particular example we could say that a Course explains a topic and could use one or more Books for that. But when a better source emerges, we would then use that.
Association
The model models the situation. In this case, a Teacher and Classroom are more permanent in nature than a Dependency. A Teacher is assigned to a specific Classroom to teach in, with the intent that it stays this way. The Teacher and Classroom are linked. They “know” about each other.
- A Teacher has been assigned a Classroom to teach in, and the Classroom keeps a record of which teachers have taught there during specific time periods.
- A Teacher teaches a Course. The Course could be taught by another Teacher. Thus it is a one directional association. The Course does not know about the Teacher and does not have to know.
- A Book knows about another Book. One Book has a reference to another Book. Both are a Book though, thus the reflexive association.
Aggregation
A Department “owns” a Teacher or Teachers. The Department is the “whole” (Aggregate) and the Teacher is the “part”. So we could say to make a Department as a functioning organizational unit requires one or more Teachers to fulfill its purpose. The Department cannot function without Teachers, but does not depend on a specific Teacher. Individual Teachers may come and go.
Composition
In the example a Department is a physical Department inside a building, therefore a Department cannot exist outside the building. The building is made up of Department(s). When the Building is gone, so is the Department.
Generalization
The example is a bit Abstract (no pun intended). This is about inheritance. We could see AbstractClassroom as “Animal” and Classroom as “Cat” or “Dog”. In this case our Classroom is of type (is a): AbstractClassroom. Teacher could have inherited from a class called Person and Building from PhysicalStructure or something.
Realization
AbstractClassroom implements the IClassroom interface.
I’ve seen a lot of examples explaining Interfaces as a mere contract, but I prefer to explain it as an additional Datatype without any implementation that a Class could have. In this case not only does AbstractClassroom implement the contract of IClassroom, but I could add the Classroom instance to a List that holds IClassroom instances as well. When we Realize or Implement the interface on a Class, that class is now of that type as well. The implementations of the behavior are the concern of the class that implements it. The contract is what is needed to define the datatype.
Modifiers
Inside the Box that represents a class in the images, the following symbols have the following meaning:
- – (single dash) means private accessibility.
- # (hash) means protected accessibililty.
- + (plus) means public accessibility.
Conclusion
A quick overview and example to refresh how to create a class diagram in UML. It is important to keep in mind that the specific situation to model determines the relationship types to be used. In this example the relationship between a Teacher and a Classroom is modeled as association. But in another context, it might have been an aggregation.
References
Pilone, D. (2006). UML 2.0 Pocket Reference (Pocket Reference (O’Reilly)). In O’Reilly Media, Inc. eBooks. https://dl.acm.org/citation.cfm?id=1212142
UML® – Unified Modeling Language | Object Management Group. https://www.omg.org/uml/
