Coursework 2

Motivation

• To do a more constrained exercise in identifying relationships between classes

• To check understanding of some of UML’s behaviour diagrams.

Draconian submission rules

The deadline for submission of this work is 17:00 on Friday November 28th. Other conditions are as last time: no late submission without prior arrangement, and a normal penalty of 10% per day, which may be waived if there’s a good reason for the pre-arranged late submission.n Anyone who mails me their Rose model file in an encoded form this time will get 0.

The problem

This question concerns a software system designed to support the help desk of an international software developer offering a range of products.

The help desk is operated by non-technical staff who are unable to answer technical enquiries. Technical enquiries are transferred to one of a number of technical groups, each of which supports a variety of products. The operator on duty is the initial point of contact with customers, and is supported by a software system which records the enquiries and tracks an enquiry until it is satisfied.

On receiving a call from a customer, the operator enters the customer’s product registration number into the system. The system then verifies that the number is valid and that the registration has not expired, and provides the operator with a unique enquiry reference number and a list of technical groups able to answer the enquiry (each product is supported by more than one group). The system records the enquiry as unallocated, and appends the date, time and operator’s identification. The operator gives the enquiry reference number to the customer, and looks to see which of the given technical groups has a free telephone line and can accept the enquiry. When one of the groups is free, the enquiry is recorded as allocated by the operator and the caller is transferred to the relevant technical group.

A member of the technical group then discusses the enquiry with the customer, recording descriptions of both the problem and suggested solutions, until the customer is happy that all the issues are resolved. The enquiry is then marked as having been satisfied. Note that the enquiry cannot be marked as satisfied unless these descriptions have been entered.

A product registration number, and hence an enquiry reference number, relates to a specific product – so if the customer asks about more than one product, separate enquiry reference numbers are allocated to each product enquiry. Thus, a customer with an enquiry about each of two separate products would be given two separate enquiry reference numbers.

The following classes have been identified for the system:

HelpDeskController – controls access to the system for both operators and technical groups Product – contains details of a product, such as the number of versions issued, first year of

issue, number of enquiries for this product etc.

Enquiry – contains information about an enquiry, such as enquiry description, solution description, and so on

Operator – contains information such as name, identification number and so on

TechnicalGroup – contains information such as telephone numbers, number of enquiries processed, and so on

ProductRegistration – contains information such as a customer’s product registration number, date of expiry of registration, and so on.

The exercise

This is all to be done in Rose, and you should submit a Rose model file by mailing it to me as plain unencoded ASCII text, not as an attachment. For anyone still having trouble with this, mail pxs < myFile.mdl (replacing myFile.mdl by the name of your model file) should do fine.

1. Develop a very simple use case diagram for the system – it probably only has one use case, though you should find several actors. (10%)

2. Develop a class model of the system using the classes listed above. (30%, including the attributes and operations, though you may want to delay identifying those until you’ve done later parts of the question.)

3. Taking advantage of Rose’s ability to generate sequence diagrams from collaboration diagrams and/or vice versa, develop both a sequence and a collaboration diagram to show a typical interaction with the system, from the time a customer rings up with an enquiry about a single product to the time the enquiry is resolved.

I’m asking for both just to make sure you’ve used an example of both. Your submitted Rose model should include both a complete legible sequence diagram and a complete legible collaboration diagram. By legible I mean that you will probably have to fix the layout of the generated diagram manually: Rose tends to put elements on top of one another. I don’t mind in which sort of diagram you do most of the work: but I think you’ll have to work in the collaboration diagram when you make sure that the links between objects correspond to associations in the class model. (Remember the Rose bug I mentioned: type the association names, don’t pick from the menu!!)

Once you’ve finished, the messages in the interaction diagrams should correspond to operations on the relevant classes in the class model, and the links in the collaboration diagram should correspond to associations in the class model. If you had not already identified the relevant operations in the class model, you will need to add them now. (30%)

4. Develop a state diagram, with 3 or 4 states, for the Enquiry class. (Select the Enquiry class in your class model, then choose State Diagram from the Browse menu – it’s greyed out unless you have a class selected, which seems like a bad user interface feature to me, but there you are!)

(Note that this class is probably too simple to want to develop a state diagram for real: I’m just trying to keep the exercise short enough.) (15%)

5. Explore the specification windows for the various UML things, and make sure your models as associated with one another as appropriate: for example, that the state diagram you developed for the Enquiry class is listed in the Diagrams tab of the Enquiry class’s specification window. (15%)

6. Check that your models are consistent (in as far as Rose can check it) using the Check Model command from the Tools menu. If there are errors, see whether there are things you can fix, and retry.

In the top level documentation window, describe very briefly in what order you developed the various models. (Slightly unlikely example: “I developed the class model, complete with all its operations. Then I developed the collaboration diagram completely. I generated the sequence diagram from it, and only had to alter the layout. Finally I did the state diagram.”)

If your checking showed errors that you haven’t been able to fix, comment on them here. E.g. do you think they are real problems with the model, or with your use of Rose? (Up to 20% in bonus marks, to count against marks you lost in the earlier parts. This reflects the fact that a problem you know about is much less troublesome than one you don’t!)

If you like, you can experiment with generating code from your model, but this is entirely optional and not for marks: don’t submit the results.