0.6 Parcheesi Assignment

Overview
1.Overview
A Structured Game Data

Structured data repeats the same kinds of fields from record to record. UML class diagrams can describe that reusable structure, while object diagrams can show particular records and their current values.

You will first use a small Parcheesi high-score table as a concrete bridge between rows of structured data, classes, and objects. Then you will apply the same idea to the larger Parcheesi game model by creating a class diagram containing Game, Player, Piece, and Turn.

B User Story

As a Parcheesi player, I want game information organized into consistent types and relationships so that the same structure can represent many games, players, pieces, and turns.

C Acceptance Criteria
  • Recognize a row of structured data as one record containing consistent fields
  • Connect record fields to class attributes and data types
  • Distinguish a class definition from a particular object instance
  • Create a Violet class diagram containing Game, Player, Piece, and Turn
  • Include the required attributes and relationships
  • Use multiplicity to communicate one-to-many relationships where required
  • Keep the model small and focused on the supplied Parcheesi structure
  • Submit the Violet diagram through the Feedback System and submit the Feedback System result URL to Canvas
D Task List
  • Read a Structured High-Score Table
  • Connect a Record to a Class
  • Connect Rows to Object Instances
  • Transfer the Pattern to the Game Model
  • Plan the Four Classes
  • Create the Parcheesi Class Diagram in Violet
  • Compare Structured Data and UML
  • Save, Submit, and Revise the Diagram

A spreadsheet row, an object instance, and a class definition are not the same thing. The useful connection is that repeated records often follow the same reusable structure.

2.Read a Structured High-Score Table
A Read the five records
Reference table
PlayerName | Wins | Score
Mia | 12 | 840
Jamal | 10 | 760
Elena | 9 | 710
Noah | 8 | 675
Priya | 7 | 630
B Identify records and fields
  • Each row represents one record
  • Each column represents a field that every record follows
  • The values differ from row to row, but the field structure stays consistent

The values do not repeat, but the shape of the information does: every record has PlayerName, Wins, and Score.

3.Connect a Record to a Class
A Read the HighScore class
B Match each column to an attribute
Reference table
Table field | Class attribute
PlayerName | PlayerName : string
Wins | Wins : int
Score | Score : int

The class does not say Mia or 840 because those are particular values. It describes the kind and type of information a HighScore record can contain.

4.Connect Rows to Object Instances
A Read one record as an object
B Add collection context

A parent object can represent the collection that contains the records.

C Compare the three views
  • Table: many records in rows
  • Class diagram: reusable record structure
  • Object diagram: particular records and current values

The class is not another row in the table. The class describes the structure that many record objects can follow.

5.Transfer the Pattern to the Game Model
A Read the first two classes
B Read the two classes you will add
C Identify the shift in scale

The high-score example described one repeated record type. The game model uses several related types because a complete game contains different kinds of information.

6.Plan the Four Classes
A Use these class definitions
Reference table
Class | Required attributes
Game | GameId : int
Player | PlayerId : intName : string
Piece | Number : int
Turn | TurnNumber : int
B Use these relationships
  • Game has Player — one Game can have many Players
  • Player controls Piece — one Player controls four Pieces
  • Game records Turn — one Game can record many Turns
  • Player takes Turn — one Player can take many Turns

You do not draw four Piece classes or many Turn classes. One reusable class represents the type; multiplicity describes how many instances may participate in the relationship.

7.Create the Parcheesi Class Diagram in Violet
A Create the four classes
1 Create Game with GameId : int
2 Create Player with PlayerId : int and Name : string
3 Create Piece with Number : int
4 Create Turn with TurnNumber : int
B Use this partial model as a scaffold
C Add the remaining relationships
1 Add Game records Turn
2 Show multiplicity 1 at Game and * at Turn
3 Add Player takes Turn
4 Show multiplicity 1 at Player and * at Turn
D Check Your Work
  • Exactly four classes are present: Game, Player, Piece, Turn
  • Every required attribute and data type is present
  • Game → Player is labeled has with 1-to-many multiplicity
  • Player → Piece is labeled controls with 1-to-4 multiplicity
  • Game → Turn is labeled records with 1-to-many multiplicity
  • Player → Turn is labeled takes with 1-to-many multiplicity
  • No object values, high-score records, or extra classes appear in the submitted class diagram
8.Compare Structured Data and UML
A Compare what each representation emphasizes
Reference table
Representation | Main emphasis
Spreadsheet/table | Rows of structured records and their field values
Object diagram | Particular instances, values, and object relationships
UML class diagram | Reusable types, attributes, data types, relationships, and multiplicity
ERD | Structured-data entities, attributes, identifiers, and relationships
B State what your Parcheesi class diagram communicates

Your finished diagram should communicate a reusable structure that could describe many different games. It should not depend on one player's current name, one current score, or one current turn value.

You connected repeated structured records to reusable class definitions, distinguished classes from object instances, and created a Parcheesi class model containing Game, Player, Piece, and Turn.

9.Save, Submit, and Revise the Diagram

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