Использование принципов управляемой моделями разработки и проектирования на базе шаблонов при проектировании SOA: Часть 2. Проектирование с применением шаблонов

Введение

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

Однако нас интересовал следующий вопрос, на который мы не ответили: "Как можно использовать тот же тип поддержки и автоматизации, но в сочетании со своими передовыми методами?" В части 1 данной серии мы рассмотрели два вида артефактов, поддерживаемых Rational Software Architect, а именно: UML-профили и шаблоны моделей. Мы узнали, что представляют собой эти артефакты и как можно создать их пользовательскую реализацию. Теперь вы должны научиться создавать пользовательские профили и шаблоны моделей.

В данном учебном руководстве мы продемонстрируем, как IBM Rational Software Architect может обеспечить поддержку принципов проектирования с применением шаблонов (patterns-based engineering, PBE) для разработки программного обеспечения. В технологии PBE мы используем различные типы артефактов, в том числе:

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

• Подключаемые модули: Платформа Eclipse по существу является механизмом для использования подключаемых модулей. Любые функции, добавляемые в эту платформу, существуют в виде подключаемых модулей. Программный пакет Rational Software Architect представляет собой (обширный) набор подключаемых модулей, которые предоставляют функции, специфичные для моделирования, SOA-разработки и т. п. Шаблоны, преобразования и другие ресурсы предоставляются в общий доступ посредством создания из них подключаемых модулей;

• Плаглеты: Плаглеты - это облегченные подключаемые модули. Они просты в использовании и не требуют долгой настройки, что дает возможность пользователю Rational Software Architect взаимодействовать с API базовой платформы для доступа к информации о модели, элементам модели и проектам в рабочей области этого пользователя. Плаглеты можно использовать для ряда задач использования и создания сценариев внутри среды или как способ изучения и тестирования взаимодействий с базовой платформой;

• RAS-ресурсы: Спецификация Reusable Asset Specification (RAS) представляет собой стандарт, разработанный группой Object Management Group (OMG) и описывающий правила компоновки, размещения и потребления ресурсов многократного использования. В Rational Software Architect предусмотрена поддержка этого стандарта, позволяющая упростить способ работы пользователей с ресурсами многократного использования. RAS-ресурсы будут рассмотрены в одном из следующих выпусков данной серии.

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

Терминология проектирования с применением шаблонов

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

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

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

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

С учетом всего этого необходимо провести различие между спецификацией и реализацией шаблона .

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

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

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

Реализация шаблона - это артефакт, который автоматизирует применение шаблона в конкретной среде. Такой артефакт допускает многократное использование; к нему легко организовать общий доступ. Шаблоны превращаются в конкретные артефакты в среде разработки. В Rational Software Architect сторонами реализации шаблонов являются:

• UML-шаблоны;
• Преобразования;
• Подключаемые модули;
• Мастера.

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

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

Преимущества реализаций шаблона

Использование принципов проектирования с применением шаблонов при разработке обеспечивает следующие преимущества.

Повышенная производительность

Сколько раз в процессе работы над проектом вы думали: "Я уже решил эту проблему. Почему мне приходится снова и снова повторять это решение?" Самая трудная, интересная и творческая часть работ уходит на решение исходной проблемы. После того как проблема решена, нам нужно использовать найденное решение и применять его многократно - быстро и последовательно. Кроме того, нам нужно сделать наше решение доступным другим специалистам, чтобы они тоже могли получить выигрыш от его использования. С течением времени мы поняли, что автоматизированные процедуры могут воссоздавать экземпляры решений значительно быстрее, чем люди. В этом, вероятно, нет ничего необычного, потому что мы всегда предполагаем, что автоматизированная процедура выполняется быстрее, чем те же действия, выполняемые вручную. Следовательно, мы можем повысить производительность просто за счет автоматизации применения нашего решения.

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

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

Совершенствование архитектурной основы

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

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

