Моделирование взаимодействий

Моделирование взаимодействий (interaction modeling)охватывает вопросы взаимодействия между объектами, необходимыми для выполнения прецедента.

Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Говоря об этих диаграммах, имеют в виду два аспекта взаимодействия. Во-первых, взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности.

Вторым видом диаграммы взаимодействия является диаграмма коопераций, в которых основное внимание уделяется отношениям между объектами.

Изобразим диаграммы последовательности для прецедентов проектируемой системы. Так как данные диаграммы вполне наглядны и понятны, из них сразу же можно понять какие выполняются действия и какова их последовательность, то они не будут сопровождаться подробным описанием, а расписаны будут только какие-либо дополнения, внесенные в диаграммы на данном этапе.

Рис.10. Диаграмма последовательности для прецедента «Добавить новый ресурс»

 

Проанализировав данную диаграмму можем сказать, что у нас появились дополнительные пограничные классы(ОКНО, БД) и управляющий(СЕРВЕР).

Также на этой диаграмме видно, какие операции они выполняют. Эти классы мы позже занесём в статическую диаграмму.

Далее рассмотрим диаграмму последовательности для прецедента

«Опросить WEB-сайт» рис. 11.

Сервер с определённым интервалом посылает запрос на обновление. И проверяет обновилась информация на сайтах или нет. Если информация обновилась то сразу же в БД происходит обновление ресурсов.

 

Рис.11. Диаграмма последовательности для прецедента «Опросить WEB-сайты»

 

 

Далее рассмотрим диаграмму последовательности для прецедента

«Найти ресурс» рис. 12.

Пользователь сначала открывает окно. Потом он заполняет строку поиска и посылает запрос на сервер. Сервер, как управляющий класс проверяет запрос и обращается к своей БД, для того чтобы найти нужный ресурс. Когда находит нужную информацию посылает результат пользователю.

 

 

Рис.12. Диаграмма последовательности для прецедента «Найти ресурс»

 

 

Диаграмма последовательности видов деятельности для прецедента «Поиск среди найденных результатов» будет такая же как на рис. 12. Поэтому я решил её ещё раз не рисовать.

Далее рассмотрим диаграмму последовательности вида деятельности «Сортировка результатов поиска» рис. 13.

Пользователь открывает окно. Задаёт параметры сортировки и посылает на сервер. Сервер обращается к своей БД и происходит сортировка. Впоследствии результат сортировки отображается на экране.

 

 

 

Рис.13. Диаграмма последовательности для прецедента «Сортировка результатов поиска»

 

Далее рассмотрим диаграмму последовательности вида деятельности «Выбор формы результата» рис. 14.

Для того, чтобы пользователь мог выбрать себе в какой форме бы он хотел получить информацию(полной или частичной), надо сперва открыть окно, затем выбрать нужную форму(заполнить) и послать на сервер. Сервер анализирует данные производит поиск и выдаёт(помещает на экран) информацию пользователю в нужной форме. Для более наглядного представления я и нарисовал данную диаграмму.

Рис.14. Диаграмма последовательности для прецедента «Выбор формы результата»

Диаграммы кооперации

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

Итак, диаграмма кооперации представляет собой второй вид модели взаимодействия UML. Диаграмма кооперации предназначена для спецификации структурных аспектов взаимодействия. Главная особенность диаграммы кооперации заключается в возможности графически представить не только последовательность взаимодействия, но и все структурные отношения между объектами, участвующими в этом взаимодействии.

На диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта, его класс и, возможно, значения атрибутов. Стрелки обозначают сообщения, обмен которыми осуществляется в рамках данного варианта использования. Их временная последовательность, однако, указывается путем нумерации сообщений. Номера последовательностей фиксируют временные последовательности сообщений. Номера последовательностей необязательны. Для сложных алгоритмов бывает трудно приписать сообщениям и осмысленную временную последовательность, поэтому для выражения временных последовательностей могут потребоваться дополнительные модели (например, диаграммы видов деятельности).

