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