4 THE CLASS MODEL  30/10/97  4.6 A simple example

A possible solution

Slide 37

Another possible solution

Slide 38

\overline{SEOC97  Id : notes6.tex, v1.21997/11/0215 : 34 : 26pxsExppxs  42}

4 THE CLASS MODEL  30/10/97  4.7 Identifying objects and classes

4.7 Identifying objects and classes

One of the simplest and most effective techniques for identifying classes and operations is to take or write an English description of what the system must do, underline the noun phrases and verb phrases, and consider the noun phrases to be candidate classes and the verb phrases to be candidate operations on some class.

Of course it isn’t as simple as this! You have to be careful to discard nouns which are inappropriate because they are:

• Redundant – maybe several noun phrases refer to things which are the same from the point of view of the system (Town and City in most applications, for example)

• Outside the scope of the system – for example, the actors in your use cases are likely to occur in the description, but probably don’t need to be represented by classes

• Vague – e.g. “information”, “concept”, where unless there’s some more concrete thing lurking behind the word it probably has no significance for the system

• Attributes – for example, “name” of a customer will occur, but name probably has the simple type string and no behaviour to speak of, and is better modelled as an attribute of class Customer than as a class in its own right

• Operations and events – e.g. the placing of an order. Sometimes you will need to model an event as a class, especially when the system has to keep a record of its having occurred, but this is the exception rather than the rule

• Implementation classes – e.g. List. By the time you reach an implementation-stage class model you may want to show these, but in the beginning they probably represent dubious assumptions about how the system must be implemented.

(This list is adapted from OU course M868, Object Oriented Software Technology.)

Classes and objects often derive from one of these sources (Schlaer-Mellor, paraphrased by Booch, adapted again by me)

• Tangible or “real world” things: courses, students, orders, pressure sensors

• Roles: DoS, mother, teacher, politicion

• Events: landing, interrupt, request

• Interactions: loan, meeting, intersection

These categories overlap, and the first two are much more common sources of objects and classes than the last two.

Other possible sources (these from Coad and Yourdan, again quoted in Booch) include: devices, locations, organisational units, other systems with which this system may interact. The last is particularly interesting: it’s common, and good practice, to create a class to wrap such an external system – maybe a particular database or TP monitor – and let your system interact with that, rather than direct with the system. This limits the possible dependencies on the external system to what you put in the interface of the wrapper class, and makes it easier to replace the external system if necessary. The danger is that you can end up having to make the wrapper allow access to so much of the external system that actually it’s inconceivable that another external system could be made to provide the same interface. If this happens, then you’ve done extra work of wrapping for no benefit, since if the external system changes, the wrapper will have to change too, and your system will be as hard to adapt as it would have been without the wrapper. Sometimes it’s better to do without the wrapper and just accept that your system is dependent on the interface to another.

Identifying objects and classes

Simplest and best: look for noun phrases in the system description!

Then abandon things which are:

• redundant

• outside scope

• vague

• attributes

• operations and events

• implementation classes.

(May need to add some back later, especially implementation classes: point is to avoid incorporating premature design decisions into your conceptual level model.)

Similarly, can use verb phrases to identify operations.

Slide 39

Real world objects vs their system representation It’s easy to get so hung up on the object way of looking at things that one forgets that objects are really things inside a computer program. When we talk about “students” and “courses” we really mean the representation of these things within our system. The consequences of this are that we must be careful

• not to record information that is definitely irrelevant to our system;

• to remember that the objects are the system!

The latter point is particularly interesting. In the CS4 administration exercise, many people made the error, which is a classic for people not yet steeped in OO, of inventing a class which was “the admin system”. The whole caboodle is the admin system, that’s the point! It’s in order to avoid this error that I really prefer the solution that didn’t even show the UI, as a conceptual model class diagram. You might think that I’ve just renamed “the admin system” to “the UI”. I haven’t, because the UI isn’t actually doing anything bar providing a mechanism for the actors of the system to be able to send messages to the system: but it’s a subtle distinction, and it’s easy to drift into monolithic design in which there’s one object that knows everything. This is bad because such designs are very hard to maintain: they tend to have assumptions built into them about how the system will be used.

I hope we’ll have time later to talk a little about techniques for user interface design which help to avoid this kind of problem, especially the Model-View-Controller pattern.

