> PowerBuilder
Интегрированная среда анализа и компиляции проектов для PowerBuilder (PBCIDE)

Введение
     В связи со множеством ограничений среды разработки PowerBuilder, родилась идея реализовать функции по сопровождению и выпуска сборок проекта в самостоятельной интегрированной среде, позволяющей проводить анализ исходного кода проекта, зависимостей между объектами и компиляцию сборок проектов, разработанных в среде PowerBuilder.
Основные возможности
- компиляция (регенерация и компоновка) как всего проекта в целом, так и отдельных библиотек с учетом зависимостей между ними;
- управление версией проекта и номером сборки, включая сохранение соответствующей информации в коде проекта и исполняемом модуле; запись в раздел о версии исполняемого модуля информации об авторском праве, названии и описании проекта
- автоматизированное размещение проектов на файловых серверах разработки и архивных копий, получение извещений о появлении новых версий библиотек
- анализ зависимостей между библиотеками и между модулями. Поиск текста по исходному коду всего проекта, анализ зависимостей от объектов баз данных
- работа с системами контроля версий посредством унифицированного интерфейса SCCI (Source Code Control Interface), реализуемого большинством систем контроля версий, например, Microsoft Visual SourceSafe, Rational ClearCase и др.
- поддерживается работа со всеми стабильными версиями PowerBuilder, начиная с версии 6.5
Технические детали
Версии PowerBuilder
     В настоящий момент компилятор поддерживает следующие версии PowerBuilder: 6.5, 8.0, 9.0. Поддержка новых версий осуществляется своевременно с выходом стабильных версий PowerBuilder до тех пор, пока Sybase будет поддерживать PBORCA.
Операции над библиотеками
     PBORCA - это API для операций над библиотеками PowerBuilder. Библиотеки PowerBuilder имеют непрозрачную структуру, что требует использование средств самого PowerBuilder для осуществления регенерации, компоновки проекта и изменения исходного кода объектов библиотек. Таким средством и является PBORCA (Powersoft OpenLibrary API) - API для доступа к функциям Library Painter, таким как регенерация библиотек, компоновка, импорт/экспорт исходного кода объектов и т.п.
 
     Для всех операций над библиотеками компилятор использует исключительно данный API, что гарантирует безопасность работы с библиотеками проекта, т.к. все операции над объектами и библиотеками осуществляются исключительно посредством ядра PowerBuilder.
Требования к системе
     Основные задачи компилятора сборок: анализ проекта, сканирование зависимостей, регенерация и компоновка библиотек проекта, требуют большого числа операций с дисковой подсистемой. Таким образом, главным требованием к системе, на которой предполагается развернуть выпуск сборок, является быстрая дисковая подсистема. Также перечисленные операции практически полностью загружают центральный процессор (отчасти из-за большого числа дисковых операций) - если система для выпуска сборок используется и для других задач, то следует предусмотреть установку быстрого современного процессора, например, Intel Celeron от 700 МГц и выше. Использование оперативной памяти зависит от величины проекта (числа библиотек проекта) и в общем случае не является ограничивающим фактором, рекомендуемый нами минимальный объем составляет 256 Мб, с учетом использования серверного варианта Windows 2000.
Управление проектом
Файл проекта
     Все настройки по выпуску сборки проекта сохраняются в текстовом файле проекта (файл с расширением mk). Файл проекта имеет структуру обычного INI-файла. Все настройки самой среды сохраняются в реестре.
Варианты создания проекта
     Для поддержки различных вариантов бизнес-процесса выпуска сборки, существуют несколько способов создания проекта (из различных источников):
- на основе файловой системы - проект располагается в едином каталоге, который включает в себя подкаталог с библиотеками и подкаталог ресурсов, например, с именем "res", с файлами ресурсов (.pbr) и ресурсами
- на основе объекта типа "Project" - для унаследованных проектов
- на основе конфигурационного файла pb.ini - также для унаследованных проектов, для которых не использовался объект типа "Project"
- на основе SCC (Source Code Control)-проекта - для любых проектов, которые разрабатываются с использованием средства контроля версий (Version Control System).
Выпуск сборок
     Под выпуском сборки понимается процесс формирования дистрибутива проекта и его размещение на файловых серверах разработки и архива. В упрощенном варианте бизнес-процесса выпуск сборки является компиляцией проекта, которая состоит из следующих этапов:
