X Код для використання на сайті:
Ширина px

Скопіюйте цей код і вставте його на свій сайт

X Для завантаження презентації, скористайтесь соціальною кнопкою для рекомендації сервісу SvitPPT Завантажити собі цю презентацію

Презентація на тему:
Діаграми прецедентів UML

Завантажити презентацію

Діаграми прецедентів UML

Завантажити презентацію

Презентація по слайдам:

Слайд 1

Діаграми прецедентів UML 2003-2010 UML. Діаграми прецедентів

Слайд 2

Зміст Складові частини діаграм прецедентів Актори. Як визначати акторів? Прецеденти. Як визначати прецеденти? Опис прецедентів. Потоки подій та сценарії Відношення між акторами та прецедентами Залучення ділових моделей при пошуку прецедентів та акторів Відношення узагальнення Організація прецедентів. Відношення залежності між прецедентами. Відношення включення (include) та розширення (extend) Варіанти діаграм прецедентів UML. Діаграми прецедентів

Слайд 3

Діаграми прецедентів (use case diagrams). Пригадаємо... Діаграми прецедентів є первісним, концептуальним представленням (концептуальною моделлю) програмних систем в процесі проектування й розробки цих систем. Діаграми прецедентів виступають основою подальшої деталізації системи у формі різних логічних і фізичних моделей. (Управління прецедентами є одним з наріжних каменів RUP.) Зокрема, прецеденти допомагають перевіряти й контролювати архітектуру ПС у процесі її розробки. Діаграмами прецедентів: визначаються загальні кордони та контекст ПС; уточнюється зовнішня функціональна поведінка ПС; визначається первісна документація, яка може використовуватись для предметного обговорення ПС розробниками, замовниками, користувачами та іншими зацікавленими сторонами – стейкхолдерами. UML. Діаграми прецедентів

Слайд 4

Ще раз про концептуальність моделі прецедентів Промені зірки RUP представляють основні ідеї, закладені у RUP Модель архітектури “4+1” UML. Діаграми прецедентів

Слайд 5

Складові частини діаграм прецедентів Окрема діаграма прецедентів (як граф) складається з: прецедентів та акторів (як вершин графа); відношень (як дуг графа). UML. Діаграми прецедентів

Слайд 6

Актори (actors) діаграми прецедентів ПС Актор (наголос на першому складі) або діяч – це об'єкт (дехто чи дещо), який буде взаємодіяти з розроблюваною ПС. (Сутності, що знаходяться поза ПС і взаємодіють із нею, складають її контекст. Таким чином, визначення акторів діаграм прецедентів дозволяє моделювати контекст ПС.) Приклади акторів: клієнт, адміністратор, білінгова система. Важливо зауважити два моменти: Поняття актора несе ролеву ознаку. (Актори, по суті, – це типи: актором є клієнт чи адміністратор, а не Петренко, Шевченко чи Буш). Акторами можуть виступати інші програмні системи. Актори позначаються у діаграмах прецедентів стилізованими людськими фігурками. UML. Діаграми прецедентів

Слайд 7

Актори (actors) UML. Діаграми прецедентів

Слайд 8

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

Слайд 9

Приклад діаграми прецедентів ATM (UML и Rational Rose, Уэнди Боггс, Майкл Боггс) UML. Діаграми прецедентів

Слайд 10

Прецеденти. Як визначати прецеденти? Прецеденти є засобом специфікації дій (функцій) системи з точки зору отримання основними акторами деяких суттєвих для них результатів. Простий спосіб виявлення прецедентів полягає в тому, що треба розглянути кожного основного актора та визначити, які суттєві результати (суттєві цілі) він може переслідувати, використовуючи ПС. Отже, прецеденти мають функціональне забарвлення, “прив'язуючись” до суттєвих цілей основних акторів. Прецеденти дозволяють специфікувати функціональну поведінку розроблюваної системи та отримати відповідь на запитання, що має робити системи, проте не визначають реалізацію цієї поведінки системи – не торкаються питань, яким чином відповідні функції реалізуються. Прецеденти зображуються еліпсами. Як правило, для іменування прецедентів використовуються дієслова чи короткі дієслівні фрази (“Створення таблиці”, “Створити таблицю”). UML. Діаграми прецедентів

Слайд 11

Прецеденти. Приклад (банкомат) UML. Діаграми прецедентів

Слайд 12

