Нотации и представления системы
Модель может быть просто текстовой. Мы можем записать требования, описать процесс словами, составить словарь терминов или зафиксировать проектное решение. Для небольших задач этого может быть достаточно. Но уже для проектов среднего масштаба текст начинает мешать: в нём плохо видны структура, параллельные ветви процесса, связи между объектами, зависимости между частями системы и размещение программных артефактов.
В какой-то момент рука сама тянется рисовать: на бумаге, в draw.io, Miro или любом другом инструменте. Даже конуру в идеале хочется нарисовать и по рисунку строить. Но у рисунков появляется отдельная проблема: нужно объяснить, какой элемент что значит. Если каждый рисует по-своему, велик риск, что все оставят всё на уровне устных договорённостей.
Нотация — это набор правил, по которым записывается модель. Она определяет, какие элементы можно использовать, как они выглядят, какие связи допустимы и что эти связи означают. Простая стрелка в неформальном рисунке может означать порядок действий, передачу данных, зависимость, сетевое соединение или направление чтения. В формальной нотации эти значения разводятся.
В проектировании ИС встречаются разные нотации и языки описания:
- блок-схемы подходят для простых алгоритмов и учебных примеров;
- IDEF и EPC исторически использовались для описания функций и бизнес-процессов;
- BPMN хорошо показывает бизнес-процессы, события и взаимодействие участников;
- ER-модели помогают описывать структуру данных;
- UML описывает объектные, поведенческие, компонентные и deployment-представления;
- C4 помогает компактно показать архитектуру программной системы на нескольких уровнях;
- SysML применяется для системной инженерии и сложных технических систем.
Представление системы — это не то же самое, что нотация. Представление отвечает на вопрос, какой аспект системы мы показываем. Например, функциональное представление говорит о возможностях системы, процессное — о ходе работы, информационное — о предметных объектах, программное — о классах и компонентах, системное — о размещении и средах выполнения.
Одна ошибка встречается очень часто: автор пытается поместить все вопросы на одну схему. На диаграмме появляются пользователи, экраны, классы, таблицы, серверы, кнопки и базы данных одновременно. Такая схема может быть полезной как черновой набросок, но как учебная и тем более реальная модель она слабая: непонятно, какой уровень она описывает и какие правила чтения применяются. Лучше сделать несколько небольших представлений, чем одну перегруженную “карту всего”.
Для выбора формы можно использовать простой ориентир:
| Нужно понять | Подходящая форма |
|---|---|
| кто заинтересован в системе | список стейкхолдеров, контекстная схема |
| что система должна делать | требования, варианты использования |
| как выполняется работа | сценарий, процессная модель, диаграмма деятельности |
| какие понятия важны | словарь, концептуальная модель классов |
| как устроена реализация | техническая модель классов, пакеты, компоненты |
| где работает система | системная архитектура, диаграмма развёртывания |
UML в этом курсе важен именно как язык фиксации отдельных представлений. Но перед использованием любой диаграммы нужно понять, какое утверждение о системе она должна сделать.