Диаграмма сотрудничества UML для системы аварийного оповещения

Question

Я работаю над некоторыми домашними заданиями по моделированию / разработке программного обеспечения, и у меня возникают проблемы, когда я не могу понять, как превратить этот конкретный пример использования в диаграмму сотрудничества. Я нашел этот превосходный учебник, но в изучаемом сценарии использования вводится компонент "UI", для которого я не могу найти аналогии.

Указанная проблема процитирована:

Название варианта использования: Сообщить об участниках, участвующих в чрезвычайных ситуациях: инициировано должностным лицом и сообщается с соответствующим потоком событий:

1. Офицер активирует функцию "Сообщить о чрезвычайной ситуации" своего терминала
2. Система отвечает, представляя форму сотруднику
3. Сотрудник заполняет форму, выбирая уровень чрезвычайной ситуации, тип, местоположение и краткое описание ситуации. Офицер также описывает возможные реакции на чрезвычайную ситуацию. Как только форма заполнена, полевой сотрудник отправляет форму.
4. Система получает форму и уведомляет корреспондента.
5. Корреспондент просматривает предоставленную информацию и создает инцидент в базе данных. Корреспондент выбирает ответ и подтверждает отчет.
6. Система отображает подтверждение и выбранный ответ сотруднику. Условие: сотрудник вошел в систему. Условие: сотрудник получил подтверждение и выбранный ответ от корреспондента, ИЛИ сотрудник получил объяснение, указывающее, почему транзакция не может быть обработана.

Насколько я понимаю, ассоциации в диаграмме Collaboration указывают на поток сообщений между объектами и не обязательно отражают физические отношения между тем, что моделируют объекты. Если это так, то какой объект должен отвечать за метод newEmergencyForm() и какой объект должен вызывать этот метод? Разве нельзя объединить метод newEmergencyForm() и метод reportEmergency() в одно целое?

Answer 1

• Теперь (текущий стандарт UML 2.4.1) диаграмма называется диаграммой связи, а не совместной. Сотрудничество остается элементом некоторых диаграмм, но у них есть другой смысл.

• Как я понимаю, Report Emergency заполняет форму. И newEmergencyForm предоставляет форму для заполнения. Это два разных действия, вы уже знаете разницу между ними, поэтому вам не нужно не замечать эту разницу и считать их за одну операцию. Но если по какой-то причине вы хотите отложить показ предмета для последующих диаграмм, вы можете сделать это. Это НЕ против стандарта.

• Я бы не назвал вещи, которые создают эти сообщения, "объектами". На этом уровне абстракции мы скорее говорим о компонентах.

• Вы не можете сказать, какой компонент создает какое-либо сообщение, пока не определите все компоненты. Вы можете сделать это в голову, это нормально, но тогда мы не можем помочь вам с выбором. Что такое "система"? (на этом уровне мы не говорим о системе в целом, это термин для варианта использования. Что такое "корреспондент"? Это то же самое, что "офицер" или может быть тем же? Или это подсистема? Какие другие компоненты у вас есть??

• В противном случае вы должны предоставить нам диаграмму компонентов в качестве источника. Кстати, я почти уверен, что после правильного определения всех компонентов вы сами найдете решение.