Діаграми прецедентів uml 2005 Діаграми прецедентів (use case diagrams)


НазваДіаграми прецедентів uml 2005 Діаграми прецедентів (use case diagrams)
Дата конвертації23.03.2013
Розмір445 b.
ТипПрезентации


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

  • 2005


Діаграми прецедентів (use case diagrams)

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

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

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

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


Складові частини діаграм прецедентів

  • Окрема діаграма прецедентів (як граф) складається з:

    • прецедентів та акторів (як вершин графа);
    • відношень (як дуг графа).


Актори (actors) діаграми прецедентів ПС

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

  • Приклади акторів: клієнт, адміністратор, білінгова система.

  • Важливо зауважити два моменти:

    • Поняття актора несе ролеву ознаку. (Актори, по суті, – це типи: актором є клієнт чи адміністратор, а не Петренко, Шевченко чи Рейган).
    • Акторами можуть виступати інші програмні системи.


Актори (actors)



Як визначати акторів?

  • Як визначати акторів? Простіше спочатку визначити основних акторів.

  • Основні актори це ті актори, які ініціюють взаємодію з програмною системою.

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

  • Далі, розглядаючи відповідальності основних акторів та проектованої системи, можна визначити другорядних акторів:



Прецеденти. Як визначати прецеденти?

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

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

  • Отже, прецеденти мають функціональне забарвлення, “прив'язуючись” до суттєвих цілей основних акторів.

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



Історія терміну “use case”

  • Прецеденти є засобом специфікації дій ПС з точки зору отримання основними акторами деяких суттєвих для них результатів при взаємодії з ПС.

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



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

  • Прецеденти рекомендується документувати ставити їм у відповідність описи – потоки подій.

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

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



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



Опис прецедентів

  • Середній варіант: напівформальна структура, що складається з напівформальних текстів.

  • У цьому випадку можна:

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


Варіант структури опису прецедентів (“потоку подій ”)

  • Для представлення потоку подій може використовуватись наступна структура:

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



Ще одна структура

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


Фрагмент головного потоку подій прецеденту “Зняти гроші” (система “Банкомат”)

  • (Передумова картка сприйнята банкоматом).

  • 1. Банкомат пропонує обрати мову спілкування, а за цим - увести код. Клієнт уводить відповідну інформацію.

  • 2. Система перевіряє код (E-1) і пропонує обрати варіант транзакції.

  • // E-1 альтернативний потік “Невірний код”.

  • 3. Клієнт обирає транзакцію “Зняти гроші” і задає суму, яку він бажає зняти.

  • 4. Система перевіряє наявність відповідної суми на рахунку (E-2).

  • // E-2 альтернативний потік “Немає грошей”.

  • . . .



Пример (www.esc.ru). Снятие денег со счета через банкомат

  • Прецедент. Снятие денег со счета через банкомат

  • Главное действующее лицо. Клиент

  • Масштаб. Банкомат

  • Уровень. Цель пользователя

  • Основной успешный сценарий.

  • 1. Клиент вставляет карточку в банкомат.

  • 2. Банкомат считывает с карточки код банка, номер счета, PIN-код и сверяет код банка и номер счета с данными в банке.

  • 3. Клиент вставляет карточку и вводит PIN-код. Банкомат проверяет совпадение введенного кода и кода на карточке.

  • 4. Клиент выбирает режим "Снять деньги наличными" и вводит сумму, кратную $5.

  • 5. Банкомат соединяется с центральной системой в банке, передает данные о транзакции, получает подтверждение и новый остаток по счету.

  • 6. Банкомат выдает деньги, возвращает карточку и печатает чек, на котором указан новый остаток по счету.

  • 7. Банкомат записывает информацию о транзакции в журнал.



Прецеденти та RUP

  • Протягом першої фази RUP – фази задуму (або початку) з віхою “Вимоги життєвого циклу” (LCO – lifecycle objective) має бути здійснена ідентифікація основних прецедентів та акторів, а також описані найбільш важливі прецеденти. Бажаним вважається також отримання первісної моделі прецедентів, розробленої на 10-20%.

  • Модель прецедентів з ідентифікованими всіма прецедентами та акторами, з описом більшості прецедентів (мінімум на 80%) вимагається на виході другої фази – фази уточнення з віхою “Архітектура життєвого циклу” (LCA – lifecycle architecture) .



