Хорошая и плохая модель
Моделирование не существует само по себе. Оно решает несколько практических задач: визуализирует систему в текущем или желаемом состоянии, определяет структуру и поведение, создаёт шаблон для дальнейшего создания системы и документирует принимаемые решения.
Поэтому качество модели нельзя оценивать только по внешнему виду. Красивая схема может быть бесполезной, если она не отвечает на вопрос, ради которого была создана. Небольшая таблица или текстовое описание может быть ценнее сложной диаграммы, если оно точно фиксирует важное решение.
Хорошая модель имеет несколько признаков:
- отвечает на конкретный вопрос;
- имеет понятный уровень абстракции;
- не содержит деталей, которые не нужны для этого вопроса;
- использует термины, понятные предполагаемому читателю;
- помогает принять или проверить проектное решение;
- может быть сопоставлена с другими материалами курса.
Выбор модели оказывает определяющее влияние на подход к решению проблемы. Если смотреть на систему как на набор экранов, легко пропустить предметные правила и жизненный цикл объектов. Если смотреть только на базу данных, можно потерять пользовательские цели. Если смотреть только на процессы, можно недооценить программную архитектуру. Поэтому нельзя ограничиваться созданием только одной модели: сложная ИС требует совокупности нескольких представлений.
Например, для системы доставки одной модели будет недостаточно. Функциональное описание поможет понять, кто работает с системой и какие цели преследует. Процессная модель покажет оформление заказа и обработку исключений. Предметная модель поможет выделить заказ, клиента, доставку, платёж и связи между ними. Программная модель покажет сервисы, интерфейсы и зависимости. Системная модель покажет, где находятся клиентское приложение, сервер и база данных.
Плохая модель обычно нарушает один из принципов. Она может быть слишком общей и не помогать принимать решения: “система управляет заказами” не объясняет, кто создаёт заказ, когда он меняет состояние и какие правила действуют. Она может быть слишком детальной и фактически дублировать код. Она может использовать термины, которые не совпадают с требованиями и сценариями.
Для практической проверки полезно смотреть не на модель целиком, а на её элементы:
| Элемент модели | Проверочный вопрос | Признак проблемы |
|---|---|---|
| Участник | какую цель он достигает? | роль есть, но не участвует во взаимодействиях |
| Требование | можно ли проверить выполнение? | формулировка вроде “удобная система” |
| Действие процесса | кто его выполняет и зачем? | действие описано технически, без предметного смысла |
| Предметный объект | какие правила или состояния с ним связаны? | объект появился только как существительное из текста |
| Технический класс | какую ответственность он несёт? | класс повторяет шаблон фреймворка без связи со сценарием |
| Узел развёртывания | какую среду или ограничение он отражает? | сервер нарисован “для красоты” |
Особенно опасна несогласованность. Если в требованиях используется термин “обращение”, в сценариях “заявка”, а в модели объектов “тикет”, участники начинают спорить не о системе, а о словах. Если процесс использует объект, которого нет в предметной модели, часть смысла потеряна. Если технический класс появляется без связи с предметной областью или проектным решением, непонятно, зачем он нужен.
Хорошая модель не обязана быть полной навсегда. Она должна быть достаточной для текущего решения и открытой к уточнению. Подробный материал про итоговую проверку этой целостности находится в разделе “Согласованность, трассируемость и типовые ошибки”, а здесь важен базовый критерий: модель должна помогать думать, а не только выглядеть как законченный документ.