Постоянная практика работы с инструментом управления изменениями IBM Rational ClearQuest выявила как его положительные, так и отрицательные стороны. При бесспорно сильном и гибком механизме формирования и редактирования схем управления изменениями - от создания экранных форм до программирования состояний и переходов для запросов на изменения (ЗИ) - можно отметить недостаток, связанный именно с программированием матрицы переходов при программировании жизненного цикла (ЖЦ) прохождения запроса на изменение.
В простом примере менеджер по управлению конфигурациями (УК) или менеджер по управлению изменениями (УИ) должен сформировать состав ЗИ и описать их жизненный цикл в диаграммах UML (это так называемый абстрактный, описательный уровень, Рисунок 1). После цикла согласований и утверждений диаграмма передается реализатору (возможно, администратору УИ), который, базируясь на модели, создает низкоуровневый набор команд для реализации в IBM Rational ClearQuest.
Данный пример показывает идеальную модель, которая в недостаточной мере применяется на практике. Зачастую модель не приобретает электронного вида, а сразу переносится (программируется) в IBM Rational ClearQuest.
Рисунок 1. Представление жизненного цикла прохождения запроса на изменение "Defect" в виде диаграммы UML 
Как правило, процессы в организациях не "костенеют" и развиваются подобно живому организму, проходя сложный эволюционный путь. Развитие процессов связано с внесением изменений как в физическую схему работ (в ClearQuest), так и в модель процесса. Обе операции ручные, т.е. тот же администратор должен внести изменения сначала в модель, а потом в схему ClearQuest (либо наоборот). Вот тут и проявляется главный человеческий фактор: поскольку обе операции ручные, то человек может допустить ошибку, причем ошибки могут быть различной тяжести. Самая банальная может заключаться в том, что важный переход не получил своего отражения либо в схеме, либо в описании процесса. К сожалению, на практике такое случается сплошь и рядом: рассогласование документированного процесса и реальной схемы может достигать 30% и более. Иными словами, процесс продолжает развиваться, а описание процесса либо серьезно отстает, либо вовсе затормаживается.
Рисунок 2. Матрица переходов в IBM Rational ClearQuest
Здесь определяется последовательность переходов запросов на изменение между состояниями. Матрица представляет собой физическое, низкоуровневое представление процесса. Скриншот показывает матрицу состояний запроса на изменение "Defect".
Решение задачи лежит на поверхности:
- взять IBM Rational ClearQuest;
- взять средство моделирования UML, например, IBM Rational Software Architect;
- создать Plug-Ins для RSA, который позволит импортировать жизненный цикл запроса на изменение из ClearQuest и представлять его в виде диаграммы UML.
Это решение позволяет вносить изменения сразу в физическое представление и тут же получать модель UML.
В данной статье подробно объясняется, каким образом можно создать Plug-Ins для RSA, выполняющий данные действия.
Дальнейшее развитие Plug-Ins - это формирование полностью замкнутого цикла описания процесса, при котором можно из модели RSA получить физическое представление в ClearQuest, но это тема отдельной статьи.
Модель процесса может быть представлена в двух видах:
- в виде диаграммы UML (абстрактное представление);
- в виде матрицы переходов (физическое представление).
IBM Rational Software Architect - это современная интегрированная среда разработки на основе Eclipse.
Сам по себе Eclipse является интегрированной расширяемой средой разработки; можно сказать, что именно широкие возможности расширения Eclipse выделяют его среди других современных сред разработки. Архитектура, в соответствии с которой построен Eclipse (и, как следствие, RSA) называется Rich Client Platform (RCP). По сути, данная архитектура подразумевает наличие микроядра, которое управляет жизненным циклом приложения и ряда вспомогательных служб, которые можно использовать, интегрируясь с архитектурой.
По факту, RSA - это базовый Eclipse с большим числом дополнительных 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, создав свою собственную группу меню.
В RSA, как и в Eclipse, есть унифицированная система установки новых plug-in"ов - через так называемые Update Site.
Update Site - это коллекция Features, которые в свою очередь хранят набор plug-in"ов.
Мы рассмотрим это подробнее после того как составим plug-in.
Есть как минимум два варианта интеграции RSA и ClearQuest.
- Использование COM.
- Использование native-функций, через которые работает сам ClearQuest. Один из возможных клиентов ClearQuest - оболочка над Eclipse, и имеет смысл воспользоваться уже проделанной низкоуровневой работой по интеграции ClearQuest с Eclipse.
В данной статье мы будем рассматривать интеграцию только через native-функции.
Для начала нам потребуется библиотека для 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 файлов, находящихся на файловой системе