Історія терміну “use case” Прецеденти є засобом специфікації дій (функцій) ПС з точки зору отримання основними акторами деяких суттєвих для них результатів при взаємодії з ПС. Айвер Якобсон (Ivar Jacobson) у середині 1980-х років придумав шведський термін "anvendningfall", що в приблизному перекладі означає "ситуація використання" чи, англійською, "usage case" ("case of use”). Працюючи над англійським перекладом своєї статті, він вирішив, що термін "usage case" звучить якось не по-англійськи, і переробив його в "use case". UML. Діаграми прецедентів

Слайд 13

Документація прецедентів. Потоки подій Прецеденти рекомендується документувати – ставити їм у відповідність описи – потоки подій. Потоки подій описують поведінку системи в процесі отримання необхідного суттєвого результата (цілі). Опис здійснюється мовою предметної області, а не в термінах реалізації. Коли Айвера Якобсона (Ivar Jacobson) запитали, чи не має він моделі для формального опису варіантів використання, він відповів: ”Звичайно, я зробив таку модель. Є тільки одна проблема – ніхто не хоче нею користуватися". UML. Діаграми прецедентів

Слайд 14

Документація прецедентів. Приєднання файлів UML. Діаграми прецедентів

Слайд 15

Опис прецедентів Найбільш природним є “середній” варіант: напівформальна структура, що складається з напівформальних текстів. У цьому випадку можна: з одного боку, проголосити, що прецеденти мають деяку базову структуру; з іншого боку, засвідчити, що люди мають можливість писати те, що вони хочуть, причому так, як вони вважають за потрібне (ця друга обставина навіть набагато важливіша за першу). UML. Діаграми прецедентів

Слайд 16

Варіант структури опису прецедентів (“потоку подій ”) Для представлення потоку подій може використовуватись наступна структура: заголовок (наприклад, “Потік подій для прецедента ”); короткий опис потоку (наприклад, “Дозволяє клієнту зняти гроші з його рахунку”); передумови (pre-conditions); //послідовність виконання прецедентів! головний потік подій та, можливо, його підпотоки; альтернативні потоки подій; постумови (post-conditions). (Перед-, постумови важливі для генерації сценаріїв тестів). UML. Діаграми прецедентів

Слайд 17

Ще одна структура опису прецедентів X. Заголовок (наприклад, “Потік подій для прецедента ”); // X - номер потоку (прецедента) X.1. Передумови (pre-conditions). X.2. Головний потік. X.3. Підпотоки (S-1, S-2, …). X.4. Альтернативні потоки (E-1, E-2, ). X.5. Постумови (post-conditions). UML. Діаграми прецедентів

Слайд 18

Фрагмент головного потоку подій прецедента “Зняти гроші” (система “Банкомат”) (Передумова – картка сприйнята банкоматом). 1. Банкомат пропонує обрати мову спілкування, а за цим - увести код. Клієнт уводить відповідну інформацію. 2. Система перевіряє код (E-1) і пропонує обрати варіант транзакції. // E-1 – альтернативний потік “Невірний код”. 3. Клієнт обирає транзакцію “Зняти гроші” і задає суму, яку він бажає зняти. 4. Система перевіряє наявність відповідної суми на рахунку (E-2). // E-2 – альтернативний потік “Немає достатньо грошей”. . . . UML. Діаграми прецедентів

Слайд 19

Потоки подій та сценарії як типи й екземпляри Для прецедентів так само, як і для акторів, природним є використання відношень на зразок “типи - екземпляри”. Коли користувач Петренко (як екземпляр діяча) взаємодіє із системою, виконується (спрацьовує) деякий сценарій (sсепаriо). Приклад. Прецедент “Зняти гроші”. Сценарії: Петренко зняв 20 грн. у банкоматі. Ющенко тричі уводив невірний код, і банкомат не повернув йому картку. ... Зрозуміло, що одному прецеденту можуть відповідати кілька (як правило багато) різних сценаріїв, і, якщо на потік подій подивитись з “позиції типу”, то його “екземплярами” виступатимуть сценарії. Множини сценаріїв можуть об'єднуватись у типові сценарії – т. з. основні сценарії. UML. Діаграми прецедентів

Слайд 20

Прецеденти як набори основних сценаріїв Прецедент можна розглядати як набір основних сценаріїв. І не завжди (не у кожному сценарії) відповідна ціль виявляється досяжною. (Приклад: людина вводить невірний пароль при одержанні грошей з банкомата. А якщо картка крадена! Система має переконатися, що людині можна спілкуватися з банкоматом.) Отже, опис прецедента іноді доцільно поділяти дві частини: опис послідовності дій, коли “усе йде, як треба” та опис того, як поводиться система, коли відбувається якийсь збій. При цьому найбільшу практичну користь, яку можна отримати з опису варіанта використання, являє собою не основний результативний сценарій, а опис саме альтернативної поведінки, коли бажаний (цільовий) результат не досягається. Практика свідчить, що основний сценарій може займати лише від чверті до однієї десятої всього опису прецедента. UML. Діаграми прецедентів

Слайд 21

Сценарії, зібрані за цілями (“смугасті штани”) Актори позначаються на діаграмі прецедентів стилізованими людськими фігурками. UML. Діаграми прецедентів