A normal UML activity diagram can show:
A web interaction introduces another useful question:
Which system performs each action?
For example:
A UML activity diagram can make those responsibilities visible using activity partitions, often called swimlanes.
Imagine two vertical lanes:
Browser Server
------- ------
Actions performed by the browser appear in the Browser lane.
Actions performed by the server appear in the Server lane.
A simplified web interaction might look conceptually like:
Browser Server
------- ------
Start
|
Create request
|
|------------------------>
Receive request
Process request
Create response
<------------------------|
Receive response
|
Display page
|
End
The arrows can cross lane boundaries.
That crossing is useful because it shows information or control moving from one responsible participant to another.
The diagram still represents one overall activity.
The partitions organize responsibility within that activity.
The Browser and Server lanes are not two unrelated diagrams.
They are two participants in one process.
Suppose the action is:
Create web request
That belongs in the Browser lane.
Suppose the action is:
Process requested path
That belongs in the Server lane.
Suppose the action is:
Render returned HTML
That belongs in the Browser lane.
The placement communicates meaning.
If an action is placed in the wrong partition, the diagram tells the reader that the wrong participant is responsible.
A web request crosses from client to server.
A response crosses back.
That can be represented visually:
Browser Server
Send request --------------> Receive request
Receive response <----------- Send response
Those crossings are some of the most informative parts of the model.
They show where responsibility moves between systems.
An action might be:
Send request
The request itself is the information being communicated.
Likewise:
Send response
is an action.
The response is the information being sent.
At this introductory level, the activity diagram focuses primarily on actions and flow rather than trying to model every protocol field inside the message.
A swimlane diagram adds information.
It also adds visual structure.
If every action belongs to the same participant, partitions may not help.
They are especially useful for web interactions because client and server responsibilities are central to the concept.
Imagine a browser visiting a soccer club page.
The Browser lane might contain:
The Server lane might contain:
The same process without lanes can show order.
The lanes add:
Who does each step?
When reading a partitioned activity diagram:
Do not read one complete lane top-to-bottom and then move to the next.
Follow the arrows through the process.
A partition can represent a:
In this module, the most useful partitions are:
Later diagrams may use partitions when other responsibility boundaries matter.
An activity diagram already answers:
What happens next?
Partitions add:
Who is responsible for what happens next?
That makes them a strong fit for modeling a web request and response.