Лабораторна робота №1. Розробка UML діаграм

РОЗРОБКА UML ДІАГРАМ

 

1 Тема роботи: Вивчення архітектури, візуальних інтерфейсів та базових інструментальних засобів CASE-системи Rational Rose

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

3 Опис робочого місця: На кожному робочому місці повинен бути комп`ютер з CASE-системой Rational Rose

4 Теоретичний матеріал:

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

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

1) головне меню;

2) панель інструментів: окрім стандартних функцій (створення, відкриття, друку проекту, тощо) надає можливість вибрати тип нової діаграми;

3) браузер проекту: показує дерево проекту – наявні діаграми та пакети;

4) панель інструментів діаграми: містить доступний для створення конкретної діаграми набір інструментів;

5) робоча область: найбільша візуальна область для створення діаграм;

6) вікно документації: область для ведення документації проекту – детального документування діаграм, пакетів, тощо;

7)вікно ведення журналу: область де відображується записи в журна проекту.

Якщо є необхідність, журнал можна записати у файл.

Рисунок 1.1- Основні компоненти

 

Конструктивні блоки UML

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

 

Рисунок 1.2-Пакет

 

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

Рисунок 1.3-Примітка

 

Примітка з’єднується пунктирною лінією із сутністю, до якої вона відноситься. Клас (class) у мові UML використовується для визначення множини об’єктів, які мають однакову структуру, поведінку та відношення із об’єктами із інших класів. Графічно клас зображується у вигляді прямокутника, який додатково може бути розділений горизонтальними лініями на розділи або секції (Рис. 4). В цих розділах вказуються ім’я класа, атрибути (змінні) ті операції (методи). Атрибут - у другій зверху секції прямокутника класа записуються його атрибути (attributes) або властивості. У мові UML прийнята визначена стандартизація запису атрибутів класу, яка підпорядковується деяким синтаксичним правилам. Кожному атрибуту класу відповідає окрема строчка тексту, яка складається із квантора видимості атрибута, імені атрибута, його кратності, типу значень атрибута и, можливо, його початкового значення: <квантор видимості><і’мя атрибута>[кратність]: <тип атрибута> = <початкове значення>{строка-властивість} Квантор видимості може приймати одне із трьох можливих значень та, відповідно, відображається за допомогою спеціальних символів: 1. Символ "+" означає атрибут з областю видимості типу загальнодоступний (public). Атрибут із цією областю видимості доступний або видний із будь-якого іншого класа пакета, у якому визначена діаграма.

Символ "#" означає атрибут з областю видимості типу захищений (protected). Атрибут із цією областю видимості недоступний або невидимий для усіх класів, за виключенням підкласів даного класу. 3. Знак "-" означає атрибут з областю видимості типу закритий (private). Атрибут із цією областю видимості недосяжне або невидимий для усіх класів без виключення. Метод - в третій зверху секції прямокутника записуються операції або методи класу. Операція (operation) уявляє собою деякий сервіс, що надає кожний екземпляр класу по визначеній вимозі. Сукупність операцій характеризує функціональний аспект поведінки класу. Заспись операцій класу у мові UML також стандартизована и підкоряється визначеним синтаксичним правилам. При цьому кожній операції класу відповідає окрема строчка, яка складається із квантора видимості операції, ім’я операції, виразу типа повертаючого операцією значення і, можливо, cтрока-властивість даної операції: <квантор видимості>< і’мя атрибута>(список параметрів): <вираз типу повертаючого значення>{строка-властивість} Квантор видимості, як і у випадку атрибутів класу, може приймати одне із трьох можливих значень та, відповідно, відображаються за допомогою спеціального символу. Символ "+" визначає операцію із областю видимості типу загальнодоступний(public). Символ "#" визначає операцію із областю видимості типу захищений (protected). І, кінець кінцем, символ "-" використовується для визначення операції із областю видимості типу закритий (private)

Класс

атрибут

метод()

Рисунок 1.4-Клас

 

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

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

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

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

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

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

Клас А

атрибут

метод()

Клас Б

атрибут

метод()

Рисунок 1.5-

 

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

 

Рисунок 1.6-

 

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

Рисунок 1.7-

 

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

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

Рисунок 1.8- Предок - Нащадок

 

Компонент (component) - Для представлення фізичної суті в мові UML застосовується спеціальний термін - компонент (component). Компонент реалізує деякий набір інтерфейсів і служить для загального позначення елементів фізичного представлення моделі. Для графічного представлення компоненту може використовуватися спеціальний символ - прямокутник зі вставленими зліва двома дрібнішими прямокутниками (рисунок 1.9). Усередині охоплюючого прямокутника записується ім'я компоненту і, можливо, деяка додаткова інформація. Зображення цього символу може трохи варіюватися залежно від характеру асоційованої з компонентом інформації http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html Applet

Рисунок 1.9-Компонент

 

Стереотип (stereotype) Проте час від часу доводиться вводити нову сутність, яка специфічна для словника предметної області, хоча виглядають подібно до примітивних будівельних блоків, вже наявних в мові. Стереотип - це не те ж саме, що батьківський клас відносно узагальнення "батько/нащадок". Точніше було б охарактеризувати його як деякий метатип, оскільки кожен стереотип створює еквівалент нового класу в метамоделі UML. Наприклад потрібно ввести допоміжний тип специфічний для веб-базованих систем – server page (Рис.1.10):

Рисунок 1.10- ServerPage

 

Рисунок 1.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):

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

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

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

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

Пакет Use Case View:

Цей пакет може містити одну або сукупність діаграм варіантів використання (Use Case diagram), які використовуються для концптуального рівня проектування ПЗ. Проклад інтерфейсу цього пакету показано на рис.1. 12:

 

Рисунок 1.12-– Пакет «Use Case View»

 

Також на панелі інструментів діаграми присутні специфічні для цього типу діаграм інструменти: Актори, Варіанти використання, Асоціації, тощо. Для додавання інструментів, які не входять в стандартний набор інструментів діаграми потрібно на панелі інструментів нажати праву кнопку мишки і вибрати останній пункт «Customize…». Після цього з’явиться вікно додавання нового інструменту до діаграми, де можна обрати потрібні інструменти.

Пакет Logical View:

Цей пакет може містити одну або сукупність діаграм логічного рівня проектування ПЗ, а саме: Class diagram (діаграма класів), Statechart diagram (діаграма стану), Activity diagram (діаграма активності), Collaboration diagram (діаграма взаємодії), Sequence diagram (діаграма послідовності) Рис.1. 13, Рис.1.14:

Рисунок 1.13-– Пакет «Logical View»

 

Щоб додати до логічного рівня нову діаграму, потрібно на пакеті Logical View нажати праву кнопку мишки і у меню яке з явиться обрати опцію New, та обрати потрібну діаграму. Для того щоб конвертувати Collaboration diagram (діаграма взаємодії) в Sequence diagram (діаграма послідовності) і навпаки потрібно нажати клавішу F5.

Рисунок 1.14-– Діаграми логічного рівня

 

Пакет Component View

Цей пакет може містити одну або сукупність діаграм фізичного рівня проектування ПЗ, а саме: Component diagram (діаграма компонентів), також там можуть міститися вкладені пакети компонентів ПЗ (Рис. 1.15):

 

Рисунок 1.15-– Пакет «Component View»

 

Deployment View

На цьому рівні міститься діаграма розміщення (Deployment diagram) апаратного і програмного забезпечення системи на етапі фізичного проектування. Для того щоб дістатися специфікації будь-якого елемента будь-якої діаграми треба 2 рази нажати лівою кнопкою мишки на потрібному елементі або діаграмі.

 

Рисунок 1.16-– Діаграма розміщення

 

Розширення UML для проектування Web-додатків (WAE) Розширення для web-додатків (Web Application Extension - WAE) представляє собою набір стереотипів специфічних для розробки web- базованих програмних систем (ПС) класу кліент-сервер. Для використання цього розширення у Case-засобі RR, його потрібно додатково інсталювати (див. посилання в кінці документу). Після інсталяції та запуску середовища RR доступні нові стереотипи (Рис. 1.17).

Класи, що розширюють можливості пакета Logical View (Class diagram)

Class:ServerPage (Серверна сторінка) – екземпляром цього класу є Web-сторінка, яка містить в собі script-сценарії, що виконуються на сервері системи та взаємодіють при цьому із його ресурсами (напр.., з БД та ін.).

Class:ClientPage (Сторінка клієнта) – екземпляром цього класу є Web-сторінка в форматі HTML, яка присутня в браузері клієнтського додатку.

Class:Form (Форма) - екземпляром цього класу є сукупність полів для вводу-виводу даних, що розміщуються на певній сторінці ClientPage.

Class:Frameset (набір фреймів) – це контейнер, що містить дані з декількох Web-сторінок або інший фрейм.

Class:Target (Ціль) - це клас, що позначає деяку область вікна браузера, яка має їм’я та відображає певну Web-сторінку.

Class:ClientScriptObject (об’єкт клієнтських сценарієв) - це клас, що містить деякий набір script-сценарієв, які містяться в окремому файлі та виконуються на запит клієнтського додатку в браузері.

Асоціації, що розширюють типи зв`язків класів в пакеті Logical View

1. Association:Build (Побудова) – це асоціація між певної серверною сторінкою, яка є відповідальною за побудову деякої клієнтської сторінки.

2. Association:Link (Зв’язок) - це асоціація, яка позначає посилання однієї клієнтської сторінки на іншу.

3. Association:Submit (Передача) - це асоціація, що зв’язує класи Form Server і Page, тобто вказує на те, яка серверна сторінка може обробляти дані, що містяться в певній формі.

4. Association:Targeted Link (Цільове посилання) – це посилання на певну сторінку, яка відображається в іншій області Target.

5. Association:Redirect (Переадресація) – це асоціація, яка показує нпрям можливого переходу з однієї сторінки на іншу (для серверних або клієнтських сторінок).

Стереотипи компонентів, що розширюють пакет Component View

1. Component: HTMLPage – це представлення будь-якої Web-сторінки, яка відображається у браузері клієнтського додатку.

2. Component:ASP Page – це представлення Web-сторінки, яка використовує технологію ASP (Active Server Pages).

3. Component:Script Library – це представлення бібліотеки script-сценаріев, які можуть бути використані іншими Web-сторінками.

4. Component:JSP Page - це представлення Web-сторінки, яка використовує технологію JSP (Java Server Pages).

5. Component:Servlet - це представлення Web-сторінки, яка використовує технологію сервлетов (Java servlets).

 

Рисунок 1.17-– Деякі стереотипи WAE

 

В середовищі RR (Рис.1.18) ]х можна додати звичним шляхом – нажати правою кнопкою мишки на панелі інструментів діаграми, вибрати Customize… та обрати потрібний стереотип.

 

Рисунок 1.1-– Нові інструменти WAE

 

5 Хід виконання роботи:

5.1 За завданням викладача підготувати три програми (додаток А) на мовах програмування Java, C# на вибір студента. Вимоги до програм: наявність графічного інтерфейс.

5.2 Розробити діаграму дії (UML activity) для програмного коду.

5.3 Оформити звіт по лабораторной роботі №1.

Питання до захисту роботи:

Які діаграм містяться в пакеті Use Case View Відповідь____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________