Диаграммы кооперации
Поведение системы может описываться на уровне отдельных объектов, которые обмениваются между собой сообщениями, чтобы достичь нужной цели или реализовать некоторый сервис. С точки зрения аналитика или конструктора важно представить в проекте системы структурные связи отдельных объектов между собой. Такое статическое представление структуры системы как совокупности взаимодействующих объектов и обеспечивает диаграмма кооперации.
Итак, диаграмма кооперации представляет собой второй вид модели взаимодействия UML. Диаграмма кооперации предназначена для спецификации структурных аспектов взаимодействия. Главная особенность диаграммы кооперации заключается в возможности графически представить не только последовательность взаимодействия, но и все структурные отношения между объектами, участвующими в этом взаимодействии.
На диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта, его класс и, возможно, значения атрибутов. Стрелки обозначают сообщения, обмен которыми осуществляется в рамках данного варианта использования. Их временная последовательность, однако, указывается путем нумерации сообщений. Номера последовательностей фиксируют временные последовательности сообщений. Номера последовательностей необязательны. Для сложных алгоритмов бывает трудно приписать сообщениям и осмысленную временную последовательность, поэтому для выражения временных последовательностей могут потребоваться дополнительные модели (например, диаграммы видов деятельности).
Диаграмма кооперации акцентирует внимание на организации объектов, принимающие участие во взаимодействии. Для создания диаграммы кооперации нужно расположить участвующие во взаимодействии объекты в виде вершин графа. Затем связи, соединяющие эти объекты, изображаются в виде дуг этого графа. Наконец, связи дополняются сообщениями, которые объекты принимают и посылают. Это дает пользователю ясное визуальное представление о потоке управления в контексте структурной организации кооперирующихся объектов.
На нижеследующих диаграммах кооперации все объекты и сообщения были взяты из соответствующих диаграмм последовательности.
Рис.15. Диаграмма кооперации для прецедента «Добавить новый ресурс»
Рис.16. Диаграмма кооперации для прецедента «Опросить WEB-сайт»
Рис.17. Диаграмма кооперации для прецедента «Найти ресурс»
Рис.18. Диаграмма кооперации для прецедента «Сортировка результатов поиска»
Рис.19. Диаграмма кооперации для прецедента «Выбор формы результата»
6. Моделирование состояний
Модель состояний (statechart model) служит детализированным описанием класса или, более точно, динамических изменений состояний класса.
Состояние (state) объекта обозначается текущими значениями его атрибутов (как элементарных атрибутов, так и атрибутов, обозначающих другие классы). Модель состояний (statechart model) фиксирует возможные состояния, в которых может находиться класс, и эффективно фиксирует «жизненный путь» класса. На протяжении своего жизненно цикла объект остается одним и тем же – его идентичность никогда не изменяется. Однако состояние объекта изменяется.
Диаграммы состояний — хорошо известное средство описания поведения систем. В большинстве объектно-ориентированных методов диаграммы состояний строятся для единственного класса и отражают динамику поведения единственного объекта.
Диаграмма состояний представляет собой двудольный граф состояний (прямоугольников с закругленными углами) и переходов (стрелки), вызванных событиями.
Значения атрибутов объекта изменяются, однако не все подобные изменения приводят к переходу между состояниями.
Модели состояний строятся для классов, которые характеризуются не просто изменениями состояний, а изменениями состояний, представляющими определенный интерес с точки зрения предметной области. Решение о том, что представляет интерес, а что нет, является прерогативой моделирования бизнес-процессов. Диаграмма состояний представляет собой модель бизнес-правил. В течение некоторого времени бизнес-правила остаются неизменными. Они относительно независимы от конкретных прецедентов. В действительности прецеденты должны соответствовать бизнес-правилам.
Не следует строить диаграммы состояний для каждого класса в системе; их стоит использовать только для тех классов, поведение которых действительно интересует, и построение диаграмм состояний помогает лучше его понять.
Рис.20. Диаграмма состояний класса«ТАЙМЕР»
Данный класс может находится в состоянии ожидания. С определенным интервалом происходит опрос сайтов, тогда класс переходит в состояние активность, до того времени пока не произойдёт опрос всех сайтов.
Далее рассмотрим в каких состояниях может находится класс РАЗДЕЛ. Он может находится в состоянии доступен, пока не начнется реконструкция раздела. Во время реконструкции из состояния доступен класс переходит в состояние недоступен. И будет недоступен пока реконструкция не завершится. Рис. 21.
Рис.21. Диаграмма состояний класса«РАЗДЕЛ»
Далее на рисунке 22 я изобразил состояния класса РЕСУРС.
Он может быть в состоянии внесения, доступен, недоступен и удален.
В состоянии внесения класс находится тогда, когда ресурс вносят в общий список. Он может быть недоступен из-за реконструкции или плохой связи и удален, если связь долгое время не восстанавливалась.
Рис.22. Диаграмма состояний класса«РЕСУРС»
Далее рассмотрим в каких состояниях может находится класс КАТАЛОГ.
Он может находится в состоянии доступен и в состоянии обновления. На рис. 23 изображена диаграмма состояний класса КАТАЛОГ.
Рис.23. Диаграмма состояний класса«КАТАЛОГ»