1.8.1. Внутреннее представление модели

Модель имеет внутреннее представление ‒ как бы иначе работали инструменты? Для графов (а модель — это нагруженный граф) известно множество разнообразных способов их представления в компьютере и разработчики инструментов для моделирования на UML вправе использовать любое из них или придумать свое (что обычно и делается). Важным общим правилом UML является спецификация того, какую именно семантическую информацию, связанную с тем или иным графическим элементом нотации, инструмент обязан хранить. Другими словами, у каждой картинки есть оборотная сторона, где все записано, даже то, что в данном контексте не нужно или нельзя показывать на картинке. Например, инструмент может поддерживать режим, в котором часть информации о классе (скажем, список операций) не отображается на картинке или отображается не полностью. Но при этом полный список со всеми деталями во внутреннем представлении сохраняется. Более того, внутреннее представление может быть переведено в текст в формате XMI без потери информации. Таким образом, в UML определен результат сериализации модели. Это важное правило, на котором базируется интероперабельность инструментов.

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

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

Рис. Пример диаграммы классов

А вот результат сериализации этой модели в формате XMI.

<uml:Model xmi:type='uml:Model' xmi:id='eee_1045467100313_135436_1' name='Data'>
  <packagedElement xmi:type='uml:Class' xmi:id='_17_0_3_1_61c0214_1365596882565_727119_2991' name='Class1'>
    <ownedAttribute xmi:type='uml:Property' xmi:id='_17_0_3_1_61c0214_1365596894398_325537_3016' visibility='private' type='_17_0_3_1_61c0214_1365596894383_86156_3014' association='_17_0_3_1_61c0214_1365596894398_705873_3015'>
      <xmi:Extension extender='MagicDraw UML 17.0.3'>
        <modelExtension>
          <lowerValue xmi:type='uml:LiteralInteger' xmi:id='_17_0_3_1_61c0214_1365596907094_924709_3043' value='1'/>
        </modelExtension>
      </xmi:Extension>
      <xmi:Extension extender='MagicDraw UML 17.0.3'>
        <modelExtension>
          <upperValue xmi:type='uml:LiteralUnlimitedNatural' xmi:id='_17_0_3_1_61c0214_1365596907094_982174_3044' value='1'/>
        </modelExtension>
      </xmi:Extension>
    </ownedAttribute>
  </packagedElement>
  <packagedElement xmi:type='uml:Class' xmi:id='_17_0_3_1_61c0214_1365596894383_86156_3014' name='Class2'>
    <ownedAttribute xmi:type='uml:Property' xmi:id='_17_0_3_1_61c0214_1365596894398_800270_3017' visibility='private' type='_17_0_3_1_61c0214_1365596882565_727119_2991' association='_17_0_3_1_61c0214_1365596894398_705873_3015'>
      <xmi:Extension extender='MagicDraw UML 17.0.3'>
        <modelExtension>
          <lowerValue xmi:type='uml:LiteralInteger' xmi:id='_17_0_3_1_61c0214_1365596904507_160810_3037' value='1'/>
        </modelExtension>
      </xmi:Extension>
      <xmi:Extension extender='MagicDraw UML 17.0.3'>
        <modelExtension>
          <upperValue xmi:type='uml:LiteralUnlimitedNatural' xmi:id='_17_0_3_1_61c0214_1365596904508_102180_3038' value='1'/>
        </modelExtension>
      </xmi:Extension>
    </ownedAttribute>
  </packagedElement>
  <packagedElement xmi:type='uml:Association' xmi:id='_17_0_3_1_61c0214_1365596894398_705873_3015'>
    <memberEnd xmi:idref='_17_0_3_1_61c0214_1365596894398_325537_3016'/>
    <memberEnd xmi:idref='_17_0_3_1_61c0214_1365596894398_800270_3017'/>
  </packagedElement>
</uml:Model>

1.8.2. Дополнения

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

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

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

Например, базовой нотацией отношения ассоциации является сплошная линия 1. Эта базовая нотация может быть расширена целым рядом дополнений: именем ассоциации 2; указанием кратности полюсов ассоциации 3, ролей 4, направления навигации; указанием на агрегацию 5 и т.д. Еще пример: базовой нотацией класса является прямоугольник с именем класса 6. Эта нотация может быть расширена секциями со списками атрибутов 7 и операций, дополнительными секциями, указанием кратности, стереотипа и т.д.

Рис. Пример использования дополнений

Не следует злоупотреблять дополнениями: максимально подробное изображение не всегда самое понятное. Старайтесь не перегружать диаграммы, применяя только те дополнения, которые необходимы в данном контексте.

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

1.8.3. Стандартные дихотомии

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