Диаграмма кооперации акцентирует внимание на организации объектов, принимающие участие во взаимодействии. Для создания диаграммы кооперации нужно расположить участвующие во взаимодействии объекты в виде вершин графа. Затем связи, соединяющие эти объекты, изображаются в виде дуг этого графа. Наконец, связи дополняются сообщениями, которые объекты принимают и посылают. Это дает пользователю ясное визуальное представление о потоке управления в контексте структурной организации кооперирующихся объектов.

На нижеследующих диаграммах кооперации все объекты и сообщения были взяты из соответствующих диаграмм последовательности.

 

 

 

Рис.15. Диаграмма кооперации для прецедента «Добавить новый ресурс»

 

 

 

Рис.16. Диаграмма кооперации для прецедента «Опросить WEB-сайт»

Рис.17. Диаграмма кооперации для прецедента «Найти ресурс»

 

 

 

Рис.18. Диаграмма кооперации для прецедента «Сортировка результатов поиска»

Рис.19. Диаграмма кооперации для прецедента «Выбор формы результата»

 

МОДЕЛИРОВАНИЕ СОСТОЯНИЙ

 

Модель состояний (statechart model) служит детализированным описанием класса или, более точно, динамических изменений состояний класса.

Состояние (state) объекта обозначается текущими значениями его атрибутов (как элементарных атрибутов, так и атрибутов, обозначающих другие классы). Модель состояний (statechart model) фиксирует возможные состояния, в которых может находиться класс, и эффективно фиксирует «жизненный путь» класса. На протяжении своего жизненно цикла объект остается одним и тем же – его идентичность никогда не изменяется. Однако состояние объекта изменяется.

Диаграммы состояний — хорошо известное средство описания поведения систем. В большинстве объектно-ориентированных методов диаграм­мы состояний строятся для единственного класса и отражают дина­мику поведения единственного объекта.

Диаграмма состояний представляет собой двудольный граф состояний (прямоугольников с закругленными углами) и переходов (стрелки), вызванных событиями.

Значения атрибутов объекта изменяются, однако не все подобные изменения приводят к переходу между состояниями.

Модели состояний строятся для классов, которые характеризуются не просто изменениями состояний, а изменениями состояний, представляющими определенный интерес с точки зрения предметной области. Решение о том, что представляет интерес, а что нет, является прерогативой моделирования бизнес-процессов. Диаграмма состояний представляет собой модель бизнес-правил. В течение некоторого времени бизнес-правила остаются неизменными. Они относительно независимы от конкретных прецедентов. В действительности прецеденты должны соответствовать бизнес-правилам.

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

Рис.20. Диаграмма состояний класса«ТАЙМЕР»

Данный класс может находится в состоянии ожидания. С определенным интервалом происходит опрос сайтов, тогда класс переходит в состояние активность, до того времени пока не произойдёт опрос всех сайтов.

Далее рассмотрим в каких состояниях может находится класс РАЗДЕЛ. Он может находится в состоянии доступен, пока не начнется реконструкция раздела. Во время реконструкции из состояния доступен класс переходит в состояние недоступен. И будет недоступен пока реконструкция не завершится. Рис. 21.

 

 

Рис.21. Диаграмма состояний класса«РАЗДЕЛ»

Далее на рисунке 22 я изобразил состояния класса РЕСУРС.

Он может быть в состоянии внесения, доступен, недоступен и удален.

В состоянии внесения класс находится тогда, когда ресурс вносят в общий список. Он может быть недоступен из-за реконструкции или плохой связи и удален, если связь долгое время не восстанавливалась.

 

 

 

Рис.22. Диаграмма состояний класса«РЕСУРС»

 

 

Далее рассмотрим в каких состояниях может находится класс КАТАЛОГ.

Он может находится в состоянии доступен и в состоянии обновления. На рис. 23 изображена диаграмма состояний класса КАТАЛОГ.

 

Рис.23. Диаграмма состояний класса«КАТАЛОГ»