МІНІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ

НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ “ЛЬВІВСЬКА ПОЛІТЕХНІКА”

ІНЖЕНЕРІЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

МЕТОДИЧНІ ВКАЗІВКИ

до виконання лабораторної роботи

на тему:

“ВИВЧЕННЯ АРХІТЕКТУРИ ВІЗУАЛЬНИХ ІНТЕРФЕЙСІВ ТА БАЗОВИХ ІНСТРУМЕНТАЛЬНИХ ЗАСОБІВ CASE-СИСТЕМИ RATIONAL ROSE”

Львів – 2013

Інженерія програмного забезпечення: Методичні вказівки до виконання лабораторної роботи для студентів базових напрямків / Укл.: І. Я. Казимира, О. Н. Кузь. – Львів: Видавництво Національного університету “Львівська політехніка”, 2012. – 22с.

Укладачі: Казимира І. Я., к.т.н., доц.

Кузь О. Н., асист.

Відповідальний за випуск:

Рецензенти:

Мета: вивчити наступні питання

• призначення системи, склад та перелік її основних компонентів

• вивчення основних понять: пакети, класи, відношення (зв’язки), компоненти, стереотипи, представлення програмної системи як сукупності UML-діаграм;

• інтерфейс та можливості пакету Use Case View;

• інтерфейс та можливості пакету Logical View;

• інтерфейс та можливості пакету Component View;

• інтерфейс та можливості пакету Deployment View;

• розширення UML - діаграм для проектування Web-додатків.

1. Призначення системи, склад та перелік її основних компонентів

Case-засіб Rational Rose (RR) – інструмент для проектування програмного забезпечення (ПЗ) будь-якої складності. RR надає розробнику потужний арсенал засобів для аналізу і моделювання майбутньої програмної системи, також дозволяє документувати розроблюваний проект та генерувати готовий програмний код, у вигляді заглушок, який відповідає розробленим класам ПС. Однією з корисних особливостей Case-засобу Rational Rose є змога впроваджувати зворотній інженірінг проекту (reverse engineering), тобто генерувати діаграми з існуючого програмного коду.

До основних компонентів Case-засіб Rational Rose можна віднести наступні (Рис. 1):

1) головне меню; 2) панель інструментів: окрім стандартних функцій (створення, відкриття, друк проекту, тощо) надає можливість вибрати тип нової діаграми; 3) браузер проекту: показує дерево проекту – наявні діаграми та пакети; 4) панель інструментів діаграми: містить доступний для створення конкретної діаграми набір інструментів; 5) робоча область: найбільша візуальна область для створення діаграм; 6) вікно документації: область для ведення документації проекту – детального документування діаграм, пакетів, тощо; 7) вікно ведення журналу: область де відображуються записи в журналі проекту. Якщо є необхідність, журнал можна записати у файл.

Рис. 1

2. Вивчення основних понять uml-діаграм: пакети, класи, відношення (зв’язки) компоненти, стереотипи

2.1. Конструктивні блоки uml

Сутності є основою UML - моделей. Прив’язку сутностей одну до одної забезпечують відношення, а діаграми групують набори сутностей. В UML представлені чотири типи сутностей: структурні (structural), поведінкові (behavioral), такі, що групують (group), анотовані (annotational). Графічне зображення окремих типів сутностей, прийняте в UML, наводиться нижче.

Єдиним представником сутності, що угрупують, є пакет (package).

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

Рис. 2. Пакет

Анотації є пояснюючою та коментованою частиною UML. Єдиним її типом є примітка (note).

Рис. 3. Примітка

Примітка з’єднується пунктирною лінією із сутністю, до якої вона відноситься.

Клас (class) у мові UML використовується для визначення множини об’єктів, які мають однакову структуру, поведінку та відношення із об’єктами із інших класів. Графічно клас зображується у вигляді прямокутника, який додатково може бути розділений горизонтальними лініями на розділи та або секції (Рис. 4). В цих розділах вказуються ім’я класа, атрибути (змінні) ті операції (методи).

