На этом шаге рассмотрим прямое и обратное проектирование диаграмм деятельности в UML.
Прямое проектирование (создание кода из модели) возможно для диаграммы деятельности, особенно если ее контекстом является операция. Например, используя диаграмму, представленную на рис. 1 из шага 166, инструментальное средство может сгенерировать следующий код операции intersection на C++:
Point Line::intersection (Line : line) {
if (slope == line.slope) return Point(0,0);
int x = (line.delta – delta) / (slope – line.slope);
int y = (slope * x) + delta;
return Point(x, y);
}Здесь применена некоторая хитрость, связанная с инициализацией локальных переменных. Менее "интеллектуальный" инструмент, вероятно, сначала объявил бы переменные, а потом присвоил им значения.
Обратное проектирование (создание модели из кода) также возможно для диаграмм деятельности, особенно если контекст кода – тело операции. Диаграмма, которую мы только что упоминали, могла быть сгенерирована на основе реализации класса Line.
Более интересной по сравнению с обратным проектированием модели из кода может оказаться анимация модели по работающей системе. Скажем, имея в распоряжении все ту же диаграмму (рис. 1 шаг 166), инструмент мог бы анимировать состояния действий на ней по мере их выполнения в работающей системе. Еще лучше было бы с этим инструментом, находящимся под управлением отладчика, контролировать скорость выполнения, возможно, устанавливая точки прерывания для приостановки процесса в нужные моменты, с тем чтобы проверить значение атрибутов конкретных объектов.
Когда вы создаете диаграммы деятельности в UML, помните, что это лишь проекции одной и той же модели динамических аспектов системы. Ни одна отдельная диаграмма деятельности не может охватить все эти аспекты в совокупности. Поэтому для моделирования динамических аспектов потока работ или операции понадобится использовать множество диаграмм.
Хорошо структурированная диаграмма деятельности должна обладать следующими свойствами:
- фокусироваться на выражении лишь одного аспекта динамики системы;
- содержать только те элементы, которые важны для понимания данного аспекта;
- представлять уровень детализации, согласованный с уровнем абстракции: показывать только те дополнения, которые важны для понимания предмета;
- не быть настолько лаконичной, чтобы читатель упустил из виду важную семантику.
Когда создается диаграмма деятельности, необходимо:
- присвоить ей имя, соответствующее ее назначению;
- начинать с моделирования главного потока. Применять ветвление, параллельность и поток объектов во вторую очередь – возможно, на отдельных диаграммах;
- использовать примечания и цветовые выделения, чтобы привлечь внимание к важным моментам.
На следующем шаге рассмотрим понятие события в UML.
