1.7.1. Назначение и уровни моделей

Модели UML могут создаваться и могут использоваться с различными целями. Иногда бывает даже так, что автор создавал модель с одной определенной целью, а используется она другими людьми совершенно неожиданным для автора образом. Таким образом, назначение модели не является чем-то постоянным и трудно изменяемым, как цвет кожи или разрез глаз. Трансформации назначения моделей вполне возможны, но, тем не менее, практика моделирования подсказывает, что модели дают больший эффект, если при моделировании принимать во внимание назначение модели.

Назначение моделей может быть самым разным, все случаи описать невозможно. Мы предлагаем следующую классификацию назначений модели, основанную на ответе на простой вопрос "а что с этой моделью станется потом?", который автор модели должен задавать себе во время моделирования. Мы рассматриваем три типичных варианта ответа.

• Концептуальная модель (conceptual model). На диаграммы такой модели будут смотреть, их будут обдумывать, но с самой моделью ничего делать не будут. Это не означает, что модель не нужна ‒ это означает, что модель используется только для управления мыслительным процессом, для понимания. Поэтому мы называем такие модели концептуальными (также применются термины модель анализа (analysis model) или аналитическая модель). Такой тип использования моделей один из самых важных, например, потому что так используются модели, которые получаются в результате анализа предметной области. Концептуальные модели довольно стабильны: если не меняется предметная область, то нет нужды менять и модель. Главное требования к модели предметной области: концептуальная целостность (consistency).
• Модель проектирования (design model). Модель проектирования представляет собой высокоуровневое (на уровне подсистем) и низкоуровневое (на уровне классов, если речь идет об использовании объектно-ориентированного подхода) описание программной системы. Модель проектирования предназначена для того, чтобы, руководствуясь ею, разработать программный код приложения. Как правило, архитектура (высокоуровневое описание) и код разрабатываются итеративно, и разработчикам в процессе разработки необходимо модифицировать модель проектирования, чтобы она соответствовала принимаемым решениям. Главное требование к модели проектирования: понятность (usability). Действительно, разработчики должны полностью понимать модель, чтобы вести разработку.
• Модель реализации (implementation model). Модель реализации предназначена для автоматического преобразования, возможно многократного, в существенно другой вид, например, в исполнимый код. Такое предназначение требует указания необходимых деталей реализации в модели, поскольку "от себя" компьютер их добавить не сможет. Главное требование к моделям реализации: полнота (completeness).

Еще раз подчеркнем, что между моделями различного назначения нет непреодолимого барьера, но стилистические различия все-таки имеются. На следующем рисунке мы приводим пример, рассматривая отношения между авторами Author и книгой Book. С концептуальной точки зрения книга 1 ‒ это тип издания, который имеет авторов 2, причем соавторов у книги может быть несколько и каждый может быть автором нескольких книг. Важно учесть, что в создание книги каждый соавтор внес определенный вклад 3. В модели проектирования необходимо уточнить, что абстрактный творческий вклад измеряется в конкретных процентах 4, а в модели реализации добавить, что необходимо проверять инвариантное соотношение 5, состоящее в том, что для каждой книги сумма вкладов всех ее авторов должна быть равна 100%.

В качестве дополнения к модели реализации можно привести поясняющую диаграмму объектов, где указать конкретную книгу  1, конкретных авторов 2 и конкретный вклад каждого из авторов 3.

Классификация по назначению ‒ не единственная используемая классификация моделей. Еще одним примером классификации, важным с теоретической точки зрения, является классификация моделей по уровням абстракции.

В UML 1 эта классификация в явном виде присутствовала в стандартах. В UML 2 из текста стандарта ее исключили, но влияние данной классификации все равно ощущается. Речь идет об весьма важной и перспективной, хотя и не очень широко используемой возможности UML ‒ о метамоделировании.

В параграфе 1.3.2 при обсуждении определения UML нами отмечено, что в описании UML используются три уровня: модели, метамодели и мета-метамодели. Добавим для полноты картины нулевой уровень ‒ сами моделируемые объекты, и дадим этим уровням имена в соответствии со стандартом UML 1: M0 ‒ уровень объектов, M1 ‒ уровень моделей, M2 ‒ уровень метамодели, M3 ‒ уровень мета-метамодели. Поскольку мета-метамодели и метамодели описываются с применением тех же средств ‒ то есть диаграмм классов, дальнейшее прибавление приставки "мета" не имеет смысла, так как не даст ничего нового.

В UML в качестве мета-метамодели применяется стандарт MOF (Meta Object Facility), специально разработанный OMG для спецификации метамоделей различных языков моделирования, таких как UML и CWM (Common Warehouse Metamodel).

В нашей книге подавляющее большинство примеров относится к уровню M1, но встречается буквально несколько примеров на уровнях M0, и в конце есть несколько диаграмм на уровне M2. Важно понять, что на всех уровнях используются одни и те же языковые средства ‒ различия не синтаксические, а семантические.

