Перед началом работы

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

О данной серии

Чтобы использование принципов и методов управляемой моделями разработки (MDD) было выгодным, среда проектирования и разработки должна иметь следующие характеристики:

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

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

Поддержка процесса и рекомендации: В контексте метода или процесса всегда предусмотрены рекомендации.

Расширяемость платформы: Рабочие группы могут дополнить или настроить среду в соответствии со своими потребностями.

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

Все эти характеристики можно отнести к IBM Rational Software Delivery Platform, и, в частности, к IBM Rational Software Architect.

В этой серии статей мы расскажем о том, как расширить функциональные возможности платформы Rational; это поможет вам в создании решений на базе SOA. В учебных руководствах данной серии, состоящей из четырех статей, рассказывается о том, что такое моделирование и как использовать средство расширения функциональных возможностей Rational Software Architect.

• В части 1 рассказывается о связи технологий SOA и разработки, управляемой моделями;
• В части 2 подробно описывается создание UML-профилей и шаблонов моделей;
• Часть 3 знакомит с проектированием на базе шаблонов, созданием шаблонов и преобразований.

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

О данном учебном руководстве

В этом учебном руководстве, части 1 нашей серии, мы рассмотрим взаимоотношения между SOA и средствами расширения функциональных возможностей Rational Software Architect. Мы продемонстрируем, как можно использовать пользовательские шаблоны и профили в Rational Software Architect для автоматизации проектирования SOA-решений. Rational Software Architect предлагает несколько функций, которые можно комбинировать для повышения производительности при разработке решений SOA и других решений. Эти автоматизированные процедуры можно использовать для повышения качества решения, а также для поддержки всего процесса управления.

Цели

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

Изучив данное учебное руководство, вы сможете рассказать о различных способах создания шаблонов в Rational Software Architect. Кроме того, вы сможете создавать несложные профили и шаблоны.

Необходимые условия

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

UML, (унифицированный язык моделирования, Unified Modeling Language)

Rational Software Architect или IBM Rational Software Modeler

SOA (service-oriented architecture, сервис-ориентированная архитектура)

Полезные ссылки на соответствующие темы можно найти в конце этого учебного руководства в разделе "Ресурсы".

Требования к системе

Для изучения данного учебного руководства необходимо, чтобы в системе были установлены такие программные продукты, как

• Rational Software Architect или IBM Rational Software Modeler.

Введение в технологию управляемой моделями разработки для сервис-ориентированной архитектуры

В одной из наших серий, "Design SOA Services with Rational Software Architect" (Проектирование SOA-сервисов при помощи Rational Software Architect) (см. раздел Ресурсы), мы рассказали о том, как можно использовать модели для документирования проектов решений на основе SOA Rational. В течение всего времени мы могли работать с различными уровнями абстракции и использовать ряд элементов модели. Эти элементы моделей помогли нам спроектировать и сгенерировать необходимые артефакты с необходимой степенью детализации.

В данном учебном руководстве вы сможете создать свои артефакты моделирования MDD при помощи Rational Software Architect, в том числе:

• Профили: Используя формальный механизм расширения UML, мы можем дополнить язык, добавив в него стереотипы, свойства и ограничения;

• Шаблоны моделей: Шаблоны модели полезно использовать при создании новых моделей в Rational Software Architect. Вместо того, чтобы создавать модель с нуля, можно привнести в проект моделирования предварительно настроенную структуру, включающую элементы модели, диаграммы и документацию. Чаще всего вам придется адаптировать шаблон модели к конкретной задаче, например к созданию модели контрольных примеров или модели анализа.

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

SOA и модели, ресурсы, шаблоны и расширяемость

На рисунке 1 показан стек SOA-решений, который является концептуальным представлением того, как SOA-решение выглядит в процессе исполнения. Мы видим пять уровней:

• Потребители;
• Бизнес-процессы;
• Сервисы;
• Компоненты сервисов;
• Операционные системы.

Эти уровни можно отобразить на проектировании программного обеспечения или уровни абстракции - чем выше уровень, тем выше уровень абстракции. Ядром стека SOA-решения является уровень Сервисы (рисунок 1), который представляет программную архитектуру сервис-ориентированных решений.

Рисунок 1. Стек SOA-решения

Соглашения и концепции SOA

