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

Примечание

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

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

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

Явно указывать в тексте экземпляр некоторого метакласса. Речь идет о том, что в естественной речи мы часто опускаем слово "пример" или "экземпляр", говоря просто "класс". Так, фразу "Атрибут возраст класса сотрудник имеет значение 30 лет" следует записать более точно, а именно: "Атрибут возраст экземпляра класса сотрудник имеет значение 30 лет".

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

Термины языка UML могут включать только один из допустимых префиксов, таких как под-, супер- или мета-. При этом сам термин с префиксом записывается одним словом.

В дополнение к этому будут использоваться следующие правила выделения текста:

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

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

Имена метаассоциаций и ассоциаций классов записываются аналогичным образом (например, ElementReference).

Имена других элементов языка UML также записываются одним словом, но должны начинаться с маленькой буквы (например, ownedElement, allContents).

Имена метаатрибутов, которые принимают булевы значения, всегда начинаются с префикса "is" (например, isAbstract).

Перечислимые типы должны всегда заканчиваться словом "Kind" (например, AggregationKind).

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

Имена стандартных обозначений (стереотипов) заключаются в кавычки и начинаются со строчной буквы (например, "type").

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

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

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

Примечание

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