Упрощенно говоря, уровень модели ‒ это число шагов по созданию экземпляров (instantiation), которые нужно сделать, чтобы спуститься с данного уровня абстракции на уровень моделируемой реальности. Поясним сказанное рисунком, в котором мы продолжаем рассмотрение примера с книгой.

Поскольку, как мы видим, на всех уровнях применяется одна и та же нотация, можно позволить инструменту, поддерживающему UML редактировать и модели, и метамодели, и мета-метамодели.

Метамоделирование ‒ чрезвычайно мощный инструмент. Одним небольшим изменением на уровне метамодели мы можем внести радикальные изменения сразу во многие элементы множества моделей. Но за такую мощь приходится платить возрастающим риском: если изменения метамодели окажутся неудачными, то последствия на уровне моделей могут быть катастрофическими. Это примерно то же самое, что изменение шаблонов генерации кода в используемом компиляторе языка программирования: может перестать работать сразу все.

Пока нельзя сказать, что уже выработана надежная техника безопасного метамоделирования. Изменения в метамоделях приходится делать на свой страх и риск. И даже если они хорошо продуманы и не приводят к ошибкам, то очень часто они приводят к несовместимости с другими инструментами. Но метамоделирование слишком привлекательно своей силой, поэтому попытки и исследования в этой области не прекращаются. В будущем, может быть, метамоделирование займет ведущее место.

Можно замахнутся и на уровень M3 и начать все менять уже на уровне мета-метамодели. Но это означает поставить под сомнение деятельность OMG в целом. У нас нет для этого никаких оснований, мы так не делаем, и не рекомендуем читателям отклоняться от стандартов, если для этого нет веских причин^∇.

1.7.2. Классические представления из UML 1 и 2

Набор используемых представлений модели является еще менее формальным и догматическим, чем набор канонических диаграмм и классификация назначения и уровня моделей.

Одним из самых популярных является набор представлений, описанных авторами языка в UML 1 и показанных на следующем рисунке. Этот рисунок заимствован из книги Буча, Рамбо и Якобсона "UML. Руководство пользователя" с соответствующим изменением терминологии.

Представление использования (Use Case View) ‒ это описание поведения системы в терминах вариантов использования с точки зрения внешних по отношению к системе действующих лиц. Данное представление описывает не то, как организована система, а те функциональные требования, которым она должна удовлетворять. При этом структурные аспекты передаются диаграммами использования, а поведенческие аспекты ‒ диаграммами взаимодействия, состояний и деятельности.

Представление проектирования (Design View) предназначено для описания словаря предметной области, то есть, в парадигме объектно-ориентированного программирования, классов, а также таких вспомогательных сущностей как, например, интерфейсы или кооперации. Структурные аспекты передаются диаграммами классов и объектов, а поведенческие аспекты ‒ диаграммами взаимодействия, состояний и деятельности.

Представление процессов (Process view) ‒ это описание взаимодействия элементов управления (процессов, потоков) во время работы системы. Оно отражает такие нефункциональные требования, как, например, обеспечение параллелизма. Структурные аспекты передаются с помощью концепции активных классов, представляющих процессы и потоки, а поведенческие аспекты ‒ диаграммами взаимодействия, состояний и деятельности.

Представление компонентов (Component view) ‒ это описание системы на уровне артефактов (компонентов, файлов и т.д.), используемых для сборки, выпуска, конфигурации программного продукта. Структурные аспекты передаются диаграммами компонентов, а поведенческие аспекты ‒ диаграммами взаимодействия, состояний и деятельности.

Представление размещения (Deployment view) отражает топологию связей аппаратных средств и размещения на них компонентов. Структурные аспекты передаются диаграммами размещения, а поведенческие аспекты ‒ диаграммами взаимодействия, состояний и деятельности.

В следующей таблице приведен набор представлений, описанных авторами языка в фундаментальной книге "UML Language Refenece", которая в русском переводе получила странное название "UML. 2-е издание". Первоначальные пять представлений, ассоциирующиеся с UML 1, при переходе к UML 2 были дополнены и в результате образовали набор уже из восьми представлений.