Несмотря на то, что людям больше известны шаблоны проектирования группы Gang of Four, которые в стеке SOA-решения применяются к уровню компонентов сервисов, шаблоны применяются также ко всем другим уровням. При использовании SOA в качестве архитектурного стиля принципы расширяемости, многократного использования ресурсов или автоматизации применяются ко всем пяти уровням. Например, шаблоны уровня архитектуры бизнеса, входящие в состав компонентной модели бизнеса (Component Business Model) IBM®, используются для представления организаций как сущностей на основе предоставляемых и запрашиваемых бизнес-сервисов.

Технология разработки, управляемой моделями (model-driven development, MDD), которая построена на моделях и преобразованиях, позволяет моделировать программное обеспечение на различных уровнях абстракции, с учетом трассируемости и подотчетности. Следовательно, имеет смысл применить подход MDD к поставке SOA-решений. Представьте себе, что у нас есть модели SOA-решений для каждого из пяти уровней стека SOA-решения, и мы можем преобразовать модели от более высоких к более низким уровням абстракции. SOA-модели и преобразования были созданы и успешно использованы в проекте. В числе прочих артефактов они включали профиль Unified Modeling Language (UML) для программирования сервисов и преобразование UML - Web Services Definition Language (WSDL, язык описания Web-сервисов). (Дополнительную информацию об этих двух артефактах можно получить из учебного руководства "Design SOA Services with RSA" (Проектирование SOA-сервисов при помощи RSA), см. раздел Ресурсы). Использование MDD в контексте SOA предполагает такие преимущества, как высокая целостность, наличие перспективы SOA для всех заинтересованных лиц, выигрыш в качестве и производительности и трассируемость решений на всем протяжении разработки до бизнес-требований.

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

Технология разработки, основанной на использовании ресурсов (asset-based development, ABD) - это дисциплина проектирования программного обеспечения, которая строится на использовании для создания решений программных ресурсов. Успешное применение принципов ABD при разработке SOA-решений предлагает ряд преимуществ и требует соблюдения всего нескольких условий, причем это не только изменения культурного характера. Например, необходим процесс для жизненного цикла ресурсов (одобрение, отказ от поддержки и т. п.), а сотрудники организации должны иметь возможность найти и использовать эти ресурсы в процессе работы над SOA-решением. Основной тип ресурсов - это сервисы.

Реестры и репозитории сервисов поддерживают многократное использование благодаря тому, что они хранят информацию о сервисах в процессе прохождения ими фаз жизненного цикла. Реестры и репозитории сервисов позволяют обеспечить многократное использование сервисов и их доступность. Репозитории ресурсов, например репозитории спецификации многократно используемых ресурсов (Reusable Asset Specification, RAS), тоже важны, потому что в них хранятся ресурсы, содержащие представления сервисов на всех уровнях абстракции (например, модель сервиса Rational Service Architect, представляющая архитектуру SOA-решения).

Как создать UML-профиль

UML-профили предоставляют простой механизм расширения независимого от конкретной предметной области унифицированного языка моделирования Unified Modeling Language (UML). Они позволяют определить специфические для данной предметной области сущности и правила. Предметная область, на которой основывается профиль, может быть технологической или относящейся к бизнесу. Кроме того, UML-профили прекрасно комбинируются с процессами разработки. Например, существует UML-профиль для бизнес-моделирования, поддерживающий унифицированный процесс Rational (Rational Unified Process, RUP) для бизнес-моделирования. Профили предлагают простой метод метамоделирования, в рамках которого можно изменять метаклассы из существующих метамоделей при помощи стереотипов (для определения специфических свойств и ограничений для метаклассов) и тэгированные значения (для определения ограничений для метаатрибутов).

Лучше всего ассоциировать графические представления со стереотипами. Например, в профиле "UML profile for Software Services" стереотип serviceSpecification описывает метакласс Interface. Он определяет свойство published, которое определяет факт публикации сервиса в реестре сервисов. И наконец, одно из ограничений заключается в том, что все операции должны быть помечены как публичные. При помощи этого профиля можно адаптировать для решения своих задач язык, используемый для проектирования, документирования и разработки SOA-решения.

