Unit 1

Object Orientation

Object Orientation is a programming paradigm that revolves around the concept of objects and
classes. It is a way of designing and organizing code that models real-world objects and systems.
The core idea is to create objects that have properties and behaviors, which can interact with each
other to achieve a specific goal.

Object Identity

Object Identity refers to the unique existence of an object in a system. Each object has its own set
of attributes (data) and methods (functions) that define its behavior. Object identity is essential in
object-oriented programming as it allows objects to be distinguished from one another.

Encapsulation

Encapsulation is the concept of bundling data and methods that operate on that data within a single
unit, called a class. This helps to hide the implementation details of an object from the outside
world, making it harder for other objects to access or modify its internal state directly.
Encapsulation promotes data hiding and abstraction.

Information Hiding

Information Hiding is a fundamental principle of object-oriented programming. It means that an

object's internal implementation details are hidden from the outside world, and only the necessary
information is exposed through a public interface. This helps to reduce coupling between objects
and makes the system more modular and flexible.

Polymorphism

Polymorphism is the ability of an object to take on multiple forms. This can be achieved through
method overriding or method overloading. Polymorphism allows objects of different classes to be
treated as objects of a common superclass, making it possible to write more generic and flexible
code.

Importance of Modelling
Modelling is an essential step in software development as it helps to create a conceptual
representation of the system being designed. Modelling allows developers to identify the key
components, relationships, and behaviors of the system, making it easier to design and implement
the system.

Principles of Modelling

Some key principles of modelling include:

o Abstraction: Focusing on essential features and ignoring irrelevant details.

o Simplification: Breaking down complex systems into smaller, more manageable parts.
o Accuracy: Ensuring that the model accurately represents the real-world system.
o Reusability: Creating models that can be reused in different contexts.

Object-Oriented Modelling

Object-Oriented Modelling is a technique used to create models of systems using object-oriented

concepts such as classes, objects, inheritance, and polymorphism. This approach helps to create
models that are more intuitive, flexible, and scalable.

Introduction to UML

UML (Unified Modelling Language) is a standardized language used for creating models of
systems. It provides a set of graphical notations and rules for creating diagrams that represent the
structure and behavior of systems.

Conceptual Model of the UML

The conceptual model of UML consists of three main components:

Structural Elements: Classes, objects, attributes, and relationships.

Behavioral Elements: Methods, operations, and interactions.

Model Management: Packages, models, and diagrams.

Architecture

Architecture refers to the high-level design of a system, including the components, relationships,
and interactions between them. In object-oriented system design, architecture is critical in defining
the overall structure and organization of the system.

What is Object-Oriented Design (OOD)?

Object-Oriented Design (OOD) is a programming approach that involves planning a system of
interacting objects for the purpose of solving a software problem. It leverages the concepts of
objects and classes, encapsulation, inheritance, and polymorphism to model real-world entities and
their interactions. OOD is used to create a system architecture that is modular, flexible, and easy to
understand and maintain.

Importance of Object-Oriented Design (OOD) in System Design

Object-Oriented Design (OOD) is crucial in system design due to several key reasons:

o Modularity: OOD breaks down complex systems into manageable, self-contained objects,
making development and maintenance more straightforward.
o Reusability: Objects and classes can be reused across different projects, reducing
redundancy and saving time.
o Scalability: OOD supports system expansion by allowing new objects to be easily
integrated without disrupting existing functionality.
o Maintainability: Encapsulation of data and behavior within objects simplifies
troubleshooting and updates, enhancing system reliability.
o Clear Mapping to Real-World Problems: By modeling software after real-world entities and
their interactions, OOD makes systems more intuitive and easier to conceptualize.
o Flexibility and Extensibility: Through inheritance and polymorphism, OOD allows for
extending and adapting systems with minimal changes, accommodating future requirements
efficiently.

Key Principles of OOD

Object-Oriented Design (OOD) is governed by several key principles that help create robust,
maintainable, and scalable systems:

o Encapsulation: Bundling data with methods that operate on the data, restricting direct
access to some components and protecting object integrity.
o Abstraction: Simplifying complex systems by modeling classes appropriate to the
problem domain, highlighting essential features while hiding unnecessary details.
o Inheritance: Establishing a hierarchy between classes, allowing derived classes to
inherit properties and behaviors from base classes, promoting code reuse and extension.
o Polymorphism: Enabling objects to be treated as instances of their parent class, allowing
one interface to be used for a general class of actions, improving flexibility and
integration.
o Composition: Building complex objects by combining simpler ones, promoting reuse
and flexible designs.
o SOLID Principles:
o Single Responsibility Principle (SRP): A class should have one, and only one, reason to
change.
o Open/Closed Principle (OCP): Classes should be open for extension but closed for
modification.
 o Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types
without altering the correctness of the program.
o Interface Segregation Principle (ISP): Clients should not be forced to depend on
interfaces they do not use.
o Dependency Inversion Principle (DIP): High-level modules should not depend on low-
level modules. Both should depend on abstractions.

Object-Oriented Design Concepts

Object-Oriented Design (OOD) involves several core concepts that facilitate the creation of robust,
scalable, and maintainable software.

1. Encapsulation

Encapsulation is the bundling of data (attributes) and methods (functions) that operate on the data
into a single unit called a class. It restricts direct access to some of the object’s components, which
is a means of preventing accidental interference and misuse of the data.

2. Abstraction

Abstraction involves hiding the complex implementation details and showing only the essential
features of the object. This helps in managing complexity by allowing the designer to focus on the
interactions at a higher level.

3. Inheritance

Inheritance is a mechanism where a new class inherits properties and behaviors (methods) from an
existing class. This promotes code reuse and establishes a natural hierarchy between classes.
4. Polymorphism

Polymorphism allows objects of different classes to be treated as objects of a common super class.
It enables a single interface to represent different underlying data types and allows m5.

5. Composition

Composition is a design principle where a class is composed of one or more objects of other
classes, rather than inheriting from them. This promotes flexibility and reusability.ethods to use
objects of various types.

Important Questions

Q 1. How does Object-Oriented Design (OOD) differ from Object-Oriented Programming (OOP)?

OOD is the process of planning and designing a system of interacting objects to solve a software
problem. It focuses on defining the structure and behavior of objects and their interactions. OOP,
on the other hand, is the implementation of the design using an object-oriented programming
language (such as C++, Java, or Python). While OOD deals with the design phase of software
development, OOP deals with the coding and implementation phase.

Q 2. How can Object-Oriented Design (OOD) improve software maintainability?

OOD improves software maintainability through:

Modularity: By dividing the system into discrete classes, each responsible for specific
functionality, it becomes easier to understand, modify, and extend the system.

Encapsulation: By restricting access to the internal state of objects and exposing only necessary
interfaces, it reduces the risk of unintended interference and makes the system more robust.

Reuse: Inheritance and polymorphism promote code reuse, reducing redundancy and making it
easier to update and maintain the system.

Clear Design: Abstraction allows designers to focus on high-level design, making the system easier
to understand and reason about.

Q 3. What is the role of UML in Object-Oriented Design?

Unified Modeling Language (UML) plays a critical role in Object-Oriented Design by providing a
standardized way to visualize the design of a system. UML includes various types of diagrams,
each serving different purposes

Q 4. How do you handle design changes in an Object-Oriented Design?

Handling design changes in an Object-Oriented Design involves several best practices to ensure the
system remains flexible and maintainable:

o Refactoring: Regularly refactor the code to improve its structure without changing its
external behavior. This helps in accommodating new requirements and improving code
quality.
o Version Control: Use version control systems to manage changes in the codebase. This
allows tracking of changes, collaboration among team members, and reverting to previous
versions if needed.
o Design Patterns: Apply appropriate design patterns that provide tested solutions for
common design problems and enhance the flexibility of the system.

Q5. What is UML?

Unified Modeling Language (UML) is a standardized visual modeling language used in the field of
software engineering to provide a general-purpose, developmental, and intuitive way to visualize
the design of a system. UML helps in specifying, visualizing, constructing, and documenting the
artifacts of software systems.

