Быстрое создание мощных специализированных инструментальных средств при помощи Rational Software Architect версии 7.0

Узнайте о возможности использования IBM Rational Software Architect версии 7.0 при построении собственных специализированных инструментальных сред для решения первоочередных проблем проектов программного обеспечения. В данной статье приведено описание новой функции Transformation Authoring, которая позволяет создавать инструментальные средства разработки с графическим интерфейсом и основанными на стандартах шаблонами.

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

IBM Rational Software Architect 7.0 содержит новую функцию Transformation Authoring, которая позволяет создать специализированные инструментальные средства без каких-либо знаний в области сред Eclipse или необходимости пользовательского кодирования. В ней применяется графический инструментарий и шаблоны, которые используют простой синтаксис XPath. В этой статье разъяснены бизнес-операции для данной технологии, описан принцип работы функции Transformation Authoring, и приведен пошаговый пример, создающий простое инструментальное средство доступа к базе данных.

Бизнес-преимущества Transformation Authoring

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

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

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

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

Легкость освоения и использования. Для построения специализированного инструментального средства можно использовать программное обеспечение Rational Software Architect. Transformation Authoring основана на проекте Eclipse с открытым исходным кодом, который называется JET, является зрелым программным продуктом (JET был начат в 2002 г.) и использует открытые стандарты, например, XPath. Особенно важно то, что оно элементарно в использовании, так как предлагает графический интерфейс пользователя, чтобы как можно больше облегчить жизнь человеку, создающему инструментальное средство.

Два компромисса

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

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

Основные понятия

Данная технология считается наращиваемой, и, в общем говоря, позволяет расширять возможности стандартных инструментальных средств, входящих в состав программного обеспечения Rational Software Architect. Функции Transformation Authoring основаны на технологии Eclipse с открытым исходным кодом, называемой JET.

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

• Инструментальные средства, генерирующие файлы. Можно использовать Transformation Authoring для быстрой разработки инструментальных средств, которые генерируют наборы файлов любого типа. Сюда относится исходный код на любом языке, файлы XML и, как будет показано в данном примере, даже целые проекты Java 2 Platform, Enterprise Edition (J2EE). Например, если есть серия процессов, которые довольно схожи и многочисленны, то можно построить инструментальное средство, которое их генерирует автоматически. А именно, можно создать инструментальное средство, которое создает проекты бизнес-процесса на языке Business Process Execution Language (BPEL) для IBM WebSphere Process Server, так, что не придется создавать их вручную.

• Инструментальные средства, преобразующие файлы в различные файловые структуры или файловые форматы. Можно создавать инструментальные средства, выполняющие преобразования. Если вы имеете представление о XSLT, то JET-шаблон может преобразовывать один файловый формат в другой, подобно тому, как это делает таблица стилей XSL. Разница заключается в том, что XSLT изначально является языком программирования, а Transformation Authoring использует процесс, называемый exemplar analysis (анализом образца), у которого есть экранный интерфейс. Вдобавок Transformation Authoring может генерировать файл любого типа, включая двоичный, и естественно может создавать файловые структуры более крупного масштаба. Это позволяет создавать все, что может быть представлено в рабочей области Eclipse, например, проекты корпоративных приложений (EAR) и архивы JAR-утилит Java 2 Platform, Enterprise Edition (J2EE).

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

• Инструментальные средства компоновки. Скрипты компоновки, например, Apache Ant, зачастую генерируют внешние вызовы, например, обращение к файловой системе, компилятору или исходной системе контроля. Хотя шаблоны JET, которые являются частью Transformation Authoring, и могут выполнять внешние вызовы, их целью является скорее трансформация, чем такой тип логики управления.
• Экранные редакторы. Как вскоре будет показано, результатом выполнения проекта Transformation Authoring является инструментальное средство, которое может выполняться. По-существу, это механизм, который принимает входные данные и выводит некоторые из выходных данных в рабочую область Eclipse. Вот поэтому для создания экранного редактора лучше подходит традиционная разработка плагина Eclipse.

Как показано на рисунке 1, после определения соответствующей проблемы, которую нужно решить, следующим шагом будет создание exemplar (образца). Образец является примерным решением проблемы. Например, если необходимо сконструировать инструментальное средство, генерирующее портлет, соответствующий виду и тематике Web-портала организации, то следует начать с примерного портлета. В качестве образца может выступать любой набор файлов. Например, образцом может быть отдельный файл XML, или папка с дюжиной классов Java, если они отражают то, что необходимо сгенерировать создаваемым инструментальным средством.

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

