Name: Syed Sarfaraz Haider

Class & Section: MCA-A

Roll No.: RA2332241030002
OOAD Assignment-3
Q1. What are the Dynamic diagrams? How is it different from the static diagram?
Ans.
Dynamic Diagrams:
Dynamic diagrams in UML (Unified Modeling Language) are used to represent the behavior of a system
over time. They focus on the flow of control, the interactions between objects, and how the system
responds to external stimuli or events. The main types of dynamic diagrams include:

1. Sequence Diagrams: These show the order in which messages are passed between objects,
emphasizing the time sequence of interactions.
2. Activity Diagrams: They depict the flow of activities or actions within a system, focusing on the
workflow and parallel processes.
3. State Machine Diagrams: These diagrams capture the different states an object can be in and the
transitions between those states based on certain events.
4. Collaboration (Communication) Diagrams : They represent how objects interact based on a
specific scenario, emphasizing object organization and message flow.

Dynamic diagrams emphasize how a system behaves or responds during execution. They are crucial for
capturing the interaction patterns and the operational workflow.

Difference between Dynamic and Static Diagrams:

While dynamic diagrams focus on the system’s behavior, static diagrams emphasize the system’s
structure. Key differences are:

1. Focus :
- Static diagrams (e.g., class diagrams, object diagrams) capture the structural components of a
system, such as classes, attributes, and relationships, giving a snapshot of the system at a specific time.
- Dynamic diagrams show how these structural elements interact and evolve during the runtime of
the system.

2. Timing :
- Static diagrams represent the design of the system at any given point, showing how the system is
structured.
- Dynamic diagrams highlight the changes and processes that occur over time, emphasizing behavior
and control flow.

3. Purpose :
- Static diagrams are used to represent how data is organized within a system, like an architectural
blueprint.
- Dynamic diagrams help model the system’s response to events, helping developers understand how
objects communicate or change state in different scenarios.

In summary, static diagrams model the what (structure) of a system, while dynamic diagrams model the
how (behavior) of a system.

Q2. What is Collaboration diagram? When to use Communication Diagrams.

Ans.
Collaboration Diagram :
A Collaboration diagram, also known as a Communication diagram in UML (Unified Modeling
Language), is an interaction diagram that shows the interactions between objects or components in a
system, emphasizing their relationships and the flow of messages. It displays both the structure and
behavior of the system. The diagram focuses on how objects are connected and interact with one another
to fulfill a specific task or process.

In a collaboration diagram, objects are represented as nodes, and interactions between them are shown
as arrows labeled with messages, indicating the order in which these messages are sent. The diagram
helps in understanding which objects collaborate to execute a particular functionality or scenario.

When to Use Communication Diagrams :

Communication diagrams are typically used when you want to focus on the relationships between
objects, showing how they are organized and how they exchange messages to accomplish a particular
task. These diagrams are useful in the following situations:

1. To Visualize Object Relationships :

Communication diagrams emphasize the structural organization of objects, which is ideal when the
layout and relationships between objects are important.

2. To Model Real-Time Systems :

In real-time or embedded systems, communication between different objects or components often
plays a critical role. Communication diagrams can model these interactions in scenarios where message
passing is essential.

3. To Represent Message Flow :

When the sequence of messages between objects is crucial for understanding the behavior of a system,
communication diagrams are used to depict the message flow in a straightforward manner.

4. For Simple Interaction Scenarios :

Communication diagrams work well in scenarios with simple, direct interactions between a limited
number of objects, such as login systems, ATM operations, or e-commerce transactions.

5. To Complement Sequence Diagrams :

Communication diagrams can be used as an alternative or complement to sequence diagrams. While
sequence diagrams focus on the time-based order of messages, communication diagrams highlight the
objects interactions and their structure.

In summary, collaboration/communication diagrams are best used when you want to understand how
objects interact and are linked, making them useful for modeling collaboration in object-oriented
systems.

Q3. Explain the purpose and components of system sequence diagram in UML diagram. Explain
with the diagram.
Ans.
Purpose of System Sequence Diagram (SSD) in UML :
A System Sequence Diagram (SSD) is used in UML (Unified Modeling Language) to represent the
sequence of interactions between a system and its external actors. The main goal of an SSD is to
visualize how an external actor interacts with the system in a particular use case or scenario. It captures
the inputs and outputs exchanged between the system and external entities (users, other systems, etc.)
and shows how the system responds to each external event.
Key purposes of SSD:
1. Captures System Behavior : SSDs focus on the high-level behavior of the system by representing
its interaction with external actors during the execution of a particular use case.
2. Defines System Boundaries : SSDs help define what is inside and outside the system, focusing on
the external stimuli (messages) that cause a system to perform a certain action.
3. Document Use Cases : SSDs complement use cases by providing a visual representation of how the
system responds to actor inputs and produces outputs, making them useful for requirements gathering
and system design.