We use UML diagrams to portray the behavior and structure of a system.

UML helps software engineers, businessmen, and system architects with modeling, design, and
analysis.

The Object Management Group (OMG) adopted Unified Modelling Language as a standard in
1997. It’s been managed by OMG ever since.

The International Organization for Standardization (ISO) published UML as an approved standard
in 2005. UML has been revised over the years and is reviewed periodically.

Q 6. Why do we need UML?

Complex applications need collaboration and planning from multiple teams and hence require a
clear and concise way to communicate amongst them.

Businessmen do not understand code. So UML becomes essential to communicate with non-
programmers about essential requirements, functionalities, and processes of the system.

A lot of time is saved down the line when teams can visualize processes, user interactions, and the
static structure of the system.

Different Types of UML Diagrams

UML is linked with object-oriented design and analysis. UML makes use of elements and forms
associations between them to form diagrams. Diagrams in UML can be broadly classified as:

Structural Diagrams

Structural UML diagrams illustrate the organization of a system by depicting its components, such
as classes, objects, and packages. They represent the elements that make up the system and the
relationships between them.

Types of Structural UML diagrams

1. Class Diagram
Class diagrams are the main building blocks of every object-oriented method.

The class diagram can be used to show the classes, relationships, interface, association, and
collaboration. UML is standardized in class diagrams.

Since classes are the building block of an application that is based on OOPs, the class diagram has
an appropriate structure to represent the classes, inheritance, relationships, and everything that
OOPs have in their context.

UML Class Notation

class notation is a graphical representation used to depict classes and their relationships in object-
oriented modeling.

Class Name:

The name of the class is typically written in the top compartment of the class box and is centered
and bold.

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.

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.

Visibility Notation:

Visibility notations indicate the access level of attributes and methods. Common visibility notations
include:
+ for public (visible to all classes)

- for private (visible only within the class)

# for protected (visible to subclasses)

~ for package or default visibility (visible to classes in the same package)

2. Package Diagram

A package diagram is a type of Unified Modeling Language (UML) diagram mainly used to
represent the organization and the structure of a system in the form of packages.

A package is used as a container to organize the elements present in the system into a more
manageable unit.

It is very useful to represent the system’s architecture and design as a cohesive unit and concise
manner.

3. 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 behavior of the system at a particular instant.

Object diagrams are vital to portray and understand functional requirements of a system. In other
words, “An object diagram in the Unified Modeling Language (UML), is a diagram that shows a
complete or partial view of the structure of a modelled system at a specific time.

4. 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.

5. Composite structure diagram

A composite structure diagram represents relationship between parts and their configuration which
determine how the classifier (class, a component, or a deployment node) behaves.

They represent internal structure of a structured classifier making the use of parts, ports, and
connectors.

They are similar to class diagrams except they represent individual parts in detail as compared to
the entire class.

6. Deployment diagram

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.

They are primarily used when a software is being used, distributed or deployed over multiple
machines with different configurations.

. Behavioral UML Diagrams

1. State Machine Diagrams

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.

2. Activity Diagrams

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.

3. Use Case Diagrams

Use Case Diagrams are used to depict the functionality of a system or a part of a system. They are
widely used to illustrate the functional requirements of the system and its interaction with external
agents(actors).

A use case is basically a diagram representing different scenarios where the system can be used.

A use case diagram gives us a high level view of what the system or a part of the system does
without going into implementation details.

4. 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.

Sequence diagrams describe how and in what order the objects in a system function.

These diagrams are widely used by businessmen and software developers to document and
understand requirements for new and existing systems.

5. Communication Diagram

A Communication Diagram (known as Collaboration Diagram in UML 1.x) is used to show

sequenced messages exchanged between objects.

A communication diagram focuses primarily on objects and their relationships.

We can represent similar information using Sequence diagrams, however communication diagrams
represent objects and links in a free form.

6. Timing Diagram

