如何将分析模式中的动作解释为序列图？

Question

Based on the Accountability Analysis Pattern:

The concept is that we have a class diagram following the logic of the Accountability Analysis Pattern. How can I use the given function assignStaffContact() to assign contact?

I have undrerstood that StaffContact class is a control class and the Client , StaffMember are entity classes (we don't care about the TimePeriod class).

I cannot figure out which classes are gonna play a part in the procedure of assigning staff contact in order to create the proper sequence diagram (UML) of this action. Arbitrarily there must be a boundary class providing the wanted interface. The actor is gonna pick the case of assigning staff contact, which will trigger the method assignStaffContact() of the control class StaffContact but with which entity classes this will communicate and finally assign the staff?

I am getting confused with class ContactForCampaign and the logic behind it being connecte to the classes Client and StaffMember . I hope I explained well enough my problem and my thought process.

Answer 1

This diagram says that:

• A StaffContact instance can be associated to several ContactForCampaign instances
• Each instance of ContactForCampaign is associated with exactly one instance of a Campaign , and defines exactly one StaffMember object as responsible, and. one Client object as commissioner (probably for the campaign).

As a consequence, we can only guess that StaffContact::assignContact() requires to know which StaffMember to add (should be an argument of the operation). Since several ContactForCampaign instances can be considered, the ooeration would probably also need to know which ContactForCampaign is relevant for the assignment. Probably this can be determined with the help of a Campaign parameter. Two cases must then be considered: replacing a staff member of an existing ContactForCampaign or create a new one if no assignment exist for a campaign. You have now all the ingredients for your sequence diagram. Note also that the operation would need to know which client is to be assigned as commissioner if a new ContactForCampaign os created.

Note that StaffContact::removeStaffContact() does not seem relevant, in view of the multiplicity 1 for the StaffMember , unless you condider removing as well the ContactForCampaign, which would then cause to lose the information regarding the commissioner.

Last but not least, in view of the 1 multiplicity on the side of StaffContact, it would not be a control class, since the control is in princple existing for the time of the use case execution only, and should not have a permanent semantic link to the objects that it controls.