January 2011 Edition
Computer Science Department, University of Cape Town
| MIT Notes Home | Edition Home |
| MSc-IT Study Material January 2011 Edition Computer Science Department, University of Cape Town | MIT Notes Home | Edition Home | |
Which of the following entities are likely to be of interest when considering system design from a “logical” point of view, and which from an “implementation” point of view? Which are relevant to all standpoints? Clerk; Screen; Mouse (the input device, not the rodent); File; List; Ledger; Service technician; Database; Customer;
A discussion of this question can be found at the end of this chapter.
Fill in the gaps with an appropriate word or phrase, or select the correct one of the indicated choices:
A class encapsulates the behaviour and properties of a number of [__________]. The members of a class are also referred to as [__________]. The minimum number of instances of a class is [__________], the maximum is [__________]. In object-oriented design, an object [can/cannot] be be a instance of more than one class, and an object [can/cannot] change which class it is an instance of.
A discussion of this question can be found at the end of this chapter.
Suppose you are designing a computer system to carry out stock control in a large book warehouse. The system should store extensive details of each book, including at least the following information: authors, title, publisher, date of publication, size, number of pages, binding format, shelf location, re-order level, purchase price, sale price. Which of these properties of books do you think are relevant to the conceptual class “Book”, and what properties to the concrete class “Book”? This problem is somewhat more difficult than it first appears; see the answer for further discussion.
A discussion of this question found at the end of this chapter.
Fill in the blanks with an appropriate word or phrase:
Attributes define the properties of a class. In a class specification an attribute has a [__________] and a [__________] (e.g., number, text). In each object of that class the attribute will also have a [__________]. This may be different for each object, but no instance of the class will lack the attribute entirely. For example if I say that a particular vehicle has 12 wheels, I am implying that vehicles have a attribute whose name is “[__________]”, whose type is “[__________]” and whose value in the particular case is [12]. The minimum number of attributes that a class may have is [__________]. The maximum number is unlimited, but in practice it is difficult to manage a class with more than about 30 attributes. Java programmers tend to use the term [__________] in preference to attribute, but these are essentially the same thing.
A discussion of this question can be found at the end of this chapter.
Draw a UML class symbol that has the following specification. The class is called “Customer”. It has four attributes: name (which is text), address (also text), balance (a number), and credit rating (type currently unknown). It has one operation: “printStatement()”, which has no parameters or return value.
A discussion of this question can be found at the end of this chapter.
In the early stages of development it is usually better to identify too many classes than too few. You can then rationalise you choice of classes by removing, modifying and merging them. The following list is of classes that may be considered for deletion or absorption into a new class. Suggest why this might be the case for each example.
Fred Bloggs, a customer of the bank
Colour
Hard disk
Central processing unit
Linked list
Red
Test procedure
List of customers
For as many of these examples as you can, suggest an application where it is not a bad choice of class.
A discussion of this question can be found at the end of this chapter.
Draw the class diagram for the radio/televsion/car example given in the text, showing where multiple inheritance occurs.
A discussion of this question can be found at the end of this chapter.
Construct a class model to represent the following information. The customer is a company that specialise in the supply of specialist musical recordings, of the type that are difficult to obtain through mainstream record shops. The customer would like to make it possible for their clients to order their products on-line using a Web browser. The on-line system is to provide full details of each musical recording, and will be integrated into an automated stock control system. In this way their client will be able to tell immediately if the items required are in stock. The customers describes the details of their stock as follows:
We stock about 10,000 different musical recordings, usually with 1-10 of each item in stock at any given time. With more popular items we will stock ten or more copies of the same recording, perhaps in different formats.
We stock recordings in different formats: cassette tapes, audio CDs and audio DVDs. The publishers we buy from will normally supply a recording in more than one format. For example, usually we will get CDs and cassettes of a given recording from the same publisher.
We buy our stock from music publishers. For each publisher we record the name and address, and the name and e-mail address of our contact person there. When we place an order we need to know the publisher's catalogue number, which is generally different for different formats.
When a customer looks at our Web site, we want to be able to give extensive details for all our recordings. For example, we will want to display the title, performer, composer, date and venue of recording, copyright holders and some general information. In addition, we want to display the titles and durations of all the musical tracks. This is complicated by the fact that the CD, DVD and cassette formats generally don't have the same tracks. Because a DVD is longer than a CD, it will usually have a few extra tracks. A cassette tape usually has even fewer tracks than the CD.
A discussion of this question can be found at the end of this chapter.
Redraw the contract-subcontract relationship shown below so that it does not use a self-association. Do you think your model is more or less expressive in this form?
 |
