UML Collaboration diagram for an emergency reporting system

Question

I am working on some software modeling/design homework and I'm having trouble wrapping my head around how to turn this particular use case into a Collaboration diagram. I found this excellent tutorial, but the use case I am studying introduces a "UI" component that I can't find an analogy for.

The problem in question is quoted:

Use case name: Report Emergency Participating Actors: Initiated by the officer and communicates with correspondent Flow of Events:

1. The officer activates the “Report Emergency” function of her terminal
2. System responds by presenting a form to the officer
3. The officer fills the form by selecting the emergency level, type, location, and brief description of the situation. The officer also describes possible responses to the emergency situation. Once the form is completed, the field officer submits the form.
4. System receives the form and notifies the correspondent.
5. The correspondent reviews the submitted information and creates an incident in the database. The correspondent selects a response and acknowledges the report.
6. The system displays the acknowledgement and the selected response to the officer. Precondition: The officer is logged into the system Postcondition: The officer has received an acknowledgement and the selected response from the correspondent, OR the officer has received an explanation indicating why the transaction could not be processed.

As I understand it, associations in a Collaboration diagram indicate the flow of messages between objects, and don't necessarily reflect the physical relationship between what the objects model. If that's the case, then which object should be responsible for the newEmergencyForm() method, and which object should be calling that method? Couldn't the newEmergencyForm() method and the reportEmergency() method be rolled up into one?

Answer 1

• Now (current UML standard is 2.4.1) the diagram is called Communication diagram, not collaboration one. Collaborations remain as elements of some diagrams, but they have other sense.

• As I understand, Report Emergency is filling the form. And newEmergencyForm is providing the form to be filled. These are two different actions, you already know the difference between them, so, you have no need in not noticing this difference and counting them for one operation. But if for some reason you wish to postpone showing the subject for later diagrams, you may do it. It is NOT against standard.

• I wouldn't name the things that create these messages 'objects'. On this level of abstraction we rather speak on components.

• You can't say what component creates some message until you define all components. You can do it in head, it is OK, but then we cant't help you with the choice. What is 'system'? (on this level we do not talk on system as a whole, it is the term for Use Case. What is çorrespondent'? Is it the same as officer or can be same? Or is it a subsystem? What other components do you have?

• Else you have to provide us the Component diagram as a source. BTW, I am almost sure that after correct defining all components you will find the solution yourself.