UNIT-IV PACKAGE DIAGRAM MODEL AND DYNAMIC MODEL 9

Package Diagram Model : Description of the model-White box, black box-Connections between packagers -
Interfaces -Create Package Diagram -Drill Down. Dynamic Model: State Diagram / Activity Diagram-
Description of the State Diagram -Events Handling -Description of the Activity Diagram - Exercise
A package diagram is a type of structural diagram in UML (Unified Modeling Language) that organizes and
groups related classes and components into packages. It visually represents the dependencies and relationships
between these packages, helping to illustrate how different parts of a system interact with each other.

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 a concise manner.
Basic Elements of Package Diagrams
The following are the basic elements of a Package Diagrams:

In a package diagram, several key elements help organize and clarify the relationships within a system:
 Package: This is the fundamental unit of a package diagram, serving as a container for various
elements like classes and interfaces. It’s depicted as a folder-like icon with a name label, making it
easy to identify.
 NameSpace: This denotes the name of the package and usually appears at the top of the package
symbol. It helps uniquely identify the package within the diagram.
 Package Merge: This relationship illustrates how one package can be merged with another. It’s
represented by a direct arrow between the two packages, indicating that their contents can combine.
 Package Import: This relationship shows that one package can access the contents of another
package, depicted with a dashed arrow.
 Dependency: Dependencies indicate that changes in one package may affect another. This relationship
signifies that one element or package relies on another, highlighting how interconnected they are.
 Element: An element is a single unit within a package, which can be a class, interface, or subsystem.
Elements reside inside packages and are connected to the main package. For instance, a class may
contain various functions and variables, all of which are considered elements tied to that class.
 Constraint: This represents a condition or requirement associated with a package, typically shown in
curly braces. Constraints help define the rules or limitations for how the package operates.
Package Structure and Notation
Below are the package structures and their notations:
1. Package

The above is the notation of a simple Package.

2. Subsystem

The above notation is used to represent subsystem.

3. Dependency

The above dashed arrow sign is used to show the dependency among two elements or two packages.
4. Import
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.
4. Merge

This notation above denotes that the Package 1 can be merged with Package 2
Package Relationships
1. Package Merge Relationship
This relationship is used to represent that the contents of a package can be merged with the contents of another
package. This implies that the source and the target package has some elements common in them, so that they
can be merged together.
Example:

The above diagram depicts that the packages are of different type of payments, but all of them are a some kind
of payment mechanism, so they can all be merged to be called as payment.
2. Package Dependency RelationshipA package can be dependant on other different packages, signifying
that the source package is somehow dependent on the target package.
Examp

The above diagram depicts that the online payment package is dependent on the Internet package and uses
"need" dependency.
3. Package Import Relationship
This relationship is used to represent that a package is importing another package to use. It signifies that the
importing package can access the public contents of the imported package.
Example:

The above package diagram shows the import relationship between the main package Shapes and it's various
other sub packages Square, Rectangle etc. They all are importing the real Shapes package so that the public
contents of the Shapes package can be used by them.
4. Package Access Relationship
This type of relationship signifies that there is a access relationship between two or more packages, meaning
that one package can access the contents of another package without importing it.
Example:

The above diagram depicts the Access relationship between the Front End and Back End services. It is much
needed that a front end service can easily access the important Back End services to carry out any operation.
Use Cases of Package Diagrams
A package diagram is a vital tool in system design, helping to model and illustrate the structure of an
organization or system. Here are some key use cases:
 It visually represents the system’s structure, organizing elements into smaller, manageable packages.
This makes it easier to understand the overall layout.
 The diagram helps manage and organize related modules or components within a system, grouping
them for clarity.
 Developers use package diagrams to show dependencies between different packages, which helps
clarify the system's architecture and the potential impact of changes.
 System architects can break down complex problems into smaller, manageable parts early in the
design process, simplifying component design and implementation.
Best Practices for Package Diagrams
Below are some of the best practices to be followed in case of a Package Diagram:
 It is always recommended to clearly define the package names in such a manner that there is no
