UML

• What is UML?
• Unified Modeling Language (UML) is a standardized visual language used to
represent and design software systems. UML provides a robust framework for
modeling both the static structure and dynamic behavior of software, enabling
developers, designers, and stakeholders to understand, analyze, and
communicate system architectures effectively. By offering a set of diagram types
tailored to different aspects of a system, UML helps streamline processes such as
requirements gathering, system design, and documentation. It bridges the gap
between conceptual understanding and technical implementation, ensuring all
stakeholders have a shared vision of the system.
Why Use UML?
[Link] Communication: UML provides a shared language for developers, project managers, and
clients, bridging the gap between technical and non-technical teams. This ensures alignment and
reduces misunderstandings.
[Link] in Design: Complex systems are visualized in an organized manner, making them easier to
analyze and decompose into manageable components. This aids both high-level overviews and
detailed technical planning.
[Link]: Standardized notations across all diagrams reduce ambiguities, allowing stakeholders
to interpret models uniformly.
[Link] Error Detection: Visual modeling helps identify logical inconsistencies, integration issues, and
design flaws during the planning phase by offering a clear, standardized representation of the
system. By using UML diagrams like use case and activity diagrams, stakeholders can pinpoint
potential mismatches in requirements, detect incorrect workflows, or highlight missing system
interactions. For example, an activity diagram can reveal unhandled edge cases in a process flow,
such as what happens if a user cancels an order mid-process. Similarly, sequence diagrams can
expose synchronization issues in multi-threaded operations. This proactive identification of issues
significantly reduces the likelihood of costly and time-consuming fixes later in development.
[Link]: UML diagrams serve as comprehensive documentation for future development,
maintenance, and scaling efforts.
How to Use UML?
[Link] Gathering: Use case diagrams map system functionalities from a user’s
perspective, defining clear objectives and scope. These diagrams include key elements
like actors, which represent users or external systems, and use cases, which outline
specific functionalities of the system. For example, a "Customer" actor might interact
with the system through use cases such as "Place Order" or "Search Product." By
illustrating these interactions within a system boundary, use case diagrams provide a
precise, visual representation of what the system must achieve, ensuring alignment
between stakeholders and developers.
[Link] Design: UML diagrams play a pivotal role in system design by visually
representing both static and dynamic aspects of the system. Class diagrams specify the
static structure by detailing classes, their attributes, methods, and relationships, such
as inheritance and associations. Sequence diagrams highlight the dynamic interactions
between objects over time, showcasing the order of message exchanges and method
calls. Activity diagrams further detail workflows by modeling processes, decision points,
and parallel activities, ensuring that all paths and edge cases are accounted for. These
diagrams together ensure a cohesive design that aligns with both technical
3. Implementation Support: UML diagrams act as detailed blueprints for developers, providing a
visual representation of the system’s design and structure. These diagrams bridge the gap
between high-level architectural planning and coding by specifying key details like class
hierarchies, object interactions, and process workflows. For instance, class diagrams help
developers implement relationships and dependencies accurately, while sequence diagrams
ensure that message passing and method calls are correctly executed. This alignment reduces
misinterpretations, speeds up development, and minimizes integration issues during coding and
testing phases.
4. Testing and Validation: Behavioral diagrams like state machine and sequence diagrams help
testers validate system behavior against expected outcomes by providing a clear visualization of
how the system transitions between states and interacts with various components. State
machine diagrams are especially useful for identifying incorrect state transitions or unhandled
events, while sequence diagrams clarify message flows and timing between objects. For
example, in an online ordering system, a sequence diagram can ensure the "Order Placed" event
triggers subsequent actions like payment processing and inventory updates, highlighting any
missing or incorrect sequences. Similarly, a state machine diagram can verify that an order
progresses correctly through states like "Pending," "Processing," and "Shipped," ensuring robust
system behavior under various conditions.
• What Happens If UML Is Not Used?
[Link] in Design: Without UML, design misinterpretations are more likely,
leading to inconsistent implementation and increased rework.
[Link] Communication: Teams may struggle to collaborate effectively
without a standardized visual language.
[Link] Issues: Lack of clear documentation makes it harder to adapt or
expand the system to meet evolving requirements.
[Link] Costs: Errors identified later in the development lifecycle often require
extensive and costly fixes, which UML can help mitigate.
• UML in Agile vs. Traditional Models
• Agile Processes:
• Agile development prioritizes working software over comprehensive documentation, meaning
UML diagrams are often lightweight and purpose-driven.
• In Agile, UML fits as a tool for iterative communication rather than exhaustive planning. For
instance, a simple use case diagram might be created during a sprint planning session to align
developers on a feature's scope and interactions.
• Activity diagrams can also help visualize workflows for user stories or tasks within a sprint,
ensuring clarity without overburdening the team with documentation.
• Diagrams evolve incrementally in Agile, adapting as the product develops through iterative
feedback cycles.
• Traditional Models:
• Traditional models, like Waterfall, heavily rely on upfront documentation, including comprehensive
UML diagrams.
• These diagrams, such as detailed class and sequence diagrams, form the backbone of design and
are often fixed early in the lifecycle.
• UML diagrams in traditional approaches are more static, serving as detailed blueprints for the
• In Agile, UML’s flexibility shines as it adapts to rapid changes and evolving
requirements, supporting teams without imposing the rigidity of traditional
documentation-heavy models.
• Agile Processes:
• UML is used iteratively, focusing on specific system components during each sprint.
• Lightweight diagrams, such as use case and activity diagrams, are preferred for quick
updates and communication.
• Continuous feedback loops ensure diagrams evolve alongside the project.
• Traditional Models:
• UML forms the backbone of extensive upfront design documentation.
• Comprehensive diagrams, including class, sequence, and deployment diagrams, are
created to cover every aspect of the system in detail.
• Fixed models guide development with minimal iteration.
• Types of UML Diagrams
• UML diagrams are broadly classified into two categories:
• 1. Structural Diagrams
• Structural diagrams represent the static aspects of a system, showing its structure,
components, and relationships.
• Class Diagram: Depicts the classes, attributes, methods, and relationships between
classes in a system.
• Object Diagram: Shows instances of classes and their relationships at a specific moment
in time, capturing the state of objects.
• Component Diagram: Represents the organization and dependencies of components,
often used for large-scale systems.
• Deployment Diagram: Illustrates the physical deployment of artifacts on hardware
nodes, detailing server configurations and network interactions.
• Package Diagram: Groups related classes or components into packages, showcasing
• 2. Behavioral Diagrams
• Behavioral diagrams capture the dynamic behavior of a system, including
interactions, processes, and state changes.
• Use Case Diagram: Describes the interactions between users (actors) and the
system, focusing on functional requirements.
• Activity Diagram: Visualizes workflows, including decision points, parallel
processes, and sequences.
• Sequence Diagram: Shows the interaction between objects over time,
highlighting message exchanges and lifelines.
• State Machine Diagram: Captures the states and transitions of an object in
response to events, mapping its lifecycle.
• Collaboration Diagram: Depicts object interactions organized around structural
relationships, emphasizing data flow.
 Common
