Class Diagram
"In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among objects." - Wikipedia
The class diagram is the main building block of object-oriented modeling. It is used for general conceptual modeling of the structure of the application, and for detailed modeling translating the models into programming code. Class diagrams can also be used for data modeling. The classes in a class diagram represent both the main elements, interactions in the application, and the classes to be programmed.
classDiagram
Animal <|-- Duck
Animal <|-- Fish
Animal <|-- Zebra
Animal : +int age
Animal : +String gender
Animal: +isMammal()
Animal: +mate()
class Duck{
+String beakColor
+swim()
+quack()
}
class Fish{
-int sizeInFeet
-canEat()
}
class Zebra{
+bool is_wild
+run()
}
Syntax
Class
UML provides mechanisms to represent class members, such as attributes and methods, and additional information about them. A single instance of a class in the diagram contains three compartments:
- The top compartment contains the name of the class. It is printed in bold and centered, and the first letter is capitalized. It may also contain optional annotation text describing the nature of the class.
- The middle compartment contains the attributes of the class. They are left-aligned and the first letter is lowercase. The bottom compartment contains the operations the class can execute. They are also left-aligned and the first letter is lowercase.
classDiagram
class BankAccount
BankAccount : +String owner
BankAccount : +BigDecimal balance
BankAccount : +deposit(amount)
BankAccount : +withdrawl(amount)
Define a class
There are two ways to define a class:
- Explicitly defining a class using keyword class like
class Animal. This defines the Animal class - Define two classes via a relationship between them
Vehicle <|-- Car. This defines two classes Vehicle and Car along with their relationship.
classDiagram
class Animal
Vehicle <|-- Car
Naming convention: a class name should be composed of alphanumeric (unicode allowed) and underscore characters.
Defining Members of a class
UML provides mechanisms to represent class members, such as attributes and methods, and additional information about them.
Quick Diagram distinguishes between attributes and functions/methods based on if the parenthesis () are present or not. The ones with () are treated as functions/methods, and others as attributes.
There are two ways to define the members of a class, and regardless of whichever syntax is used to define the members, the output will still be same. The two different ways are :
- Associate a member of a class using : (colon) followed by member name, useful to define one member at a time. For example:
classDiagram
class BankAccount
BankAccount : +String owner
BankAccount : +BigDecimal balance
BankAccount : +deposit(amount)
BankAccount : +withdrawl(amount)
- Associate members of a class using {} brackets, where members are grouped within curly brackets. Suitable for defining multiple members at once. For example:
classDiagram
class BankAccount{
+String owner
+BigDecimal balance
+deposit(amount) bool
+withdrawl(amount) int
}
Return Type
Optionally you can end the method/function definition with the data type that will be returned (note: there must be a space between the final ) of the method definition and return type
example:
classDiagram
class BankAccount{
+String owner
+BigDecimal balance
+deposit(amount) bool
+withdrawl(amount) int
}
Generic Types
Members can be defined using generic types, such as List<int>, for fields, parameters and return types by enclosing the type within ~ (tilde). Note: nested type declarations (such as List<List<int>>) are not currently supported
This can be done as part of either class definition method:
classDiagram
class Square~Shape~{
int id
List~int~ position
setPoints(List~int~ points)
getPoints() List~int~
}
Square : -List~string~ messages
Square : +setMessages(List~string~ messages)
Square : +getMessages() List~string~
Visibility
To specify the visibility of a class member (i.e. any attribute or method), these notations may be placed before the member's name, but it is optional:
+Public-Private#Protected~Package/Internal
note you can also include additional classifers to a method definition by adding the following notations to the end of the method, i.e.: after the
():
*Abstract e.g.:someAbstractMethod()*$Static e.g.:someStaticMethod()$
Defining Relationship
A relationship is a general term covering the specific types of logical connections found on class and object diagrams.
[classA][Arrow][ClassB]:LabelText
There are different types of relations defined for classes under UML which are currently supported:
| Type | Description | |
|---|---|---|
| <\ | -- | Inheritance |
| *-- | Composition | |
| o-- | Aggregation | |
| --> | Association | |
| -- | Link (Solid) | |
| ..> | Dependency | |
| ..\ | > | Realization |
| .. | Link (Dashed) |
classDiagram
classA <|-- classB
classC *-- classD
classE o-- classF
classG <-- classH
classI -- classJ
classK <.. classL
classM <|.. classN
classO .. classP
We can use the labels to describe nature of relation between two classes. Also, arrowheads can be used in opposite directions as well :
classDiagram
classA --|> classB : Inheritance
classC --* classD : Composition
classE --o classF : Aggregation
classG --> classH : Association
classI -- classJ : Link(Solid)
classK ..> classL : Dependency
classM ..|> classN : Realization
classO .. classP : Link(Dashed)
Labels on Relations
It is possible to add a label text to a relation:
[classA][Arrow][ClassB]:LabelText
classDiagram
classA <|-- classB : implements
classE o-- classF : association
Cardinality / Multiplicity on relations
Multiplicity or cardinality in class diagrams indicates the number of instances of one class linked to one instance of the other class. For example, one company will have one or more employees, but each employee works for just one company.
Multiplicity notations are placed near the ends of an association.
The different cardinality options are :
0..1Zero or one1Only 10..1Zero or One1..*One or more*Manynn {where n>1}0..nzero to n {where n>1}1..none to n {where n>1}
Cardinality can be easily defined by placing cardinality text within qoutes " before(optional) and after(optional) a given arrow.
[classA] "cardinality1" [Arrow] "cardinality2" [ClassB]:LabelText
classDiagram
Customer "1" --> "*" Ticket
Student "1" --> "1..*" Course
Galaxy --> "many" Star : Contains
Annotations on classes
It is possible to annotate classes with a specific marker text which is like meta-data for the class, giving a clear indication about its nature. Some common annotations examples could be:
<<Interface>>To represent an Interface class<<abstract>>To represent an abstract class<<Service>>To represent a service class<<enumeration>>To represent an enum
Annotations are defined within the opening << and closing >>. There are two ways to add an annotation to a class and regardless of the syntax used output will be same. The two ways are :
- In a separate line after a class is defined. For example:
classDiagram
class Shape
<<interface>> Shape
Shape : noOfVertices
Shape : draw()
- In a nested structure along with class definition. For example:
classDiagram
class Shape{
<<interface>>
noOfVertices
draw()
}
class Color{
<<enumeration>>
RED
BLUE
GREEN
WHITE
BLACK
}
Comments
Comments can be entered within a class diagram, which will be ignored by the parser. Comments need to be on their own line, and must be prefaced with %% (double percent signs). Any text after the start of the comment to the next newline will be treated as a comment, including any class diagram syntax
classDiagram
%% This whole line is a comment classDiagram class Shape <<interface>>
class Shape{
<<interface>>
noOfVertices
draw()
}