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.
Contents
1)
Members
a)
Visibility
b)
Scopes
2)
Relationships
a)
Instance level relationships
i)
Links
ii)
Association
iii)
Aggregation
iv)
Composition
v)
Differences between composition
and aggregation
b)
Class level relationships
i)
Generalization
ii)
Realization
c)
General relationship
i)
Dependency
d)
Multiplicity
Class Diagram
The class diagram is the
main building block of object oriented modelling.
In the diagram, classes are
represented with boxes which contain three parts:
·
The top part contains the name of the class. It is printed in bold and centred,
and the first letter is capitalized.
·
The middle part contains the attributes of the class. They are
left-aligned and the first letter is lowercase.
·
The bottom part contains the methods the class can execute. They are
also left-aligned and the first letter is lowercase.
Members
Visibility
To specify the visibility of
a class member (i.e., any attribute or method), these notations must be placed
before the member's name.
|
+
|
Public
|
|
-
|
Private
|
|
#
|
Protected
|
|
/
|
Derived
|
|
~
|
Package
|
Scopes
The UML specifies two types of scope for members: instance and classifier.
·
Classifier members are commonly recognized as “static” in many
programming languages. The scope is the class itself.
·
Attribute values are equal for all instances
·
Method invocation does not affect the instance’s state
·
Instance members are scoped to a specific instance.
·
Attribute values may vary between instances
·
Method invocation may affect the instance’s state (i.e., change
instance’s attributes)
Relationships
1) Instance level
relationships
a) Links
A Link is the basic relationship among
objects
b) Association
An association represents a family of links. A binary
association (with two ends) is normally represented as a line. An association
can link any number of classes. An association with three links is called a
ternary association. There are four different types of association:
bi-directional, uni-directional, Aggregation (includes Composition aggregation)
and Reflexive. Association
represents the static relationship shared among the objects of two classes.
Class diagram example of association between
two classes
c) Aggregation
Aggregation is a variant of the "has a"
association relationship; aggregation is more specific than association. It is
an association that represents a part-whole or part-of relationship.
Aggregation can occur when a class is a collection or
container of other classes, but the contained classes do not have a strong lifecycle dependency on the container. The contents of the
container are not automatically destroyed when the container is.
In UML, it is graphically represented as a hollow diamond shape on the containing class with a single line that connects
it to the contained class.
Class diagram showing Aggregation between two
classes
d) Composition
Composition is a stronger variant of the "has a"
association relationship; composition is more specific than aggregation. Composition usually has a strong lifecycle dependency between instances of the container
class and instances of the contained class(es): if the container is destroyed,
normally every instance that it contains is destroyed as well.
The UML graphical
representation of a composition relationship is a filled diamond shape on the containing class
end of the tree of lines that connect contained class(es) to the containing
class.
Class diagram showing Composition between two
classes at top and Aggregation between two classes at bottom
Differences between composition and aggregation
Composition relationship: When attempting to represent real-world
whole-part relationships, e.g., an engine is a part of a car.
Aggregation relationship: When representing a software or database relationship, e.g., car model engine ENG01 is part of a car model CM01, as the engine, ENG01 may be also part of a different car model.
Aggregation relationship: When representing a software or database relationship, e.g., car model engine ENG01 is part of a car model CM01, as the engine, ENG01 may be also part of a different car model.
2) Class level
relationships
a) Generalization
The Generalization
relationship ("is a") indicates that one of the two related classes
(the subclass) is
considered to be a specialized form of the other (the super type) and the superclass
is considered a 'Generalization' of the subclass.
The UML graphical
representation of a Generalization is a hollow triangle shape on the superclass end of the line (or tree of
lines) that connects it to one or more subtypes.
The generalization relationship
is also known as the inheritance or "is
a" relationship.
The superclass (base
class) in the generalization relationship is also known as the "parent", superclass, base class, or base type.
The subtype in the specialization
relationship is also known as the "child", subclass, derived class, derived type, inheriting class, or inheriting type.
Class diagram showing generalization between
one superclass and two subclasses
b) Realization
In UML modelling, a
realization relationship is a relationship between two model elements, in which
one model element (the client) realizes (implements or executes) the behaviour
that the other model element (the supplier) specifies.
The UML graphical representation
of a Realization is a hollow triangle shape on the interface end of the dashed line (or tree of lines) that connects
it to one or more implementers.
A realization is a
relationship between classes, interfaces, components, and packages that connects
a client element with a supplier element. A realization relationship between
classes and interfaces and between components and interfaces shows that the
class realizes the operations offered by the interface.
3) General relationship
a) Dependency
Dependency is a weaker form of bond which indicates that one class
depends on another because it uses it at some point in time. One class depends
on another if the independent class is a parameter variable or local variable
of a method of the dependent class. This is different from an association,
where an attribute of the dependent class is an instance of the independent
class. Sometimes the relationship between two classes is very weak. They are
not implemented with member variables at all. Rather they might be implemented
as member function arguments.
Class diagram showing dependency between
"Car" class and "Wheel" class (An even clearer example
would be "Car depends on Wheel", because Car already aggregates (and not just uses) Wheel)
b) Multiplicity
This association
relationship indicates that (at least) one of the two related classes make
reference to the other. This relationship is usually described as "A has a
B" (a mother cat has kittens, kittens have a mother cat).
The UML representation of an
association is a line with an optional arrowhead indicating the role of the object(s) in the relationship,
and an optional notation at each end indicating the multiplicity of instances of that entity (the
number of objects that participate in the association).
|
0..1
|
No instances, or one instance
|
|
1
|
Exactly one instance
|
|
0..*
|
Zero or more instances
|
|
1..*
|
One or more instances
|