Diagram Name Category Purpose/Use Case Key Elements Applications
Defines the static
structure of a system, Classes, attributes, Database schema design,
Class Diagram Structural showing classes, methods, associations, object-oriented
attributes, and generalizations development
relationships.
Represents a snapshot of
Debugging, modeling
Object Diagram Structural system objects at a Objects, relationships
real-time states
specific point in time.
Depicts the organization
Components, interfaces, Microservices design,
Component Diagram Structural and dependencies of
dependencies software architecture
components in a system.
Shows the physical
Nodes, artifacts, Network setup,
Deployment Diagram Structural deployment of software
associations infrastructure planning
on hardware nodes.
 Models interactions
between actors and Requirement
Actors, use cases,
Use Case Diagram Behavioral the system to capture gathering, system
relationships
functional scoping
requirements.
Illustrates workflows,
Activities, transitions,
including decisions Process modeling,
Activity Diagram Behavioral forks, joins, decision
and parallel algorithm design
nodes
processes.
Shows object
API design,
interactions over Lifelines, messages,
Sequence Diagram Behavioral debugging
time, focusing on activations
communication flows
message flow.
Captures states of an
State Machine States, transitions, Lifecycle modeling,
Behavioral object and transitions
Diagram events finite state machines
triggered by events.
Depicts object
Collaboration Objects, links, Workflow modeling,
Behavioral interactions and their
Diagram messages service orchestration
relationships.
• Basics of All UML Diagrams
• Each UML diagram has:
• Symbols: Specific notations for elements like classes, actors, objects, or states.
• Relationships: Such as associations, generalizations, dependencies, or transitions.
• Purpose: Focus on a particular aspect of the system to enhance understanding
and facilitate communication.
Use case diagram
• A use case diagram represents the interactions between external users (actors)
and the system, serving as a blueprint for identifying functional requirements. It
focuses on what the system must achieve, highlighting user-centric interactions
and system boundaries. Technically, these diagrams use elements like actors (e.g.,
users, external systems) and use cases (e.g., "Place Order," "Generate Report") to
visualize the scope of the system. For example, in an online shopping platform, a
"Customer" actor might interact with use cases like "Search Product" or "Add to
Cart." By showing these relationships, use case diagrams help stakeholders
identify gaps in requirements, align the system’s functionality with business
objectives, and establish a shared understanding of the project's goals across
teams. They also serve as a foundation for further design and development
processes, ensuring that all functionalities are explicitly defined and agreed upon
early in the project lifecycle.
Components of a Use Case Diagram:
• Use case diagrams consist of several key components that includes.
collectively represent the functional aspects of a system 1. Example: All functionalities such as product search and
and its interactions with external entities. Each component payment processing are encapsulated within the e-commerce
contributes to capturing and visualizing the system’s system’s boundary.
behavior and scope effectively. 4. Relationships: Define how actors and use cases interact or
1. Actors: Represent the external entities that interact with depend on one another. UML provides several types of
the system. These can be individual users, external relationships to capture these interactions:
systems, or organizations. Actors are depicted as stick 1. Association: A direct link between an actor and a use case,
figures or labeled entities. indicating interaction.
1. Example: A "Customer" actor is associated with the "Place Order"
1. Example: In an e-commerce application, a "Customer" is an use case.
actor who interacts with the system by placing orders, while a 2. Include: Represents a mandatory relationship where a use
"Payment Gateway" system is another actor facilitating case includes the functionality of another.
transactions.
1. Example: The "Place Order" use case includes "Authenticate User" to
2. Use Cases: Denote the specific functionalities or services ensure secure transactions.
provided by the system to achieve a particular goal. Each 3. Extend: Denotes an optional or conditional relationship,
use case is represented as an oval, labeled with the where one use case extends the behavior of another under
specific conditions.
functionality it performs. 1. Example: "Apply Discount" extends "Place Order" when promotional
1. Example: "Place Order," "Search Product," and "View Cart" codes are used.
are typical use cases in an online shopping platform. 4. Generalization: Illustrates inheritance relationships between
3. System Boundary: A rectangle that encloses all the use actors or use cases.
cases, representing the scope of the system. The boundary 1. Example: A "Registered Customer" actor generalizes the "Guest
User" actor, inheriting basic interactions while adding capabilities like
clearly separates the internal functionalities from external saved payment details.
interactions, ensuring clarity in defining what the system
Component Description Purpose
External entities (users or systems) Define who or what interacts with
Actors interacting with the system. the system.
Functionalities or services Outline what the system does to
Use Cases provided by the system. meet user needs.
The rectangle enclosing all use Represents the scope of the
System Boundary cases. system.
A link between an actor and a use Indicates interaction or
Association case. communication.
A relationship where one use case Avoid redundancy and reuse
Include includes another mandatory use common functionalities.
case.
A relationship where a use case Represent conditional or optional
Extend adds optional behavior to another. features.
Inheritance relationships between Show specialization or hierarchical
Generalization actors or use cases. relationships.
• Discussion on Include and Extend Relationships
• The "Include" and "Extend" relationships are pivotal in defining the modularity and conditional behavior
of a system:
[Link] Relationship:
1. Represents mandatory functionality that one use case incorporates into another. This relationship is used to avoid
redundancy by reusing common behavior across multiple use cases.
2. Technical Explanation: The included use case is executed every time the base use case is triggered. This is particularly
useful when the same functionality, such as "Authenticate User," needs to be invoked by multiple higher-level use
cases like "Place Order" and "View Account."
3. Example: In an e-commerce application, the "Place Order" use case includes the "Authenticate User" use case to
ensure that only authorized users can proceed with their orders.
[Link] Relationship:
1. Represents optional or conditional behavior that extends the functionality of the base use case. This allows the system
to incorporate additional features without altering the primary behavior.
2. Technical Explanation: The extending use case is executed only when specific conditions are met. For example, "Apply
Discount" extends "Place Order" when a promotional code is entered by the user.
3. Example: In a hotel booking system, the "Book Room" use case can be extended by "Add Special Requests" if the user
chooses to include additional preferences such as meal plans or accessibility options.
• By leveraging "Include" and "Extend" relationships, designers can create modular, reusable, and flexible
use case diagrams that reflect real-world scenarios while maintaining clarity and simplicity.
Activity Diagram
• An activity diagram illustrates workflows of a system, focusing on the sequence and conditions
of tasks or operations.
• It is used to model business processes, user workflows, or algorithmic steps, providing a clear
visualization of decision points and parallel tasks.
• Components of an Activity Diagram:
[Link]: Represent tasks or actions.
1. Example: "Enter Payment Details."
[Link] Node: Indicates the beginning of a workflow, depicted by a filled circle.
[Link] Node: Represents the completion of a workflow, shown as a filled circle within a larger
circle.
[Link] Nodes: Depict branching based on conditions, represented by diamonds.
1. Example: "Is Payment Valid?" leads to different paths.
[Link] Nodes: Combine multiple paths into one, simplifying workflows.
[Link] and Join Nodes: Represent parallel processing and synchronization.
1. Example: Fork into "Process Payment" and "Send Confirmation Email."
Component Description Purpose
Represent individual tasks or actions in Define the steps involved in a process or
Activities the workflow. operation.