Timing Diagram are a special form of Sequence diagrams which are used to depict the behavior of
objects over a time frame. We use them to show time and duration constraints which govern
changes in states and behavior of objects.
 Unit 2
I. BASIC STRUCTURAL MODELING
1. Classes:

Terms and Concepts:

A class is a description of a set of objects that share the same attributes, operations, relationships,
and semantics. Graphically, a class is rendered as a rectangle.

Names

Every class must have a name that distinguishes it from other classes. A name is a textual string.
That name alone is known as a simple name; a qualified name is the class name prefixed by the
name of the package in which that class lives. A class may be drawn showing only its name

Attributes

An attribute is a named property of a class that describes a range of values that instances of the
property may hold. A class may have any number of attributes or no attributes at all. An attribute
represents some property of the thing you are modeling that is shared by all objects of that class.
For example, every wall has a height, width, and thickness; you might model your customers in
such a way that each has a name, address, phone number, and date of birth
Operations

An operation is the implementation of a service that can be requested from any object of the
class to affect behavior. In other words, an operation is an abstraction of something you can do to
an object that is shared by all objects of that class. A class may have any number of operations or
no operations at all. For example, in a windowing library such as the one found in Java's awt
package, all objects of the class Rectangle can be moved, resized, or queried for their properties.
Often (but not always), invoking an operation on an object changes the object's data or state.
Graphically, operations are listed in a compartment just below the class attributes. Operations
may be drawn showing only their names

You can specify an operation by stating its signature, which includes the name, type, and default
value of all parameters and (in the case of functions) a return type

Organizing Attributes and Operations

When drawing a class, you don't have to show every attribute and every operation at once. In
fact, in most cases, you can't (there are too many of them to put in one figure) and you probably
shouldn't (only a subset of these attributes and operations are likely to be relevant to a specific
view). For these reasons, you can elide a class, meaning that you can choose to show only some
or none of a class's attributes and operations. You can indicate that there are more attributes or
properties than shown by ending each list with an ellipsis ("...").

Responsibilities

A responsibility is a contract or an obligation of a class. When you create a class, you are making
a statement that all objects of that class have the same kind of state and the same kind of
behavior. At a more abstract level, these corresponding attributes and operations are just the
features by which the class's responsibilities are carried out. A Wall class is responsible for
knowing about height, width, and thickness; a FraudAgent class, as you might find in a credit
card application, is responsible for processing orders and determining if they are legitimate,
suspect, or fraudulent; a TemperatureSensor class is responsible for measuring temperature and
raising an alarm if the temperature reaches a certain point.

Common Modeling Techniques

Modeling the Vocabulary of a System

You'll use classes most commonly to model abstractions that are drawn from the problem you
are trying to solve or from the technology you are using to implement a solution to that problem.
Each of these abstractions is a part of the vocabulary of your system, meaning that, together, they
represent the things that are important to users and to implementers.
To model the vocabulary of a system,

Identify those things that users or implementers use to describe the problem or solution.
Use CRC cards and use case-based analysis to help find these abstractions.
For each abstraction, identify a set of responsibilities. Make sure that each class is crisply
defined and that there is a good balance of responsibilities among all your classes.
Provide the attributes and operations that are needed to carry out these responsibilities for
each class.

A set of classes drawn from a retail system, including Customer, Order, and Product. This figure
includes a few other related abstractions drawn from the vocabulary of the problem, such as
Shipment (used to track orders), Invoice (used to bill orders), and Warehouse (where products
are located prior to shipment). There is also one solution-related abstraction, TRansaction, which
applies to orders and shipments.

Modeling the Distribution of Responsibilities in a System

Once you start modeling more than just a handful of classes, you will want to be sure that your
abstractions provide a balanced set of responsibilities.

To model the distribution of responsibilities in a system,

Identify a set of classes that work together closely to carry out some behavior.
Identify a set of responsibilities for each of these classes.
Look at this set of classes as a whole, split classes that have too many responsibilities into
smaller abstractions, collapse tiny classes that have trivial responsibilities into larger
ones, and reallocate responsibilities so that each abstraction reasonably stands on its own.
 Consider the ways in which those classes collaborate with one another, and redistribute
