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

	- Актер - внешний пользователь процесса
	- Прецедент использования (бизнес-процесс)

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

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

Рис. 13.9. Диаграмма прецедентов использования

В реализации прецедента использования возможно выделение нескольких потоков событий:

· основной поток событий, который приводит к требуемому результату наиболее коротким путем, например выполнение заказа без задержек;

· альтернативные потоки событий, например временное откладывание или полный отказ от выполнения заказов. Основной и альтернативный потоки событий в модели прецедентов использования описываются в виде неформальных текстовых комментариев.

Несколько прецедентов использования может иметь общую часть, выделяемую в самостоятельный прецедент использования, с которым устанавливаются отношения использования (uses). С другой стороны, некоторые прецеденты использования могут быть расширены деталями. В таком случае создается дополнительный прецедент использования, с которым устанавливаются отношения расширения (extends). Пример применения такого рода отношений показан на рис. 13.10.

Рис. 13.10. Пример применения отношений использования и расширения

Диаграммы классов объектов (Class diagram)

Диаграммы классов объектов (Class diagram) отображают статическую структуру классов объектов. Эта диаграмма рассматривает внутреннюю структуру проблемной области, иерархию классов объектов, статические связи объектов.

Классы объектов могут иметь различные стереотипы поведения: объекты-сущности, управляющие объекты, интерфейсные объекты:

	Интерфейсный объект (Interface Object) - активный объект, форма взаимодействия информационной системы с пользователем (экранная форма, меню, командная строка, кнопка)
	Управляющий объект (Control Object) - активный объект, координирующий выполнение функций
	Сущность (Entity Object) - пассивный объект, над которым выполняются операции обработки процесса

Объекты, отражаемые в диаграмме классов объектов, связы­ваются статическими отношениями, которые отражают постоян­ные связи между объектами независимо от выполнения конкретного бизнес-процесса. К статическим отношениям относятся обобщение, агрегация, ассоциация объектов:

	Отношения ассоциации 0..l:l; 0..1:M, M:N (могут быть поименованы); 0..1 - необязательность связи; · - множественность
	Отношения обобщения (наследования)
	Отношения агрегации (целое - часть)

Пример использования статических отношений представлен на рис.13.11.

Рис. 13.11. Фрагмент диаграммы классов объектов

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

Диаграммы состояний (Statechart diagram)

Диаграмма состояний отображает поведение объектов одного класса в динамике, связь состояний объектов с событиями и определяет:

· какие типичные состояния проходит объект;

· какие события ведут к изменению состояния объекта;

· какие действия объект выполняет, когда он получает сообщение об изменении состояния;

	Входная точка
	Состояние
	Переход состояний
	Выходная точка

· как объекты создаются и уничтожаются (входные и выходные точки диаграммы).

Ниже представлены используемые в диаграмме состояний понятия и их графическое обозначение:

Входная точка определяет событие, которое образует начальное состояние объекта. В точку входа нельзя перейти из состояния объекта.

Выходная точка определяет завершение существования объекта. Из точки выхода нет перехода состояния.

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

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

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

Переход состояний описывается следующими атрибутами:

Назначение - состояние объекта, в которое перейдет объект после перехода состояния.

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

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

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

Переход состояний графически помечается меткой линии, на которой задается по крайней мере один из следующих атрибутов:

Вызов, Условие перехода, Действие.

Пример модели перехода состояний представлен на рис. 13.12.

Рис. 13.12. Пример диаграммы состояний для объекта «строка заказа»

Диаграмма взаимодействия объектов (interaction diagram)

Для каждого прецедента использования может быть построена модель динамического взаимодействия объектов, которая представляется в одной из двух форм:

· в форме диаграммы последовательностей (sequence diagram), показывающей последовательность взаимодействий на графе;

· в форме кооперативной диаграммы (collaboration diagram), показывающей взаимодействие объектов в табличной форме.

В диаграмме последовательностей взаимодействие объектов отображается в виде стрелки между объектами, которая соответствует событию или сообщению от одного объекта к другому, вызывающему выполнение метода, реагирующего на событие (сообщение) объекта. Номер стрелки соответствует номеру события в последовательности. Пример диаграммы последовательностей представлен на рис. 13.13.

Рис. 13.13. Диаграмма последовательностей для прецедента Выполнение заказа клиент.

Диаграмма кооперативного поведения представляется в табличном виде по следующим правилам.

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

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

3. На пересечении строк и столбца вертикально отображается условный отрезок времени, в течение которого выполняется то или иное действие над объектом.

Пример кооперативной диаграммы представлен на рис. 13.14.

Рис. 13.14. Диаграмма кооперативного поведения для основного потока событий прецедента использования Выполнить заказ

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

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

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

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

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

	Деятельность (activity)
	Поток от деятельности к деятельности
	Разделение потока на деятельности, выполняемые параллельно или произвольно
	Решение
	Синхронизация
	Итерация
<	Выход

Пример диаграммы деятельностей представлен на рис. 13.15.

Рис. 13.15. Диаграмма деятельностей процесса выполнения заказа

Диаграммы пакетов

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

Пакетная технология группирования классов объектов позволяет упростить:

· разработку и эксплуатацию ЭИС;

· гибкую адаптацию типовых компонентов с позиции их повтор­ного использования;

· оптимизацию клиент-серверной архитектуры ЭИС.

Обычно ЭИС разбивается на функциональные и обеспечивающие пакеты (рис. 13.16).

Рис. 13.16. Пример диаграммы пакетов

Функциональные пакеты, соответствующие решаемым проблемам (задачам), объединяются в один общий пакет «Проблемная область». Каждый пакет, в свою очередь, может быть разбит на подпакеты в соответствии с семантической близостью и теснотой взаимодействия классов объектов. Обычно пакеты проблемной области содержат иерархии обобщения и агрегации. Классы объектов, требуемые в нескольких подсистемах, выделяются в самостоятельные пакеты. В одном пакете, как правило, определяется не более 20 компонентов, обычно 5-15.

С обеспечивающей точки зрения ЭИС разбивают на пять основных пакетов:

· «Интерфейс», объекты которого реализуют функции взаимодействия пользователей с ЭИС по вводу-выводу информации и обмен сообщениями между подсистемами;

· «База данных», объекты которого выполняют доступ к дан­ным во внешней памяти;

· «Управление задачами», объекты которого осуществляют функции диспетчеризации и маршрутизации обработки объектов, например в системе управления рабочими потоками;

· «Утилиты», объекты которого осуществляют вспомогательные функции, например преобразование форматов данных;

· Обеспечивающие пакеты, т.е. работающие по принципу «клиент-серверной» архитектуры, выполняющие серверные функции для функциональных объектов-клиентов. Таким образом, обеспечивающие пакеты освобождают пользователя от знания деталей программно-технической реализации ЭИС.