Chapter II:

Modeling with UML

August, 2024
Bahir Dar, Ethiopia
Prepared By: Shwaga A.
 8/9/2024

2 CONTENTS…

• Overview of UML
• Building Blocks of the UML
▪ Things in the UML
▪ Relationships in the UML
▪ Diagrams in the UML
 8/9/2024

3 Overview of the UML

• Modeling consists of building an abstraction of reality.

• Abstractions are simplifications because:
• They ignore irrelevant details and
• They only represent the relevant details.
• What is relevant or irrelevant depends on the purpose of the model.
 8/9/2024

4 Cont’d…

• UML (Unified Modeling Language)

• An emerging standard for modeling object-oriented software.
• Resulted from the convergence of notations from three leading
object-oriented methods:
• OMT (James Rumbaugh)(class diagrams)
• OOD (Grady Booch)
• OOSE (Ivar Jacobson)(use case diagrams)
• The Unified Modeling Language (UML) is one of the most exciting and
useful tools in the world of system development.
 8/9/2024

5 Cont’d…

• UML is a standard language for specifying, visualizing, constructing,

and documenting the artifacts of software systems.
• UML as a Language for Visualizing - The vision for the system being
developed can be easily communicated through UML and thus the
software team has a unified vision of a system that is only described in
specification and requirement documents.
• A picture is worth a thousand words; a graphical notation articulates
and unambiguously communicates the overall view of the system
(problem domain).
 8/9/2024

6 Cont’d…

• UML as a Language for Specifying - the structure or behavior of a system

can be described with UML.
• i.e , UML provides the means to model precisely, unambiguously
and completely.
• UML as a Language for Constructing - UML’s models can be directly
connected or converted to a variety of programming languages like C++,
Java, or Visual Basic with no ambiguity.This facilitates forward engineering.
• Models built with UML have a “design” dimension to it; these are
language independent and can be implemented in any programming
language.
 8/9/2024

7 Cont’d…

• UML as a Language for Documenting - UML provides a language for

expressing requirements, tests, activities of project planning and release
management.
• Some of the artifacts that may need to be documented are: Requirements,
Architecture, Design, Source Code, Project Plan, Tests, Prototypes, and
Releases.
• Every software project involves a lot of documentation
 8/9/2024

8 Why do we model software?

• A model is a simplification of reality.

• Software is getting increasingly more complex
• A single programmer cannot manage this amount of code in its
entirety.
• Code is not easily understandable by developers who did not write it
• We need simpler representations for complex systems
• Modeling is a mean for dealing with complexity
• We build models so that we can better understand the system we
are developing
 8/9/2024

9 Benefits

• Models help us to visualize a system as it is or as we want it to be.

• Models permit us to specify the structure or behavior of a system.
• Models give us a template that guides us in constructing a system.
• Models document the decisions we have made.
• The UML gives everyone from business analyst to designer to
programmer a common vocabulary to talk about software design.
 8/9/2024

10 Building blocks of the UML

• The building blocks of UML can be defined as:

1) Things
2) Relationships
3) Diagrams
• Things are the abstractions that are first-class citizens in a model
• Relationships tie these things together
• Diagrams group interesting collections of things.
 8/9/2024

11
 8/9/2024

12 Structural things

• Structural things are the nouns of the UML models. These are mostly
static parts of the model, representing conceptual or physical elements.
• Structural things are called classifiers.
• Structural thing include classes, interfaces, collaborations, use cases,
components, and nodes.

• A class
• is a description of a set of objects that share the same attributes,
operations, relationships, and semantics.
 8/9/2024

13 Class

• A class implements one or more

interfaces.
• Graphically, a class is rendered as a
rectangle, usually including its name,
attributes, and operations
• Class represents set of objects having
similar responsibilities.
 8/9/2024

14 Interface

• Interface defines a set of operations

which specify the responsibility of a
class. Or
• is a collection of operations that
specify a service of a class or
component.
 8/9/2024

15 Collaboration

• Collaboration defines interaction between elements.

• A given class or object might participate in several
collaborations
• A use case
• It’s a description of sequences of actions that a system
performs that yield observable results of value to a
particular actor.
• A use case is used to structure the behavioral things in a
model.
 8/9/2024

16 Component

• Component describes physical part of a system.

• It is a modular part of the system design that hides its implementation behind
a set of external interfaces.
 8/9/2024

17 Node

• A node can be defined as a physical element that exists