Components of System Sequence Diagram:

An SSD consists of the following key components:

1. Actors:
- Represented as stick figures on the left of the diagram.
- Actors can be users, other systems, or external entities that interact with the system.

2. System :
- Depicted as a rectangular box labeled “System” or by its specific name. This box represents the
system as a black box, focusing only on its interactions, not internal workings.

3. Lifelines :
- Vertical dashed lines that extend downwards from the actor and system, representing the timeline of
their existence during the interaction.

4. Messages :
- Arrows from the actor to the system and vice versa. Messages represent the communication (or
events) between the actor and the system.
- Each message shows an action the actor initiates or a response from the system.

5. Return Messages :
- Dashed arrows returning from the system to the actor, representing the response after an action or
operation is processed.

6. Interaction Sequence :
- The vertical arrangement of messages represents the order of interactions, with time progressing
from top to bottom.

Example of System Sequence Diagram :

Here’s an example of an SSD for a simple “Login Use Case” :

1. The Actor (User) initiates a login request by sending the message "enterLoginDetails()" to the
system.
2. The System verifies the login credentials.
3. The system returns a success or failure message, such as "loginSuccess()" or "loginFailed()" to the
actor.

Below is a text-based description of how the SSD might look:

| User | System |
|-----------------------------|---------------------------|
| enterLoginDetails() | |
|--------------------------->| |
| |verifyLogin() |
| |-------------------------->|
| | |
| | loginSuccess()/ |
|<---------------------------| |

This diagram shows how the actor (User) interacts with the system by sending login details, and how
the system processes that input and returns the outcome (success or failure).

When to Use System Sequence Diagrams :

- SSDs are used early in system design, during requirements gathering and use case analysis.
- They are helpful for capturing the flow of interactions for system operations and are typically created
for each major use case or scenario.
- They are also used to ensure clarity in system behavior before delving into more detailed design or
implementation phases.

Q4. What is interaction Diagram? How we draw interaction diagram?

Ans.
An Interaction Diagram in UML (Unified Modeling Language) is used to describe how objects within
a system interact with each other to accomplish a specific task or functionality. It emphasizes the flow
of control and data between objects or components during the execution of a system. There are two
main types of interaction diagrams:

1. Sequence Diagram : Focuses on the chronological order of messages exchanged between objects
over time.
2. Collaboration (Communication) Diagram : Focuses on the structural organization of objects that
send and receive messages, highlighting their relationships.

Both diagrams show how objects collaborate to perform a specific operation but present the information
in different ways. Sequence diagrams focus on the timeline, while collaboration diagrams highlight the
object interactions and relationships.

Types of Interaction Diagrams :

1. Sequence Diagrams :
- These diagrams emphasize the time sequence of messages exchanged between objects or
components in a system. It shows objects, their lifelines, and the interactions in the order they occur.

2. Collaboration Diagrams (also called Communication Diagrams):

- These focus on how objects are organized and interact, showing the relationships between the
objects. It shows which objects communicate and how, without explicitly focusing on the time sequence
of events.

To draw an interaction diagram (typically a Sequence Diagram or Collaboration Diagram), follow these
steps:
Steps to Draw a Sequence Diagram :

1. Identify the Scenario or Use Case :

- Select a specific use case or scenario you want to model. For example, a "place order" use case.

2. Determine the Objects Involved :

- Identify the objects or actors involved in the interaction. These can be users, external systems, or
objects within the system (e.g., User, Order, Payment).

3. Set up the Diagram Layout :

- On the left, place the actors or objects involved. Each object is represented by a box with its name
at the top.
- Draw lifelines (dashed vertical lines) extending downward from each object or actor, representing
their existence over time.

4. Model the Sequence of Interactions :

- Begin adding messages as arrows from one object to another, starting at the top of the diagram and
moving downward.
- Each arrow represents a message (or method call) from one object to another.
- Label each message with a description (e.g., "placeOrder()" or "processPayment()").

5. Add Return Messages :

- If there are any return messages from the system or object (e.g., a confirmation or response), use
dashed arrows to represent the responses.

6. Continue with More Interactions :

- Continue adding interactions, going downward, to model the complete scenario.

