На этом шаге рассмотрим прямое и обратное проектирование диаграмм взаимодействия.
Прямое проектирование (создание кода из модели) возможно и для диаграммы последовательности, и для диаграммы коммуникации, особенно если контекстом таковой является операция. Например, применяя диаграмму коммуникации (рис. 1, шаг 143), инструментальное средство может сгенерировать следующий код операции register (регистрировать), включенной в класс Student на языке Java:
public void register() {
CourseCollection courses = getSchedule();
for(int i = 0; i < courses.size(); i++)
courses.item(i).add(this);
this.registered = true;
}Инструментальное средство должно уметь реализовывать метод getSchedule, возвращающий объект CourseCollection (СписокКурсов), определяемый на основе сигнатуры операции. Проходя по содержимому объекта с применением стандартной идиомы итераций (о которой, безусловно, инструмент должен знать), код затем обобщается для любого количества предложенных курсов.
Обратное проектирование (воссоздание модели из кода) также возможно и для диаграмм последовательности, и для диаграмм коммуникации, особенно если речь идет о контексте операции. Сегменты предыдущей диаграммы могли бы быть восстановлены инструментом из прототипа операции register.
Однако более интересной, чем обратное проектирование модели из кода, может быть анимация модели на основе работающей системы. Например, в случае с предыдущей диаграммой инструмент может анимировать сообщения, показывая, как они передаются в работающей системе. Более того, имея такой инструмент под управлением отладчика, вы можете управлять скоростью выполнения – возможно, устанавливая точки прерывания, чтобы приостановить процесс в интересных местах и просмотреть значения атрибутов конкретных объектов.
Когда вы создаете диаграммы взаимодействия в UML, помните, что диаграммы последовательности и коммуникации являются проекциями одной и той же модели динамических аспектов системы. Ни одна диаграмма взаимодействия в отдельности не может охватить все динамические аспекты системы, а также ее подсистем, операций, классов, вариантов использования и коопераций.
Хорошо структурированная диаграмма взаимодействия наделена следующими свойствами:
- сосредоточена на передаче лишь одного аспекта динамики системы;
- включает в себя лишь те элементы, которые существенны для понимания данного аспекта;
- представляет уровень детализации, соответствующий уровню абстракции, и включает лишь дополнения, существенные для понимания диаграммы;
- не настолько лаконична, чтобы создать у читателя неверное представление о существенной семантике.
Когда вы строите диаграмму взаимодействия:
- присваивайте ей имя, соответствующее ее назначению;
- используйте диаграмму последовательности, если нужно подчеркнуть порядок сообщений во времени. Используйте диаграмму коммуникации, если хотите сделать акцент на организации объектов, участвующих во взаимодействии;
- размещайте элементы так, чтобы пересекающихся линий было как можно меньше;
- используйте примечания и выделения цветом, чтобы привлечь внимание к важным деталям диаграмм;
- не злоупотребляйте ветвлением. Вы можете гораздо лучше изобразить сложные ветвления на диаграммах деятельности.
На следующем шаге рассмотрим понятие варианта использования в UML.