duplicate present in the same package which might create confusion.
 Organize the packages in a hierarchical manner so that it represents the proper structure of the system
and the relationship of the various parts of the system.
 Make the packages concise, use a single package to represent a single function or element. Don't use
overcomplicated and complex packages.
 Clearly mention and document the dependencies between the packages using the suitable
symbols .This includes dependencies such as associations, generalizations, or dependencies.
Benefits of Package Diagram
Below are the benefits of package diagram:
 It provides a visual representation of the system's architecture, showing that how each elements are
organized and interact with each other.
 Package Diagram encourages a modular approach to represent any system in form of smaller and easy
to understand packages. It also supports the encapsulation of elements into packages which share a
same trait.
 It servers as a common language of commmunication between the developers and the stakeholders.
 By showing the dependency between the different packages, it become easy to identify and manage
dependencies between the packages, also it becomes easy to address issues related to coupling and
cohesion.
Challenges of Package Diagrams
Below are the challenges of Package diagrams:
 Balancing detail and simplicity in a package diagram is challenging.
 Each package should avoid being overloaded with information to maintain clarity.
 The focus is primarily on the static structure of system elements.
 Package diagrams may not effectively capture dynamic aspects, like runtime behaviors or interactions.
 Dependencies among packages are essential to show, but overemphasis can create clutter.
 Dependencies should be presented clearly and concisely for better understanding.
Package Diagrams in Software Development
Package Diagram plays a significant role in the field of Software Development as a visual representation of an
architecture of a system. It helps in understanding , organizing and communication of the structural
component of a system.
 Package Diagram provides a high level view of the system's architecture by grouping related elements
together to form packages, and representing the dependencies and interactions with each other.
 Package Diagram promotes modularity and encapsulation, which allows the developers to create
software with clear boundaries among its components.
  By visually representing classes, interfaces, functions and other elements in a concise manner by
including them in a package, software developers can manage the complexity of large
software/systems.
in State Machines.

White Box Representation

 Definition: In a white box representation, the internal structure of the package is visible. It exposes the
inner details, such as the classes, interfaces, and their relationships contained within the package.
 Purpose:
o Provides insight into the internal organization and dependencies of a package.
o Useful for developers and designers who need to understand how the components within a
package interact with each other.
 Details Included:
o Classes, interfaces, sub-packages, and their relationships (e.g., associations, dependencies,
generalizations).
o May also include visibility indicators (public, private, protected elements).
 Use Case:
o During system design and development phases where detailed understanding is required.
o For debugging, refactoring, or understanding complex systems.
 Advantages:
o Offers a comprehensive view for understanding package internals.
o Facilitates better communication among team members involved in detailed design.
 Disadvantages:
o May overwhelm viewers who do not need such detailed information.
o Exposes sensitive internal details that might not need to be shared with all stakeholders.

2. Black Box Representation

 Definition: In a black box representation, the internal details of a package are hidden. The package is
treated as a single unit, showing only its public interfaces or points of interaction with other packages.
 Purpose:
o Focuses on the functionality or services provided by the package rather than its internal
implementation.
o Useful for stakeholders who are only concerned with the overall functionality of the package.
 Details Included:
 o The package's name and its public interfaces (e.g., APIs).
o High-level dependencies between packages (e.g., a dependency arrow showing one package
relies on another).
 Use Case:
o During early stages of system design for high-level architectural planning.
o For communication with non-technical stakeholders or external teams.
 Advantages:
o Simplifies the representation, making it easier to understand at a glance.
o Protects the intellectual property and maintains abstraction.
 Disadvantages:
o Lacks the detailed information necessary for implementation or debugging.
o May obscure dependencies or interactions within the package.

3. Key Differences
Feature White Box Representation Black Box Representation

Internal structure and components are Internal details are hidden. Only public interfaces
Visibility
shown. are shown.

Focus Inner workings of the package. Services or functionality provided by the package.

Classes, interfaces, relationships, and sub-

Details Package name and external dependencies.
packages.

Use For detailed design and implementation. For high-level design and communication.

Stakeholder Developers, system architects. Non-technical stakeholders, external teams.

Complexity High complexity. Simplified representation.

4. Analogy
 White Box: Similar to looking inside a car’s engine to understand how all components (e.g., pistons,
belts, spark plugs) work together.
 Black Box: Similar to viewing the car as a whole and focusing only on its features (e.g., speed, fuel
efficiency, brand).
Understanding these two representations helps engineering students decide which level of abstraction is most
appropriate for a given stage of development or audience.

Connections between packagers

In a package diagram, the connections between packages represent various types of relationships that depict
how they interact or depend on each other. Here are the primary types of connections that can exist between
packages:

1. Dependency

 Definition: A dependency indicates that one package (the dependent package) relies on another
package (the supplier package) for its functionality. Changes in the supplier package might affect the
dependent package.
 Representation: Represented by a dashed arrow pointing from the dependent package to the supplier
package.
 Example:
o A package OrderManagement depends on a package PaymentProcessing.
o If PaymentProcessing changes its API, OrderManagement might need to be updated.

2.Import

 Definition: An import relationship specifies that the elements (classes, interfaces) of one package are
accessible to another package.
 Representation: Represented by a dashed arrow with an open arrowhead, sometimes labeled as
«import».
 Example:
o A package UserInterface imports a package Utils to use utility classes or methods.

3. Access

 Definition: An access relationship indicates that a package can access specific elements of another
package.
 Representation: Similar to import, represented with a dashed arrow and sometimes labeled as
«access».
 Example:
o A package Logging provides access to specific logging classes used by a package
ApplicationCore.

4. Containment (Hierarchical Relationship)

 Definition: A containment relationship shows that a package contains sub-packages or components.

 Representation: Represented by nesting one package within another or by showing a direct line
connecting the parent package to its child packages.
 Example:
o A package ECommerceSystem contains sub-packages like ProductCatalog, ShoppingCart,
and UserAccounts.

Example Scenario

E-Commerce System:

 Package OrderManagement depends on InventoryManagement to check product availability

(dependency).
 Package PaymentProcessing imports utility methods from Utils (import).
  Package ApplicationCore accesses specific logging methods from Logging (access).
 Package ECommerceSystem contains sub-packages ProductCatalog, ShoppingCart, and
UserAccounts (containment).

These relationships ensure that the interaction between packages is clearly defined, facilitating better
modularity and maintenance of the system.

Definition of Interfaces in Package Diagrams

 An interface is a contract or specification that defines the methods and properties a package offers to others.
 It serves as a bridge between the internal components of a package and the external packages that depend on
it.

2. Roles of Interfaces in Package Diagrams

a. Encapsulation and Abstraction

 Purpose: Interfaces encapsulate the internal implementation details of a package and expose only what is
necessary for external interaction.
 Benefit: This promotes modularity and reduces the dependency on the internal details of a package, making
the system easier to maintain and evolve.

b. Defining Communication Protocols

 Purpose: Interfaces act as formal communication protocols between packages.

 Benefit: They ensure that dependent packages interact correctly with the package implementing the interface.
c. Flexibility and Interchangeability

 Purpose: Interfaces allow a package to depend on abstractions rather than concrete implementations.
 Benefit: This enables developers to substitute one package with another as long as it adheres to the same
interface, promoting flexibility and reusability.

d. Dependency Management

 Purpose: By relying on interfaces, packages can depend on stable, well-defined contracts rather than on other
packages directly.
 Benefit: This reduces coupling between packages, making the system more robust and easier to scale.

e. Enhancing Testability

 Purpose: Interfaces make it easier to mock or stub dependencies for testing.

 Benefit: This simplifies testing by allowing developers to test a package in isolation from others.

