You will, using object-oriented principles, design a set of interrelated classes and document that design with a UML diagram. It’s an Olympian task!
Specifically, you will create and document a UML diagram for organizing people at the Olympics.
Part I: Athletic attributes
The key draw for the Olympics is the Olympic athletes themselves. They are capable of amazing things. But don’t despair, you are too! The first amazing thing you’re going to do in this assignment is to define a class that can be used to store information about the athletes. Before reading ahead, please stop for a moment to think about what information you would need to identify an athlete. That is, what attributes will you need?
Well, at minimum, our Athlete needs a name. Since Athletes come from all over the world, we shouldn’t use terms like “first name” and “last name”, since some cultures put the family name first, and some put the given name first. So, those are the terms we will use. An Athlete has a familyName and a givenName. (We’re making some simplifying assumptions here already! Firstly, we’re assuming that we don’t need any other information, like a middle name or names. And we might get into trouble later if we use these names to identify our athletes. Can you imagine why? Consider that China alone sent 431 athletes to the Olympics in Tokyo.)
Each Athlete, for the purposes of the Olympics, is classified as male or female. That is, each Athlete has a gender. (The discussion of sex vs gender in sport is long and far too complicated to get into here, let alone gender identity more generally. That said, the Tokyo Olympics have seen the first openly transgender athlete, New Zealand weightlifter Laurel Hubbard.)
Each Athlete is at the Olympics representing exactly one delegation. This is usually, but not always, a country – consider the case of the Refugee Olympic Team at the Tokyo Olympics.
Each Athlete is at the Olympics to compete in one or more events. Most athletes compete in only one, but that is not a rule. (JuVaughn Harrison of the USA athletics team, for example, competed in both long jump and high jump at the Tokyo Olympics.) Let’s assume for now that an event is just the name of the event. We’ll make this a bit more complicated later.
So, at minimum, our Athlete needs attributes to represent their family name, given name, gender, delegation, and the event or events in which they compete.
Your task for Part 1 is to draw the UML diagram representing (this first version of) our Athlete class.
Part II: Methods of comparison
Following Part I, we have now defined an Athlete as a list of attributes. (You could add still more characteristics – that is, attributes – to an Athlete: height, weight, weight class, etc. But we’ll leave that as an exercise to the reader for now.) But Athletes aren’t just fascinating because of who they are, it’s also because of what they can do. In object-oriented terms, methods of the Athlete class are exactly what Athletes can do.
So, what can Athletes do at the Olympics? Well, obviously they can do all sorts of things: run, jump, swim, shoot, bike, wrestle, play basketball, etc. But, importantly, not every Athlete can do all of these things. So not all of these things should be methods in the Athlete class. The Athlete class should only contain methods that are applicable to all Athletes. For our purposes, we will say that all Athletes are at the Olympics to compete, they are all required to be drug tested, and they all have to eat. (Obviously.)
Your task for Part 2 is to create a new UML diagram that adds these methods to the Athlete class you created in Part 1. Please name these methods following the common convention that has appeared in your lectures and workbooks so far. Method names should be short (just a few words), descriptive, active (they should be verbs), and be writtenInCamelCase.
Part III: A series of fortunate Events
In parts 1 and 2, we created the Athlete class, which will let us keep track of our Olympic athletes. But there are other ways to look at this same data. Our Athlete class is most useful if we consider the Olympics as a collection of people. One could also look at the Olympics as a series of Events. (Or, as we saw with our Athletes, Athletes compete in Events.) So in Part 3, we’ll create another class to keep track of information related to each event. As before, we’ll call it Event.
Each Event has a name (Men’s Basketball, Women -78kg Judo, etc.), is for men or women (gender), and a list of competitors (who are each Athletes). Each event is either completed or not, and if it is completed, has one or more goldMedalists, silverMedalists, and bronzeMedalists, each of whom is an Athlete. (Do Events need any methods?)
Your task for Part 3 is to create a new UML diagram that represents an Event, and shows how Events are related to Athletes.
The more eagle-eyed among you may notice that this only covers individual Events: There are also team events, which may also be mixed gender. In team events, the individual competitors are not Athletes, but national teams. Consider how you would modify our Events class to model team sports. (NOTE: This does not have to be submitted as part of this assessment! It is only something for you to think about, and to do on your own if you want more practice.
Part 4: It takes an Olympic village
We’ve talked so far about Athletes and the Events they compete in. But there are a lot more people that are needed to make the Olympics a reality! In the final part of this assessment, Part 4, we’re going to talk about some other types of OlympicPerson: Coaches and Referees, specifically.
Here, you’re a bit more on your own. Consider now that you have a parent class OlympicPerson, which has (at least!) 3 subclasses: OlympicAthlete, OlympicCoach, and OlympicReferee. These may have different attributes, different methods, or both. Consider carefully which attributes and methods belong in OlympicPerson – that is, they apply to EVERYONE at the Olympics – and which only apply to SOME people at the Olympics, and so belong in a subclass or subclasses.
Your task for Part 4 is to create a new UML diagram that depicts 4 classes and their relationships: OlympicPerson, OlympicAthlete, OlympicCoach, and OlympicReferee.
EXPERT ANSWER