their responsibilities accordingly so that no class within a collaboration does too much or
too little.

Modeling Nonsoftware Things

To model nonsoftware things,

Model the thing you are abstracting as a class.

If you want to distinguish these things from the UML's defined building blocks, create a
new building block by using stereotypes to specify these new semantics and to give a
distinctive visual cue.
If the thing you are modeling is some kind of hardware that itself contains software,
consider modeling it as a kind of node as well, so that you can further expand on its
structure.

Modeling Primitive Types

To model primitive types,

 Model the thing you are abstracting as a class or an enumeration, which is rendered using
class notation with the appropriate stereotype.
If you need to specify the range of values associated with this type, use constraints.

2.Relationships:

Terms and Concepts

A relationship is a connection among things. In object-oriented modeling, the three most

important relationships are dependencies, generalizations, and associations. Graphically, a
relationship is rendered as a path, with different kinds of lines used to distinguish the kinds of
relationships.

Dependencies

A dependency is a relationship that states that one thing (for example, class Window) uses the
information and services of another thing (for example, class Event), but not necessarily the
reverse. Graphically, a dependency is rendered as a dashed directed line, directed to the thing
being depended on. Choose dependencies when you want to show one thing using another.
Generalizations

A generalization is a relationship between a general kind of thing (called the superclass or

parent) and a more specific kind of thing (called the subclass or child). Generalization is
sometimes called an "is-a-kind-of" relationship: one thing (like the class BayWindow) is-a-kind-
of a more general thing (for example, the class Window). An objects of the child class may be
used for a variable or parameter typed by the parent, but not the reverse

Associations

An association is a structural relationship that specifies that objects of one thing are connected to
objects of another. Given an association connecting two classes, you can relate objects of one
class to objects of the other class. It's quite legal to have both ends of an association circle back
to the same class. This means that, given an object of the class, you can link to other objects of
the same class. An association that connects exactly two classes is called a binary association.
Although it's not as common, you can have associations that connect more than two classes;
these are called n-ary associations.

Beyond this basic form, there are four adornments that apply to associations.

Name

An association can have a name, and you use that name to describe the nature of the relationship.
So that there is no ambiguity about its meaning, you can give a direction to the name by
providing a direction triangle that points in the direction you intend to read the name.
Role

When a class participates in an association, it has a specific role that it plays in that relationship;
a role is just the face the class at the far end of the association presents to the class at the near end
of the association. You can explicitly name the role a class plays in an association. The role
played by an end of an association is called an end name (in UML1, it was called a role name).
the class Person playing the role of employee is associated with the class Company playing the
role of employer.

Multiplicity

An association represents a structural relationship among objects. In many modeling situations,

it's important for you to state how many objects may be connected across an instance of an
association. This "how many" is called the multiplicity of an association's role. It represents a
range of integers specifying the possible size of the set of related objects.

The number of objects must be in the given range. You can show a multiplicity of exactly one
(1), zero or one (0..1), many (0..*), or one or more (1..*). You can give an integer range (such as
2..5). You can even state an exact number (for example, 3, which is equivalent to 3..3).
Aggregation

A plain association between two classes represents a structural relationship between peers,
meaning that both classes are conceptually at the same level, no one more important than the
other. Sometimes you will want to model a "whole/part" relationship, in which one class
represents a larger thing (the "whole"), which consists of smaller things (the "parts"). This kind
of relationship is called aggregation, which represents a "has-a" relationship

Common Modeling Techniques

Modeling Simple Dependencies

A common kind of dependency relationship is the connection between a class that uses another
class as a parameter to an operation.

To model this using relationship,

Create a dependency pointing from the class with the operation to the class used as a
parameter in the operation.

a set of classes drawn from a system that manages the assignment of students and instructors to
courses in a university. This figure shows a dependency from CourseSchedule to Course,
because Course is used in both the add and remove operations of CourseSchedule.
Modeling Single Inheritance