7. Finalize the Diagram :

- Ensure the diagram models the complete scenario, clearly showing all the objects and messages
involved in the interaction.

Steps to Draw a Collaboration (Communication) Diagram :

1. Identify the Scenario :

- Like with a sequence diagram, first choose a specific use case or scenario you want to depict.

2. Identify the Objects :

- Determine which objects or actors are involved in the interaction.

3. Place Objects on the Diagram :

- Instead of using vertical lifelines, place objects as nodes on the diagram, arranging them as
necessary. Each object or actor is represented by a labeled box.

4. Draw Links Between Objects :

- Draw lines between objects to represent associations or links.

5. Add Messages :
- For each link, add arrows labeled with the message that gets passed between the objects. Indicate
the order in which messages are passed, typically by numbering them.
Example of Sequence Diagram (text-based):
Customer -> System : browseItems()
Customer -> System : selectItem()
Customer -> System : addItemToCart()
Customer -> System : makePayment()
System -> PaymentGateway : processPayment()
PaymentGateway -> System : paymentConfirmation()
System -> Customer : orderConfirmation()

This sequence diagram represents a shopping system where the customer browses items, selects an item,
adds it to the cart, makes a payment, and finally gets an order confirmation.

When to Use Interaction Diagrams:

1. Design Phase : During system design, interaction diagrams help model the communication between
objects.
2. Requirement Analysis : They assist in understanding how the system behaves in specific scenarios
or use cases.
3. Documenting Complex Interactions : These diagrams are useful for documenting the flow of
control and data in complex operations.

Conclusion:
An Interaction Diagram helps in visualizing how objects in a system communicate with each other
through message exchanges. They are vital tools in object-oriented analysis and design to understand
system behavior and ensure effective communication between objects. Sequence diagrams focus on the
time order of messages, while collaboration diagrams emphasize the structural relationships and
interaction links.

Q5. Describe activity and use case diagram. When to use activity diagrams with real world
scenario.
Ans.
Activity Diagram :
An Activity Diagram in UML (Unified Modeling Language) is used to model the flow of activities or
actions in a system or process. It visually represents workflows, parallel processes, decision points, and
how they are connected. Activity diagrams focus on the dynamic aspects of a system, describing how
various elements interact to carry out a process, including both sequential and concurrent activities.

Key Components of Activity Diagrams :

1. Action/Activity : Represents an operation or step in the process.
2. Decision Node: A diamond-shaped symbol that indicates a decision point where the flow can branch
based on conditions.
3. Control Flow: Arrows representing the flow from one activity to another.
4. Start Node : Indicates the starting point of the process (shown as a filled circle).
5. End Node : Indicates the termination of the process (shown as a filled circle inside a larger circle).
6. Swimlanes : Divides the diagram into sections for different actors or departments, clarifying who is
responsible for which activity.
7. Fork and Join Nodes : Fork represents the splitting of a process into multiple parallel activities,
while join brings them back into a single flow.

When to Use Activity Diagrams :

- Business Processes : Activity diagrams are useful for modeling workflows, business processes, or
system operations like order processing, invoice generation, or customer service operations.
- Real-world Scenarios : In real-world scenarios like **online shopping**, activity diagrams can
represent the steps a customer takes from browsing products to checking out and receiving an order.
- Complex Use Cases : For modeling complex use cases with multiple decision points and alternate
flows, activity diagrams provide a detailed view.

Example of a Real-World Scenario :

For instance, in a hotel reservation system , an activity diagram might illustrate the sequence of steps
from searching for available rooms, selecting a room, entering customer details, processing payment,
and sending a confirmation email.

Use Case Diagram :

A Use Case Diagram represents the functional aspects of a system. It shows the system's functionalities
(use cases) and the actors (users or other systems) that interact with it. The diagram is high-level,
focusing on what the system does (functional requirements) rather than how it does it.

Key Components of Use Case Diagrams :

1. Actors : Represent external entities (users or other systems) that interact with the system.
2. Use Cases : Ovals representing the different functionalities the system provides (e.g., "Place Order,"
"Login").
3. System Boundary : A rectangle that defines the scope of the system and what’s inside or outside of
it.
4. Relationships :
- Association : Links between actors and use cases.
- Include : Represents mandatory sub-processes that a use case must perform.
- Extend : Represents optional or conditional behavior extending the base use case.

When to Use Use Case Diagrams :

- Requirement Gathering : Use case diagrams are ideal for capturing functional requirements during
the early stages of system design.
- User Interaction : They illustrate how users will interact with the system.
- Documenting System Scope : They help define what the system will and won’t do by clarifying the
boundaries between the system and the external actors.

