Всякий раз, когда я пытался подыскать русскоязычную литературу на данную тему, меня встречала масса противоречащих друг другу материалов (даже среди соотечественников-коллег в России доводилось встречать много программистов и проектировщиков, которые путались в базовых понятиях данной предметной области, либо вовсе не знали их). Если термины проектирования и используются, то, как показывает практика, немногие знают их теоретическую основу.
Наверстать это я и поставил задачей в цикле своих статей, зная, какие каверзные вопросы часто спрашивают на интервью специальностей Database Engineer и Software Developer (случай моего коллеги: в IT-компании Мюнхена задали вопрос «что такое метамодель?»).
В своих статьях я постараюсь разложить все по полочкам, используя материалы собственных конспектов из немецкого университета (максимально простым языком, как принято в западных ВУЗ-ах). Буду рад, если они помогут. Для удобства я разбил все на пять частей, которые буду публиковать поочередно.
Всех заинтересовавшихся прошу под кат!
Итак в первой части речь пойдет о понятиях актора, прецедента, зависимости, бизнес-процесса, активности, перехода (в англоязычной терминологии: actor, use-case, dependence, business process, activity, transition).
Акторы и прецеденты
Большинство систем (в том числе и программных) создаются с учетом того, что в дальнейшем они будут использоваться некоторыми пользователями и взаимодействовать с другими системами.
Поведение пользователей, их взаимодействие с системой, поведение системы и ее частей, взаимодействие систем с другими – все это является тем содержательным аспектом работы, который необходимо формализовать. Для этого введем несколько понятий.
Сущности, с которыми система взаимодействует в процессе своей работы, называются акторами. Актором может быть человек или другая система, подсистема или класс, которые представляют нечто вне рассматриваемой системы.
Графически актор обозначается «человечком»:
Стоит отметить, что все, что находится за границами системы, моделируется только при помощи акторов, а внутри системы акторов нет.
Прецедент (UseCase) – совокупность близких по содержанию сценариев взаимодействия акторов с системой, которое осуществляется с целью получения ими некоторого полезного результата.
Прецедент представляет поведение сущности, но не показывает, как достигается некоторый результат, а только что именно выполняется для его достижения. Также можно сказать, что прецедент – описание отдельного (конкретного) аспекта поведения системы с точки зрения пользователя.
Прецеденты обозначаются эллипсом, внутри которого указано его название:
Акторы и прецеденты используются при построении диаграмм прецедентов – UseCase диаграмм. Данные диаграммы показывают отношения между внешними для системы объектами, а также их связь с самой системой, нужны для описания функционала и поведения. Таким образом, элементы диаграммы прецедентов: акторы, сами прецеденты и отношения между ними.
Диаграммы прецедентов полезны потому, что наглядно демонстрируют суть взаимодействия применительно к рассматриваемой задаче («мышление от задач»), позволяют определить профили пользователей (кто какими правами обладает и какие функции может исполнять), позволяют организовать тестирование и оптимизировать систему. На основе диаграмм прецедентов также можно сформировать удобную документацию пользователя – благодаря их наглядности.
Прецеденты могут быть классифицированы исходя из соображений их степени важности.
Выделяют три вида прецедентов:
- Главные – прецеденты, без которых система в принципе не может функционировать.
- Второстепенные – прецеденты, без реализации которых возможно частично или временное (но в конечном счете неполноценное) функционирование системы. Рассматривая все тот же случай покупки, можно предположить, что платеж через банковскую карту может быть недоступен (например, в случе отсутствия связи с банком)
- Дополнительные – прецеденты, реализация которых не оказывает существенного влияния на основную функциональность системы (таким образом, система может функционировать полноценно безотносительно их отсутствия или наличия).
Рассмотрим пример: покупка товара в супермаркете (актор – покупатель). Рассматривая действия покупателя на кассе, сложно обойти операцию платежа (в какой-либо форме – не важно, наличными или нет) – этот прецедент будет главным. Использование платежного банковского терминала можно рассматривать как второстепенный прецедент, поскольку в случае его отсутствия (поломки терминала по факту) по-прежнему можно оплатить товар наличными через кассу. Дополнительным прецедентом будет являться, например, выдача подарочного стикера продавцом (в случае если сумма товара превысит определенную сумму) – на работу системы данная функция вообще никак не влияет.
Отношения на диаграмме прецедентов обозначаются с помощью линий, соединяющих прецеденты и акторы. Существует три вида отношений: ассоциация, обобщение, зависимость.
Ассоциация – устойчивое структурное отношение между сущностями.
Зависимость – семантическое отношение между сущностями, в котором одна сущность (зависимая) обладает некоторой информацией о другой сущности (независимой).
Обобщение – это отношение между сущностью-родителем и сущностью потомком, при котором потомок является частным случаем родителя и наследует его структуру, поведение и семантику.
Зависимость – семантическое отношение между сущностями, в котором одна сущность (зависимая) обладает некоторой информацией о другой сущности (независимой).
1. Зависимость расширения – зависимость между прецедентами, в которой один прецедент (расширяющий) неявно включается в другой (расширяемый).
Расширение дополняет прецедент другими прецедентами, имеющими место при некоторых условиях. По сути оно добавляет в исходный прецедент последовательность действий, содержащуюся в другом прецеденте. Отношение расширения прецедента А к прецеденту В означает, что экземпляр прецедента В может включать в себя (при определенных условиях, которые могут быть описаны в расширении) поведение, описанное в прецеденте А.
Например:
2. Зависимость включения – зависимость между прецедентами, в которой один прецедент явно включает в себя другой прецедент, то есть в некоторой точке базового прецедента содержится поведение другого прецедента.
Включаемый прецедент не существует сам по себе, а является всего лишь частью «объемлющего» прецедента. Таким образом, базовый прецедент как бы заимствует поведение включаемых, раскладываясь на более простые прецеденты. Стрелка всегда направлена в сторону того элемента, от которого что-то требуется.
Например:
Пример
Рассмотрим реализацию системы прохождения тестов (обзорно, нам важен лишь общий принцип без учета подробностей), построим диаграмму прецедентов.
Актором будет внешний пользователь системы – тестируемый. Он может просмотреть перечень тестов – таков основной прецедент системы, связь между ним и актором – ассоциация (устойчивое структурное отношение между сущностями).
Следом возникает вопрос – какие есть возможности у актора? Во-первых, он может пройти тест, а во-вторых – может читать методические материалы к нему. Оба прецедента связаны с прецедентом «Смотреть перечень тестов» через зависимость включения, то есть рисуем пунктирную стрелку с подписью «include» в направлении к прецедентам «пройти тест» и «читать методические материалы к тесту».
Кроме того, у тестируемого пользователя может быть возможность получить сертификаты по пройденным тестам – в случае, если есть пройденные тесты. Данный прецедент связан с прецедентом «смотреть перечень тестов» посредством зависимости расширения (дополняет прецедент другим прецедентом, имеющим место при некоторых условиях). Рисуем пунктирную стрелку с надписью «extend» от прецедента «получить сертификаты» в направлении к прецеденту «смотреть перечень тестов», указывая при этом точку расширения – наличие пройденных тестов.
Бизнес-процессы и активности
Бизнес-процесс — это совокупность взаимосвязанных структурированных мероприятий или задач, направленная на создание определенного продукта или услуги для потребителя.
Иными словами, бизнес-процессом называется последовательность действий (производимых работ), преобразовывающих входные данные (ресурсы) в конечный измеримый результат, соответствующий поставленной задаче.
Бизнес-процессы могут быть наглядно отображены (смоделированы) на диаграмме активностей – Activity Diagram.
Моделирование бизнес-процессов производится в несколько шагов, первым из которых является их разбиение на составляющие части. Далее выделяются участники (и создаются для них «дорожки» – части области диаграммы, где отображаются только те действия, за которые отвечает конкретный участник), определяются условия, при которых выполняется каждый процесс, описываются переходы, отображаются активности.
Активность – состояние объекта (группы объектов), в котором он (они) выполняет некоторые действия. На диаграмме активностей отображается в виде прямоугольника с закругленными углами.
Например, активностью, присущей анкетируемому, является «заполнение анкеты»:
Существует два варианта перехода: простой (срабатывает в момент завершения активности, у каждой активности входящих переходов может быть несколько, исходящих — только один; сам переход обозначается стрелкой) и условный. Остановимся подробнее на условном переходе.
При описании бизнес-процесса возникают ситуации, когда переход к следующей активности зависит от какого-либо условия. Для отражения таких ситуаций на диаграмме активности применяют условный переход, обозначающийся ромбом и стрелками.
У каждой активности также, как и в случае с простыми переходами, может быть несколько входящих условных переходов (на диаграмме: «стрелки, идущие от ромба»), но исходящим является всегда один – будь то простой (на диаграмме: «стрелка, идущая к следующей активности») или условный (на диаграмме: «стрелка, идущая к ромбу»). Условный переход срабатывает в момент завершения активности и проверки условия.
Например, в случае с проведением анкетирования, у активности «проверка анкеты» может быть условный переход с двумя вариантами развития событий: «анкета забракована» (заполнена неправильно) и «анкета прошла проверку» (заполнена корректно). Первый вариант приведет к активности «удаление анкеты», второй – к активности «учет результатов анкеты».
Для организации взаимодействия активностей также используют разветвители и синхронизаторы.
Разветвители используются в том случае, когда после срабатывания одной активности, должны сработать сразу несколько других.
Синхронизаторы используются тогда, когда для срабатывания активности необходимо выполнение нескольких предыдущих действий, при чем эти действия должны выполниться обязательно все.
Пример
Рассмотрим пример с заполнением и проверкой анкет подробнее – построим полную диаграмму активностей. Участниками будут: анкетируемый, отдел обработки, отдел аналитики; следует проиллюстрировать три соответствующие вертикальные «дорожки», разделенные пунктирными линиями.
Анкетируемый заполняет анкету – следовательно, описываем активность «заполнение анкеты». Далее анкета попадает в отдел обработки, где происходит ее проверка; вводим активности «проверка анкеты» и «удаление анкеты». Если анкета не прошла проверку, она удаляется, в противном случае – попадает в отдел аналитики; используем условный переход для описания этого механизма.
Активность, рассмотренную выше как «учет результатов анкеты», конкретизируем: при просмотре одобренной анкеты в отделе аналитики, надлежит обработать заполненные анкетируемым ответы и дополнительно определить место проведения анкетирования (например, регион, город, и т.д.), после чего занести результат анкетирования в базу. Следовательно, сначала вводим разветвитель и описываем действия «обработка ответов» и «определение места проведение», после чего вводим синхронизатор и описываем активность «занесение результатов анкетирования в базу»,
Примечание: темным кружком обозначается состояние начала деятельности, темным кружком с белым обрамлением – конец.
Послесловие
Такой получилась первая статья из цикла о Basic Information System Design. Задавайте вопросы, постараюсь всем ответить. Будут замечания – исправлюсь, и в новых статьях тоже учту.
ссылка на оригинал статьи https://habr.com/post/422063/
Добавить комментарий