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