Проектування програмного продукту із застосуванням систем візуального моделювання

* State machine diagram (діаграма станів) - діаграма, на якій представлено кінцевий автомат з простими станами, переходами і композитними станами. Кінцевий автомат (англ. State machine) - специфікація послідовності станів, через які проходить об'єкт або взаємодія у відповідь на події свого життя, а також відповідні дії об'єкта на ці події. Кінцевий автомат прикріплений до вихідного елементу (класу, кооперації або методу) і служить для визначення поведінки його примірників;

* Activity diagram (діаграма описів технологій, процесів, функцій) - діаграма, на якій показано розкладання деякої діяльності на її складові частини. Під діяльністю (англ. activity) розуміється специфікація виконуваного поведінки у вигляді координованого послідовного і паралельного виконання підлеглих елементів - вкладених видів діяльності та окремих дій (англ. action), з'єднаних між собою потоками, що йдуть від виходів одного вузла до входів іншого. Діаграми діяльності використовуються при моделюванні бізнес-процесів, технологічних процесів, послідовних і паралельних обчислень;

* Component diagram (діаграма компонент) - статична структурна діаграма, показує розбиття програмної системи на структурні компоненти та зв'язку (залежності) між компонентами. В якості фізичних компонент можуть виступати файли, бібліотеки, модулі, виконувані файли, пакети і т. п.;

* Deployment diagram (діаграма топології) - служить для моделювання працюючих вузлів (апаратних засобів, англ. Node) і артефактів, розгорнутих на них. В UML 2 на вузлах розвертаються артефакти (англ. artifact), в той час як в UML 1 на вузлах розгорталися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, встановлюється залежність маніфестації;

* Package diagram (діаграма пакетів) - структурна діаграма, основним змістом якої є пакети і відносини між ними. Жорсткого поділу між різними структурними діаграмами не проводиться, тому дане назва пропонується виключно для зручності і не має семантичного значення (пакети та діаграми пакетів можуть бути присутні на інших структурних діаграмах). Діаграми пакетів служать, в першу чергу, для організації елементів у групи за якоюсь ознакою з метою спрощення структури та організації роботи з моделлю системи;