In modeling the vocabulary of your system, you will often run across classes that are structurally
or behaviorally similar to others. You could model each of these as distinct and unrelated
abstractions. A better way would be to extract any common structural and behavioral features
and place them in more-general classes from which the specialized ones inherit.

To model inheritance relationships,

Given a set of classes, look for responsibilities, attributes, and operations that are
common to two or more classes.
Elevate these common responsibilities, attributes, and operations to a more general class.
If necessary, create a new class to which you can assign these elements (but be careful
about introducing too many levels).
Specify that the more-specific classes inherit from the more-general class by placing a
generalization relationship that is drawn from each specialized class to its more-general
parent.

Modeling Structural Relationships

When you model with dependencies or generalization relationships, you may be modeling
classes that represent different levels of importance or different levels of abstraction. Given a
dependency between two classes, one class depends on another but the other class has no
knowledge of the one.

To model structural relationships,

For each pair of classes, if you need to navigate from objects of one to objects of another,
specify an association between the two. This is a data-driven view of associations.
For each pair of classes, if objects of one class need to interact with objects of the other
class other than as local variables in a procedure or parameters to an operation, specify an
association between the two. This is more of a behavior-driven view of associations.
 For each of these associations, specify a multiplicity (especially when the multiplicity is
not *, which is the default), as well as role names (especially if they help to explain the
model).
If one of the classes in an association is structurally or organizationally a whole compared
with the classes at the other end that look like parts, mark this as an aggregation by
adorning the association at the end near the whole with a diamond.

3.Common Mechanisms:

Terms and Concepts

A note is a graphical symbol for rendering constraints or 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.

A stereotype is an extension of the vocabulary of the UML, allowing you to create new kinds of
building blocks similar to existing ones but specific to your problem. Graphically, a stereotype is
rendered as a name enclosed by guillemets (French quotation marks of the form « »), placed
above the name of another element.

Optionally the stereotyped element may be rendered by using a new icon associated with that
stereotype.

A tagged value is a property of a stereotype, allowing you to create new information in an

element bearing that stereotype. Graphically, a tagged value is rendered as a string of the form
name = value within a note attached to the object.

A constraint is a textual specification of the semantics of a UML element, allowing you to add
new rules or to modify existing ones. Graphically, a constraint is rendered as a string enclosed by
brackets and placed near the associated element or connected to that element or elements by
dependency relationships. As an alternative, you can render a constraint in a note.
 UML Collaboration Diagram
The collaboration diagram is used to show the relationship between the objects in a system. Both
the sequence and the collaboration diagrams represent the same information but differently.
Instead of showing the flow of messages, it depicts the architecture of the object residing in the
system as it is based on object-oriented programming. An object consists of several features.
Multiple objects present in the system are connected to each other. The collaboration diagram,
which is also known as a communication diagram, is used to portray the object's architecture in
the system.

Notations of a Collaboration Diagram

Following are the components of a component diagram that are enlisted below:

1. Objects: The representation of an object is done by an object symbol with its name and
class underlined, separated by a colon.

In the collaboration diagram, objects are utilized in the following ways:

o The object is represented by specifying their name and class.

o It is not mandatory for every class to appear.
o A class may constitute more than one object.
o In the collaboration diagram, firstly, the object is created, and then its class is
specified.
o To differentiate one object from another object, it is necessary to name them.
2. Actors: In the collaboration diagram, the actor plays the main role as it invokes the
interaction. Each actor has its respective role and name. In this, one actor initiates the use
case.
3. Links: The link is an instance of association, which associates the objects and actors. It
portrays a relationship between the objects through which the messages are sent. It is
represented by a solid line. The link helps an object to connect with or navigate to another
object, such that the message flows are attached to links.
4. Messages: It is a communication between objects which carries information and includes
a sequence number, so that the activity may take place. It is represented by a labeled
arrow, which is placed near a link. The messages are sent from the sender to the receiver,
and the direction must be navigable in that particular direction. The receiver must
understand the message.
When to use a Collaboration Diagram?
The collaborations are used when it is essential to depict the relationship between the object. Both
the sequence and collaboration diagrams represent the same information, but the way of
portraying it quite different. The collaboration diagrams are best suited for analyzing use cases.