Совет:
на практике можно воспользоваться программой IBM WebSphere Business Modeler для работы с бизнес-специалистами и фиксации аспектов бизнес-процессов. Модели из WebSphere Business Modeler можно открыть в Rational Software Architect. В Rational Software Architect можно использовать их на входе преобразований, которые используются при создании детализированных технических проектов.

Как уже объяснялось ранее, основной идеей управляемой моделями разработки является возможность работы на нескольких уровнях абстракции. Например, вы можете обнаружить, что UML-профиль для программирования сервисов включает слишком много технических деталей, чтобы использовать его в беседе с бизнес-партнерами по SOA-проекту. По сути, есть смысл создать новый профиль, который абстрагируется от деталей, документированных в профиле Software Services. После того как вы придете к соглашению по поводу деталей, документированных в более высокоуровневой модели, можно воспользоваться преобразованием для автоматизированного создания модели на более низком уровне, использующем профиль Software Services.

Передовой метод для нового профиля или метамодели
Важно отметить что профили - не самый лучший механизм расширения метамодели. Например, профиль не может исключить или определить новые метаклассы или отношения в метамодели (например, в метамодели UML); он также не может устранить ограничения, налагаемые метамоделью, которую он изменяет. Наилучшими механизмами расширения являются MetaObject Facility (MOF) и Eclipse Modeling Framework (EMF), разработанные группой Object Management Group (OMG). Дополнительную информацию о MOF и EMF можно найти на Web-сайте OMG (см. ссылку в разделе Ресурсы).

Об использовании профилей

В соответствии со спецификацией UML 2.0 профили имеют следующие особенности использования:

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

Создаем профиль в Rational Software Architect

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

Совет:
стоит отметить важный момент: в этой части нашего учебного руководства используется Rational Software Architect версии 7. Ссылку, по которой можно загрузить ознакомительную версию этой программы, можно найти в разделе Ресурсы.

Примечание:
При создании профилей мы работаем только с представлениями Project Explorer и Properties..

1. Убедитесь, что у вас открыта перспектива Modeling;
2. Выберите из меню команды File > New > Project, а затем введите profile в поле Filter мастера New Project ;
3. Выберите UML Profile Project и нажмите кнопку Next (рисунок 2);

Рисунок 2. Проект нового UML-профиля

4. Дайте проекту имя SimpleServiceProfile;
5. Два раза нажмите кнопку Next, а затем введите SimpleServiceProfile в полях Profile Name и File Name (рисунок 3);
6. Нажмите Finish.

Рисунок 3. Ввод имени UML-профиля и имени файла

Определяем стереотипы профиля

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

1. Выберите из меню команды SimpleServiceProfile > Profiles;
2. В представлении Project выделите SimpleServiceProfile;
3. Нажмите на нем правой кнопкой мыши и выберите команды Add UML > Stereotype (рисунок 4);
4. Присвойте стереотипу имя SimpleServiceSpec;

Рисунок 4. Создание нового стереотипа

Затем определите тип (метакласс), который будет расширять только что созданный стереотип SimpleServiceSpec.

5. Убедитесь, что в обозревателе проектов Project Explorer выделен стереотип SimpleServiceSpec;
6. Перейдите на вкладку Extensions в представлении Properties, а затем нажмите кнопку Add Extension;
7. В поле Metaclass открывшегося окна Create metaclass extension введите Interface;
8. Убедитесь, что элемент Interface выбран, после чего нажмите кнопку OK.

Таким образом мы декларируем, что наш стереотип SimpleServiceSpec расширяет UML-элемент Interface. После того как элемент Interface будет создан и развернут, пользователи профиля смогут создать особый экземпляр элемента Interface, обозначенный как SimpleServiceSpec. Результат показан на рисунке 5 рисунке 5.

Рисунок 5. Расширение метакласса для стереотипа SimpleServiceSpec

Выбираем изображения для пиктограмм

Теперь необходимо определить графическое представление нашего стереотипа. Можно выбрать два изображения: одно для пиктограммы в панели Project Explorer и одно для картинки на диаграмме. В этом упражнении мы определим только изображение для пиктограммы.

1. Убедитесь, что стереотип SimpleServiceSpec выделен в обозревателе проектов в Project Explorer, а затем перейдите на вкладку General в представлении Properties;
2. Чтобы выбрать пиктограмму, нажмите кнопку Browse , а затем выберите файл с расширением GIF или BMP . Если хотите, можете использовать для пиктограммы имеющийся файл GIF размером 16x16 пикселей (это рекомендуемый размер);
3. В поле пиктограммы теперь указано Defined;

