Unit 5 Flashcards
Why do object modellers concentrate on nouns?
The nouns represent the things in the domain being modelled, and things are more stable than actions, which are expressed as verbs.
What are the main criteria for filtering a list of nouns in order to remove inappropriate ones and settle upon a more suitable set of candidate classes?
There are three basic criteria that can be applied as follows:
- redundancy (the use of words or data that could be omitted without loss of meaning or function; repetition or superfluity of information).;
- not important or independent enough, such as an attribute of another class rather than a class in its own right;
- lack of relevance to the problem domain; either beyond the scope of the desired system, or part of the language used for modelling.
In addition to these basic criteria, we should pay particular attention to events. Will an instance of that kind of event have state, behaviour and identity that are significant in the problem domain? A loan of a book from a friend might not be worth modelling, for example, but a bank loan is significant: it must be paid back and it attracts interest so that you pay back more than the original loan. In all cases, you should clear up any ambiguity with a domain expert or the users themselves.
Explain why object diagrams cannot form the basis for a software specification.
Object diagrams represent particular states of the system at particular moments in time,
whereas a specification must describe all valid states of the system, at all possible times.
In a windowing system, a window may be converted to an icon, and back to a full window. What operations can be performed on full windows but not on iconised windows? Would a model containing the classes Icon and FullWindow be able to capture the distinction adequately?
Scrolling and maximising can be done on full windows but not on iconised ones. It will be difficult to model the distinction between a full window and its iconised version adequately by using two different classes, since an object (in this case, the window) cannot dynamically change its class. A solution to this problem might be to have a single class in which an attribute makes the distinction.
In connection with rooms, the hotel manager’s vocabulary includes the words ‘occupied’ and ‘free’. How might such words be represented in a class diagram?
Two ways come immediately to mind:
- as an attribute of the Room class;
- as an association between the Room and Guest classes.
Either is quite acceptable as a way of recording the information.
In your model in part (b), will your decision about occupancy change if you have to include the fact that a room must be cleaned before the next guest occupies it?
(b) Question
In connection with rooms, the hotel manager’s vocabulary includes the words ‘occupied’ and ‘free’. How might such words be represented in a class diagram?
(b) Answer
Two ways come immediately to mind:
- as an** attribute** of the Room class;
- as an association between the Room and Guest classes.
No. The cleaning of a room certainly depends upon whether or not it is occupied, but not on how we choose to model occupancy. (You would include this requirement relating to cleaning in a dynamic model, such as a sequence diagram or state diagram. This will be discussed in a later unit.)
Does invoking an operation on an instance of a class always change the object’s state?
No. Not all operations are intended to change an object’s state. For example, you might provide an operation on the Guest class to respond with the address for any particular instance (object) of that class.
What does an attribute of a class represent?
An attribute represents a particular property (a named value) of the class that each instance of that class will have. Whatever else the attributes of a class are used for, at any one time they collectively define the state of an instance of the class.
Does a multiplicity of 1 indicate that there can be no change in the object to which the multiplicity relates?
No. It merely means that at any one time there will be exactly one object at that end of the relationship. The attributes, or even the identity, of this object may change over time.
If an airline system models flights and pilots, and each flight needs two pilots, would you use a multiplicity of 2?
Probably not. There are probably times during the life of a Flight object when fewer than two pilots are allocated, such as when the flight has been scheduled but crew details have not yet been settled.
Suppose that each person has a number of wardrobes, and each wardrobe contains an even number of shoes. How would you model the evenness of the shoes?
You might use a multiplicity on the association between the classes Wardrobe and Shoe, indicating that valid values were 0, 2, 4, 6, 8 and so on up to some reasonable limit.
Alternatively, you could say that a Wardrobe contains an arbitrary number of instances of a class called ShoePair, where each ShoePair contains one left shoe and one right shoe.
This approach generalises more easily to situations where the groups are not homogeneous. For example, a table setting contains one knife, one fork and one spoon.
If a model contains role names, do you also need to use association names?
No, but it is sometimes convenient to have a name for the association as a whole. For example, you might focus on what is meant by works for, rather than the need to consider both the role employer and the role employee (at the same time).
What is a navigation expression used for?
It provides a way of naming another object or its attributes relative to a starting object, by referring to intermediate role names.
What is a recursive association?
A recursive association is an association where both ends terminate at the same class.
When considering attributes, what is the effect of moving from a conceptual model to a specification model?
The conceptual model records attributes of classes that will be familiar to a domain expert. For example, a hotel manager will be familiar with the daily rate for a room and whether or not it is occupied.
In the specification model, the developer must consider the representation of attributes within a software system. For instance, daily rates for rooms involve money, and you can use a true/false (Boolean) expression to represent the occupancy of rooms.
In a multi-user operating system, users are allocated passwords. Draw a fragment of a class model to represent this association. Bear in mind that you do not want to be able to identify the corresponding user for a given password. What does this tell you about the representation of the association?
Users will want to ‘know about’ their passwords, not the other way round. Figure 23 shows that each instance of the class User will have a collection of references to the appropriate Password objects.
What is a qualified association?
A qualified association is an association at one end of which there is a qualifier, consisting of one or more attributes. The values of the attributes (taken together) uniquely identify the objects in the class at the other end of the association.
Suppose that, in the invoices example shown in Figure 18, invoices have unique numerical identifiers known as invoice numbers. How would you capture this information in a class diagram?
You could use a qualified association whose attribute is named invoiceNo in a manner similar to that shown in Figure 25, by attaching the qualifier to the Customer end of the association between Customer and Invoice.
Look again at Figure 30. Will an instance of Account support the addInterest operation?
No; addInterest is not part of the interface for the class Account. It is, however, part of the interface for the class SavingsAccount, which is a specialisation of the class Account. Objects of the superclass cannot replace objects of any subclass.
Figure 24 shows the class Account with an attribute, called accountNo. Write an appropriate invariant that limits the values of this attribute to a number composed of a 3-digit branch code followed by a 7-digit identifier.
We are not told anything about the range of either branch codes or identifiers, but we do know that a valid account number has 10 digits as follows:
{accountNo is a 10-digit number, with a 3-digit number at the beginning for the branch code, followed by a 7-digit identifier}
How would you model the constraint in a hotel system that every bill must be paid with either a cheque or a credit card? How would you extend your model if cash wereto be allowed?
Figure 47 shows one way is to use the {xor} notation. However, this can relate only two associations. If you need to express a three-way constraint in order to allow for the addition of cash payments, for example, you will have to abandon the graphical notation of {xor}, and resort to writing a textual constraint. Alternatively, you could use generalisation to create an abstract Payment class with an association to the class Bill, following the examples in Section 4 of this unit. Then each payment method, such as cheque or credit card or cash, would become a specialisation of the parent, abstract class Payment.
The model in Figure 51 expresses the fact that a train must be associated with two employees: a driver and a guard. By considering the loop of associations, identify a problem with the model, and suggest a constraint that solves the problem.
You need to capture the fact that a given employee cannot be both the driver and the guard for a particular train. You can formulate this as a constraint on any class round the loop. For example, the following constraint can be located in the class Train:
- *context Train inv:
self. driver <> self.guard**
The model in Figure 52 shows that a person takes out a mortgage to buy a house. A person can take out one or more mortgages. But a person must offer that house as security against a given mortgage. By considering the loop of associations, identify a problem with the model, and suggest a suitable constraint using OCL.
The model would allow one person to have a mortgage that uses someone else’s home as security. You need to capture the fact that a house’s owner is the same person who offered that house as security for a given mortgage. When there are multiplicities in the loop that can be greater than one, you need to take care in writing the invariant. In one direction around the loop, an individual house has only one owner. In the opposite direction, each house is security for only one mortgage, and that mortgage is associated with only one owner. This makes it easy to place an appropriate constraint on either the House class or the Mortgage class. For the House class, we could write:
context House inv:
self.owner = self.mortgage.person
Similarly, for the Mortgage class, we could write:
context House inv:
self.person = self.security.owner
However, expressing an equivalent constraint on the class Person is more problematic because you would have to find the intersection of two sets: the dwellings owned by a particular person and the mortgages taken out by the same person. We suggest that you use English to formulate a suitable constraint in such circumstances. You could place the constraint inside a note and attach it to the appropriate class.
