РАЗДЕЛ 2
КОНЦЕПЦИЯ, ФОРМАЛЬНЫЕ ОСНОВЫ И СТРУКТУРА МЕТОДОЛОГИИ КРГИ
2.1. Описание концептуальных основ методологии КРГИ
Введем условные обозначения для структурных единиц объекта реинженерии.
Методология КРГИ представляет собой совокупность моделей, методов и средств технологии, основная идея которой концептуально состоит в расщеплении компонента К, внутри которого интегрированы функции графического интерфейса исходного приложения П, на пару компонентов, один из которых - легковесный интерфейсный компонент И, другой - основное ядро Б: .
По окончании процесса инженерии компонент И содержит только поддержку графического интерфейса и обладает возможностью удаленного запуска на большом количестве платформ.
В компоненте Б сконцентрирована только бизнес-логика начального компонента К. Платформа компонента Б совпадает с платформой исходного компонента К.
Компоненты И и Б связаны между собой с помощью транспортного протокола Т, обеспечивающего межкомпонентное взаимодействие как в рамках одного компьютера, так и в гетерогенной распределенной среде.
Схематически результат применения технологии к объекту реинженерии изображен на рис. 2.1:
Рис. 2.1. Концептуальная схема преобразования компонентов приложения при реинженерии по методологии КРГИ
2.2. Формальные основы методологии КРГИ
2.2.1. Общие требования к методологии и объектам реинженерии
Сформулируем набор требований к методологии КРГИ. Фактически, это детализация требований к гипотетической методологии, сформулированных в п. 1.4. Разрабатываемый технологический процесс должен удовлетворять следующим параметрам:
1. Основная функциональность исходного приложения должна быть полностью сохранена. Допускается изменение обеспечивающей функциональности.
2. Этапы технологического процесса реинженерии должны быть по возможности автоматизированы. Автор отдает себе отчет, что полностью автоматизировать процесс реинженерии для всего класса приложений КП-КРГИ нереально в силу индивидуальности архитектуры каждого приложения. Наиболее близко приблизиться к полностью автоматизированной технологии можно было бы при фиксации затрагиваемого слоя по уровню используемого GUI API. То есть, если бы мы свели задачу к эмулирующей библиотеке. Однако такой метод вступает в противоречие с требованием обеспечения удаленного запуска, т. к. неэффективно использует сетевой ресурс. В этом случае обмен между компонентами производится с помощью большого количества пакетов малого размера, что недопустимо для глобальных сетей и модемных соединений.
3. Метод должен оперировать с представлениями приложения, начиная с уровня исходных текстов, т. к. достигнуть требуемых параметров и показателей качества путем преобразований на уровне объектного кода не представляется возможным.
4. Должен затрагиваться только слой ГИП. Остальные слои должны остаться незатронутыми, чтобы минимизировать ошибки, вносимые процессом реинженерии. По этой же причине платформы исходного приложения и функциональной части конечного приложения, оставшейся после выделения графического интерфейса в отдельный компонент, должны совпадать.
5. Преобразованный слой ГИП должен обеспечить работу с приложением на разных платформах. То есть должна быть обеспечена мобильность графического интерфейса. Кроме того, архитектура на основе компонентной модели должна обеспечивать возможность удаленного запуска графического интерфейса, экономно используя сетевой ресурс.
6. Должна быть доступна функция визуального проектирования экранных форм для обеспечения легкости внесения возможных последующих изменений и добавлений в систему.
7. В качестве компонентной модели должна использоваться CORBA как архитектура, предоставляющая наилучшую интероперабельность на современном этапе.
8. Графические интерфейсы исходного и конечного приложений должны быть эквивалентны с точки зрения пользователя. Имеется в виду следующее:
* предоставление традиционного ГИП с окнами верхнего уровня;
* расположение визуальных элементов внутри окон, близкое к исходному;
* узнаваемый пользователями исходного приложения внешний вид новых визуальных элементов;
* реакция интерфейса, максимально приближенная к реакции исходного приложения, с поправкой на соглашения, принятые для платформ графического интерфейса.
9. Несмотря на попытки частичной автоматизации процесса восстановления спецификации, он остается очень трудоемким. Качество и адекватность получаемого описания архитектуры приложения сильно зависит от квалификации специалиста, выполняющего обратную инженерию. Разрабатываемая методология должна позволить избежать выполнения этого трудоемкого этапа в процессе реинженерии.
Теперь сформулируем набор требований к объекту реинженерии. Приложение, к которому может быть применена технология на базе методологии КРГИ, должна удовлетворять перечисленным ниже требованиям.
1. Наличие полностью собираемых исходных текстов компонента К. Это требование естественным образом следует из ориентации методологии на уровень исходного текста, хотя затрагивается также уровень моделей. Если сборка приложения осуществляется устаревшими средствами (не поддерживаемыми в настоящий момент компиляторами, препроцессорами и т.д.), то необходимо предварительно мигрировать приложение на современные средства. Объясняется это тем, что часть приложения, не затрагиваемая процессом реинженерии, будет инкапсулирована с использованием компонентной модели, интеграция которой с устаревшими средствами может быть затруднена.
2. Существование выбранной компонентной модели для исходной комбинации платформы и программной среды реализации приложения. Этот аспект также связан с проблемой инкапсуляции.
3. Взаимодействие исходного приложения с пользователем посредством компонентного оконного графического интерфейса. Подразумевается иерархическая организация экранных форм из типизированных визуальных элементов интерфейса. Приложения со специализированным графическим интерфейсом рассматриваться не будут. Это, например, ГИС-системы, системы 3D-моделирования, игровые прил