A discussion of this question can be found at the end of this chapter.
What is meant by the statement “objects are not classes, but instances of classes. However, classes can be considered objects”? In other words, in what sense is a class also an object? (This is a tricky question if you are not absolutely clear on the distinction between “classes” and “objects”).
A discussion of this question can be found at the end of this chapter.
Write a simple, one-line definition of each of the following key terms. Try to do this without referring back to the notes if possible. For each term, give an example.
Attribute
Operation
Self-association
Generalisation
Polymorphism
Link class
Multiplicity
Stereotype
A discussion of this question can be found at the end of this chapter.
Which of the following are true? Give an example to support your decision.
If Z is a subclass of Y, and Y is a subclass of X, then Z is a subclass of X
If Z is associated with Y by an association A, and Y is associated with X by an association A, then Z is associated with X by an association A
If Z is associated with Y by an association A and by an association B, then A and B are different names for the same association
If each object of class Z is associated with ten objects of class Y, and each object of class Y is associated with ten objects of class X, then there are 100 objects of class X for each object of class Z
A discussion of this question can be found at the end of this chapter.
What is the difference between class modelling, and entity-relationship modelling? In what ways are classes and entities similar? In what ways are they different? (If you have not completed the part of the course that deals with entity-relationship modelling, you may find this question difficult).
A discussion of this question can be found at the end of this chapter.
Consider these three classes: Rectangle, Circle, and Line, which are subclasses of a general Shape class. These classes have operations drawRectangle(), drawCircle(), and drawLine() respectively. Each of these methods cause the appropriate shape to be drawn. Is this system exhibiting polymorphism or not?
A discussion of this question can be found at the end of this chapter.
What is the difference between a link class and a link attribute? Gives examples of each.
A discussion of this question can be found at the end of this chapter.
Probably “Clerk”, “Customer”, “Ledger” and “Service technician” are important in a logical standpoint. None of these are likely to transform directly into parts of a computer program. On the other hand, “File”, “List” and “Database” probably will. “Screen” and “Mouse” are less easy to categorise. In some cases these will in fact simply be alternative representations of the human beings that will interact with a system. For example, a clerk may use a keyboard and a mouse; in some systems it is the fact that these particular devices are in use that is important, but in most it will be the person and that person's role that are important.
A class encapsulates the behaviour and properties of a number of [objects, entities]. The members of a class are also referred to as [instances]. The minimum number of instances of a class is [zero], the maximum is [unlimited, infinite]. In object-oriented design, an object [cannot] be be a instance of more than one class, and an object [cannot] change which class it is an instance of.
Some things are clearly properties of the conceptual class. For a book, things like the title, author, date of publication and publisher are probably conceptual. They will be independent of any physical realisation of that book. For example, there are many copies of Tolstoy's “War and Peace” in existence, in many different formats, but all share the same fundamental properties.
In a library, the shelf location and bar-code number are properties of the physical book.
Less straightforward cases are properties like the format (size, shape, binding) of the book. These are clearly “concrete” properties. However, there are many different copies of each of these formats. Are these individual copies “physical” and the formats themselves “conceptual”? This is not a straightforward question. It may be in a very complex book handling system that we have to institute a number of different classes to represent book information.
Attributes define the properties of a class. In a class specification an attribute has a [name] and a [type] (e.g., number, text). In each object of that class the attribute will also have a [value]. This may be different for each object, but no instance of the class will lack the attribute entirely. For example if I say that a particular vehicle has 12 wheels, I am implying that vehicles have a attribute whose name is “[number of wheels]”, whose type is “[number, integer]” and whose value in the particular case is [12]. The minimum number of attributes that a class may have is [zero]. The maximum number is unlimited, but in practice it is difficult to manage a class with more than about 30 attributes. Java programmers tend to use the term [instance variable] in preference to attribute, but these are essentially the same thing.
Bad classes:
Fred Bloggs, a customer of the bank: this is potentially a bad class because Fred Bloggs is an object (instance), perhaps of class Customer. It is unlikely that there will be a whole class of Fred Bloggses.
Colour: colour is likely to be an attribute of something. If you have studied Java programming you will probably come across a class called Colour. However, Java does this as an extension of the language, not because Colour represents anything in a model. However, in a program for, for example, colour mixing in printing machinery, perhaps Colour is important enough to be a class in its own right.
Hard disk: this is a bad class because it is concerned with the internal operation of the computer. In modelling, we want to avoid detail of this depth. “Document” and perhaps “Folder” may be reasonable modelling concepts. However, in an application to design computers, HardDisk may be a sensible class.
Central processing unit: has all the same problems as the example above
Linked list: if you didn't know what a linked list was, then that is as good a reason as any for getting rid of it. Even if you did, it is still too technical to use in modelling
Red: is probably the value of an attribute
Test procedure: this is probably an operation, or perhaps a use case
Print: this is almost certainly an operation (or a Printer class perhaps?)
List of customers: too much detail. “Customer” is a sensible class name. The fact that there are more than one customer should be represented by the multiplicities of associations with other classes (see later).
 |