Depicted by a filled circle, indicates the

Start Node start of the process.
Marks the beginning of a workflow.

Depicted by a filled circle within another

End Node circle, represents process end.
Marks the completion of a workflow.

Depicted by diamonds, indicate Show points where decisions affect the

Decision Nodes branching based on conditions. workflow path.

Combine multiple paths into a single Simplify complex workflows by merging

Merge Nodes path. paths.

Enable visualization of simultaneous

Fork Nodes Represent splitting into parallel tasks.
processes.

Represent synchronization of parallel Ensure completion of parallel tasks

Join Nodes tasks. before continuing.

Arrows indicating the flow between Show the sequence and conditions for
Transitions nodes. moving between activities.
Component Symbol Purpose Example
Marks the beginning of Start of browsing for
Start Node Filled Circle
the process. products.
Indicates the end of the Order confirmation is
End Node Double Circle
process. sent.
Rectangle with Rounded Represents a task or
Activity Add Item to Cart.
Edges action.
Indicates branching based
Decision Node Diamond Is Payment Valid?
on conditions.
Splits one flow into Process Payment and
Fork Node Horizontal or Vertical Bar
multiple parallel tasks. Send Confirmation Email.
Both payment and
Synchronizes parallel
Join Node Horizontal or Vertical Bar inventory update
tasks into one flow.
completed.
Shows the flow from one From browsing to adding
Transition Arrow
activity to the next. items to the cart.
• Practical Applications
• Use Case Diagram: Effective for requirement gathering, stakeholder
communication, and scoping projects.
• Activity Diagram: Useful for process modeling, algorithm design, and visualizing
complex workflows.
Step-by-Step Process for Creating a Use Case Diagram
• Step 1: Understand the Scenario • Use "include" and "extend" relationships
• Clearly define the system’s purpose and where applicable to avoid redundancy and
scope. add optional functionalities.
• Identify the primary functionalities and • Consider generalizations if actors or use cases
stakeholders involved. share common traits.
• Step 2: Identify the Actors • Step 5: Define the System Boundary
• Determine who or what interacts with the • Draw a rectangle around all use cases to
system (e.g., users, external systems). depict the system’s scope.
• Step 3: Identify the Use Cases • Place actors outside the boundary.
• Define the system’s functional requirements • Step 6: Validate and Refine
as use cases. • Review the diagram for completeness and
• Ensure each use case represents a meaningful accuracy.
interaction or feature. • Ensure the diagram is clear and effectively
• Step 4: Establish Relationships communicates the system’s scope and
functionality.
• Connect actors to relevant use cases using
Element Symbol Purpose Example

Represents a user or
Actor Stick figure Customer, Librarian
external system

Describes a functionality or
Use Case Oval Place Order, Borrow Book
feature

Defines the scope of the

System Boundary Rectangle E-commerce System
system

Association Solid line Links an actor to a use case Customer -> Search Product

Reuses common Place Order -> Include ->

Include Dotted arrow (<<include>>)
functionality Authenticate User

Place Order -> Extend ->

Extend Dotted arrow (<<extend>>) Adds optional behavior
Apply Discount
• Scenario 1: E-Commerce Platform
• An e-commerce platform allows customers to search for products, add items to a
shopping cart, and place orders. The system interacts with a payment gateway to
process payments and sends order details to the warehouse for inventory
updates. Administrators can manage inventory and track orders. The platform
must ensure secure user authentication during transactions and support discount
codes for promotional offers.
Element Details
Actors Customer, Admin, Payment Gateway
Search Product, Add to Cart, Place Order, Manage
Use Cases
Inventory, Process Payment
System Boundary E-commerce Platform
Customer -> Search Product -> Add to Cart -> Place
Relationships Order; Place Order -> Include -> Process Payment;
Admin -> Manage Inventory
• A library management system enables members to borrow and return books,
view book availability, and renew memberships online. Librarians manage book
inventories, add new books to the catalog, and track overdue books. The system
should notify members about due dates and provide a facility for fines collection.
Both members and librarians have distinct access rights within the system.
Element Details
Actors Member, Librarian
Borrow Book, Return Book, Add Book, Renew
Use Cases
Membership
System Boundary Library Management System
Member -> Borrow Book -> Extend -> Renew
Relationships Membership; Librarian -> Add Book -> Manage
Inventory
• A hotel booking system allows guests to search for available rooms, book
reservations, and cancel bookings. The system integrates with a payment gateway
to handle deposits and refunds. Guests can add special requests, such as extra
amenities or early check-in. Administrators can update room availability, manage
pricing, and process guest feedback.
lement Details
Actors Guest, Admin, Payment System
Search Room, Book Room, Cancel Booking, Process
Use Cases
Payment
System Boundary Hotel Booking System
Guest -> Search Room -> Book Room; Book Room ->
Relationships Include -> Process Payment; Guest -> Extend -> Cancel
Booking
• An online food delivery application enables users to browse menus from
restaurants, place food orders, and track deliveries. The system interacts with
restaurants to confirm orders and with delivery personnel to ensure timely
dispatch. Users can apply discount codes, provide ratings, and pay online.
Restaurants update menus, while administrators oversee system performance
and resolve user complaints.
Element Details
Actors User, Restaurant, Delivery Personnel, Admin
Browse Menu, Place Order, Track Delivery, Update
Use Cases
Menu
System Boundary Food Delivery Application
User -> Browse Menu -> Place Order -> Track Delivery;
Relationships
Restaurant -> Update Menu
Step-by-Step Process for Creating an Activity
Diagram
• Step 1: Understand the Scenario • Sequence the activities and connect them
• Clearly define the process or workflow to be with transitions (arrows).
modeled. • Place decision nodes where choices affect
• Identify the key actions, decision points, and the workflow path.
outcomes. • Add fork and join nodes to represent parallel
• Step 2: Identify Key Components processing.
• Activities: Determine all tasks or operations • Step 4: Add Annotations
involved in the workflow. • Label transitions with conditions or triggers.
• Start and End Nodes: Define where the • Clearly label activities, decision points, and
process begins and ends. nodes for readability.
• Decision Points: Identify points where the • Step 5: Validate the Diagram
process branches based on conditions. • Check for completeness, clarity, and logical
• Forks and Joins: Note parallel tasks that flow.
occur simultaneously and when they • Ensure all paths lead to an end node.
synchronize.
• Scenario 1: E-Commerce Platform
• A customer browses an e-commerce platform, selects items to add to their cart,
and proceeds to checkout. During payment, the system validates the payment
details. If successful, the system confirms the order, updates inventory, and sends
a confirmation email. If payment fails, an error message is displayed.
Element Details
Browse Catalog, Add Item to Cart, Check Out, Confirm
Activities
Payment
Start Node Customer begins browsing the platform.
End Node Order confirmation is sent.
"Is Payment Valid?" directs flow to success or error
Decision Nodes
paths.
Splits into "Send Confirmation Email" and "Process
Fork Nodes
Payment" tasks.
Shows sequential flow from browsing to payment
Transitions
confirmation.
• A library member searches for a book in the system and checks its availability. If
the book is available, they proceed to borrow it. The system updates the
inventory and issues a receipt. If the book is not available, the system notifies the
member and allows them to reserve it.
Element Details
Activity Diagram Elements

