MDD

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: простой

IBM developerWorks, IBM developerWorks, IBM

05.2007

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

В гл. 8, «Использование Rational Software Architect для разработки, управляемой моделями», объясняется, как применять Rational Software Architect (RSA) к разработке приложений и каркаса. В этой главе описывается, как вы можете дополнять RSA своими собственными трансформациями и шаблонами.

В этой главе приводятся пошаговые инструкции по размещению профилей и реализации шаблонов и трансформаций. Примеры, которые мы здесь используем, основаны на ESB-сценарии, описанном в гл. 2, «Общий обзор сценария», и в гл. 7, «Разработка шаблонов для сценария».

9.1 Введение в реализацию шаблонов и трансформаций для RSA

В гл. 3, «Разработка, управляемая моделями», вы познакомились с концепциями UML-профилей, шаблонов и трансформаций. В этой главе вы узнаете, как реализовывать шаблоны и трансформации в качестве расширений RSA.

Профили, шаблоны и трансформации упаковываются для размещения в виде плагинов (plug-ins) Eclipse. Плагин - это пакет расширений для RSA. Один плагин может содержать много расширений, которые могут быть связаны с различными аспектами RSA. Плагин может вносить свой вклад в элементы меню, кнопки панели инструментов, в представления и перспективы, а также в шаблоны, трансформации и UML-npo-фили.

Любой плагин RSA может объявлять точки расширения (extension points), в которые могут вносить свой вклад другие плагины. Таков базовый механизм расширений для платформы Eclipse, на которой базируется RSA. В число точек расширений, объявленных в редакторе UML-моделей RSA, входят точки, через которые вы можете влиять на UML-профили, шаблоны и трансформации.

RSA включает в себя все инструменты, необходимые для создания новых плагинов RSA. За общей информацией о плагинах и среде разработки плагинов (Plug-in Development Environment) обращайтесь к справке RSA, к теме «Extending Rational Software Architect functionality» (Расширение функциональности Rational Software Architect), начиная с раздела «Extending the workbench - Platform Plug-in Developer Guide» (Расширение рабочей среды - руководство разработчика плагинов для платформы).

В этой главе содержатся инструкции по выполнению специфических задач. Сначала прочитайте разд. 9.2 «Настройка: включение Eclipse Developer». Последующие разделы вы можете читать в любом порядке.

Чтобы узнать, как упаковать UML-профиль для размещения в RSA-плагин, читайте разд. 9.3, «Размещение UML-профилей».

Чтобы узнать, как расширить редактор UML-моделей в RSA, включив новые шаблоны, читайте разд. 9.4, «Реализация шаблонов».

Чтобы узнать, как разработать трансформацию, которая генерирует код по UML-mo-дели, читайте разд. 9.5, «Реализация трансформации».

В начало

9.2 Настройка: включение Eclipse Developer

Прежде чем начать работать с примерами из данной главы, включите Eclipse Developer, чтобы можно было использовать Среду разработки плагинов (Plug-in Development Environment).

1. В главном меню выберите пункт Window (Окно) -> Preferences (Настройки).
2. Установите флажок Eclipse Developer, как показано на рис. 9-1.

В начало

9.3 Размещение UML-профилей

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

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

Чтобы разместить профиль, вам нужно выполнить следующие действия:

1. Задать в карте путей местоположение профиля.
2. Выпустить версию профиля.
3. Добавить профиль в плагин.
4. Разместить плагин.

Первый шаг - настройка карты пути выполняется при создании нового профиля. Последующие шаги делаются после разработки профиля.

9.3.1 Настройка карты путей

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

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

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

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

1. Выберите пункт меню File (Файл) -> New (Новый) -> Project (Проект) -> UML Profile Project (Проект UML-профиля) и вызовите проект TestProfile.
2. Перетащите файл профиля Test.epx в новый проект и удалите из нового проекта созданный по умолчанию файл default.epx.

   Модели автоматически будут перестроены на новое местоположение профиля.

   Если модели не были правильно перестроены, очистите тестовую модель, удалив тестовый профиль, и добавьте его снова, из нового места. После этого повторно примените стереотипы.

3. Создайте карту путей, указывающую на новый проект TestProfile. Карты путей задаются в окне настроек (Preferences) рабочей среды
1. выберите в меню Window (Окно) -> Preferences (Настройки) в разделе Modeling (Моделирование);
2. используя тестовый профиль из предыдущего примера в качестве примера, настройте карту путей, чтобы она указывала на папку, содержащую тестовый профиль (рис. 9-2).

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

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

9.3.2 Выпуск версии профиля

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

1. Откройте профиль и в проводнике моделей (Model Explorer) выберите пакет с профилем. Щелкните по нему правой кнопкой мыши и выберите пункт Release (Выпустить). Введите обозначение выпуска (release label).
2. После того как вы создали новую версию профиля либо как описано выше, либо путем внесения изменений, вам нужно открыть все модели, к которым этот профиль применялся, чтобы перевести их на новую версию (рис. 9-3).

9.3.3 Добавление профиля в плагин

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

Создание нового проекта плагина

