Побудова діаграми прецедентів

Лабораторная работа, 26 Декабря 2012, автор: пользователь скрыл имя

Описание работы

Мета. Навчитися моделювати вимоги до системи за допомогою діаграм прецедентів за допомогою PowerDesigner.
Дана робота включає і дублює матеріал, котрий детально розглядається в курсі «Аналіз вимог до програмного
забезпечення», що викладається паралельно на третьому курсі. Однак, її не можна виключити з циклу лабораторних
робіт, оскільки на основі отриманих даних буде проводитися подальше моделювання системи.

Скачать полностью (226.67 Кб) Сколько стоит заказать работу?

Работа содержит 1 файл

LabUsecase.pdf

— 237.78 Кб (Скачать)
Page 1
Лабораторна робота № 6. Побудова діаграми прецедентів. 
 Мета. Навчитися моделювати вимоги до системи за допомогою діаграм прецедентів за допомогою PowerDesigner. 
Дана робота включає і дублює матеріал, котрий детально розглядається в курсі «Аналіз вимог до програмного 
забезпечення», що викладається паралельно на третьому курсі. Однак, її не можна виключити з циклу лабораторних 
робіт, оскільки на основі отриманих даних буде проводитися подальше моделювання системи. Також вона дозволяє 
студентам ознайомитися з новим для них середовищем моделювання PowerDesigner під час застосування набутих 
раніше умінь. 
 Завдання 
Побудувати діаграму прецедентів. 

Побудувати звіт. 
 
 Теорія 
 Питання, що допоможуть визначити акторів та прецеденти. 
Визначення акторів 
Визначення прецедентів 
Хто або що використовує систему? 
Які ролі вони граю у взаємодії? 
Хто встановлює систему? 
Хто або що запускає і вимикає систему? 
Хто обслуговує систему? 
Які системи взаємодіють з даною системою? 
Хто або що отримує і надає інформацію системі? 
Чи відбувається що‐небудь в точно встановлений час? 
(Тоді в якості актора можна використовувати час) 
 
Які функціональні можливості знадобляться конкретному 
актору від системи?
Система зберігає і знаходить інформацію? Якщо так, який з 
акторів ініціює цю поведінку?
Що відбувається, коли система змінює стан (наприклад, 
при запуску і виключенні системи)? Хто‐небудь з акторів 
отримує при цьому повідомлення?
Які небудь зовнішні події впливають на систему? Як 
система дізнається про ці події?
Чи взаємодіє система з якою‐небудь зовнішньою 
системою?
Система генерує звіти? 
Використовуйте наступну специфікацію опису прецедента: 
1) ім’я прецедента; 
2) ID прецедента; 
3) стислий опис; 
4) актори, що задіяні в прецеденті (виконавці); 
5) передумови (
 PD: Specification Tab Pre-Conditions
 ); 
6) постумови – результати, що отримують по закінченні прецедента (
 PD: Specification Tab Post-Conditions
 ); 
7) основний потік (
 PD: Specification Tab Action Steps
 ); 
8) альтернативні потоки або розширення (
 PD: Specification Tab Extension Points
 ). 
До цієї специфікації можна додати наступні параметри: зацікавлені актори, спеціальні вимоги, список технологій і типів 
даних, частота використання, відкриті питання. 
Описувати основний сценарій за наступними правилами. 
Описувати першу дію сценарію за шаблоном: «1. Прецедент починається, коли <актор> <дія>.» 
Наступні кроки: <номер> <хто‐небудь> <здійснює деяку дію>. 
В розділі основного сценарію описуються три види дій: 
1. Взаємодія між виконавцями (та системою) 
Page 2

2. Верифікація (зі сторони системи) 
3. Зміна стану системи (наприклад запис або модифікація сутностей) 
Для опису простого розгалуження можна використовувати ключове слово «Якщо», для опису дій, що повторюються 
можна використовувати ключове слово «Повторити Для» (For) <чого?>, а також «Виконувати Поки» (While). 
Приклад 
 Основний потік:
1. Прецедент починається, коли Покупець вибирає опцію «знайти продукт».
2. Система запитує у Покупця критерій пошуку.
3. Покупець вводить запрошуваний критерій.
4. Система шукає продукти, відповідні критерію Покупця.
5. Якщо система знаходить відповідні продукти, тоді
5.1. Для кожного знайденого продукту
5.1.1. Система виводить на екран мініатюрне представлення продукту.
5.1.2. Система виводить на екран короткий опис продукту.
5.1.3. Система виводить на екран ціну продукту.
6. Інакше (Else)
6.1. Система повідомляє Покупця про те, що відповідні продукти не
знайдені.
 
Альтернативні потоки можуть бути ініційовані трьома різними способами: 
1. Альтернативний потік може бути ініційований замість основного потоку. Він ініціюється головним актором і повністю 
заміщає весь прецедент. Тобто його можна виділити в окремий прецедент. 
2. Альтернативний потік може бути ініційований після певного етапу основного потоку. Тоді шаблон початку: 
 1. Альтернативний потік починається після кроку X основного потоку.