Рисунок 1. Процесс Transformation Authoring

Теперь, когда есть образец, следующим этапом будет создание проекта JET Transformation Authoring. Данный проект позволяет выполнять exemplar analysis (анализ образца), представляющий собой процесс, указывающий Rational Software Architect, что именно из выходного результата инструментального средства необходимо оставить в образце, а что следует изменить. Например, если нужно сконструировать инструментальное средство, создающее классы Java, то, возможно, не следует жестко кодировать имена этих объектов в инструментальном средстве. Вместо этого, может возникнуть желание предоставить инструментальному средству некоторую входную информацию относительно того, какие имена классов использовать. Именно такого рода решения принимаются во время анализа образца.

Результатом анализа образца является input model (модель входных данных) и шаблоны JET (на самом деле также создается много других файлов, но обязательно знать нужно только об этих). У модели входных данных инструментального средства может быть несколько функционально эквивалентных форм, включая схему XML, Eclipse Modeling Framework (EMF) модель Ecore или модель UML. Поэтому, например, если нужно создать простейшее инструментальное средство, которое генерирует произвольные папки и пустые файлы на основе модели входных данных в виде схемы XML, то входные данные такого инструментального средства могут выглядеть как код, показанный в листинге 1.

Шаблоны JET также создаются в процессе анализа образца. Изначально они являются точными копиями файлов образца. Следовательно, если в качестве образца использовать файл Book.java, то анализ образца создаст соответствующий файл Book.java.jet. Можно оформить шаблоны JET тегами JET на основе XPath 1.0. Теги снова укажут то, что должно быть статичным, и то, что должно динамически изменяться инструментальным средством. На диаграмме, представленной на рисунке 1, показан этап редактирования шаблонов. Более подробное описание приведено в статье с примером базы данных Pojo.

Когда редактирование шаблонов закончено, проект Transformation Authoring сам становится специализированным, повторно используемым инструментальным средством, как показано на рисунке 2. Можно запустить JET-преобразование при любых вводимых данных, отвечающих модели входных данных.

Рисунок 2. Иллюстрация использования специализированного инструментального средства

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

Предварительные условия

Помимо стандартной инсталляции Rational Software Architect 7.0, убедитесь, что установлена функция Transformation Authoring, как показано на рисунке 3. Для проверки того, инсталлирована она или нет, в Microsoft Windows выберите Start > Programs > IBM Installation Manager. Когда откроется Installation Manager, выберите Modify Packages.

Рисунок 3. Добавление функции Transformation Authoring
 

Пример базы данных Pojo

В данном разделе подробно рассматривается пошаговый пример конструирования инструментального средства при помощи Transformation Authoring. Проблема, решаемая инструментальным средством, которое будет сконструировано, заключается в согласованном доступе к базе данных в пределах большого приложения. Если обращение к базе данных происходит при помощи объектно-ориентированного языка, то зачастую возникает необходимость в преобразовании таблицы базы данных в объект. Стандартный способ - это шаблон объектов доступа к базам данных (Database Access Object - DAO). Данный шаблон выполняет преобразование таблиц в объекты, где у каждой таблицы соответствующий тип объекта. Однако когда в базе данных много таблиц, процесс написания соответствующего объекта для каждой таблицы становится очень утомительным. В случае Java, это может повлечь написание большого числа компонентов Java или обычных объектов Java (Pojos), также как и многочисленных свойств компонентов. В данном примере цель инструментального средства заключается в генерировании базы данных Pojo. Это также привнесет в вашу организацию непротиворечивость, поскольку весь коллектив разработчиков сможет использовать стандартное инструментальное средство для создания объектов доступа к базе данных.

Примечание: Конечно, для решения такого рода проблемы объектно-реляционного преобразования существуют и гораздо лучшие инструментальные средства, например, Apache iBatis и Java Persistence API. Мы выбрали данное простое инструментальное средство в качестве примера, поскольку его легко понять, но, тем не менее, оно достаточно сложно, чтобы оказаться нам полезным.