Trap 2: overusing generalisation

Suppose I’m developing a personal organiser application, and I want to implement an appointments diary using the class LinkedList. I should not make the relationship between AppointmentsDiary and LinkedList be a generalisation! Why not? Because this isn’t conceptually a generalisation relationship: it isn’t true that an appointments diary is a kind of linked list. It’s tempting, and I’ve succumbed, because it saves writing one-line wrapper methods for things like add and next – but when I’ve done this kind of thing I’ve always regretted it. One of the problems is that you have no option but to expose the whole of the linked list interface, even if (say) you didn’t want to allow things in the system to access the number of appointments. This kind of additional dependency can make it hard to alter the implementation later.

Slide 40

Trap 3: identifying too many classes

Particularly when considering generalisation relationships, it’s easy to get carried away, and build complicated (and highly coupled) inheritance hierarchies that aren’t necessary. By all means identify lots of generalisations: but be careful that you don’t automatically implement all generalisations using inheritance. For example, we could have identified AIModule, CSModule etc. as subclasses of Module in the example. But what would be the benefit? Do they have any different behaviour from the system’s point of view? Better, here, to have an attribute of a module which records what kind of module it is. Inheritance is best left for when some subclass has extra behaviour or relationships that don’t make sense for the superclass.

Slide 41

4 THE CLASS MODEL  30/10/97  4.8 CRC cards

4.8 CRC cards

CRC stands for Class, Responsibilities, Collaborations. CRC cards were introduced (and described in a paper at the major OO conference OOPSLA’89) by Kent Beck and Ward Cunningham, as a technique to help programmers with experience in non-OO languages to “think objects”.

On a small card, we record the name of a class (at the top), the responsibilities of the class (on the left hand side of the card) and the collaborators of the class on the right hand side of the card. Class B is listed as a collaborator of Class A if either some object of class A sends a message to an object of class B, or vice versa – so in particular, a class is in an association relationship (possibly aggregation) with each of its collaborators. The responsibilities of the class describe at a high level the purpose of the class’s existence: they’re connected with the operations the class provides, but are more general than that. For example, “maintain data about the model” is acceptable as a description of a responsibility, though there might be many associated operations, for getting the various bits of data concerned. A class should not normally have more than three or four responsibilities, and many classes will have only one or two. If a class does end up having more than 3 or 4 responsibilities, consider whether you can describe them more concisely, and if you can’t consider whether it would be better to split the responsibilities and have two or more classes.

Too many responsibilities corresponds to low cohesion in your model: too many collaborators corresponds to high coupling. Using CRC cards can help to identify both of these faults in your model.

You can also use CRC cards to walk through use cases, working out how the class model provides the functionality required by the use cases, and where the missing bits are.

Beyond that it’s up to you. Some people like to pile cards related by generalisation together, with the most abstract at the top, so that you use the specialised class only when the particular specialisation is relevant. Some people like to group cards which are more closely related close together, or to put a “controller” class at the top.

CRC cards

Class, Responsibilities, Collaborations

Originally introduced by Kent Beck and Ward Cunningham as an aid to getting non-OO programmers to “think objects”.

Also useful for validating the class model against the use case model.

We’ll see next week how to record much of the information produced using CRC cards in UML interaction diagrams.

CRC cards are an aid to clear thought, not a formal part of the design process.

Slide 42

4 THE CLASS MODEL  30/10/97  4.9 CRC Example

A CRC card

Class OrderLine represents a single line on an order; for example if an order is for 6 blue widgets and 10p each and 8 red ones at 11p each we have two order lines, one for each kind of widget.

Order

See whether items in stock OrderLine

Work out total price

Check for valid payment  Customer

Dispatch to delivery address

Not a toy example: the scale of this is about right. Crowded CRC cards mean either badly expressed responsibilities or non-cohesive classes.

Slide 43

4.9 CRC Example

Let us return to the CS4 administration system.

Using the class diagram and the use case diagram, and using my hint to each group about where you should start, build a (maybe partial) set of CRC cards for this system. You may well find that you have to alter the class model or the use case model as you proceed: this uncovering of deficiencies is of course one main purpose of using CRC cards! (You should be much happier about altering the class model than the use case model, of course, since the use case model is supposed to represent the users’ requirements, which you can’t cahnge unilaterally! However, it could happen that you find the use cases as recorded are too specific, for example: you could find that you’re able to represent equivalent functionality in a different way. I doubt that it’ll happen in this example, but in general, it might well.)