3. Representation of Interfaces in Package Diagrams

 Symbol: Interfaces are represented as a small circle (also called a "lollipop") or a rectangle with the
«interface» keyword.
 Connections:
o A dashed line connects the interface to the package that provides or implements it.
o Solid arrows point from the dependent package to the interface.

4. Example

Scenario: E-Commerce System

 Packages:
o PaymentProcessing
o OrderManagement
 Interface: PaymentService

Description:

 The PaymentProcessing package provides the PaymentService interface.

 The OrderManagement package depends on the PaymentService interface to process payments, without
needing to know the internal workings of PaymentProcessing.

Diagram:
plaintext
CopyEdit
+------------------+ +------------------+
| OrderManagement | | PaymentProcessing|
| | | +--------------+ |
| +--------------+ | | |«interface» | |
| | PaymentService| | | | PaymentService| |
| +--------------+ | | +--------------+ |
| | | |
+------------------+ +------------------+
| ^
|---------------------------|

5. Key Benefits

1. Improved Modularity: Interfaces clearly define boundaries between packages.

2. Reduced Coupling: By depending on interfaces, packages avoid tight coupling with specific implementations.
3. Enhanced Collaboration: Teams can work on different packages independently as long as they adhere to the
interface contracts.
4. Ease of Maintenance: Changes in the implementation of a package don't affect dependent packages as long as
the interface remains consistent.

interfaces in a package diagram are essential for achieving abstraction, flexibility, and modularity, enabling
the design of scalable and maintainable systems.

Drill down
Drill down is an analytics capability that allows users to instantly shift from an overview of data to a
more detailed and granular view within the same dataset they are analyzing by clicking on a metric
in a dashboard or report.
The Drill Down technique is a method for gaining insight into the root causes of a problem within a
department or area. After the root causes are known, a larger plan can be devised to address the
problem.

A Drill Down is not the same as a diagnosis, but rather a broad and deep general examination.
Furthermore, the technique is not used to find out the causes of all problems, but only the 20 percent
of the causes behind 80 percent of the effects.
This is a principle from the Pareto-analysis.
When a major problem arises with potentially major consequences, one of the best things that can be
done is to split the problem into several components until the problem is resolved. This can be done
with the Drill Down technique. By dividing a larger process into smaller pieces, an overview is
created and the problem can be solved step by step.
Using Drill-Down to Navigate the Hierarchy

Drill-down refers to the process of exploring the contents of a package or subsystem in greater detail. It is
useful when a package encapsulates multiple elements, and you want to focus on a specific part of the system.
Steps to Perform Drill-Down:

1. Select the Target Package:

o Identify a package in the diagram that needs further elaboration.
2. Expand the Contents:
o Open the package to reveal its internal components, such as classes, sub-packages, or relationships.
Tools like ArgoUML, Enterprise Architect, or Visual Paradigm make this easy by allowing you to zoom
in on the package.
3. Navigate Between Levels:
o Move from a high-level view of the system to a detailed view of specific components within a package.
4. Create Detailed Diagrams:
o Within the package, create additional diagrams (e.g., class diagrams, sequence diagrams) to represent
interactions or behaviors at a granular level.
5. Use Navigation Links:
o In some UML tools, navigation links enable quick movement between the higher-level package view
and the detailed internal diagrams.

Benefits of Using Drill-Down in Package Diagrams

 Improved Clarity:
o It avoids overwhelming users with too much information by showing only the relevant level of detail.
 Hierarchical Navigation:
o It provides a clear path to explore system components at different levels of abstraction.
 Enhanced Understanding:
o Facilitates focused analysis of specific subsystems or modules without losing sight of the broader
context.

Advantages of Drill-Down in Diagrams