3. Альтернативний потік може бути ініційований у будь‐який момент в ході виконання основного потоку (
 PD:
Exceptions
 ). Тоді шаблон початку: 
 1. Альтернативний потік починається у будь-який момент часу.
Такі альтернативні потоки використовуються для моделювання того, що може відбутися в будь‐якій точці основного 
потоку до завершального етапу.
Щоб виявити альтернативні потоки, потрібно уважно вивчити основний потік. На кожному кроці основного потоку 
необхідно шукати: 
• можливі альтернативи основному потоку; 
• помилки, які можуть виникнути в основному потоці; 
• переривання, які можуть трапитися в конкретній точці основного потоку; 
• переривання, які можуть відбутися в будь‐якій точці основного потоку. 
Після деталізації прецедентів можна розширити діаграму прецедентів додатковими зв’язками. 
Додаткові відношення на діаграмах прецедентів 
Узагальнення акторів 
 
Якщо кілька акторів мають схожу поведінку, для спрощення діаграми їх можна узагальнити. Це здійснюється шляхом 
створення нового абстрактного актора, котрий буде відображати ту частину поведінки акторів, що є однаковою для 
них.  
Узагальнення прецедентів 
 
Узагальнення прецедентів виносить поведінку, загальну для одного або більше прецедентів, в батьківський прецедент. 
Нащадки можуть:
• успадковувати можливості батьківського прецеденту;
• вводити нові можливості;
• перевизначати (міняти) успадковані можливості.
Page 3

Дочірній прецедент автоматично успадковує всі можливості свого предка. Слід пам’ятати, що відношення та точки 
розширення прецеденту не можуть бути перевизначені. 
Стандарту документування узагальнення прецедентів не існує, проте часто при цьому діють за наступними правилами: 
Кожний номер кроку в нащадку супроводжується номером кроку відповідного батьківського прецеденту. 
Якщо крок нащадка перевизначає крок батька, його номер супроводжується літерою «о» (overridden). 
Якщо батьківський прецедент не містить потоку подій, або потік не завершено, він вважається абстрактним. Часто 
абстрактні прецеденти використовуються для найбільш загального опису поведінки системи, потік подій в них заміняє 
стислий опис. На практиці опис перевизначення та наслідування подій має ряд недоліків: необхідно використовувати 
додаткові теги, це ускладнює наочність моделі для замовника, при зміні батьківського прецеденту необхідно вручну 
змінювати нащадків. Застосування абстрактних прецедентів дозволяє цього уникнути. 
Відношення «include» 
 
Іноді в різних прецедентах можуть бути описані однакові дії, тобто в прецедентах повторюються частини потоку подій. 
Для уникнення таких повторень використовується відношення «include».  
Відношення «include» виносить кроки, загальні для кількох прецедентів, в окремий прецедент, який потім включається 
в інші. 
Прецедент, що включає в себе інший прецедент називається базовим, а той, що включається – включним. В базовому 
прецеденті необхідно точно вказати місце, де повинна бути включена поведінка включного прецедента. На 
відповідному кроці сценарію пишеться include (<ім’я включного прецеденту>). 
Відношення «extend» 
 
Надає можливість ввести нову поведінку в прецедент. Базовий прецедент надає набір точок розширення, для 
внесення нової поведінки. Розширюючий прецедент надає набір сегментів вставки, котрі можна ввести в місця, 
позначені точками розширення. 
Точки розширення в основному потоці не нумерують, оскільки вони не мають впливати на основний потік. Основний 
потік є завершеним потоком і без розширень, він виступає як каркас для них. На жаль, часто розробники розуміють 
такий зв’язок по своєму, тому краще уникати частого використання відношення «extend». 
 Порядок виконання роботи 
 1.
Відкрити case‐засіб PowerDesigner. 
 
2.
Створити новий проект. File → New Project 
З’явиться діалог, в котрому слід призначити ім’я проекту та 
пакпку, де він буде зберігатися. 
 
3.
Побудувати діаграму прецедентів. 
Fil→New Model 
Вибрати тип моделі = «Object‐Oriented Model», вибрати тип 
діаграми = «Use Case Diagram». 
Задати ім’я моделі та мову автоматичної генерації коду. 
 
4.
Додати акторів. 
В ToolBox обрати інструмент «Actor»  , клікнути на діаграмі. 
Буде створено нового актора, щоб змінити його ім’я та інщі 
параметри слід обрати в контекстному меню актора 
«Properties» або клікнути по актору два рази. 
 
5.
Додати прецеденти.  
І описати їх: заповнити вкладки General, Specification. 
В ToolBox обрати інструмент «Use Case» 
, клікнути на 
діаграмі. Параметри змінюються аналогічно. 
 
