Опыт реинжиниринга объектно-
ориентированного комплекса программ с применением CASE-
средства Rational Rose и SILVERRUN
Ю.Новоженов, Компания Аргуссофт
Мировая практика разработки сложных программных комплексов показывает, что обычно такие
системы имеют предысторию в виде совокупности программ, которые частично или полностью
реализуют требования к системе. Для их развития и дальнейшего сопровождения такой системы
именно в силу ее сложности требуется создание совокупности моделей, представляющих в
графическом виде разные аспекты системы и отражающих иерархию ее построения. В особенности это
касается систем, предыстория которых в той или иной мере основана на применении объектно-
ориентированного подхода.
Для создания подобных моделей современные инструментальные средства включают специальные
средства реинжиниринга, позволяющие восстановить отдельные модели по исходным текстам
программ.
Исходные предпосылки для проведения реинжиниринга состоят в следующем.
Имеется реализованная и оттестированная информационная система.
Имеется определенный перечень задач, которые решает система.
Имеются тексты программ, решающих эти задачи, на некотором языке (языках)
программирования.
Отдельно от системы может существовать документ, в котором заказчик декларирует, что в
системе должно быть добавлено или изменено.
Построение модели системы включает решение следующих задач:
Создание описания архитектуры. Архитектура описывается в виде иерархии категорий
классов, соответствующей разным уровням абстракции. В дальнейшем предполагается взаимно
однозначное соответствие между понятиями "категория классов" и "подсистема". Каждой категории
должен соответствовать каталог на внешнем устройстве, а иерархии категорий - иерархия каталогов.
Логическое моделирование. Строятся диаграммы классов, где показываются классы и отношения
между ними.
Построение функциональной модели системы. Решение этой задачи предполагает описание
поведения системы в виде иерархии диаграмм сценариев.
Динамическое моделирование. Динамика работы системы описывается с помощью диаграмм
состояний для управляющих классов.
Реинжиниринг базы данных системы с построением ER-диаграмм.
Порядок решения этих задач принципиально отличается от порядка действий, выполняемых при
разработке новых проектов. Архитектура и логическое описание системы могут быть автоматически
получены с помощью реинжиниринга текстов программ и построения диаграмм классов CASE-
системой. Таким образом, не функциональное описание системы служит основой для выявления
классов и отношений между ними, а наоборот, предварительно полученные диаграммы классов
наряду с программными кодами служат для описания поведения системы и динамики ее работы.
Примером инструментального средства, реализующего объектно-ориентированный подход к
разработке программных систем, является семейство CASE-систем Rational Rose фирмы Rational
Software Corporation.
Системы, входящие в состав этого семейства, предназначаются для автоматизации этапов анализа и
проектирования, а также для генерации кодов на различных языках и выпуска проектной
документации. Все CASE-средства, входящие в состав Rational Rose, используют методы Гради Буча
(он является научным руководителем разработок) и ОМТ Джеймса Рамбо, поддерживая единый
графический интерфейс с пользователем. Различия между этими системами минимальны и
определяются языками, на которых генерируются коды программ.
В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий,
графический интерфейс пользователя (GUI), средства просмотра проекта (browser), средства
контроля проекта, средства сбора статистики и генератор документов. Все перечисленные
компоненты являются общими для всех систем семейства. К ним следует добавить генератор кодов -
индивидуальный для каждой системы - и анализатор - отдельный программный модуль,
обеспечивающий реинжиниринг.
Репозиторий представляет собой объектно-ориентированную базу данных. Средства просмотра
обеспечивают "навигацию" по проекту, в том числе, перемещение вверх/вниз по иерархиям классов и
подсистем, переключение из одного вида диаграмм к другому и т. д. Средства контроля и сбора
статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после
завершения его описания. Генератор отчетов формирует тексты выходных документов на основе
содержащейся в репозитории информации.
Rational Rose включает средства автоматической генерации кодов программ на языках третьего и
четвертого поколений. Используя информацию, содержащуюся в логической и физической моделях
проекта, генератор кодов формирует файлы заголовков и файлы описаний классов и объектов.
Создаваемый таким образом скелет программы может быть уточнен путем прямого
программирования.
Анализатор кодов создает модели проектов на основе информации, содержащейся в определяемых
пользователем исходных текстах программ. В процессе работы анализатор осуществляет контроль
правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы,
может целиком или фрагментарно использоваться в различных проектах. Таким образом
обеспечивается возможность повторного использования программных компонент.
В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций,
определяющих логическую и физическую структуры модели, ее статические и динамические аспекты.
Диаграммы классов показывают классы и их иерархии, отображая логику построения прикладной
системы. Для больших систем обычно строится не одна а несколько подобных диаграмм.
Диаграмма классов определяет только статические аспекты, относящиеся к классам. Динамика их
поведения представляется на диаграммах состояний. Диаграммы сценариев показывают
существующие объекты и их взаимодействие в логическом проекте прикладной системы.
Модульные диаграммы определяют распределение классов и объектов в модулях, физически
реализующих проект. Одна модульная диаграмма представляет всю или часть модульной
архитектуры системы. Для решения задачи распределения аппаратных ресурсов в Rational Rose
используются диаграммы процессов.
Не вся необходимая информация о проекте может быть наглядно отражена в диаграммах, поэтому
Rational Rose содержит средства ввода спецификаций, которые дополняют набор диаграмм.
Спецификации создаются для классов, класс-утилит, операций, подсистем, объектов, модулей и т.
д.
Основные свойства Rational Rose, обеспечивающие ее высокую конкурентоспособность на мировом
рынке программных средств:
охват всех этапов жизненного цикла работы над проектом с единой
методикой и нотацией;
возможность повторного использования программных разработок
пользователей за счет средств реинжиниринга;
наличие средств автоматического контроля, позволяющих вести отладку
проекта по мере его разработки;
возможность описания проекта на разных уровнях для различных категорий
пользователей;
удобный для пользователя графический интерфейс;
автоматическая генерация кодов на языках С++, Ada, Smalltalk, PowerBuilder,
SQLWindows, VisualBasic;
наличие средств групповой разработки;
широкий спектр применения системы - базы данных, банковские системы,
телекоммуникация, системы реального времени и т. д.
возможность использования различных платформ: IBM PC (в среде
Windows), Sun SPARC Stations (Solaris, SunOS), Hewlett-Packard (HP UX), IBM
RS/6000 (AIX).
Система Rational Rose/С++ была применена для реинжиниринга банковской информационной
системы, применяемой в системе ЦБ РФ. Это - сложная система с полной предысторией, содержащая
системные библиотеки и приложения. Работа выполнялась на платформе Windows '95 (компьютере
P/100 с 16 MB оперативной памяти). Реинжиниринг приложений, содержащих свыше 500 классов,
выполнялся около 25 часов.
Отдельно на той же платформе был выполнен реинжиниринг базы данных системы с помощью CASE-
средства SILVERRUN. За время порядка 5 минут была построена ER-модель базы данных,
содержащей около 200 таблиц.
Результаты можно сформулировать следующим образом:
Система Rational Rose/С++ обеспечивает реинжиниринг сложных информационных систем
на базе весьма ограниченных ресурсов.
CASE-средство SILVERRUN обеспечивает реинжиниринг сложных баз данных за минимальное
время.
Восстановлена архитектура системы в виде иерархии категорий классов.
Получена логическая модель системы в виде совокупности диаграмм и спецификаций классов.
Построена физическая модель системы в виде диаграмм подсистем и модулей.
Анализ результатов реинжиниринга позволил определить наиболее существенные недостатки
существующего комплекса программ и пути их исправления. Вот несколько примеров.
В рамках проекта определены общие классы, которые отдельными
разработчиками могут переопределяться. При этом каждый разработчик имеет
право создавать новый класс с тем же именем, что и общий класс, в своем
каталоге. В результате дублируется код, изменения, вносимые в общие классы,
нужно повторять в каталоге разработчика, возникает путаница с именами
классов, что особенно неудобно при построении и анализе модели. Объектно-
ориентированный подход предлагает простой и естественный путь исправления
таких ситуаций - применение механизма наследования. Разработчики должны не
дублировать общий класс, а заводить класс-наследник (с оригинальным
именем).
В системе представлены несколько разных проектов, причем в проекте могут
использоваться классы из других проектов путем указания доступа к
соответствующим программным модулям. Это плохо, так как класс в проекте-
владельце может быть изменен, а в других это не требуется, что может
приводить к совершенно непредсказуемым ошибкам, которые могут возникать
даже без изменений исходных кодов, а просто при повторном конфигурировании
системы. Нужно сформировать библиотеку классов, представляющих типовые
проектные решения, куда следует занести все классы, которые разделяются
между разными проектами. Эти классы изменять не следует, а при
необходимости внесения изменений или уточнений в проекте заводится класс-
наследник.
Реинжиниринг и анализ отдельных приложений показал, что есть много
классов, которые не связаны отношениями с другими классами. Причина состоит
в том, что не выдержан объектно-ориентированный стиль программирования. В
приложениях есть достаточно сложные функции на С (например, main), которые
исполняют роли управляющих классов. Такое положение дел не отвечает задаче
сопровождения, поскольку большое число фактических связей, имеющихся в
системе, в модели будет отсутствовать. В результате прослеживание и
локализация ошибок будет затруднена. Выход из этой ситуации очевиден.
Следует полностью использовать объектно-ориентированные возможности С++,
создавая управляющие классы и минимизируя использование функций на
С.
Построенные диаграммы классов и модулей являются основой для разработки полной модели системы
путем дополнения их диаграммами состояний и взаимодействий, которые создаются с помощью того
же CASE-средства.