We will be practicing creating and interpreting UML class diagrams for our lab t

We will be practicing creating and interpreting UML class diagrams for our lab this week.
UML class diagrams are an industry standard way of designing object-oriented programs. Being able to efficiently create accurate class diagrams will allow you to easily design large, complex programs. The better your initial design is, the better the final product will be. The goal for this lab is to practice using UML class diagrams enough to recognize all of the different symbols and arrows used.
Construct the lab files by following the instructions below. The check-in for the lab this Friday will be for all parts below. Once you have completed the program, you will submit it for this assignment.
Part 1: UML to Java
For the first half of this lab, you will be implementing an existing UML class diagram as a set of Java program files.
Create a Java class file for the King, Knight, Weapon, and Material classes shown in the UML class diagram below. Your classes must implement everything shown in the diagram, including all variables with correct access modifiers, methods, and inheritance. Notes about the diagram are provided below.
Diagram Notes
Access ModifiersMake sure you use the correct access modifiers for the variables and methods in this diagram. The symbols for all three modifiers are shown: + for public, – for private, and # for protected.
Method BodiesEvery method in this diagram is either a constructor, an accessor, or a mutator (equipWeapon and reforge are mutators).
The details of how each method should be filled out aren’t provided on UML class diagrams, so in a practical scenario you would need to have separate documentation to keep track of this. For this lab the methods are all relatively simple.
Relationship Between King and KnightThe relationship between King and Knight is association. This is shown using a plain line with no arrow or diamond. A King can have any number of Knights under his command, but each Knight must have one and only one King.
This relationship is useful for keeping track of the purpose of these classes, but it does not have any impact on the code for this lab. In a more fleshed-out project, this relationship would be enforced somewhere else in the code, in the methods of Knight and King or in another class entirely.
Relationship Between Knight and WeaponThe relationship between Knight and Weapon is aggregation. This is shown using a line with an empty/white diamond on the aggregator. A Knight must always have a Weapon (and in this case, no more than one at a time). In contrast, a Weapon can be wielded by a maximum of one Knight at a time, but it might also be ownerless.
Aggregation relationships demonstrate that one class contains another. In this case, Knight contains Weapon. This is implemented in the code by giving the Knight class a Weapon variable called arms (short for armaments). Since the relationship shown is aggregation, this means a Weapon can exist separate from the Knight class. We can also see this in the multiplicity values; a Weapon can be wielded by 0 or 1 Knights.
Relationship between Weapon and MaterialThe relationship between Weapon and Material is composition. This is shown using a line with a filled/black diamond on the composite class. A weapon must always be made of a material, and (in this program) a material is only ever used to construct one weapon.
Composition relationships are like aggregation relationships in that one class contains another, but they differ in that the contained class cannot exist outside of the container. In the project outlined by this diagram, a Material cannot exist separately from a Weapon. It is created alongside the Weapon, and it is destroyed alongside it as well. Every Material must always belong to exactly one Weapon – no more, no less.
One easily missed detail about this relationship in the diagram above is the getMaterial method of Weapon. It returns a String, the name of the material, instead of the Material object itself. This way the reference to the Material object can’t be accessed or taken outside of the Weapon class (it still must be created outside of the class for the constructor though).
Part 2: Java to UML
For the second half of this lab, you will be documenting an existing Java project as a UML class diagram.
Download and extract the zip file below. Create a UML class diagram containing all of the classes in the zip file. Your diagram must show all details that are in the class files, including all variables, methods, access modifiers, inheritance relationships, and non-inheritance relationships. Notes about the classes are provided below.
You may draw your diagram by hand and submit a picture of it, or you may use any digital drawing software of your choice. You are allowed to use a program that is made specifically for UML diagram creation such as LucidChart (there is a free version available). If you are uncertain whether or not you are allowed to use any given software for this assignment, please send me a message with the name of the software you would like to use and I will see if it is acceptable.
This project models board games and card games. The classes include: BoardGame.java, CardGame.java, Player.java, CardPlayer.java, Card.java, CardDeck.java, Die.java, and Color.java.
Class files for this part:
You can extract a zip file on Windows by right clicking the zip file and selecting “Extract All”, then selecting a destination for the unzipped files (the default location is in a folder with the same name as the zip file, in the same location as the zip file).
You can extract a zip file on Mac just by double clicking it. The unzipped file will be in the same location that the zipped file was.
Notes about the Classes
The Inheritance RelationshipsThis project gives us a sneak peek at a future topic this semester: class inheritance. The CardGame class inherits from the BoardGame class, and the CardPlayer class inherits from the Player class. In the code, you can see this by the use of the “extends” keyword in the class headers.
In UML diagrams, standard inheritance relationships are shown using an empty/white arrow pointing to the “parent” class. These connections should not have role descriptions or multiplicity values. Other than this new type of arrow, nothing else needs to be changed about the classes, and they can all still have other relationships to them as normal. Here is an example of what those connections should look like in your diagram (your diagram should not have the text hint in the middle).
We will revisit this syntax when we cover inheritance relationships.
Static and Constant VariablesUML class diagrams are created to show the relationships between classes in an object-oriented program. Static and constant fields are separate from objects created from the classes, so they are often left out of class diagrams. Please include all static fields and constants for this assignment.
Since these elements are often excluded, the syntax for how to specify them isn’t always consistent. You may write your static and constant class members the same way that you would write non-static and non-constant members, or you may use the following syntax.
For static members: underline them.
For constants: write them the same as variables, but include the value of the constants. For example “+PI: double = 3.14”.
The Non-Inheritance RelationshipsMost of the relationships in this project are either aggregation or composition. The difference between the two is whether the class that is contained in the other continues to exist when the container class is destroyed.
It is best to analyze the code for this, but you can also try to apply some common sense logic. A few examples include:
Does a card continue to exist when its deck is destroyed?
Do the Player objects continue to exist when the BoardGame object is destroyed? (Don’t think of the Player objects as people – they are just collections of board game information, like the player’s score. Does it make sense for a player to take their score from one game and keep it when playing a different one?)
If a card is held by a Player, does it still exist even if that Player is no longer part of the game?
ArrayList in CardPlayerThe CardPlayer class contains an ArrayList as one of its variables. We haven’t covered ArrayLists in-depth yet, but in simple terms they are arrays that can change length as needed whenever new items are added. In your diagram, the type of the CardPlayer’s hand variable needs to use the full type shown: “ArrayList“.
This is the minimum amount of progress that is required for this week’s check-in. Please make your check-in post with your completed diagram for part 2. Please remember to make the check-in post before the deadline. If no revisions are necessary with your check-in post, then that means you are done with this lab and ready to submit.
Submission
For this lab you will be submitting 5 files:
The four class files you created for part 1 of the lab
The picture or screenshot of your UML class diagram you created for part 2 of the lab
Submit your files by clicking “Start Assignment” at the top of the page and then selecting your screenshot and class files for submission. You can submit all files by selecting “Add Another File” in the submission box. Please submit all files individually; this assignment will NOT accept a zip file or an Eclipse project.
Rubric
CriteriaRatingsPts
This criterion is linked to a Learning OutcomePart 1 Class MembersFor full points, the variable names and types, and the method names, parameter names and types, and return types, as well as all access modifier symbols must be correct for all 5 classes.