Rational Rose для розробників. Частина 2, CASE-засоби (моделювання), Програмування, статті

Частина 1

“З ким подружився … так тобі і треба …”,
– Способи впровадження CASE технологій ….


Вашій увазі пропонується наступна частина статті з Rational Rose, яка, як і раніше, цілком орієнтована на розробників, що використовують у своєму повсякденному житті мова С + +. В даній статті розглянуто: зворотне проектування (спробуємо проаналізувати наявний код і перетворити його в модель на розі). проектування складного класу (для початку), розглянемо деякі моменти в настройках Rose для ефективної кодогенераціі. Спробуємо розглянути лінки для інших (відмінних від С + +) мов програмування.

Так, першу частину ми цілком присвячуємо зворотного проектування.

Одне з безперечних переваг Rational Rose – зворотне проектування, оскільки розробнику і проектувальнику важливо побачити перед змінами вже працюючу систему в нормальному графічному поданні. Як правило, візуально-графічний ряд надає куди більший вплив ніж гортання технічних завдань і програмних текстів. Тим більше, що проект, що піддався зворотному проектування, може бути доопрацьований і знову згенерований (а згодом і скомпільований). Rational Rose надає для цього всі необхідні засоби.


Для здійснення зворотного проектування, в Rational Rose передбачений потужний модуль – Analyzer, чиє основне призначення, що випливає з назви, аналіз програм, написаних на С і С + +. Даний модуль здатний проаналізувати наявний файл на одному з вищезгаданих мов і перетворити його у візуальну модель, привласнивши вихідного файлу розширення mdl. Далі файл можна спокійно відкрити для модифікації з Rational Rose вже в візуальному режимі.

Analyzer являє собою окремий програмний файл, що викликається як з самої Rose, так і звичайним способом. Модуль входить не в усі поставки Rational Rose, а тільки в Enterprise, Professional і RealTime. В поставку Data Modeler даний модуль не входить, оскільки специфіка поставки не передбачає створення коду та зворотного проектування.

Подальша частина статті буде присвячена саме зворотного проектування. Розглянемо на конкретних прикладах, що розробник отримає від Rational Rose, застосовуючи її як інструмент візуального ГО-проектування.


Приклади будуть містити різні конструкції на мові С + + і результат їх перетворення в модель. Також постараємося приділити достатньо часу деталям трансляції коду програми в модель.

Рис. 1


Для правильного перетворення коду в модель необхідно провести кілька налаштувань, про які ми і поговоримо.

На малюнку 1 показаний зовнішній вигляд програми в стандартних настройках і з не захаращені екраном.

Основні поля, що підлягають обов’язковому заповненню (на першому етапі) це:


Для проведення правильного реінжинірінгу необхідно заповнити вищеописані поля. Всі файли, що підлягають реинженирингу, вказуються в полі “Files”. Слід враховувати, що при цьому ви отримуєте візуальну модель взаємодії класів та структур, стало бути не йде ні якої мови про те, щоб на візуальної моделі відбився існуючий код системи. Далі: всі нестандартні конструкції не будуть виведені в модель (аналізатор їх просто проігнорує), це означає, що будь-яке відхилення від заздалегідь відомих конструкцій призводить до того, що в початковому варіанті Rose не зможе правильно проаналізувати код. Цей факт не є недоліком, оскільки в арсеналі Analyser’а є інструменти тонкої настройки, що дозволяють налаштувати все таким чином, щоб специфіка конкретного проекту була б повністю врахована.

Процес реінжинірінгу ділиться на два етапи: аналіз і генерація моделі.

На першому етапі проводяться всі підготовчі операції з аналізу тексту програми на відсутність синтаксичних помилок. Другий етап – це перетворення коду в модель.

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

Відповідно, при відсутності помилок у файлі, можна приступити до генерації моделі. З метою оптимізації часу генерації в Rose передбачено три способи проведення реінжинірінгу, кожен з яких може охопити і чудово виконати певний сегмент робіт. Якщо користувачеві з якихось причин не підходить не один з трьох встановлених способів, то Rose допускає створення власного реверсінженірінга.

