- •Лабораторна робота '' Проектування моделі предметноїобласті''
- •Порядок виконання роботи
- •Контрольні питання
- •Список рекомендованої літератури
- •Діаграма прецедентів Визначення вимог через прецеденти
- •Виявлення акторів
- •Визначення прецедентів
- •Деталізація прецедентів
- •Питання для самоконтролю
- •Узагальнення на діаграмі прецедентів
- •Відношення залежності на діаграмі прецедентів
- •3.3.1. Include "Захист від ботів"
- •Недоліки відношень розширення та включення
- •Лабораторная работа ’’ Розробка технічного завдання, за шаблонами міжнародних стандартів.’’
- •3. Планирование задач проекта в Microsoft Office Project 2007
- •3.1. Создание проекта
- •3.2. Календари проекта
- •3.3. Особенности планирования задач в системе Microsoft Project 2007
- •3.4. Ввод данных о задачах проекта
- •3.5. Контрольные вопросы
- •4. Лабораторна робота ’’ Методика розрахунку трудомісткості розробки та впровадження програмного продукту ’’
- •5. Лабораторная работа ’’ Відладка і тестування проектованого програмного забезпечення’’
- •2.1 Особенности разработки диаграмм компонентов в среде ibm Rational Rose 2003
- •2.2 Тестирование программного средства
- •8. Лабораторная работа ’’ Дослідження характеристик розробленої автоматизованої системи’’
- •1. Задание на самоподготовку
- •2 Задание на лабораторное занятие
Контрольні питання
Що таке UML та UP?
Опишіть структуру UML.
На якиж розрізах (представлениях) системи базується UML?
Які будівельні блоки містить UML?
На яких аксіомах базується UP?
Опишіть основні робочі потоки UP.
Що таке ітерація UP, з чого вона складається?
Опишіть структуру UP.
Що виконується на фазі Початок, Уточнення, Побудова, Впровадження?
Які моделі включає в себе спеціфікація вимог?
Основні етапи робочого потоку виявлення вимог.
Що таке вимоги? Які типи вимог Ви знаєте?
Як організовують вимоги? Які набори критеріїв Ви знаєте?
Як виконується пошук вимог?
За яким алгоритмом зазвичай моделюють прецеденти? Типи акторів.
Визначіть поняття актор, прецедент, контекст.
Яка мета глосарію проекту? З чого він складається
Опишіть, що являє собою основний потік прецедента, як відображається нелінійність потоку?
Співставлення моделі вимог та прецедентів.
Що відображає відношення узагальнення між акторами? Коли його доцільно використовувати?
Який зміст несе відношення узагальнення між прецедентами? Коли його доцільно використовувати?
В чому полягає відношення «include», «exclude»?
Список рекомендованої літератури
Арлоу, Д. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование : 2-е изд. / Д. Арлоу,И. Нейштадт.‑ СПб: Символ Плюс, 2007. – 624 с.
Буч, Г. Язык UML. Руководство пользователя.: Пер. с англ. / Г. Буч , Дж. Рамбо , А. Джекобсон. ‑ М.: ДМК, 2000.‑ 496 с.
Боггс, У. UML и Rational Rose / У. Боггс, М. Боггс.‑ М: Лори, 2008.‑ 600 с.
<на зміст>
Діаграма прецедентів Визначення вимог через прецеденти
Моделювання прецедентів – це форма вироблення вимог. Ідея опису функціональних вимог через прецеденти була запропонована Айваром Якобсоном в 1986 році. Найбільш вагомий внесок в проблему опису прецедентів вніс Алістер Кокбурн.
Основні визначення
Виконавець (актор) – сутність, якій притаманна деяка поведінка, наприклад людина (що ідентифікується своєю роллю), комп’ютерна система або організація, яка взаємодіє з суб’єктом моделювання (системою) але є зовнішньою по відношенню до нього.
Сценарій (екземпляр прецедента) – спеціальна послідовність дій або взаємодій між виконавцем та системою, це конкретний випадок використання системи або один прохід прецедента.
Неформально, прецедент – набір взаємопов’язаних успішних та неуспішних сценаріїв.
Прецедент (за RUP) – набір сценаріїв використання, в якому кожний екземпляр сценарію являє собою послідовність дій, що виконуються системою для досягнення відчутного або значущого для конкретного актора результату.
На етапі аналізу вимог слід розглядати прецедент як «чорний ящик», і зосереджуватися на питанні ЩО повинен виконати прецедент, а не те як він повинен це зробити.
Моделювання прецедентів зазвичай відбувається таким чином:
Встановлюються межі потенційної системи.
Виявляються актори.
Виявляються прецеденти:
визначається прецедент;
визначаються основний та альтернативні потоки.
Попередні кроки повторюються, поки прецеденти, актори і межі системи не стабілізуються.
Зазвичай починають з найзагальнішої оцінки меж системи, щоб позначити область моделювання. Потім всі дії здійснюються ітеративно і часто паралельно. Результат цієї діяльності – модель прецедентів. Ця модель включає 4 компоненти:
• Межа системи – прямокутник, що окреслює прецеденти для позначення краю, або межі, модельованої системи. У UML 2 цю межу називають суб’єктом (контекстом або контекстним класификатором) системи.
• Актори – ролі, що виконуються людьми або сутностями, що використовують систему.
• Прецеденти – те, що актори можуть робити з системою.
• Відношення – значущі відношення між акторами і прецедентами.
Модель прецедентів є основним джерелом об'єктів і класів. Це основні початкові дані для моделювання класів.