Example of a Real-World Scenario :

In an e-commerce website , a use case diagram might show actors such as customers, administrators,
and payment systems interacting with use cases like "Browse Products," "Add to Cart," "Checkout,"
and "Process Payment."

When to Use Activity Diagrams in Real-World Scenarios :

Activity diagrams are most useful in scenarios where you need to model workflows or business
processes. Some real-world examples include:

1. Order Processing :
For example, in an **order processing system**, an activity diagram can illustrate steps from order
creation, payment processing, packing, and shipping to order delivery.

2. Customer Support Workflow :

In a customer service process , an activity diagram can model the steps involved in receiving a query,
forwarding it to the appropriate department, resolving the issue, and responding to the customer.
3. Healthcare System :
In a patient admission system , an activity diagram can represent the flow from patient check-in,
medical consultation, diagnosis, treatment, to discharge.

4. Loan Approval Process :

For a bank loan approval process, an activity diagram might represent activities such as submitting a
loan application, credit checking, document verification, and final approval or rejection.

Q6. What do you understand by State machine diagram? When we use State Diagrams with
example.
Ans.
A State Machine Diagram (also known as a State Diagram or Statechart Diagram) is a UML diagram
used to represent the different states that an object or system can be in, along with the transitions
between those states. It models how an object responds to external events and transitions from one state
to another. The diagram emphasizes the lifecycle of an object, capturing how it changes state over time
in response to events or conditions.

Key Components of State Machine Diagrams :

1. State : Represents a condition or situation during the life of an object where it satisfies some
condition, performs an action, or waits for an event. States are usually represented by rounded
rectangles.

2. Initial State : Depicted as a filled circle, it shows where the lifecycle of the object begins.

3. Final State: Depicted as a filled circle within another circle, it represents the end of the object’s
lifecycle or process.

4. Transitions: Arrows showing the movement from one state to another, triggered by an event.
Transitions are often labeled with the event that causes the change of state.

5. Event/Trigger : An occurrence that causes the object to move from one state to another.

6. Guard Condition: A condition that must be true for a transition to occur.

When to Use State Machine Diagrams:

State machine diagrams are particularly useful in scenarios where an object undergoes different states
and where its behavior is determined by these states. They are commonly used when:

1. Modeling Lifecycle of an Object: They are used when you want to model the entire lifecycle of an
object, including various possible states and how it transitions between them.

2. Real-Time Systems : In systems where the behavior is state-dependent, such as in embedded or real-
time systems, state diagrams can help model how a system or component behaves based on different
inputs.

3. Representing Event-Driven Systems: If a system or object is heavily dependent on events (e.g., a

traffic light system or vending machine), a state diagram is helpful to model how the system reacts to
those events.
4. Understanding Complex Behaviors : For systems where behavior changes significantly depending
on the current state, state diagrams help clarify the different transitions and conditions that trigger them.

Example of Using a State Machine Diagram :

Vending Machine Example :

Imagine a vending machine that transitions through several states as a user interacts with it:

- Initial State : The machine starts in the "Idle" state, waiting for a customer to insert money.
- Insert Coin : When the user inserts a coin, the machine transitions to the "Waiting for Selection" state.
- Select Item : Once the user selects an item, the machine moves to the "Dispensing Item" state.
- Dispense Item : After dispensing the item, the machine returns to the "Idle" state, waiting for the next
customer.

State Diagram Representation :

[Idle] -- (insert coin) --> [Waiting for Selection]

[Waiting for Selection] -- (select item) --> [Dispensing Item]
[Dispensing Item] -- (item dispensed) --> [Idle]

In this example:
- States : Idle, Waiting for Selection, Dispensing Item
-Events : insert coin, select item, item dispensed
-Transitions : The system transitions from one state to another based on user actions.
When to Use State Diagrams in Real-World Scenarios :

1. ATM Machine :
- States: Idle, Card Inserted, PIN Verified, Processing Transaction, Transaction Complete.
- The state machine diagram can model how the ATM transitions between states as a user interacts
with it, from inserting the card to completing the transaction.

2. Traffic Light System :

- States: Red Light, Green Light, Yellow Light.
- The diagram can model how the traffic light system transitions between red, yellow, and green states
based on timed intervals or external sensors.

3. Order Processing System:

- States: Order Placed, Payment Processed, Order Shipped, Order Delivered.
- The state diagram can be used to model how an order transitions through these states in an e-
commerce system.