Поговоримо детальніше про три стандартних способи:


Всі налаштування можуть бути змінені користувачем на розсуд. При збереженні змін можливо вказати нове ім’я шаблона або перезаписати уже існуюче, що дозволить при частому використанні зворотного проектування не втрачати часу на установку потрібного пункту. Вибір відповідного пункту обов’язково позначається на швидкості аналізу, чим більше – тим довше. Ще хочеться відзначити таку особливість модуля Analyzer: після аналізу створюється не тільки модель, але і лог файл з повідомленнями, що виникли в результаті сканування програми. Лог може містити як попередження, так і помилки. А особливість генерації моделі полягає в тому, що вона відбудеться не дивлячись ні на що, то є, незважаючи на помилки в тексті програми. Природно, ніякої мови немає про яку-небудь правильної моделі! Цю особливість слід враховувати і уважно аналізувати файл звіту після генерації моделі.


Ще одна важлива ремарка. Як правило, зворотному проектуванню піддається повноцінний проектний файл, що містить в собі і директиви # INCLUDE для визначень, і коментарі, а також інші супровідні інструкції. І природно розробнику хочеться мати такий інструмент, який адекватно реагуватиме на всі складові. Поспішаю обрадувати: модуль Analyzer в режимі (DetailedAnalysis) забезпечує наступне:


Тепер від загальних фраз перейдемо до практики (як казав незабутній син турецького підданого: “ближче до тіла … відомості будуть оплачені …”). Для початку спробуємо виконати зворотне проектування з мови С без використання об’єктів. Нашою метою буде отримання графічної моделі зі структури на мові програмування. Чому структури? Даний тип даних все ще широко використовується програмістами мовою С, скидати з рахунків, який дещо передчасно!

Отже, проект для реверсінженірінга являє собою тільки заголовний файл з оголошенням наступної структури:


//It”s main structure
struct struct_main{
char *string; //Structure”s pointer
int buffer[100]; //Temporary buffer
char name[10];//Name of data
int a; //Integer
int b; //Integer
};








 

Рис. 2

Як бачите, структура досить тривіальна. Без надмірностей. Особливо хочеться ще раз звернути увагу на коментарі. Кожен рядок забезпечена коментарем, який несе певну смислове навантаження. Сенс будь-якого реверсінженірінга полягає не тільки в тому, щоб коректно намалювати модель, а й для правильного опису специфікації кожної складової класу / структури.


Після проведення всіх стандартних маніпуляцій зі створення проекту та його аналізу виходить ось така модель в троянді (рис 2):

Рис 2

Рис 3


Малюнки 2, 3 і 4 показують окремі специфікації.


  1. – Модель структури, отриманої в результаті зворотного проектування
  2. – Список атрибутів класу / структури. Тут перераховані всі змінні структури.
  3. – Генеральна інформація про структуру. Як видно з малюнка, коментар без яких би то не було обмежень перейшов в розряд документації, що дозволить використовувати його на подальшому етапі доповнення атрибутів, документування та створення звітів.

Як бачимо, кінцевий результат гідний уваги, оскільки модель нічого не втрачає в результаті зворотного проектування, у той же час саме зворотне проектування являє потужний механізм аналізу ефективності існуючих програмних напрацювань натисканням на одну-дві кнопки.

І ще … як окремого випадку розглянемо оголошення підструктури відповідно до нижчеподаних лістингом:


//It”s main structure
struct struct_main{
char *string; //Structure”s pointer
int buffer[100]; //Temporary buffer
char name[10];//Name of data
int a; //Integer
int b; //Integer

struct struct_in{
int m,st;
};

};


На цей раз без коментарів і занудства. На виході отримаємо (стр 5) наступну модель:








 

Рис. 5

Як бачимо, все ясно і зрозуміло. Скромно, але дуже інформативно. На жаль, якщо справа стосується структур, то ніякі зв’язку в моделі не генерітся!