Добавляем атрибут

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

1. В обозревателе проектов Project Explorer выделите стереотип SimpleServiceSpec;
2. Нажмите на нем правой кнопкой мыши и выберите команды Add UML > Attribute;
3. Дайте атрибуту имя source (как на рисунке 6);

Рисунок 6. Создание нового атрибута стереотипа

4. На вкладке General в представлении Properties нажмите кнопку Select Type и задайте для атрибута тип String. Этот атрибут, или свойство, дает возможность пользователю профиля использовать данный стереотип для указания дополнительной информации о выделенном элементе. В данном случае пользователь может ввести строку символов, определяющую, где искать спецификацию.

На этом мы закончим определение нашего (очень) простого профиля в упражнении. Результат показан на рисунке 7.

Рисунок 7. Простой профиль Service

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

Тестирование и выпуск профиля

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

1. Сохраните профиль (CTRL + Shift + s);

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

2. Выделите SimpleServiceProfile в обозревателе проектов Project Explorer, нажмите на нем правой кнопкой мыши и выберите команду Compress;
3. Нажмите Yes.

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

1. Выделите SimpleServiceProfile в обозревателе проектов Project Explorer, нажмите на нем правой кнопкой мыши и выберите команду Release;
2. Укажите в ярлыке выпуска test release. Результат можно увидеть в файле profile.epx (рисунок 8).

Рисунок 8. Версии профиля

Совет:
Выпустив профиль, уведомите пользователей о том, что в него нельзя вносить изменения, которые могут негативно отразиться на его свойствах. Rational Software Architect принудительно применяет это ограничение, не позволяя удалять какие-либо элементы из выпущенного профиля. После выпуска профиля в него можно добавлять элементы, но изменять его каким-либо другим способом нельзя.

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

1. Создайте новый UML-проект и модель с диаграммой классов по умолчанию. Именно к этой модели мы применим наш профиль;
2. Убедитесь, что новая модель выбрана в обозревателе проектов Project Explorer, а затем перейдите на вкладку Profiles в представлении Properties и нажмите кнопку Add Profile;
3. В диалоговом окне Select Profile выберите Profile in workspace, а затем выберите файл SimpleServiceProfile.epx (рисунок 9);
4. Нажмите кнопку OK;

Рисунок 9. Выбор профиля в рабочей области

Создайте новый UML-интерфейс на диаграмме классов (из палитры), и дайте ему имя IClaimRecorder.

5. Убедитесь, что элемент IClaimRecorder выделен, а затем перейдите на вкладку Stereotypes в представлении Properties и нажмите кнопку Apply Stereotypes;
6. Теперь у нас есть стереотип SimpleServiceSpec, который мы только что сделали доступным (рисунок 10). Выделите его и нажмите кнопку OK.

Рисунок 10. Применение нового стереотипа

Обратите внимание на то, что для IClaimRecorder теперь доступны новый значок и свойство источника (рисунок 11).

Рисунок 11. Стереотип SimpleServiceSpec применен к элементу IClaimRecorder

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

Как создать и применить пользовательский шаблон

В контексте Rational Software Architect шаблонами могут называться различные виды шаблонов, используемые для различных целей:

• Шаблоны страниц: Используются для создания новых Web-страниц HTML или JSP;
• UML-шаблоны: Используются для создания элементов модели с одинаковыми свойствами. UML-шаблоны определяют набор параметров шаблона, которые могут быть привязаны к другим элементам моделей;
• Шаблоны кода: Могут использоваться для автоматической вставки повторяющихся фрагментов кода, например методов get и set, комментариев для новых методов в Java-коде или комментариев в XML-документах;
• Шаблоны Java™ Emitter (JET): Эти шаблоны используют синтаксис Java Server Pages (JSP) для представления генерируемого кода (например, Java, XML, SQL). Об этом мы поговорим более подробно в Части 2 данной серии;
• Шаблоны моделей: Предоставляют базовую структуру для моделей.

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