1. В главном меню выберите пункт File (Файл) -> New (Новый) -> Project (Проект) -> Plug-in Development (Разработка плагина) -> Plug-in Project (Проект плагина).
2. Плагин должен иметь уникальный идентификатор, а имя проекта плагина обычно совпадает с идентификатором плагина. Поскольку идентификатор должен быть уникальным, его название обычно имеет форму имени Java-пакета. Это может быть имя реального Java-пакета, если плагин включает исходный код Java, но это не обязательно. Идентификатор должен быть уникальным.
   Плагин обычно включает в себя код Java, поэтому проект плагина - это часто Java-проект. В данном случае мы создаем плагин, содержащий UML-профиль, и классы Java не требуются, поэтому наш проект не должен быть Java-проектом (рис. 9-4).
   
   Рис. 9-4. Мастер создания нового проекта плагина
   
   
   
3. На следующей странице мастера заполняется идентификатор (ID) плагина. Предполагается, что имя проекта совпадает с идентификатором. В поле Plug-in Name вводится удобное для восприятия имя плагина. В поле Plug-in Provider вводится удобное для восприятия название вашей компании или организации.
   Нажмите Finish (Готово), чтобы завершить создание нового проекта (рис. 9-5).
   
   Рис. 9-5. Свойства нового плагина
   
   
   
4. Файл plugin.xml - это манифест плагина, который идентифицирует плагин и объявляет, какие расширения плагин вносит в RSA. Этот файл открыт для редактирования, как показано на рис. 9-6.
   Перейдите на вкладку plugin.xml, чтобы увидеть полное содержимое этого файла в виде XML
   
   Рис. 9-6. Редактор манифеста плагина
   
   
   

В примере 9-1 показано содержимое файла манифеста плагина.

<?xml version="1.0" encoding="UTF-8"?> 
<?eclipse version=»3.0»?> 
<plugin
id =»itso.mdd.soi.profile»
name=»ITSO SOI  Profile  Plug-in»
version=»1.0.0»
provider-name=»IBM»> 
</plugin>
			

Добавление профиля в проект плагина

1. Отредактируйте манифест плагина, добавив в него (перед тегом </plugin>) текст, приведенный в примере 9.2.

<extension
            point=»com.ibm.xtools.emf.msl.Pathmaps»> 
        <pathmap
            name=»SOI_PROFILE_PATH»
            plugin=»itso.mdd.soi.profile»
            path=»profiles»> 
        </pathmap> 
</extension> 
<extension
             point=»com.ibm.xtools.uml2.msl.UMLProfiles»> 
<UMLProfile
id=»itso.mdd.soi.profile» 
name=»SOI Example Profile»
path = »pathmap://SOI_PROFILE_PATH/SOIExampleProfile.epx» 
required = »false» 
visible=»true»> 
</UMLProfile> 
</extension>
			

• Первое расширение - это карта путей. Используйте то же имя карты, которое вы применяли ранее (см. шаг 1) при указании местоположения профиля. Имя карты путей разрешается в папку profiles в данном плагине. Создайте теперь эту простую папку. После того, как вы скомпонуете размещаемый профиль, вы сможете удалить карту путей из настроек рабочей области.
• Во втором расширении объявляется, что профиль SOIExampleProfile.epx находится в месте, указанном картой путей, и ему присваивается легкое для восприятия имя.

2. Перетащите профиль Test.epx из проекта TestProfile в папку Profiles в itso.mdd.soi.test.
3. В редакторе манифеста плагина нажмите кнопку Build (Собрать).
4. В окне Binary Build (Двоичная сборка) выберите файлы и папки, которые вы хотите разместить в плагине. Обязательно нужно включить файл plugin.xml. Здесь мы также хотим включить папку profiles.
5. Сохраните и закройте манифест плагина.

9.3.4 Размещение плагина

1. В главном меню выберите пункт File (Файл) -> Export (Экспорт) -> Deployable plug-ins and fragments (Размещаемые плагины и фрагменты).
2. Чтобы разместить плагин в своей собственной рабочей среде, используйте опции, показанные на рис. 9-8. Убедитесь только, что директории соответствуют вашему варианту установки RSA.
   В результате будет создана директория с именем plugin-id_1.0.0 (ID плагина в сочетании с его версией) в указанной папке плагина, в которой будут содержаться файлы, которые вы решили включить в плагин. Вы можете сделать это вручную, а также с помощью сборочного скрипта ANT (вместо использования мастера).
3. Перезапустите RSA. Профиль готов к использованию как «размещенный профиль» с именем, которое вы присвоили ему в манифесте плагина.
   Если упаковать плагин в zip-файл, чтобы передать его кому-то другому, то вы сможете экспортировать плагин как zip-файл. Для инсталляции разархивируйте файл в соответствующую директорию и перезапустите RSA.

В начало

9.4 Реализация шаблонов

В справке Rational Software Architect содержатся обучающие материалы, относящиеся к тому, что описано в данной главе. Найдите тему Creating modeling artifacts for reuse (Создание артефактов моделирования для повторного использования) -> Authoring patterns (Создание собственных шаблонов). Существуют также примеры проектов плагинов с шаблонами, которые вы можете импортировать в рабочее пространство RSA. Обращайтесь к разделу Samples Gallery (Галерея примеров) в Help (Справка) -> Technology samples (Примеры технологии) -> Patterns (Шаблоны).

9.4.1 Начало работы

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

Создание нового проекта плагина

1. Выберите пункт меню File (Файл) -> New (Новый) -> Project... (Проект...) -> Plug-in Development (Разработка плагина) -> Plug-in Project (Проект плагина).
2. Укажите имя проекта на следующей странице мастера. Как уже говорилось в предыдущем разделе, имя проекта, идентифицирующее плагин, должно быть уникальным. В нашем примере мы назовем его ESB Service Pattern. Оставшиеся параметры на этой странице вы можете оставить так, как они заданы по умолчанию.