Атрибут - у другій зверху секції прямокутника класа записуються його атрибути (attributes) або властивості. У мові UML прийнята визначена стандартизація запису атрибутів класу, яка підпорядковується деяким синтаксичним правилам. Кожному атрибуту класу відповідає окрема строчка тексту, яка складається із квантора видимості атрибута, імені атрибута, його кратності, типу значень атрибута и, можливо, його початкового значення:

<квантор видимості><і’мя атрибута>[кратність]:

<тип атрибута> = <початкове значення>{строка-властивість}

Квантор видимості може приймати одне із трьох можливих значень та, відповідно, відображається за допомогою спеціальних символів:

1. Символ "+" означає атрибут з областю видимості типу загальнодоступний (public). Атрибут із цією областю видимості доступний або видний із будь-якого іншого класу пакета, у якому визначена діаграма.

2. Символ "#" означає атрибут з областю видимості типу захищений (protected). Атрибут із цією областю видимості недоступний або невидимий для усіх класів, за виключенням підкласів даного класу.

3. Знак "-" означає атрибут з областю видимості типу закритий (private). Атрибут із цією областю видимості недосяжне або невидимий для усіх класів без виключення.

Метод - в третій зверху секції прямокутника записуються операції або методи класу. Операція (operation) уявляє собою деякий сервіс, що надає кожний екземпляр класу по визначеній вимозі. Сукупність операцій характеризує функціональний аспект поведінки класу. Заспись операцій класу у мові UML також стандартизована і підкоряється визначеним синтаксичним правилам. При цьому кожній операції класу відповідає окрема строчка, яка складається із квантора видимості операції, ім’я операції, виразу типа повертаючого операцією значення і, можливо, cтрока-властивість даної операції:

<квантор видимості>< і’мя атрибута>(список параметрів):

<вираз типу повертаючого значення>{строка-властивість}

Квантор видимості, як і випадк уатрибутів класу, може приймати одне із трьох можливих значень та, відповідно, відображаються за допомогою спеціального символу. Символ "+" визначає операцію із областю видимості типу загальнодоступний (public). Символ "#" визначає операцію із областю видимості типу захищений (protected). І символ "-" використовується для визначення операції із областю видимості типу закритий (private)

Рис. 4 Клас

Крім внутрішньої побудови або структури класів на відповідній діаграмі вказуються різноманітні відношення між класами. При цьому сукупність типів таких відношень фіксована у мові UML та визначена семантикою цих типів відношень. Базовими відношеннями або зв’язками у мові UML є:

1) Відношення залежності (dependency relationship)

2) Відношення асоціації (association relationship)

3) Відношення узагальнення (generalization relationship)

4) Відношення реалізації (realization relationship)

Відношення залежності в загальному випадку указує деяке семантичне відношення між двома елементами моделі або двома множинами таких елементів, яке не є відношенням асоціації, узагальнення або реалізації. Воно стосується тільки самих елементів моделі і не вимагає безліч окремих прикладів для пояснення свого сенсу. Відношення залежності використовується в такій ситуації, коли деяка зміна одного елементу моделі може потребувати зміни іншого залежного від нього елементу моделі. Відношення залежності графічно зображується пунктирною лінією між відповідними елементами із стрілкою на одному з її кінців ("->" або "<-"). На діаграмі класів дане відношення зв'язує окремі класи між собою, при цьому стрілка направлена від класу-клієнта залежності до незалежного класу або класу-джерела (Рис. 5). На даному малюнку зображено два класи: Клас_А і Клас_Б, при цьому Клас_Б є джерелом деякої залежності, а Клас_А – клієнтом цієї залежності

Рис. 5

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

Найбільш простій випадок даного відношення - бінарна асоціація.

Наприклад: в системі є клас Робітник і клас Компанія. Асоціація між ними може називатися «Робота». Тоді можна сказати «Розробник працює в Компанії»

Рис. 6

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