Реализации шаблонов помогают также обеспечить трассируемость, или возможность обратной трассировки всего написанного кода к требованиям. При использовании Rational Software Architect мы можем использовать и его интеграцию с IBM® Rational® RequisitePro® и IBM® WebSphere® Business Modeler для создания соединений между такими элементами моделей, как прецеденты, и требованиями, указанными бизнес-владельцами. Затем, в процессе работы на разных уровнях абстракции, охватывающих и модели, и код, мы можем добавить дополнительные ассоциации, показывающие отношения между элементами в проекте и требованиями. Реализации шаблонов могут использоваться для автоматизации создания трассировочных ссылок по мере создания элементов решения. Благодаря поддержке трассируемости мы можем ответить на следующие вопросы: "В чем заключается результат изменений?" и "Почему данное решение настроено именно так?"

Улучшенное качество

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

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

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

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

• Решение применяется повторно несколько раз;
• Необходимо использовать решение на основе передовых методов;
• Проект должен быть выполнен в сжатые сроки;
• Основное требование к проекту - качество;
• Нехватка квалифицированных специалистов.

Поддержка инструментов и артефактов

Виды элементов, обеспечивающих совершенствование

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

• Элементы, обеспечивающие автоматизацию: В эту группу входят такие элементы, как UML-шаблоны, преобразования, мастера Rational Software Architect и подключаемые модули Eclipse. Это основные элементы, из которых состоит реализация шаблона;

• Элементы, поддерживающие применение автоматизированных процедур: В эту группу входят такие элементы, как профили, шаблоны моделей и плаглеты;

• Элементы, объясняющие процессы и предоставляющие рекомендации: Эта группа состоит из таких элементов, как подключаемые модули IBM® Rational® Method Composer, а также Справка (Help), инструкции для пользователей и другие формы документации.

Рисунок 1. Типы элементов

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

• Создать документацию в формате Справки Windows при помощи встроенной справочной системы в Rational Software Architect;
• Создать регулируемый подключаемый модуль Rational Method Composer, который организации и коллективы смогут использовать для создания собственного процесса разработки, включающего описания процедур использования ресурсов.

Способы использования комбинации элементов

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

Рисунок 2. Комбинирование элементов

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

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

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

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

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

• Люди добиваются наибольшего успеха в создании реализаций шаблонов, если они придерживаются направления снизу вверх или от краев к центру. Направление снизу вверх чаще всего более сложное и связано с риском. Здесь стоит вспомнить, что шаблон строится на проверенном, известном решении. Если у вас нет решения, из которого создается шаблон, то можно ли назвать шаблоном то, что вы создаете?
• При создании пользовательских представлений, документирующих входную информацию в спецификации шаблона, постарайтесь свести к минимуму объем предоставляемой пользователем информации. Этого можно добиться двумя способами:
  • Ограничьте количество элементов и диаграмм, которые необходимы для работы с вашей автоматизированной процедурой. Пользователи могут использовать множество диаграмм и элементов в различных сочетаниях, но это не означает, что необходимо использовать все эти элементы. Старайтесь, чтобы они оставались простыми;
  • Как и при определении схемы базы данных, необходимо нормализовать информацию, которая передается в реализацию шаблона. Пусть пользователи указывают только простые значения, являющиеся уникальными для данного применения шаблона. Если какое-либо из значений может быть вычислено на основе других значений, не требуйте от пользователя предоставления этой информации. Кроме того, если информация не является уникальной для конкретного применения шаблона, встройте такую информацию непосредственно в шаблон.

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

UML-шаблоны

UML-шаблон применяется в самой модели, благодаря чему можно использовать передовые методы для создания элементов в модели и определения деталей. Как уже говорилось в предыдущем разделе, UML-шаблоны часто используются в сочетании с UML-профилем для добавления разметки к элементам модели. С их помощью можно также добавлять в модель элементы или изменять различные аспекты существующих элементов. Главное, что следует иметь в виду - это то, что UML-шаблон работает в модели, а преобразование выполняется между моделями. По умолчанию в Rational Software Architect включено несколько UML-шаблонов, созданных на базе шаблонов проектирования Gang of Four (GoF). Работать с этими шаблонами и любыми другими шаблонами, которые вы установите, можно из панели обозревателя шаблона Pattern Explorer (рисунок 3).

Рисунок 3. Pattern Explorer

Примечание:
Библиотека шаблонов My Struts Patterns не входит в состав стандартной установки Rational Software Architect. В данном случае мы создали пользовательские шаблоны ( шаблоны для моделирования решений на базе Struts). Создавая новые шаблоны, собирайте их в библиотеки, которые упрощают поиск и использование.