3. Как показано на рис. 9-10, Plug-in ID - это уникальный идентификатор плагина, и он вводится на основании допущения, что ID совпадает с именем проекта. В поле Plug-in Name вводится удобное для восприятия имя плагина. В поле Plug-in Provider вводится удобное для восприятия имя, обозначающее вашу компанию или организацию.
   Примите остальные параметры, как они есть по умолчанию и нажмите Next.

4. На странице Templates (Шаблоны) поставьте флажок Create a plug-in using one of the templates (Создание плагина с использованием одного из шаблонов) и выберите пункт Plug-in with Patterns (Плагин с шаблонами). По образцу плагина создается новый проект с манифестом плагина и базовым классом реализации библиотеки шаблонов.
   Нажмите Finish (Готово).
5. В диалоговых окнах Confirm Perspective Switch (Подтверждение переключения перспектив) и Confirm Enablement (Подтверждение включения) выберите Yes (Да).

На рис. 9-12 приводится внешний вид проекта плагина для шаблона после успешного создания проекта.

В этом новом проекте плагина формируется каркас шаблона на основе Java. Каркас предоставляет функции, которые автор шаблона может использовать при определении поведения шаблона.

Базовый код, созданный в этом каркасе, называется моделью реализации, и он включает в себя:

• библиотеку шаблонов, содержащую тела шаблонов и их параметры;
• тела шаблонов, каждое из которых представляет собой Java-класс;
• Java-класс со вложенными классами для каждого параметра;
• классы-параметры, каждый из которых представляет собой пустое расширение и методы обновления для добавления, удаления или внесения изменения в аргумент.

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

В RSA есть представление Pattern authoring (Создание собственных шаблонов), которое представляет собой инструмент с графическим пользовательским интерфейсом для проектирования библиотеки шаблонов. По умолчанию после создания проекта плагина это представление отображается в нижней части рабочей среды, как это показано на рис. 9-13- Щелкните правой кнопкой мыши по указанному здесь пункту ESB Service Pattern.

В этом меню есть следующие пункты:

• New Pattern... (Новый шаблон...). Вызывает мастера создания нового шаблона в данной библиотеке.
• Export... (Экспорт...) Вызывает мастера экспортирования библиотеки шаблонов как актива с возможностью повторного использования.
• Generate Help Files (Генерация файлов справки). Генерирует для шаблона стандартную справочную документацию RSA.Привыбореэтогопунктаменюсоздаются. При выборе этого пункта меню создаются следующие элементы
  • HTML-файл, использующий информацию, содержащуюся в дескрипторе размещения формата Reusable Asset Specification (RAS) библиотеки шаблонов.
  • оглавление библиотеки шаблонов;
  • HTML-файлы для каждого шаблона в библиотеке, с использованием информации, содержащейся в дескрипторе размещения RAS шаблона;
  • оглавление каждого шаблона;
  • ссылки на файлы оглавления в файле plugin.xml, относящемся к данной библиотеке.
• Regenerate Source Code (Регенерация исходного кода). Повторная генерация базового кода библиотеки шаблонов. Полезно, если код оказывается несинхронизи-рованным со статическими данными в библиотеке или с файлами манифестов.
• Show Properties View (Показать представление Свойства). Переключение на представление Properties (Свойства), в котором отображаются настройки параметров библиотеки шаблонов.

Далее мы создадим шаблон в библиотеке шаблонов ESB Service, а затем реализуем метод расширения для созданного шаблона.

9.4.2 Определение шаблона

Шаблон содержит следующие переменные:

• Имя класса реализации. Это необязательный элемент. Если отсутствует, будет создан базовый (skeleton) файл.
• Один или несколько параметров. Параметры шаблона определяют, к чему применяется данный шаблон.

Выполните следующие инструкции, чтобы создать шаблон и добавить его в только что созданную библиотеку шаблонов (т. е., в нашем примере в библиотеку ESB Service Pattern).

1. Перейдите в представление Pattern authoring (Создание собственных шаблонов) и щелкните правой кнопкой мыши по новой библиотеке шаблонов.
2. Выберите пункт меню New Pattern... (Новый шаблон...).
3. Откроется страница New Pattern (Новый шаблон):
   1. Измените значение в поле Pattern Name (Имя шаблона), введя туда имя создаваемого шаблона. В нашем примере это имя Service Connection Pattern. Обратите внимание, что значения в полях Class Name (Имя класса) и Package (Пакет) обновляются автоматически в соответствии с новым именем.
   2. Для нового шаблона можно выбрать один из трех типов - Collaboration (Кооперация), Package (Пакет) и Class (Класс), которые определяют тип UML-эле-мента для экземпляра данного шаблона. Эти типы соответствуют спецификации суперструктуры UML2 для следующих шаблонов:
      • Кооперация (Collaboration). Как показывает само название, это кооперация (взаимодействие) между элементами. Этот тип применяется не только к кооперации. Он может содержать параметры почти для каждого типа UML-элемен-тов. Это наиболее часто используемый тип, и именно его мы будем применять в нашем примере.
      • Пакет (Package). Как правило, используется для представления архитектуры программных систем, например уровней или общей структуры пакетов.
      • Класс (Class). Это эквивалент параметризованного класса. Он используется редко.
   3. Для всех указанных параметров генерируется базовый код в классе реализации шаблона, который затем можно дополнять, вводя операции над значениями, указанными в качестве параметров. Параметры можно добавлять или удалять либо при помощи данного мастера, либо в представлении Pattern authoring (Создание собственных шаблонов).

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

      По умолчанию новые шаблоны помещаются в группу Miscellaneous Patterns (Разные шаблоны), и это означает, что при публикации плагина он будет отображаться в проводнике по шаблонам (Pattern Explorer) как член группы Miscellaneous. В нашем примере мы поместим шаблон в новую группу, которую назовем Service Patterns.

      Нажмите кнопку Add (Добавить) рядом с текстовым полем Groups (Группы). Введите в поле имени группы имя ServicePatterns и нажмите OK.

   4. Поле версии в данном примере можно оставить незаполненным, но помните, что это поле становится важным, если шаблон упаковывается как актив RAS, и значение из этого поля становится версией актива. Это касается и вкладки Details (Детали). Информация на этой странице используется для заполнения манифеста RAS шаблона, а также документации, но в данном примере эти поля можно оставить пустыми.