This is a somewhat contrived example, and is unlikely to occur in a real application. However, multiple inheritance does occur in real applications all the time. It is probably more important in programming, rather than modelling as such. For example, a popular style of programming called “mix-in” programming makes extensive use of multiple inheritance. In mix-in programming a large number of very simple, general-purpose classes are defined, and these are inherited in various combinations by the major classes. Because something is important in programming, this does not necessarily mean it should be used in modelling. This topic is an important and controversial one.
There is no single right answer to this question. You should be prepared to discuss you solution with your tutor/classmates (hint: a good answer will probably contain between 5 and 10 classes).
 |
In this alternative formulation, there is no self-association, but a SubContract is shown as a sub-class of Contract. The representation that used a self-association did not make this class/sub-class relationship explicit; indeed it may not really be true. If one is prepared to accept the implicit assumption that SubContract is a sub-class of Contract, then the diagram shown above does effectively remove the self-association. This may be a reasonable approach for someone who really find self-associations difficult to follow. So perhaps some improvement in expressiveness has been gained, but at the expense of a slight loss of accuracy.
Suppose a class model has three classes, called ClassA, ClassB and ClassC. Objects of these classes will share properties (this is the definition of being an instance of a class, after all). However, the classes themselves will also have properties in common. For example, they will all the attribute “name”. Its value is “ClassA” for ClassA, “ClassB” for ClassB, etc. All classes will have the property of being able to enter into relationships with other classes. All classes will have the attribute “numberOfAttributes”. Thus we can say that there is a class called “Class”, which embodies the behaviour of all classes. Each actual class is an instance of class “Class”.
This is not simply an academic point. Being able to express a modelling notation in terms of the modelling notation itself is a very powerful way to ensure that the modelling system is consistent. If you study the UML specification documents, you will find that all UML diagram rules are themselves specified in UML notation. This is called meta-modelling
Attribute: a property that objects of a class have, that can be expressed in terms of a name, a type and a value. For example, class “Vehicle” has attribute “numberOfWheels”. Different vehicles have different values of this attribute.
Operation: a well-defined unit of behaviour of an object of a class. For example, class Vehicle has operation “startEngine()”.
Self-association: an association between one or more objects of a class, and one or more objects of the same class. For example, each object of class “LivingThing” is involved in a one-to-many association called “eats” with other objects of the same class (technically I suppose that some living things don't eat other living things, but I hope you get the general idea).
Generalisation: the property that a class has of representing behaviour and attributes of a number of subclasses. For example, class Vehicle generalises classes Car, Bus and Tram, etc.
Polymorphism: differences in behaviour between different sub-classes of the same base class. For example, all sub-classes of Vehicle have the operation “startEngine()”, but the mechanism of starting the engine is different in each case.
Link class: a class that specifies the details of an association between two other objects. For example, the relationship between a seller and a buyer may be complex enough to need a class (e.g., SalesTransaction) to represent its details.
Multiplicity: the number of objects that take part in each end of an association. For example, the multiplicity of the relationship between Driver and Vehicle is 1 to (1-*), meaning a driver can drive one or more vehicles.
Stereotype: a category to which a class belongs, e.g., “Actor”, or “User interface element”.
If Z is a subclass of Y, and Y is a subclass of X, then Z is a subclass of X. This is correct, and a fundamental principle of object orientation. If mammal is a type of animal, and dog is a type of mammal, then dog is a type of animal. Can you think of a dog that is a mammal but not an animal?
If Z is associated with Y by an association A, and Y is associated with X by an association A, then Z is associated with X by an association A. This is false. For example, lions eat zebra and zebra eat grass. But lions don't eat grass. The association is not carried across the classes. This is one of the things that distinguishes generalisation/specialisation from other relationships.
If Z is associated with Y by an association A and by an association B, then A and B are different names for the same association. This is also false. Two objects can be associated in completely different ways. For example, customers deposit money in a bank account; customers withdrawn money from a bank account. “Deposit” and “withdraw” are two totally different associations.
If each object of class Z is associated with ten objects of class Y, and each object of class Y is associated with ten objects of class X, then there are 100 objects of class X for each object of class Z. This is correct. For example, if a program has ten screen windows, and each window has ten buttons, then there will be 100 buttons for each program.
Class diagrams can be considered to be highly-developed and regularised entity relationship models (ERMs). Class modelling provides a definite notation and meaning for concepts that are weakly-defined in ERMs. For example, an relationship called “is-a” can be used in an ERM to show that one thing is a type of another thing, or that one thing is an instance of another thing. Moreover, when an “is-a” relationship is used, it does not necessarily denote any inheritance of properties. In ERMs properties are usually represented as entities as well, so this would be difficult to show. The same applies to relationships that are often written as “has-a”. This is an aggregation, but the different types of aggregation are not as well defined in ERM as they are in class modelling.
For all these differences, ERMs and class diagrams are more similar than they are different; both attempt to show the static structure of system in terms of the “things” (entities; classes) of which it is comprised.
The system as described is not polymorphic. There is a difference in behaviour between the different subclasses of Shape, and this difference is in an operation that is philosophically common to the three classes. That is, drawCircle(), drawRectangle(), and drawLine() are obviously drawing operations. However, there is no corresponding “drawing” operation in the base class “Shape”. The system could not invoke the drawing operation in Shape, with a view to the correct sub-class being drawn. To be polymorphic, the base class needs to have an operation called “draw()” that is abstract, that is, does nothing. The sub-classes all provide their own implementations of “draw()”. Now if there is an object of an sub-class of Shape (it doesn't matter which), another object can cause it to be drawn by invoking the “draw()” operation. The presence of “draw” as an abstract operation in Shape guarantees that all sub-classes of shape will respond to a “draw” operation. This is a powerful simplifying principle.
Both link classes and link attributes provide additional information about associations than can be carried by a simple association name. A link attribute carries only a single piece of information and, being and attribute, cannot interact directly with other objects. A link class is a fully-fledged class and can take part in class relationships of its own. It can carry as much information as required. Link attributes are simpler to read and simpler to implement, but are not as versatile. For example, an employer and an employee may interact in a way defined by a contract. A simple link attribute might be a contract number. This would identify different contractual agreements between the same entities. However, implementing Contract as a class would allow a lot of extra information to be represented. Of course, it is only worth doing this if it improves the expressiveness or accuracy of the model.
