Scribd
Upload
10 views

UML Class Diagram Tutorial

A Class serves as a blueprint for creating Objects, defining their properties and methods, while Objects are instances of Classes with specific states and behaviors. UML class relationships include Inheritance, Association, Aggregation, Composition, Dependency, and Realization, each illustrating different types of connections between Classes. Understanding these relationships is essential for accurately implementing code based on UML diagrams.

Uploaded by

snehasharma12679
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
10 views

UML Class Diagram Tutorial

A Class serves as a blueprint for creating Objects, defining their properties and methods, while Objects are instances of Classes with specific states and behaviors. UML class relationships include Inheritance, Association, Aggregation, Composition, Dependency, and Realization, each illustrating different types of connections between Classes. Understanding these relationships is essential for accurately implementing code based on UML diagrams.

Uploaded by

snehasharma12679
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

What is a Class?

A Class is a blueprint for an object. Objects and classes go hand


in hand. We can't talk about one without talking about the other.
And the entire point of Object-Oriented Design is not about
objects, it's about classes, because we use classes to create
objects. So a class describes what an object will be, but it isn't the
object itself.

In fact, classes describe the type of objects, while objects are


usable instances of classes. Each Object was built from the same
set of blueprints and therefore contains the same components
(properties and methods). The standard meaning is that an object
is an instance of a class and object - Objects have states and
behaviors.

Example

A dog has states - color, name, breed as well as behaviors -


wagging, barking, eating. An object is an instance of a class.
:
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.
:
:

You might also like