1. To model collaboration among the objects or roles that carry the functionalities of use
cases and operations.
2. To model the mechanism inside the architectural design of the system.
3. To capture the interactions that represent the flow of messages between the objects and
the roles inside the collaboration.
4. To model different scenarios within the use case or operation, involving a collaboration of
several objects and interactions.
5. To support the identification of objects participating in the use case.
6. In the collaboration diagram, each message constitutes a sequence number, such that the
top-level message is marked as one and so on. The messages sent during the same call are
denoted with the same decimal prefix, but with different suffixes of 1, 2, etc. as per their
occurrence.

Steps for creating a Collaboration Diagram

1. Determine the behavior for which the realization and implementation are specified.
2. Discover the structural elements that are class roles, objects, and subsystems for
performing the functionality of collaboration.
o Choose the context of an interaction: system, subsystem, use case, and operation.
3. Think through alternative situations that may be involved.
o Implementation of a collaboration diagram at an instance level, if needed.
o A specification level diagram may be made in the instance level sequence diagram for
summarizing alternative situations.
Benefits of a Collaboration Diagram

1. The collaboration diagram is also known as Communication Diagram.

2. It mainly puts emphasis on the structural aspect of an interaction diagram, i.e., how
lifelines are connected.
3. The syntax of a collaboration diagram is similar to the sequence diagram; just the
difference is that the lifeline does not consist of tails.
4. The messages transmitted over sequencing is represented by numbering each individual
message.
5. The collaboration diagram is semantically weak in comparison to the sequence diagram.
6. The special case of a collaboration diagram is the object diagram.
7. It focuses on the elements and not the message flow, like sequence diagrams.
8. Since the collaboration diagrams are not that expensive, the sequence diagram can be
directly converted to the collaboration diagram.
9. There may be a chance of losing some amount of information while implementing a
collaboration diagram with respect to the sequence diagram.

The drawback of a Collaboration Diagram

1. Multiple objects residing in the system can make a complex collaboration diagram, as it
becomes quite hard to explore the objects.
2. It is a time-consuming diagram.
3. After the program terminates, the object is destroyed.
4. As the object state changes momentarily, it becomes difficult to keep an eye on every
single that has occurred inside the object of a system.

Sequence Diagram
The sequence diagram represents the flow of messages in the system and is also termed as an
event diagram. It helps in envisioning several dynamic scenarios. It portrays the communication
between any two lifelines as a time-ordered sequence of events, such that these lifelines took part
at the run time. In UML, the lifeline is represented by a vertical bar, whereas the message flow is
represented by a vertical dotted line that extends across the bottom of the page. It incorporates the
iterations as well as branching.

Purpose of a Sequence Diagram

1. To model high-level interaction among active objects within a system.

2. To model interaction among objects inside a collaboration realizing a use case.
3. It either models generic interactions or some certain instances of interaction.

Notations of a Sequence Diagram

Lifeline
An individual participant in the sequence diagram is represented by a lifeline. It is positioned at
the top of the diagram.
Actor
A role played by an entity that interacts with the subject is called as an actor. It is out of the scope
of the system. It represents the role, which involves human users and external hardware or
subjects. An actor may or may not represent a physical entity, but it purely depicts the role of an
entity. Several distinct roles can be played by an actor or vice versa.
Activation
It is represented by a thin rectangle on the lifeline. It describes that time period in which an
operation is performed by an element, such that the top and the bottom of the rectangle is
associated with the initiation and the completion time, each respectively.

Messages
The messages depict the interaction between the objects and are represented by arrows. They are
in the sequential order on the lifeline. The core of the sequence diagram is formed by messages
and lifelines.

Following are types of messages enlisted below:

o Call Message: It defines a particular communication between the lifelines of an interaction,

which represents that the target lifeline has invoked an operation.
o Return Message: It defines a particular communication between the lifelines of interaction
that represent the flow of information from the receiver of the corresponding caller message.