at run time and represents a computational resource,
generally having at least some memory and, often, processing
capability.
• Examples: a server, network etc
• Graphically, a node is rendered as a cube, usually including
only its name as shown in the following figure
 8/9/2024

18 Behavioral things

• Behavioral things are the dynamic parts of UML models.

• These are the verbs of a model , representing behavior over time and space.
• There are three primary kinds of behavioral things:
• an interaction
• a state machine
• an activity
• An interaction is used to represent communication among the components of
a system.
• Interaction is basically message exchange between two UML components.
 8/9/2024

19 An Interaction

• An interaction is a behavior that comprises a set of messages exchanged

among a set of objects or roles within a particular context to accomplish a
specific purpose.
• Graphically, a message is rendered as a directed line, including the name of its
operation as shown below
 8/9/2024

20 State machine

• State machine describes the different states of a component in its life

cycle.
• The behavior of an individual class or a collaboration of classes may be
specified with a state machine.
• Graphically, a state is rendered as a rounded rectangle, usually including its
name and its substates
• A State machine is used to describe different states of a system component.
• The state can be active, idle or any other depending upon the situation.
 8/9/2024

21 State machine

• A state diagram is used to represent the condition of the system or part of the
system at finite instances of time. It’s a behavioral diagram and it represents the
behavior using finite state transitions.
• State diagrams are also referred to as State machines and State-chart
Diagrams .
• These terms are often used interchangeably. So simply, a state diagram is used
to model the dynamic behavior of a class in response to time and changing
external stimuli.
 8/9/2024

22 Activity

• An activity is a behavior that specifies the sequence of steps a computational

process performs.
• In an interaction, the focus is on the set of objects that interact.
• In a state machine, the focus is on the life cycle of one object at a time.
• In an activity, the focus is on the flows among steps without regard to which
object performs each step.
 8/9/2024

23 Activity

• We use Activity Diagrams to illustrate the flow of control in a system.

• We can also use an activity diagram to refer to the steps involved in the
execution of a use case.
• We model sequential and concurrent activities using activity diagrams.
• So, we basically depict workflows visually using an activity diagram.
• An activity diagram focuses on condition of flow and the sequence in which it
happens.
• We describe or depict what causes a particular event using an activity diagram.
 8/9/2024

24 Grouping things

• Grouping things are the organizational parts of UML models.

• In UML there is only one element available for grouping and that is package.

• Package
• A package is a general purpose mechanism for organizing elements into
groups.
• Structural things, behavioral things, and even other grouping things may be
placed in a package.
• The packages are used to wrap the components of a system.
 8/9/2024

25 Grouping things

• Graphically a package is rendered as a tabbed folder, usually including

only its name and sometimes, its contents.
 8/9/2024

26 Annotational things

• Annotational things are the explanatory parts of UML models.

• These are the comments you may apply to describe, illuminate, and remark
about any element in a model.
• There is one primary kind of annotational thing called a note.
• A note is simply a symbol for rendering constraints and comments
attached to an element or a collection of elements
• Graphically, a note is rendered as a rectangle with a dog-eared corner,
together with a textual or graphical comment. It may be anchored to an The schedule can
element with a dashed line. MaintainSchedule be update
 8/9/2024

27 Relationships in the UML

• Objects do not exist in isolation, they exist in relationship to other objects

• There are four kinds of relationships in the UML:
i. Dependency
ii. Associations
• Association
• Aggregation (special type of association)
• Composition(special type aggregation)
iii. Generalization
iv. Realization
• These relationships are the basic relational building blocks of the UML.
• You use them to write well-formed models.
 8/9/2024

28 Dependency relationship

• Dependency is an important aspect in UML elements.

• It describes the dependent elements and the direction of dependency.
• Dependency is a semantic relationship where a change in one thing (the
independent thing) causes a change in the semantics of the other thing (the
dependent thing).

• Client class depends on the Supplier class.

 8/9/2024

29 Dependency relationship

• The notation used for dependency is a dashed line with an

arrowhead.
• The arrow head represents the independent element and the other end the
dependent element.

• If something changes in meeting then this would affect schedule but the
reverse is not true
 8/9/2024

30 Association relationship

• Association
• An association is a structural relationship that specifies how objects
(instances of classes) are connected to other objects.
• describes how the elements in an UML diagrams are associated.
• In simple word it describes how many elements are taking part in an
interaction.
• Association is represented by a line with (without) arrows on both
sides.
 8/9/2024

31 Associations relationships

• We can also indicate the behavior of an object in an association (i.e., the role
of an object) using role names.
 8/9/2024

32 Aggregation relationship

• Aggregation indicates a relationship between a whole and its parts

• Aggregation is a special kind of association, representing a structural
relationship between a whole and its parts.
• Has-a relationship
• The part can exist separately from the whole
 8/9/2024

33 Composition

• Strong form of aggregation where the part can not exist separately from
the whole
• That means the construction and destruction of the part depend on the whole

• A department is part of a company. The construction and destruction of a

department depends on the company
 8/9/2024

34 Generalization

• Generalization describes the inheritance relationship of the object oriented

world. It is parent and child relationship.
• A generalization is a specialization/generalization relationship in which the
specialized element (the child) builds on the specification of the generalized
element (the parent).
• Is -a kind-of relationship
• Relationship between a general thing and a more specific kind of that thing (i.e
super class and subclass)
• A child inherits + reuses the non private parent classes attributes and
operations.
• The child can have additional attributes and operation of its own
 8/9/2024

35 Generalization

• Generalization describes the inheritance relationship of the object oriented

world. It is parent and child relationship.
 8/9/2024

36 Realization

• Realization can be defined as a relationship in which two elements are

connected.
• One element describes some responsibility which is not implemented and the
other one implements them.
• You'll encounter realization relationships in two places:
• between interfaces and the classes or components that realize them,
• and between use cases and the collaborations that realize them.
• Graphically, a realization relationship is rendered as a cross between a
generalization and a dependency relationship
 8/9/2024

37 Multiplicity

• Multiplicity is a definition of cardinality - i.e. number of elements - of

some collection of elements by providing an inclusive interval of non-negative
integers to specify the allowable number of instances of described element.
• Multiplicity interval has some lower bound and (possibly infinite) upper
bound
• Multiplicity allows us to specify how many objects are participating in
relationships
• It is the number of instances of one class that relate to one instance of
another class. For each association, there are two multiplicity decisions to
make, one for each end of the association.
• How many objects are associated
 8/9/2024

38 Multiplicity
 8/9/2024

39 Multiplicity

• As shown below, House has exactly

one kitchen, one bath and one
bedroom
✓ kitchen, bath and bedroom
exist only if the house
exist(composition)
✓All kitchen, bath and bedroom
are rooms(inheritance)
 8/9/2024

40 What is Application and Solution Domain

• Application Domain (Requirements Analysis)

• The environment in which the system is operating
• Solution Domain (System Design, Object Design)
• The available technologies to build the system
 8/9/2024

41 UML Diagrams

• System development focuses on three different models of the

system:
• The functional model, represented in UML with use case diagrams, describes
the functionality of the system from the user’s point of view.
• The object model, represented in UML with class diagrams, describes the
structure of a system in terms of objects, attributes, associations, and
operations.
 8/9/2024

42 UML Diagrams

• The dynamic model, represented in UML with sequence diagrams, statechart

diagrams, and activity diagrams, describes the intern al behavior of the system.
• Sequence diagrams describe behavior as a sequence of messages
exchanged among a set of objects
• State chart diagrams describe behavior in terms of states of an
individual object and the possible transitions between states.
• In this activity, we describe UML diagrams for representing these models.
• It is necessary to understand the notation before describing the activities
 8/9/2024

43 UML Diagrams

• A diagram is the graphical representation of a set of elements rendered as a

connected graph of vertices (things) and arcs (relationships)
• The diagrams are graphical representation of the models which uses
various symbols and text.
• Each different symbol has a special meaning in the context of the UML. The
user can use text to describe the concepts from the system under
development.
• Each diagram has its own set of symbols.
• Each diagram captures a different dimension, view, perspective of the system.
 8/9/2024

44 UML Diagrams

a) Structural Diagrams emphasize what things must be in the system

being modeled:
b) Behavior Diagrams emphasize what must happen in the system being
modeled:
• Activity diagram
• State Machine diagram
• Use case diagram
• Interaction Diagrams, a subset of behavior diagrams, emphasize the
flow of control and data among the things in the system being
modeled:
 8/9/2024

45 UML Diagrams
 8/9/2024

46 UML: Class Diagram