Создаем пользовательский UML-шаблон

В этом разделе мы создадим простой пользовательский UML-шаблон в предметной области SOA. В курсе DEV498 "Pattern Implementation Workshop with IBM Rational Software Architect" (Семинар по реализации шаблонов при помощи Rational Software Architect) даны более подробные рекомендации по этому процессу (см. раздел Ресурсы).

Спецификация шаблона

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

По завершении анализа экземпляра мы определим роли, участвующие в шаблоне, их атрибуты, производные атрибуты и модель ввода и приступим к созданию спецификации и реализации шаблона. В данном учебном руководстве UML-шаблон реализует шаблон "Service Provider" . В таблице 1 представлена спецификация этого шаблона.

Таблица 1. Спецификация шаблона "Service Provider"

Имя шаблона	Service Provider
Контекст	Поставщики сервисов используются для объединения связанных сервисов. Затем эти объединенные сервисы предлагаются поставщиком, который их объединяет. Поставщики сервисов моделируются при помощи UML-компонентов, а типы сервисов, которые они предоставляют, моделируются при помощи спецификаций сервисов (интерфейсов). Чтобы создать модель поставщика сервисов, проектировщикам сначала необходимо создать UML-компонент, стереотипизированный как <<serviceProvider>>. Затем нужно создать по одному UML-порту для каждого из предоставляемых сервисов и типизировать эти порты при помощи стереотипа <<serviceSpecification>>. В завершение необходимо стереотипизировать каждый порт при помощи стереотипа <<service>>.
Проблема	Последовательность действий, которые должны выполнить проектировщики, чтобы создать модель поставщика сервисов, не является интуитивно понятной. Она требует от проектировщиков знаний об UML-компонентах и UML-портах.
Направленность усилий	При моделировании SOA-решений проектировщики должны концентрироваться только на предметной области SOA. Например, они должны создать поставщики сервиса и сервисы и не волноваться по поводу UML-компонентов и портов. При создании поставщика сервисов все проектировщики должны думать только о том, какие сервисы необходимо сгруппировать.
Решение	Создать абстрагированное представление поставщика сервисов, которое будет интуитивно понятно проектировщикам, работающим над моделированием сервисов. Обязать проектировщиков указывать только имя поставщика сервисов и набор интерфейсов, для которых он должен предлагать сервисы. Исходя из этой информации, создать подходящие элементы UML-модели и применить соответствующие стереотипы к модели поставщика сервисов в UML. Абстракция, предоставляемая данным шаблоном, показана на следующем снимке экрана: Это решение не требует от проектировщика знаний о создании UML-компонентов или портов (справа)
Логическое обоснование решения	Проектировщикам SOA не нужно заниматься созданием и изменением UML- элементов, достаточно всего лишь указать информацию о поставщике сервисов. Создание и добавление элементов UML-модели автоматизировано. Окончательная модель сервиса создается с использованием передовых методов и хорошо подготовлена для подачи на вход преобразований, что ускоряет проектировочные работы.

В Rational Software Architect UML-шаблон представляет собой подключаемый модуль на базе Eclipse, который использует несколько специализированных API, в том числе API для шаблонов, UML 2 API, EMF API, и т. д. Чтобы приступить к созданию шаблона, выполните следующие шаги:

1. Выберите из меню команды File > New > Project;
2. В открывшемся окне мастера замените текст Type filter text на Plug-in, а затем выделите узел Plug-in Project (рисунок 4);
3. Затем нажмите кнопку Next;

Рисунок 4. Plug-in Project

4. На следующей странице мастера, Plug-in Project, введите имя проекта com.ibm.myPatternLibrary;
5. Не изменяя значений по умолчанию, нажмите кнопку Next;
6. Согласитесь со значениями по умолчанию на странице мастера Plug-in Content и снова нажмите кнопку Next;
7. На следующей странице мастера Templates убедитесь, что установлен флажок Create a plug-in using one of the templates;
8. Выберите шаблон Plug-in with Patterns из списка Available Templates и нажмите кнопку Finish (рисунок 5);

Рисунок 5. Шаблон Plug-in with Patterns