o Self Message: It describes a communication, particularly between the lifelines of an

interaction that represents a message of the same lifeline, has been invoked.

o Recursive Message: A self message sent for recursive purpose is called a recursive message.
In other words, it can be said that the recursive message is a special case of the self message
as it represents the recursive calls.
 o Create Message: It describes a communication, particularly between the lifelines of an
interaction describing that the target (lifeline) has been instantiated.

o Destroy Message: It describes a communication, particularly between the lifelines of an

interaction that depicts a request to destroy the lifecycle of the target.

o Duration Message: It describes a communication particularly between the lifelines of an

interaction, which portrays the time passage of the message while modeling a system.

Note
A note is the capability of attaching several remarks to the element. It basically carries useful
information for the modelers.
Sequence Fragments

1. Sequence fragments have been introduced by UML 2.0, which makes it quite easy for the
creation and maintenance of an accurate sequence diagram.
2. It is represented by a box called a combined fragment, encloses a part of interaction inside
a sequence diagram.
3. The type of fragment is shown by a fragment operator.

Example of a Sequence Diagram

An example of a high-level sequence diagram for online bookshop is given below.

Any online customer can search for a book catalog, view a description of a particular book, add a
book to its shopping cart, and do checkout.
Benefits of a Sequence Diagram

1. It explores the real-time application.

2. It depicts the message flow between the different objects.
3. It has easy maintenance.
4. It is easy to generate.
5. Implement both forward and reverse engineering.
6. It can easily update as per the new change in the system.

The drawback of a Sequence Diagram

1. In the case of too many lifelines, the sequence diagram can get more complex.
2. The incorrect result may be produced, if the order of the flow of messages changes.
3. Since each sequence needs distinct notations for its representation, it may make the
diagram more complex.
4. The type of sequence is decided by the type of message.
Asynchronous Messages in Sequence Diagrams

In sequence diagrams, asynchronous messages are represented by a dashed arrow with an open
arrowhead. Here's a breakdown of the different types of asynchronous messages:

Asynchronous Messages without Priority

Represented by a dashed arrow with an open arrowhead.

Indicates that the sender does not wait for a response from the receiver.
The receiver processes the message at its own pace.

sequenceDiagram
participant A as "Sender"
participant B as "Receiver"
A->>B: Asynchronous Message

Asynchronous Messages with Priority

Represented by a dashed arrow with an open arrowhead and a priority indicator (e.g.,
high, low, medium).
Indicates that the sender does not wait for a response from the receiver, but the message
has a specific priority.
The receiver processes the message based on its priority.

sequenceDiagram
participant A as "Sender"
participant B as "Receiver"
A->>B: High Priority Asynchronous Message

Call-Back Mechanism

Represented by a dashed arrow with an open arrowhead and a return arrow.

Indicates that the sender expects a response from the receiver at a later time.
The receiver processes the message and sends a response back to the sender.
sequenceDiagram
participant A as "Sender"
participant B as "Receiver"
A->>B: Asynchronous Message with Call-Back
B->>A: Response

Broadcast Messages

Represented by a dashed arrow with an open arrowhead and a broadcast indicator (e.g.,
broadcast, multicast).
Indicates that the sender sends the message to multiple receivers.
Each receiver processes the message independently.

sequenceDiagram
participant A as "Sender"
participant B as "Receiver 1"
participant C as "Receiver 2"
 A->>B: Broadcast Asynchronous Message
A->>C: Broadcast Asynchronous Message

Sequence diagram that depicts all the above scenarios:

sequenceDiagram

participant A as "Sender"

participant B as "Receiver 1"

participant C as "Receiver 2"

participant D as "Receiver 3"

A->>B: Asynchronous Message

A->>C: High Priority Asynchronous Message

A->>D: Asynchronous Message with Call-Back

D->>A: Response

A->>B: Broadcast Asynchronous Message

A->>C: Broadcast Asynchronous Message

A->>D: Broadcast Asynchronous Message