Sample. System under discussion: the insurance company (http://alistair.cockburn.us) (1)

  • Primary Actor: The claimant

  • Goal: Get paid for car accident

  • 1. Claimant submits claim with substantiating data.

  • 2. Insurance company verifies claimant owns a valid policy

  • 3. Insurance company assigns agent to examine case

  • 4. Agent verifies all details are within policy guidelines

  • 5. Insurance company pays claimant

  • Extensions:

  • 1a. Submitted data is incomplete:

  • 1a1. Insurance company requests missing information

  • 1a2. Claimant supplies missing information

  • 2a. Claimant does not own a valid policy:

  • 2a1. Insurance company declines claim, notifies claimant, records all this, terminates proceedings.

  • 3a. No agents are available at this time

  • 3a1. (What does the insurance company do here?)



Sample. System under discussion: the insurance company (http://alistair.cockburn.us) (2)

  • 4a. Accident violates basic policy guidelines:

  • 4a1. Insurance company declines claim, notifies claimant, records all this, terminates proceedings.

  • 4b. Accident violates some minor policy guidelines:

  • 4b1. Insurance company begins negotiation with claimant as to degree of payment to be made.

  • Variations:

  • 1. Claimant is

  • a. a person

  • b. another insurance company

  • c. the government

  • 5. Payment is

  • a. by check

  • b. by interbank transfer

  • c. by automatic prepayment of next installment

  • d. by creation and payment of another policy



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

  • Стосовно прецедентів так само, як і у випадку діячів, залучаються відношення на зразок “типи - екземпляри”.

  • Коли користувач (як екземпляр діяча) взаємодіє із системою, виконується (спрацьовує) деякий сценарій (sсепаriо) послідовність деяких дій відповідного прецеденту.

  • “Зняти гроші” – Петренко зняв 20 грн у банкоматі. Ющенко тричі уводив невірний код, і банкомат не повернув йому картку. ...

  • Зрозуміло, що одному прецеденту можуть відповідати одразу кілька різних сценаріїв, і, якщо на потік подій подивитись з “позиції типу”, то його “екземплярами” виступатимуть сценарії.

  • Множини сценаріїв можуть об'єднуватись у типові сценарії – т. з. основні сценарії.

  • Іноді відношення “типи - екземпляри” застосовується також до пари прецедент - набір основних сценаріїв.



Архітектура ПС та прецеденти

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

  • Реальним індикатором стабільності архітектури може бути практика роботи зі сценаріями: якщо зміни в архітектурі малі і залишаються малими, коли вводяться (враховуються) нові основні сценарії, є всі підстави думати, що архітектура стабільна.

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



Використання сценаріїв при плануванні версій

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

  • (Пріоритет – Rank – можна встановлювати для прецедентів при їх специфікації).

  • Г.Буч рекомендує проектувати 5±2 проміжних випусків системи.



Відношення між акторами та прецедентами

  • Зв'язки між акторами та прецедентами – комунікації у діаграмах прецедентів представляються однонаправленими асоціаціями (відповідний стереотип - <>) і зображаються суцільною стрілкою у напрямку від “ініціатора зв'язку”. Це єдиний тип відношень, які можливі між акторами та прецедентами , тому можна цей стереотип і не задавати.



Діаграма прецедентів. (Система “Дипломні роботи”)



Ділове проектування (система “Дипломні роботи”)



Система “Дипломні роботи”

  • Можливі додаткові прецеденти “Відправити електронні листи викладачам”, “Відправити електронні листи студентам”.

  • Мабуть, не підлягає автоматизації діловий прецедент “Багаторазові нагадування куратором студентів про необхідність обрати теми дипломних робіт”.



Використання різних ділових моделей. Артефакти та відповідальність. Кольори

  • Постановка задачі на автоматизацію: “Оприбуткування товару на складі підприємства від продавця”.

  • Документ (вхідний, вихідний) - дія -підрозділ - виконавець.

  • На основі опису бізнесів-процесів з використанням діаграми діяльності (activity diagram) визначаються (і позначаються кольором) діяльності, які варто автоматизувати:

  • 1. Виписує доручення;

  • 2. Виписує прийомний акт у двох екземплярах;

  • 3. Реєструє товар у картотеці;

  • 4. Передає екземпляр акта в бухгалтерію;

  • 5. Одержує прибутковий акт.

  • Е.Б. Золотухина, Р.В. Алфимов Пример описания предметной области с использованием Unified Modeling Language (UML) при разработке программных систем, Interface Ltd., 2001



Відношення узагальнення

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

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

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

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



Відношення узагальнення. Приклад



Організація прецедентів. Відношення залежності

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

  • Найважливішими випадками відношень залежності є відношення включення та розширення зі стереотипами <> та <<extend>>. Вони мають важливе значення стосовно до, мабуть, найголовнішої стратегії у програмування - стратегії повторного використання коду.

  • Зауваження:

  • у Rational Rose ці стереотипи застосовуються не тільки для відношення залежності, а й для однонаправленої асоціації.

  • <> та <<extend>> як залежності не дуже “стикуються” (напрямки стрілок протилежні).



Організація прецедентів. Відношення включення (include)

  • Відношення включення (include) між прецедентами означає, що в деякій “точці” базового прецеденту як складова частина використовується поведінка іншого прецеденту. Прецедент, що включається, ніколи не використовується автономно (з точки зору UML він розглядається як абстрактний, - див. специфікацію прецедентів у Rational Rose, а саме прапорець Abstract), він використовується тільки як частина більш загального прецеденту. Можна вважати, що один прецедент запозичає, використовує поведінку (функціональність) іншого прецеденту (того, що включається, тобто абстрактного). (Зауважимо, що імена абстрактних прецедентів зображаються курсивом).

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



Організація прецедентів. Відношення включення (include)

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

  • Приклад: include(“Перевірити клієнта”).

  • На діаграмі прецедентів відношення включення зображують у вигляді залежності зі стереотипом <<include>> (пунктирна стрілка спрямована від базового прецеденту до того, що включається, абстрактного).



Організація прецедентів. Відношення розширення (extend)

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

  • Відношеннями include та extend можна розділити обов'язкову й необов'язкову поведінку (обов'язкові й необов'язкові підпотоки).

  • Мотивація застосування відношення extend та ж сама, що і у випадку відношення включення include, тобто пов'язана зі стратегією повторного використання коду.



Організація прецедентів. Відношення розширення (extend)

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

  • Приклад: При обранні . . . extend(“Надати квитанцію”).

  • На діаграмі прецедентів відношення розширення зображують у вигляді залежності зі стереотипом extend. Пунктирна стрілка має бути спрямована до базового прецеденту (до прецеденту, який розширюється), від абстрактного (того, що розширює).



Організація прецедентів. Відношення включення і розширення



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

  • Варіанти діаграм прецедентів:

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


До реалізації прецедентів



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



Приклад діаграми прецедентів (http://www.caseclub.ru/articles/use_case.html)



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



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

  • Primary Flow of Events for ‘Enter New Order’ Use Case

  • 1.The salesperson selects the ‘Create New Order’ option from the options menu.

  • 2.System displays the Order Detail form.

  • 3.Salesperson enters the order number, customer, and items ordered.

  • 4.Salesperson saves the order.

  • 5.System creates a new order and saves it to the database.



Приклад. Діаграма прецедентів системи “Банк”



Діаграма діяльності. Ще один приклад. (Terry Quatrani «Introduction to the Unified Modeling Language» - www.rational.com)



Діаграма діяльності. Ще один приклад. (Terry Quatrani «Introduction to the Unified Modeling Language» - www.rational.com)



Діаграма діяльності. Ще один приклад





Діаграма діяльності



Схожі:

Діаграми прецедентів uml 2005 Діаграми прецедентів (use case diagrams) iconПрактичні рекомендації по використанню uml та Rational Rose при проектуванні пс. Діаграми взаємодій. Діаграми класів
Б. Деталізація прецедентів опис потоків подій прецедентів або (як мінімум) основних сценаріїв прецедентів
Діаграми прецедентів uml 2005 Діаграми прецедентів (use case diagrams) iconДіаграми прецедентів uml 2010 Зміст
Організація прецедентів. Відношення залежності між прецедентами. Відношення включення
Діаграми прецедентів uml 2005 Діаграми прецедентів (use case diagrams) iconДіаграми прецедентів uml 2007 План
Організація прецедентів. Відношення залежності між прецедентами. Відношення включення
Діаграми прецедентів uml 2005 Діаграми прецедентів (use case diagrams) iconДіаграми прецедентів uml 2003-2010 Зміст
Організація прецедентів. Відношення залежності між прецедентами. Відношення включення
Діаграми прецедентів uml 2005 Діаграми прецедентів (use case diagrams) iconУніфікована мова моделювання uml. Діаграми прецедентів 2004 Уніфікована мова моделювання uml
У цей же період часу оновлюються версії таких досить розповсюджених методів як: Booch'93, omt-2 (Object Modelling Technique), Fusion,...
Діаграми прецедентів uml 2005 Діаграми прецедентів (use case diagrams) iconВикористання uml та Rational Rose при проектуванні пс. Діаграми взаємодії. Діаграми класів
Для визначення поведінки класів із складною динамікою реагування на події можуть бути задіяні
Діаграми прецедентів uml 2005 Діаграми прецедентів (use case diagrams) iconСтруктуризація прецедентів 2005 Прецеденти та цілі користувачів
Переклад на російську мову опублікований у видавництві "Лорі" М. 2002 р під назвою "Современные методы описания функциональных требований...
Діаграми прецедентів uml 2005 Діаграми прецедентів (use case diagrams) icon2003-2011 Зміст Реалізація прецедентів. Використання діаграм послідовностей

Діаграми прецедентів uml 2005 Діаграми прецедентів (use case diagrams) icon2003-2011 Зміст Реалізація прецедентів. Використання діаграм послідовностей

Діаграми прецедентів uml 2005 Діаграми прецедентів (use case diagrams) icon2003-2011 Зміст Реалізація прецедентів. Використання діаграм послідовностей


Додайте кнопку на своєму сайті:
dok.znaimo.com.ua


База даних захищена авторським правом ©dok.znaimo.com.ua 2013
звернутися до адміністрації
dok.znaimo.com.ua
Головна сторінка