В статье "Design SOA services with Rational Software Architect, Part 2" (Проектирование SOA-сервисов при помощи Rational Software Architect, Часть 2) (см. в разделе Ресурсы) мы говорили о шаблонах моделей при изучении профиля UML 2 Profile for Software Services (профиль для сервисов). Подключаемый модуль для Rational Software Architect для этого профиля на самом деле содержит шаблон модели, который можно использовать для создания новой модели проекта сервиса. При создании новой модели мастер New UML Model предлагает список шаблонов моделей, которые могут быть использованы для создания этой модели, включая и пустой шаблон. В список доступных моделей входит и шаблон проекта сервиса Service Design Model (см. рисунок 12).

Рисунок 12. Мастер New UML Model

Если выбрать шаблон модели Service Design, то созданный проект уже будет содержать пакеты, элементы модели, элементы модели многократного использования и диаграммы, которые помогут в создании проектов сервисов, как показано на рисунке 13 .

Рисунок 13. Шаблон модели Service Design

Создаем модель, которая будет использоваться в качестве шаблона

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

Средства расширения функциональных возможностей Rational Software Architect, кроме того, позволяют зарегистрировать модель как шаблон. В этом разделе мы создадим простой шаблон модели Service Design, построенный на структуре модели, которую мы использовали в серии "Design SOA Services with Rational Software Architect" (Проектирование SOA-сервисов при помощи Rational Software Architect) (см. ссылку в разделе Ресурсы). Сначала необходимо создать новую модель, а затем убедиться в том, что эту модель можно использовать в качестве шаблона.

Создаем UML-модель

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

Рисунок 14. Структура проекта

1. В перспективе Modeling выберите из меню команды File > New > Project;
2. В окне мастера New Project введите uml в поле Filter;
3. Выберите UML Project и нажмите кнопку Next (рисунок 15);

Рисунок 15. Мастер New Project

4. Дайте проекту имя Service Design Model и нажмите кнопку Next (рисунок 16);

Рисунок 16. Новый проект UML-моделирования

5. Убедитесь, что в поле Templates выбран шаблон Blank Model;
6. Введите в поле File name имя Service Design Model и убедитесь, что в новой модели будет создана диаграмма классов, как показано на рисунке 17;
7. Нажмите Finish.

Рисунок 17. Мастер New UML Model

Совет:
при нажатии на значок ? в левом нижнем углу мастера становится доступной контекстная справка (см. рисунок 18).

Рисунок 18. Опция контекстной справки

Настройка конфигурации UML-модели

Теперь необходимо настроить UML-модель на использование профиля Services.

1. Убедитесь, что в обозревателе моделей Model Explorer выделена модель Service Design Model (рисунок 19);

Рисунок 19. Первоначальное отображение UML-модели в Project Explorer

2. В представлении Properties (рисунок 20) перейдите на вкладку Profiles. На этой вкладке перечислены профили, которые применяются к UML-модели по умолчанию. Теперь вы можете добавить в список профиль Software Services;

Рисунок 20. Применяемые к модели профили

3. Нажмите кнопку Add Profiles, а затем выделите профиль Software Services в списке Deployed Profile;
4. Нажмите кнопку OK.

Создаем структуру пакета

Теперь нам нужно создать структуру UML-модели, а именно три пакета:

• Messages (Сообщения);
• Service Specifications (Спецификации сервисов);
• Services (Сервисы).

Затем мы свяжем эти пакеты, чтобы показать зависимости.

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

1. В меню Window выберите команду Preferences;
2. Введите в поле Filter значение default, а затем выделите пункт Default Diagrams (в секции Modeling);
3. Измените Default diagram type на Class Diagram;
4. Нажмите кнопку Apply, а затем кнопку OK;
5. Выделите диаграмму классов Main и переименуйте ее в Main - Service Design Model, для этого нажмите клавишу F2 (если будет выведен запрос о сохранении модели, сохраните ее);
6. Выделите модель Service Design Model;
7. Нажмите на ней правой кнопкой мыши и выберите команды Add UML > Package, как показано на рисунке 21;

Рисунок 21. Создание нового пакета

8. Дайте пакету имя Messages;
9. Переименуйте диаграмму классов Main в Main - Messages;
10. Таким же образом создайте два пакета, Service Specifications и Services, а затем переименуйте их диаграммы классов Main, соответственно, в Main - Service Specifications и Main - Services. На рисунке 22 показана готовая модель;

Рисунок 22. Созданные нами пакеты