Дихотомия класс-объект означает, что всегда четко различается, о чем идет речь: об общем описании некоторого множества однотипных объектов (т.е. о классе) или о конкретном объекте из некоторого множества однотипных объектов (т.е. об экземпляре класса). Это важное различие передается единообразно: если это конкретный объект (экземпляр класса), то его имя подчеркивается; если это класс (описание множества), то оно не подчеркивается. Одна и та же сущность в разных контекстах может рассматриваться и как класс (множество) и как экземпляр класса (элемент). Это совершенно естественно и неизбежно, хотя бы потому, что элементами множеств могут быть множества. Важно четко указать, что именно подразумевается в данном контексте. Например, класс 1 в обычной модели является описанием множества объектов и его имя не подчеркивается, а подчеркиваются имена его экземпляров 2. Но в то же время каждый класс, как показано ниже, является объектом 3 ‒ экземпляром метакласса Classifier 4, определенного в метамодели UML.

Рис. Дихотомия класс-объект

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

Если речь идет об абстрактном описании, то для этого может быть использован абстрактный класс в трех вариантах нотации: имя класса пишется курсивом 1, используется соответствующее ограничение 2 или применяется стереотип интерфейса 3. При этом подразумевается, что прямые экземпляры данных классификаторов создать нельзя (подробнее смотри параграф 3.1.3), так как для них не определена реализация.

Если требуется показать, что классификатор имеет реализацию, т.е. у него могут быть прямые экземпляры, тогда при записи имени используется прямое начертание 4.

На рисунке указано, что современный мобильный телефон может быть представлен как объединение трех различных устройств (поддерживает три совершенно разных интерфейса).

Рис. Дихотомия интерфейс-реализация

1.8.4. Механизмы расширения

Механизмы расширения ‒ это встроенный в язык способ изменить язык. Авторы UML при унификации различных методов постарались включить в язык как можно больше различных средств (удерживая объем языка в рамках разумного), так чтобы язык оказался применимым в разных контекстах и предметных областях. Но нельзя объять необъятного! Вполне могут возникать и возникают случаи, когда стандартных элементов моделирования не хватает или они не вполне адекватны.

Механизмы расширения позволяют определять новые элементы модели на основе существующих управляемым и унифицированным способом. Таких механизмов три:

• помеченные значения;
• ограничения;
• стереотипы.

Эти механизмы не являются независимыми ‒ они тесно связаны между собой.

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

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

Рис. Пример использования помеченных значений

Логическое утверждение может иметь два значения: истина или ложь, то есть задаваемое им условие либо выполняется, либо не выполняется. Указывая ограничение для элемента модели, мы изменяем его семантику, требуя, чтобы ограничение выполнялось. Ограничение может относиться к отдельному элементу или к совокупности элементов модели.

Ограничения записываются в виде строки текста, заключенной в фигурные скобки. Это может быть неформальный текст на естественном языке, логическое выражение языка программирования, поддерживаемого инструментом или выражение на некотором другом формальном языке.

Авторы UML в качестве такого языка предлагают использовать OCL, специально включенный для этой цели в стандарт в качестве отдельной спецификации.

Аналогично помеченным значениям, ограничение можно написать после имени элемента или в отдельном комментарии, присоединенном к элементу. Ниже приведен пример использования ограничения.

Рис. Пример использования ограничения

Для помеченных значений и ограничений одна и та же синтаксическая конструкция ‒ текст в фигурных скобках ‒ используется не случайно. На самом деле помеченное значение можно считать ограничением. А именно, если в модели указано помеченное значение { A = B }, то это можно рассматривать как запись условия: "свойство A обязательно имеет значение B".

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

После того, как стереотип определен, его можно использовать как элемент модели нового типа. Если при создании стереотипа не использовались дополнения и графическая нотация взята от базового элемента модели, на основе которого определен стереотип, то стереотип элемента обозначается при помощи имени стереотипа, заключенного в двойные угловые скобки (типографские кавычки « »), которое помещается перед именем элемента модели. Если же для стереотипа определена своя нотация, например, новый графический символ, то указывается этот символ. Впрочем, для пущей ясности, можно указать как имя стереотипа, так и графический символ (значок). На рисунке ниже приведен пример определения и использования стереотипа «PowerUser», который мы определили на базе стандартного стереотипа действующего лица.

Рис. Пример использования стереотипа

Отношение между элементом модели, который взят за основу M2::Actor и новым элементом модели M2::PowerUser называется отношением расширения (extension) 1.

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

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

Не следует путать стереотип и отношение обобщения. Пусть суперкласс M1::User является обобщением подкласса M1::Admin. Тогда как M1::User, так и M1::Admin являются экземплярами одного и того же метакласса, определенного в метамодели. Это показано в виде зависимостей со стереотипом «instanceOf» 2. Если же стереотип M2::PowerUser определен на основе класса M2::Actor, то в метамодели им соответствуют разные метаклассы, и, следовательно, например, между классами M1::User и M1::LocalAdmin никакого отношения обобщения нет. Между ними определено отношение расширения 3 на мета уровне.

Рис. Стереотип и отношение обобщения