Как мы уже обсудили ранее, нам понадобится образец, чтобы начать процесс конструирования инструментального средства. То есть нужен пример того, что в конечном итоге должно создавать инструментальное средство. На рисунке 4 показан объект Java, который будет служить образцом в данном примере. Он соответствует таблице клиента в реляционной базе данных.

Рисунок 4. Образец Pojo, используемый в качестве примера

На рисунке 5 показан процесс Transformation Authoring для данного примера. Мы начнем с Web-проекта в рабочей области Rational Software Architect, которая содержит Pojo клиента и образец. Далее большая часть примера посвящена детализации процесса анализа образца для создания инструментального средства генерации базы данных Pojo. Когда инструмент будет закончен, можно будет модифицировать простой XML-файл и запустить его для генерирования любого количества Web-проектов и инкапсулированной базы данных Pojos.

Рисунок 5. Процесс Transformation Authoring в данном примере

Создание образца

В данном разделе будет выполнен импорт Web-проекта, используемого в данном упражнении в качестве образца. Будет приведено более подробное описание клиента Pojo и конфигурации Web-проекта.

1. Откройте Rational Software Architect в Web-окне.
2. Выберите File > Import... > Other > Project Interchange и импортируйте файл Exampleexemplar.zip.
3. Изучите Web-проект.

Обратите внимание, что это Web-проект J2EE с единственным компонентом Java, или Pojo, который называется CustomerDAO (см. Листинг 2). У Pojo есть несколько свойств компонентов и статический метод, называемый retrieveCustomer, для обращения к клиенту из базы данных при помощи первичного ключа и последующей выдачи результата CustomerDAO.

В листинге 2 числа в скобках указывают на несколько интересных моментов:

1. Cтрока констант в верхней части класса используется для хранения SQL-запроса для получения клиента.
2. Строка констант также используется для хранения контекстной ссылки на источник данных JDBC.
3. Статичный метод считывает клиента из базы данных.

Дважды щелкните на web.xml под DatabasePojo/WebContent/WEB-INF/, а затем выберите вкладку References. Обратите внимание на наличие внешней ссылки на источник данных Java Database Connectivity (JDBC) для Web-проекта, как показано на рисунке 6. Помните об этом, поскольку данная ссылка на ресурс будет играть большую роль в последующих разделах.

Рисунок 6. Ссылка на ресурс источника данных JDBC

Создание проекта анализа образца

В данном разделе показано, как создать проект Transformation Authoring и проект анализа образца. Во время данного процесса будет создана XML-схема, которая определит входные данные для создаваемого инструментального средства. Также будет сконфигурировано инструментальное средство для получения структуры директории и имен файлов, являющихся результатом Web-проектов, чтобы они были динамическими, а именно, чтобы имена директорий, например DatabasePojo, или имена файлов, начиная с Customer для образца, не были жестко закодированы, а скорее основывались на входных данных, предоставляемых пользователем инструментального средства.

1. Создание проекта анализа образца.
   1. Щелкните правой кнопкой мыши на Web-проекте DatabasePojo и выберите New > Other > Transformation Authoring > EMFT JET Project with exemplar Authoring.
   2. Укажите MyExamplarAnalysis в качестве имени проекта и нажмите Finish.

2. Создание атрибутов и типов модели входных данных.
   1. Щелкните правой кнопкой мыши на root, выберите New > Type и назовите его war.
   2. Щелкните правой кнопкой мыши на war, выберите New > Attribute и назовите его datasourceJNDI.
   3. По мере необходимости продолжите создавать типы и атрибуты для формирования структуры директории (древовидной), такой же как показано в правой части рисунка 7.

Рисунок 7. Определение модели входных данных

В правой части рисунка 7 показана модель входных данных инструментального средства. Соответствующая XML-схема находится в файле MyexemplarAnlysis/schema.xsd. В таблице 1 описано назначение всех типов и атрибутов в модели входных данных.

Таблица 1. Характеристика модели входных данных
 

Это просто пример модели входных данных. Он может быть изменен в любое время. Например, после окончания работы над данным примером, можно добавить атрибут package в daoBean, для того, чтобы пользователь мог указать, какой пакет Java используется для каждого компонента.