1. Improved Clarity:
o Simplifies understanding by showing only the relevant level of detail when needed, avoiding
overwhelming information.
2. Hierarchical Exploration:
o Enables navigation from a high-level view to granular details, ensuring better comprehension
of complex systems.
3. Focus on Specific Elements:
o Facilitates targeted analysis of particular subsystems or components without distracting from
the overall system structure.
4. Enhanced Documentation:
o Provides a structured way to document systems at different levels of abstraction, improving
maintainability.
5. Support for Iterative Development:
o Encourages iterative design and analysis, allowing designers to expand and refine details as
required.
Disadvantages of Drill-Down in Diagrams

1. Risk of Fragmentation:
o Excessive drill-down levels can make navigation cumbersome and disjointed, leading to a
fragmented understanding of the system.
2. Dependence on Tools:
o Effective drill-down navigation often requires advanced UML tools, which may have a steep
learning curve or cost.
3. Loss of Context:
o Focusing on detailed views might cause stakeholders to lose sight of the high-level picture or
system's overall purpose.
4. Inconsistent Detailing:
o If not uniformly detailed, some components may have insufficient or excessive information,
creating gaps in understanding.
5. Time-Consuming:
o Creating detailed diagrams for each drill-down level can be time-intensive, especially for large
systems.

Real-world applications of drill down analysis:

Business Intelligence:
Analyzin g sales performance by product category, then drilling down to
individual product sales or store performance.
Examining customer behavior by demographics, then drilling down to specific
customer segments to understand their purchasing patterns.
Finance:
Reviewing a company's overall financial statement, then drilling down to
individual expense categories to identify areas for cost reduction.
Analyzing investment portfolio performance by asset class, then drilling down to
specific investments to assess risk and potential returns.
Healthcare:
Examining patient outcomes by hospital, then drilling down to analyze treatment
protocols for specific conditions.
Identifying trends in patient demographics by disease type to inform healthcare
strategies.
Marketing:
Analyzing website traffic by source, then drilling down to specific landing pages to
understand user behavior
Evaluating marketing campaign performance by region, then drilling down to
individual ad placements to optimize ad spend

State Diagram:
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 Machine diagrams are also referred to as State Machines Diagrams
and State-Chart Diagrams.
 These terms are often used interchangeably. So simply, a state machine
diagram is used to model the dynamic behavior of a class in response to
time and changing external stimuli.

Basic components and notations of a State Machine diagram

1. Initial state
We use a black filled circle represent the initial state of a System or a Class. A
transition from this state will show the first real state.

2. 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.
3. 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.

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

5. 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.
6. 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.

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

8. Decision box
It is of diamond shape that represents the decisions to be made on the
basis of an evaluated guard.
 9. Final State
We use a filled circle within a circle notation to represent the final state in a
state machine diagram.

Types of State

The UML consist of three states:

1. Simple state: It does not constitute any substructure.

2. Composite state: It consists of nested states (substates), such that it
does not contain more than one initial state and one final state. It can be
nested to any level.
3. Submachine state: The submachine state is semantically identical to the
composite state, but it can be reused.

How to draw a State Machine diagram in UML?

Below are the steps of how to draw the State Machine Diagram in UML:
Step1. Identify the System:
 Understand what your diagram is representing.
  Whether it’s a machine, a process, or any object, know what
different situations or conditions it might go through.
Step2. Identify Initial and Final States:
 Figure out where your system starts (initial state) and where it ends
(final state).
 These are like the beginning and the end points of your system’s journey.
Step3. Identify Possible States:
 Think about all the different situations your system can be in.
 These are like the various phases or conditions it experiences.
 Use boundary values to guide you in defining these states.
Step4. Label Triggering Events:
 Understand what causes your system to move from one state to another.
 These causes or conditions are the events.
 Label each transition with what makes it happen.
Step5. Draw the Diagram with appropriate notations:
 Now, take all this information and draw it out.
 Use rectangles for states, arrows for transitions, and circles or rounded
rectangles for initial and final states.
 Be sure to connect everything in a way that makes sense.
Let’s understand State Machine diagram with the help of an example, ie for an
online order :

