ДО ВИКОНАННЯ ЛАБОРАТОРНИХ РОБІТ

З ДИСЦИПЛІНИ

«АНАЛІЗ ВИМОГ ДО ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ»

для студентів спеціальностей

6.050103 “Програмна інженерія”

Програми професійного спрямування

“Програмне забезпечення систем”

Затверджено

На засіданні кафедри автоматизації

Проектування енергетичних

Процесів та систем

Протокол N_____ від ________

КИЇВ НТУУ "КПІ" 2012

Методичні вказівки до виконання лабораторних робіт з дисципліни «АНАЛІЗ ВИМОГ ДО ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ »

для напряму підготовки 6.050103 “Програмна інженерія”

програми професійного спрямування “Програмне забезпечення систем”

/Укл. І.В. Сегеда. - К.:НТУУ "КПІ", 2012- с.

Навчальне видання

Методичні вказівки

до виконання лабораторних робіт з дисципліни «Аналіз вимог до програмного забезпечення» для студентів спеціальності6.050103 “Програмна інженерія”

Укладач. Сегеда Ірина Василівна

Відповідальний редактор О.С. Лук’яненко

Рецензенти: О.А. Гуржий

С.І. Шаповалова

1. Лабораторна робота '' Проектування моделі предметноїобласті''

Проаналізувати функції та побудувати діаграму прецедентів в середовищі IBM Rational Rose 2003

Тривалість - чотири академічні години.
Мета. Навчитися моделювати вимоги до системи за допомогою діаграм прецедентів в середовищі PowerDesigner.

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

Завдання

1. Спроектувати модель предметної області, модель якої розроблена як індивідуальне завдання і перевірена викладачем;
2. Проаналізувати предметну область і побудувати концептуальну схему головної бази даних системи.
3. Проаналізувати функції і побудувати відповідну діаграму прецедентів.

Теорія

Питання, що допоможуть визначити акторів та прецеденти.

Існує кілька ступенів формалізації прецедента:

1) стислий – анотація на один абзац, зазвичай вона описує лише основний успішний сценарій

2) вільний – неформальний стиль: опис займає кілька абзаців і охоплює кілька сценаріїв.

3) розгорнутий – найбільш докладний стиль опису, містить всі сценарії, передумови, результати,…

Використовуйте наступну специфікацію опису прецедента:

4) ім’я прецедента;

5) ID прецедента;

6) стислий опис;

7) актори, що задіяні в прецеденті (виконавці);

8) передумови (PD: Specification Tab Pre-Conditions);

9) постумови – результати, що отримують по закінченні прецедента (PD: Specification Tab Post-Conditions);

10) основний потік (PD: Specification Tab Action Steps);

11) альтернативні потоки або розширення (PD: Specification Tab Extension Points).

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

Описувати основний сценарій за наступними правилами.

Описувати першу дію сценарію за шаблоном: «1. Прецедент починається, коли <актор> <дія>.»

Наступні кроки: <номер> <хто-небудь> <здійснює деяку дію>.

В розділі основного сценарію описуються три види дій:

1. Взаємодія між виконавцями (та системою)

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. Альтернативний потік починається у будь-який момент часу.

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

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

• можливі альтернативи основному потоку;

• помилки, які можуть виникнути в основному потоці;

• переривання, які можуть трапитися в конкретній точці основного потоку;

• переривання, які можуть відбутися в будь-якій точці основного потоку.

Після деталізації прецедентів можна розширити діаграму прецедентів додатковими зв’язками.

Додаткові відношення на діаграмах прецедентів

Узагальнення акторів

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

Узагальнення прецедентів

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

• успадковувати можливості батьківського прецеденту;

• вводити нові можливості;

• перевизначати (міняти) успадковані можливості.

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

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

Кожний номер кроку в нащадку супроводжується номером кроку відповідного батьківського прецеденту.

Якщо крок нащадка перевизначає крок батька, його номер супроводжується літерою «о» (overridden).

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

Відношення «include»

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

Відношення «include» виносить кроки, загальні для кількох прецедентів, в окремий прецедент, який потім включається в інші.

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

Відношення «extend»

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

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

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

