Язык UML. Руководство пользователя

       

Стандартные элементы


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

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


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

В UML определены четыре стандартных стереотипа, применимые к классам:

  • metaclass - определяет классификатор, все объекты которого являются классами;
  • powertype - определяет классификатор, все объекты которого являются потомками данного родителя;
  • stereotype - определяет, что данный классификатор является стереотипом, который можно применить к другим элементам;
  • utility - определяет класс, атрибуты и операции которого находятся в области действия всех классов.

    Примечание: В следующих главах книги рассматривается ряд других стандартных стереотипов, применимых к классам: interface, type, implementationClass (см. главу 11), actor (см. главу 16), exception, signal (см. главу 20), process и thread.




    К пакетам применимы все механизмы расширения UML (см. главу 6). Чаще всего используют помеченные значения для определения новых свойств (например, указания имени автора) и стереотипы для определения новых видов пакетов (например, пакетов, инкапсулирующих сервисы операционных систем).

    В языке UML определены пять стандартных стереотипов (см. "Приложение В"), применимых к пакетам:

  • facade (фасад) - определяет пакет, являющийся всего лишь представлением какого-то другого пакета;
  • framework (каркас) - определяет пакет, состоящий в основном из образцов (паттернов - см. главу 28);
  • stub (стаб, заглушка) - определяет пакет, служащий заместителем открытого содержимого другого пакета;
  • subsystem (подсистема) - определяет пакет, представляющий независимую часть моделируемой системы (см. главу 31);
  • system (система) - определяет пакет, представляющий всю моделируемую систему.
  • языке UML не определены пиктограммы для этих стереотипов. Помимо них применяется еще стереотип import, которым помечают отношения зависимости (см. главы 5 и 10) между пакетами, один из которых импортирует другой.

    Практически все эти стандартные элементы рассматриваются в других местах книги. Здесь мы коснемся только стереотипов facade и stub. Оба они предназначены для работы с очень большими моделями. Стереотип facade используется для показа свернутого представления сложного пакета. Предположим, что ваша система содержит пакет BusinessModel. Некоторым пользователям вы захотите показать одно подмножество его элементов (например, только те, что связаны с клиентами), другим - другое (связанное с продуктами). С этой целью определяют фасады, которые импортируют только подмножества элементов другого пакета (но никогда не владеют ими). Стереотип stub используют, если в вашем распоряжении имеются инструменты, расщепляющие систему на пакеты для последующей работы с ними в разное время и в разных местах. Например, если есть две группы разработчиков, работающие в двух разных офисах, то первая из них может создать стабы (Stubs) для пакетов, необходимых другой группе. Такая стратегия позволяет командам работать независимо и не мешать друг другу, причем пакеты-стабы будут описывать стыковочные узлы системы, требующие особенно тщательной проработки.






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


    Рис. 13.5 Стереотипные объекты

    В UML определено два стандартных стереотипа (см. "Приложение В"), применимых к отношениям зависимости между объектами и классами.

  • instanceOf - показывает, что объект-клиент является экземпляром классификатора-поставщика;
  • instantiate - показывает, что класс-клиент создает экземпляры классификатора-поставщика.

    Существует также два относящихся к объектам стереотипа, применимых к сообщениям и переходам между состояниями (см. главу 18):

  • become - говорит, что объект-клиент - это тот же объект, что и поставщик, но в более поздний момент времени и, возможно, имеющий другие значения, состояния или роли;
  • copy - показывает, что объект-клиент является точной, но независимой копией поставщика.

    Кроме стереотипов, в UML определено одно стандартное ограничение, применимое к объектам:

  • transient - показывает, что во время выполнения взаимодействия (см. главу 15) создается экземпляр роли, который уничтожается перед завершением выполнения.




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

    В UML определены два стандартных (см. "Приложение В") стереотипа, применимых к активным классам:

  • process (процесс) - ресурсоемкий поток управления, который может выполняться параллельно с другими процессами;
  • thread (нить) - облегченный поток управления, который может выполняться параллельно с другими нитями в рамках одного и того же процесса.

    Различие между процессом и нитями связано с разными способами создания потоков управления операционной системой, работающей на узле (см. главу 26), где размещается объект.

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

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




    Все механизмы расширения UML (см. главу 6) применимы и к компонентам. Чаще всего используются помеченные значения для расширения свойств компонентов (например, для задания версии компонента) и стереотипы для задания новых видов компонентов (например, зависимых от операционной системы).

    В UML определены пять стандартных стереотипов (см. "Приложение В"), применимых к компонентам:

  • executable (исполнимый) - определяет компонент, который может исполняться в узле;
  • library (библиотека) - определяет статическую или динамическую объектную библиотеку;
  • table (таблица) - определяет компонент, представляющий таблицу базы данных;
  • file (файл) - определяет компонент, представляющий документ, который содержит исходный текст или данные;
  • document (документ) - определяет компонент, представляющий документ.

    Примечание: UML не определяет пиктограмм для этих стереотипов, хотя в "Приложении В" предлагается некоторая общепринятая нотация.



    Содержание раздела