С этого момента Rational Software Architect начинает заполнять новый проект подключаемого модуля, который пока содержит пустой шаблон библиотеки шаблонов Pattern Library. Если вы находитесь не в перспективе Plug-in Development Environment, Rational Software Architect предложит переключиться в эту перспективу. Кроме того, в перспективу будет добавлено представление Pattern Authoring, показанное на рисунке 6.

Рисунок 6. Представление Pattern Authoring

9. Ненадолго остановимся на том, что мы видим в представлении Package Explorer (рисунок 7);
   • Класс Activator является глобальным для проектов подключаемых модулей и используется средами на базе Eclipse для взаимодействия с подключаемыми модулями;
   • Класс PatternLibrary.java является уникальным для UML -шаблонов. В данном случае, как можно понять по его имени, он используется для представления библиотек шаблонов. Как уже говорилось ранее, в соответствии со своим определением библиотека шаблонов может содержать один или более связанных шаблонов.

Рисунок 7. Представление Package Explorer

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

10. В представлении Pattern Authoring выделите узел com.ibm.mypatternlibrary;
11. Нажмите на нем правой кнопкой мыши и выберите команду New Pattern;
12. На первой странице мастера New Pattern введите имя поставщика сервисов для этого шаблона;

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

13. Чтобы добавить параметр, нажмите кнопку Add рядом с полем Parameters (рисунок 8);

Рисунок 8. Добавление параметра в шаблон

14. Для этого параметра укажите имя поставщика сервисов Service Provider Name;
15. Для Type нажмите кнопку Browse и выберите Literal String;
16. Нажмите OK, чтобы подтвердить выбор типа (рисунок 9);

Рисунок 9. Определение параметра

При помощи описанных выше шагов мы определили, что наш шаблон будет иметь параметр с именем Service Provider Name, типом Literal String и кратностью 1 (один).

17. Нажмите OK, чтобы завершить определение параметра;
18. Нам нужно добавить еще один параметр, поэтому еще раз нажмите кнопку Add;
19. В поле Name введите Service Specifications;
20. В поле Type выберите Interface;
21. Установите для Multiplicity значение 1..* (см. рисунок 10);

Рисунок 10. Добавление еще одного параметра

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

22. Перейдите на вкладку Parameter Dependency;
23. В секции Existing Parameters выделите параметр Service Provider Name, а затем нажмите кнопку > (стрелка вправо) рядом с секцией Supplier Parameters (рисунок 11);

Рисунок 11. Вкладка Pattern Dependency

24. Чтобы завершить работу с параметром, нажмите кнопку OK;

Совет:
Как вы могли заметить ранее в представлении Pattern Explorer, библиотека Design Pattern имеет несколько вложенных папок для дополнительной классификации шаблонов. Эти подкатегории в библиотеке называются группами. По умолчанию новый шаблон добавляется в группу Miscellaneous Patterns. При помощи кнопок Add и Remove рядом с полем Groups удалите группу по умолчанию и добавьте пользовательскую группу.

25. Просмотрите детали, ассоциированные с шаблоном, а затем нажмите кнопку OK.

Рисунок 12. Пользовательская настройка групп шаблонов

Rational Software Architect добавляет в проект классы. После этого в представлении Pattern Authoring (рисунок 13) мы увидим, что библиотека содержит шаблон.

Рисунок 13. Библиотека шаблонов в представлении Pattern Authoring

Определив базовую структуру шаблона, можно приступить к определению поведения, ассоциируемого с данным шаблоном. В представлении Package Explorer мы увидим, что в проект был добавлен новый класс ServiceProvider. Как и предполагалось, данный класс используется для представления нашего шаблона. Давайте рассмотрим этот класс в деталях (рисунок 14).

Рисунок 14. Класс ServiceProvider

Обратите внимание на то, что в классе шаблона ServiceProvider имеются внутренние классы, созданные для каждого параметра: ServiceProviderName и ServiceSpecifications. Для каждого из этих внутренних классов имеется по два метода, представляющих общий интерес.

• Первый метод, expand(PatternParameterValue value), вызывается при выполнении пользователем шаблона подключения (привязки) одного из элементов модели к данному параметру;