На рис. 9-15 показано, как теперь выглядит страница.

Во вкладку Detail (Подробная информация) вы можете ввести описание нового шаблона.

Нажмите OK. Теперь у нас есть шаблон, который мы скоро реализуем.

Проект шаблона содержит следующие директории и файлы

• Классы с Java-кодом. Хранятся в директории src. Классы для проекта плагина и библиотеки шаблонов создаются автоматически. В нашем примере они находятся собственно в пакетах ESB_Service_Pattern и ESB_Service_Pattern.lib. Отдельные классы также генерируются для каждого шаблона, добавляемого в библиотеку. Они находятся в пакете ESB_Service_Pattern.patterns.<nM# шаблона>.
• Директория PatternFiles. Эта созданная по умолчанию директория содержит следующие элементы: файл документации манифеста RAS (.rmd)длябиблиотекииS(.rmd)длябиблиотекии (.rmd)длябиблиотекии) для библиотеки и каждого шаблона; файл модели шаблона, содержащий определение шаблона, и, если созданы, справочные HTML-файлы шаблона со вспомогательным XML-файлом.
• Директория Icons. По умолчанию содержит один образец значка, sample.gif.
• Файлы плагинов. Компоновочный файл (build.properties) и XML-файл плагина (plugin.xml) используются, когда шаблон экспортируется для создания плагина шаблона RSA.Поумолчаниюисходныйкодплагинаневключаетсявплагин,со. По умолчанию исходный код плагина не включается в плагин, создаваемый при помощи экспорта.
• Графическое представление диаграммы. Автор шаблона может включить в плагин дополнительный GIF-файл, отображающий высокоуровневое представление компонентов шаблона для того, кому придется этот шаблон применять.

9.4.3 Реализация шаблона

За подробной информацией о реализуемом шаблоне и всем примере обращайтесь к гл. 5, «Жизненный цикл решения, создаваемого с использованием разработки, управляемой моделями». Чтобы быстро увидеть взаимосвязи, мы приводим диаграмму, которая использовалась в гл. 5 для описания шаблона.

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

• фасад интеграционной службы (ISF);
• интеграционная служба (IS);
• два фасада поставщика (PF1 и PF2).

Между этими компонентами в кооперации существуют связи, которые используют порты, определяемые в каждом компоненте.

Реализация методов расширения

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

Наш шаблон Service Connection Pattern имеет только один параметр - тип кооперации (т. е. ESB). Для определения параметра выполните следующие инструкции:

1. В представлении Pattern authoring (Создание собственных шаблонов) выберите пункт меню Windows (Окна) -> Show View (Показать представление) -> Other... (Другое...) -> Modeling (Моделирование) -> Pattern authoring (Создание собственных шаблонов).
2. Выберите интересующий вас шаблон. В данном примере мы выбираем шаблон Service Connection Pattern. Щелкните по нему правой кнопкой мыши и выберите пункт меню New Parameter... (Новый параметр...).
3. В панель Parameter (Параметр) (рис. 9-17) введите имя параметра - ESB Collaboration. Выберите тип - Collaboration. Параметр «Кратность» (multiplicity) установите равным единице.

Давайте рассмотрим изменения, которые были внесены в класс реализации шаблона (ESB_Service_Pattern.patterns.serviceconnectionpattern.ServiceConnectionPattern.java). Вы можете найти этот класс в элементе ESB Service Pattern -> src в представлении Package Explorer (Проводник по пакетам).

Для указанного параметра был сгенерирован внутренний класс ESBCollaboration, который содержит методы расширения, необходимые для реализации. В примере 9-3 приведены сигнатуры этих методов.

public boolean expand(PatternParameterValue value);
public boolean expand(PatternParameterValue.Removed value);
			

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

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

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

Чтобы реализовать шаблон, вам нужно хорошо знать UML2 API. Информацию об UML 2 вы можете получить на следующем Web-сайте:

http://www.eclipse.org/uml2

За подробной информацией об использовании этих классов также обращайтесь к теме Patterns framework API в справке RSA. Пункт меню Help (Справка) -> Help Contents (Содержание) -> Extending Rational Software Architect functionality (Расширение функциональности Rational Software Architect) -> Extensibility reference (Справочник по расширяемости) -> API Reference (Справочник по API).

В следующих описаниях примеров кода мы предполагаем, что вы уже немного знакомы с UML2 API.

Пример кода для шаблона ESB Service Pattern

Сначала мы рассмотрим, как создать четыре компонента в модели кооперации ESB. Компонент - это тип атрибута (свойство, в терминах UML).Поэтомусначаламы). Поэтому сначала мы должны создать четыре объекта-свойства, а затем определить их тип как Component.

