Обратное проектирование - Этапы проектирования

Процесс обратного проектирования делится на два этапа: анализ и генерацию модели.

На первом этапе производятся все подготовительные операции по анализу текста программы на отсутствие синтаксических ошибок. Второй этап -это преобразование кода в модель.

Все операции выполняются независимо, что дает больший маневр для разработчика, который, например, хочет провести только синтаксический разбор теста, без генерации модели.

Соответственно при отсутствии ошибок в файле можно приступить к генерации модели. В целях оптимизации времени генерации в Rose предусмотрено три способа проведения обратного проектирования, каждый из которых может охватить и превосходно выполнить определенный сегмент работ. Если пользователю по каким-либо причинам не подходит ни один из трех предустановленных способов, то Rose допускает создание собственного способа обратного проектирования.

Поговорим подробнее о следующих трех стандартных способах:

• FirstLook - приближенная пробежка по телу программы.

• Detailed Analysis - детальный анализ проекта.

• RoundTrip - комбинация двух вышеперечисленных способов. Позволяет безболезненно строить и перестраивать разрабатываемые приложения по принципу круговой разработки.

Все настройки могут быть изменены по усмотрению пользователя. При сохранении изменений возможно указать новое имя шаблона или перезаписать уже существующее, что позволит при частом использовании обратного проектирования не терять времени на установку нужного пункта. Выбор соответствующего пункта обязательно сказывается на скорости анализа, чем больше - тем дольше. Еще хочется отметить такую особенность модуля Analyzer: после анализа создается не только модель, но и лог-файл с сообщениями, возникшими в результате сканирования программы. Лог может содержать как предупреждения, так и ошибки. А особенность генерации модели состоит в том, что она состоится несмотря ни на что, т. е. невзирая на ошибки в тексте программы. Естественно, никакой речи нет о какой-либо правильной модели! Эту особенность следует учитывать и внимательно анализировать файл отчета после генерации модели.

Как правило, обратному проектированию подвергается полноценный проектный файл, содержащий в себе и директивы #INCLUDE для определений, и комментарии, а также прочие сопроводительные инструкции. И естественно, разработчику хочется иметь такой инструмент, который адекватно будет реагировать на все составляю­щие. Для этого модуль Analyzer в режиме (DetailedAnalysis) обеспечивает следующее:

• Анализ и преобразование в визуальную модель классов и структур.

• Генерацию связей в модели (между классами или структурами).

• Нахождение в исходном тексте комментариев и перенос их в качестве атрибутов компонентов модели. То есть если исходный текст снабжен комментариями, то они все перейдут в виде атрибутов к соответствующему элементу (переменной, массиву... и т. д.).

• Способен закачать в проект все заголовочные файлы (по цепочке один за другим).

Нашей целью будет получение графической модели из класса на языке программирования. Обратите внимание на комментарии. Каждая строка снабжена комментарием. Смысл обратного проектирования состоит не только в том, чтобы корректно нарисовать модель, но и для правильного описания спецификации каждой составляющей класса. За основу программы возьмем следующий класс:

//It's main class class string public:
char *string; //Structure's pointer
int buffer[100]; //Temporary buffer
char name[10]={"Massiv"}; //Name of data
int a; //Integer

int b; //Integer void string(void); //constructor
void ~string(void); //destructor char StringCopy(char *, //Buffer char *, //sourcel char *); //source2 private:
int tmp_a;
int tmp_b;

Результат обратного проектирования представлен на рис. 16.2.

Рис. 16.2. Класс String

Рис. 16.2 показывает модель класса string. А на рис. 16.3 отображается вкладка, описывающая функции класса. Как и в случае с переменными имена функций отображаются на экране. Также доступен вход в спецификации конкретной функции. Если еще раз вернуться к листингу, то можно обратить внимание на декларацию функции StringCopy, в которой входные параметры подробно документированы. Так вот: если был применен подобный подход к документированию, то комментарий каждого параметра перенесется в качестве описательного комментария в соответствующую часть атрибута модели класса. То есть, получается, очень выгодно подвергать обработке исходные тексты, написанные по всем правилам программирования.

Выразительные средства визуального проектирования и анализа делают Rational Rose незаменимым инструментом при создании крупных информационных систем. Особенно полно Rose раскрывает свои возможности при анализе эффективности не новой системы, а уже существующей. Вышеуказанные примеры показывают, что даст инструмент при анализе проекта на предмет повышения его эффективности. Данная проблемане является надуманной, поскольку подобный анализ нужен компаниям переводящим, например, старое программное обеспечение на новые платформы и новые технологии.

Рис. 16.3. Вкладка описывающая функции класса String

Модель ничего не теряет в результате обратного проектирования, в то же время само обратное проектирование представляет мощный механизм анализа эффективности существующих программных наработок нажатием на одну-две кнопки.

Rational Rose имеет в своем арсенале возможность прямого и обратного проектирования на ADA, Java, C++, COM, DDL, Basic, XML; схемы Oracle и Sql srv. Rose имеет открытое, хорошо документированное API, позволяющее любому человеку создать дополнительный модуль (мост) для любого языка. На сегодняшний день Rose - это уникальный продукт в плане открытости архитектуры.