0.4 Parcheesi Assignment

Overview

Players, Pawns, and Storage

In the previous Parcheesi assignment, object diagrams represented particular game objects and activity diagrams represented what happened during a turn. In this assignment, you will add a third UML viewpoint: a class diagram.

A class diagram describes reusable structure. First, you will use Player and Pawn as a fully worked example of how several particular objects can be represented by reusable classes and multiplicity. Then you will transfer that idea to a new part of the game by creating your own small GameBoard–Cell class diagram in Violet. You will finish with a second, very small activity diagram showing game information being saved to persistent storage.

Keep It Small

You are not modeling the entire Parcheesi game. The Player–Pawn class diagram is a worked example. Your own class diagram needs only GameBoard and Cell. The storage activity diagram needs only the few actions required to show information moving from a running game to persistent storage.

Task List

  1. Start With Objects You Already Know
  2. Study the Worked Player–Pawn Class Example
  3. Explore GameBoard and Cell Objects
  4. Plan the GameBoard–Cell Class Model
  5. Create the GameBoard–Cell Class Diagram in Violet
  6. Model Saving Game Information
  7. Compare the Three UML Viewpoints
  8. Save, Submit, and Revise the Diagrams

  1. 1. Start With Objects You Already Know

    User Story — Describe Players and Their Pawns

    As a Parcheesi player, I want the game model to describe players and their pawns so that the same structure can represent different players and game pieces.

    Before introducing class diagrams, start with the kind of UML you already used in Parcheesi 0.2: an object diagram. An object diagram shows particular objects that exist in one specific situation.

    Step 1 — Read one Player object and four Pawn objects

    UML object diagram showing one particular redPlayer object named Avery linked to four particular Pawn objects: redPawn1, redPawn2, redPawn3, and redPawn4. Pawn 1 is not at Start and Pawns 2 through 4 are at Start.
    Object diagram: one particular Player object is linked to four particular Pawn objects.

    Step 2 — Count the actual objects

    1. There is exactly one object named redPlayer
    2. There are four separate Pawn objects: redPawn1, redPawn2, redPawn3, and redPawn4
    3. The one redPlayer object is connected to each of the four Pawn objects
    Objects Show Actual Instances

    The diagram does not need a multiplicity label to tell you there are four pawns. You can count the four actual Pawn objects. This particular game state contains 1 Player object and 4 Pawn objects.

    Step 3 — Notice the object-specific values

    1. redPlayer has the particular Name value Avery
    2. redPawn1 has Number = 1 and IsAtStart = false
    3. The other three pawns each have their own current values
    Object Diagram Question

    An object diagram answers: Which particular objects exist right now, what values do they have, and which objects are linked?

    Go to top

  2. 2. Study the Worked Player–Pawn Class Example

    The previous object diagram showed one particular Player object and four particular Pawn objects. A class diagram compresses that repeated structure into reusable types.

    Step 1 — Read the completed class diagram

    UML class diagram with one Player class and one Pawn class. Player has Name string and Color string. Pawn has Number int and IsAtStart bool. The association shows multiplicity 1 at Player and 4 at Pawn and is labeled controls.
    Class diagram: one reusable Player class is associated with four Pawn instances through the 1-to-4 multiplicity.

    Step 2 — Compare the worked object and class views

    Object diagramClass diagram
    One particular redPlayer : PlayerOne reusable Player class
    Four separate Pawn objects are drawnOne reusable Pawn class is drawn
    Current values such as Name = "Avery"Attribute definitions such as Name : string
    Four actual Player-to-Pawn links are visibleMultiplicity expresses the reusable 1 Player to 4 Pawns pattern
    Worked Example, Not Your Final Diagram

    You do not need to recreate Player–Pawn. Use it as an example of the thinking you will apply to a different pair of classes in the next tasks.

    Important UML Distinction

    Object diagrams show actual instances and actual links. Class diagrams show reusable types and associations. Multiplicity belongs to the class-level association.

    Go to top

  3. 3. Explore GameBoard and Cell Objects

    Now transfer the same idea to another familiar part of Parcheesi. The diagram below shows one particular board object and six particular Cell objects.

    Step 1 — Read the concrete object state

    Object diagram showing one mainBoard object of type GameBoard linked by contains relationships to six Cell objects. mainBoard has Name Main Board. Each Cell has a Number value from 1 through 6 and an IsSafe true or false value.
    Concrete example: one GameBoard object contains six particular Cell objects.

    Step 2 — Identify repeated structure

    1. Find the one mainBoard : GameBoard object
    2. Count the six separate Cell objects
    3. Notice that every Cell object has a Number value
    4. Notice that every Cell object has an IsSafe true/false value
    5. Notice that the board has a contains link to each Cell object

    Step 3 — Separate object values from reusable definitions

    Particular object valueReusable idea to carry forward
    Name = "Main Board"GameBoard needs a text attribute for its name
    Number = 1, 2, and so onCell needs a whole-number attribute
    IsSafe = true/falseCell needs a true/false attribute
    Six actual contains linksA GameBoard can contain many Cell instances
    The Six Cells Are a Concrete Example

    This object diagram shows only the six-cell teaching segment. Your class diagram should describe the reusable relationship, not claim that every possible game board always contains exactly six cells.

    Go to top

  4. 4. Plan the GameBoard–Cell Class Model

    Use the object diagram as evidence, then replace the particular objects and values with reusable class information.

    Step 1 — Plan the GameBoard class

    1. Create a reusable class named GameBoard
    2. Replace the particular value Name = "Main Board" with Name : string

    Step 2 — Plan the Cell class

    1. Create a reusable class named Cell
    2. Replace the particular Number values with Number : int
    3. Replace the particular IsSafe values with IsSafe : bool

    Step 3 — Use multiplicity for the reusable relationship

    The worked Player–Pawn example used an exact multiplicity of 4. For the board model, use * to mean “many.”

    Generic UML class diagram showing one Container related to many Item instances. The Container end has multiplicity 1 and the Item end has multiplicity star.
    The * multiplicity means many instances may participate at that end of an association.
    1. Use relationship label contains
    2. Use multiplicity 1 at the GameBoard end
    3. Use multiplicity * at the Cell end
    What You Have Planned

    You now have all the pieces needed for the class diagram, but you have not been given the finished GameBoard–Cell diagram. Your next task is to assemble those pieces correctly in Violet.

    Go to top

  5. 5. Create the GameBoard–Cell Class Diagram in Violet

    Build the class diagram you planned. This is the main class-diagram artifact for Parcheesi 0.4.

    Step 1 — Create the GameBoard class

    1. Open Violet and create a new class diagram
    2. Add a class named GameBoard
    3. Add Name : string

    Step 2 — Create the Cell class

    1. Add a class named Cell
    2. Add Number : int
    3. Add IsSafe : bool

    Step 3 — Connect the classes

    1. Add one association between GameBoard and Cell
    2. Label the association contains
    3. Show multiplicity 1 at the GameBoard end
    4. Show multiplicity * at the Cell end
    5. Arrange the classes so the relationship and multiplicities are easy to read

    Check Your Work

    • The diagram contains exactly GameBoard and Cell
    • GameBoard contains Name : string
    • Cell contains Number : int and IsSafe : bool
    • The association is labeled contains
    • The association reads as 1 GameBoard contains many Cells
    • The diagram shows reusable classes and data types, not six individual Cell objects or current values
    Compare With the Object Diagram

    The six-cell object diagram was concrete and repetitive on purpose. Your class diagram should be much smaller because one Cell class can describe all of those Cell objects.

    Go to top

  6. 6. Model Saving Game Information

    User Story — Show a Game Being Saved

    As a Parcheesi player, I want the current game information to be saved so that the game state can still exist after the running game closes.

    This second diagram is deliberately much smaller than the class diagram work. Its purpose is to show information moving from a running system to persistent storage.

    Step 1 — Review a generic storage flow

    Generic UML activity diagram showing information existing in a running system, a Save action, writing information to storage, and then ending.
    An activity diagram can show information moving from a running system to persistent storage.

    Step 2 — Start a Parcheesi storage diagram in Violet

    Partial UML activity diagram that starts with Parcheesi game is running, then Player chooses Save, with a note telling the learner to continue with the storage action.
    Use this short scaffold to begin the Parcheesi storage activity diagram.

    Step 3 — Complete the storage flow

    1. Begin with Parcheesi game is running
    2. Add Player chooses Save
    3. Add one action that clearly communicates that the game information is written to persistent storage
    4. Add a clear ending point

    Step 4 — Keep the activity diagram intentionally simple

    You do not need file names, file formats, folders, databases, code, or operating-system details. The only important idea is that the information begins in a running system and is written somewhere that can persist after the running game ends.

    Check Your Work

    • The diagram starts with the game running
    • The player chooses Save
    • The game information is written to persistent storage
    • The flow ends clearly
    • No programming or file-system implementation details are included
    Go to top

  7. 7. Compare the Three UML Viewpoints

    You have now used all three UML forms introduced so far in the course.

    Step 1 — Match each diagram type to its main question

    Diagram Main question Parcheesi example
    Object diagram What particular objects exist now, and how are they related? mainBoard contains cell1 through cell6
    Class diagram What reusable kinds of things exist, what information do they contain, and how are they related? GameBoard contains Name; Cell contains Number and IsSafe; GameBoard contains many Cells
    Activity diagram What happens next? Player chooses Save, then game information is written to storage

    Step 2 — Make sure your two new diagrams answer different questions

    1. Your class diagram should describe reusable structure
    2. Your storage activity diagram should describe a small process
    3. Do not add current object values to the class diagram
    4. Do not add class attributes to the activity diagram
    Checkpoint Summary

    You used Player and Pawn as a worked example of the difference between objects and classes, then created your own GameBoard–Cell class diagram with attributes, data types, an association, and multiplicity. You also created a small activity diagram showing game information moving from a running system to persistent storage.

    Go to top

  8. 8. Save, Submit, and Revise the Diagrams

    Use the same concise submission process you practiced in the previous Parcheesi assignments.

    © 2026 Northcentral Technical College

    Go to top