(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

Практика реализации модуля интеграции для Rational Software Architect. Часть 1

Источник: developerworks
Александр Новичков, руководитель отдела внедрения и консалтинга, СМ-Консалт, Алексей Черников, ведущий специалист отдела перспективных разработок, СМ-Консалт

Введение

Постоянная практика работы с инструментом управления изменениями IBM Rational ClearQuest выявила как его положительные, так и отрицательные стороны. При бесспорно сильном и гибком механизме формирования и редактирования схем управления изменениями - от создания экранных форм до программирования состояний и переходов для запросов на изменения (ЗИ) - можно отметить недостаток, связанный именно с программированием матрицы переходов при программировании жизненного цикла (ЖЦ) прохождения запроса на изменение.

В простом примере менеджер по управлению конфигурациями (УК) или менеджер по управлению изменениями (УИ) должен сформировать состав ЗИ и описать их жизненный цикл в диаграммах UML (это так называемый абстрактный, описательный уровень, Рисунок 1). После цикла согласований и утверждений диаграмма передается реализатору (возможно, администратору УИ), который, базируясь на модели, создает низкоуровневый набор команд для реализации в IBM Rational ClearQuest.

Данный пример показывает идеальную модель, которая в недостаточной мере применяется на практике. Зачастую модель не приобретает электронного вида, а сразу переносится (программируется) в IBM Rational ClearQuest.

Рисунок 1. Представление жизненного цикла прохождения запроса на изменение "Defect" в виде диаграммы UML
Рисунок 1. Представление жизненного цикла прохождения запроса на изменение

Как правило, процессы в организациях не "костенеют" и развиваются подобно живому организму, проходя сложный эволюционный путь. Развитие процессов связано с внесением изменений как в физическую схему работ (в ClearQuest), так и в модель процесса. Обе операции ручные, т.е. тот же администратор должен внести изменения сначала в модель, а потом в схему ClearQuest (либо наоборот). Вот тут и проявляется главный человеческий фактор: поскольку обе операции ручные, то человек может допустить ошибку, причем ошибки могут быть различной тяжести. Самая банальная может заключаться в том, что важный переход не получил своего отражения либо в схеме, либо в описании процесса. К сожалению, на практике такое случается сплошь и рядом: рассогласование документированного процесса и реальной схемы может достигать 30% и более. Иными словами, процесс продолжает развиваться, а описание процесса либо серьезно отстает, либо вовсе затормаживается.

Рисунок 2. Матрица переходов в IBM Rational ClearQuest
 

Здесь определяется последовательность переходов запросов на изменение между состояниями. Матрица представляет собой физическое, низкоуровневое представление процесса. Скриншот показывает матрицу состояний запроса на изменение "Defect".

Решение задачи лежит на поверхности:

  1. взять IBM Rational ClearQuest;
  2. взять средство моделирования UML, например, IBM Rational Software Architect;
  3. создать Plug-Ins для RSA, который позволит импортировать жизненный цикл запроса на изменение из ClearQuest и представлять его в виде диаграммы UML.

Это решение позволяет вносить изменения сразу в физическое представление и тут же получать модель UML.

В данной статье подробно объясняется, каким образом можно создать Plug-Ins для RSA, выполняющий данные действия.

Дальнейшее развитие Plug-Ins - это формирование полностью замкнутого цикла описания процесса, при котором можно из модели RSA получить физическое представление в ClearQuest, но это тема отдельной статьи.

Модель процесса может быть представлена в двух видах:

  • в виде диаграммы UML (абстрактное представление);
  • в виде матрицы переходов (физическое представление).

Общее представление об RSA

IBM Rational Software Architect - это современная интегрированная среда разработки на основе Eclipse.

Сам по себе Eclipse является интегрированной расширяемой средой разработки; можно сказать, что именно широкие возможности расширения Eclipse выделяют его среди других современных сред разработки. Архитектура, в соответствии с которой построен Eclipse (и, как следствие, RSA) называется Rich Client Platform (RCP). По сути, данная архитектура подразумевает наличие микроядра, которое управляет жизненным циклом приложения и ряда вспомогательных служб, которые можно использовать, интегрируясь с архитектурой.

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

Разработка plug-in"а для RSA

Центральный элемент расширения RSA (и Eclipse) - plug-in. Функциональность plug-in"а может быть любой - всё, что можно описать на Java, может быть plug-in"ом.

Plug-in"ы часто бывают очень сложными, а поскольку среда состоит из огромного числа plug-in"ов, которые необходимо инициализировать, она, как правило, запускается довольно долго; из-за этого возникают определённые трудности при отладке plug-in"ов (особенно если учесть, что обновление установленного plug-in до новой версии тоже может занять длительное время). Чтобы протестировать работоспособность собственного plug-in"а, который работает внутри RSA, используется Runtime Workbench.

В Runtime Workbench есть все необходимые для работы RSA сервисы, но, как правило, их там заметно меньше, чем в рабочей версии RSA, в которой ведётся разработка (точные настройки используемой конфигурации plug-in"ов для Runtime Workbench можно найти в Window - Preferences - Plug-in development - Target platform).

Даже с упрощениями Runtime Workbench инициализация RSA всё равно может занять достаточно много времени. Чтобы проще было отлаживать функциональность plug-in"ов, в RSA есть такое понятие как Pluglet - он работает схоже с plug-in"ом, но запускается прямо из рабочего RSA, в котором ведётся разработка.

К сожалению, Pluglet подходит не для всех целей; в текущей версии IBM Rational Software Architect (на момент написания статьи - 7.0.0) невозможно без перезапуска среды два раза выполнить Pluglet, если он содержит Native-вызовы.

Java позволяет загрузить native-библиотеку в один Classloader, и при втором запуске Pluglet считает, что native-библиотека уже загружена в другом Classloader"е, но не имеет к нему доступа. Поскольку в этой статье мы сделаем упор на использование native-библиотек для взаимодействия с IBM Rational ClearQuest, более подробно рассматривать Pluglets не будем.

Общие принципы

Plug-in"ы могут как расширять интерфейс, так и выполнять какие-то фоновые задания или предоставлять некоторые службы другим plug-in"ам. Это настраивается при создании plug-in"а.

Plug-in"ы могут встраиваться в интерфейс RSA практически в любое место: в контекстное меню, в Menu Bar, они могут создавать собственный View. При этом можно достаточно гибко задавать условия, при которых plug-in становится видимым (например, если он встраивается в контекстное меню, можно задать, чтобы этот пункт меню появлялся только при выделении файлов какого-то расширения).

Далее в данной статье мы увидим, как встроить plug-in в Menu Bar, создав свою собственную группу меню.

Установка plug-in"а в RSA

В RSA, как и в Eclipse, есть унифицированная система установки новых plug-in"ов - через так называемые Update Site.

Update Site - это коллекция Features, которые в свою очередь хранят набор plug-in"ов.

Мы рассмотрим это подробнее после того как составим plug-in.

Интеграция RSA и ClearQuest

Есть как минимум два варианта интеграции RSA и ClearQuest.

  1. Использование COM.
  2. Использование native-функций, через которые работает сам ClearQuest. Один из возможных клиентов ClearQuest - оболочка над Eclipse, и имеет смысл воспользоваться уже проделанной низкоуровневой работой по интеграции ClearQuest с Eclipse.

В данной статье мы будем рассматривать интеграцию только через native-функции.

ClearQuest JNI

Для начала нам потребуется библиотека для Java, которая будет вызывать native-функции ClearQuest"а через Java Native Interface. Она поставляется вместе с ClearQuest, в виде скомпилированного .jar.

В каталоге, в который установлен IBM Rational ClearQuest (в Windows по умолчанию это каталог C:\Program Files\Rational\ClearQuest), находится файл cqjni.jar.

Можно было бы его добавить в Build Path проекта, и в обычных приложениях уже был бы доступ к CQ через JNI. Но тогда процесс отладки plug-in"а может оказаться неудобным - при запуске Runtime Workbench, native-вызовы, которые пытаются работать из скомпилированного .jar, могут не срабатывать (на них будет прерываться выполнение задачи plug-in"а, ошибки выводиться не будут). Поэтому, чтобы быть уверенными в результатах, мы сначала декомпилируем cqjni.jar.

Если же вы решите включить .jar в Build Path, не забудьте, что это native-библиотека, и поэтому необходимо прописать её Native Path. К статье прилагается уже декомпилированный набор классов из cqjni.jar, так что самостоятельно их добывать не обязательно.

Для Java есть достаточно много декомпиляторов; в этой статье мы будем использовать jad, бесплатный для некоммерческого использования. Работа с ним идёт через консоль. У ряда других бесплатных декомпиляторов нет возможности декомпилировать сразу множество файлов, особенно часто такое бывает среди декомпиляторов с графическим интерфейсом без консольного аналога.

В принципе, в нашем случае подойдёт практически любой декомпилятор - для нас не принципиально, чтобы код был читаемым, требуется только, чтобы он работал.

Итак, jad можно скачать, например, здесь: http://www.varaneckas.com/jad (EN). После того как он скачается, его следует разархивировать и добавить в PATH (либо при дальнейшей работе с ним убедиться, что к нему есть доступ).

Далее потребуется взять ранее упомянутый cqjni.jar, и извлечь из него все .class-файлы (с помощью любого распаковщика, который умеет распаковывать .zip). Из папки с извлечёнными .class-файлами для декомпиляции можно запустить команду:

jad -d CQJNI -s .java *.class

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

Чтобы необходимые ручные изменения применить и проверить их работоспособность, создадим тестовый проект через File - New - Other, Java Project. Назовём его CQJNITest.

Далее, импортируем наши декомпилированные классы. Из контекстного меню нашего проекта выбираем Import, затем File System (Рисунок 3).

Рисунок 3. Окно импорта в проект IBM Rational Software Architect  файлов, находящихся на файловой системе

 
Читать часть 2

Ссылки по теме


 Распечатать »
 Правила публикации »
  Написать редактору 
 Рекомендовать » Дата публикации: 12.01.2010 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
IBM Rational Functional Tester Floating User License
IBM RATIONAL Quality Manager Quality Professional Authorized User Single Install License + Sw Subscription & Support 12 Months
IBM RATIONAL Clearcase Floating User License + Sw Subscription & Support 12 Months
Rational ClearCase Multisite Floating User License
Rational ClearQuest Floating User License
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
СУБД Oracle "с нуля"
Программирование на Visual Basic/Visual Studio и ASP/ASP.NET
Проект mic-hard - все об XP - новости, статьи, советы
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
 



    
rambler's top100 Rambler's Top100