• Второй метод, expand(PatternParameterValue.Removed value), вызывается при удалении пользователем подключения или изменении привязки параметра.

Вспомните: мы определили, что между этими двумя параметрами существует отношение зависимости. Для поддержки этой зависимости в класс ServiceSpecification был добавлен внутренний класс ServiceSpecifications_ServiceProviderNameDependency . Один из методов данного класса представляет особый интерес: update(PatternParameterValue, PatternParameterValue). Этот метод вызывается в том случае, если уже существует привязка какого-либо элемента к параметру Service Provider Name, а вы выполняете привязку какого-либо элемента к параметру ServiceSpecifications. Методы update и expand являются основными методами данного шаблона. Именно в этих областях мы напишем код, который будет определять поведение шаблона. В данном случае необходимо определить поведение только для тех ситуаций, в которых выполняется условие зависимости, поэтому давайте сосредоточимся на методе update. При написании кода для шаблона можно пользоваться интерфейсами прикладного программирования (API):

• UML 2 API: По материалам Web-сайта Eclipse.org: "Один из проектов Eclipse Tools, UML2, представляет собой реализацию метамодели UML 2 на базе EMF для платформы Eclipse. Задачами данного проекта было предоставление удобной в применении реализации метамодели UML для поддержки разработки инструментов моделирования, общей XMI-схемы, которая способствовала бы взаимообмену семантических моделей, прецедентов как средств проверки корректности спецификации и правил проверки корректности в качестве определения и принудительного обеспечения уровней совместимости." Rational Software Architect версии 7 поддерживает окончательную версию спецификации UML 2.1 группы Object Management Group (OMG);

• API шаблонов: API IBM Rational Patterns Framework дополняет описанные ранее средства авторинга шаблонов и обеспечивает поддержку применения шаблонов к UML-моделям. Дополнительную информацию об этих API можно найти в справочной системе (рисунок 15).

Figure 15. Справочная система (Help)

Как уже говорилось ранее, для поставщика сервисов нам нужно создать UML-компонент и UML-порты, которыми он владеет, с учетом параметров, указанных пользователем (имя и набор интерфейсов). Чтобы это могло осуществиться, необходимо написать код для метода ServiceSpecifications::ServiceSpecifications_ServiceProviderNameDependency::update(PatternParameterValue, PatternParameterValue). Замените код для этого метода кодом из листинга 1.

Листинг 1

                    
public boolean update(PatternParameterValue value,
					PatternParameterValue dependencyValue) {

// Создаем компонент с именем, указанным в параметре service provider
//  name  (dependencyValue).
// Затем добавляем порт к уже существующему или только что созданному
// компоненту для каждого из интерфейсов (value).
// Если к модели до сих пор не применялся профиль, применяем
// его.
// И в завершение применяем стереотип serviceProvider к
// компоненту, а стереотип serviceSpecification к
// интерфейсу (если они до сих пор не были применены).

// Получаем значение первого параметра шаблона: типа
// StringExpression для имени поставщика сервиса
LiteralString stringExp = (LiteralString) dependencyValue.getValue();

// Получаем значение только что добавленного элемента во второй
// параметр шаблона:  service interface
Interface theInterface = (Interface) value.getValue();

// Получаем пакет для этого интерфейса и создаем компонент в
//этом же пакете
Package pck = theInterface.getPackage();

// Проверяем, применялся ли к модели профиль сервиса -
//если нет, то выполняем
Profile pf = pck.getModel().getAppliedProfile("Software Services Profile");

if (pf == null) {
// Do nothing
} else {
// получаем или создаем компонент, если это необходимо
	Component serviceProvider = 
	(Component) pck.getPackagedElement(stringExp.getName(), 
       false, UMLPackage.eINSTANCE.getComponent(), true);

	// Применяем стереотип поставщика сервисов к компоненту
	String serviceProviderStereotypeName =
	 "Software Services Profile::ServiceProvider";

	Stereotype serviceProviderStereotype = 
	serviceProvider.getAppliedStereotype(serviceProviderStereotypeName);
	if (serviceProviderStereotype == null) {
		serviceProviderStereotype = 
		serviceProvider.getApplicableStereotype(serviceProviderStereotypeName);
		serviceProvider.applyStereotype(serviceProviderStereotype);
		}

	// Применяем стереотип спецификации сервиса к
	// интерфейсу
	String serviceSpecificationStereotypeName = 
	"Software Services Profile::ServiceSpecification";
	Stereotype serviceSpecificationStereotype = 
	theInterface.getAppliedStereotype(serviceSpecificationStereotypeName);
	if (serviceSpecificationStereotype == null) {
		serviceSpecificationStereotype = 
		theInterface.getApplicableStereotype(serviceSpecificationStereotypeName);
	theInterface.applyStereotype(serviceSpecificationStereotype);
	}

// Создаем в компоненте порт, типизированный в соответствии с интерфейсом
	Port thePort = serviceProvider.createOwnedPort
	(theInterface.getName(), theInterface);

	// Применяем стереотип сервиса к порту
	thePort.applyStereotype
	(thePort.getApplicableStereotype("Software Services Profile::Service"));
	}
	return true;
}

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

