CLASS DIAGRAM
In object-oriented programming (OOP), a class is a blueprint or template for
creating objects. Objects are instances of classes, and each class defines a set of
attributes (data members) and methods (functions or procedures) that the
objects created from that class will possess. The attributes represent the
characteristics or properties of the object, while the methods define the
behaviors or actions that the object can perform.
UML Class Notation
class notation is a graphical representation used to depict classes and their
relationships in object-oriented modeling.
1. Class Name:
The name of the class is typically written in the top compartment of the
class box and is centered and bold.
2. Attributes:
Attributes, also known as properties or fields, represent the data members
of the class. They are listed in the second compartment of the class box
and often include the visibility (e.g., public, private) and the data type of
each attribute.
3. Methods:
Methods, also known as functions or operations, represent the behavior
or functionality of the class. They are listed in the third compartment of
the class box and include the visibility (e.g., public, private), return type,
and parameters of each method.
4. Visibility Notation:
Visibility notations indicate the access level of attributes and methods.
Common visibility notations include:
o + for public (visible to all classes)
o - for private (visible only within the class)
o # for protected (visible to subclasses)
o ~ for package or default visibility (visible to classes in the same
package)
Relationships between classes
UML is not just about pretty pictures. If used correctly, UML precisely conveys
how code should be implemented from diagrams. If precisely interpreted, the
implemented code will correctly reflect the intent of the designer. Can you
describe what each of the relationships mean relative to your target
programming language shown in the Figure below?
If you can't yet recognize them, no problem this section is meant to help you to
understand UML class relationships. A class may be involved in one or more
relationships with other classes. A relationship can be one of the following
types:
Inheritance (or Generalization):
A generalization is a taxonomic relationship between a more general classifier
and a more specific classifier. Each instance of the specific classifier is also an
indirect instance of the general classifier. Thus, the specific classifier inherits
the features of the more general classifier.
Represents an "is-a" relationship.
An abstract class name is shown in italics.
SubClass1 and SubClass2 are specializations of SuperClass.
The figure below shows an example of inheritance hierarchy. SubClass1 and
SubClass2 are derived from SuperClass. The relationship is displayed as a solid
line with a hollow arrowhead that points from the child element to the parent
element.
Inheritance Example - Shapes
The figure below shows an inheritance example with two styles. Although the
connectors are drawn differently, they are semantically equivalent.
Association
Associations are relationships between classes in a UML Class Diagram. They
are represented by a solid line between classes. Associations are typically
named using a verb or verb phrase which reflects the real world problem
domain.
Simple Association
A structural link between two peer classes.
There is an association between Class1 and Class2
The figure below shows an example of simple association. There is an
association that connects the <<control>> class Class1 and <<boundary>> class
Class2. The relationship is displayed as a solid line connecting the two classes.
Cardinality
Cardinality is expressed in terms of:
one to one
one to many
many to many
Aggregation
A special type of association.
It represents a "part of" relationship.
Class2 is part of Class1.
Many instances (denoted by the *)
of Class2 can be associated with
Class1.
Objects of Class1 and Class2 have
separate lifetimes.
The figure below shows an example of aggregation. The relationship is
displayed as a solid line with a unfilled diamond at the association end, which
is connected to the class that represents the aggregate.
Composition
A special type of aggregation where parts are destroyed when the whole is
destroyed.
Objects of Class2 live and die with Class1.
Class2 cannot stand by itself.
The figure below shows an example of composition. The relationship is
displayed as a solid line with a filled diamond at the association end, which is
connected to the class that represents the whole or composite.
Dependency
An object of one class might use an object of another class in the code of a
method. If the object is not stored in any field, then this is modeled as a
dependency relationship.
A special type of association.
Exists between two classes if changes to the definition of one may cause
changes to the other (but not the other way around).
Class1 depends on Class2
The figure below shows an example of dependency. The relationship is
displayed as a dashed line with an open arrow.
The figure below shows another example of dependency. The Person class
might have a hasRead method with a Book parameter that returns true if the
person has read the book (perhaps by checking some database).
Realization
Realization is a relationship between the blueprint class and the object
containing its respective implementation level details. This object is said to
realize the blueprint class. In other words, you can understand this as the
relationship between the interface and the implementing class.
For example, the Owner interface might specify methods for acquiring property
and disposing of property. The Person and Corporation classes need to
implement these methods, possibly in very different ways.
Class Diagram Example: Order System
