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

Цели и задачи

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

Перед тем, как делать диаграммы, опишите выбранный процесс по шагам в виде нумерованного списка. Эта часть работы проверяться не будет, но позволит вам (и нам) лучше и быстрее погрузиться в предметную область. Идеально, если в этом описании (и на диаграмме) будут задействованы варианты использования, выделенные в прошлой лабораторной на детализированной диаграмме использования.

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

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

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

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

Пример текстового описания

Обратите внимание, что это всего лишь пример, по нему не надо строить диаграммы. Также учтите, что он покрывает большое количество альтернативных потоков, вам можно не расписывать такое количество.

Пример.pdf

Оценивание

В отчёте обязательно укажите ФИО, группу и номер лабораторной работы.

Максимум за эту лабораторную работу — 8 баллов. За что снимаются баллы:

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

Методические рекомендации

Два примера диаграмм, плохой и хороший.

Какие есть ошибки на этой диаграмме: нет защитного условия на одном из переходов, в действие “Open Report Form” входит несколько переходов (и выходит тоже). За каждую такую ошибку будет снижение баллов

Более толковый вариант диаграммы: появилась параллельность с помощью fork/join node, появилось защитное условие для случая, когда все отчёты сгенерированы, добавлена merge node для слияния разных последовательных потоков управления в один, добавлен коннектор для перехода из конца в начало

Несмотря на то, что в UML поддерживаются и горизонтальные дорожки, и вертикальные, негласной практикой считается использовать именно вертикальные дорожки. Разумного объяснения нет, как и явного ограничения. При этом горизонтальные дорожки приняты, например, в BPMN.
Не забывайте про защитные условия (guards) на разветвлении управления, причём на всех выходах, в противном случае выбор конкретного пути исполнения не гарантируется. Тут же отметим, что из одного разветвления может идти больше двух вариантов.
Распространённая ошибка — проводить из одного действия несколько потоков управления сразу. Для этого используйте либо разветвление/объединение управления (decision/merge node), либо развилку/слияние управления (fork/join node).
Чтобы не тянуть стрелки через всю диаграмму (например, если по какому-то условию мы приходим к завершающим действиям прямо из начала), можно воспользоваться коннекторами. Чтобы сделать коннектор в Visual Paradigm, нужно нажать ПКМ по нужному переходу и выбрать “Split Connector”. Обратите внимание, что по нотации коннектор имеет ровно один вход и один выход.
Между заключительным состоянием деятельности (final node) и заключительным состоянием потока (activity final node) есть разница, на диаграмме должна быть хотя бы одна final node, чтобы с точки зрения семантики деятельность завершилась. При этом допускается использовать несколько final node, если это необходимо (например, чтобы не тянуть стрелки через всю диаграмму).
Чтобы обработать альтернативный поток, который распространяется на несколько шагов диаграммы, проще использовать обработку исключений.
Для циклов (особенно при работе с объектами) разумно использовать expansion region, чтоб не городить огород из проверок.
Несколько моментов, которые нужно учесть при работе с контактами:
- Нужно проставить хотя бы тип передаваемых или принимаемых данных. Это, скорее всего, будут классы, которые с высокой вероятностью окажутся на диаграмме классов в следующей лабораторной работе.
- Если для работы деятельности нужно получить несколько значений сразу (аналогия с несколькими параметрами функции), можно использовать наборы параметров.