0.5.9 Modeling a Web Request With a UML Activity Diagram

Begin With the Interaction You Want to Explain

A web request can involve many technical details.

Your first model should stay focused on the responsibilities already introduced:

  • user chooses a URL;
  • browser creates and sends a request;
  • server processes the request;
  • server returns a response;
  • browser interprets and displays the result.

The purpose of the UML activity diagram is to make that flow and responsibility visible.

Use Browser and Server Partitions

Create two activity partitions:

Activity diagram showing Start, then Interpret URL, then Create request, then Send request.
Start.
  • New
  • Changed
  • Removed

The next step occurs on the server.

Cross to the Server

After the browser sends the request, the activity flow crosses into the Server partition.

The server-side sequence can be modeled as:

Activity diagram showing Receive request, then Process request, then Create response, then Send response.
ReceiveRequest.
  • New
  • Changed
  • Removed

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.

Cross Back to the Browser

After the server sends the response, the flow returns to the Browser lane.

The browser can then:

Activity diagram showing Receive response, then Interpret response, then Display result, then End.
ReceiveResponse.
  • New
  • Changed
  • Removed

This produces a complete round trip.

A Complete Conceptual Flow

The model can be read as:

Activity diagram showing BROWSER CLIENT SERVER, then Start, then Interpret URL, then Create request, then Send request Receive request, then Process request.
BROWSERCLIENTSERVER.
  • New
  • Changed
  • Removed

The exact rendered UML will use activity-diagram notation and partitions rather than plain text.

The meaning should remain this clear.

A Parcheesi Web Example

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:

Activity diagram showing Browser requests game page, then Server processes page request, then Server sends page response, then Browser displays game page.
BrowserRequestsGamePage.
  • New
  • Changed
  • Removed

Keep the scenario subordinate to the networking concept.

Do not add game logic that is unrelated to the request/response flow.

The Diagram Should Show Responsibility, Not Just Order

Without partitions, this sequence:

Activity diagram showing Browser sends request Server receives request, then Server sends response Browser receives response.
BrowserSendsRequestServerReceivesRequest.
  • New
  • Changed
  • Removed

The Internet provides the connectivity between those endpoints.

Keep the Scope Introductory

Do not add concepts that have not yet been introduced, such as:

  • server-side application architecture;
  • web APIs;
  • authentication protocols;
  • cookies;
  • sessions;
  • asynchronous JavaScript;
  • database access.

Those may be important in other courses.

They are not needed to model the basic web request.

Read the Final Diagram as a Story

A strong diagram should let you say:

If the UML communicates that story clearly, the model is doing its job.