От бизнес-правил к данным. Почему я выбрал ORM2 и сделал свое SPA-приложение

На старте почти любого проекта бизнес-аналитик оказывается в одной и той же ситуации. Бизнес говорит: «клиент может иметь несколько договоров», «договор относится только к одному клиенту», «товар идентифицируется артикулом».

Эти формулировки понятны предметным экспертам, но в таком виде их не передашь архитектору данных или команде разработки — для них это еще не техническое задание. Неясно, где здесь сущность, а где значение, что будет идентификатором, какие ограничения критичны, а какие можно оставить на уровне процессов.

На этом шаге аналитик становится переводчиком между двумя мирами. Нужен промежуточный слой — формальное, проверяемое описание предметной области. Таким слоем часто становится концептуальная модель данных: она помогает согласовать термины между бизнесом и ИТ, зафиксировать правила до проектирования таблиц и API, увидеть противоречия и пробелы в требованиях, отделить смысл данных от будущей технической реализации.

Меня зовут Вадим Скляров, я бизнес-аналитик проектного офиса МТС Медиа. В этом материале расскажу, почему для этой задачи я выбрал ORM2 в качестве инструмента концептуального моделирования, какие приложения есть на рынке, почему в итоге понадобилось собственное SPA-приложение и чем оно оказалось полезным.

Зачем бизнес-аналитику концептуальная модель

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

Если пропустить эти шаги, команда почти неизбежно начинает спорить уже на техническом уровне — о таблицах, связях, nullable-полях и типах идентификаторов — хотя на самом деле еще не договорилась о смысле.

Почему именно ORM2

ORM2 (Object-Role Modeling 2) — это подход к описанию предметной области через элементарные факты и ограничения. ORM2 предлагает смотреть на модель как на набор утверждений вида:

• клиент оформляет заказ.

• заказ имеет номер.

• Товар идентифицируется Артикулом.

• Каждый Заказ оформляет только один Клиент.
  

То есть в центре внимания не таблица или класс, а факт и правило его существования.

Если для бизнеса важнее простота и проверяемость, то для архитекторов данных — выразительность и семантическая точность. ORM2 как раз  закрывает обе задачи. Его сильные стороны:

1. Факт-ориентированность: модель строится вокруг бизнес-фактов, а не вокруг технической структуры хранения.

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

3. Богатый набор ограничений: ORM2 хорошо работает с обязательностью, уникальностью, внешними ограничениями, подмножествами, исключениями, частотами и другими правилами, которые в более популярных нотациях нередко выражаются хуже или уходят в текстовые комментарии.

4. Семантическая устойчивость: в ORM2 легче отделить смысл модели от формы будущей реализации. Мы не слишком рано «сворачиваем» знания бизнеса в таблицы и атрибуты.

5. Хорошая связь с дальнейшей трансформацией: из ORM2 можно переходить к ER-представлению, реляционной модели, XML-структурам и другим целевым формам.

ORM2 часто сравнивают с ER-диаграммами и UML. Подробный разбор всех трех нотаций есть в книге «Information Modeling and Relational Databases, 3rd Edition» — повторять его здесь не буду. Отмечу лишь, что меня привлекла возможность строить модель на основе текстового описания бизнес-правил и при необходимости транслировать ее в ER-представление.

Почему я решил написать еще один редактор диаграмм

Экосистема ORM2 заметно уже, чем у ER и UML. Методология сильная, но инструментальный рынок у нее нишевый. В качестве рабочего инструмента для своих задач я пробовал использовать NORMA, DogmaModeler, CaseTalk и Microsoft Visio. И понял, что для моей задачи не хватает конкретного набора свойств.

Мне нужен был инструмент, который решает сразу несколько повседневных проблем аналитика.

1. Быстрое моделирование без разворачивания среды. Открыл локальную страницу — и работаешь.

2. Прямой переход от текста бизнеса к модели. Не только рисовать мышкой, но и вводить правила в текстовом виде.

3. Прозрачный мост к архитекторам данных. Сохранять ORM как первичный источник смысла, но уметь показывать модель и как Barker ER.

4. Локальная работа с чувствительными данными. Без обязательного сервера, без сложного доступа, без лишней передачи артефактов наружу.

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

Так появился собственный браузерный редактор — SPA-приложение для просмотра, редактирования и преобразования ORM-моделей.

Стоит оговориться: такое приложение не заменяет enterprise CASE-средства. Если нужны крупный корпоративный репозиторий, строгие процессы согласования, богатая командная коллаборация или широкая интеграция с governance-стеком — специализированные платформы все равно нужны. Но если задача — быстро перевести бизнес-правила в концептуальную модель и показать ее архитектору данных — такое приложение, на мой взгляд, очень полезно.

Что умеет самописное SPA-приложение

Если описывать коротко, это локальный визуальный редактор ORM2-моделей с текстовым входом бизнес-правил и альтернативным ER-представлением.

Базовые возможности

Приложение позволяет:

• загружать и сохранять ORM-модели;

• визуально редактировать объекты, факты, роли и ограничения;

• работать с типами объектов EntityType и ValueType;

• создавать унарные, бинарные и тернарные факты;

• задавать обязательность, уникальность и кардинальности ролей;

• экспортировать диаграмму в SVG и PNG.

Работа с бизнес-правилами

Отдельный важный блок — текстовый ввод бизнес-правил. Аналитик вводит правила на русском языке, приложение разбирает формулировки, создает или дополняет факты, применяет ограничения, показывает диагностику по текущей строке и вербализует диаграмму обратно в текст. Это особенно полезно в живой аналитической сессии, когда модель строится буквально со слов эксперта.