1.	Відкрити case-засіб PowerDesigner. Буде відображено вікно привітання, в ньому можна одразу обрати опцію «Create Project» або закрити це вікно і в головному меню обрати пункт File → New Project.
2.	Створити новий проект. З’явиться діалог, в котрому слід призначити ім’я проекту та папку, де він буде зберігатися. Папку проекту слід назвати наступним чином: <Номер команди> <Перелік фамілій членів команди> Між номером команди та переліком фамілій один пробіл. Ім’я проекту відповідає назві предметної області. Після цих дій робоче вікно буде наступним →.
3.	Створити нову модель. - або File → New Model В діалозі «New Model» клікнути на режим «Model Type». Обрати тип моделі «Object-Oriented Model». - або в контекстному меню проекту (піктограма ) вікна Object Browser обрати New →Object-Oriented Model Обрати тип діаграми = «Use Case Diagram». Задати ім’я моделі (Analysis<Назва предметної області>) та мову автоматичної генерації коду C# 2.0. Натиснути "OK". Автоматично в моделі буде створено діаграму прецедентів, слід надати їй змістовне ім’я (Контекстне меню → Rename): UCD<Назва предметної області >. Після цього одразу збережіть модель в папці проекту.
4.	Додати акторів. В ToolBox на вкладці Standard обрати інструмент «Actor» . Після цього кожний клік на діаграмі буде генерувати нового актора, щоб припинити додавання нових акторів слід клікнути правою кнопкою миші. Щоб змінити ім’я та інші параметри створених акторів, слід обрати в контекстному меню актора пункт «Properties» або клікнути по актору два рази. Необхідно кожному актору призначити змістовне ім’я, наприклад, користувачем системи "Книга рецептів" (RecipeBook) буде "Кухар".
5.	Додати прецеденти. В ToolBox обрати інструмент «Use Case» . Клікнути на полі.
6.	У вікні параметрів прецедента описати прецедент детально:
a.	заповнити вкладку General: визначити назву прецедента і надати йому стислий опис в області Comment.
b.	заповнити вкладку Specification. Ця вкладка має підвкладки.
i.	У підвкладку Pre-Conditions слід занести передумови прецедента;
ii.	Action Steps — основний потік прецедента;
iii.	Extension Points — альтернативні потоки прецедента;
iv.	Exceptions — альтернативні потоки, що можуть виникнути в будь-який момент в наслідок збоїв в системі;
v.	Post-Conditions — результати діяльності прецедента.
7.	Встановити зв’язки між акторами та прецедентами.В PowerDesigner зв’язки бувають трьох типів, для їхнього встановлення існують відповідні інструменти:
a.	актор-прецедент (асоціація) – інструмент ; у властивостях асоціації можна змінити орієнтацію зв’язку: "Primary actor" вказує на те, що актор ініціює прецедент; "Secondary actor" — актор лише отримує результати прецедента;
b.	зв’язок узагальнення – інструмент .
c.	залежність прецедентів – інструмент ; Для усіх будівельних блоків PowerDesigner містить напередвизначені стереотипи, що дозволяють встановити залежності типу «include», «extend» та ін. Якщо таких стереотипів не має у випадаючому списку, можна вписати назву стереотипу у поле Stereotype або створити стереотип.
8.	Створити стереотипи ≪include≫, ≪extend≫. Для створення нових стереотипів використовуються файли розширення, котрі можна створити через Model→Extensions. Клік на пустому рядку таблички створює новий файл розширень.
a.	Стоючи на цьому файлі, слід обрати Proerties (Alt+Enter). Відкриється вікно редагування розширень.
b.	В контекстному меню Profile обрати "Add Metaclasses…" З’явиться вікно, де слід обрати відповідний метаклас: в нашому випадку, необхідно відмітити елемент Dependency. В профілі з’явиться новий елемент Dependency:
c.	В контекстному меню Dependency обрати New → Stereotype. Задати ім’я стереотипу (Name) та бірку (Label), інші параметри залишити незмінними. Після натискання кнопки "Применить" оновлення вступають в силу. Кнопка "ОК" зберігає усі нововведення та закриває вікно редагування розширюючих механізмів. Якщо закрити вікно х-ом або кнопкою "Отмена", нововведення не будуть збережені.
d.	Після створення стереотипів таким чином у випадаючому списку стереотипів вікна властивостей зв’язка залежності (7с) з’являться відповідні елементи.	Файли розширення дозволяють створити також нові метакласи параметри та генерації. В них можна задати нові опції існуючих об’єктів, налаштувати інтерфейс PowerDesigner, виконати інші налаштування моделі в діалозі «Extension properties».
9.	Створити доповнення для акторів, що є системами. Для цього створити стереотип "Actor System" для актора, відповідно пунктам 8а-8с.
a.	В контекстному меню стереотипу "Actor System" обрати New → Custom Symbol. У вікні, що відкриється натиснути кнопку "Modify".
b.	У вкладці "Custom Shape" вікна "Symbol Format" включити опцію "Enable Custom Shape". Обрати бажану форму за допомогою полів "Shae type". Підтвердити зміни кнопкою "OK".
c.	У вікні властивостей стереотипу включити опцію "Toolbox Custom Tool". За допомогою кнопки Select Icon можна обрати зображення інструмента, відповідного створеному стереотипу Actor System. Обрати зображення у вікні, що відкриється. Підтвердити зміни розширень.
d.	Після цього у Toolbox з’явиться додаткова вкладка, що називається так само, як і створений файл розширень. У цій вкладці з’явиться інструмент, відповідний створеному стереотипу Actor System. За допомогою цього інструменту можна створювати в діаграмі акторів за стереотипом Actor System. Такі актори будуть мати форму, визначену в п. 9б, і позначатися стереотипом Actor System. Крім того можна буде задати цей стереотип створеному раніше актору у вікні властивостей цього актора (п4), після цього зображення актора зміниться відповідно до заданої в п. 9б форми.
10.	Створити звіт. Головне меню Report→ Report Wizard На першому кроці гіда по створенню звіту слід задати ім’я звіту та мову.
11.	На другому кроці слід вибрати формат файлу звіту, а також шаблон.
12.	Далі слід обрати структуру інформації, що буде відображатися в звіті.
13.	Після цього можна задати, інформацію про які об’єкти і їхні атрибути, яким чином відображати в звіті. Після чого можна переглянути звіт або одразу згенерувати його чи роздрукувати.

Контрольні питання

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»?

Список рекомендованої літератури

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

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

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

<на зміст>

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

Живите по правилу: МАЛО ЛИ ЧТО НА СВЕТЕ СУЩЕСТВУЕТ? Я неслучайно подчеркиваю, что место в голове ограничено, а информации вокруг много, и что ваше право...

Что способствует осуществлению желаний? Стопроцентная, непоколебимая уверенность в своем...

ЧТО И КАК ПИСАЛИ О МОДЕ В ЖУРНАЛАХ НАЧАЛА XX ВЕКА Первый номер журнала «Аполлон» за 1909 г. начинался, по сути, с программного заявления редакции журнала...

Что делать, если нет взаимности? А теперь спустимся с небес на землю. Приземлились? Продолжаем разговор...

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: