Site Map  Search

OOA Home OOD content UML Corrections book Code object Exercise Solutions oriented Resources tutorial Miscellany textbook

Exercise Solutions (Restricted)

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

Chapter 6



Question 6.3
You are part of a team working on the subject matter model for STREPT – the module registration system mentioned in Section 1.3.3. You have been specifically asked to explore the following requirements:

  • The system must register student details, including at least home-time address and term-time address.
  • The system must register course details, including but not limited to name, course code, credits needed, department responsible and duration in weeks.
  • The system must register the modules that make up a course including, but not limited to, name, description, credits available, duration in weeks and prerequisite modules.
  • The system must register a student’s choice of modules for a course.
  • The system must register faculty and departmental defaults for student, course and module details. For example, the Engineering faculty default for a student’s preferred notification route is email, whereas the Social Science department’s default for the same thing is letter.
  • The system must register specific details concerning a single presentation of a course or module, for example, starting date.
  • The system won’t concern itself with validating modules against courses (invalid combinations, for example). For the initial version(s) of the system, that will be done prior to input to the system, although the system may well take over that role in some future version.
  • The system must route messages to students and keep a record of the message (e.g. library hours during vacation time) and the route to the student (e.g. term-time email).

Using the considerations and criteria from the chapter, what entities would you initially choose? Decide on up to about four attributes, with attribute types for each entity. While you are listing entities and attributes (there’s not much point in doing a diagram at this stage), make notes about any association (or other) relationships you anticipate having in the model.

It may well be that your choices overlap with part of another team member’s work; that’s OK, your team is planning to have a rationalization and consistency pass later. Think of your job here as something of a brainstorming entity choice. (The word entity is being used in the same way as it was in the chapter. If you prefer to say “class”, that’s OK, but you are looking for classifications of “subject matter objects”; you are not planning or inventing software classes.)

  family name : string, forename : string, age : natural number, sex : enum{female, male}, (and in relationship with addresses)

Home Address
  postal address : string, post/zip code : string, email address : string, telephone number : string