• Class diagram is a static model that describe the structure of the system by
showing its classes and the relationships among them.
• Class diagrams illustrates classes, interfaces, and their associations. They are
used for static object modeling.
• Classes are abstractions that specify the attributes and behavior of a set of
objects.
• Objects are entities that encapsulate state and behavior. Each object has an
identity: It can be referred individually and is distinguishable from other
objects.
 8/9/2024

47 UML: Class Diagram

• Objects are instances of classes that are created, modified, and destroyed
during the execution of the system.
 8/9/2024

48 UML: Class Diagram notations

• Class diagrams describe the system in terms of objects, classes, attributes,

operations, and their associations.
• In UML, classes and objects are depicted by boxes including three
compartments.
• The top compartment displays the name of the class or object. The center
compartment displays its attributes, and the bottom compartment displays its
operations.
• The attribute and operation compartment can be omitted for clarity.
• Object names are underlined to indicate that they are instances.
 8/9/2024

49 Cont’d…

• By convention, class names start with an uppercase letter.

• Objects in object diagrams may be given names (followed by their class) for
ease of reference. In that case, their name starts with a lowercase letter.
• Each end of an association can be labeled by a string called role.
• Labeling the end of associations with roles allows us to distinguish multiple
associations originating from a class.
• Moreover, roles clarify the purpose of the association.
 8/9/2024

50 Cont’d…

• Class diagram can be used:

• during requirements analysis to model problem domain concepts
• during system design to model subsystems and interfaces
• during object design to model classes.
 8/9/2024

51 Cont’d…

• Class diagrams are great for:

• discovering related data and attributes
• getting a quick picture of the important entities in a system
• seeing whether you have too few/many classes
• seeing whether the relationships between objects are too complex, too
many in number, simple enough, etc.
• spotting dependencies between one class/object and another
 8/9/2024

52 Cont’d…

• Not so great for:

• discovering algorithmic (not data-driven) behavior
• finding the flow of steps for objects to solve a given problem
• understanding the app's overall control flow (event-driven? Web based?
sequential? etc.)
 8/9/2024

53 UML: Object Diagram

• An Object Diagram can be referred to as a screenshot of the instances in a

system and the relationship that exists between them.
• Since object diagrams depict behaviour when objects have been instantiated,
we are able to study the behaviour of the system at a particular instant.
• Object diagrams visualize specific instances of objects and their relationships at
a particular moment in time. They typically use real-world examples.
• In fact, they’re also known as instance diagrams because they display what the
system looks like at a specific moment in time.
 8/9/2024

54 UML: Object Diagram

• An object diagram is similar to a class diagram except it shows the instances of

classes in the system.
• We depict actual classifiers and their relationships making the use of class
diagrams.
• On the other hand, an Object Diagram represents specific instances of classes
and relationships between them at a point of time.
 8/9/2024

55 Object Diagram Notations

 8/9/2024

56 Object Diagram Notations

• Objects or Instance specifications

• When we instantiate a classifier in a system, the object we create represents
an entity which exists in the system.
• We can represent the changes in object over time by creating multiple instance
specifications.
• We use a rectangle to represent an object in an object diagram.
• Attributes and Values
• Inside the object box, attributes of the object are listed along with their
specific values.
 8/9/2024

57 Object Diagram Notations

• Link
• We use a link to represent a relationship between two objects.
• We represent the number of participants on the link for each, at the end of
the link.
• The term link is used to specify a relationship between two instance
specifications or objects.
• We use a solid line to represent a link between two objects.
 8/9/2024

58 UML: Object Diagram

• Objects are also represented in rectangles, their names underlined & written
with first letter in small case.
• Names of objects can be written in 4 ways:
• write only the class name preceded by a colon and underlined
• : Student
• write the name of specific object with it’s class
oneStudent : Student
• write only the object name oneStudent:
• multiple objects :
: Student
 8/9/2024

59 Component diagram

• Component diagrams are used to represent how the physical components in a

system have been organized. We use them for modelling implementation
details.
• Component Diagrams depict the structural relationship between software
system elements and help us in understanding if functional requirements have
been covered by planned development.
• Component Diagrams become essential to use when we design and build
complex systems.
• Interfaces are used by components of the system to communicate with each
other.
 8/9/2024

60 Component diagram

• Component diagrams visualize the internal structure of a class, including its

parts, interfaces, and collaborations.
• They provide insights into how components interact within the larger system
architecture, helping to understand the organization and dependencies of
software elements.
 8/9/2024

61 UML: Deployment Diagrams

• Deployment Diagrams are used to represent system hardware and its