The UML diagrams we draw depend on the system we aim to represent. Here is
just an example of how an online ordering system might look like :
1. On the event of an order being received, we transit from our initial state to
Unprocessed order state.
2. The unprocessed order is then checked.
3. If the order is rejected, we transit to the Rejected Order state.
 4. If the order is accepted and we have the items available we transit to the
fulfilled order state.
5. However if the items are not available we transit to the Pending Order state.
6. After the order is fulfilled, we transit to the final state. In this example, we
merge the two states i.e. Fulfilled order and Rejected order into one final
state.
When to use a State Machine Diagram?

The state machine diagram implements the real-world models as well as

the object-oriented systems. It records the dynamic behavior of the system,
which is used to differentiate between the dynamic and static behavior of a
system.
State machine diagram is used for:

1. For modeling the object states of a system.

2. For modeling the reactive system as it consists of reactive objects.
3. For pinpointing the events responsible for state transitions.
4. For implementing forward and reverse engineering.

What are the Differences between a State Machine

Diagram and a Flowchart?
Statechart diagram FOR LIBRARY MANGEMENT SYSTEM
 Activity Diagrams | Unified Modeling Language (UML)
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 ie 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.
 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.
 They are used in business and process modeling where their primary use is
to depict the dynamic aspects of a system.

Activity Diagram Notations

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

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

For example:
Consider the previous example of opening an application, opening the
application is an activity state in the activity diagram.

3. 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.
For example:
Here both the states transit into one final state using action flow symbols i.e.
arrows.

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

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.
 5. 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.
6. 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.

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

10. 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.
 11. 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.

How to Draw an Activity Diagram in UML?

Step 1. Identify the Initial State and Final States:

 This is like setting the starting point and ending point of a journey.
  Identify where your process begins (initial state) and where it concludes
(final states).
 For example, if you are modelling a process for making a cup of tea, the
initial state could be “No tea prepared,” and the final state could be “Tea
ready.”
Step 2. Identify the Intermediate Activities Needed:
 Think of the steps or actions required to go from the starting point to the
ending point.
 These are the activities or tasks that need to be performed.
 Continuing with the tea-making , intermediate activities could include “Boil
water,” “Pour tea into a cup”.
Step 3. Identify the Conditions or Constraints:
 Consider the conditions or circumstances that might influence the flow
of your process.
 These are the factors that determine when you move from one activity
to another.
 Using the tea-making scenario, a condition could be “Water is boiled,”
which triggers the transition to the next activity.
Step 4. Draw the Diagram with Appropriate Notations:
 Now, represent the identified states, activities, and conditions visually using
the appropriate symbols and notations in an activity diagram. This diagram
serves as a visual map of your process, showing the flow from one state to
another.
4. What are Activity Diagrams used for?
Activity diagrams are used in software development and system design to model
and visualize the dynamic aspects of a system. Here are some common uses of
activity diagrams:
 Dynamic modelling of the system or a process.
 Illustrate the various steps involved in a UML use case.
 Model software elements like methods,operations and functions.
 We can use Activity diagrams to depict concurrent activities easily.
 Show the constraints, conditions and logic behind algorithms.
 During the requirements analysis phase, activity diagrams assist in
capturing and documenting the dynamic aspects of user interactions.
5. What are the Differences between an Activity diagram and a Flowchart? An
activity diagram is very similar to a flowchart. So let us understand if activity
diagrams or flowcharts are any different.
 Activity Diagram Flow Chart

An activity diagram is associated with

A Flow Chart is associated with the
the UML(Unified Modelling
programming.
Language)

An activity diagram is used to model Depicts a diagrammatic representation

the dynamic aspects of a system and illustrating a solution model to a given
also illustrates the workflow of problem and a flow chart converges
activities within a use case or business into being an activity diagram if
process. complex decisions are being made.

Commonly used in software

Widely used in software engineering
engineering within the UML for
for representing algorithms, decision
modeling and designing software
structures, and program flows.
systems on high level.

Activity diagram for a banking system