Изменить стиль страницы

Пакет Элементы ядра

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

Примечание 25

Пакет Элементы ядра специфицирует базовые конструкции, требуемые для описания исходной метамодели, и определяет архитектурный «скелет» для присоединения дополнительных конструкций языка, таких как метаклассы, метаассоциации и метаатрибуты. Хотя пакет Элементы ядра содержит семантику, достаточную для определения всей оставшейся части языка UML, он не является мета-метамоделью UML.

В этот пакет входят основные метаклассы языка UML: класс (Class), атрибут (Attribute), ассоциациях (Association), ассоциация-класс (AssociationClass), конец ассоциации (AssociationEnd), свойство поведения (BehavioralFeature), классификатор (Classifier), ограничение (Constraint), тип данных (DataType), зависимость (Dependency), элемент (Element), право на элемент (ElementOwnership), свойство (Feature), обобщение (Generalization), элемент отношения обобщения (GeneralizableElement), интерфейс (Interface), метод (Method), элемент модели (ModelElement), пространство имен (Namespace), операция (Operation), параметр (Parameter), структурное свойство (StructuralFeature), правила правильного построения выражений (Well-formedness rules).

Пакет Вспомогательные элементы

Пакет Вспомогательные элементы является подпакетом пакета Основные элементы и специфицирует дополнительные конструкции языка UML, которые расширяют пакет Элементы ядра. Вспомогательные элементы обеспечивают понятийный базис для зависимостей, шаблонов, физических структур и элементов представлений. В этот пакет входят следующие метаклассы: связывание (Binding), комментарий (Comment), компонент (Component), узел (Node), презентация (Presentation), уточнение (Refinement), цепочка зависимостей (Trace), потребление (Usage), элемент представления (ViewElement), зависимость (Dependency), элемент модели (ModelElement), правила правильного построения выражений (Well-formedness rules). При этом три последних метакласса взяты из пакета Элементы ядра и используются для спецификации остальных.

Примечание 26

Пакет Механизмы расширения

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

Для этой цели в языке UML предусмотрены три механизма расширения, которые могут использоваться совместно или раздельно для определения новых элементов модели с отличающимися семантикой, нотацией и свойствами от специфицированных в метамодели языка UML элементов. Такими механизмами являются: ограничение (Constraint), стереотип (Stereotype) и помеченное значение (TaggedValue).

Таким образом, механизмы расширения языка UML предназначены для выполнения следующих задач:

• Уточнения существующих модельных элементов при разработке моделей на языке UML.

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

• Определения таких расширений языка UML, которые зависят от специфики моделируемого процесса или от языка реализации программного кода.

• Присоединения произвольной семантической или несемантической информации к элементам модели.

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

Наиболее важные из встроенных механизмов расширения основываются на понятии стереотип. Стереотипы обеспечивают некоторый способ классификации модельных элементов на уровне объектной модели и возможность добавления в язык UML «виртуальных» метаклассов с новыми атрибутами и семантикой. Другие встроенные механизмы расширения основываются на понятии списка свойств, содержащего помеченные значения и ограничения. Эти механизмы обеспечивают пользователю возможность включения дополнительных свойств и семантики непосредственно в отдельные элементы модели. 

Пакет Типы данных

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

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

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

Для определения различных типов данных в языке UML используются как простые конструкции: целое число (Integer), строка (String), имя (Name), Булев (Boolean), время (Time), кратность (Multiplicity), тип видимости (VisibilityKind), диапазон кратности (MultiplicityRange), так и более сложные: выражение (Expression), булевское выражение (BooleanExpression), тип агрегирования (AggregationKind), тип изменения (ChangeableKind), геометрия (Geometry), отображение (Mapping), выражение-процедура (ProcedureExpression), тип псевдосостояния (PseudostateKind), выражение времени (TimeExpression), непрерываемый (Uninterpreted).

вернуться

Примечание 25

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

вернуться

Примечание 26

Хотя этот пакет имел самостоятельное значение в начальных версиях языка UML, однако в проектах последней версии его элементы объединились с пакетом Элементы ядра. Причиной этого послужило требование строгого вхождения каждого элемента в один пакет.