3. Настройка именования папки War-проекта.
   1. Переместите папку DatabasePojo в тип war в правой части окна, как показано на рисунке 8.
   2. Выберите Create Project: DatabasePojo, а затем вкладку Properties.
   3. В поле *name, щелкните правой кнопкой мыши на Database text в DatabasePojo и выберите Replace with Model Reference....
   4. Под типом war выберите атрибут name.

Рисунок 8. Ввод обобщенного имени Web-проекта

4. Настройка наименования и структуры папки для Java-класса Pojo.
   1. Переместите CustomerDAO.java в daoBean, как показано на рисунке 9.
   2. Выберите Create File: CustomerDAO, а затем вкладку Properties.
   3. В поле *path, щелкните правой кнопкой мыши на Database, выберите Replace with Model Reference..., и замените на имя атрибута под типом war.
   4. Аналогично, замените текст Customer из CustomerDAO на имя атрибута под типом daoBean.

Рисунок 9. Ввод обобщенного имени файла и пути Pojo

5. Настройка наименования и структуры папок для остальных файлов.
   1. Переместите файлы, выделенные в левой части окна рисунка 10 в war тип в правой части окна.
   2. Выберите Create File: .project, а затем вкладку Properties.
   3. В поле *path, замените текст Database на имя атрибута под типом war из модели входных данных, как показано на рисунке 11.
   4. Повторите эти операции для остальных восьми файлов, которые вы только что скопировали.

Рисунок 10. Настройка остальных файлов Web-проекта

Рисунок 11. Ввод обобщенного пути файла .project

Редактирование шаблонов JET

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

Для генерирования первоначальных JET шаблонов необходимо обновить проект Transformation Authoring.

1. Щелкните правой кнопкой мыши на правой панели модели входных данных и выберите Update Project, как показано на рисунке 12.

Рисунок 12. Обновление проекта (Update project)

2. Внимательно просмотрите проект MyexemplarAnalysis. Вы найдете несколько новых файлов, сгенерированных под шаблонами (см. рисунок 13).

Рисунок 13. Шаблоны JET

На данном этапе шаблоны являются точными копиями файлов проекта образца. В первую очередь будем работать с шаблонами web.xml.jet и CustomerDAO.java.jet, поскольку они содержат текст, который должен быть изменен инструментальным средством на основе модели входных данных. Большинство оставшихся файлов будут просто скопированы в выходной результат Web-проектов.

В шаблоне web.xml.jet необходимо изменить две вещи. Во-первых, имя проекта жестко закодировано - <display-name>DatabasePojo</display-name>. Обратите внимание, что Database подчеркнута синим цветом. Rational Software Architect автоматически распознает то, что вам, вероятно, потребуется изменить Database на атрибут имени war в модели входных данных. Следовательно, эту замену можно выполнить без ручного редактирования:

3. Отредактируйте шаблон web.xml для обобщения отображаемого имени.
   1. Откройте MyexemplarAnalysis/templates/war/web.xml.jet.
   2. Выберите вкладку Problems.
   3. Прокрутите вниз и выберите пункт Info, который в качестве ресурса соответствует web.xml.jet, как показано на рисунке 14.
   4. Щелкните правой кнопкой мыши и выберите Quick Fix, а затем OK.

Рисунок 14. Замена, на основе предположений Rational Software Architect

Вторая замена, которую необходимо сделать, это имя источника данных JDBC. В данный момент оно жестко закодировано - jdbc/ACMEDataSource. Так как не было автоматического определения, то придется указывать, какой атрибут из модели входных данных нужно заменить - атрибут war datasourceJNDI:

4. Отредактируйте шаблон web.xml для ввода обобщенного имени JDBC Datasource JDNI.
   1. Выберите текст jdbc/ACMEDataSource.
   2. Щелкните правой кнопкой мыши и выберите Replace with Model Reference....
   3. Замените на атрибут datasourceJNDI под типом war.

Полученный шаблон web.xml.jet должен выглядеть как показано в листинге 3.

В оставшейся части статьи объясняется изменение шаблона CustomerDAO.java.jet. Необходимо заменить определенный текст на теги так, чтобы он извлекался из модели входных данных при запуске инструментального средства Customer. В частности, нужно заменить текст, который ссылается на Customer или любое из его свойств Java-компонентов, например, social или joined.

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

