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 розширює попередню діаграму. Хоча відносини між акторами і прецедентами на ній опущені, але присутні додаткові прецеденти, які описують важливі, нехай і невидимі для звичайного користувача, елементи поведінки системи. Ця діаграма зручна, оскільки дає можливість користувачам, експертам і розробникам спільно візуалізувати, специфікувати, конструювати і документувати свої рішення щодо функціональних вимог до системи.

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

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

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