Scribd
Upload
7 views

UNIT 1_UML Basic Notations

The document outlines the basic notations used in UML, including representations for classes, objects, components, interfaces, and packages. It explains various relationships such as inheritance, association, aggregation, composition, and dependency, along with their respective notations and multiplicity. Additionally, it provides examples to illustrate these concepts in UML diagrams.

Uploaded by

sushantsinghrajput2902
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
7 views

UNIT 1_UML Basic Notations

The document outlines the basic notations used in UML, including representations for classes, objects, components, interfaces, and packages. It explains various relationships such as inheritance, association, aggregation, composition, and dependency, along with their respective notations and multiplicity. Additionally, it provides examples to illustrate these concepts in UML diagrams.

Uploaded by

sushantsinghrajput2902
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 37

UML Basic Notations

UML defines specific notations for each of the building


blocks.
Class
• A class is represented by a rectangle having three sections −
• the top section containing the name of the class
• the middle section containing class attributes
• the bottom section representing operations of the class
The visibility of the attributes and operations can be represented in the following ways −
• Public − A public member is visible from anywhere in the system. In class diagram, it is
prefixed by the symbol ‘+’.
• Private − A private member is visible only from within the class. It cannot be accessed from
outside the class. A private member is prefixed by the symbol ‘−’.
• Protected − A protected member is visible from within the class and from the subclasses
inherited from this class, but not from outside. It is prefixed by the symbol ‘#’.
• An abstract class has the class name written in italics.
• Example − Let us consider the Circle class introduced earlier.
The attributes of Circle are x-coord, y-coord, and radius. The
operations are findArea(), findCircumference(), and scale(). Let
us assume that x-coord and y-coord are private data members,
radius is a protected data member, and the member functions
are public. The following figure gives the diagrammatic
representation of the class.
Object
An object is represented as a rectangle with two sections −
An object is represented as a rectangle with two sections −
• The top section contains the name of the object with the name of the
class or package of which it is an instance of. The name takes the
following forms −
• object-name − class-name
• object-name − class-name :: package-name
• class-name − in case of anonymous objects
• The bottom section represents the values of the attributes. It takes
the form attribute-name = value.
• Sometimes objects are represented using rounded rectangles.
• Example − Let us consider an object of the class Circle named
c1. We assume that the center of c1 is at (2, 3) and the radius of
c1 is 5. The following figure depicts the object.
Component
A component is a physical and replaceable part of the system that
conforms to and provides the realization of a set of interfaces. It
represents the physical packaging of elements like classes and
interfaces.
• Notation − In UML diagrams, a component is represented by a
rectangle with tabs as shown in the figure below.
Interface
• Interface is a collection of methods of a class or component. It
specifies the set of services that may be provided by the class or
component.
• Notation − Generally, an interface is drawn as a circle together
with its name. An interface is almost always attached to the
class or component that realizes it. The following figure gives
the notation of an interface.
Package
• A package is an organized group of elements. A package may
contain structural things like classes, components, and other
packages in it.
• Notation − Graphically, a package is represented by a tabbed
folder. A package is generally drawn with only its name.
However it may have additional details about the contents of
the package. See the following figures.
Relationship
• The notations for the different types of relationships are as follows
−
Usually, elements in a relationship play specific roles in the relationship. A role
name signifies the behavior of an element participating in a certain context.
Example − The following figures show examples of different relationships
between classes.
• The first figure shows an association between two classes,
Department and Employee, wherein a department may have a
number of employees working in it. Worker is the role name.
The ‘1’ alongside Department and ‘*’ alongside Employee
depict that the cardinality ratio is one–to–many.

• The second figure portrays the aggregation relationship, a


University is the “whole–of” many Departments.
Show relationships
This is the fun part, class diagram relationships and
showing how each class may interact with another.

• Inheritance
Also known as generalization, this is a relationship where a
subclass inherits attributes, methods and other relationships
from a superclass.
• Association
Sometimes called simple association, this is a relationship
that indicates one class is related to another but not
necessarily dependent.
• Aggregation
A special type of association, aggregation is where one
class contains, or is composed of, other classes. A whole
and its parts.
These parts can exist independently of the larger class and
may be shared among multiple wholes.
The shape of this connection is a hollow diamond attached
to the "part" with a solid line going back to the "whole" or
class.
• Composition
On the flipside is composition, where a part cannot exist
without the whole, or superclass.
Expanding the example further and adding a couple more
classes; stadiums and snack bars. If the team’s stadium is
torn down, the snack bar can’t exist.
This is drawn with a solid line and filled in diamond at the
superclass, or stadium in this case.
• Dependency
This is a relationship where one class relies on another in
some way, often through method parameters, return types
or temporary associations.
Coaches and players are related in this way, where the
coach depends on the performance data or behavior of
players to make strategic decisions.
We’d show this with a dashed line and an open arrow.
Add multiplicity notation (if necessary)
• Multiplicity specifies how many instances of one class are
associated with instances of another class in an association.
• For example, the player and team association would have multiplicity
notation to indicate there are multiple players on a team.
• The way we show that on the structure diagram is as follows:
• 0..1 = zero to one
• 1 = exactly one
• 0..* = zero to many
• 1..* = one to many
• n..m = specific number range
• Example:
• https://www.visual-paradigm.com/guide/uml-unified-
modeling-language/uml-class-diagram-tutorial/
• Association(using relationship): The objects created and
destroyed independently and represented as one-to-one, one-
to-many, or many-to-many (also known as cardinality).
• Aggregation(HAS-A relationship): parent can exist without
child and a child can exist independently of the parent and
this involve a one-to-one, one-to-many, or many-to-many
relationship between the participating objects.
• composition(“death” relationship, PART-OF): parent
destroyed, child dies
• Inheritance : is-a relationship.

You might also like