software.
• It tells us what hardware components exist and what software components
run on them.
• We illustrate system architecture as distribution of software artifacts over
distributed targets.
• An artifact is the information that is generated by system software.
• They are primarily used when a software is being used, distributed or deployed
over multiple machines with different configurations.
 8/9/2024

62 UML: Deployment Diagrams

• Deployment diagrams visualize the physical deployment of software

components across nodes in a distributed system.
• They show how software and hardware interact and are essential for planning
and visualizing system deployments in various environments.
 8/9/2024

63 UML: Deployment Diagrams

 8/9/2024

64 UML: Package Diagram

• A package is used as a container to organize the elements present in the system into
a more manageable unit.
• represents the system’s architecture and design as a cohesive unit and a concise
manner.
• We use Package Diagrams to depict how packages and their elements have
been organized.
• A package diagram simply shows us the dependencies between different
packages and internal composition of packages.
 8/9/2024

65 UML: Package Diagram

• Packages help us to organise UML diagrams into meaningful groups and make
the diagram easy to understand.
• They are primarily used to organise class and use case diagrams.
• It is a container for organizing different diagram elements such as classes,
interfaces, etc.
• It is represented in the Diagram in a folder-like icon with its name.
 8/9/2024

66 Package structure and notation

• NameSpace: It represents the package’s name in the diagram. It generally

appears on top of the package symbol which helps to uniquely identify
the package in the diagram.
• Package Merge: It is a relationship that signifies how a package can be
merged or combined. It is represented as a direct arrow between two
packages. Signifying that the contents of one package can be merged with the
contents of the other.
• Package 1 can be merged with Package 2
 8/9/2024

67 Package structure and notation

• Dependency: Dependencies are used to show that there might be some

element or package that can be dependent upon any other element or
package, meaning that changing anything of that package will result in alteration
of the contents of the other package which is dependent upon the first one.
• It is represented as a Dashed Arrow.
 8/9/2024

68 Package structure and notation

• Package Import: It is another relationship that

shows one package’s access to the contents of a
different package.
• The above notation is of the Import, here it also
uses a dashed arrow line but the difference is, the
word <<import>> is being written to represent
the below package or function or element has
been imported from the above package.
 8/9/2024

69 Package structure and notation

• Element: An element can be a single unit inside of a package, it can be a class,

an interface or subsystems. This packages are connected and reside inside of
packages that hold them.
• For example, if we consider a Class, then there can be many functions
inside it and many variables or subclass can also be present, all of these are
considered as an Element of that Class and they are connected with the
Main Class, without the existence of the main class, they will also not exist
or have no relevance.
• Constraint: It is like a condition or requirement set related to a package.
• It is represented by curly braces.
 8/9/2024

70 Use case Diagram

• Use Case Diagrams give a graphic overview of the actors (users or external
systems) involved in a system, different functions needed by those actors and
how these different functions interact.

• It serves as a blueprint for understanding the functional requirements of a

system from a user’s perspective, aiding in the communication between
stakeholders and guiding the development process.
• It provides a high-level view of the system’s functionality by illustrating
the various ways users can interact with it without going into implementation
details.
• Helps to easily identify the main actors involved and the main processes of the
system.
 8/9/2024

71 Use case Diagram

 8/9/2024

72 Use case Diagram notations

• UML notations provide a visual language that enables software developers,

designers, and other stakeholders to communicate and document system
designs, architectures, and behaviors in a consistent and understandable
manner.
 8/9/2024

73 Use case Diagram notations

• Actors are external entities that interact with

the system.
• These can include users, other systems, or hardware
devices.
• In the context of a Use Case Diagram, actors
initiate use cases and receive the outcomes.
• Proper identification and understanding of actors
are crucial for accurately modeling system behavior.
 8/9/2024

74 Use case Diagram notations

• Use Cases
• Use cases are like scenes in the play. They represent
specific things your system can do.
• In the online shopping system, examples of use
cases could be “Place Order,” “Track Delivery,” or
“Update Product Information”.
• Use cases are represented by ovals.
 8/9/2024

75 Use case Diagram notations

• System Boundary
• The system boundary is a visual representation of
the scope or limits of the system you are
modeling.
• It defines what is inside the system and what is
outside.
 8/9/2024

76 Association relationship

• The Association Relationship represents a

communication or interaction between an
actor and a use case.
• It is depicted by a line connecting the actor
to the use case.
• This relationship signifies that the actor is
involved in the functionality described by the
use case.
 8/9/2024