Activities Search Book, Borrow Book, Return Book

Start Node Member initiates a search for books.
End Node Borrowing or returning process is completed.
"Is Book Available?" determines whether borrowing is
Decision Nodes
successful.
Allows simultaneous actions like updating inventory
Fork Nodes
and issuing receipts.
Shows the sequence from searching to borrowing or
Transitions
returning.
• A guest searches for rooms on the hotel’s booking system and selects a room to
book. The system checks room availability. If the room is available, the guest
proceeds to confirm the booking and process payment. Once completed, the
system updates room availability and sends a booking confirmation.
Element Details
Activities Search Room, Confirm Booking, Process Payment
Start Node Guest begins by searching for rooms.
End Node Booking confirmation is sent.
"Is Room Available?" directs flow to booking or error
Decision Nodes
paths.
Splits into updating room availability and processing
Fork Nodes
payment tasks.
Indicates flow from room search to booking
Transitions
completion.
• A user browses the food delivery app to select dishes from a restaurant menu and
places an order. The system checks food availability. If the order is valid, the
restaurant prepares the food while delivery personnel are assigned. The order is
then delivered to the user.
Element Details
Browse Menu, Place Order, Prepare Food, Deliver
Activities
Order
Start Node User starts by browsing the menu.
End Node Food is delivered to the user.
"Is Food Available?" determines order success or
Decision Nodes
failure.
Splits into "Prepare Food" and "Assign Delivery
Fork Nodes
Personnel" tasks.
Tracks the flow from order placement to delivery
Transitions
completion.
• The Automatic Teller Machine (ATM) is the banking subsystem
that enables the end-users to interact with the multiple
functionalities of the bank like transactions, depositing, etc.
• In this diagram, we have two actors, the customer, and the
technician. The customer needs to check the balance, withdraw
cash, deposit funds, and transfer funds. All these functionalities
are the use cases. The technician repairs and maintains the ATM
so that customers have no complaints. These are the use-cases
too.
• There is a relationship between the bank and the ATM because
the user will only do such acts when the bank authenticates
them.
• In the diagram, we can see the multiple actors: staff and the
student, librarian, and library database. And we have dozens of
use cases like authenticating, reserve a book, renewing a book,
paying a fine, etc. Some use cases are related to each other, like
invalid renewal and renewing a book, registering a new user,
getting a library card ID, etc.
• The librarian also does multiple tasks. The thing to notice here is
that one actor is a machine that is the library database. As
mentioned above, the actor can be anyone, either a human and a
machine.
• In this illustration, we have an online shopping subsystem. It has
use cases like view items, make a purchase, checkout, and client
register. Then we have multiple actors like the registered user,
web customer, and new customer. These actors are related to
each other. The use cases are also in a relationship.
• The actors PayPal and credit payment service are the
organizations interacting with the subsystem with different use-
cases.
• The shopping order processing above shows how to deal with an
order. When it's rejected, the order will be closed. Besides, the
bar represents actions that you can do simultaneously. When it's
accepted, you have to fill it first, and after that, you can ship the
order and send an invoice. When the order closes, the transaction
is complete.
• When you go to withdraw cash from an ATM, three parties will be
involved, including the customer, ATM, and the bank. The ATM
coordinates with the bank at various points to make the process
of transaction smooth.
• The initial state is the customer to start the session. The diagram
displays both physical and invisible interactions until the
customer gets the cash.
• When you have a laptop and use it, it goes through the process of
being made, tested, and sold. But in the diagram, you can see
that some laptops failed to pass tests and then need testing once
more.
• During tests, the laptop can break down completely. In this case,
it will be taken back to the factory for a remake. Also, when you
use it, accidents usually happen and you need to replace the
parts.
• You must have realized the use of broken arrows. As illustrated
above, they symbolize the flow of an object as it passes from one
point to another.
• This is an example of an activity diagram for login use cases.
Here, a decision node is used for branching to different paths.
The user may end up at one of two outcomes. If s/he enters the
correct login details, the user will follow the course of a
successful login. Otherwise, if he enters the wrong login details,
then a different approach is followed.
• An example of activity diagram for online shopping. Online
customer can browse or search items, view specific item, add it
to shopping cart, view and update shopping cart, checkout. User
can view shopping cart at any time. Checkout is assumed to
include user registration and login.
• This example does not use partitions, most of the actions are
assumed to be fulfilled by online customer.
• Requested order is input parameter of the activity. After order is
accepted and all required information is filled in, payment is
accepted and order is shipped. Note, that this business flow
allows order shipment before invoice is sent or payment is
confirmed.