МІНІСТЕРСТВО ОСВІТИ ТА НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ “ЛЬВІВСЬКА ПОЛІТЕХНІКА”

Кафедра ПЗ
Створення та робота з випадками використання в Rational Rose
Методичні матеріали
до лабораторної роботи № 2 з курсу:
“Основи проектування інформаційних систем”
для студентів базового напрямку
6.0804 “Комп’ютерні науки”
ЗАТВЕРДЖЕНО
на засіданні кафедри
“Програмне забезпечення”
Протокол №
від
ЛЬВІВ 2008
Створення та робота з випадками використання в Rational Rose. Методичні матеріали до лабораторної роботи № 2 з курсу: “ Основи проектування інформаційних систем ” для студентів базового напрямку 6.0804 “Комп’ютерні науки”.
Укладачі:
Макар В.М., доцент, к.т.н.
Муха Т.О.., асистент.

Відповідальний за випуск:
Рецензенти:
1. МЕТА РОБОТИ
Ознайомитися з основними принципами побудови моделей за допомогою програмного засобу Rational Rose, навчитися створювати акторів, випадки використання, відношення між ними та будувати діаграму випадків використання.
2.ОСНОВНІ ТЕОРЕТИЧНІ ВІДОМОСТІ
2.1 Основні поняття і постановка модельної задачі
Робота над моделлю в середовищі Rational Rose починається із загального аналізу проблеми і побудови діаграми варіантів використання, яка відображає функціональне призначення програмної системи, що проектується. Основне завдання діаграми варіантів використання – бути єдиним засобом, який дав би можливість замовнику, кінцевому користувачеві і розробнику спільно обговорювати функціональність і поведінку системи.
Модельна задача
Основним прикладом, що буде розглядатися є реєстрація курсів в університеті ESU (Eastern State University).
Після того, як викладачі ESU вирішать, які курси вони будуть вести протягом семестру, служба реєстрації курсів введе інформацію в комп’ютерну систему. Потім для викладачів видрукують сумарний звіт по курсах, які вони читатимуть, а для студентів – каталог курсів.
На цьому етапі студенти заповнюють спеціальну реєстраційну форму, де вказують вибрані курси і віддають її в службу реєстрації. Зазвичай студент підписується на чотири курси, після чого інформація заноситься в комп’ютер. Після цього запускається нічна пакетна програма, яка розподіляє студентів по курсах. При виникненні конфліктної ситуації служба реєстрації уточнює дані студента. Після вдалого розподілення студенту висилається розклад для провірки. Зазвичай, процес реєстрації на курси займає близько тижня, проте в ряді випадків може бути потрібно до двох тижнів, щоб залагодити всі питання. Після цього викладачі отримують список студентів для кожного курсу, який вони будуть читати.
Постановка задачі реєстрації курсів:
На початку кожного семестру студенти можуть запросити каталог курсів, в який включений список предметів, навчання по яких пропонується в даному семестрі. Інформація про курси повинна містити прізвище викладача, назву факультету і короткий опис, який допоможе студентам зробити вибір.
Нова система дозволить студенту здійснити вибір чотирьох курсів, із тих що пропонуються в наступаючому семестрі. Крім того студенту потрібно вказати ще два варіанта на випадок якщо курс буде відмінений або переповнений. На курс не повинно бути записано більше десяти і менше трьох студентів. Курс, на який запишеться менше трьох студентів буде відмінений. Після закінчення реєстрації система реєстрації направляє інформацію в систему оплати для виставлення рахунків студентам.
Викладачі повинні мати можливість он-лайнового доступу до системи для вказання курсів, які вони будуть читати, і для перегляду списку студентів, що записалися.
В кожному семестрі виділяється визначений час, протягом якого студенти можуть міняти свій розклад і отримувати доступ до системи для додавання і видалення вибраних курсів.
Актори
Актори не є частиною системи – вони являються чимось або кимось, що повинно взаємодіяти з системою.
Актори можуть:
тільки надавати інформацію системі
тільки отримувати інформацію із системи
надавати і отримувати інформацію із системи
Зазвичай акторів визначають із опису задачі або шляхом переговорів із замовниками і експертами. Для визначення акторів може бути використаний наступний набір запитань:
хто використовує систему
хто відповідає за супровід системи
зовнішнє апаратне забезпечення, що використовується системою інші системи, які повинні взаємодіяти із даною системою
Потрібно уважно підходити до питання визначення акторів для системи. Таке визначення зазвичай відбувається ітеративно – перший із затверджених списків акторів як правило далекий від кінцевого. Наприклад, чи є новий студент актором іншого виду, ніж студент, що повернувся із академічної відпустки? Припустимо спочатку зупинились на ствердній відповіді. Наступний крок – вияснити як актор взаємодіє із системою. Якщо новий студент використовує систему не так, як студент, що повернувся, то це різні актори. Якщо ж вони використовують систему однаковим чином – це один і той же актор.
Інший варіант – створення актора для кожної ролі, яку виконує учасник. Тут теж можна отримати надлишковість. Наприклад, немає потреби створювати окремого актора, тому що необхідні засоби, уже закладені для акторів в ролі студентів і викладачів.
Для системи реєстрації курсів можна виділити наступних акторів:
студент
викладач
реєстратор
система оплати
Випадки використання (Use cases)
За допомогою випадків використання (use cases) моделюється діалог між актором і системою. Іншими словами, вони визначають можливості, які система забезпечує для актора. Набір всіх випадків використання визначає способи її використання.
Протягом довгих років велися дискусії на тему правильності випадків використання. Однією із проблем є рівень їх деталізації. Наскільки детальним повинен він бути? Однозначної відповіді немає. Для визначення рівня деталізації може використовуватись наступне правило: «Випадок використання визначає основний елемент функціональності і відбувається від початку до кінця. Він повинен приносити щось значне для актора».
Наприклад: в системі реєстрації навчальних курсів студент повинен обрати курси для наступного семестру; студент повинен бути закріплений до пропонованих курсів; студенту повинен бути виставлений рахунок. Це три випадки використання чи один? Варто було б організувати як один, тому що функціональність того, що відбувається, визначає те, що відбувається, від початку до кінця.
Друга проблема в тому, як об’єднати функціональність різних дій, які здаються єдиними. Наприклад, реєстратор повинен добавляти курси, видаляти і змінювати їх. Три випадки використання чи один? Знову таки варто було б організувати один, робота з навчальним планом тому, що дії виконуються одним актором (реєстратором) і виконуються над однією сутністю (розкладом).
На основі описаних вище потреб можна виділити наступні випадки використання:
реєстрація на курси
вибір курсів для викладання
запит розкладу курсів
управління інформацією про курси
управління інформацією про викладачів
управління інформацією про студентів
створення каталогу курсів
Відношення
Між актором і випадком використання може існувати лише один тип відношення – асоціативне відношення. Асоціативне відношення може бути або одностороннім (від актора до випадку відношення або від випадку відношення до актора), або двостороннім (від актора до випадку відношення і від випадку відношення до актора). Напрямок зв’язку показує, хто є її ініціатором (актор чи випадок використання). Такий тип відношення зображається у вигляді суцільної лінії, що з’єднує елементи, що взаємодіють. Напрямок взаємодії зображається стрілкою.
Існує два типи відношень між випадками використання: включає і доповнює. Різні випадки використання можуть мати фрагменти, що функціонують однаково. Їх зазвичай виділяють в окремий випадок використання, щоб не повторювати декілька разів. Відношення включає створюється тоді, коли один випадок використання використовує інший. Наприклад, кожний випадок використання в системі реєстрації курсів починається з аутентифікації користувача.
Відношення включає зображається у вигляді стрілки з переривчастою лінією з надписом (стереотипом) «include», яка напрямлена від базового випадку використання до використовуваного.
Відношення доповнює використовується для відображення:
додаткових режимів;
режимів, які запускаються тільки при відповідних умовах, наприклад сигнал тривоги;
альтернативних потоків, які запускаються по вибору актора.
Наприклад випадок використання, що контролює рух коробок на конвеєрі, може бути доповнений випадком використання сигналу тривоги при виникненні затору.
Відношення доповнює зображається у вигляді стрілки з переривчастою лінією з надписом (стереотипом) «extend».
2.2
Для створення нової пустої моделі в Rational Rose необхідно після запуску програми в вікні майстра створення моделі натиснути на кнопку Cancel. Для переходу на діаграму Use Case необхідно розкрити натисканням лівої кнопки миші розділ Use Case View у вікні Browser і двічі натиснути на піктограму із надписом Main. Результат виконання описаних вище дій зображено на рис.2.1.

Рис.2.1. Активізація Use Case діаграми
Ratio