Создание отношений пакетов

Теперь нужно создать отношения между этими пакетами.

11. Откройте диаграмму классов Main - Service Design Model, если она не была открыта ранее;
12. Перетащите при помощи мыши эти три пакета из обозревателя моделей Model Explorer в область диаграммы;
13. Чтобы добавить отношение "использует" между пакетом Service Specifications и пакетом Service Message, поместите указатель мыши на пакет Service Specifications, нажмите исходящую стрелку и, удерживая кнопку мыши нажатой, переместите указатель мыши на пакет Service Messages, после чего отпустите кнопку мыши;
14. Затем выберите команду Create Usage (рисунок 23);

Рисунок 23. Создание отношения "использует"

15. Таким же образом создайте отношение "использует" между пакетами Service и Service Specification. Готовая диаграмма показана на рисунке 24;

Рисунок 24. Отношения пакетов

На рисунке 25 показан окончательный вид пакета в Project Explorer. Обратите внимание на отношения "использует" в иерархии пакетов Services и Service Specifications.

Рисунок 25. Структура нового пакета

16. Сохраните все изменения (Ctrl + Shift + s).

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

Совет:
Используя шаблоны модели, поставляемые вместе с Rational Software Architect, обратите внимание на то, что все шаблоны имеют пакет компоновочных блоков многократного использования (Reusable Building Blocks). Этот набор элементов включается в шаблоны потому, что существует ряд элементов, которые часто используются совместно в повторяющихся структурах. Вместо документирования повторяющихся структур для более быстрого использования в модели их можно скопировать и вставить из папки Reusable Building Blocks, а также сохранить модель вместе со структурой в соответствии с передовыми методами. При создании пользовательского шаблона имейте в виду это соображение и структурируйте ваш шаблон таким образом, чтобы он предоставлял подобные функции.

В следующем разделе мы экспортируем только что созданную модель как шаблон модели.

Предоставление модели в качестве шаблона

В Rational Software Architect версии 7 можно создать новый проект или модель на основе уже существующего (не только из зарегистрированного шаблона). Rational Software Architect позволяет выбрать проект или модель (рисунок 26), после чего создается новая модель или новый проект, являющийся репликацией (копией) выбранного проекта. Новый проект содержит элементы модели и диаграммы из исходной модели.

Рисунок 26. Новая UML-модель, созданная на основе уже существующей

Регистрируем модели в качестве шаблонов (по желанию) Существует возможность зарегистрировать модели в качестве шаблонов, чтобы сделать их доступными наряду с шаблонами, входящими в комплект поставки. Для этого следует воспользоваться функцией расширения функциональных возможностей Rational Software Architect и точкой расширения com.ibm.xtools.modeler.ui.wizards.templates. Например, подключаемый модуль com.ibm.xtools.modeler.ui.templates демонстрирует использование точки расширения. В этом учебном руководстве мы не будем останавливаться на этом моменте.

1. Выберите из меню команды File > New > UML Model;
2. На первой странице мастера New Model выделите пункт Existing model, а затем нажмите кнопку Next;
3. На второй странице (рисунок 27), нажмите кнопку Browse, а затем выберите файл Service Design Model.emx;
4. Введите имя модели в поле File name, а затем нажмите кнопку Finish.

Рисунок 27. Спецификация новой UML-модели

Rational Software Architect создает новую модель, используя в качестве шаблона модель Service Design.

Краткое заключение

В этом учебном руководстве мы рассмотрели несколько различных способов документирования и автоматизации использования передовых методов, разработанных в организации и отрасли, в Rational Software Architect. В частности, мы рассмотрели создание пользовательских профилей и шаблонов моделей. Профили позволяют дополнить язык UML, чтобы его можно было использовать для проектирования SOA. Адаптировав язык к своим потребностям, можно использовать шаблоны моделей для того, чтобы помочь пользователям профилей создавать хорошо определенные модели и решения. В следующих выпусках серии мы расскажем об автоматизации использования передовых методов в рамках модели или нескольких моделей.

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

• Обратиться в "Интерфейс" за дополнительной информацией/по вопросу приобретения продуктов
• Подробнее о продуктах IBM Rational Software
• Приобрести продукты компании IBM Rational в электронном магазине ITShop.ru
• Подписаться на рассылку " CASE-технологии"