5. Замените текст на теги, используя оставшиеся предложения Info.
   1. Откройте MyexemplarAnalysis/templates/daoBean/CustomerDAO.java.jet.
   2. Выберите вкладку Problems.
   3. Щелкните правой кнопкой мыши на first Info item для ресурса CustomerDAO.java.jet.
   4. Выберите Quick Fix > Replace all instances, как показано на рисунке 15, и щелкните OK.

Рисунок 15. Согласие со всеми предложениями в шаблоне Customer

6. Несколько предложений остаются на вкладке Problems - с ними тоже следует согласиться.

Шаблон Customer должен выглядеть в точности так же, как показано в листинге 4. Однако обратите внимание, что все еще есть много жестко закодированной информации из образца, которую нужно изменить для синхронизации с моделью входных данных. Например, SQL-запрос для customer все еще жестко закодирован, также как и информация, относящаяся к свойствам social, name и joined.

8. Ввод обобщенной строки SQL-запроса.
   1. Выделите текст SELECT CUSTOMER FROM ACME.DB WHERE SOCIAL = ?.
   2. Щелкните правой кнопкой мыши и замените его на атрибут SQL из модели входных данных.

Если вы посмотрите на раздел Attributes, то увидите, что попали в ситуацию, когда уже недостаточно просто произвести замену из модели входных данных. Причина заключается в том, что не известно, как много свойств пользователь предоставит для Pojo (для customer Pojo из образца их было три). Решением является использование тега JET <c:iterate/> над свойствами компонентов, предоставленных пользователем инструментального средства:

9. Замените атрибуты social, name и joined на тег <c:iterate/>, как показано в листинге 5.

При создании раздела методов get-and-set вы опять столкнетесь с новой ситуацией. На этот раз необходимо использовать тег итерации, но проблема в том, что в методах get имя свойства нужно писать с большой буквы. Например, если пользователь вводит foo в качестве имени свойства компонента, то необходимо сконструировать getFoo(). Решением будет использование выражения JET XPath, называемого uppercaseFirst(), следующим образом:

10. Замените social, name и joined методов get и set на тег <c:iterate/>, как показано в листинге 6.

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

11. Замените (int social, String name, Date joined) на подпись конструктора, как показано в листинге 7.

12. Замените тело конструктора, как показано в листинге 8.

В шаблоне Customer присутствует 3 вхождения слова customer . Вы снова используете выражение JET XPath lowercaseFirst() для того, чтобы убедиться, что первая буква - прописная:

13. Замените три вхождения customer на <c:get select="lowercaseFirst($war/@name)" />.

Статичный метод извлечения в шаблоне Customer берет первичный ключ в качестве аргумента. Определение типа для первичного ключа требует немного более продвинутого XPath с учетом того, что сначала необходимо проверить имя ключа, а затем сопоставить его с beanProperty, как показано на рисунке 16.

Рисунок 16. Место определения типа первичного ключа

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

14. Замените аргумент метода извлечения (int social), как показано в листинге 9.

15. Замените текст stmt.setInt(1, social); как показано в листинге 10.

При извлечении информации из ResultSet JDBC, появится новая проблема: поскольку для доступа к данным ResultSet требует числовой указатель (в образце были использованы числа 1-3). Стандартная функция XPath выдает позицию текущего узла при выполнении итераций по набору узлов, которая называется position(). Таким образом, можно использовать позицию для наполнения индексов:

16. Замените текст (result.getInt(1), result.getString(2), result.getDate(3)), как показано в листинге 11.

На этом процесс анализа образца и разработка специализированного инструментального средства завершаются.

Запуск преобразования

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

1. Определите входные данные, которые необходимо преобразовать.
   1. Откройте MyexemplarAnalysis/test.xml.
   2. Заполните узел <root/>, как показано в листинге 12.

2. Запуск преобразования.
   1. Щелкните правой кнопкой мыши на test.xml.
   2. Выберите Run As > Input for JET Transformation, как показано на рисунке 17.

Рисунок 17. Запуск преобразования JET

В результате в рабочей области вы должны увидеть новый Web-проект, который называется MyResultPojo, как показано на рисунке 18.

Рисунок 18. Результат преобразования

Обратите внимание, что были созданы два Pojo, названные BoatDAO и PlaneDAO, как показано на рисунке 19.

Рисунок 19. Объекты, полученные в результате обращения к базе данных

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

Предупреждение трудоемких проблем интеграции и миграции

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