77 Include relationship

• The Include Relationship indicates that a

use case includes the functionality of
another use case.
• It is denoted by a dashed arrow pointing
from the including use case to the included
use case.
• This relationship promotes modular and
reusable design.
 8/9/2024

78 Extend relationship

• The Extend Relationship illustrates that

a use case can be extended by another
use case under specific conditions.
• It is represented by a dashed arrow
with the keyword “extend.”
• This relationship is useful for handling
optional or exceptional behavior.
 8/9/2024

79 Generalization relationship

• The Generalization Relationship

establishes an “is-a” connection between
two use cases, indicating that one use
case is a specialized version of another.
• It is represented by an arrow pointing
from the specialized use case to the
general use case.
 8/9/2024

80 UML: Sequence Diagram

• A sequence diagram simply depicts interaction between objects in a sequential

order i.e. the order in which these interactions take place.
• We can also use the terms event diagrams or event scenarios to refer to
a sequence diagram.
• UML sequence diagrams show how objects interact over time, visualizing the
order of messages exchanged between objects.
• describe how and in what order the objects in a system function.
 8/9/2024

81 UML: Sequence Diagram

• Sequence diagrams in UML show how objects interact with each other and the
order those interactions occur.
• they show the interactions for a particular scenario.
• The processes are represented vertically and interactions are shown as
arrows.
• Actors
• Lifelines • Replay message
• Messages • Found message
• Create message • Lost message
• Delete message • Guards
• Self message
 8/9/2024

82 UML: Sequence Diagram notation

• Actors
• An actor in a UML diagram represents a type of role where it interacts with
the system and its objects.
• an actor is always outside the scope of the system we aim to model using
the UML diagram.
• Is used to depict various roles including human users and other external subjects.
• Represented in a UML diagram using a stick person notation.
• We can have multiple actors in a sequence diagram.
 8/9/2024

83 UML: Sequence Diagram notation

• For example:
• Here the user in seat reservation system is shown as an actor where it exists
outside the system and is not a part of the system.
 8/9/2024

84 Cont’d…

• Lifelines
• A lifeline is a named element which depicts an individual participant in a
sequence diagram.
• So basically each instance in a sequence diagram is represented by a lifeline.
• Lifeline elements are located at the top in a sequence diagram.
• The standard in UML for naming a lifeline follows the following format:
Instance Name : Class Name
• We display a lifeline in a rectangle called head with its name and type.
The head is located on top of a vertical dashed line (referred to as the stem)
as shown below.
 8/9/2024

85 Cont’d…

• If we want to model an unnamed instance, we follow the same pattern except

now the portion of lifeline’s name is left blank.
• Difference between a lifeline and an actor is that a lifeline always portrays an
object internal to the system whereas actors are used to depict objects
external to the system.
 8/9/2024

86 Cont’d…

• Messages
• Communication between objects is depicted using messages.
• messages appear in a sequential order on the lifeline.
• represented using arrows.
• Lifelines and messages form the core of a sequence diagram.
 8/9/2024

87 Cont’d…

• We
 8/9/2024

88 Cont’d…

• Messages can be broadly classified into the following categories:

• Synchronous messages
• A synchronous message waits for a reply before the interaction can move
forward.
• The sender waits until the receiver has completed the processing of the
message.
• The caller continues only when it knows that the receiver has processed
the previous message i.e. it receives a reply message.
• A large number of calls in object oriented programming are synchronous.
 8/9/2024

89 Cont’d…

• We use a solid arrow head to represent a synchronous message.

 8/9/2024

90 Cont’d…

• Asynchronous Messages
• An asynchronous message does not wait for a reply from the receiver.
• The interaction moves forward irrespective of the receiver processing the
previous message or not.
• We use a lined arrow head to represent an asynchronous message.
 8/9/2024

91 Cont’d…

• Create message
• We use a Create message to instantiate a new object in the sequence diagram.
• There are situations when a particular message call requires the creation of an
object.
• It is represented with a dotted arrow and create word labelled on it to
specify that it is the create Message symbol.
 8/9/2024

92 Cont’d…

• For example:
• The creation of a new order on a e-commerce website would require a new
object of Order class to be created.
 8/9/2024

93 Cont’d…

• Delete Message
• We use a Delete Message to delete an object.
• When an object is deallocated memory or is destroyed within the system we
use the Delete Message symbol.
• It destroys the occurrence of the object in the system.
• It is represented by an arrow terminating with a x.
 8/9/2024

