Согласованность и трассируемость модели
Согласованность модели
Заголовок раздела «Согласованность модели»UML-диаграмма редко существует сама по себе. Обычно она показывает один взгляд на систему: требования, процесс, структуру, взаимодействие, состояние или размещение. Проблемы начинаются тогда, когда разные взгляды противоречат друг другу.
Примеры несогласованности:
- актор есть на диаграмме использования, но не описан среди пользователей или внешних систем;
- use case не связан с требованием;
- сценарий содержит шаг, которого нет на диаграмме деятельности;
- object flow показывает объект, которого нет в концептуальной модели;
- sequence diagram вызывает операцию, которой нет на технической диаграмме классов;
- state diagram описывает состояние объекта, которого нет в модели классов;
- deployment diagram не учитывает нефункциональные требования.
Такие ошибки важнее, чем визуальные недочёты. Красивая диаграмма, которая противоречит другой части модели, не помогает проектированию.
Трассируемость
Заголовок раздела «Трассируемость»Трассируемость показывает, как один артефакт модели связан с другим. Она отвечает на вопрос: откуда появился этот элемент и где он используется дальше.
Например:
- требование порождает use case;
- use case раскрывается сценариями;
- сценарий превращается в диаграмму деятельности;
- объекты из процесса становятся кандидатами в концептуальные классы;
- концептуальные классы уточняются в технические классы;
- технические классы участвуют в диаграмме последовательности;
- компоненты реализуются артефактами;
- артефакты размещаются на узлах;
- нефункциональные требования влияют на развёртывание.
Трассируемость не обязательно должна быть огромной таблицей на весь проект. Для учебной модели достаточно показать связи для нескольких ключевых требований и сценариев.
Минимальная матрица трассируемости
Заголовок раздела «Минимальная матрица трассируемости»Пример структуры:
| Требование | Use case | Сценарий | Activity | Conceptual class | Technical class | State/Sequence | Deployment |
|---|---|---|---|---|---|---|---|
| FR-01 | Оформить заказ | Основной поток оформления | Activity: оформление заказа | Order, OrderItem | OrderService, OrderDto | Sequence: checkout | Web app, backend, DB |
Такая таблица не заменяет диаграммы. Она помогает проверить, что элементы модели не появились случайно и не потерялись между уровнями.
Чек-лист согласованности
Заголовок раздела «Чек-лист согласованности»Перед завершением модели полезно проверить несколько связей:
- все акторы обоснованы через стейкхолдеров, пользователей или внешние системы;
- все use cases связаны с функциональными требованиями;
- сложные use cases раскрыты текстовыми сценариями;
- сценарии отражены на диаграммах деятельности;
- альтернативы и исключения не потеряны при переходе к activity diagram;
- объектные потоки согласованы с концептуальными классами;
- бизнес-правила отражены как guards, constraints, предусловия или переходы состояний;
- технические классы объяснимы через концептуальную модель и проектные решения;
- sequence diagram использует существующие классы и операции;
- state diagram описывает реальный жизненный цикл предметного объекта;
- deployment diagram учитывает нефункциональные требования и выбранную системную архитектуру;
- термины называются одинаково во всех артефактах.
Итоговая идея
Заголовок раздела «Итоговая идея»Смысл курса не в том, чтобы нарисовать как можно больше диаграмм. Смысл в том, чтобы построить согласованную модель информационной системы.
Каждая диаграмма должна иметь источник и продолжение. Если у элемента нет источника, непонятно, зачем он появился. Если у элемента нет продолжения, непонятно, какую роль он играет в проектировании. Согласованная модель связывает предметную область, требования, сценарии, процессы, объекты, программную структуру, компоненты, развёртывание и поведение в одну систему проектных решений.