* Object diagram (діаграма об'єктів) - демонструє повний або частковий знімок модельованої системи в заданий момент часу. На діаграмі об'єктів відображаються екземпляри класів (об'єкти) системи з зазначенням поточних значень їх атрибутів і зв'язків між об'єктами;

* Composite structure diagram (діаграма композитної / складовою структури) - статична структурна діаграма, демонструє внутрішню структуру класів і, по можливості, взаємодія елементів (частин) внутрішньої структури класу. Підвидом діаграм композитної структури є діаграми кооперації (Collaboration diagram, введені в UML 2.0), які показують роль і взаємодія класів у рамках кооперації. Кооперації зручні при моделюванні шаблонів проектування. Діаграми композитної структури можуть використовуватися спільно з діаграмами класів;

* Timing diagram (діаграма синхронізації) - альтернативне подання діаграми послідовності, явно показує зміни стану на лінії життя із заданою шкалою часу. Може бути корисна в додатках реального часу;

* Interaction overview diagram (діаграма огляду взаємодії) - різновид діаграми діяльності, що включає фрагменти діаграми послідовності та конструкції потоку управління.

В якості переваг мови UML можна виділити наступне:

* UML об'єктно-орієнтована, в результаті чого методи опису результатів аналізу і проектування семантично близькі до методів програмування на сучасних об'єктно-орієнтованих мовах;

* UML дозволяє описати систему практично з усіх можливих точок зору і різні аспекти поведінки системи;

* Діаграми UML порівняно прості для читання після досить швидкого ознайомлення з його синтаксисом;

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

* UML отримав широке поширення і динамічно розвивається

4.2 Загальна характеристика CASE-засобів Visual Paradigm

CASE-засіб Visual Paradigm з часу своєї появи зазнало серйозну еволюцію і перетворилося на сучасне і потужний засіб аналізу, моделювання та розробки ІС. В Visual Paradigm мова UML став базовою технологією візуалізації та розробки.

У рамках Visual Paradigm існують різні програмні інструментарії, що відрізняються між собою діапазоном реалізованих можливостей. Базовим засобом в даний час залишається Visual Paradigm for UML, яке існує в семи модифікаціях:

* Visual Paradigm Enterprise Edition;

* Visual Paradigm Professional Edition;

* Visual Paradigm Standart Edition;

* Visual Paradigm Modeler Edition;

* Visual Paradigm Personal Edition;

* Visual Paradigm Community Edition;

* Visual Paradigm Viewer Edition;

Visual Paradigm доступно як для операційного середовища типу UNIX, так і для Windows. Найбільш повними можливостями володіє перша з вказаних модифікацій цього кошти. З цих можливостей можна відзначити: реалізацію UML, генерацію кодів більш ніж на 10 різних мовах програмування (Java, C + +, CORBA IDL, PHP, XML Schema, Ada, Python, C #, VB. NET, Object Definition Language (ODL), Flash ActionScript , Delphi, Perl, Objective-C, and Ruby, зворотну генерацію діаграм (реінжинірингу) на основі програмного коду (Java class,. NET dll and exe, JDBC, and Hibernate) і випуск проектної документації.

Visual Paradigm дозволяє генерувати програмний код стандарту MS Visual C + +, забезпечує документування проекту в форматі HTML для Web-публікації і підтримує інтеграцію з іншими інструментами об'єктно-орієнтованої розробки програм, базами даних і з компонентами MS Office.

Можливі практично всі сучасні досягнення в області інформаційних технологій:

* інтеграція з MS Visual Studio, що включає в себе підтримку на рівні прямого і зворотного генерації кодів і діаграм VB, Visual C + +, Visual J + + (ATL-Microsoft Active Template Library, Web-Classes, DHTML, Data Connections);

* безпосередня робота (інжиніринг і реінжиніринг) з виконуваними модулями і бібліотеками форматів EXE, DLL, TLB, OCX;

* повна підтримка CORBA 2.2, включаючи реалізацію технології компонентної розробки додатків CBD (Component-Based Development), мови визначення інтерфейсу IDL (Interface Definition Language) і мови визначення даних DDL (Data Definition Language);

* повна підтримка середовища розробки Java-додатків JDK 1.2, включаючи прямий і зворотний генерацію класів Java формату JAR, а також роботу з файлами форматів CAB і ZIP.

* інтеграція з SDE for Eclipse / WebSphere ®;

* інтеграція з SDE for JBuilder ®;

* інтеграція з SDE for JDeveloper;

* інтеграція з SDE for IntelliJ IDEA ™;

* інтеграція з SDE for WebLogic Workshop ™.

Широкі можливості Visual Paradigm дозволяють:

* проектувати системи будь-якої складності;

* давати розгорнуте уявлення про проект у поєднанні зі редством документування (SoDA);

* проводити кодогенерацію;

* проводити зворотне проектування наявних систем;

* також Visual Paradigm має відкритий для доповнень інтерфейс;

* інтегрується із засобами розробки;

* підтримує мову UML;

* зручний для користувача графічний інтерфейс;

* багатоплатформеність.

4.3 Інтерфейс програми VP-UML

У CASE-засобі VP-UML реалізовані загальноприйняті стандарти на робочий інтерфейс програми, подібно відомим середах візуального програмування.

Після установки VP-UML на комп'ютер користувача запуск цієї програми в середовищі MS Windows призводить до появи на екрані робочого інтерфейсу (рисунок 4.2).



Рисунок 4.2 - Загальний вид робочого інтерфейсу програми Visual Paradigm

Робочий інтерфейс VP-UML складається з різних елементів, основними з яких є:

* головне меню програми;

* вікно діаграми;

* стандартна панель інструментів;

* вікно повідомлень;

* спеціальна панель інструментів.

Розглянемо коротко призначення та основні функції основних елементів.

Головне меню програми

Головне меню програми виконано в загальноприйнятому стандарті і має вигляд, як на рисунку 4.3.

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

Рисунок 4.3 - Зовнішній вигляд головного меню програми

Стандартна панель інструментів

Стандартна панель інструментів розташовується нижче головного меню програми і має вигляд представлений на рисунку 4.4. Деякі з інструментів недоступні (новий проект не має жодних елементів). Стандартна панель інструментів забезпечує швидкий доступ до тих команд меню, які виконуються розробниками найбільш часто.

Рисунок 4.4 - Зовнішній вигляд стандартної панелі інструментів

Вікно браузера

Вікно браузера за замовчуванням розташовується в лівій частині робочого інтерфейсу під панеллю інструментів (рисунок 4.5).

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

Рисунок 4.5 - Зовнішній вигляд браузера

Спеціальна панель інструментів

Спеціальна панель інструментів розташовується між вікном браузера і вікном діаграми в середній частині робочого інтерфейсу. Панель інструментів видозмінюється в залежності від типу діаграми (рисунок 4.6).



Рисунок 4.6 - Зовнішній вигляд спеціальної панелі інструментів для діаграми варіантів використання

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

Вікно діаграми

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



Рисунок 4.7 - Зовнішній вигляд вікна діаграм з різними видами уявлень моделі

Назва діаграми, яка розташовується в даному вікні, вказується в рядку заголовка вікна. Наприклад, на рисунку 4.7 активною є діаграма варіантів використання, тому в рядку заголовка програми розміщується текст Use Case Diagram1 (використовувалося назву діаграми за замовчуванням). Перемикання між діаграмами можна здійснити вибором потрібної закладки вікна з діаграмою або через пункт головного меню програми Window >Navigate. При активізації окремого виду діаграми змінюється зовнішній вигляд спеціальної панелі інструментів, яка настроюється під конкретний вид діаграми.

Вікно документації

Вікно документації за замовчуванням може не бути присутнім на екрані. В цьому випадку воно може бути активізовано через пункт меню View> Panes> Documentation, після чого вікно з'явиться нижче вікна браузера (рисунок 4.8).

Рисунок 4.8 - Зовнішній вигляд вікна документації

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

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

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

4.4 Принцип роботи в VP-UML

Вихідним кроком розробки нового проекту є створення окремих моделей або уявлень в контексті побудови канонічних діаграм. Для нового проекту можна скористатися пунктом головного меню File> New Project. Після цієї операції відкривається додаткове вікно (рисунок 4.9) для збору інформації про новий проект.

Рисунок 4.9 - Заповнення інформації про новий проект

Якщо є готовий проект (файл з розширенням vpp), то його можна відкрити для подальшої модифікації через меню FiIe> Open Project. В цьому випадку програма завантажить існуючий проект з усіма наявними в ньому діаграмами, специфікаціями і документацією.

Після закінчення сеансу роботи над проектом виконану роботу необхідно зберегти у файлі проекту з розширенням vpp. Це можна зробити через меню File> Save Project (Файл> Зберегти проект) або File> Save As (Файл> Зберегти проект як ...). При цьому вся інформація про проект, включаючи діаграми і специфікації елементів, буде збережена в одному файлі.

Як і інші програми, VP-UML дозволяє настроювати глобальні параметри середовища, такі як вибір шрифтів і кольору для представлення різних елементів моделі. Налаштування шрифтів проводиться через меню Tools> Options (Інструменти> Параметри). Характерною особливістю середовища є можливість роботи з символами кирилиці. Однак слід зауважити, що при специфікації елементів моделі з наступною генерацією тексту програмного коду потрібно відразу записувати імена і властивості елементів символами тієї мови, яка підтримується відповідною мовою програмування.

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

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

4.5 Лабораторний практикум

4.5.1 Лабораторная робота № 1 «Діаграма прецедентів»

Мета роботи: освоїти прийоми розробки і побудови діаграми варіантів використання.

Зміст роботи:

1. створення і підготовка бланка діаграми;

2. виділення з виданого завдання основних дійових осіб (акторів);

3. співвіднесення акторів з варіантами взаємодії;

4. розташування акторів і прецедентів використання на діаграмі;

5. створення зв'язків між об'єктами діаграми;

6. збереження побудованої діаграми.

Теоретична частина

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

При моделюванні статичного вигляду системи з точки зору прецедентів діаграми використання зазвичай застосовуються двома способами:

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

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

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

Поняття варіанту використання (use case) вперше ввів Івар Якобсон і надав йому таку значимість, що в даний час варіант використання перетворився в основний елемент розробки та планування проекту.

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

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

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

Для наочного подання варіантів використання в якості основних елементів процесу розробки програмного забезпечення (ПЗ) застосовуються діаграми варіантів використання. На малюнку 4.10 показаний приклад такої діаграми для банкомата (Automated Teller Machine, ATM).

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



Рисунок 4.10 - Приклад діаграми варіантів використання

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

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

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

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

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

* не моделюйте зв'язку між дійовими особами. За визначенням дійові особи перебувають поза сферою дії системи. Це означає, що зв'язки між ними також не належать до її компетенції;

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

Для відображення порядку виконання варіантів використання застосовують діаграми діяльності;

* варіант використання повинен бути ініційований дійовою особою. Це означає, що повинна бути суцільна стрілка, що починається на діючому обличчі і закінчується на варіанті використання.

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

Ідентифікація подій, на які необхідно реагувати, допомагає ідентифікувати варіанти використання.

Варіанти використання починають описувати, що повинна буде робити система. Щоб фактично розробити систему, однак, будуть потрібні більш конкретні деталі. Ці деталі описуються в документі, званому «потік подій» (flow of events). Метою потоку подій є документування процесу обробки даних, що реалізується в рамках варіанту використання. Цей документ детально описує, що будуть робити користувачі системи, і що - сама система.

Хоча потік подій і описується детально, він також не повинен залежати від реалізації. Мета - описати, що буде робити система, а не як вона буде робити це.

Зазвичай потік подій включає:

1. короткий опис;

2. передумови (pre-conditions);

3. основний потік подій;

4. альтернативний потік подій (або кілька альтернативних потоків);

5. післяумови (post-conditions).

У мові UML на діаграмах варіантів використання підтримується кілька типів зв'язків між елементами діаграми. Це зв'язку комунікації (communication), включення (include), розширення (extend) і узагальнення (generalization).

Зв'язок комунікації - це зв'язок між варіантом використання і дійовою особою. Мовою UML зв'язку комунікації показують за допомогою односпрямованої асоціації (суцільної лінії зі стрілкою). Напрямок стрілки дозволяє зрозуміти, хто ініціює комунікацію.

Зв'язок включення застосовується в тих ситуаціях, коли є який-небудь фрагмент поведінки системи, який повторюється більше ніж в одному варіанті використання. За допомогою таких зв'язків зазвичай моделюють багаторазово використовувану функціональність. У прикладі АТМ варіанти використання «Зняти гроші» і «Покласти гроші на рахунок» повинні впізнати (аутентифікувати) клієнта і його ідентифікаційний номер перед тим, як допустити здійснення самої транзакції.

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

Зв'язок розширення застосовується при описі змін в нормальному поведінці системи. Вона дозволяє варіанту використання тільки при необхідності використовувати функціональні можливості іншого.

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

Рисунок 4.11 - Зв'язки використання і розширення

За допомогою зв'язку узагальнення показують, що у кількох дійових осіб є загальні риси. Наприклад, клієнти можуть бути двох типів: корпоративні та індивідуальні. Цей зв'язок можна моделювати за допомогою нотації, показаної на рисунку 4.12.

Рисунок 4.12 - Узагальнення дійової особи

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

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

Типові прийоми моделювання

Моделювання контексту системи

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

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

Моделювання контексту системи складається з наступних кроків:

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

2. організуйте схожих акторів за допомогою відносин узагальнення;

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

4. помістіть акторів на діаграму прецедентів і визначте способи їх зв'язку з прецедентами системи.

Рисунок 4.13 - Моделювання контексту системи

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

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

Моделювання вимог до системи

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

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

Моделювання вимог до системи проводиться таким чином:

1. встановіть контекст системи, ідентифікувавши навколишні її актори;

2. для кожного актора розгляньте поведінку, якого він чекає або вимагає від системи;

3. поіменне ці загальні варіанти поведінки як прецеденти;

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

5. змоделюйте ці прецеденти, актори і відносини між ними на діаграмі прецедентів;

6. доповніть прецеденти примітками, що описують нефункціональні вимоги; деякі з таких приміток можна приєднати до системи в цілому.

Рисунок 4.14 - Моделювання вимог до системи

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

Наприклад, прецедент «Виявлення фальшивих карток» описує поведінку, важливе як для «Торгових підприємств», так і для «субсидують фінансових інститутів». Інший прецедент - «Звіт про стан рахунку» - також описує поведінку, необхідну від системи різними організаціями в своїх контекстах.

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

Така ж методика застосовна і при моделюванні вимог до підсистеми.

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

Після запуску програми VP-UML, для початку побудови діаграми варіантів використання, необхідно на стартовій сторінці обрати діаграму Use Case (рисунок 4.15).

Рисунок 4.15 - Бланк діаграми варіантів взаємодії

На панелі інструментів для даної діаграми присутні всі необхідні умовні позначення об'єктів діаграми (таблиця 4.1).

Таблиця 4.1 - Інструменти спеціальної панелі діаграми схем взаємодії.

Як приклад розглянемо побудову діаграми, показаної на рисунку 4.16. Для нанесення на діаграму дійової особи на панелі інструментів вибирається кнопка із зображенням чоловічка, для варіанту використання використовується кнопка із зображенням еліпса. Після натискання необхідної кнопки (дійової особи або варіанту використання), необхідно перемістити покажчик миші до тієї області, де буде розташовуватися новий об'єкт діаграми, і натиснути ліву кнопку миші. Тепер необхідно ввести назву нового об'єкта.

Рисунок 4.16 - Зв'язок асоціації.

При створенні зв'язку асоціації, за замовчуванням створюється двонаправлений зв'язок (рисунок 4.16). Для того, щоб з неї отримати односпрямовану зв'язок необхідно відключити параметр у властивостях зв'язку (рисунок 4.17).

Рисунок 4.17 - Зв'язок асоціації

Для цього необхідно встановити покажчик миші на бік лінії зв'язку асоціації, протилежну майбутньому вказівником напрямки зв'язку та викликати контекстне меню правою кнопкою миші. У меню, вибрати пункт «Navigable» і потім клацнути по пункту «Unspecified».

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

Рисунок 4.18 - Діаграма варіантів використання

При побудові діаграми варіантів використання необхідно пам'ятати, що кожен варіант використання повинен мати пов'язане з ним короткий опис того, що він буде робити. Для відображення введеної інформації використовується спеціальна область документації варіанту використання (рисунок 4.19).



Рисунок 4.19 - Короткий опис варіанту використання

4.5.2 Лабораторна робота № 2 «Діаграми класів»

Мета роботи: освоїти прийоми розробки і побудови діаграми класів.

Зміст роботи:

1. створення і підготовка бланка діаграми;

2. виділення з виданого завдання основних класів системи;

3. співвіднесення класів системи з атрибутами і операціями;

4. розташування класів на діаграмі;

5. створення зв'язків між об'єктами діаграми;

6. додавання в класи атрибутів і операцій;

7. розстановка множинності;

8. збереження побудованої діаграми.

Теоретична частина

Діаграмою класів (Class diagram) називають діаграму, на якій показано безліч класів, інтерфейсів, кооперацій і відносин між ними. Її зображують у вигляді безлічі вершин і дуг.

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

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

Зазвичай діаграми класів використовуються для таких цілей:

* для моделювання словника системи. Моделювання словника системи передбачає прийняття рішення про те, які абстракції є частиною системи, а які - ні. За допомогою діаграм класів ви можете визначити ці абстракції та їх обов'язки;

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

* для моделювання логічної схеми бази даних. Логічну схему можна уявляти собі як креслення концептуального проекту бази даних. У багатьох сферах діяльності потрібно зберігати стійку (persistent) інформацію в реляційної або об'єктно-орієнтованої базі даних. Моделювати схеми також можна за допомогою діаграм класів.

Стереотипи класів

Стереотипи - це механізм, що дозволяє розділяти класи на категорії. В UML визначено три основних стереотипу класів: Boundary (кордон), Entity (сутність) і Control (управління).

Граничними класами (boundary classes) називаються такі класи, які розташовані на кордоні системи і всього навколишнього середовища. Це екранні форми, звіти, інтерфейси з апаратурою (такий як принтери або сканери) та інтерфейси з іншими системами. Щоб знайти граничні класи, треба досліджувати діаграми варіантів використання. Кожному взаємодії між дійовою особою і варіантом використання повинен відповідати, принаймні, один граничний клас. Саме такий клас дозволяє чинному особі взаємодіяти з системою.

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

Керуючі класи (control classes) відповідають за координацію дій інших класів. Зазвичай у кожного варіанту використання є один керуючий клас, який контролює послідовність подій цього варіанту використання.

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

Клас TransactionManager (менеджер транзакцій) займається координацією повідомлень, які стосуються транзакцій з базою даних. Можуть бути й інші менеджери для роботи з іншими елементами функціонування системи, такими як поділ ресурсів, розподілена обробка даних або обробка помилок.

Крім згаданих вище стереотипів можна створювати і свої власні.

Атрибути

Атрибут - це елемент інформації, пов'язаний з класом. Наприклад, у класу Company (компанія) можуть бути атрибути Name (Назва), Address (Адреса) і NumberOfEmployees (Число службовців).

Так як атрибути містяться всередині класу, вони приховані від інших класів. У зв'язку з цим може знадобитися вказати, які класи мають право читати і змінювати атрибути. Це властивість називається видимістю атрибута (attribute visibility).

У атрибута можна визначити чотири можливі значення цього параметра. Розглянемо кожен з них в контексті приклад (малюнок 4.11). Нехай у нас є клас Employee з атрибутом Address і клас Company:

* Public (загальний, відкритий). Це значення видимості припускає, що атрибут буде видно усіма іншими класами. Будь клас може переглянути або змінити значення атрибута. В такому разі клас Company може змінити значення атрибута Address класу Employee. Відповідно до нотацією UML загальному атрибуту передує знак «+».

* Private (закритий, секретний). Відповідний атрибут не видно ніяким іншим класом. Клас Employee буде знати значення атрибута Address і зможе змінювати його, але клас Company не зможе його ні побачити, ні редагувати. Якщо це знадобиться, він повинен попросити клас Employee переглянути або змінити значення цього атрибута, що зазвичай робиться за допомогою спільних операцій. Закритий атрибут позначається знаком «-» відповідно до нотацією UML.

* Protected (захищений). Такий атрибут доступний тільки самому класу і його нащадкам. Припустимо, що у нас є два різних типи співробітників - з погодинною оплатою і на окладі. Таким чином, ми отримуємо два інших класу HourlyEmp і SalariedEmp, які є нащадками класу Employee. Захищений атрибут Address можна переглянути або змінити з класів Employee, HourlyEmp і SalariedEmp, але не з класу Company. Нотація UML для захищеного атрибута - це знак «#».

* Package or Implementation (пакетний). Припускає, що даний атрибут є загальним, але тільки в межах його пакета. Припустимо, що атрибут Address має пакетну видимість. В такому випадку він може бути змінений з класу Company, тільки якщо цей клас знаходиться в тому ж пакеті. Цей тип видимості не позначається ніяким спеціальним значком.

Рисунок 4.20 - Видимість атрибутів

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

Операції

Операції реалізують пов'язане з класом поведінку. Операція включає три частини - ім'я, параметри і тип значення, що повертається. Параметри - це аргументи, одержувані операцією «на вході». Тип значення, що повертається відноситься до результату дії операції.

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

У мові UML операції мають наступну нотацію:

Ім'я Операції (аргумент1: тип даних аргумента1, аргумент2: тип даних аргумента2, ...): тип значення, що повертається

Слід розглянути чотири різних типи операцій.

* Операції реалізації (implementer operations) реалізують деякі бізнес-функції. Такі операції можна знайти, досліджуючи діаграми взаємодії.

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

* Операції управління (manager operations) керують створенням і знищенням об'єктів. У цю категорію потрапляють конструктори і деструктори класів.

* Операції доступу (access operations) використовуються для перегляду або зміни значення закритих або захищених атрибутів. Нехай, наприклад, у нас є атрибут Salary класу Employee. Ми не хочемо, щоб всі інші класи могли змінювати цей атрибут. Замість цього до класу Employee ми додаємо дві операції доступу - GetSalary і SetSalary. До першої з них, що є загальною, можуть звертатися й інші класи. Вона просто отримує значення атрибута Salary і повертає його викликав її класу.

Операція SetSalary також є загальною, вона допомагає викликав її класу встановити нове значення атрибута Salary. Ця операція може містити будь-які правила і умови перевірки, які необхідно виконати, щоб зарплата могла бути змінена. Такий підхід дає можливість безпечно інкапсулювати атрибути всередині класу, захистивши їх від інших класів, але все ж дозволяє здійснити до них контрольований доступ. Створення операцій Get і Set (отримання і зміни значення) для кожного атрибута класу є стандартом.

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

Щоб ідентифікувати операції, виконайте наступні дії:

1. вивчіть діаграми послідовності і кооперативні діаграми. Більша частина повідомлень на цих діаграмах є операціями реалізації.

Рефлексивні повідомлення будуть допоміжними операціями.

2. розгляньте керуючі операції. Може знадобитися додати конструктори і деструктори.

3. розгляньте операції доступу. Для кожного атрибута класу, з яким повинні будуть працювати інші класи, треба створити операції Get і Set.

Зв'язки

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

Існують чотири типи зв'язків, які можуть бути встановлені між класами:

- асоціації, залежності, агрегації і узагальнення.

Асоціація (association) - це семантична зв'язок між класами. Їх малюють на діаграмі класів у вигляді звичайної лінії (рисунок 4.21).

Рисунок 4.21 - Асоціація

Асоціації можуть бути двонаправленими, як у прикладі, або односпрямованим. Мовою UML двонаправлені асоціації малюють у вигляді простої лінії без стрілок або зі стрілками з обох її сторін. На односпрямованої асоціації зображують тільки одну стрілку, що показує її напрямок.

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

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

Зв'язки залежності (dependency) також відображають зв'язок між класами, але вони завжди однонаправлені і показують, що один клас залежить від визначень, зроблених в іншому. Залежності зображують у вигляді стрілки, проведеної пунктирною лінією (рисунок 4.22).

Рисунок 4.22 - Залежність

При генерації коду для цих класів до них не будуть додаватися нові атрибути.

Однак, будуть створені специфічні для мови оператори, необхідні для підтримки зв'язку. Наприклад, на мові С + + в код увійдуть необхідні оператори # include.

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

Рисунок 4.23 - Агрегація

На додаток до простої агрегації UML вводить сильнішу різновид агрегації, звану композицією. Згідно композиції, об'єкт-частина може належати тільки єдиному цілому, і, крім того, як правило, життєвий цикл частин збігається з циклом цілого: вони живуть і вмирають разом з ним. Будь-яке видалення цілого поширюється на його частини.

Таке каскадне видалення нерідко розглядається як частина визначення агрегації, проте воно завжди мається на увазі в тому випадку, коли множинність ролі становить 1 .. 1; наприклад, якщо потрібно видалити Клієнта, то це видалення має поширитися і на Замовлення (і, в свою чергу, на рядки замовлення).

За допомогою узагальнень (generalization) показують зв'язку спадкування між двома класами. Більшість об'єктно-орієнтованих мов безпосередньо підтримують концепцію наслідування. Вона дозволяє одному класу успадковувати всі атрибути, операції та зв'язку іншого. Мовою UML зв'язку спадкування називають узагальненнями і зображують у вигляді стрілок від класу-нащадка до класу-предка (рисунок 4.24).

Рисунок 4.24 - Узагальнення

Крім успадкованих атрибутів, кожен підклас має свої власні унікальні атрибути, операції та зв'язку.

Множинність (multiplicity) показує, скільки примірників одного класу взаємодіють за допомогою цієї зв'язку з одним примірником іншого класу в даний момент часу.

Наприклад, при розробці системи реєстрації курсів в університеті можна визначити класи Course (курс) і Student (студент). Між ними встановлено зв'язок: у курсів можуть бути студенти, а у студентів - курси. Питання, на який повинен відповісти параметр множинності: «Скільки курсів студент може відвідувати в даний момент? Скільки студентів може за раз відвідувати один курс? »

Так як множинність дає відповідь на обидва ці питання, її індикатори встановлюються на обох кінцях лінії зв'язку. У прикладі реєстрації курсів ми вирішили, що один студент може відвідувати від нуля до чотирьох курсів, а один курс можуть слухати від 10 до 20 студентів. На діаграмі класів це можна зобразити, як показано на рисунку 4.25.

Рисунок 4.25 - Множинність

У мові UML прийняті наступні нотації для позначення множинності (таблиця 4.2).

Таблиця 4.2 - Нотації для позначення множинності.

Зв'язки можна уточнити за допомогою імен зв'язків або рольових імен. Ім'я зв'язку - це зазвичай дієслово або дієслівна фраза, що описує, навіщо вона потрібна. Наприклад, між класом Person (людина) і класом Company (компанія) може існувати асоціація. Можна задати в зв'язку з цим питання, чи є об'єкт класу Person клієнтом компанії, її співробітником або власником? Щоб визначити це, асоціацію можна назвати «employs» (наймає) (рисунок 4.26).

Рисунок 4.26 - Ім'я зв'язку

Імена у зв'язків визначати не обов'язково. Зазвичай це роблять, якщо причина створення зв'язку не очевидна. Ім'я показують біля лінії відповідної зв'язку.

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

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

Рисунок 4.27 - Рольові імена

Типові прийоми моделювання

Моделювання простих кооперацій

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

Таким чином, окрім визначення словника системи потрібно приділити увагу візуалізації, специфікування, конструювання та документування різних способів спільної роботи увійшли до словника сутностей. Для моделювання такого «співпраці» застосовуються діаграми класів.

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

Моделювання кооперації здійснюється наступним чином:

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

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

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

4. заповніть ідентифіковані елементи змістом. Що стосується класів, почніть з правильного розподілу обов'язків; пізніше можна буде перетворити їх в конкретні атрибути та операції.

Як приклад на рисунку 4.28 показані класи, взяті з реалізації автономного робота. Основна увага тут приділена тим класам, які беруть участь у механізмі руху робота по заданій траєкторії. Як видно з малюнка, існує один абстрактний клас «Мотор» з двома конкретними нащадками, «Мотор поворотного Механізму» і «Головний Мотор», які успадковують п'ять операцій їх батьків. Ці два класи, в свою чергу, є частиною класу «Привід». Клас «Агент Траєкторії» пов'язаний відношенням асоціації «один до одного» з класом «Привід» і ставленням «один до багатьох» - з класом «Датчик Сутичок». Для класу «Агент Траєкторії» не показано ні атрибутів, ні операцій, хоча наведені обов'язки.