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

 

Введение

 

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

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

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

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

Динамические модели объектно – ориентированных программных систем обеспечивают представление поведения системы. Динамизм этих моделей состоит в том, что в них отражается изменение состояний в процессе работы системы. Средства языка UML для создания динамических моделей многочисленны и разнообразны [4]. Эти средства ориентированы не только на собственно программные системы, но и на отображение требований заказчика к поведению таких систем.

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

Диаграммы деятельности (activity diagrams) – это технология, позволяющая описывать логику процедур, бизнес – процессы и потоки работ. Во многих случаях они напоминают блок – схемы, но принципиальная разница между диаграммами деятельности и нотацией блок – схем заключается в том, что первые поддерживают параллельные процессы. Диаграммы деятельности подвергались самым большим изменениям при смене версий языка UML. В UML-1 диаграммы деятельности разрабатывались как особый случай диаграмм состояний. Это вызвало немало трудностей у специалистов, моделирующих потоки работ, для которых хорошо подходят диаграммы деятельности. В UML 2 это ограничение было ликвидировано.

Диаграммы состояний (state machine diagrams), называемые также конечным автоматом – это известная технология описания поведения системы. В том или ином виде диаграммы состояний существуют с 1960 года, а на заре объектно- ориентированного программирования понятие автомат применялось для представления поведения системы. Автомат (state machine) описывает поведение в терминах последовательности состояний, через которые проходит объект в течение своей жизни. Таким образом, автомат задает поведение системы, как цельной, единой сущности, моделирует жизненный цикл единого объекта. В силу этого автоматный подход удобно применять для формализации динамики отдельного, трудного для понимания блока (объекта) системы. Кроме того, диаграммы состояний являются хорошим способом представления протоколов, описывающих правильную последовательность сообщений, например, протоколов для доступа к базам данных или для обеспечения связи на основе протокола управления передачей (TCP). Диаграммы состояний идеально подходят для описания работы пользовательских интерфейсов. Если диаграммы взаимодействий хороши для понимания системы, то диаграммы состояний эффективны в определении точного поведения системы.

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

Диаграммы деятельности

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

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

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

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

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

Далее рассмотрим нотации, применяемые на диаграммах деятельности.

Деятельность (activity) – это важнейший элемент диаграмм, представляющий этап (шаг) процесса. Этап отмечен текстовым описанием, заключенным в скругленный прямоугольник.

Действие (action) – это небольшой шаг внутри деятельности. Действия появляются в четырех случаях (разделяются на четыре категории):

· Во время входа в деятельность (отмечены словом entry).

· Во время выхода из деятельности (отмечены словом exit ).

· Во время выполнения деятельности (продолжаются только в пределах деятельности и отмечены словом do ).

· При наступлении определенного события (отмечены словом event).

· Действия не обязательны, но позволяют предоставить подробности, помогающие разрабатывать систему. Если введено действие, то оно показывается внутри деятельности, в не зависимости от своей категории. Пример деятельности с действиями приведен на рис.6.2.

 

Рис.6.1 Диаграмма деятельности бронирования авиабилетов

 

Рис.6.2. Спецификация деятельности «Показ доступных рейсов»

 

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

 

⇐ Предыдущая11121314151617181920Следующая ⇒

Поделиться: