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