Term-Time Address
  postal address : string, post/zip code : string, email address : string, telephone number : string

  [But see below. JD]

  formal name : string, familiar name : string, code : string, URL : string
  [I've noted several likely relationships for course. Were you tempted to have department, etc. as attributes? We don't want to model something twice, so if department is an entity (exhibits identity) then a course's department is best modeled with a relationship. JD]

  formal name : string, code : string, URL : string

  formal name : string, code : string, expansive description : string, credits available : natural number, duration in weeks : natural number, (modules seem to be related to modules, as well as being related to students)

  formal name : string, URL : string

  start date : date, duration in weeks : natural number
  [I couldn't discern any more than these two attributes. That's OK. There are entities that are characterized more by the identities of the instances they are related to, rather than by the values of their attributes. And with more information, more might appear. Resist too much invention, however; difficult with an exercise where there's no possibility of asking clarifying questions, of course. JD]

  content : string
[I did go back to the domain experts and uncovered a missing requirement about bandwidth, which eventually led to a maximum length property for the content attribute. JD]

  medium : enum{email, letter, fax, call, SMS}, date sent : date (and a relationship to an address)

[Transmission appeared on my initial list with a question mark against it. It was when I started to do the attributes of message that I became convinced that it was an entity. Originally I called it "Route", but everyone got confused because, in other campus systems, much is made of "Study Route". JD]

[Address is often an interesting one. It is often modeled as an attribute at this stage, as it often exhibits no identity, i.e. no individuality. However, most object-oriented designs eventually take the purely technical decision to implement address as an object, later. Here, address does seem to exhibit identity and is, we suspect, going to be in a many-to-one relationship with student. So I've modeled it here as an entity. And the address entities have been given postal address attributes with type string (or text if you prefer); telephone number and email address are shown as strings as well. Personally, I think analysts have already wasted too much time attempting to define address, telephone number and email. Unless a situation throws up something unique, I use the types postal address, telephone number and email. If I want/need to insult my designers, I include a note saying that they should probably be objects in the implementation. JD]

[There is clearly something in common between home- and term-time addresses. What will we do about that? If you know about it, you might be tempted to say, "generalize!" I don't think that's necessary. As you are going to find out if you haven't reached the next chapter yet, I prefer any use of generalization to strongly justify itself. And it's not necessary here. My next decision was to change to one Address entity and two relationships. We are anticipating, somewhat, an exercise coming up shortly and also an exercise in the next chapter. JD]

[I've been careful with names. I hope you have. For example, there were many places where I could have named an attribute "name"; but I've tried to do better than that. JD]

[As noted in the book, I've used the term "natural number". You may prefer positive integer. (I don't like "int" at this stage however; although it's minor (obsessional) point. JD]

[As noted in the book, units are vexatious. One can add attribute properties to the model repository (data dictionary) for "default unit". One can use the name, as I've done; respecting the requirements, being precise and allowing the designers to be cleverer if they deem it appropriate. If handling units was a critical requirement, then I would figure units into the model, probably using an analysis patter (as it's a commonly recurring modeling problem). JD]



Question 6.5
Think of at least two ways of defining the type of the attribute eyesight. It was an attribute of Witness in the text.

20/20 numeric style or, more likely, enum {average, good, short, long, astigmatic, blind, unknown}


Question 6.6
Explain the difference between the interpretation (conventional) of a multiplicity of 1.. and the interpretation (this book’s and many others’) of aggregation’s distinguishing feature.

When developers demand a more useful definition of aggregation than is often given (even in the UML itself), we often use "existence-dependence". Let us assume that we do choose to use that as our bottom-line distinguishing characteristic of aggregation.

  • A diamond at one end of an aggregation relationship means that the instances (not class) at the other end of an instance of this aggregation relationship would not exist were they not engaged in that role (of helping "form" the instance at the diamond end). Aggregation says something about the characterizers (and the characterized).
  • A multiplicity with a minimum of one (1..), on the other hand, indicates that the instance at the other end would not be a valid instance should the associate at the 1.. end not be there. Mandatory multiplicity (1..) says something about the characterized.


I have assumed, from the multiplicity maxima, that the crime instance in question is somehow active, rather than historical and so have not used the role name "investigates" or "investigated" assuming "investigating" instead. I have further assumed that the potentially several officers associated with a crime are the officers who have been assigned to the crime (rather than, say, credited with solving it).

Question 6.8
Write a few paragraphs on why the many-to-many relationship is problematical and the ways in which we can try to avoid it.

[All the information was in the text, so this is test of recollection and understanding. The salient points were:

  • Difficult to implement
  • Frequently it's indicative of model sloppiness masking better modeling arrangements, such as a missing entity "in the middle" or a necessary pair of associations. The latter possibility often also deals with another troublesome model denizen -- the bidirectional relationship -- when a sloppy, bidirectional many-to-many is replaced with a pair of one-to-many associations in complementary directions.
  • Probably relevant would be a comment on the historical genesis of this problem: relational database developers (reasonably) not needing to care about relationships as much as object-oriented designers and programmers need to care.


Question 6.9
The text gave an example of resolving an apparent many-to-many association between Patient and Doctor. Here, in Figure 6.46,

we would seem to have a similar problem. How do we simplify this one in a similar fashion? (Hint one: the solution isn’t quite so easy as adding Visit to Patient and Doctor in Figure 6.28. Hint two: once isn’t enough.)

Is there anything missing? Is a customer directly associated with products or is something else involved? A customer places orders for products. Would Order exhibit identity? Would it be appropriate to model Order as an entity? Yes and yes.

However, we are still left with a many-to-many relationships. Is there some good and correct entity still missing? We could not adequately characterize an order with attributes that could be straightforwardly measured. There will be an open number of items being ordered. The order needs to be in a one-to-many association relationship with what is traditionally called an Order Line in a sales order processing system. With Order and Order Line present we have a simpler, a more easily implementable model, and an entirely natural model.

[There's one more consideration. I've used the pair of role names "orders" and "ordered by". The text advised against automatically inverting the grammar of the role name at one end of an association, in order to obtain the role name at the other end. The suggestion was think carefully about whether there really is a perception, a characterization; and if convinced that there was, to try to come up with a better name. Well I was convinced that there would be characterization in that direction in a typical sales order, I tried some alternative, all sounded artificial and unnatural; so I decided that this was one of those occasions when "xyzed by" was allowed as the most appropriate and correct name. If you have a better pair of names, however, all suggestions are welcome. JD]


Modeling and diagrams

Question 6.11
Think about the association and aggregation relationships that you would choose to model between the entities from your earlier answer to Exercise 6.3. Depict your choices in a UML structure diagram. Include high-quality role names at one or both ends and include multiplicities at both ends. Be clear as to how you intend to decide on association versus aggregation.

Diagram 1

Diagram 2

With existence-dependence as our bottom-line distinction between aggregation and association, I have no aggregation relationships; although I could still be persuaded that Faculty and Department were in an aggregation relationship, like this:

[As usual, when one starts modeling associations, inadequacies in the first-draft entity names surface. You'll see that several names have been sharpened. JD]

[There is not enough detail available to make definitive decisions about the exact nature of the roles. I have put in an illustrative and reasonable mixture of single-ended and double-ended arrangements. Lecturers could add more contextual description added and ask for more definitive decisions on the roles. JD]

[One early draft followed the text a little too closely and had Department -> Faculty -> Course -> Module. This wasn't totally accurate and left at least one many-to-many, like this:

It is also necessary to choose between Department -> Course Presentation -> Module Presentation (thus implying Department -> Module Presentation) or Department -> Module Presentation -> Course Presentation (thus implying Department -> Course Presentation). Asking whether a Department is characterized more by the courses it's responsible for or by the modules it's responsible for, led me to the arrangement given first.

Other many-to-many associations remain. I think the book's point about correct granularity certainly applies here. Between Enrolled Student and Course Presentation, for example, I would probably end up quite happy to have an "Enrollment" or "Choice" entity between them. As ever, it's better to find something reasonable at analysis time than to have an arbitrary design-time invention of an intersection object. JD]

[Perhaps one of the most challenging things to model is the default student, default module and default course. It seems hopelessly inelegant to store a whole heap of attributes in the department or the faculty.

Would there be entity sets like Default Student, Default Course, etc., distinct from the ordinary Student, Course, etc., associated with the Faculty and Departments, and whose attributes corresponded to Student, Course, etc. attributes for which defaults were held? Firstly one has to worry about the volatility of the set of attributes that would have default values. Secondly one starts to worry about pairs of entity boxes with common attributes subsets where the commonality certainly isn't just coincidence; one wants to do some factoring.

One then asks oneself if there isn't just an instance of the Student etc. entity that is conceptual rather than physical, and that holds the values of those attributes for which the Departments, etc. has defaults. The problem with doing that is the big difference between the hundreds of "real" instances and the handful of "fake" instances. We wouldn't want the "fake" instances to appear in any future reports, for example. In an early version, I tried using an {XOR} constraint, like this:

but that's going to become unworkable as soon as there is more than one "normal" relationship. It would be necessary to change over to putting (OCL) constraints all over the place in order to stop the fake instances participating in associations which could form the basis of reports, etc.

My preferred solution so far, is to use the supertypes and subtypes you saw. There are no differences in attributes between Default Student and Enrolled Student, for example, since any attribute might have default values at some point or other; so all the Student attributes would be defined in the Student supertype. The differentiation is in the relationships. Only the "real students" participate in the "normal "relationships.

If we were to choose not to use subtypes, preferring a distinguished 1..1 "default" association with another instance of Student, etc., it might be an idea to draw more attention to the default instance and actually make it one of those rare times when we represent an instance iconically,with a box, in an analysis model, like this:

Is the Notional Student really there in the subject matter? Or is it an invention too far? I think they are there: a department has a notion of a default student; and it's a real notion; and it's just like the real thing, except it isn't the real thing. We can't complain that a Notional Student doesn't have a physical presence, because neither does a Department, nor a Debt nor a Risk, etc.

Should a supertype be generalized out of the Faculty and the Department? Some design disciplines (e.g. structured design, 1970s, Stevens, Myers, Constantine) taught us to consider removing lattice associations like those between the Faculty and the Department, and the Student, Module and Course; but I would say we shouldn't. In the analysis the needs of diagram layout shouldn't encourage such artificiality as a "Default Holder". And in the design I would want evidence of enough common implementation worth factoring out, such that the factoring benefits clearly outweighed the fragile superclass drawbacks.

While my initial brainstorm was one big (whiteboard and Post-it™) diagram, it's size and topology quickly dictated that it become at least two diagrams.

This would be (another) example of the generalization relationships offering less direct implementation clues than, say, association or aggregation. Although it seems a reasonably elegant model of the subject matter, it probably doesn't suggest a reasonable implementation. It's unlikely that one would complicate a Student class to the degree that subclassing it would, just to get some default values for it's attributes. I'm certain that my designers will invent much more sensible and clever ways to achieve the result. JD]

[If you used "Course Presentation" and "Module Presentation" in a similar way to mine, you may have generalized a Presentation supertype. I probably will as well, but I think I'll leave it noted as a probably future enhancement until I'm a bit more certain and a couple of my peers have helped me review it. JD]

Question 6.12
In ALICE, the restaurant example we worked through earlier, you may have wondered about the restriction that a booking could only be for a single table. Extend the model to indicate that a booking might occupy more than one table.

There are several possibilities. The first thing I (and several students) considered was changing over to booking virtual tables that were made up of physical tables. There are all sorts of fascinating possibilities, such as these beginnings:

but this kind of thing seems to fail on at least two analysis counts -- it's not necessary and it doesn't fit with people's natural perception -- and on one (unfair and only guessed at) count -- it's probably unworkable. Let me explain the perception objection in more detail. In the book I mentioned my test of imagining myself leading the training session where I'm teaching the restaurant staff to use the new system, and imagining how I would explain any interface manifestations of such a model. Whether I couch it in terms of super tables or virtual tables, all I can picture are blank and puzzled looks. While the designers may well decide at some future point to use the notion of a super table or a virtual table, I don't feel that such a thing should be in the subject matter model.

When I talked to some subject matter experts, their picture was that if you had a booking you wanted to accommodate, and it was too big for any available tables, you would allocate it to a group of tables. Their mental picture was that "The Jones' booking for 2100 next Thursday is allocated to tables 3 and 4". "Ah," said I, "Don't you have to have some special way of referring to such a group?" (You have virtual tables really, don't you?) "No," I was told, "you can pick any constituent table's number and use that to refer to the group. No-one's idiot enough to get confused if told to take the Borsch to table 3, and find that table 3 is pushed up next to table 4."

So my next inclination is to change from a booking being accepted by just one table, to a booking potentially being accepted by more than one table.

We take a booking instance and find that most of the time it's allocated to one table; but sometimes we find that an accepted booking instance is allocated to more than one table instance. (Notice how you must reason on an instance basis; not a set/class basis.) And we take a table instance, wondering how it will be spending the next few hours or days, and we continue to see it in association with several bookings that it has accepted. We (analysts, not object instances) could follow a table to an accepted booking and follow that booking back to its table instance(s) to see if it was a large booking and which other table instances, if any, were involved.

[Supplementary exercise: why did I make the qualification, "We (analysts, not object instances) ..." just now? JD]

Have we got a bidirectional many-to-many association? I think we have. There is mutual characterization, which was the book's suggested test.

[If we picture the links among some sample instances (those tuples that are now back at the heart of the semantics of associations, i.e. links are lines, not branches and not starbursts) we might have this:

And if we picture that implemented for full bidirectionality with typical collection objects in a typical language (i.e. typical language link implementations can branch), we'd have pointers like this:

and if a pointer got lost and the following came to pass:

then the system would be in an incorrect state. JD]

Would we check, and check again, that we hadn't overlooked some valid subject matter element that would simplify away the bidirectional many-to-many? Yes, we would. They are simply too troublesome to get a consensus interpretation in analysis models, and to implement. Have we overlooked something? I considered an allocation but found it too artificial for an analysis model. I tried table group; it's not all that artificial and I nearly went for it; but in the final analysis I found it to a sufficiently unusual way of looking at the subject matter that I didn't go for it in the final analysis.

Question 6.13
The model developed for ALICE – the restaurant example we worked through earlier – didn’t take account of departments. In a large restaurant, the kitchen is divided up into departments. How would you modify the model to include them?

Having investigated whether "Menu Section" was sufficient, wondering whether it inevitably predicted the kitchen department, and coming to the conclusion that it did not, because a dish that was a starter according to the menu could actually be a specialty of the restaurant and thus not prepared in the starters department but in the main department by Anton himself, another association was added between the Dish entity and a Department entity: