Опыт реинжиниринга объектно- ориентированного комплекса программ с применением 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-средства.
