Хід роботи

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

Діаграми пакетів містять один тип елементів - пакет і один тип зв'язків - залежність, тому чисельна оцінка для діаграми пакетів не така важлива, як для діаграми класів.

На рис. 10.4 зображена діаграма пакетів підсистеми «Служба зайнятості у рамках внз» системи «Дистанційне навчання».

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

На рис. 10.5 зображена діаграма компонентів, побудована на основі діаграми пакетів, зображеної на мал. 10.4. На мал. 4.6 зображена діаграма розміщення підсистеми «Служба зайнятості у рамках внз».

Завдання

1. Побудувати для модельованої системи загальну діаграму пакетів, відмітити на ній пакети з необхідними системними бібліотеками, відобразити залежності між пакетами.

2. Побудувати для цієї системи діаграму компонентів, що відповідає побудованій діаграмі пакетів, системні пакети зображувати у вигляді специфікацій пакетів.

3. Побудувати для проектованої системи декілька варіантів діаграми розміщення(для архітектури «клієнт-сервер», трирівневої архітектури і т. д.), обґрунтувати кожен варіант, запропонувати найбільш оптимальний.

Контрольні питання

1. Яку проблему проектування покликані розв'язати діаграми пакетів?

2. У чому відмінність діаграм пакетів від діаграм класів?

3. У чому сенс залежності між елементами діаграми пакетів?

4. Що таке інтерфейс класу?

5. За якими ознаками класи групуються в пакети?

6. Які види елементів моделі представлені на діаграмі компонентів?

7. Як пов'язані між собою діаграми пакетів і діаграми компонентів?

8. Що показує діаграма розміщення?

9. Які сутності відображаються на діаграмах розміщення?

10. У яких випадках потрібне застосування діаграм розміщення?

Лабораторна робота № 11-12

Тема. Проектування системної архітектури. Уявлення реалізації. Компоненти ісхдного коду

Мета роботи : вивчення можливостей кодогенерації Rational Rose 98.

Короткі теоретичні відомості

Усі розробники стикаються з ситуацією, коли доводиться проектувати великі класи. При ручному введенні і оголошенні є ряд підводних каменів : по-перше, постановник завдань, як правило, описує «що треба» на словах, в крайньому випадку з мінімальним паперовим супроводом; по-друге, розробник, що створює систему, знову-таки у більшості випадків ігнорує усі коментарі, якими необхідно супроводжувати програмний код. Система кодогенерації Rational Rose дозволяє, разом з іншими засобами проектування, побудувати процес розробки програмного забезпечення як виробничий процес із строгим розподілом ролей, повноважень і т. д.

Для демонстраційних цілей досить спроектувати тільки один клас. Назвемо його String. У його обов'язки повинні входити основні операції над масивами(друк, копіювання, порівняння, отримання розміру). Як приклад опишемо спочатку цей клас на З++:

Class String Protected:

Char *TmpString; Public:

Int Counter;

Int Stat;

Int GetStringSize(Char *); Int PrintString(Char *); Int CmpString(Char *, Char *); Int CpyString(Char *, Char *);

};

Тепер засобами Rose все спроектуємо в графічному виді.

Кожен атрибут задається окремо, з коментарем, і розписується тип(public, protected, private). На мал. 15.1 показаний розворот специфікації для TmpString.

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

Результатом виконання вищеописаних дій буде поява клас са з розписаними специфікаціями. Сам клас показаний на мал. 15.2. Можна відмітити, що в графічному виді можна оцінити основні властивості кожного елементу.

Наступний крок в роботі – отриманні коду на С++. Тут хочеться розвіяти існуючий міф о 100 %-вій генерації кода. Rational Rose 98 в принципі не може дати готового коду, вона здатна лише спроектувати клас і розписати специфікацію кожного елемента, підставити шаблони членів класу для подальшого заповнення кодом. А ось для 100%-вої генерації робочого коду на С + + використовується Rational Rose RealTime, яка в даному випадку не розглядається. Ітак, повернемось до кодогенерації (точніше сказати до класогенерації). Через систему меню (Tools) обираємо мову що підтримується, для опису спроектованого класу (в даному випадку це С++), викликаємо Code Generational. Результатом роботи буде прояв двох файлів: MyString.h та MyString.cpp. В першому розписується сам клас, а другий є шаблоном для подальшого заповнення відповідним кодом. Нижче наводяться роздруківки обох файлів

Весь наведений матеріал отриманий без зміни налаштувань та без додаткової правки.

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

Для отримання ж докладного звіту по класу або технічного завдання можна скористатися інструментом Rational SoDA.

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