Совет:
Чтобы сделать код более удобочитаемым, в редакторе нажмите на нем правой кнопкой мыши и выберите команды Source > Format. После добавления кода добавьте соответствующие инструкции для импорта. Для этого нажмите правой кнопкой мыши в панели редактора и выберите команды Source > Organize Imports (CTLR + Shift + O) Убедитесь в том, что инструкции для импорта из листинга 2 добавлены в код.

Листинг 2

                    
import org.eclipse.uml2.uml.Component;
import org.eclipse.uml2.uml.Interface;
import org.eclipse.uml2.uml.LiteralString;
import org.eclipse.uml2.uml.Package;
import org.eclipse.uml2.uml.Port;
import org.eclipse.uml2.uml.Profile;
import org.eclipse.uml2.uml.Stereotype;
import org.eclipse.uml2.uml.UMLPackage;

Совет:
Мастер Organize Import в автоматическом режиме может некорректно разрешить некоторые инструкции для импорта. Поэтому вам придется вручную просмотреть список инструкций для импорта, чтобы убедиться, что в него включены все инструкции из листинга 2.

27. Выберите из меню команды File > Save All.

Тестируем реализацию шаблона

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

1. Сначала откройте файл plugin.xml, дважды нажав на нем левой кнопкой мыши в представлении Package Explorer;
2. Затем перейдите на вкладку Overview в редакторе Manifest editor;
3. Затем откройте ссылку Launch an Eclipse application (рисунок 16);

Совет:
Чтобы использовать контрольные точки и перемещаться по коду, необходимо вместо этого открыть ссылку Launch an Eclipse Application in Debug mode.

Рисунок 16. Запуск приложения Eclipse в режиме отладки

После этого запустится второй экземпляр Rational Software Architect. В экземпляре рабочего цикла инструментальной среды исполнения создайте новый UML-проект, а затем добавьте новую UML-модель, которая будет использовать шаблон Blank Model:

4. Выберите из меню команды File > New > Project;.
5. В мастере New Project выделите UML Project и нажмите кнопку Next;
6. Введите в качестве имени проекта Service Provider Test и нажмите кнопку Next;
7. Убедитесь, что в списке Templates выделена модель Blank Model, а затем выделите Class Diagram в поле Default diagram type;
8. Нажмите Finish. Нажмите кнопку Yes в окне запроса с предложением перейти в перспективу Modeling;

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

9. Теперь нужно применить профиль Software Services к модели Blank Model:
   1. Убедитесь, что модель Blank Model выделена в представлении Project Explorer и перейдите на вкладку Profiles в представлении Properties;
   2. Нажмите кнопку Add Profile, выделите Software Services under Deployed Profiles и нажмите кнопку OK;
   3. Затем откройте представление Pattern Explorer ;
   4. Выберите из меню команды Window > Show View > Other;
   5. Введите условие pattern в поле Filter, выберите из списка Pattern Explorer и нажмите кнопку OK (рисунок 17).

Рисунок 17. Представление Pattern Explorer

10. В представлении Pattern Explorer разверните узел Miscellaneous Patterns. Вы должны увидеть созданный нами шаблон Service Provider (рисунок 18);

Рисунок 18. Шаблон Service Provider

11. Перетащите шаблон Service Provider при помощи мыши в область диаграммы Main (рисунок 19).

