Поиск по сайту: Подпишись на рассылку:

Опыт реинжиниринга объектно- ориентированного комплекса программ с применением CASE- средства Ration

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