Согласованность, трассируемость и типовые ошибки
Отдельная модель редко решает задачу целиком. Обычно каждый артефакт показывает один взгляд: требования, участников, сценарии, процесс, предметные объекты, программную структуру, данные или размещение. Проблемы начинаются тогда, когда эти взгляды противоречат друг другу.
Согласованность означает, что разные части модели не конфликтуют и используют один язык. Если требование говорит об “обращении”, сценарий — о “заявке”, а концептуальная модель — о “тикете”, нужно решить, это одно понятие или разные. Если процесс создаёт объект, которого нет в предметной модели, часть смысла потеряна.
Трассируемость показывает, откуда появился элемент модели и где он используется дальше. Например, требование порождает пользовательскую цель; цель раскрывается спецификацией и сценариями; сценарий уточняется процессной моделью; данные из процесса становятся кандидатами в предметные объекты; предметные объекты входят в концептуальную модель; концептуальная модель уточняется техническими классами; технические решения связываются с архитектурой данных, программной архитектурой и развёртыванием.
Примеры несогласованности:
- внешний участник есть в функциональном описании, но не описан среди пользователей или внешних систем;
- пользовательская цель не связана с требованием;
- сценарий содержит шаг, которого нет в процессной модели;
- процесс использует объект, которого нет в концептуальной модели;
- техническая модель содержит класс, не объяснимый предметной моделью или проектным решением;
- архитектурное размещение не учитывает нефункциональные требования.
Минимальная матрица трассируемости может быть небольшой. Достаточно взять три-пять важных требований и показать для каждого цепочку:
| Требование | Цель | Сценарий | Процесс | Предметные объекты | Технические элементы | Архитектурное решение |
|---|---|---|---|---|---|---|
| Студент должен записаться на консультацию | Записаться на подходящее время | основной сценарий записи | процесс выбора интервала | Студент, Интервал, Запись | BookingService, BookingRepository | веб-клиент + сервер приложения |
| Нельзя записаться на занятый интервал | Предотвратить конфликт | исключение “интервал занят” | проверка доступности | Интервал, Запись, Статус | проверка в доменной модели | транзакционное сохранение |
| Преподаватель должен получать уведомления | Узнать о новой записи | шаг отправки уведомления | процесс уведомления | Уведомление, Запись | NotificationGateway | внешний почтовый сервис |
Типовые ошибки перехода между уровнями:
- требование есть, но ни один сценарий его не покрывает;
- сценарий есть, но не связан с целью пользователя;
- процесс использует данные, которых нет в предметной области;
- объект предметной области без причины превращается сразу в таблицу или DTO;
- технический класс появляется без связи с концептуальной моделью или проектным решением;
- архитектурное решение не связано с нефункциональными требованиями;
- модель описывает реализацию, но не объясняет бизнес-смысл.
Проверку согласованности лучше выполнять не в самом конце, а после каждого перехода между уровнями. После требований стоит проверить участников и границу. После спецификации — связь целей, правил и сценариев. После процессной модели — соответствие шагов сценария и данных на потоках. После концептуальной модели — наличие объектов, которые действительно используются в процессах. После технической модели — соответствие классов выбранным сценариям и операциям.
Особенно полезно искать “висячие” элементы. Висячее требование не ведёт ни к одному сценарию. Висячий сценарий не связан с целью. Висячий объект не участвует в процессах и правилах. Висячий технический класс не нужен для реализации сценариев. Висячий сервер на схеме развёртывания не объясняется компонентами или нефункциональными требованиями. Такие элементы могут оказаться полезными, но пока их роль не доказана, они делают модель слабее.
Итоговая согласованность не означает, что модель стала окончательной. Она означает, что на текущем уровне детализации можно объяснить происхождение и назначение основных элементов. Для курса это ключевой результат: студент показывает не набор диаграмм, а связное проектное рассуждение.