In 0.2 Parcheesi, you showed particular Player and Pawn objects. In 0.3, you used an activity diagram to describe a move. In 0.4, you created a class diagram to describe the information Game, Player, and Pawn objects can contain. This week, you will create a sequence diagram to show communication between the player's client and the game server.
Keep working in the same Violet sequence diagram throughout this assignment. Build it one piece at a time: add the two participants, send a move request, and return the updated board. Your only deliverable is the completed, editable sequence diagram. The checks below help you review it; they do not require separate written answers.
For this simplified turn, assume the player has rolled the die and chosen a pawn. The client sends that information to the server. The server applies the game rule, updates the game state, and returns the updated board for the client to display. Model one successful move.
Open a blank sequence diagram in Violet. You will learn the tools as you add each part of the Parcheesi interaction.
Open Violet UML Diagramming Tool. Choose File > New and select Sequence diagram, or choose Sequence diagram from Violet's opening screen.
A sequence diagram shows which participants communicate and the order of their messages. Read it from top to bottom: a message placed lower in the diagram happens later. Horizontal position separates the participants; it does not show which one acts first.
Locate the diagram tools. Hover over an icon to read its tool name if the label is not visible. You will use the following tools as you build the diagram.
| Tool | What you will use it for |
|---|---|
| Object lifeline | Add a participant and its vertical timeline |
| Activation bar | Show a period when a participant is carrying out an operation |
| Call / Create message | Draw the request from the client to the server |
| Return message | Draw the response from the server to the client |
| Note and Note connector | Explain the local work beside the participant that performs it |
To place an item, select its tool and click in the workspace. To connect items, select the appropriate connection tool and drag from the starting item to the receiving item. To edit a label, open the item's properties and enter its text. In the desktop editor, you can normally open properties by double-clicking the item; if your version uses a context menu, right-click and choose its properties command.
Your diagram needs two participants. Each participant has a name box at the top and a vertical dashed line below it. That line is its lifeline: it lets you follow the participant through the interaction.
Select Object lifeline and click near the upper-left part of the workspace. Open the name box's properties and enter Player Browser / Client. Confirm the change.
The client is the part of the game running in the player's browser. It accepts the player's choice and displays the result returned by the server. This lifeline represents the client software.
Use Object lifeline again to place a second participant to the right of the client. Name it Game Server. Align the two name boxes near the top and leave enough horizontal space for message labels between them.
The server processes the move and maintains the shared game state, such as the positions of the pawns. The client and server are different participants even though they work together on the same turn.
You should have two named lifelines: Player Browser / Client on the left and Game Server on the right. Keep these same two lifelines for the whole diagram. When the server sends its response, it will return to the existing client lifeline.
Start on the player's side. Before the client can request a move, the player needs a die result and a selected pawn.
Select Activation bar and click on the client's dashed lifeline below its name box. The narrow rectangle belongs on the lifeline, not beside it.
An activation bar shows a period during which an operation is in progress. In this model, the client's operation includes sending the move request, waiting for the response, and displaying the result. It can remain in progress while the server does its work.
Select Note and place a note beside the upper part of the client activation. Open its properties and enter these lines:
Roll the die
Choose a pawnUse Note connector to attach the note to the client activation. A note explains something about the diagram; its connector does not represent a message. Here, it records the preparation that happens before the move request.
The client has an activation bar and a note describing the die roll and pawn choice. You have not sent anything to the server yet. Leave room below this preparation for the request and response.
Now add the first message between the two participants. A message has a sender, a receiver, and a label describing the communication.
Select Call / Create message. Start on the client activation bar below the preparation note and drag across to the server's lifeline. Release on the lifeline below the server's name box, not on the name box itself. You are sending a request to a server that already exists.
The message should point from left to right, with its arrowhead at Game Server. Violet may add the receiving activation automatically. If it does not, use Activation bar to place one on the server lifeline at the request's arrival and connect the request to that bar.
Open the message's properties and enter Move request (selected pawn, die result) as its label. Confirm the change.
The label describes what the client sends: which pawn the player selected and the die result for the move. For example, the player might select Pawn2 after rolling 3. Keep the general label in your diagram so the interaction describes a turn without being limited to those particular values.
This is a plain-language message label. You are describing communication, so you do not need to write program code or a method definition.
Follow the solid message arrow. It begins at the client and reaches the server activation. Read it as: “The client asks the server to process a move using the selected pawn and die result.” The arrow shows communication, not a pawn moving across the board.
The server must process the request before it can return the result. Keep this work on the server's side of the diagram.
Add a Note beside the server activation below the incoming request. Enter these lines:
Apply the game rule
Update game stateConnect the note to the server activation using Note connector. The game state is the information describing the game at that moment. Updating it includes recording the pawn's resulting position.
These actions happen inside the server while it processes the request. The note explains them without adding more participants or internal message calls to this first sequence diagram.
The server activation starts when the request arrives. Its note describes applying the rule and updating the game state. Leave space below the request for the server's response so that the order is clear.
Complete the interaction by sending the result back to the same client that made the request.
Select Return message. Below the request, drag from the server activation back to the original client activation. The return should use a dashed line with its arrowhead pointing left toward Player Browser / Client.
Open the return message's properties and label it Updated board. This response carries the result of the server's work. Keep it below the request because the server must receive and process the request before returning the result.
Add a Note beside the client, below the returning Updated board message. Enter Display updated board and connect the note to the client activation.
The server supplies the updated information; the client displays it to the player. Keep the client activation long enough to include receiving the response and displaying the board. The server activation should cover processing the request through sending its response. Use Violet's selection and resize controls as needed to keep the bars and messages aligned.
Your diagram now has a request traveling from the client to the server and a response returning from the server to the client. The notes explain the preparation, server processing, and final display. The interaction ends after the client displays the updated board.
Read your diagram from top to bottom. Follow each message in the direction of its arrowhead and identify which participant sends it and which receives it.
Start with the client's preparation note. Follow the move request to the server, read the server's processing note, and follow Updated board back to the client. Finish with Display updated board. Confirm that your diagram tells this story in that order.
Last week's class-diagram associations described relationships between kinds of objects. This week's message arrows describe communication during an interaction. The position of each message now matters because it helps show when the communication happens.
Save your completed sequence diagram and use the Feedback System to check it, following the same submission process as last week. The sequence diagram is the only work you need to include.
Choose File > Save. Use the base filename Parcheesi 0.5 LastName, replacing LastName with your last name. Keep Violet's sequence-diagram file extension. In the desktop version used for these assignments, the filename ends with .seq.violet.html.
Submit the editable Violet diagram file, not a screenshot. Keep a saved copy so you can reopen it and make corrections.
ZIP the .seq.violet.html file itself without first placing it inside another folder. Use the ZIP filename Parcheesi 0.5 LastName.seq.violet.html.zip and submit it to the Feedback System for this assignment. Include only the completed sequence diagram in the ZIP.
Read the returned feedback. Correct any reported issues in Violet, save the corrected diagram, ZIP it again, and resubmit it. Repeat until the required feedback is resolved.
Submit the resulting Feedback System URL to Canvas as directed by your course. No separate written explanation or additional diagram is required.