Модели могут создаваться и использоваться с различными целями. Назначение моделей может быть самым разным, все случаи описать невозможно. Между тем от целей создания и области применения модели зависит способ ее конструирования, необходимая инструментальная поддержка и многое другое. Таким образом, необходим набор руководящих принципов, классификация, которая позволяла бы предопределять свойства модели в соответствии с областью ее применения. Предлагаемая нами классификация основана на вариантах ответа на простой вопрос - "а что с этой моделью станется потом?", который автор модели должен задавать себе во время моделирования. Рассмотрим три типичных варианта ответа.
- Концептуальная модель (conceptual model). На диаграммы такой модели будут смотреть, их будут обдумывать, но с самой моделью ничего делать не будут. Это не означает, что модель не нужна — это означает, что модель используется только для управления мыслительным процессом, для понимания. Поэтому мы называем такие модели концептуальными. Такой тип использования моделей один из самых важных, например, потому что так используются модели, которые получаются в результате анализа предметной области. Концептуальные модели довольно стабильны: если не меняется предметная область, то нет нужды менять и модель. Главное требования к модели предметной области: концептуальная целостность (consistency).
- Модель проектирования (design model). Модель проектирования представляет собой высокоуровневое (на уровне подсистем) и низкоуровневое (на уровне классов, если речь идет об использовании объектно-ориентированного подхода) описание программной системы. Модель проектирования предназначена для того, чтобы, руководствуясь ею, разработать программный код приложения. Как правило, архитектура (высокоуровневое описание) и код разрабатываются итеративно, и разработчикам в процессе разработки необходимо модифицировать модель проектирования, чтобы она соответствовала принимаемым решениям. Главное требование к модели проектирования: понятность (usability). Действительно, разработчики должны полностью понимать модель, чтобы вести разработку.
- Модель реализации (implementation model). Модель реализации предназначена для автоматического преобразования, возможно многократного, в существенно другой вид, например, в исполнимый код. Модель реализации модифицируется постоянно все время разработки, она должна быть в равной степени понятна как разработчику, так и компьютеру. Такое предназначение требует указания необходимых деталей реализации в модели, поскольку "от себя" компьютер их добавить не сможет. Главное требование к моделям реализации: полнота (completeness).
На следующем рисунке мы приводим пример, рассматривая отношения между авторами (Author) и книгой (Book). С концептуальной точки зрения книга (1) — это тип издания, который имеет авторов (2), причем соавторов у книги может быть несколько и каждый может быть автором нескольких книг. Важно учесть, что в создание книги каждый соавтор внес определенный вклад (3). В модели проектирования необходимо уточнить, что абстрактный творческий вклад измеряется в конкретных процентах (4), а в модели реализации добавить, что необходимо проверять инвариантное соотношение (5), состоящее в том, что для каждой книги сумма вкладов всех ее авторов должна быть равна 100%.
Рисунок 1. Концептуальная модель, модель проектирования и модель реализации
Как видно, между моделями различного назначения нет непреодолимого барьера, но стилистические различия все-таки имеются. Кроме того, некоторые модели могут включать в свой состав дополнительные поясняющие диаграммы.
Например, в качестве дополнения к модели реализации можно привести поясняющую диаграмму объектов, где указать конкретную книгу (1), конкретных авторов (2) и конкретный вклад каждого из авторов (3).
Рисунок 2. Поясняющая диаграмма объектов