Моделирование поведения системы, какие модели используются для этих целей и каким образом отображаются на них события и сообщения между объектами системы. (179)
Диаграммы деятельности (activity diagrams) – это технология, позволяющая описывать логику процедур, бизнес – процессы и потоки работ. Во многих случаях они напоминают блок – схемы, но принципиальная разница между диаграммами деятельности и нотацией блок – схем заключается в том, что первые поддерживают параллельные процессы. Диаграммы деятельности подвергались самым большим изменениям при смене версий языка UML. В UML-1 диаграммы деятельности разрабатывались как особый случай диаграмм состояний. Это вызвало немало трудностей у специалистов, моделирующих потоки работ, для которых хорошо подходят диаграммы деятельности. В UML 2 это ограничение было ликвидировано. Диаграммы состояний (state machine diagrams), называемые также конечным автоматом – это известная технология описания поведения системы. В том или ином виде диаграммы состояний существуют с 1960 года, а на заре объектно- ориентированного программирования понятие автомат применялось для представления поведения системы. Автомат (state machine) описывает поведение в терминах последовательности состояний, через которые проходит объект в течение своей жизни. Таким образом, автомат задает поведение системы, как цельной, единой сущности, моделирует жизненный цикл единого объекта. В силу этого автоматный подход удобно применять для формализации динамики отдельного, трудного для понимания блока (объекта) системы. Кроме того, диаграммы состояний являются хорошим способом представления протоколов, описывающих правильную последовательность сообщений, например, протоколов для доступа к базам данных или для обеспечения связи на основе протокола управления передачей (TCP). Диаграммы состояний идеально подходят для описания работы пользовательских интерфейсов. Если диаграммы взаимодействий хороши для понимания системы, то диаграммы состояний эффективны в определении точного поведения системы. Диаграммы взаимодействия (interaction diagrams) описывают взаимодействие групп объектов в различных условиях их поведения (в различных сценариях). UML определяет диаграммы взаимодействия нескольких типов, из которых, наиболее употребительными, являются диаграммы последовательности. Обычно диаграмма последовательности описывает один сценарий, как правило, основной. На этой диаграмме показаны экземпляры объектов и сообщения, которыми объекты обмениваются в рамках одного варианта использования. Именно поэтому диаграммы взаимодействия считаются основным аппаратом для фиксации полной динамики системы.
27. Диаграмма последовательности: элементы диаграммы, что и как она описывает, продемонстрировать пример диаграммы последовательности для сценария "Покупка бензина на автозаправочной станции". (191) Для пояснения концепций диаграмм взаимодействия, используем пример реализации функции поиска вакансий работ на сайте jobs.com[10]. На рисунке 6.11 показан один из вариантов диаграммы последовательности для этой функции.
Рис. 6.11. Детализированная диаграмма последовательности для функции поиска вакансий на сайте
На этом рисунке имеем клиента (соискатели), страницу поиска и поисковую систему. Используем параметрический объект КритерииПоиска для хранения, проверки и передачи введенной клиентом информации. На диаграмме отображен тот факт, что поисковая система производит чтение информации о вакансии из базы данных (на этом этапе объект БазаДанных может представлять собой интерфейс доступа к данным), а также что этот объект помещает прочтенную информацию в объект СписокПодходящихВакансий. Полученную диаграмму можно реализовать с очень малым уровнем неоднозначности. Участвующие в потоке объекты нарисованы в прямоугольниках в верхней части диаграммы. Остальные объекты, так называемые объекты инфраструктуры, находятся на серверной стороне и отражают серверную логику, серверные страницы, интерфейсы и другие подобные объекты. Некоторые объекты имеют имена своих классов (необязательно присваивать объектам имена, отличающиеся от имен классов). У каждого объекта имеется линия жизни, изображаемая в виде вертикальной штриховой линии под объектом. Эта линия начинается, когда создается экземпляр объекта, и заканчивается в точке разрушения объекта. Сообщения, соответствующие коммуникациям между объектами, рисуют между линиями жизни объектов. Сообщение показывает, что объект-клиент вызывает операцию объекта-сервера. При генерации кода, сообщения транслируются в вызовы методов объекта-сервера. Сообщения должны располагаться в хронологическом порядке сверху вниз. Далее, после определения операций класса, каждое сообщение станет операцией. Сообщения могут быть рефлексивными, что соответствует обращению объекта к своей собственной операции. На диаграммах последовательности можно показывать активизацию (focus of control). Активизация – это маленький прямоугольник, поясняющий интервал активности объекта при взаимодействии. Активность соответствует времени нахождения в стеке одного из методов объекта. В языке UML полосы активности не обязательны, но считается, что они исключительно удобны при пояснении поведения. Штриховая стрелка обозначает возврат для вызова. Их следует применять, только когда это дает дополнительную информацию, в противном случае они просто вносят неразбериху.
|