Формы представления моделей

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

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

Даня

Смотри, какую я шикарную диаграмму модели нарисовал!

Артём

А ромбик — это что?

Даня

Ну это же очевидно… Ромбик — пользователь, я был уверен, что ты догадаешься 🥲

Артём

Вот именно поэтому у системных аналитиков есть нотация 🙃

Что такое нотация и зачем она нужна

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

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

Модели в виде диаграмм создаются с помощью разных нотаций.

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

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

Какие нотации используют системные аналитики

Одно и то же требование можно рассмотреть с разных сторон с помощью разных моделей. В свою очередь, одну и ту же модель можно отобразить с помощью разных нотаций. При этом каждая нотация хороша только для создания «своей» модели.

Системные аналитики используют нотации BPMN, нотацию Чена (названа в честь американского учёного Питера Чена), Use Case Diagram UML и многие другие. Мы рассмотрим самые популярные из них, а также изучим диаграммы, к которым применяются такие нотации.

Диаграммы бизнес-процессов

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

Ключевые характеристики бизнес-процесса:

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

Примеры бизнес-процессов:

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

Для моделирования бизнес-процессов можно использовать нотацию BPMN (Business Process Management Notation). BPMN помогает рассмотреть требование, ответив на вопросы: «Какой это бизнес-процесс? Какова его цель и как в этом процессе задействованы пользователи?» С помощью BPMN можно составить бесконечное количество диаграмм, а не одну-единственную.

Описать бизнес-процесс можно не только с помощью BPMN, но и с помощью нотации Activity Diagram UML.

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

Распределение активностей по ролям отображается в виде так называемых пулов и дорожек. Пул (от англ. swimming pool) — это группа активностей, их общий «бассейн», а дорожки определяют то, какие активности совершает каждый участник процесса.

Представьте, что вы работаете с таким требованием: «Абонент создаёт обращение в техподдержку. Его обрабатывает оператор первой линии, при необходимости он подключает оператора второй линии. Пообщавшись с операторами, абонент либо соглашается с тем, что обращение закрыто, либо переоткрывает его».

В случае с этим требованием группа активностей участников процесса (абонент, оператор первой линии, оператор второй линии) объединяется в общий пул «Обработка обращения в техподдержку».

ER-диаграммы

Если рассматривать это же требование с точки зрения того, как связаны абонент и обращение, нужно построить модель связей. Сделать это можно с помощью ERD (Entity-Relationship Diagram), которая используется при моделировании связей (relationships) между объектами системы и сущностями (entity).

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

В отличие от диаграмм бизнес-процессов ERD не показывает развитие ситуации в динамике, она демонстрирует статичное состояние сущностей системы — то, как они связаны. С помощью ERD можно ответить на вопрос: «В каких отношениях состоят разные сущности?»

Для записи ERD существуют различные специальные нотации. Одна из них называется «нотация Питера Чена» (чаще говорят «нотация Чена»). Для нашего примера (требование об обработке обращения в техподдержку) ER-диаграмма в этой нотации будет выглядеть так:

Абонент может создать несколько обращений, но у каждого обращения может быть только один автор.

Существуют и другие нотации, которые позволяют смоделировать ERD: нотация Джеймса Мартина (её ещё называют «вороньи лапки»), нотация Чарльза Бахмана, нотация IDEF1X (Integrated Definition 1Х). Они хороши для моделирования связей между сущностями, но не применимы для моделирования других аспектов (процессов, состояний).

Часто лучше дополнить ER-диаграмму словарём данных (Data Dictionary). Словарь данных — это описание статического состояния тех или иных сущностей системы без обозначения связей между ними.

Например, в словаре данных мы укажем, что сущность «обращение» содержит поля «номер» (тип данных — число), «ID абонента» (тип данных — число) и «текст» (тип данных — буквы, числа и спецсимволы).

Диаграмма Use Case

Use Case Diagram UML (Universal Modelling Language) — нотация для моделирования вариантов использования системы со стороны пользователей. Use Case Diagram позволяет изучить требование, отвечая на вопрос: «Как пользователь может воздействовать на систему?».

Вспомните наше требование:

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

Ключевой элемент для Use Case Diagram — пользователь (в нотации UML Use Case Diagram — схематичный человечек), который взаимодействует с системой. Пользователи в данном случае — абонент, операторы первой и второй линий.

State Machine Diagram

Диаграмма, которая показывает, как меняет своё состояние та или иная сущность в системе, называется диаграммой состояний. С помощью такой диаграммы можно изучить, например, как сущность «обращение в техподдержку» меняет состояние от «создана» до «в работе» и «закрыта». Диаграмму состояний можно составить в нотации State Machine Diagram UML (Universal Modelling Language).

Выберите, какую диаграмму следует применять для указанных задач.

Пользователь должен уметь выполнить в системе такие задачи как: — составить расписание дел, — отметить дело выполненным, — поручить дело другому пользователю системы.

Диаграмма Use Case

Верно, для описания вариантов использования системы пользователем используют диаграммы Use Case.

Составить схему связей между сущностями: — заказ в интернет-магазине, — покупатель.

ER-диаграмма

Верно, связи между сущностями системы описываются с помощью ER диаграмм.

Процесс отправки посылки через «Почту России»: от оформления до получения

Диаграммы бизнес-процессов

«Отправка посылки» — это бизнес-процесс, а значит моделировать нужно с помощью диаграмм бизнес-процессов (BPMN или Activity Diagram UML).

Смоделировать связь сущностей «книга», «автор» и «издательство»

ER-диаграмма

Верно, для моделирования связи между сущностями системы используют ER диаграммы.

Процесс покупки товара онлайн

Диаграммы бизнес-процессов

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

Изменение статуса сообщения, отправленного в месседжере

State Machine Diagram

Да, изменение состояния (или статуса) сообщения описывается с помощью State Machine Diagram.

Подведём итоги

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

Нотация — это набор условных обозначений. Своего рода язык символов, с помощью которого системные аналитики одинаково понимают диаграммы друг друга.
С помощью различных нотаций можно составлять модели требования и изучать разные их аспекты: от изменения состояний до внутренних связей между сущностями системы.
- Для моделирования бизнес-процессов применяют нотацию BPMN и Activity Diagram UML.
- Для ER-диаграмм можно использовать нотации: Чена, Мартина («вороньи лапки»), Бахмана, IDEF1X.
- Для моделирования вариантов использования системы применяют Use Case Diagram UML.
- Для изучения изменения состояния какой-либо сущности в системе применяют State Machine Diagram UML.