94 Cont’d…

• For example:
• In the scenario below when the order is received by the user, the object of
order class can be destroyed.
 8/9/2024

95 Cont’d…

• Self Message
• Certain scenarios might arise where the object needs to send a message to
itself.
• Such messages are called Self Messages and are represented with a U shaped
arrow.
• Example: Consider a scenario where the device wants to access its webcam.
Such a scenario is represented using a self message.
 8/9/2024

96 Cont’d…
 8/9/2024

97 Cont’d…

• Reply Message
• Reply messages are used to show the message being sent from the receiver
to the sender.
• We represent a return/reply message using an open arrow head with a
dotted line.
• The interaction moves forward only when a reply message is sent by the
receiver.
 8/9/2024

98 Cont’d…

• For example:
• Consider the scenario where the device requests a photo from the user.
• Here the message which shows the photo being sent is a reply message.
 8/9/2024

99 Cont’d…

• Found Message
• A Found message is used to represent a scenario where an unknown
source sends the message.
• It is represented using an arrow directed towards a lifeline from an
end point.
 8/9/2024

100 Cont’d…

• For example:
• Consider the scenario of a hardware failure.
• It can be due to multiple reasons and we are not certain as to what caused
the hardware failure.
 8/9/2024

101 Cont’d…

• Lost Message
• A Lost message is used to represent a scenario where the recipient is not
known to the system.
• It is represented using an arrow directed towards an end point from
a lifeline.
• For example:
• Consider a scenario where a warning is generated.
 8/9/2024

102 Cont’d…

• The warning might be generated for the user or other software/object that
the lifeline is interacting with.
• Since the destination is not known before hand, we use the Lost Message
symbol.
 8/9/2024

103 Cont’d…

• Guards
• To model conditions we use guards in UML.
• They are used when we need to restrict the flow of messages on the
pretext of a condition being met.
• Guards play an important role in letting software developers know the
constraints attached to a system or a particular process.
 8/9/2024

104 Cont’d…

• For example:
• In order to be able to withdraw cash, having a balance greater than zero is
a condition that must be met as shown below.
 8/9/2024

105 Cont’d…

• The above sequence diagram depicts the sequence diagram for an emotion
based music player:
• Firstly the application is opened by the user.
• The device then gets access to the web cam.
 8/9/2024

106 Cont’d…

• The webcam captures the image of the user.

• The device uses algorithms to detect the face and predict the mood.
• It then requests database for dictionary of possible moods.
• The mood is retrieved from the database.
• The mood is displayed to the user.
• The music is requested from the database.
• The playlist is generated and finally shown to the user.
 8/9/2024

107 UML: State machine diagram

• State machine diagrams model the behavior of objects as they move through
states in response to events.
• They visualize state transitions, actions, and conditions, providing insights into
how components behave in different scenarios.
 8/9/2024

108 Basic components and notations of state machine

diagram

• Initial state
• We use a black filled circle represent the initial state of a System or a Class.
• Transition
• We use a solid arrow to represent the transition or change of control from
one state to another. The arrow is labelled with the event which causes the
change in state.

• State
• We use a rounded rectangle to represent a state. A state represents the
conditions or circumstances of an object of a class at an instant of time.
 8/9/2024

109 Basic components and notations of state machine

diagram

• Fork
• We use a rounded solid rectangular bar to represent a Fork notation with
incoming arrow from the parent state and outgoing arrows towards the newly
created states. We use the fork notation to represent a state splitting into two
or more concurrent states.
• Join
• We use a rounded solid rectangular bar to represent a Join notation with
incoming arrows from the joining states and outgoing arrow towards the
common goal state. We use the join notation when two or more states
concurrently converge into one on the occurrence of an event or events.
 8/9/2024

110 Basic components and notations of state machine

diagram

• Self transition
• We use a solid arrow pointing back to the state itself to represent a self
transition.
• There might be scenarios when the state of the object does not change upon
the occurrence of an event. We use self transitions to represent such cases.
 8/9/2024

111 Basic components and notations of state machine

diagram

• Composite state
• We use a rounded rectangle to represent a composite state also. We represent
a state with internal activities using a composite state.

• Final State
• We use a filled circle within a circle notation to represent the final state in a
state machine diagram.
 8/9/2024

112 UML: Activity Diagram