Тепер перейдемо до більш важких матерій у вигляді класів С + +. Хоча мова С і залишається досить потужним структурним мовою, все ж його “образотворчих” коштів в плані побудови великих інформаційних систем явно недостатньо. Ми не будемо заглиблюватися в полеміку про те чому на великих проектах С + + виглядає виїгришней, також не будемо ми торкатися самої концепції ООП – це тема окремої статті. Нас цікавить досить приземлена проблема: як класи з чистого тексту можна перетворити в наочну модель із забезпеченням всіх графічних зв’язків …

Як і раніше, спробуємо виконати реверсінженірінг, використовуючи простий клас. За основу програми перепишемо (підстроїв) структуру під клас. Отримаємо в результаті щось схоже на наступний лістинг: / / It “s main class
class string{

public:
char *string; //Structure”s pointer
int buffer[100]; //Temporary buffer
char name[10]; //Name of data
int a; //Integer
int b; //Integer
void string(void); //constructor
void ~string(void); //destructor
char StringCopy(char *, //Buffer
char *, //source1
char *); //source2

private:
int tmp_a;
int tmp_b;

};


Результат зворотного проектування:








Рис. 6

Рис. 7

Малюнок 6 показує модель класу “string”. А на малюнку 7 відображається вкладка, що описує функції класу. Як і у випадку з змінними імена функцій на екрані. Також доступний вхід в специфікації конкретну функцію. Якщо ще раз повернутися до лістингу, то можна звернути увагу на декларацію функції “StringCopy”, в якій вхідні параметри прискіпливо документовані. Так от, якщо був застосований подібний підхід до документування, то коментар кожного параметра перенесеться в якості описового коментаря в відповідну частину атрибута моделі класу. Тобто, виходить, дуже вигідно піддавати обробці вихідні тексти, написані за всіма правилами програмування.

З простим класом все просто – зі складним – трохи складніше. Нижче вашій увазі представлений лістинг трьох класів і їх візуальна модель. Приклад ілюструє образотворчі можливості Rose в плані промальовування зв’язків між класами.


//It”s main class
class string{

public:
char *string; //Structure”s pointer
int buffer[100]; //Temporary buffer
char name[10]; //Name of data
int a; //Integer
int b; //Integer
void string(void); //constructor
void ~string(void); //destructor
char StringCopy(char *, //Buffer
char *, //source1
char *); //source2

private:
int tmp_a;
int tmp_b;

};

 
//It”s my string
class MyString: public string{

public:

int s,m,r;

private:
char ms, mss;
};

//Super string
class NewString: public string, MyString
{
public:
int z;
};








 

Рис. 8


Як видно з рисунку 8, після операції зворотного проектування відразу стане видно дерево успадкування, що дозволить розробнику дізнатися всю ієрархію, а потім оптимізувати додаток під власні потреби, позбавившись від непотрібної (неефективної) гілки.

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

Трохи про інших мовах програмування.


Rational Rose має в своєму арсеналі можливість прямого і зворотного проектування на: ADA, Java, C + +, COM, DDL, Basic, XML, схеми Oracle і Sql srv … Але як бути тим, хто використовує мови відсутні в списку підтримки? На жаль, компанія Ratoinl не прагне розширювати список підтримуваних мов за свій рахунок, віддавши на відкуп третім фірмам можливість заповнення мовних ніш. Це можливо з тієї простої причини, що Rose має відкрите, добре документоване API, що дозволяє будь-якій людині створити додатковий модуль (міст) для будь-якої мови! Підкреслюю: ДЛЯ БУДЬ-ЯКОГО. Природно, при цьому людина повинна знати UML і синтаксис мови-джерела і мати якийсь час на дану реалізацію. На сьогоднішній день Rose – це унікальний продукт в плані відкритості архітектури.

На даний момент існують декілька компаній, наприклад, EnsembleSystems (www.ensemble-systems.com), Що займаються написанням подібних лінків. Вже є лінки до Delphi, ErWin, Jbuilder, VisualCafe, Jdeveloper, VisualAge SmallTalk …

Погодьтеся, список вселяє оптимізм і вселяє надію, що рано чи пізно буде повністю покритий весь мовний спектр, і Роза почне розуміти все, включаючи людську мову!

Частина 3


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*