Концептуальная модель
Когда словарь и объекты-кандидаты уже появились, их нужно собрать в концептуальную модель. Такая модель показывает, какие понятия важны в предметной области, какие связи между ними существуют, какие атрибуты значимы и какие правила ограничивают допустимые состояния.
Источники концептуальной модели
Заголовок раздела «Источники концептуальной модели»Концептуальная модель должна быть понятна не только разработчику, но и предметному эксперту. Если эксперт не может проверить, верно ли связаны заказ, клиент, платёж и доставка, значит модель слишком рано ушла в технические детали. Здесь важны понятия, связи и правила, а не механизмы реализации.
Источников у концептуальной модели несколько. Словарь даёт термины и определения. Требования показывают, какие возможности нужны системе. Сценарии и процессы показывают, какие объекты создаются и используются во времени. Бизнес-правила показывают ограничения и условия. Нефункциональные требования могут подсказать важность аудита, истории изменений или хранения событий.
Пример перехода от анализа к концептуальной модели:
| Материал анализа | Возможный элемент модели |
|---|---|
| “Студент выбирает свободный интервал” | Студент, Интервал консультации, Запись |
| “Нельзя записаться на занятый интервал” | ограничение на связь Запись — Интервал |
| “Преподаватель открывает интервалы” | Преподаватель связан с Интервалом |
| “Запись можно отменить” | состояние записи или операция отмены |
| “Отправляется уведомление” | Уведомление как событие или объект обмена |
Понятия, свойства и связи
Заголовок раздела «Понятия, свойства и связи»В концептуальной модели важно различать класс, атрибут и связь. “Статус” может быть атрибутом заявки, если он просто хранит текущее значение. Но если со статусами связаны правила перехода, история изменений и ответственные участники, статус или изменение статуса может потребовать отдельного представления. “Адрес доставки” может быть атрибутом заказа в простой системе или отдельным объектом, если с адресами связаны проверки, зоны доставки и повторное использование.
Проверять концептуальную модель удобно на экземплярах. Если модель говорит, что один заказ может иметь много позиций, можно создать пример заказа с двумя позициями и проверить кратности. Если правило говорит, что оплаченный заказ нельзя редактировать, нужно увидеть, где в модели есть состояние заказа или правило, объясняющее ограничение. Если объект не удаётся показать на конкретном примере, возможно, он выделен слишком абстрактно.
Граница с технической моделью
Заголовок раздела «Граница с технической моделью»Концептуальная модель — это не база данных и не код. Но она задаёт основу для последующих решений: какие понятия важны, какие связи нельзя потерять и какие правила должны пережить переход к реализации.
При построении концептуальной модели полезно начинать не с атрибутов, а с связей и правил. Атрибуты легко добавить позже, а неверная связь между понятиями ломает смысл модели. Например, важно понять, может ли студент иметь несколько активных записей, может ли интервал существовать без преподавателя, может ли уведомление относиться к нескольким событиям.
Технические поля вроде id, createdAt, updatedAt и deletedFlag добавляют только тогда, когда они влияют на предметный смысл, например на аудит или историю изменений.
Концептуальная модель обычно фиксируется на концептуальной диаграмме классов и объектов. Её отношения и ограничения нужно читать вместе с обзором отношений UML, а стереотипы и профили — вместе с ограничениями и OCL, если простого изображения связи недостаточно.