Назначение моделирования
Моделирование не существует само по себе (иначе зачем бы мы его изучали) и решает несколько задач:
- визуализация системы в текущем или желаемом состоянии;
- определение структуры и/или поведения системы;
- создание шаблона для дальнейшего создания системы;
- документация принимаемых решений.
Модель при этом не должна быть копией реальности. Если попытаться включить в неё все детали предметной области, регламентов, интерфейса, кода и инфраструктуры, она перестанет помогать и станет ещё одной сложной системой. Полезная модель всегда упрощает реальность, но сохраняет те свойства, которые важны для текущего вопроса.
При моделировании также важно соблюдать несколько устоявшихся принципов:
- Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как оно в итоге будет выглядеть. Другими словами, выбирать и создавать модель нужно вдумчиво.
- Каждая модель может быть воплощена с разной степенью абстракции.
- Лучшие модели — те, что ближе к реальности. Если модель где-то расходится с действительностью, нужно понимать, в чём именно расхождение и на что оно влияет.
- Нельзя ограничиваться созданием только одной модели. Наилучший подход — использовать совокупность нескольких моделей, почти независимых друг от друга.
Если смотреть на средства моделирования объектно-ориентированных систем (а к таким сводится большинство), то обычно UML покрывает большинство потребностей и выбирается в силу своей выразительности. При этом важно уметь не сводить работу с моделью в UML (и в любой другой нотации) к рисованию диаграмм-картинок, это именно связная модель, раскрывающая систему с разных сторон.
Хорошая модель имеет несколько признаков:
- отвечает на конкретный вопрос;
- имеет понятный уровень абстракции;
- не содержит деталей, которые не нужны для этого вопроса;
- использует те же термины, что и остальные артефакты;
- помогает принять или проверить проектное решение;
- согласована с другими представлениями системы.
Например, для системы доставки одной диаграммы будет недостаточно. Диаграмма использования поможет понять, кто работает с системой и какие цели преследует. Диаграмма деятельности покажет процесс оформления заказа. Диаграмма классов поможет выделить Order, Customer, Delivery и связи между ними. Диаграмма компонентов покажет крупные части реализации, а диаграмма развёртывания — где находятся клиентское приложение, сервер и база данных.
Хорошая модель (или набор моделей) помогает ответить сразу на несколько вопросов:
- что происходит в предметной области;
- какие проблемы должна решить система;
- кто взаимодействует с системой и зачем;
- какие сценарии должны быть поддержаны;
- какие информационные объекты участвуют в этих сценариях;
- как эти объекты превращаются в программную модель;
- из каких компонентов состоит реализация;
- где эта реализация развёртывается;
- как проверить, что все части модели не противоречат друг другу.
Плохая модель обычно нарушает один из этих принципов. Она либо слишком общая и не помогает принимать решения, либо слишком детальная и дублирует код, либо использует термины, которые не совпадают с требованиями и сценариями. Поэтому важны не только отдельные диаграммы, но и связи между ними.