Page 4

6.
Встановити зв’язки між акторами та прецедентами. 
В PowerDesigner зв’язки бувають трьох типів, для їхнього 
встановлення існують відповідні інструменти: 

актор‐прецедент – інструмент 
; 

зв’язок прецедентів – інструмент 
; 

зв’язок узагальнення – інструмент 
. 
Для того, щоб задати зв’язки типу include або extend слід 
встановити зв’язок 
 і задати стереотип 
(вбудований в PD) include або extend, відповідно. 
Для зв’язку прецедентів PowerDesigner 
містить напередвизначені стереотипи, що 
дозволяють встановити зв’язки типу 
«include», «extend» та ін. 
Зв’язок узагальнення дозволяє узагальнити 
кілька акторів або прецедентів в один. 
7.
Створити стереотипи. 
Для створення нових стереотипів використовуються файли 
розширення, котрі можна створити через Model→Extensions. 
Файли розширення дозволяють створити також нові метакласи 
параметри та генерації. В них можна задати нові опції існуючих 
об’єктів, налаштувати інтерфейс PowerDesigner, виконати інщі 
налаштування моделі в діалозі «Extension properties». 
8.
Створити звіт. Головне меню Report→ Report Wizard  
На першому кроці гіда по створенню звіту слід задати ім’я звіту 
та мову. 
 
9.
На другому кроці слід вибрати формат файлу звіту, а також 
шаблон. 
10. Далі слід обрати структуру інформації, що буде відображатися в 
звіті. 
Page 5

11. Після цього можна задати, інформацію про які об’єкти і їхні 
атрибути, яким чином відображати в звіті. 
Після чого можна переглянути звіт або одразу згенерувати його 
чи роздрукувати. 
 Контрольні питання 
 1. Що таке UML та UP? 
2. Опишіть структуру UML. 
3. На якиж розрізах (представлениях) системи базується UML?  
4. Які будівельні блоки містить UML? 
5. На яких аксіомах базується UP? 
6. Опишіть основні робочі потоки UP. 
7. Що таке ітерація UP, з чого вона складається? 
8. Опишіть структуру UP. 
9. Що виконується на фазі Початок, Уточнення, Побудова, Впровадження? 
10. Які моделі включає в себе спеціфікація вимог? 
11. Основні етапи робочого потоку виявлення вимог. 
12. Що таке вимоги? Які типи вимог Ви знаєте? 
13. Як організовують вимоги? Які набори критеріїв Ви знаєте? 
14. Як виконується пошук вимог? 
15. За яким алгоритмом зазвичай моделюють прецеденти? Типи акторів. 
16. Визначіть поняття актор, прецедент, контекст. 
17. Яка мета глосарію проекту? З чого він складається 
18. Опишіть, що являє собою основний потік прецедента, як відображається нелінійність потоку? 
19. Співставлення моделі вимог та прецедентів. 
20. Що відображає відношення узагальнення між акторами? Коли його доцільно використовувати? 
21. Який зміст несе відношення узагальнення між прецедентами? Коли його доцільно використовувати? 
22. В чому полягає відношення «include», «exclude»? 
 Оформлення звіту та порядок його подання 
 Для лабораторної роботи потрібен загальний звіт на групу. 
Пакет файлів повинен включати: 

файл проекту PowerDesigner (*.prj), файл моделі вимог (*.rqm), файл об’єктно‐орієнтованої моделі (*.oom). 

файл звіту в форматі rtf або htm. 
 Список рекомендованої літератури  
Арлоу, Д. UML 2 и Унифицированный процесс. Практический объектно‐ориентированный анализ и 
проектирование : 2‐е изд. / Д. Арлоу,И. Нейштадт.‐ СПб: Символ Плюс, 2007. – 624 с. 

Буч, Г. Язык UML. Руководство пользователя.: Пер. с англ. / Г. Буч , Дж. Рамбо , А. Джекобсон. ‐ М.: ДМК, 2000.‐ 
496 с. 

Боггс, У. UML и Rational Rose / У. Боггс, М. Боггс.‐ М: Лори, 2008.‐ 600 с. 

 <на зміст> 
  
 

Информация о работе Побудова діаграми прецедентів

Связанные документы

Побудова навантажувальної діаграми

Побудова робочох і теплової діаграми циклів

Прецедент в английском праве

Принципи побудови логістичних систем в корпораціях

Судебный прецедент в Российской Федерации

Инні діаграми, адитивність, пропорційність, лінійніст

Судебный прецедент в правовой системе Англии

Агресивна поведінка у дітей молодшого шкільного віку

Захист від радіації

Пропозиції від ПОДВ

Похожие темы

В. И. Вернадский

Анализ в менеджменте

Бюджет в экономике

Адаптация в организации

Аудит в бухгалтерском учете

Внебюджетные фонды в РФ