Разрабатывая диаграммы прецедентов, необходимо придерживаться следующих правил:
1. Рекомендуется вначале построить контекстную диаграмму, на которой отображаются основные прецеденты (функции) системы, а затем для каждого из них построить диаграммы декомпозиции (детализации).
2. Контекстная диаграмма может представлять собой несвязный граф. Ввиду того, что с системой предусматривается работа разных категорий пользователей (акторов), каждая из них задействуют только часть функциональных возможностей.
3. Чрезмерная детализация прецедентов не требуется. Следует помнить, что прецедент – это относительно крупный блок функциональности системы. Для детализации в дальнейшем будут использоваться другие виды диаграмм, более подходящие для этой цели.
4. Для лучшего восприятия отдельная диаграмма (контекстная или декомпозиции) не должна быть перенасыщена элементами. Рекомендуется отображать на диаграмме не более 15 прецедентов.
5. Располагать элементы следует так, чтобы была видна логическая последовательность выполнения прецедентов и было минимум пересечений между отношениями.
6. Перед построением диаграммы необходимо задокументировать потоки событий в системе. Поток событий – это процесс обработки данных, реализуемый в рамках одного или нескольких прецедентов. Описание потока включает информацию о том, какие обязанности возлагаются на акторов, а какие – на систему. Оно содержит:
· краткое описание поведения, реализуемого в прецеденте;
· предусловия – условия, которые должны быть соблюдены, прежде чем прецедент может быть задействован. Например, таким условием может быть завершение выполнения другого прецедента или наличие у пользователя прав доступа;
· основной поток событий описывает, что должно происходить во время выполнения прецедента в наиболее распространенном (типовом) случае. В этом случае дочерние прецеденты связаны с базовым отношением включения;
· альтернативные потоки событий описывают исключительные ситуации (например, ввод неправильного пароля или необходимость выполнения дополнительных действий). Дочерние прецеденты при разработке диаграммы связываются с базовым отношением расширения;
· постусловия – условия, которые должны быть выполнены после завершения прецедента. Например, таким условием может быть обязательное сохранение результатов расчета в базе данных на сервере.
7. На диаграммах не следует отображать особенности реализации прецедентов и внутренней организации системы, связанные со спецификой используемых программных и аппаратных средств. Данные диаграммы в первую очередь предназначены для совместного с заказчиком определения функциональных требований к системе. Поэтому понимать (интерпретировать) отображенное на диаграммах и заказчик и разработчик должны одинаково.
8. Нельзя моделировать коммуникационные связи между акторами. По определению акторы находятся вне сферы действия системы, что означает, что связи между ними также не относятся к её компетенции.
9. Нельзя соединять сплошной стрелкой (коммуникационной связью) два прецедента непосредственно. Диаграммы данного типа описывают только, какие прецеденты доступны системе, а не порядок их выполнения. Для отображения порядка выполнения прецедентов применяют диаграммы деятельности.
10. Прецедент должен быть инициирован актором. Это означает, что должна быть сплошная стрелка, начинающаяся на акторе и заканчивающаяся на прецеденте.
Прецеденты документируются следующим образом:
1. Имя прецедента. Обязательный атрибут описания.
2. Сводка. Является кратким словесным описанием прецедента; как правило, состоит из нескольких фраз. Обязательный атрибут описания.
3. Зависимости. Графическое описание зависимостей данного прецедента от других с указанием характера зависимости (включение или расширение). Необязательный атрибут описания.
4. Акторы. Графическое описание актеров, задействованных в прецеденте. Каждому актору в обязательном порядке присваивается имя. Раздел состоит, как минимум, из одного главного актора, инициирующего прецедент. Обязательный атрибут описания.
5. Описание. Текстовое описание главной последовательности. В описании перечисляются действия актора и реакция системы на них. Обязательный атрибут описания.
Пример выполнения работы
2.1. Выбор акторов и прецедентов. В этом и последующих примерах будем проектировать систему для предметной области " Предприятие по сборке и продаже компьютеров ".
Для данной предметной области выделим следующих акторов и представим их краткое описание (табл. 2.1).
Таблица 2.1
| Акторы | Краткое описание |
| Менеджер по работе с клиентами | Сотрудник, который общается с заказчиком и работает с заказом |
| Менеджер по снабжению | Сотрудник, который занимается закупкой необходимых комплектующих |
| Инженер по сборке настольных компьютеров | Сотрудник, который занимается сборкой настольных компьютеров |
| Инженер по сборке ноутбуков | Сотрудник, который занимается сборкой ноутбуков |
| Инженер по тестированию | Сотрудник, который занимается тестированием собранных компьютеров |
| Заведующий складом | Сотрудник, который заведует складом комплектующих |
Рассмотрим, какие возможности должна предоставлять система.
· Актор " Менеджер по работе с клиентами" использует систему для оформления, редактирования заказов и управления информацией о клиентах предприятия.
· Актор " Менеджер по снабжению" использует систему для просмотра перечня необходимых для закупки комплектующих и ведения информации о снабжении.
· Актор " Инженер по сборке настольных компьютеров" использует систему для просмотра нарядов на сборку персональных компьютеров, для заказа комплектующих со склада и отметки о ходе выполнения работы.
· Актор " Инженер по сборке ноутбуков" использует систему для просмотра нарядов на сборку ноутбуков, для заказа комплектующих со склада и отметки о ходе выполнения работы.
· Актор " Инженер по тестированию" использует систему для просмотра нарядов на тестирование собранной продукции и отметки о ходе выполнения работы.
· Актер " Заведующий складом" использует систему для учета поступления и выдачи комплектующих.
На основании вышеизложенного можно выделить следующие прецеденты (табл. 2.2):
Таблица 2.2
| Работа с заказом | Запускается менеджером по работе с клиентами. Позволяет вносить, изменять, удалять или просматривать заказы |
| Управление информацией о клиенте | Запускается менеджером по работе с клиентами. Позволяет добавлять, изменять или удалять клиентов, а также просматривать информацию о клиентах |
| Управление информацией о поставщиках | Запускается менеджером по снабжению. Позволяет добавлять, изменять или удалять поставщиков, а также просматривать информацию о поставщиках |
| Управление информацией о комплектующих | Запускается менеджером по снабжению. Позволяет просматривать информацию о комплектующих, производить их учет и прогнозировать их необходимое количество и делать заказы |
| Сборка компьютеров | Запускается менеджером по сборке. Позволяет просматривать наряды на сборку компьютеров и делать отметки о выполнении работ |
| Требование необходимых комплектующих | Запускается менеджером по сборке. Предназначено для затребования необходимых комплектующих со склада. |
| Тестирование компьютеров | Запускается менеджером по тестированию. Позволяет просматривать список компьютеров, подлежащих тестированию и делать отметки о выполнении работ |
| Учет поступления и выдачи комплектующих | Запускается зав. складом. Позволяет вести учет поступления и выдачи запчастей и комплектующих. |
2.2. Анализ отношений между акторами ипрецедентами. Рассмотрим теперь отношения между акторами и прецедентами. Для прецедента " Сборка компьютеров" не имеет значение, какой именно актор будет с ним взаимодействовать - " Инженер по сборке настольных компьютеров" или " Инженер по сборке ноутбуков". Поэтому мы ввели еще одного актора - " Инженер по сборке", с которым связали первых двух акторов отношением обобщения (generalization).
Отношение между прецедентами " Работа с заказом " и " Управление информацией о клиенте " - отношение расширения, поскольку когда актор " Менеджер по работе с клиентами " работает с заказом (оформляет, меняет и т.д.), то не всегда при этом он управляет информацией о клиентах. Отношение между прецедентами " Сборка компьютеров " и " Требование необходимых комплектующих " - отношение включения, поскольку для сборки компьютеров обязательно нужно заказывать необходимые комплектующие со склада.
2.3. Построение диаграммы прецедентов. Созданная диаграмма прецедентов показана на рис. 2.1.
Рис. 2.1. Главная диаграмма прецедентов