Создание объектов-свойств

В сгенерированном методе expand() замените все, что указано в примере 9-4, на то, что указано в примере 9-5.

/**
* Это метод расширения, создаваемый по умолчанию, который обычно реализуется
* с помощью параметров шаблона.
*
* Поведение по умолчанию - вернуть true.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
*  @generated
* /
public boolean expand(PatternParameterValue value)   {
      //Сделать : реализовать метод расширения для параметра 
      return  true;
}
			

/**
* Это метод расширения, создаваемый по умолчанию, который обычно реализуется
* с помощью параметров шаблона.
* Поведение по умолчанию - вернуть true.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
*/
public boolean  expand(PatternParameterValue value)   {
      Collaboration  collValue =  (Collaboration) value.getValue();

      // Creating the Integration Facade Service (IFS) component 
      Property collIFSProperty = createProperty(collValue, «IFS»); 
      Component ifsComp = createComponent(collValue, collIFSProperty, 
      collValue.getName()  +  «IFS»);

      // Создание IS-компонента
      Property collISProperty = createProperty(collValue, «IS»); 
      Component  isComp = createComponent(collValue, collISProperty, 
      collValue.getName()  +  "IS");

      // Создание компонента фасада первого поставщика (PFS1) 
      Property collPFS1Property = createProperty(collValue, «PFS1»); 
      Component pfsiComp = createComponent(collValue, collPFSIProperty, 
      collValue.getName()  +  "1PFS");

      // Создание компонента фасада второго поставщика (PFS2) 
      Property collPFS2Property = createProperty(collValue, «PFS2»); 
      Component pfs2Comp = createComponent(collValue, collPFS2Property, 
      collValue.getName()  +  «2PFS»); 
      return true;
}
			

Совет. Многие типы, такие, как Property, остаются неразрешимыми, поскольку не импортированы необходимые UML-пакеты. Чтобы исправить эти проблемы, укажите на красный крестик на левом поле редактора исходного кода и выберите для каждого типа uml-пакет для импорта.

Обратите внимание, что сгенерированный тег Javadoc™ @ был удален, поскольку модель реализации генерируется заново при каждом изменении библиотеки шаблонов. Если тег не удален, значит, модификации были уничтожены путем перезаписи в ходе повторной генерации кода.

Реализация методов-утилит

Далее мы реализуем методы-утилиты, используемые в методе expand(), а именно createProperty() и createComponent(). Поместите эти методы непосредственно перед методом public boolean expand(PatternParameterValue value).

private  Property createProperty(Collaboration  coll, String propertyName) { 
      Property collProperty =
      coll. сreateOwnedAttnbute(UML2Package. eINSTANCE. getProperty()); 
      collProperty. set Name (propertyName); 
      return collProperty;
}
			

private Component createComponent
         (Collaboration coll, Property collProperty, String compName) { 
     Component aComp = UML2Factory.eINSTANCE.createComponent(); 
     aComp.set Name(compName);

     collProperty.setType(aComp);

     //Добавление созданных компонентов как отдельных элементов в пакет модели 
     coll.getPackage().getOwnedMembers().add(aComp);

     return aComp;
}
			

Теперь мы готовы к созданию коннекторов для следующих пар компонентов:

• IFS -> IS;
• IS -> PFS1;
• IS -> PFS2.

Добавление входных и выходных портов к компонентам

Чтобы можно было соединить компоненты, они должны иметь входные и выходные порты. Объект-порт, соответствующий объекту-порту UML-модели, - это точка взаимодействия между классификатором и его окружением. Выходной порт (out) представляет сторону, от которой исходит запрос, а входной порт (in) - получателя.

Добавьте код, приведенный в примере 9-8, в метод createComponent (), перед вызовом collProperty.setType(aComp).

Port  inPort = aComp. createOwnedPort(UML2Package. eINSTANCE. getPort()); 
Port outPort = aComp. createOwnedPort(UML2Package. eINSTANCE. getPort()); 
inPort.setName(«in»); 
outPort.setName(«out»);
			

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

Метод-утилита для создания коннекторов

Добавьте код, приведенный в примере 9-9, в конец метода expand(), перед оператором returntrue. true.

//Коннектор  IFS  ->  IS
Connector ifsOutPortToIsInPort = createConnector(collValue,
    collIFSProperty,   ifsComp,   collISProperty,   isComp); 
//Коннектор  IS  ->  PFS1 
Connector isOutPortToPfs1InPort = createConnector(collValue,
    collISProperty,   isComp,   collPFS1Property,   pfs1Comp); 
//Коннектор  IS  ->  PFS2
Connector isOutPortToPfs2InPort = createConnector(collValue,
    collISProperty,   isComp,   collPFS2Property,   pfs2Comp);
			

Реализуем метод-утилиту сreateConnector() (пример 9-10).

        (Collaboration  coll, Property outPortProperty,
        Component outComp, Property inPortProperty, Component inComp) {
     Connector aConnector =
        coll.create0wnedConnector(UML2Package.eINSTANCE.getConnector());
     ConnectorEnd outPort =
        aConnector.create End(UML2 Package.eINSTANCE.getConnectorEnd()); 
     ConnectorEnd inPort =
        aConnector.create End(UML2 Package.eINSTANCE.getConnectorEnd()); 
     outPort. setPartWithPort (out PortProperty); 
     outPort.setRole(outComp.getOwnedPort("out")); 
     inPort. setPartWithPort(inPortProperty); 
     inPort.setRole(inComp.getOwnedPort("in")); 
     return  aConnector;
}
			

Применение стереотипа службы-поставщика

И наконец, нам нужно применить стереотип службы-поставщика к четырем компонентам. Стереотип службы-поставщика определен в профиле UML 2.0 Profile for SoftforSoftr ware Services, который вы должны установить как плагин в рабочую среду. За информацией об этом профиле обращайтесь к следующему сайту:

http://www.ibm.com/developerworks/rational/library/05/419_soa/

Прежде чем мы сможем применять стереотип, мы также должны убедиться, что профиль был применен к модели.

В начале кода метода expand() найдите следующую строку:

Collaboration collValue =  (Collaboration) value.getValue(); 
			

После этой строки добавьте код, приведенный в примере 9-11.

//Применение  профиля  UML  2.0  Profile for Software Services 
//Получение  инсталлированного профиля
    Resource   resource = collValue.eResource().getResourceSet().getResource( 
URI.createURI(«pathmap://SOFTWARE_SERVICES/profiles/SoftwareServices.epx»), 
true); 
Profile softSrvProfile =  (Profile)  EcoreUtil.getObjectByType(
        resource.getContents(), UML2Package.eINSTANCE.get Profile()); 
//Был ли  профиль применен?  Если  нет, применить 
if  (false == collValue.getModel().isApplied(softSrvProfile)) { 
       collValue.getModel().apply(softSrvProfile);
}
			

Полное URL-имя, используемое в методе сreateURI(), было получено из файла plugin. xml инсталлированного профиля.

1. Чтобы открыть файл plugin.xml, выберите пункт меню Windows (Окна) -> Show View (Показать представление) -> Other... (Другое...).
2. В списке Show View (Показать представление) выберите PDE -> Plug-ins (Плагины).
3. После открытия представления перейдите в пакет, в который инсталлирован профиль. Для профиля Software Services - это пакет com.ibm.rational.softsvc. Файл plugin.xml находится прямо под именем пакета.
4. Откройте файл plugin.xml и посмотрите на исходный код. URL определяется в строке

   <extension><UMLProfile path=«......»></UMLProfile></extension>

   
   

Во фрагменте «......» находится полное URL-имя. В нашем случае оно определяется как «pathmap://SOFTWARE_SERVICES/profiles/SoftwareServicesSecurity.epx».

Далее идет последняя часть реализации нашего шаблона Service Connection Pattern -применение стереотипа службы-поставщика.

Добавьте код, приведенный в примере 9-12, в конец метода expand(), прямо перед строкой return true;.

//Получить шаблон поставщика и применить его к четырем компонентам 
Stereotype sTypeObj  = ifsComp.getApplicableStereotype(
          «Software Services  Prof lie::ServiceProvider»); 
if (null != sTypeObj) {
      ifsComp.apply(sTypeObj);
      isComp.apply(sTypeObj);
      pfsiComp.apply(sTypeObj);
      pfs2Comp.apply(sTypeObj);
}  else  {
      System.out.println(«The Stereotype ServiceProvider cannot  be found from 
the 
Software  Services  Profile");
}
			

В примере 9-13 приведен список необходимых импортируемых классов.

import   org.eclipse.emf.ecore.resource.Resource;
import   org.eclipse.emf.ecore.util.EcoreUtil;
import   org.eclipse.emf.common.util.URI;
import   org.eclipse.uml2.Collaboration;
import   org.eclipse.uml2.Component;
import   org.eclipse.uml2.Connector;
import   org.eclipse.uml2.ConnectorEnd;
import   org.eclipse.uml2.Port;
import   org.eclipse.uml2.Profile;
import   org.eclipse.uml2.Property;
import   org.eclipse.uml2.Stereotype;
import   org.eclipse.uml2.UML2Factory;
import   org.eclipse.uml2.UML2Package;
			

9.4.4 Тестирование шаблона

Для тестирования шаблона выполните следующие шаги:

1. Запустите рабочую среду времени выполнения. Если вы не знаете, как это сделать, обращайтесь к разд. 9.6, «Запуск рабочей среды времени выполнения».
2. После запуска рабочей среды переключитесь на перспективу Modeling (Моделирование).
3. Вам потребуется UML-модель, к которой будет применяться шаблон. Создайте новый проект модели, выбрав пункт меню New (Новый) -> Project (Проект) -> Modeling (Моделирование).
4. Выберите пункт UML Project (UML-проект) и нажмите Next (Далее).
5. Введите имя проекта - ESB Service Pattern Test - и нажмите Next (Далее).
6. Измените значение Blank Model на My Simple Model, как показано на рис. 9-19, и нажмите Finish (Готово).
7. В проводнике по моделям (Model Explorer) откройте пункт ESB Service Pattern Test -> My Simple Model.emx -> My Simple Model.
8. Выделите пункт My Simple Model и сделайте двойной щелчок мышью по диаграмме в свободном стиле Main.
9. После того как откроется диаграмма Main, снова откройте представление Pattern Explorer (Проводник по шаблонам) и перетащите элемент Service Connection Pattern на диаграмму, как показано на рис. 9-20.

Применение шаблона

Для применения шаблона выполните следующие шаги:

1. Откройте пункт Composite Structure Diagram (Диаграмма композитной структуры) -> Collaboration (Кооперация).
2. Сделайте щелчок мышью в пустом месте диаграммы. Теперь на диаграмме появится контур кооперации. Обратите внимание, что созданная кооперация отображается в пункте My Simple Model в проводнике по моделям (Model Explorer). Также ее можно увидеть в представлении Properties (Свойства).

3. В представлении Properties (Свойства) переименуйте кооперацию Collaboration1 в ESB Service Collaboration.
4. Чтобы применить шаблон, перетащите ESB Service Collaboration diagram в поле ESB Collaboration[1] в экземпляре шаблона Service Connection Pattern.

Теперь созданные компоненты отображаются в Проводнике моделей (см. рис. 9-23).

После применения шаблона убедитесь, что к модели был применен профиль:

5. Сделайте двойной щелчок мышью по файлу My Simple Model.emx. При этом модель откроется в редакторе UML-моделей.
6. В редакторе взгляните на раздел Applied Profiles (Примененные профили), и вы увидите там профиль Software Service Profile.

7. Также проверьте, были ли стереотипы профиля применены к элементам модели. Сделать это можно, взглянув на свойства (Properties) каждого созданного компонента:
   1. Щелкните правой кнопкой мыши по компоненту и выберите пункт меню Show Properties View (Показать представление свойства).
   2. В представлении Properties (Свойства) щелкните мышью по пункту Stereotypes (Стереотипы) на панели слева и взгляните на раздел Applied Stereotypes (Примененные стереотипы). Здесь будет указан стереотип ServiceProvider из профиля Software Services Profile.

9.4.5 Публикация шаблонов

Вы можете опубликовать шаблон, экспортировав его как размещаемый плагин. За соответствующими инструкциями обращайтесь к разд. 9.7, «Размещение плагинов».

В начало

9.5 Реализация трансформации

Как уже обсуждалось в гл. 8, «Использование Rational Software Architect для разработки, управляемой моделями», вы можете применять трансформацию к модели, используя в перспективе Modeling (Моделирование) пункт меню Modeling (Моделирование) -> Transform (Трансформация). Чтобы добавить свою трансформацию к этому меню, вам нужно создать плагин Eclipse, который будет связан с точкой расширения поставщика трансформации. Существует шаблон проекта плагина, который позволяет настроить манифест и базовые классы.

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

9.5.1 Создание нового плагина с трансформацией

1. В главном меню выберите пункт File (Файл) -> New (Новый) -> Project (Проект) -> Plug-in Development (Разработка плагина) -> Plug-in Project (Проект плагина).
2. Откроется панель Plug-in Project (Проект плагина). Плагин должен иметь уникальный идентификатор. По умолчанию имя проекта плагина задается в соответствии с идентификатором. Поскольку идентификатор должен быть уникальным, его название обычно имеет форму имени Java-пакета. Это может быть имя реального Java-пакета, если плагин включает исходный код Java, но это необязательно. Идентификатор должен быть уникальным.
   Плагин с трансформацией включает код Java,поэтомуустановитеопцию, поэтому установите опцию Create a Java project (Создать Java-проект) и нажмите Next (Далее).

3. Откроется панель Plug-in Content (Содержание плагина) (рис. 9-25). В свойствах плагина идентификатор (Plug-in ID) по умолчанию задается равным имени проекта плагина. В поле Plug-in Name вводится удобное для восприятия имя плагина. В поле Plug-in Provider вводится удобное для восприятия название вашей компании или организации.
   Примите заданные по умолчанию параметры и нажмите Next (Далее).

4. На панели Templates (Шаблоны) (рис. 9-26) выберите шаблон, который генерирует часть базовых классов, которые вам нужно включить в плагин. Выберите шаблон Plug-in with Transformation инажмите нажмите Next (Далее).

5. В окне Transformation Provider (Поставщик трансформации) (рис. 9-27) вы можете выбрать имя Java-пакета или класса, который будет использоваться для одного из главных генерируемых классов - поставщика трансформации (transformation provider). По сути, это точка входа для вашей трансформации. Класс-поставщик трансформации объявляется в манифесте плагина, поэтому, если вы решите позже переименовать его, не забудьте изменить имя и в манифесте.
   Нажмите Next (Далее).

6. На панели New Transformation (Новая трансформация) (рис. 9-28) отображается информация, которую вы можете использовать для генерации базового класса трансформации. Поставщик трансформации может содержать одну или несколько трансформаций, каждая из которых реализуется Java-классом.
7. Каждая трансформация, объявленная в манифесте плагина, отображается в мастере Configure Transformations (Конфигурирование трансформаций), который вызывается через пункт меню Modeling (Моделирование) -> Transform (Трансформация) -> Configure Transformations... (Конфигурирование трансформаций...). Такие опции, как имя, путь к группе и описание, определяют, как трансформация будет выглядеть в окне мастера.
   Опции Source Model Type (Тип исходной модели) и Target Model Type (Тип целевой модели) влияют на выбор исходной и целевой модели для трансформации. Тип Resource обозначает все, что не является UML-моделью.
   Обратите внимание, что в нижней части страницы выбрана опция Use default UML2 Transformation framework (Использовать заданный по умолчанию каркас трансформаций UML2). Этот параметр определяет стиль генерируемого базового кода трансформации. В нашем примере трансформации мы будем использовать стиль по умолчанию.
   Нажмите Next (Далее).

8. Поскольку используется заданный по умолчанию каркас трансформаций UML2, в панели New Rule Definitions (Определение новых правил) (рис. 9-29) вы можете определить классы правил, связанные с конкретными типами элементов. Эта информация применяется для генерации базового кода трансформации. Мы определим правила позже.
   Нажмите Finish (Готово), чтобы сгенерировать проект плагина.

На рис. 9-30 показаны файлы, сгенерированные для нового проекта. Сгенерированы класс плагина ExamplePlugin.java, поставщик трансформации ServiceTransformProvider.java и корневой класс ServicesTransformation.java.

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

Поставщик трансформаций

В манифесте плагина, plugin.xml, объявляется класс-поставщик трансформаций. Он расширяет абстрактный базовый класс, AbstractTransformationProvider, и в нем перечислены трансформации, которые этот класс может выполнять. Перечисленные здесь трансформации отображаются в мастере Configure Transformations (Конфигурирование трансформаций), который можно вызвать через пункт меню Modeling (Моделирование) -> Transform (Трансформация) -> Configure Transformations... (Конфигурирование трансформаций...) Modeling (Моделирование) -> Transform (Трансформация) при размещении плагина. Когда пользователь выбирает одну из этих трансформаций, именно поставщик трансформаций отвечает за проверку контекста трансформации (исходного и целевого объектов и всех свойств) и конструирование корневой трансформации, которая и выполняет процесс преобразования.

Наш сгенерированный поставщик трансформаций настроен для обработки одной трансформации и не проводит специальных проверок контекста трансформации.

Корневая трансформация

Метод createTransform поставщика трансформаций необходим для того, чтобы получить экземпляр класса AbstractTransform. Это абстрактный класс, поэтому на практике вы должны вернуть экземпляр какого-нибудь класса-потомка AbstractTransform.

Шаблон плагина с трансформацией создает класс, расширяющий класс RootTransform. Именно экземпляр этого класса создается сгенерированным поставщиком трансформаций.

Чтобы понять, что делает класс RootTransform, мы должны дать краткий обзор основных классов, входящих в API трансформаций RSA.

9.5.2 API трансформаций

В справке RSA можно найти JavaDoc, посвященный API (интерфейсу прикладного программирования) трансформаций. API трансформаций состоит из четырех пакетов, но только два из них представляют для нас непосредственный интерес: com.ibm. xtools.transform.core и com.ibm.xtools.transform.uml2.

Пакет com.ibm.xtools.transform.core

Основные классы и интерфейсы, входящие в этот пакет, показаны на рис. 9-31.

AbstractTransform

AbstractTransform - это абстрактный базовый класс для всех реализаций трансформаций. Он содержит один абстрактный метод:

public void  execute(ITransfomContext  context);
			

Совсем не обязательно создавать непосредственных потомков класса AbstractTransform. Неабстрактных классов-потомков Transform и RootTransform, наряду с классами UMLTransform и UMLKindTransform из пакета com.ibm.xtools.transform.uml2, в большинстве случаев вполне достаточно.

ITransformContext

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

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

Transform

Экземпляр класса Transform реализует метод execute (выполнить) путем перебора коллекции трансформаций, правил и средств извлечения (экстракторов) и вызова их методов execute.

Трансформация является экземпляром класса-потомка AbstractTransform. Любая коллекция трансформаций, правил и экстракторов выполняется классом Transform. Разные экземпляры класса Transform могут выполнять одинаковые правила, и классу Transform разрешено запускать самого себя.

AbstractRule

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

AbstractContextExtractor

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

RootTransform

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

Пакет com.ibm.xtools.transform.uml2

Этот пакет содержит несколько классов, предназначенных специально для работы с моделями UML2.НаснаиболееинтересуетклассUML2. Нас наиболее интересует класс UMLKindTransform. На рис. 9-32 показано, как класс UMLKindTransform расширяет класс Transform через класс UML-Transform

UMLKindTransform

Класс UMLKindTransform также является потомком класса Transform (не прямым), но работает совершенно по-другому. Он содержит набор правил, экстракторов и трансформаций, каждый из которых связан с типом элемента UML-модели (Class, Property, Activity и т. п.). Этот класс проходит по UML-модели или части модели и для каждого исходного элемента выполняет все правила, экстракторы и преобразования, зарегистрированные для этого типа элемента модели.

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

Когда вы применяете класс UMLKindTransform, вы не можете использовать механизм расширения трансформаций и позволять другим плагинам дополнять вашу трансформацию другими правилами.

UMLTransform

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

9.5.3 Реализация корневой трансформации

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

/**
  *   Constructor.
  *   @param descriptor  A transformation  descriptor.
  */
public ServiceTransformation(ITransformationDescriptor descriptor)   { 
      super(descriptor);

      // Инициализация  корневой трансформации  с помощью  главной трансформации.
      // При  значении аргумента false  главная трансформация  будет работать
      // только  с одиночным объектом  (а не со списком  выбранных объектов).
      UMLKindTransform umlkindTransform = new UMLKindTransform(descriptor);
      initialize(umlkindTransform, false);
      // Определение правил, которые будут выполняться до и после
      // главной трансформации.
      setuplnitialize();
      setupFinalize();
      // Добавление  правил  к  главной трансформации.
      addUMLRules(umlkindTransform);
			

Сгенерированные методы setuplnitialize, setupFinalize и addUMLRules - это пустые методы для добавления вашего кода. Методы setupInitializeиsetupeиsetup и setupFinalize, как показывает их название, - это место для кода, выполняемого перед или после определения главной трансформации. Для данного примера обработка в начальной или завершающей фазе не нужна.

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

В данном примере мы хотим сгенерировать артефакты, перечисленные в табл. 9-1.