Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Моделювання прецедентів
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
Не вказано
Факультет:
Комп’ютерні науки
Кафедра:
Не вказано
Інформація про роботу
Рік:
2012
Тип роботи:
Методичні вказівки до лабораторної роботи
Предмет:
Основи автоматизованого проектування складних об’єктів і систем
Частина тексту файла (без зображень, графіків і формул):
Методичні вказівки
до лабораторної роботи № 2
«Моделювання прецедентів»
з дисципліни
«Основи автоматизованого проектування складних об’єктів та систем»
для студентів базового напрямку підготовки по спеціальності
“Комп’ютерні науки” (шифр 0804)
Львів-2012
Методичні вказівки до лабораторної роботи № 2 “Моделювання прецедентів” з дисципліни “Основи автоматизованого проектування складних об’єктів та систем ” для студентів спеціальності - шифр 0804 “Комп’ютерні науки” Укл. Скрибайло-Леськів Д.Ю.,
Львів: Національний університет “Львівська політехніка”, 2012.
Методичні вказівки обговорено та схвалено на засіданні кафедри АСУ Протокол № ___________ від «___»___________2012 р.
Завідувач кафедрою АСУ ______________ Медиковський М.О.
Методичні вказівки обговорено та схвалено на засіданні методичної комісії базового напрямку підготовки
Протокол № ___________ від «___»___________2012 р.
Лабораторна робота № 2
Моделювання прецедентів
Мета: Оволодіти навичками моделювання діаграм прецедентів та навчитися реалізовувати їх.
Завдання: Здійснити моделювання діаграм прецедентів за допомогою середовища розробки діаграм Enterprise Architect.
1. Теоретичні відомості
Прецедентом (use case) називається опис множини послідовностей дій (включаючи варіанти), що виконуються системою для того, щоб актор міг отримати певний результат. Графічно прецедент зображується у вигляді еліпса.
Діаграма прецедентів в UML - це діаграма, на якій зображено відношення між акторами та прецедентами в системі. Також перекладається як діаграма варіантів використання.
Діаграми прецедентів або діаграми варіантів використання (use case diagrams). Такі діаграми описують функціональність, яка буде надаватись користувачам системи, котра проектується. Представляються шляхом використання прецедентів та акторів, а також відношень між ними. Набір усіх прецедентів діаграми фактично визначає функціональні вимоги, за допомогою яких може бути сформульоване технічне завдання.
Прецеденти є основним засобом визначення необхідної поведінки системи. Як правило, вони використовуються для опису вимог до системи, тобто, що має робити система. Основними поняттями, пов'язаними з прецедентами є актори, прецеденти (варіанти використання), та суб'єкт.
Суб'єкт — це система, що розглядається, і до якої відносяться прецеденти. Користувачів та будь-які інші системи, що можуть взаємодіяти із суб'єктом, представлено як акторів. Актори завжди представляють сутності, що знаходяться за межами системи. Поведінка суб'єкта описується одним або більше прецедентами, що визначаються відповідно до потреб акторів. Строго кажучи, термін «прецедент» означає тип прецедента. Екземпляр прецедента означає існування поведінки, що відповідає вимогам типу прецедента. Часто такі екземпляри описуються специфікаціями взаємодії.
Діаграма прецедентів є графом, що складається з множини акторів, прецедентів (варіантів використання) обмежених границею системи (прямокутник), асоціацій між акторами та прецедентами, відношень серед прецедентів, та відношень узагальнення між акторами. Діаграми прецедентів відображають елементи моделі варіантів використання.
Прецеденти є засобом специфікації системи с точки зору отримання діячами деяких істотних для них результатів. Тобто, прецедентами задаються сервіси (функціональні можливості) системи, якими може скористатись діяч.
Як саме визначати прецеденти? Відповідь може бути такою. Стосовно кожного діяча слід розглянути типові (узагальнюючі) варіанти сервісів (функцій), які мають підтримуватись системою і якими може скористатись діяч. (Можливо, для цього доведеться спочатку провести ділове моделювання.) Виділеним сервісам і мають відповідати прецеденти.
Типові приклади застосування
Діаграми прецедентів, або варіантів використання, застосовують для моделювання статичного виду системи з погляду прецедентів. Цей вигляд охоплює головним чином поведінку системи, тобто видимі ззовні сервіси, що надаються системою в контексті її оточення.
При моделюванні статичного виду системи з погляду прецедентів діаграми використання зазвичай застосовуються двома способами:
для моделювання контексту системи.
Моделювання контексту має на увазі, що ми обводимо систему уявною лінією і виявляємо актори, які знаходяться за цією лінією і взаємодіють з системою.
Діаграми прецедентів потрібні на цьому етапі для ідентифікації акторів і семантики їх ролей;
для моделювання вимог до системи.
Моделювання вимог до системи припускає вказівку на те, що система повинна робити (з погляду зовнішнього спостерігача), незалежно від того, як вона винна це робити. Діаграми прецедентів потрібні тут для специфікації бажаної поведінки системи. Вони дозволяють розглядати всю систему як "чорний ящик": ви бачите все, що знаходиться поза нею, спостерігаєте за її реакцією на події, але нічого не знаєте про її внутрішній устрій.
Будь-який прецедент повинен мати ім'я, що відрізняє його від інших прецедентів. Воно повинне бути унікальне усередині охоплюючого пакету. Ім'я прецеденту є текстовим рядком. Узяте само по собі, воно називається простим ім'ям. До складеного імені спереду додано ім'я пакету, в якому він знаходиться. Зазвичай при зображенні прецеденту указують тільки його ім'я, як показано на рис.1.
Рис.1. Прості і складені імена
Примітка: Ім'я прецеденту може складатися з будь-якого числа букв, цифр і деяких розділових знаків (за винятком таких, як двокрапки, які застосовуються для відділення імені прецеденту від імені охоплюючого пакету). Ім'я може займати декілька рядків. На практиці для іменування прецедентів використовують короткі дієслівні фрази в активній формі, що позначають деяку поведінку і узяті із словника модельованої системи.
Прецеденти і актори
Актор є зв'язною множиною ролей, які користувачі прецедентів виконують під час взаємодії з ними. Зазвичай актор представляє роль, яку в даній системі грає людина, апаратний пристрій або навіть інша система. Наприклад, якщо ви працюєте в банку, то можете грати роль «Співробітник кредитного відділу». Якщо в цьому банку у вас є рахунок, ви граєте роль «Клієнта». Таким чином, екземпляр актора є конкретною особою, що взаємодіє з системою певним чином. Хоча ви і використовуєте акторів в своїх моделях, вони не є частиною системи, оскільки існують поза нею.
Як показано на рис.2 акторів зображають у вигляді людських фігурок. Можна визначити загальні типи акторів (наприклад, «Клієнт») і потім спеціалізувати їх (наприклад, створивши різновид «Комерційний клієнт» за допомогою відносин узагальнення).
Рис.2
Прецеденти і потік подій
Можна специфікувати поведінку прецеденту шляхом опису потоку подій в текстовій формі - у вигляді, зрозумілому для стороннього читача. У опис необхідно включити вказівку на те, як і коли прецедент починається і закінчується, коли він взаємодіє з акторами і якими об'єктами вони обмінюються. Важливо позначити також основний і альтернативний потоки поведінки системи.
Наприклад, в контексті банкомату можна було б таким чином описати прецедент Validate user (Перевірити користувача).
Основний потік подій. Прецедент починається, коли система запрошує у клієнта його персональний ідентифікаційний номер (PIN). Клієнт (Customer) може ввести його з клавіатури. Завершується введення натисненням клавіші Enter. Після цього система перевіряє введений PIN і, якщо він правильний, підтверджує введення. На цьому прецедент закінчується.
Винятковий потік подій. Клієнт може припинити транзакцію у будь-який момент, натиснувши клавішу Cancel. Ця дія починає прецедент заново. Ніяких змін на рахунку клієнта на проводиться.
Винятковий потік подій. Клієнт може у будь-який момент до натиснення клавіші Enter стерти свій PIN і ввести новий.
Винятковий потік подій. Якщо клієнт ввів неправильний PIN, прецедент запускається спочатку. Якщо це відбувається три рази підряд, система відміняє всю транзакцію і не дозволяє даному клієнтові знову почати роботу з банкоматом протягом 60 секунд.
Діаграми варіантів використання є первісним, концептуальним представленням (концептуальною моделлю) системи в процесі її проектування й розробки. Вони виступають основою подальшої деталізації системи у формі логічних і фізичних моделей.
Розробка діаграм варіантів використання переслідує такі конкретні цілі:
визначити загальні кордони та контекст системи;
сформулювати загальні вимоги до функціональної поведінки системи;
отримати первісну документацію для предметної взаємодії розробників системи з її замовниками й користувачами.
Діаграми варіантів використання створюються на етапі аналізу вимог до системи.
Рис.3. Створення діаграми прецедентів в EA
Прецедентам рекомендується співставляти потоки подій, які описують поведінку системи в процесі отримання необхідного результату.
Потоки подій описуються мовою предметної області, а не в термінах реалізації.
Найчастіше для опису потоку подій пропонується наступна структура:
заголовок (наприклад, “Потік подій для прецеденту <Зняти гроші>”);
короткий опис потоку (наприклад, “Дозволяє клієнту зняти гроші з його рахунку”);
передумови (pre-conditions) (діаграми прецедентів не дозволяють відображати послідовний характер використання прецедентів!);
головний потік подій та, можливо, його підпотоки;
альтернативні потоки подій;
постумови (post-conditions).
Діаграма прецедентів. (Банкомат)
Зв'язки між акторами та прецедентами (комунікації) на діаграмах прецедентів представляються однонаправленими асоціаціями (відповідний стереотип - <<communication>>) і зображаються суцільною стрілкою у напрямку від “ініціатора зв'язку”. Це єдиний тип діаграмних відношень, які можливі між акторами та прецедентами, тому можна цей стереотип і не задавати.
Рис.4. Зв’язки між актором і прецедентами
Для визначення діячів, необхідно розглянути ситуації, типові для використання системи. Користувачами системи, як уже згадувалось вище, не обов'язково мають бути люди; це можуть бути інші (зовнішні) системи, що звертаються до даної системи чи до яких звертається дана система.
Варто зауважити, що між діячами й користувачами системи є важлива відмінність: діячі, по суті, – це типи, тоді як користувачів слід розглядати як конкретних екземплярів таких типів.
Рис. 5. Приклад діаграми прецедентів
Сутності, що знаходяться поза системою і взаємодіють із нею, складають її контекст. Таким чином, визначення діячів діаграм прецедентів дозволяє моделювати контекст системи.
Можливі додаткові прецеденти “Відправити електронні листи викладачам”, “Відправити електронні листи студентам”.
Мабуть, не підлягає автоматизації діловий прецедент “Багаторазові нагадування куратором студентів про необхідність обрати теми дипломних робіт”.
Стосовно прецедентів так само, як і у випадку діячів, залучаються поняття на зразок “типи - екземпляри”.
Коли користувач (як екземпляр діяча) взаємодіє із системою, виконується (спрацьовує) деякий сценарій (sсепаriо) – послідовність деяких дій відповідного прецеденту.
Зрозуміло, що одному прецеденту можуть відповідати одразу кілька різних сценаріїв, і, якщо на потік подій подивитись з “позиції типу”, то його “екземплярами” виступатимуть сценарії.
Іноді відношення “типи - екземпляри” застосовується також до характеристики пар прецеденти - сценарії.
Архітектура системи розробляється при розгляді “архітектурно істотних” сценаріїв (для підмножини прецедентів, що представляють найбільш перспективну поведінку, яку повинна підтримати система).
Гарним індикатором стабільності архітектури може бути досвід роботи з архітектурою: якщо зміни в архітектурі малі і залишаються малими, коли вводяться нові сценарії, є всі підстави думати, що архітектура стабільна.
Та найголовніше - саме до сценаріїв застосовуються подальші кроки на шляху моделювання, використовуючи діаграми взаємодії (у першу чергу - діаграми послідовності), а також при потребі діаграми діяльності та діаграми станів.
Організація прецедентів
Для організації прецедентів їх групують в пакети, так само як і класи.
Крім того, прецеденти можна організувати, визначивши між ними відносини узагальнення, включення і розширення. Ці відносини застосовують, щоб виділити деяку загальну поведінку (витягуючи його з інших прецедентів, які його включають) або, навпаки, варіації (помістивши таку поведінку в інші прецеденти, які його розширюють).
Використовуйте елементи діаграми випадку
Використовуйте з'єднувачі діаграми випадку
Актор (Actor)
Використання (Use)
Використання випадку(Use case)
Партнер (Associate)
Співпраця (Collaboration)
Виведення (Generalize)
Межа (Boundary)
Включення (Include)
Пакет (Package)
Потяг (Extend)
Усвідомлення (Realize)
Заклик (Invokes)
Передування (Precedes)
Між прецедентами можуть існувати семантичні залежності, які доцільно представляти у діаграмах (для зображення відношень залежностей використовуються пунктирні стрілки).
Найважливішими випадками відношень залежності є відношення включення та розширення. Вони мають важливе значення стосовно до, мабуть, найголовнішої стратегії у програмування - стратегії повторного використання коду.
Відношення включення (include) між прецедентами означає, що в деякій “точці” базового прецеденту як складова частина використовується поведінка іншого прецеденту. Прецедент, що включається, ніколи не використовується автономно (з точки зору UML він розглядається як абстрактний, - див. специфікацію прецедентів в UML, а саме прапорець Abstract), він використовується тільки як частина більш загального прецеденту. Можна вважати, що один прецедент запозичає, використовує поведінку (функціональність) іншого прецеденту (того, що включаються, абстрактного). (Зауважимо, що імена абстрактних прецедентів позначаються курсивом).
Завдяки наявності відношення включення вдається уникнути багаторазового опису потоків подій, оскільки спільну поведінку можна описати у вигляді самостійної поведінки, що включається в інші.
Щоб специфікувати місце в потоці подій, де саме базовий прецедент включає поведінку іншого, просто пишеться слово include, за яким іде ім'я прецеденту, що включається.
Приклад: include(“Перевірити клієнта”).
На діаграмі прецедентів відношення включення зображують у вигляді залежності зі стереотипом include (пунктирна стрілка спрямована від базового прецеденту до того, що включається, абстрактного).
Рис.6. Приклад відношення включення
Відношення розширення (extend) застосовують для моделювання таких частин прецеденту, які користувач сприймає як необов'язкову поведінку системи. Тим самим можна розділити обов'язкову й необов'язкову поведінку. Відношення розширення використовується також для моделювання окремих субпотоків, які виконуються тільки при певних обставинах.
Мотивації цього відношення ті ж самі, що і у випадку відношення включення.
У потоці подій вказуються точки розширення. Потік може містити кілька точок розширення, ідентифікованих іменем прецеденту, що використовується для розширення.
Приклад: При обранні . . . extend(“Надати квитанцію”).
На діаграмі прецедентів відношення розширення зображують у вигляді залежності зі стереотипом extend. Пунктирна стрілка має бути спрямована до базового прецеденту (до прецеденту, який розширюється), від абстрактного (того, що розширює).
Рис.7. Приклад відношення розширення
Відношення узагальнення (generalize) між прецедентами аналогічно відносинам узагальнення між класами. Це означає, що прецедент-нащадок успадковує поведінку і семантику свого батька, може заміняти його або доповнювати його поведінку, а крім того, може бути підставлений усюди, де з'являється його батько (як батько, так і нащадок можуть мати конкретні екземпляри). Наприклад, в банківській системі можлива наявність прецеденту «Перевірити Клієнта», який відповідає за перевірку особи клієнта. Він може мати двох спеціалізованих нащадків («Перевірити пароль» І «Сканування сітківки»). Обидва нащадки поводяться так само, як прецедент «Перевірити клієнта», і можуть використовуватися скрізь, де використовується їх батько, але при цьому кожен з них додає і свою власну поведінку (перший перевіряє текстовий пароль, а другий - малюнок сітківки ока).
Рис.8. Приклад відношення узагальнення у ЕА
Примітка: Організація прецедентів шляхом виділення загальної поведінки (відношення включення) і різних варіацій (відношення розширення) є важливою складовою частиною процесу розробки простого, збалансованого і зрозумілого набору прецедентів системи.
Діаграма прецедентів є одним з п'яти типів діаграм, вживаних в UML для моделювання динамічних аспектів системи. Діаграми прецедентів грають основну роль в моделюванні поведінки системи, підсистеми або класу. Кожна така діаграма показує безліч прецедентів, акторів і відносини між ними.
Рис.9 Приклад діаграми прецедентів з використанням відношення розширення у середовищі ЕА
Діаграми прецедентів мають велике значення для візуалізації, специфікації і документування поведінки елементу. Вони полегшують розуміння систем, підсистем або класів, представляючи погляд ззовні на те, як дані елементи можуть бути використані у відповідному контексті. Крім того, такі діаграми важливі для тестування виконуваних систем в процесі прямого проектування і для розуміння їх внутрішнього устрою при зворотному проектуванні.
У мові UML діаграми прецедентів якраз і дозволяють візуалізувати поведінку системи, підсистеми або класу, щоб користувачі могли зрозуміти як їх використовувати, а розробники - реалізувати відповідний елемент. На рис.10 приводиться діаграма, що описує використання стільникового телефону.
Рис.10. Діаграма прецедентів для пристрою «Мобільний телефон»
Рис.11. Діаграма прецедентів для Internet - системи замовлення квитків у театр.
Рекомендації до створення діаграм прецедентів.
Створюючи діаграми прецедентів в UML, пам'ятайте, що кожна з них є всього лише графічним представленням статичного виду системи з погляду прецедентів. Це означає, що жодна діаграма прецедентів, узята окремо, не може, та і не повинна охоплювати весь цей вигляд цілком. В сукупності діаграми прецедентів дають повне уявлення про вид системи з погляду прецедентів, а кожна з них окремо - тільки про один з його аспектів.
Добре структурована діаграма прецедентів володіє наступними властивостями:
акцентує увагу тільки на одному аспекті статичного виду системи з погляду прецедентів;
містить тільки такі прецеденти і акторів, які важливі для розуміння цього аспекту;
містить тільки такі деталі, які відповідають даному рівню абстракції; показує тільки ті доповнення (наприклад, точки розширення), які необхідні для розуміння системи;
містить просторово організовані елементи так, що семантично близька суть фізично розташована поряд;
містить примітки і колір, щоби привернути увагу читача до важливих особливостей діаграми;
не показує дуже багато видів відношень. У загальному випадку, якщо є багато складних відносин включення і розширення, їх виділяють в окрему діаграму.
2. Приклад моделювання діаграми прецедентів на тему: «Iнформаційно-аналітична система «Реєстратура готелю»».
Документація прецедентів
Описуюча специфікація прецеденту Пошук
Прецедент
Пошук
Короткий опис
Прецедент дає можливість клієнту провести пошук по базі даних номера готелю, який його цікавить
Суб'єкти
Клієнт, Система
Передумови
Користувач за допомогою терміналу вибирає номер та відправляє запит.
Основний потік
Початок прецеденту - співпадає з рішенням клієнта вибрати номер в готелі. Система пропонує декілька форм пошуку (наприклад, за типом номеру, вартістю та ін.). В результаті система видає інформацію згідно введених клієнтом даних.
Альтернативний потік
Клієнт не вводить в поле пошуку жодної інформації. Стан системи залишається незмінним.
Постумови
Якщо прецедент був успішний, запит опрацьовується. В іншому випадку стан системи залишається незмінним.
Описуюча специфікація прецеденту Оплата
Прецедент
Оплата
Короткий опис
Прецедент дає можливість клієнту оплатити вартість проживання в готелі і додаткові платні послуги.
Суб'єкти
Клієнт, Система
Передумови
Клієнт вибирає додаткові послуги і форму оплати(готівка, безготівкова, кредитна картка) .
Основний потік
Початок прецеденту – кінець процедури реєстрації, після якої клієнт може оплатити вартість проживання в готелі та інші платні послуги.
Клієнт має змогу замовити додаткові послуги в будь-який момент під час проживання в готелі. Клієнт проводить оплату в зручній для нього формі(готівкою, безготівковою, кредитною карткою). Після чого отримує закодовану ключ-картку “VingCard”.
Альтернативний потік
З тих чи інших причин система повідомляє клієнту про помилку процедури оплати і пропонує повторити спробу.
Постумови
Якщо прецедент був успішний, система прийняла оплату клієнта. В іншому випадку проходить відмова і система пропонує повторити спробу.
Описуюча специфікація прецеденту Замовлення додаткових послуг
Прецедент
Замовлення додаткових послуг
Короткий опис
Прецедент дає можливість клієнту замовити додаткові платні послуги
Суб'єкти
Клієнт, Система
Передумови
Клієнт заповнює форму з відповідними полями.
Основний потік
Початок прецеденту - остаточне рішення клієнта замовити деяку послугу. Клієнт вибирає зі списку ті послуги, які його зацікавили і відправляє запит на замовлення. Після чого клієнт повинен підтвердити замовлення. Далі система переходить до прецеденту Оплата.
Альтернативний потік
Якщо замовлення не було підтверджене, система пропонує повторити спробу.
Постумови
Якщо прецедент був успішний, система передає клієнту повідомлення про успішне замовлення. В іншому випадку пропонує повторити спробу.
Описуюча специфікація прецеденту Повідомлення клієнту
Прецедент
Повідомлення клієнту
Короткий опис
Прецедент інформує клієнта про хід його сеансу
Суб'єкти
Система
Передумови
Система отримала деякий запит та опрацьовує його.
Основний потік
Початок прецеденту – закінчення опрацювання запиту
клієнта. В залежності від успішності виконання та
прецеденту, який привів до запиту, система відправляє
відповідне повідомлення.
Альтернативний потік
Якщо ніяких запитів до системи не надходило, її стан
залишається незмінним
Постумови
Якщо прецедент був успішний, система надсилає
повідомлення про результат виконання запиту, а також
додаткову інформацію, якщо така передбачена
прецедентом, що призвів до запиту.
Описуюча специфікація прецеденту Реєстрація
Прецедент
Реєстрація
Короткий опис
Прецедент дає можливість клієнту зареєструватись в
системі.
Суб'єкти
Клієнт, Система
Передумови
Клієнт, користуючись вказівками інтерфейсу,
реєструється в системі.
Основний потік
Початок прецеденту - користувач заповнює електронну
реєстраційну форму, де вказує особисту інформацію.
Система відображає реєстраційну форму, з полями для
вводу інформації про клієнта.
Альтернативний потік
Якщо клієнт вводить неповні дані то система
виводить повідомлення про помилку i повертається до форми
реєстрації.
Постумови
Якщо реєстрація пройшла успішно, клієнт може
здійснити оплату потрібного йому номера.
Описуюча специфікація прецеденту Бронювання
Прецедент
Бронювання
Короткий опис
Система дає можливість клієнтам забронювати номер в готелі по телефону або через Інтернет.
Суб'єкти
Клієнт, Система
Передумови
Система повинна заносити в базу даних номери, які були попередньо заброньовані клієнтами
Основний потік
Клієнт заповнює форму бронювання. Система заносить в базу даних інформацію про клієнта, дату прибуття, термін проживання, категорію номера(одномісний, двомісний, напівлюкс, люкс, апартаменти та ін.), кількість номерів та ін.
Альтернативний потік
Якщо клієнт некоректно вводить дані, система пропонує повторити спробу.
Постумови
Система заносить в базу даних необхідну інформацію. Інакше пропонує перейти до повторного заповнення форми.
Описуюча специфікація прецеденту Обновлення бази даних
Прецедент
Обновлення бази даних
Короткий опис
База даних обновлюється при бронюванні, поселенні або виселенні клієнта з номера.
Суб'єкти
Система
Передумови
Системи повинна постійно обновлювати базу даних номерів готелю.
Основний потік
Система обновлює базу даних при бронюванні, поселенні або виселенні клієнта.
Альтернативний потік
Стан системи залишається незмінним.
Постумови
Система заносить в базу даних інформацію про стан(зайнятий, вільний чи заброньований) номера.
Описуюча специфікація прецеденту Обслуговування
Прецедент
Обслуговування
Короткий опис
Система надає клієнту всі послуги, включені у вартість проживання.
Суб'єкти
Клієнт, система
Передумови
Система переглядає перелік послуг, які клієнт включив в список послуг на період його перебуванні у готелі.
Основний потік
У визначені періоди доби система надає різні види послуг(харчування, прибирання номерів, доставка в номер кореспонденції, фруктів та ін.).
Також система надає послуги, які діють на постійній основі весь період перебування клієнта в готелі(цілодобова інтегрована система готельної охорони та безпеки, кабельне та супутникове телебачення, кондиціонер та ін.).
Альтернативний потік
Якщо клієнт попередньо відмовився від деяких послуг, то система надавати їх не буде.
Постумови
Система надає клієнту весь спектр попередньо узгоджених послуг.
Описуюча специфікація прецеденту Виїзд з готелю
Прецедент
Виїзд з готелю
Короткий опис
Прецедент дає можливість системі зафіксувати виїзд клієнта з номера, повернути ключ, і занести необхідні дані в базу даних.
Суб'єкти
Система, Клієнт
Передумови
Клієнт бажає покинути номер.
Основний потік
Якщо вийшов термін проживання клієнта в готелі система повідомляє про це клієнта. Клієнт повертає закодовану ключ-картку “VingCard”. Після чого система відмічає в базі даних інформацію про виселення клієнта.
Альтернативний потік
Стан системи залишається незмінним.
Постумови
Клієнт успішно проходить процедуру виселення. Якщо ніяких запитів до системи не надходило, її стан залишається незмінним.
3. Порядок виконання роботи
Ознайомитися з теоретичною частиною.
Ознайомитися із середовищем розробки діаграм.
Розробити діаграму прецедентів для свого індивідуального завдання.
Здійснити документацію для кожного прецеденту діаграми.
Оформити звіт по результатах виконаної роботи.
Вимоги до звіту
Оформити звіт для захисту лабораторної роботи за зразком:
назва роботи
мета роботи
порядок роботи
короткі теоретичні відомості
аналіз отриманих результатів та висновок.
Рекомендована література
Язык UML. Руководство пользователю / Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. 2-е изд., Питер 2004.
Головатий О.О. Методичні вказівки до оформлення пояснювальних записок із дипломних робіт, літньої практики, курсових робіт та рефератів для студентів спеціальностей “Програмне забезпечення автоматизованих систем” та “Економічна кібернетика”. Жовті Води, ІП “Стратегія”, 2005.
Хабуш А., Ткачук Н.В., Исмаилов Р. Применение Web–технологии в информационно-управляющей системе газокомпрессорной станции магистрального газопровода. // Вісник ХДПУ. Харків, ХДПУ, вип. 102, 2000- С.113-117.
http://www.asp.net.
http://www.rational.com.
http://www.omg.org.
Методичні вказівки до лабораторної роботи № 2 “ Моделювання прецедентів” з дисципліни “ Основи автоматизованого проектування складних об’єктів та систем ” для студентів спеціальності 0804 “Комп’ютерні науки”
Укладач:
Скрибайло-Леськів Д.Ю.
Комп’ютерний набір, верстку та редагування
здійснила ст. гр. КН-41, каф. АСУ, Федевич О.Ю.
01.04.2013 22:04-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора