This is the summary of the class diagram relation types from the book: Creating Software with Modern Diagramming Techniques by Ashley Peacock.
| Type | Description |
|---|---|
--> |
Association |
o-- |
Aggregation |
*-- |
Composition |
-- |
Link (Solid) |
<|-- |
Inheritance |
..> |
Dependency |
..|> |
Realization |
.. |
Link (Dashed) |
classDiagram
direction LR
Car "1.." -- "0.." Road : drives on
Association: there is a relationship between the entities, with at least one entity holding a reference to the other. There is no owner of the relationship though, and they can exist completely independently of one another. An example separate to Streamy might be a Teacher and Student relationship.
classDiagram
direction LR
Driver "1.." o-- "0.." Car : drives
Aggregations: there is a more direct relationship between the entities than an association, but they can still exist independently of one another. There is an owner of the relationship, however if the parent is deleted, the child can still remain. Continuing the education theme, a Teacher has an aggregate relationship to Class. You could delete the Teacher, but the Class would still remain and make sense on its own.
classDiagram
direction LR
Driver "1" *-- "0..1" License : has
Compositions: the closest of relationships is reserved for compositions. Similarly to aggregations, there is an owner of the relationship. However, if the parent is deleted, the child must be deleted too, and makes no sense without its parent relationship. Picking up the education theme once more, Grade could be a composite relation to Class-if the Class were deleted, the Grade probably wouldn’t make sense unless it’s linked to a Class.
classDiagram
direction TB
Car <|-- RaceCar
Car <|-- OffroadCar
Inheritence: Generalisations are probably the simplest of associations as they are more familiar and easily recognisable to anyone who’s worked with inheritance in programming, and they behave in exactly the same way.
classDiagram
direction LR
Mechanic "1.." --> "0.." Car : services
Relations: One of the key features of a domain model written with UML is that you can, and should, describe how the entities interact with regard to their relationships. In a lot of cases, and in the case of our domain model we have so far, a lot of the descriptions can be simply described as has. You should try to be as descriptive as possible, and try to avoid using has for everything where possible.