Рисунок 19. Перетаскивание шаблона в область диаграммы Main

В модели создается новый экземпляр шаблона Service Provider. Обратите внимание, что экземпляр шаблона представлен в виде кооперации с ключевым словом <<Pattern Instance>>.

Тестируем шаблон Service Provider

Теперь можно перейти к тестированию шаблона Service Provider.

1. Сначала, при помощи палитры на панели действий, создайте в модели пару интерфейсов:
   • AccountVerification;
   • AccountActivation.

Эти интерфейсы мы используем для привязки параметра шаблона Service Specifications.

2. Сначала необходимо задать имя поставщика сервиса (через привязку параметра Service Provider Name):
   1. Поместите указатель мыши на параметр Service Provider Name нашего экземпляра шаблона;
   2. После появления раскрывающейся панели действий нажмите и отпустите левую кнопку мыши на второй пиктограмме (см. рисунок 20);

Рисунок 20. Открываем вторую пиктограмму на панели действий

3. Введите SalesMgr, а затем нажмите клавишу Enter. Мы создали привязку для первого параметра (см. рисунок 21);

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

4. Затем перетащите интерфейс AccountVerification на параметр Service Specifications (рисунок 22);

Рисунок 22. Перетаскивание интерфейса AccountVerification на параметр Service Specifications

Именно в этом момент выполняется код, который мы написали для метода ServiceProvider::ServiceSpecifications::update(PatternParameterValue, PatternParameterValue). Этот код создает UML-компонент с именем SalesMgr и стереотип <<serviceProvider>>. В компоненте также должны быть созданы UML-порт AccountVerification, типизированный при помощи интерфейса AccountVerification и стереотипизированный при помощи стереотипа <<service>> . Кроме того, стереотип <<serviceSpecification>> должен быть применен и к интерфейсу AccountVerification (рисунок 23).

Рисунок 23. Результаты в представлении Project Explorer

5. Затем перетащите интерфейс AccountActivation на параметр Service Specifications. Просмотрите результаты привязки экземпляра шаблона в модели (рисунок 24);

Рисунок 24. Результаты привязки экземпляра шаблона в модели

6. Можно перетащить поставщик сервисов SalesMgr в область диаграммы, которая после этого будет выглядеть так, как показано на рисунке 25;

Рисунок 25. Диаграмма поставщика сервисов SalesMgr

Обратите внимание, например, на два UML-интерфейса (спецификации сервисов) в отделе интерфейсов, предоставляемых компонентом SalesMgr (поставщиком сервисов).

7. Теперь продемонстрируйте компонент в его внешнем представлении:
   1. Убедитесь, что компонент SalesMgr выделен на диаграмме, а затем нажмите на нем правой кнопкой мыши и выберите команды Filters > Show External View;
   2. Измените размеры компонента и портов таким образом, чтобы они выглядели примерно так, как на рисунке 26.

Рисунок 26. Внешнее представление компонента SalesMgr

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

На этом тестирование реализации шаблона закончено. Можно сохранить нашу модель и закрыть инструментальную среду исполнения. Закончив тестирование ресурса, можно создать спецификацию RAS (Reusable Asset Specification) для многократного использования данного ресурса. О создании пакета из ресурса мы поговорим в одном из следующих выпусков данной серии.

Когда и зачем следует использовать шаблоны

В нашем учебном руководстве мы объяснили терминологию проектирования с использованием шаблона, а затем остановились на одном из типов реализаций шаблонов, так называемых UML-шаблонах. Важно не забывать о том, что UML- шаблоны, которые мы создаем, не ограничены конкретным типом модели. Вы можете создавать и применять UML-шаблоны на протяжении всего периода моделирования, потому что их можно использовать на всех уровнях абстракции. Выполнив поиск по книгам вашего любимого книжного интернет-магазина или по ресурсам технических Web-сайтов, вы можете найти различные типы шаблонов. Для SOA-решений можно применять UML-шаблоны при необходимости выполнения любой из следующих задач:

• Моделирование проектируемых сервисов;
• Создание первоначального проекта сервиса;
• Уточнение проекта сервиса;
• Применение передовых методов;
• Применение повторяющихся решений;
• Компенсация нехватки специалистов.

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

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

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