Альтернативная нотация: Barker ER

Одна из ключевых функций — трансформация ORM в Barker ER. Бизнесу проще обсуждать правила в ORM-логике, архитекторам данных привычнее смотреть на ER-представление, а одна и та же модель может быть показана двум аудиториям без потери исходного источника.

Приложение позволяет переключать режим показа ValueType — как отдельных элементов или как атрибутов сущности — и фиксирует, что при преобразовании ORM в ER часть семантики теряется.

Что особенно ценно

Ниже — особенности, которые лично для меня оказались принципиальными.

• Локальный SPA-формат, благодаря которому можно начать моделирование без сервера, отдельного деплоя и согласований.

• Русскоязычный текстовый ввод правил. Инструмент работает с формулировками бизнеса напрямую, а диаграмма строится уже на их основе.

• Двусторонняя связка «текст ↔ диаграмма» дает возможность в любой момент получить вербализацию модели — читаемые предложения, понятные бизнесу.

• ORM как первичная модель, Barker ER как представление. Это важный архитектурный выбор. ER здесь не заменяет ORM, а выступает как производная визуализация для другой аудитории. 

• Компактный ORM-XML, удобный для обмена и AI-обработки. Модель хранится в формате, который удобно читать, версионировать и использовать в интеграции с LLM-помощниками.

Пример: как можно построить модель за несколько минут

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

Шаг 1. Формулируем правила так, как это обычно делает бизнес

Как правило, после первых установочных встреч с бизнесом аналитик может описать бизнес-правила на естественном языке. SPA-приложение понимает правила, составленные по одному из шаблонов:

• Сущность> определяется через { <ключ1>, <ключ2>, ... }

• <Сущность> имеет атрибут <Название_атрибута>

• <Сущность1> <предикат> <квантор> <Сущность2>

• <Сущность1> <предикат> <Сущность2> и <Сущность3>

• <Сущность> <свойство/предикат> - унарный факт

Предикат это роли, например, «имеет» , «включает в себя»? Кванторы — ограничения:

• один или более = один или несколько

• только один = ровно один

• не более одного = ноль или один

• ноль или несколько = ноль или более

В нашем примере бизнес-правила будут следующими:

КонцертнаяПлощадка определяется через {Название}
КонфигурацияПлощадки определяется через {Название}
КонцертнаяПлощадка включает один или более КонфигурацияПлощадки
КонфигурацияПлощадки принадлежит одна или более КонцертнаяПлощадка

ДоговорРасходный определяется через {номер, дата}
КонцертнаяПлощадка заключает один или более ДоговорРасходный ДоговорРасходный относится только к одна КонцертнаяПлощадка

Услуга определяется через {название}
ДоговорРасходный включает одна или несколько Услуга
Услуга включается в один или несколько ДоговорРасходный

ПоставщикУслуги определяется через {ИНН, КПП}
ПоставщикУслуги заключает один или несколько ДоговорРасходный
ДоговорРасходный заключается только один ПоставщикУслуги

ДоговорДоходный определяется через {номер, дата}
КонцертнаяПлощадка заключает один или более ДоговорДоходный
ДоговорДоходный относится только к одна КонцертнаяПлощадка

ОрганизаторМероприятия определяется через {ИНН, КПП}
ОрганизаторМероприятия заключает один или несколько ДоговорДоходный
ДоговорДоходный заключается только один ОрганизаторМероприятия

Мероприятие определяется через {название, дата}
Мероприятие организует только один ОрганизаторМероприятия
ОрганизаторМероприятия организует один или более Мероприятие
ДоговорДоходный заключается только на один Мероприятие
Мероприятие проводится только по один ДоговорДоходный
Мероприятие имеет только один КонфигурацияПлощадки
КонфигурацияПлощадки относится к один или более Мероприятие

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

Шаг 2. Генерируем модель по правилам

Вставляем бизнес-правила в приложение:

Для каждого правила выполняется валидация: распознаются типы объектов, факты, определяется обязательность и уникальность, подсвечиваются ошибки, если формулировка неоднозначна. После валидации нажимаем «Применить правила» — приложение генерирует модель в ORM2.

Шаг 3. Проверяем модель с бизнесом через вербализацию

Одна из самых полезных возможностей нотации ORM вообще и приложения в частности: модель можно прочитать как набор фраз. Это позволяет проверить смысл: действительно ли доходный договор всегда относится только к одной площадке, может ли поставщик оказывать услугу без договора, чем является дата проведения мероприятия — атрибутом первичного ключа или самостоятельным объектом предметной области и так далее. 

Вербализация обновляется динамически, при каждом изменении диаграммы. Выбранное правило подсвечивает сущность или факт, к которому оно относится.

Шаг 4. Показываем архитектору ER-представление

ORM2 удобна для концептуального уровня и диалога с бизнесом, а для логического моделирования в приложении предусмотрено переключение на Barker ER. При этом исходная аналитическая модель останется ORM-источником.

Выводы

На практике ORM2 оказалась полезной методологией для бизнес-аналитика при построении концептуальной модели данных. Она позволяет быстрее и лучше понять предметную область, сокращает время на сбор и описание бизнес-правил во время встреч с заказчиком и уменьшает неоднозначность формулировок.

Разработанное SPA-приложение — вспомогательный инструмент, который помогает быстро строить диаграммы концептуальной модели в ORM2.