Frequently-asked questions »

Question »

Questions

OO class modelling 1 »

OO class modelling 2 »

Data/ Attribute Normalisation »

Fact Gathering »

Text in bold is suggested wording and text is italics is commentary on the answer.

First, it is important to remember to answer each part of the question.  Make it clear which part of the question you are answering by using the question parts indicated (a, b and c). It is useful to start each part of your answer on a new page, allowing you to add extra detail after your initial answer. 

• Answer to part a
• Answer to part b

• Answer to part c

Part a

A possible class model is shown in the attached diagram.

The significant points in each paragraph of the case study are discussed below, leading to this sample class model.

Paragraph 1

This paragraph defines the basic subscriber class. Subscribers are also divided into business and personal subscribers and business subscribers in turn are further specialised.  This is because each can make different forms of payment, e.g. a platinum subscriber may only pay by direct debit, whilst a non-platinum or personal subscriber can pay in either form.

Paragraph 2

This paragraph defines the notion of a statement (note the name 'monthly' is not necessary), containing the various charges.  These charges form the statement and hence the correct association is one of aggregation.  We have chosen the name statement entry to define this class and this is then specialised into either a charge item or a payment.  Charge items are further refined into service or call charges.

Paragraph 3

This paragraph creates the association between subscribers, users and handsets.   It is important to remember that the class model is attempting to describe the logical classes, i.e. even though in some cases a person might be a user and subscriber, the case study wishes to distinguish between the two, since each has special properties.

Paragraph 4

This paragraph defines information necessary to handle credit checking and will lead to additional attributes and operations being added, such as checkCredit and updatebalance in the subscriber class.

Part b

A possible sequence diagram is shown in the attached drawing.

This sequence diagram is based upon the narrative (mainly) in paragraph 4 of the case study.  Two additional classes are added to handle the boundary and control objects to deal with user interface and application logic respectively.

The first message (makeCall) comes from the external world and is intercepted by the boundary object.  The boundary object relays the message to the control object which will presumably decide it is a valid action and instruct the handset object to make a call.  The handset object must ask its associated user if there is sufficient credit with message checkCredit.  User is not responsible for credit, so it must in turn ask its associated subscriber.

Return messages are not normally shown, but assuming that the subscriber's credit is OK, the control object tells the call object to billCall.  A charge would presumably be returned and the user object would be instructed by the control object to update the balance of the subscriber (updateBalance), which again must ask its associated subscriber to do so.

Part c

First define the concept of message passthrough.

Message passthrough is where an object receives a message and simply relays the message onto another object without further processing.

Now explain what is good and bad about message passthrough.

Message passthrough is generally regarded as bad, as it increases the interaction coupling of a class model and can make reuse more difficult.

However, in some circumstances it is possible that message passthrough is good, for example, where an object is an aggregation of other objects and simply relays a message onto to those objects which create it.  

The best marks are now obtained by relating this question to the case study.

Looking at the sequence diagram in part b of this question, you can see it occurs with checkCredit between Handset, User and Subscriber and with updateBalance between the control object, User and Subscriber.

Although aggregation is not involved here, the message passthrough is acceptable.  This is because when credit is being checked, for example, a Handset only knows its User (the association on the class diagram is only between Handset and User and not Handset and Subcriber).  Therefore the Handset would not know which Subscriber to 'ask' to check the credit. 

Full marks would be obtained for explaining how to get around the message passthrough.

One way around this would be to supply the subscriber-id when a call is made so that the Handset object would know which Subscriber's credit to check.

Hide comments »