• Activity Diagrams are used to illustrate the flow of control in a system and
refer to the steps involved in the execution of a use case.
• We can depict both sequential processing and concurrent processing of
activities using an activity diagram.
• i.e. an activity diagram focuses on the condition of flow and the sequence
in which it happens.
• We describe what causes a particular event using an activity diagram.
 8/9/2024

113 UML: Activity Diagram notations

• An activity diagram portrays the control flow from a start point to a finish
point showing the various decision paths that exist while the activity is being
executed.
 8/9/2024

114 UML: Activity Diagram notations

• Initial State
• The starting state before an activity takes place is depicted using the initial
state.
• A process can have only one initial state unless we are depicting nested
activities. We use a black filled circle to depict the initial state of a system. For
objects, this is the state when they are instantiated.
• The Initial State from the UML Activity Diagram marks the entry point and the
initial Activity State.
• For example: Here the initial state of the system
before the application is opened.
 8/9/2024

115 UML: Activity Diagram notations

• Action or Activity State

• An activity represents execution of an action on objects or by objects.
• We represent an activity using a rectangle with rounded corners.
• Basically any action or event that takes place is represented using an activity.
 8/9/2024

116 UML: Activity Diagram notations

• Action Flow or Control flows

• Action flows or Control flows are also referred to as paths and edges. They
are used to show the transition from one activity state to another activity
state.
• An activity state can have multiple incoming and outgoing action flows. We use
a line with an arrow head to depict a Control Flow. If there is a constraint to
be adhered to while making the transition it is mentioned on the arrow.
 8/9/2024

117 UML: Activity Diagram notations

• For example:
• Here both the states transit into one final state using action flow symbols i.e.
arrows.
 8/9/2024

118 UML: Activity Diagram notations

• Decision node and Branching

• When we need to make a decision before deciding the flow of control, we use
the decision node.
• The outgoing arrows from the decision node can be labelled with conditions
or guard expressions.
• It always includes two or more output arrows.
 8/9/2024

119 UML: Activity Diagram notations

• For example:
• We apply the conditions on input number to display the result :
• If number is odd then display the number.
• If number if even then display the error.
 8/9/2024

120 UML: Activity Diagram notations

• Guard
• A Guard refers to a statement written next to a decision node on an arrow
sometimes within square brackets.
• The statement must be true for the control to shift along a particular
direction.
• Guards help us know the constraints and conditions which determine the flow
of a process.
 8/9/2024

121 Cont’d…

• Fork
• Fork nodes are used to support concurrent activities. When we use a fork
node when both the activities get executed concurrently i.e. no decision is
made before splitting the activity into two parts.
• Both parts need to be executed in case of a fork statement.
• We use a rounded solid rectangular bar to represent a Fork notation with
incoming arrow from the parent activity state and outgoing arrows towards
the newly created activities.
 8/9/2024

122 Cont’d…

• For example:
• In the example below, the activity of making coffee can be split into two
concurrent activities and hence we use the fork notation.
 8/9/2024

123 Cont’d…

• Join
• Join nodes are used to support concurrent
activities converging into one.
• For join notations we have two or more
incoming edges and one outgoing edge.
• For example:
• When both activities i.e. steaming the milk
and adding coffee get completed, we
converge them into one final activity.
 8/9/2024

124 Cont’d…

• Merge or Merge Event

• Scenarios arise when activities which are not being executed concurrently have
to be merged.
• We use the merge notation for such scenarios.
• We can merge two or more activities into one if the control proceeds onto
the next activity irrespective of the path chosen.
• For example:
• In the diagram below: we can’t have both sides executing concurrently, but they finally merge
into one. A number can’t be both odd and even at the same time.
 8/9/2024

125 Cont’d…

• For example:
• In the diagram below: we can’t have both sides executing concurrently, but they
finally merge into one. A number can’t be both odd and even at the same time.
 8/9/2024

126 Cont’d…

• Time Event
• This refers to an event that stops the flow for a
time; an hourglass depicts it. We can have a
scenario where an event takes some time to
completed.
• For example:
• Let us assume that the processing of an image
takes a lot of time. Then it can be represented as
shown below.
 8/9/2024

127 Cont’d…

• Final State or End State

• The state which the system reaches when a particular process or activity ends
is known as a Final State or End State.
• We use a filled circle within a circle notation to represent the final state in a
state machine diagram.
• A system or a process can have multiple final states.
 8/9/2024

128

Thank You!