4.2.4.3. Пакет «Общие механизмы.
В этом пакете, состоящем из одного подпакета управления моделями, определены общие механизмы, применимые ко всем моделям UML (рис. 4.2.8). Он служит для спецификации методов организации элементов в модели, пакеты и подсистемы.
Рис. 4.2.8. Состав пакета «Общие механизмы».
Подпакет Управление моделями.
Подпакет Управление моделями (Model Management) описывает базовые элементы UML, формирующие все модельные представления, и содержит семантики модели, пакета и подсистемы. Они играют роли контейнеров, группирующих прочие элементы модели.
Пакет есть метакласс UML и может содержать ограничения и зависимости между элементами модели внутри себя. Каждый элемент пакета имеет видимость только внутри данного пакета, т.е. за пределами пакета его элементы нельзя использовать без дополнительных указаний на импорт или доступ к отдельным элементам пакета. Но и сами пакеты со своим содержимым определены в некоем пространстве имен, которое определяет уникальность имен всех элементов модели, а само пространство имен, будучи тоже элементом модели, может быть вложено в более общее пространство имен.
Подклассом пакета является модель - абстракция системы, предназначенная для определенной цели, которая и определяет нужные для включения в медель компоненты. Цель обычно задана в форме исходных требований к системе,а те в UML записываются как варианты использования системы (прецеденты).
В UML система с различных точек зрения может представляться различными моделями. Такими моделями могут быть: логическая, проектирования, вариантов использования и т.д. Каждая модель по-своему абстрагирует и рассматривает физическую систему, и модели могут вкладываться друг в друга. Пакет может включать различные модели одной системы, что важно для механизмов разработки моделей на UML.
Общая модель системы в контексте языка UML содержит в себе модель анализа и модель проектирования, что явно отражает связь с ООАП (рис. 4.2.9.а).
Рисунок. 4.2.9.а. Изображение модели системы в виде пакетов моделей анализа и проектирования.
Подсистема группирует элементы модели, специфицирующие некоторое простое поведение системы. В метамодели UML подсистема - подклассом и классификатора и пакета, а её элементы делятся на спецификацию поведения и его реализацию.
Графическим представлением подсистемы служит, как и для пакета, прямоугольник с разделением на три секции (рис. 4.2.9 б). Верхний малый прямоугольник содержит "вилку", указывающую на подсистему. Имя подсистемы с возможным ключевым словом или стереотипом записывают внутри большого прямоугольника. Имя подсистемы можно записать рядом с "вилкой".
Рис. 4.2.9 б. Изображение подсистемы в UML.
Операции подсистемы расположены в левой верхней секции, ниже - элементы спецификации, а справа - элементы реализации. Два последних раздела помечены как "Элементы спецификации" и "Элементы реализации", а секция операций не помечается. Отсутствующие в подсистеме секции на схеме не отображаются.
4.2.5. Особенности описания метамодели uml
Метамодель языка UML описывается на полуформальном языке с применением представлений трех видов:
абстрактного синтаксиса;
правил корректного построения выражений;
семантики.
Абстрактный синтаксис - модель описания части языка UML, используемой для построения диаграмм классов по описаниям системы на естественном языке. Абстрактный синтаксис в UML ограничен в возможностях, относящихся лишь к интерпретации обозначений компонент диаграмм, связей между ними и возможных дополнительных обозначений. Элементы абстрактного синтаксиса включают ряд ключевых слов и значений отдельных атрибутов базовых понятий уровня метамодели, имеющих однозначное обозначение на естественном языке.
Правила корректного построения выражений нужны для задания дополнительных ограничений или свойств ряда компонент модели. Все экземпляры класса инвариантны друг другу поскольку обладают общими свойствами. Задание инвариантных свойств классов и отношений использует специальные выражения формального языка, в UML названного языком объектных ограничений (Object Constraint Language, ОСL). ОСL использует естественный язык для описания правил корректного построения выражений.
Семантика UML описывается, как правило, на естественном языке, но может содержать дополнительные обозначения, отражающие связи понятий. Сложность описания семантики UML заключена в метамодельном уровне представлений основных конструкций. Понятия UML абстрактны (агрегация, ассоциация, композиция, состояние, сотрудничество); одновременно каждое понятие конкретизируется на модельном уровне (автомобиль, марка, номер госрегистрации, год выпуска). Эта двойственность определяет сложность описания семантики UML.
Итак, метамодель UML - комбинация графики (специальных обозначений), формального и естественного языков. Имеется предел, который теоретически ограничивает описание метамодели средствами самой метамодели, что и вынуждает использовать выразительный естественный язык (обычно достаточны национальный и, в некоторых случаях, английский языки).
Естественный язык должен использоваться по строгим правилам для создания формальной модели. Так, описание семантики UML может содержать фразы типа "Сущность A есть сущность В" или "Сущность С обладает способностью", интерпретируемые в традициях русского языка. Этого может быть мало для более формального описания рассматриваемых сущностей. В таких случаях дополнительно специфицируют семантику простых фраз, для чего применяют следующие правила:
Явно указывать в тексте экземпляр метакласса. В обиходе часто опускают слово "пример" или "экземпляр", говоря только "класс". Так, фразу "Атрибут Год выпуска класса Автомобиль имеет значение 2010" надо записать точнее, а именно: "Атрибут Год выпуска экземпляра класса Автомобиль имеет значение 2010".
Каждый раз применяют значение слова, приписанное имени соответствующей конструкции UML. Все особенности семантики следует указать явным образом.
Термины языка UML записываются одним словом только с одним из допустимых префиксов, таких как мета-, под- или супер-.
Правила записи текста непосредственно восходят к англоязычным терминам языка UML Для ссылок на конструкции UML (не на их представления в метамодели) применяют обычный текст без выделения.
Имена метаклассов - элемент нотации UML: существительное, возможно, с присоединенным прилагательным. При этом английское имя метакласса записывается одним словом, а каждая его часть выделена прописной буквой (т.н. «Верблюжья нотация», например, DateOfBirth); те же правила для имен метаассоциаций и ассоциаций классов. Имена других элементов UML записываются так же, но начинаются со строчной (например, allContents).
Имена логических метаатрибутов начинаются с префикса "is" (например, isEmpty).
Перечислимые типы заканчиваются словом "Kind" (например, AmountKind).
В тексте метаассоциаций, метаатрибуты, метаклассы и т. д. всегда называются так, как в модели.
Закавыченные имена стандартных обозначений (стереотипов) начинаются со строчной буквы (напр., "type").
В языке UML информация о модели системы выражена специальными графическими конструкциями - диаграммами.
Диаграмма (diagram) — графическое представление модели в форме связного графа, вершинам и ребрам которого сопоставлена определенная семантика. В UML включены следующие виды диаграмм:
Диаграмма вариантов использования или диаграмма использования, диаграмма прецендентов (use case diagram).
Диаграммы взаимодействия (interaction diagrams).
Диаграмма деятельности (activity diagram или диаграмма активности).
Диаграмма классов (class diagram).
Диаграмма компонент (component diagram).
Диаграмма кооперации (collaboration diagram или диаграмма сотрудничества).
Диаграммы поведения (behavior diagrams).
Диаграмма последовательности (sequence diagram).
Диаграмма развертывания или диаграмма топологии (deployment diagram).
Диаграммы реализации (implementation diagrams).
Диаграмма состояний (statechart diagram).
Некоторые из них служат для обозначения других подвидов диаграмм, а самостоятельно в UML используются следующие:
Диаграмма вариантов использования.
Диаграмма деятельности.
Диаграмма классов.
Диаграмма компонентов.
Диаграмма кооперации.
Диаграмма последовательности.
Диаграмма развертывания.
Диаграмма состояний.
Этот перечень канонический, он - неотъемлемая графическая часть UML.
Нотация канонических диаграмм - основное средство разработки моделей на языке UML, а совокупность построенных диаграмм самодостаточна, ибо они содержат всю информация, нужную для реализации проекта системы.
Каждая диаграмма даёт конкретные детали представлений о модели системы в терминах UML. Диаграмма вариантов использования - самая общая концептуальная модель системы, исходная для построения остальных диаграмм. Диаграмма классов - логическая модель; она отражает статическую структуру системы. Диаграммы поведения также разновидности логической модели и отражают динамику работы системы, а диаграммы реализации представляют физические компоненты системы, формируя ее физическую модель. Итак, интегрированно модель системы в нотации UML (рис. 4.2.10) представляется в виде совокупности указанных выше диаграмм.
Рис. 4.2.10. Интегрированная модель системы средствами UML.
Раньше рассматривалась еще диаграмма объектов. Однако в версии UML 1.3 она исключена из канонических диаграмм, ибо ее элементы могут присутствовать на других диаграммах.
Кроме графических элементов, на каждой канонической диаграмме может быть текст, расширяющий семантику базовых элементов. В UML есть три механизма расширения.
Стереотипы, основанные на уже существующих и описанных в метамодели UML типах или классах, расширяют именно семантику, но не структуры предшествующих типов или классов. Некоторые стереотипы предопределены в UML, другие указываются разработчиком. На диаграммах изображаются как текст, в угловых кавычках. Предопределенные стереотипы - ключевые слова UML, и используются на канонических диаграммах на языке оригинала без перевода.
Помеченное значение (tagged value) — явное определение свойства как пары "имя – значение". В помеченном значении само имя называют тегом (tag). На диаграммах они изображаются строкой текста специального формата в фигурных скобках. В формате записи: {тег = значение} используют теги из нотации UML, но их определение не строгое, поэтому теги могут быть указаны самим разработчиком.
Ограничение (constraint) - логическое условие, ограничивающее семантику выбранного элемента модели. Как правило, ограничения специфицируются разработчиком. На диаграммах они изображаются строкой текста в фигурных скобках. Для формальной записи ограничений предназначен язык объектных ограничений (Object Constraint Language, OCL) - составная часть UML.