A web request can involve many technical details.
Your first model should stay focused on the responsibilities already introduced:
The purpose of the UML activity diagram is to make that flow and responsibility visible.
Create two activity partitions:
The next step occurs on the server.
After the browser sends the request, the activity flow crosses into the Server partition.
The server-side sequence can be modeled as:
You do not need to model the server's internal implementation in detail.
The current purpose is to show the server's responsibility in the request/response exchange.
After the server sends the response, the flow returns to the Browser lane.
The browser can then:
This produces a complete round trip.
The model can be read as:
The exact rendered UML will use activity-diagram notation and partitions rather than plain text.
The meaning should remain this clear.
The Module 0.5 UML assessment uses the Parcheesi scenario.
Imagine a simple web interaction where the browser requests a page that presents information about a Parcheesi game.
The purpose of the diagram is not to design a full online game.
It is to show the web interaction.
For example:
Keep the scenario subordinate to the networking concept.
Do not add game logic that is unrelated to the request/response flow.
Without partitions, this sequence:
The Internet provides the connectivity between those endpoints.
Do not add concepts that have not yet been introduced, such as:
Those may be important in other courses.
They are not needed to model the basic web request.
A strong diagram should let you say:
If the UML communicates that story clearly, the model is doing its job.