The "color" is also shown as a "set of strings" attribute; this is possible in ODL because you have constructors such as Set, List etc. Notice that this question was featured in the E/R chapter, where it was not possible to make a balloon to be a set (hence the statutory statement that "a set of colors is not a suitable attribute type for teams"). If you took this statement to heart, you might have made color to be a separate class and expressed the uniform colors as a relationship; that is fine! Or you could have a color as an enum or as a struct of three reals (with proportions for the red, blue and green percentages!). There are many posible solutions.
Finally, we have chosen a List to denote the players of a team; the reason for this is two-fold: (i) in several sports, the players are ordered and (ii) the captain can be easily indicated by his position on the list, (by just an integer, get it? :-)). You could have instead chosen a Set, in which case, captain would have been a string or something (realize that you cannot have an attribute of type Player; so, you would have to figure out how to enforce the requirement that the captain is one of the players themselves) But that looks shabby, don't you agree? Or you could make captain be a one-one relationship from Team to Player, that too would serve the purpose, though that still doesn't prevent us from naming a non-player as a captain.
Obviously, we cannot enumerate every possible answer! All we look for is to see if your solution satisfies the question's constraints; if so, you are fine! 15 points for every correct interface declaration with 5 more points for identifying any relevant notes.
interface Team
{
attribute string name;
attribute Set<string> colors_of_uniform;
relationship List<Player> members
inverse Player::playsfor;
attribute int captain;
relationship Set<Fan> favorite_team_of
inverse Fan::favorite_teams;
};
interface Player
{
attribute string name;
relationship Team playsfor
inverse Team::members;
relationship Set<Fan> favorite_player_of
inverse Fan::favorite_players;
};
interface Fan
{
attribute string name;
relationship Set<Team> favorite_teams
inverse Team::favorite_team_of;
relationship Set<Player> favorite_players
inverse Player::favorite_player_of;
attribute string favorite_color;
};
Some notes that we still have to write are that a crime can be a felony or a misdemeanor but not both. Similarly, a punishment can be a fine or a jail sentence but not both (this is different from the issue of a fine and a jail sentence being applied to a given felony; a given punishment can be only one of the two). Since the punishment for a misdemeanor is always a fine, you might want to make the arrow entering Fines (from Misdemeanors) a curved one. Similarly, there has to be some punishment for a felony (at least a fine or a jail sentence). There is no way to say "at least" in E/R, so this has to be a note. Notice that two curved arrows entering Fines and Jail Sentences (from Felonies) will not work, since then you are insisting that both of them have to be applied toward the felony.
I added a key for Punishments since it seems useful to have one (even though the question doesn't declare what the key should be). It is wrong to make the dollar amount to be a key for Fines, since the key for a subclass cannot be different from the key for the main class. This means that the dollar amount is also the key for Punishments in general, but this is obviously wrong. Some Punishments do not have dollar amounts, only Fines do.
Notice that you can feel free to move two of the "time" balloons down to Flights since they are part of many-one relationships. We cannot move the "time" ballloon of stopover at to either Flights or Airports because it is an attribute of a many-many relationship.
One of the notes you have to write is that a part can be either composite or monolithic but not both.