If you find it helpful to get concrete – in this small example, you might, although in a larger system you probably shouldn’t at this stage – you may use the reverse side of the CRC card to record other information, e.g., the names of any operations you identify.

4.9.1 Discussion

Many of you seemed to find this exercise rather difficult and confusing. Probably I should have led up to it more carefully: will do so next year! However, between you I think you did identify all the key interactions.

I’ve added to the Rose model I’ve been maintaining for this system, and provided access to the file from the course home page: you might like to browse it in detail, though I am definitely not claiming it’s definitive! The collaborations are represented as associations on the class model; I’ve listed the high-level responsibilities of each class in its documentation field in the class model. I’ve also added a very short note to each use case to say how it is implemented. Here for example is the specification of HonoursCourse.

Here’s my revised class model, showing some operations needed to realise the responsibilities. The basic structure hasn’t changed (much) from the previous version, only I messed up the layout so it looks as though it has changed more!

Revised class model

Slide 44

There are several issues that this brings up:

Very data-heavy system All our classes have encapsulating data as the major part of their responsibilities. This shouldn’t surprise us, since the main purpose of the system is to maintain data about CS4! But it isn’t really typical of OO systems – for example, the system you’re dealing with for Coursework 1 has a lot more behaviour and less data, and is more typical. Classes which do nothing but encapsulate data are often, but not always, a sign that all the behaviour is somewhere else, maybe in a single Controller class, which is bad design because it tends to mean that the particular current use of the system (the current set of use cases) is being hard coded. So when your design has such classes you should check that you aren’t missing some behaviour that goes with the data being encapsulated. In this case, I think what we have is reasonable: our system just doesn’t have very much in the way of behaviour.

Maintaining associations Several of our operations (like addStudent on Module, addModule on Student) have the job of updating the association relationships which we already show on the diagram. Yet in other cases (like the association between Student and DirectorOf-Studies) we don’t provide operations to do this. Why, and how do you decide what to do?

I’m not sure that I can give a completely straight answer to this: I suspect it’s an area where practice differs. I think the most useful thing is probably to show the relationship if it will be updated as the system carries out the behaviour you care about, but not if it’s just set up when the objects are created and you don’t expect it to change thereafter. For example, we do need to show how the particular Student objects get associated with particular Module objects, because this is the student registration process. But we haven’t been asked to show how a student’s DoS changes, so to show that would clutter the diagram. (Probably, the association is set up when the Student object is created – perhaps a DoS object is a parameter to the constructor of Student – and doesn’t change thereafter.) As always, you have to do what you think is most helpful, and take the consequences in confusion if you get it wrong!

The user interface I haven’t shown the user interface(s), i.e. how the actors get to use these facilities. On reflection, it became clear that a single UI object was not going to do: different actors need access to different parts of the system’s functionality. I’ve commented on this in the Documentation field of each class on the class model, under Actor Interactions. (During development, you can use the documentation field for whatever seems useful – I’ve got a Remarks: section in many of mine, i.e. I’m using it as a convenient place to make notes about things we may want to think about later. By the end of the development, you probably want the class documentation field to contain only stuff that genuinely is documentation about the class, independent of the particular context in which the class is being used here. So the Responsibilities section would probably stay, but the rest would be deleted as the issues are dealt with.)

Probably, we would end up with a Model-View-Controller interface, in which each actor is provided with a different (but consistent) view onto the system. More design work needed!

Scope On writing this up, I noticed another feature that comes up fairly often: some uncertainty about which real-world objects we should be representing in our system. Pretty clearly we don’t want random History students represented. Probably we just want students who take some CS4 module. But then those students may have DoSs not in CS and take modules not in CS, so we are of course representing lecturers and modules from other departments. We might want to consider to what extent we want to do this.

New references

• Schlaer, S. and Mellor, S Object oriented system analysis 1988 Yourdan Press

• OU M868 course material

• Coad,P. and Yourdan, E. Object oriented analysis 1990, Prentice Hall.