- Сканирование зависимостей - построение дерева зависимостей библиотек друг от друга (например, функция fА, описанная в некотором объекте библиотеки А, используется в объектах библиотеки Б). Сортировка библиотек в порядке увеличения зависимостей позволяет построить верный порядок регенерации библиотек проекта, то есть первыми будут регенерироваться базовые (общие) библиотеки. Дерево зависимостей является фундаментом для анализа проекта.
- Управление версией и номером сборки проекта - разработчики ранних версий PowerBuilder (например, PowerBuilder 6.5) не позаботились об управлении версией проекта, включая информацию о разработчике проекта, его авторском праве и т.п. Типичный исполняемый модуль, созданный в среде PowerBuilder в разделе о версии содержит информацию о фирме "Sybase". Компилятор сборок предлагает три варианта управления версией проекта, которые можно объединять по вашему усмотрению в единый подход:
- сохранение информации о версии в файле проекта - вы всегда будете знать номер версии и номер сборки
- сохранение информации о версии в исполняемом модуле - эта информация доступна на закладке "Version" в окне свойств исполняемого модуля. Данный подход повышает представительский уровень вашей компании, а также реализует "родной" для Windows способ версионного контроля приложения, что может пригодиться при создании инсталляторов
- сохранение информации о версии и номере сборки в коде самого проекта - ваши тестеры и пользователи всегда будут в курсе номера версии сборки, с которой они работают. Более подробно данный подход описан в справочной системе компилятора сборок
- Регенерация проекта - регенерация всех библиотек проекта
- Компоновка проекта - компоновка всех библиотек проекта, а также формирование исполняемого модуля.
     В компиляторе сборок реализована поочередная регенерация библиотек проекта, в отличие от режима Full Rebuild, используемого в PowerBuilder. Это дает дополнительные преимущества:
- остановка регенерации в любой момент времени
- продолжение регенерации проекта после остановки в результате ошибки компиляции
- компиляция только отдельных изменившихся библиотек и включение их в дистрибутив
     Различные аспекты компиляции (только новое, приоритет компиляции, количество регенераций каждой библиотеки) сборки можно настраивать в зависимости от сложившихся условий выпуска сборки
     При компиляции унаследованных проектов, то есть разработанных под ранними версиями PowerBuilder, при помощи компилятора можно проводить миграцию проекта под новую среду исполнения
     Более сложные варианты бизнес-процесса выпуска сборки могут включать различные перемещения библиотек и исполняемых модулей проекта на файловые сервера разработки и архива. Различные модели движения библиотек, а также их реализация в среде рассматриваются в разделе о движении библиотек
Поиск
     В среде реализовано три вида поиска объектов.
     Поиск объектов по структуре проекта, то есть по составу библиотек проекта, предназначен для определения библиотеки, в которой содержится искомый объект. Это может пригодиться при наладке или доработке проекта, когда разработчик не знаком со всеми библиотеками проекта, но знает название объекта, который ему необходимо исправить.
     Поиск в исходном коде проекта является средством анализа проекта и позволяет определить те участки кода, в которых данный объект используется тем или иным образом.
     Поиск "плохих" объектов является средством повышения стабильности сборки и позволяет находить дублирующиеся или отсутствующие (но требуемые в других библиотеках) объекты в проекте.
Анализ проекта
     Компилятор сборок обладает мощным механизмом анализа зависимостей между библиотеками проекта. Ниже приводится перечень некоторых видов зависимостей:
- объект ОА некоторой библиотеки А использует (в нем декларативно объявлена) переменную типа объект ОБ, который расположен в библиотеке Б - пример статической зависимости
- объект ОА использует таблицы или хранимые процедуры - пример динамической зависимости
- объект ОА создает переменную, динамически определяя ее тип - пример динамической зависимости
     Компилятор сборок предоставляет инструменты для анализа как статических, так и динамических зависимостей и поможет вам ответить на следующие вопросы:
1. Как много исправлений придется произвести для изменения сигнатуры некоторой функции?
2. На какие участки кода может повлиять удаление или модификация некоторой таблицы?
3. Почему библиотеки обладают циклическими зависимостями?
4. Каким образом и где используются базовые объекты вашей системы?
     Компилятор сборок снабжен редактором исходного кода объектов, который представляет исходный код в виде дерева функций и событий и позволяет производить изменения в исходном коде.
Движение библиотек
     Под движением библиотек подразумевается некоторая модель перемещения библиотек от разработчиков на компьютер интегратора, модель выкладывания в общее пользование очередной версии проекта, а также архивирование проекта. Движение библиотек является неотъемлемой частью бизнес-процесса выпуска сборок, так как проект, как правило, создается группой разработчиков. В случае проектов, созданных на основе средства контроля версий (SCC), движение формируется операциями "Get Latset Version", "Check In" и "Check Out". Для большей гибкости компилятором сборок поддерживаются следующие средства по обеспечению движения библиотек:
- Ссылки - пути, по которым располагаются последние версии библиотек. Среда компилятора сборок автоматически отслеживает появление новых библиотек и предлагает провести обновление. Мастер поиска ссылок позволяет автоматизировать процесс сопоставления библиотеки и ссылки.
- Путь для выкладывания - путь, по которому должна располагаться откомпилированная библиотека. Мастер поиска путей для выкладывания позволяет автоматизировать процесс сопоставления библиотеки и пути для выкладывания.
- Мастер выкладывания проекта на сервер разработки - данный мастер призван исключить рутинные операции с файловым менеджером и автоматизировать процесс выкладывания откомпилированного проекта на сервер разработки.
- Мастер выкладывания проекта в архив - помимо автоматизации файловых операций (п. 3) мастер позволяет раскладывать проекты в архиве по версиям и номерам сборок.
Скачать демонстрационную версию (520 Кб)

 Evgeny Savitsky © 2002-2005