Дане відношення має фундаментальне значення для опису структури складних систем, оскільки застосовується для представлення системних взаємозв'язків типу "частина-ціле" (part of). Розкриваючи внутрішню структуру системи, відношення агрегації показує, з яких компонентів складається система і як вони зв'язані між собою. З погляду моделі окремі частини системи можуть виступати як у вигляді елементів, так і у вигляді підсистем, які, у свою чергу, теж можуть утворювати складені компоненти або підсистеми. Це відношення за своєю суттю описує декомпозицію або розбиття складної системи на простіші складові частини, які також можуть бути піддані декомпозиції, якщо в цьому виникне необхідність в подальшому. Наприклад: розподіл комп’ютера на складові частини – системний блок, монітор, клавіатура, мишка

Рис. 7

Відношення узагальнення. Відношення узагальнення є звичайним таксономічнім відношенням між більш загальним елементом (батьком або предком) і більш приватним або спеціальним елементом (дочірнім або нащадком). Дане відношення може використовуватися для представлення взаємозв'язків між пакетами, класами, варіантами використання і іншими елементами мови UML.

Стосовно діаграми класів дане відношення описує ієрархічна будова класів і спадкоємство їх властивостей і поведінки. При цьому передбачається, що клас-нащадок володіє всіма властивостями і поведінкою класу-предка, а також має свої власні властивості і поведінку, які відсутні у класу-предка. На діаграмах відношення узагальнення позначається суцільною лінією з трикутною стрілкою на одному з кінців (Рис. 8). Стрілка указує на більш загальний клас (клас-предок або суперклас), а її відсутність – на більш спеціальний клас (клас-нащадок або підклас).

Рис. 8

Компонент (component) - Для представлення фізичної суті в мові UML застосовується спеціальний термін – компонент (component). Компонент реалізує деякий набір інтерфейсів і служить для загального позначення елементів фізичного представлення моделі. Для графічного представлення компоненту може використовуватися спеціальний символ – прямокутник зі вставленими зліва двома дрібнішими прямокутниками (малий. 9). Усередині охоплюю чого прямокутника записується ім'я компоненту і, можливо, деяка додаткова інформація. Зображення цього символу може трохи варіюватися залежно від характеру асоційованої з компонентом інформації

Рис. 9

Стереотип (stereotype) Проте час від часу доводиться вводити нову сутність, яка специфічна для словника предметної області, хоча виглядають подібно до примітивних будівельних блоків, вже наявних в мові.

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

Наприклад потрібно ввести допоміжний тип специфічний для веб- базованих систем – server page (Рис.10):

Рис.10

На рис.11 зображено внутрішній опис стереотипа

Рис. 11

У середовище RR існує 8 базових типів діаграм, користуючись якими розробник має можливість створювати вичерпний опис розроблюваної ПС:

1. UseCase diagram (діаграма прецедентів).

2. Class diagram (діаграма класів).

3. Component diagram (діаграма компонентів).

4. Deployment diagram (діаграма розташування).

5. Statechart diagram (діаграма стану).

6. Activity diagram (діаграма активностіі).

7. Collaboration diagram (діаграма взаємодії).

8. Sequence diagram (діаграма послідовності)

Вищезгадані діаграми в RR згруповані по декільком рівням моделювання характеристик ПЗ, що розробляється. Ці рівні називаються View, знаходяться в браузері деревоподібної структури проекту і показані символами відповідних пакетів (див. Рис. 1):

1) пакет Use Case View – діаграми цього рівня відповідають етапу концептуального (або архітектурного) рівня проектування ПЗ;

2) пакет Logical View – діаграми цього рівня відповідають етапу логічного проектування компонентів ПЗ, при цьому вони можуть бути поділені на 2 типа: статичні та динамічні діаграми ;

3) пакет Component View – діаграми цього рівня відповідають етапу фізичного рівня проектування компонентів ПЗ;

4) пакет Deployment View.- діаграми цього рівня також відповідають етапу фізичного рівня проектування компонентів ПЗ і доповнюють можливості пакет Component View.