Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Створення та робота з випадками використання в Rational Rose
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
КН
Кафедра:
Кафедра програмного забезпечення
Інформація про роботу
Рік:
2008
Тип роботи:
Лабораторна робота
Предмет:
Інші
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти і науки України
Національний університет "Львівська Політехніка"
Кафедра Програмного
Забезпечення
Лабораторна робота №1
з курсу: «Основи проектування інформаційних систем»
на тему: «Створення та робота з випадками використання в Rational Rose»
Львів 2008
Варіант №14
Мета роботи: Ознайомитися з основними принципами побудови моделей за допомогою програмного засобу Rational Rose, нав читися створювати акторів, випадки використання, відношення між ними та будувати діаграму випадків використання.
Теоретичні відомості.
Основні поняття і постановка модельної задачі.
Робота над моделлю в середовищі Rational Rose починається із загального аналізу проблеми і побудови діаграми варіантів використання, яка відображає функціональне призначення програмної системи, що проектується. Основне завдання діаграми варіантів використання – бути єдиним засобом, який дав би можливість замовнику, кінцевому користувачеві і розробнику спільно обговорювати функціональність і поведінку системи.
Актори.
Актори не є частиною системи – вони являються чимось або кимось, що повинно взаємодіяти з системою.
Актори можуть:
тільки надавати інформацію системі
тільки отримувати інформацію із системи
надавати і отримувати інформацію із системи
Зазвичай акторів визначають із опису задачі або шляхом переговорів із замовниками і експертами. Для визначення акторів може бути використаний наступний набір запитань:
хто використовує систему
хто відповідає за супровід системи
зовнішнє апаратне забезпечення, що використовується системою інші системи, які повинні взаємодіяти із даною системою
Потрібно уважно підходити до питання визначення акторів для системи. Таке визначення зазвичай відбувається ітеративно – перший із затверджених списків акторів як правило далекий від кінцевого. Наприклад, чи є новий студент актором іншого виду, ніж студент, що повернувся із академічної відпустки? Припустимо спочатку зупинились на ствердній відповіді. Наступний крок – вияснити як актор взаємодіє із системою. Якщо новий студент використовує систему не так, як студент, що повернувся, то це різні актори. Якщо ж вони використовують систему однаковим чином – це один і той же актор.
Інший варіант – створення актора для кожної ролі, яку виконує учасник. Тут теж можна отримати надлишковість. Наприклад, немає потреби створювати окремого актора, тому що необхідні засоби, уже закладені для акторів в ролі студентів і викладачів.
Для системи реєстрації курсів можна виділити наступних акторів:
студент
викладач
реєстратор
система оплати.
Випадки використання (Use cases).
За допомогою випадків використання (use cases) моделюється діалог між актором і системою. Іншими словами, вони визначають можливості, які система забезпечує для актора. Набір всіх випадків використання визначає способи її використання.
Протягом довгих років велися дискусії на тему правильності випадків використання. Однією із проблем є рівень їх деталізації. Наскільки детальним повинен він бути? Однозначної відповіді немає. Для визначення рівня деталізації може використовуватись наступне правило: «Випадок використання визначає основний елемент функціональності і відбувається від початку до кінця. Він повинен приносити щось значне для актора».
Наприклад: в системі реєстрації навчальних курсів студент повинен обрати курси для наступного семестру; студент повинен бути закріплений до пропонованих курсів; студенту повинен бути виставлений рахунок. Це три випадки використання чи один? Варто було б організувати як один, тому що функціональність того, що відбувається, визначає те, що відбувається, від початку до кінця.
Друга проблема в тому, як об’єднати функціональність різних дій, які здаються єдиними. Наприклад, реєстратор повинен добавляти курси, видаляти і змінювати їх. Три випадки використання чи один? Знову таки варто було б організувати один, робота з навчальним планом тому, що дії виконуються одним актором (реєстратором) і виконуються над однією сутністю (розкладом).
На основі описаних вище потреб можна виділити наступні випадки використання:
реєстрація на курси
вибір курсів для викладання
запит розкладу курсів
управління інформацією про курси
управління інформацією про викладачів
управління інформацією про студентів
створення каталогу курсів.
Відношення.
Між актором і випадком використання може існувати лише один тип відношення – асоціативне відношення. Асоціативне відношення може бути або одностороннім (від актора до випадку відношення або від випадку відношення до актора), або двостороннім (від актора до випадку відношення і від випадку відношення до актора). Напрямок зв’язку показує, хто є її ініціатором (актор чи випадок використання). Такий тип відношення зображається у вигляді суцільної лінії, що з’єднує елементи, що взаємодіють. Напрямок взаємодії зображається стрілкою.
Існує два типи відношень між випадками використання: включає і доповнює. Різні випадки використання можуть мати фрагменти, що функціонують однаково. Їх зазвичай виділяють в окремий випадок використання, щоб не повторювати декілька разів. Відношення включає створюється тоді, коли один випадок використання використовує інший. Наприклад, кожний випадок використання в системі реєстрації курсів починається з аутентифікації користувача.
Відношення включає зображається у вигляді стрілки з переривчастою лінією з надписом (стереотипом) «include», яка напрямлена від базового випадку використання до використовуваного.
Відношення доповнює використовується для відображення:
додаткових режимів;
режимів, які запускаються тільки при відповідних умовах, наприклад сигнал тривоги;
альтернативних потоків, які запускаються по вибору актора.
Наприклад випадок використання, що контролює рух коробок на конвеєрі, може бути доповнений випадком використання сигналу тривоги при виникненні затору.
Відношення доповнює зображається у вигляді стрілки з переривчастою лінією з надписом (стереотипом) «extend».
Для створення нової пустої моделі в Rational Rose необхідно після запуску програми в вікні майстра створення моделі натиснути на кнопку Cancel. Для переходу на діаграму Use Case необхідно розкрити натисканням лівої кнопки миші розділ Use Case View у вікні Browser і двічі натиснути на піктограму із надписом Main.
Rational Rose дає можливість створювати нові елементи моделі декількома способами:
можна створити нові елементи, використовуючи контекстне меню;
можна створити елементи за допомогою Menu: Tools → Create;
ще можна створити за допомогою панелі інструментів.
Створивши актори і випадки використання першим способом, який був описаний вище, отримуємо наступні випадки використанні і випадки використання.
Для створення діаграми випадків використання потрібно перенести ці елементи на діаграму.
Окрім головної діаграми випадків використання можна створити ще й інші додаткові діаграми випадків використання. Для цього треба в контекстному меню розділу Use Case View обрати New → Use Case Diagram і ввести ім’я нової діаграми в Browser.
Постановка задачі індивідуального завдання.
Інформаційна система обліку поселень та бронювань у готелі. Реєстратор має мати можливість проглянути інформацію про занятість номерів на відповідні числа. Після присвоєння користувачеві номера він повинен отримати від системи оплати рахунок. Користувач має мати можливість замовити послуги (їжу, і т.д.). Відділ, що відповідає за харчування повинен отримати інформацію про замовлення клієнта і організувати сервіс. Відділ сервісу повинен мати змогу отримати список клієнтів готелю, та їх замовлення. Користувач має мати змогу переглянути зайнятість номерів готелю, та забронювати місця.
Практична частина.
Дана інформаційна система складається із п’яти акторів і десяти випадків використання.
Акторами моделі є:
користувач – має можливість переглянути зайнятість номерів на відповідне число і забронювати місця в готелі, після реєстрації має можливість замовляти послуги, за які пізніше отримає рахунок;
реєстратор – повинен перевіряти зайнятість номерів готелю, для того, щоб вести облік місць;
сервісний відділ – формує список клієнтів готелю та отримує замовлення від них;
харчовий відділ – отримує замовлення послуг від користувача і організовує сервіс;
система оплати – присвоює користувачам номери і надсилає їм квитанцію про оплату рахунку.
Випадками використання в цій моделі є:
забронювання місць в готелі – користувач має можливість наперед забронювати місця в готелі;
зайнятість готелю – користувач має право знати, які місця в готелі є зайнятими, для того, щоб мати можливість вибирати між ними;
зайнятість номерів на відповідне число – реєстратор перевіряє, скільки місць в той чи інший день є зайнятими, а які є вільними;
замовлення клієнтів – надсилаються сервісному відділу, для того, щоб організувати сервіс;
замовлення послуг – формуються користувачами і надсилаються харчовому відділу, для організації харчування;
надати користувачу рахунок – формується системою оплати і надається користувачеві за використані послуги;
організація сервісу – формується харчовим відділом для задоволення потреб користувача;
присвоїти користувачу номер – формується системою оплати для реєстрації користувача;
список клієнтів готелю – формуються списки, які надсилаються сервісному відділу для організації сервісу;
контроль користувача – це є додатковий випадок використання, який створений для того, щоб показати, як відбувається контроль реєстрації і оплати послуг користувачами системою оплати.
В результаті побудов і описів ми отримаємо наглядне зображення даної моделі, яка буде містити набір акторів, випадків використання і зв’язків між ними (рис. 1).
Рис.1. Загальна модель інформаційної системи
поселень та бронювань у готелі
Висновки.
Оскільки з кожним роком складність програмного забезпечення зростає, потреба в засобах візуального моделювання і проектування значно збільшується. Все більше програмістів і розробників, які раніше просто писали програмний код, розуміють, що для створення серйозного програмного забезпечення необхідний суворий системний підхід, використання передових методик і засобів розробки великих проектів.
Таку методику і програмний продукт (Rational Rose), які дозволяють в максимальному об’ємі працювати по даній методиці, надає компанія Rational .
В даній роботі було розглянуто процес створення моделі інформаційної системи для поселення і бронювання місць у готелі. Це є ознайомча модель, яка призначена для того, щоб користувач міг наглядно побачити, як працює пакет Rational Rose.
Основним в цій роботі є навчитися визначати акторів, випадки використання та встановлювати зв’язки між ними. Оскільки це є основним у проектуванні інформаційних систем, то без знання цих елементарних речей практично важко далі буде вивчати середовище Rational Rose.
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора