Exercise Solutions (Unrestricted)

Chapters 1 2 3 4 5 6 7 8 9 11 12

Chapter 6

Abstraction

Question 6.1
Consider a music player such as a CD, MD or MP3 player. Consider the random or shuffle play function that they often provide. As an exercise in abstraction, how would you describe the meaning of shuffle, in words (after the next chapter, you can try it as an activity diagram).

The temptation is to say pick a track at random. But that won’t do: some tracks wouldn’t get played and some tracks would get played more than once. What you want to do is pick at random an as yet unplayed track from the tracklist, play it and mark it as played. When all the tracks are discovered to be marked as played, clear all the marks.

Question 6.2
The text mentioned (page 103) that one shouldn’t confuse the one instance you can easily see for the set that it is an instance of. The example question was whether Perpetrator was an entity set, or whether it was a particular instance of a Suspect entity set that the model would be better off having. How would you answer that question?

We would first check that the names "Perpetrator" and "Suspect" were good names, otherwise the following test wouldn't work. Good names would be complete, accurate, honest, colorful and reasonably concise.

We only need to do what we would usually do when considering the classification of entity instances into entity sets: ask ourselves what the characterizing properties are. What would be the characterizing properties of a Perpetrator entity set? What would be the characterizing properties of a Suspect entity set? Would one be a proper subset of the other? Would the fact that some particular instance was a "perpetrator" instance naturally and adequately be modeled by its particular values for Suspect characteristics? Or would there be no characteristics of Suspect that weren't also Perpetrator characteristics?

Question 6.4
(Moderately difficult) If you work in, or know something about, a subject matter like the following, list the entities you think might be relevant to a typical piece of software that concerned itself with that subject matter?

• weather reporting and forecasting
  Forecast, Observation, Front, Cline, Station, Satellite, Cell, ...
• fingerprint matching
  Surface, Developer, Lifter Tape, Officer, Location, Date and Time, Feature, Point of Similarity, ...
• radar operator training screen simulator
  Beam, Obstruction, Reflection, Failure, ...
• congestion charging
  (Congestion charging is where, as you enter the center of London for example, your vehicle’s number plate or “license plate” is read by a camera and those who have not paid their congestion charge by the end of the day, at a newsagent shop say, are sent a notice of a penalty fine.)
  Exemption, Observation, Fine, Letter, Conviction, ...

Question 6.7
Figure 6.25 had an example of an association relationship named with a single identifier “in the middle”. The advice that accompanied it was to use role names at the association ends instead. Do that, recording any assumptions you make.

I assumed that a crime would potentially have several officers assigned to it, but that if the model doesn't separate out crimes that are no longer under active investigation, a crime might have no officers assigned to it. I assumed that if an officer is active in some investigation at some particular point in time, the officer will be investingating one crime.

[As per the book's observations and recommendations, I have named the "moment of time" relationships with a present participle. JD]

Question 6.10
In the UML appendix (Appendix C) there is a section on generalization sets. We haven’t covered them in the main text because they are not really object-oriented. However, the three classifications illustrated by Figure C.38, on page 496, give us interesting things to try to model. How did we, and how would you model those classifications?

[The first printing had an error. The reference there was to Figure C.40 which wasn't even about generalization sets! JD]

Our model used menu sections for modeling whether a dish was considered to be a starter, a main or a dessert course. What would we use for the other two classification schemes of "spicyness" and "morality"? "Course" was modeled via a menu section entity because of the open-ended nature of menu sections. What one restaurant calls a starter, another might call an entrée, and so forth. With "spiciness" and "morality", it would seem reasonable to assert a fixed number of possibilities, and thus to be able to use dish attributes with enumerated values: {spiced, bland} and {meaty, fishy, vegetarian}, for example.