Представления	Диаграммы	Комментарий
Статическое представление (Static view)	Диаграмма классов	В UML 1 ‒ часть представления проектирования (Design view)
Представление проектирования (Design view)	Диаграмма внутренней структуры Диаграмма кооперации Диаграмма компонентов	В UML 1 частично отображается в представлении процессов (Process view) и представлении компонентов (Component view)
Представление использования (Use Case view)	Диаграмма использования	В UML 1 описывается одноименным представлением, однако в список диаграмм данного представления были также добавлены диаграммы взаимодействия, состояний и деятельности.
Представление автоматов (State machine view)	Диаграмма автомата	В UML 1 данное представление не является обособленной частью, а используется всеми представлениями по мере необходимости.
Представление деятельности (Activity view)	Диаграмма деятельности Обзорная диаграмма взаимодействия	В UML 1 данное представление не является обособленной частью, а используется всеми представлениями по мере необходимости.
Представление взаимодействия (Interaction view)	Диаграмма последовательности Диаграмма коммуникации Диаграмма синхронизации	В UML 1 данное представление не является обособленной частью, а используется всеми представлениями по мере необходимости.
Представление развертывания/размещения (Deployment view)	Диаграмма развертывания	В UML 1 описывается одноименным представлением, однако в список диаграмм данного представления были также добавлены диаграммы взаимодействия, состояний и деятельности.
Представление управления моделью (Model Management view)	Диаграмма пакетов	Отсутствует в UML 1

Статическое представление (Static view) отражает статическую структуру системы и не описывает динамику в любом ее проявлении. Чаще всего, статическое представление отражает логические концепции приложения, основой которого служат классы и их отношения.

Представление проектирования (Design view) является более детализированным вариантов статического представления, выделяя классификаторы, обеспечивающие необходимую функциональность системы.

Представление использования (Use Case view) описывает функционирование системы в терминах вариантов использования и рассматривает их с точки зрения заинтересованных действующих лиц.

Представление автоматов (State machine view) специфицирует поведение отдельных элементов, для которых можно ввести понятие жизненного цикла, описываемого набором состояний и переходов между ними.

Представление деятельности (Activity view) описывает функционирование системы с точки зрения различных элементов деятельности, соединенных потоками управления и потоками данных.

Представление взаимодействия (Interaction view) отражает последовательность обмена сообщениями между элементами системы во время выполнения приложения.

Представление развертывания (Deployment view) описывает размещение артефактов на вычислительных узлах во время выполнения приложения, а также компоненты и другие элементы, манифестацией которых являются данные артефакты.

Представление управления моделью (Model Management view) отражает внутреннюю организацию модели, описывая ее разбиение на пакеты и указывая отношения между ними. Включение этого аспекта в число представлений авторам представляется спорным.

1.7.3.Три представления ‒ взгляд авторов

Учитывая неформальный характер самого понятия представления, и опираясь на собственный опыт использования UML, мы рискнем предложить свой вариант набора представлений. Их всего три.

Представление использования. По сути это то же самое представление, что было указано выше. Представление использования призвано отвечать на вопрос, что делает система полезного. Определяющим признаком для отнесения элементов модели к представлению использования является, по нашему мнению, явное сосредоточение внимания на факте наличия у системы внешних границ, то есть выделение внешних действующих лиц, взаимодействующих с системой, и внутренних вариантов использования, описывающих различные сценарии такого взаимодействия. Таким образом, единственным выразительным средством представления использования оказываются диаграммы использования.

Представление структуры. Представление структуры призвано отвечать (с разной степенью детализации) на вопрос: из чего состоит система. Определяющим признаком для отнесения элементов модели к представлению структуры является явное выделение структурных элементов ‒ составных частей системы ‒ и описания взаимосвязей между ними. Принципиальным является чисто статический характер описания, то есть отсутствие понятия времени в любой форме, в частности, в форме последовательности событий и/или действий. Представление структуры описывается, прежде всего, и главным образом диаграммами классов, а также, если нужно, диаграммами компонентов, размещения, внутренней структуры и, в редких случаях, диаграммами объектов.

Представление поведения. Представление поведения призвано отвечать на вопрос: как работает система. Определяющим признаком для отнесения элементов модели к представлению поведения является явное использование понятия времени, в частности, в форме описания последовательности событий / действий, то есть в форме алгоритма. Представление поведения описывается диаграммами автомата и деятельности, а также обзорной диаграммой взаимодействия, диаграммами коммуникации и последовательности. В редких случаях можно воспользоваться диаграммой синхронизации.

Такой набор представлений является ортогональным и согласованным с классификацией диаграмм. Более того, он во многом инспирирован личным опытом моделирования. Авторам никогда не удавалось построить разумную модель для мало-мальски сложной системы так, как это рекомендуется в некоторых учебниках: сначала построить представление использования, затем последовательно представление проектирование, представления процессов и компонентов и, наконец, представление развертывания.

По нашему мнению, процесс моделирования (независимо от назначения модели) является не линейным последовательным, а итеративным и параллельным, примерно таким, как показано ниже.

Другими словами, процесс моделирования циклический, на каждом шаге может присутствовать уточнение представления использования, за которым следует параллельное моделирование структуры и поведения.

Исходя из сказанного, мы положили свой набор представлений в основу структуры книги. В главе 2 рассматривается представление использования, в главе 3 ‒ представление структуры, а в главе 4 ‒ представление поведения.