Міністерство освіти і науки, молоді та спорту України
Національний університет «Львівська політехніка»
Кафедра АСУ
Звіт до лабораторної роботи №2
з дисципліни:
«Основи автоматизованого проектування складних об'єктів і систем»
Тема: «Моделювання прецедентів»
Мета роботи: Оволодіти навичками моделювання діаграм прецедентів та навчитися реалізовувати їх.
Порядок виконання роботи
1. Ознайомитися з теоретичною частиною.
2. Ознайомитися із середовищем розробки діаграм.
3. Розробити діаграму прецедентів для свого індивідуального завдання.
4. Здійснити документацію для кожного прецеденту діаграми.
5. Оформити звіт по результатах виконаної роботи.
Короткі теоретичні відомості
Прецедентом (use case) називається опис множини послідовностей дій (включаючи варіанти), що виконуються системою для того, щоб актор міг отримати певний результат. Графічно прецедент зображується у вигляді еліпса.
Діаграма прецедентів в UML - це діаграма, на якій зображено відношення між акторами та прецедентами в системі. Також перекладається як діаграма варіантів використання.
Діаграми прецедентів або діаграми варіантів використання (use case diagrams). Такі діаграми описують функціональність, яка буде надаватись користувачам системи, котра проектується. Представляються шляхом використання прецедентів та акторів, а також відношень між ними. Набір усіх прецедентів діаграми фактично визначає функціональні вимоги, за допомогою яких може бути сформульоване технічне завдання.
Прецеденти є основним засобом визначення необхідної поведінки системи. Як правило, вони використовуються для опису вимог до системи, тобто, що має робити система. Основними поняттями, пов'язаними з прецедентами є актори, прецеденти (варіанти використання), та суб'єкт.
Суб'єкт — це система, що розглядається, і до якої відносяться прецеденти. Користувачів та будь-які інші системи, що можуть взаємодіяти із суб'єктом, представлено як акторів. Актори завжди представляють сутності, що знаходяться за межами системи. Поведінка суб'єкта описується одним або більше прецедентами, що визначаються відповідно до потреб акторів. Строго кажучи, термін «прецедент» означає тип прецедента. Екземпляр прецедента означає існування поведінки, що відповідає вимогам типу прецедента. Часто такі екземпляри описуються специфікаціями взаємодії.
Діаграма прецедентів є графом, що складається з множини акторів, прецедентів (варіантів використання) обмежених границею системи (прямокутник), асоціацій між акторами та прецедентами, відношень серед прецедентів, та відношень узагальнення між акторами. Діаграми прецедентів відображають елементи моделі варіантів використання.
Прецеденти є засобом специфікації системи с точки зору отримання діячами деяких істотних для них результатів. Тобто, прецедентами задаються сервіси (функціональні можливості) системи, якими може скористатись діяч.
Як саме визначати прецеденти? Відповідь може бути такою. Стосовно кожного діяча слід розглянути типові (узагальнюючі) варіанти сервісів (функцій), які мають підтримуватись системою і якими може скористатись діяч. (Можливо, для цього доведеться спочатку провести ділове моделювання.) Виділеним сервісам і мають відповідати прецеденти.
Типові приклади застосування
Діаграми прецедентів, або варіантів використання, застосовують для моделювання статичного виду системи з погляду прецедентів. Цей вигляд охоплює головним чином поведінку системи, тобто видимі ззовні сервіси, що надаються системою в контексті її оточення.
При моделюванні статичного виду системи з погляду прецедентів діаграми використання зазвичай застосовуються двома способами:
для моделювання контексту системи.
Моделювання контексту має на увазі, що ми обводимо систему уявною лінією і виявляємо актори, які знаходяться за цією лінією і взаємодіють з системою. Діаграми прецедентів потрібні на цьому етапі для ідентифікації акторів і семантики їх ролей;
для моделювання вимог до системи.
Моделювання вимог до системи припускає вказівку на те, що система повинна робити (з погляду зовнішнього спостерігача), незалежно від того, як вона винна це робити. Діаграми прецедентів потрібні тут для специфікації бажаної поведінки системи. Вони дозволяють розглядати всю систему як "чорний ящик": ви бачите все, що знаходиться поза нею, спостерігаєте за її реакцією на події, але нічого не знаєте про її внутрішній устрій.
Хід роботи
Тема індивідуального завдання: система автоматизації ведення юридичних документів кафедри, що стосуються захисту диплому.
Діаграма прецедентів
/
Рис. 1. Діаграма прецедентів
Документація прецедентів
Описуюча специфікація прецеденту Редагування потенційних членів комісії
Прецедент
Редагування потенційних членів комісії
Короткий опис
Прецедент дає можливість клієнту вводити дані про потенційних членів комісії і редагувати їх.
Суб'єкти
Клієнт, Система.
Передумови
Користувач переходить на відповідну веб-сторінку.
Основний потік
Користувач може ввести дані про члена комісії і додати його до бази даних. Або користувач може обрати з випадного списку існуючого члена комісії та змінити дані про нього.
Альтернативний потік
Клієнт не здійснює ніяких дій. Стан системи залишається незмінним.
Постумови
Якщо прецедент був успішний, то відповідні дані про членів комісії вносяться у базу даних. В іншому випадку система робить запит на повторне введення даних.
Описуюча специфікація прецеденту Отримання результатів захисту
Прецедент
Отримання результатів захисту
Короткий опис
Прецедент дає можливість клієнту отримати документ з результатами захисту.
Суб'єкти
Клієнт, Система.
Передумови
Користувач переходить на відповідну веб-сторінку.
Основний потік
Користувач обирає рік та сезон захисту та завантажує документ з результатами захисту.
Альтернативний потік
Клієнт не здійснює ніяких дій. Стан системи залишається незмінним.
Постумови
Якщо прецедент був успішний, то користувач отримує документ зі звітом. В іншому випадку стан системи залишається незмінним.
Описуюча специфікація прецеденту Підрахунок статистичних даних
Прецедент
Підрахунок статистичних даних
Короткий опис
Прецедент збирає статистичні дані щодо певної здачі.
Суб'єкти
Система.
Передумови
Система отримує запит на підрахунок статистичних даних з результатами захисту.
Основний потік
Система здійснює пошук всіх дипломів, що стосуються обраного захисту і підраховує статистичні дані по різних критеріях.
Альтернативний потік
Клієнт не здійснює ніяких дій. Стан системи залишається незмінним.
Постумови
Якщо прецедент був успішний, то система повертає статистичні дані на верхній рівень. В іншому випадку стан системи залишається незмінним.
Описуюча специфікація прецеденту Редагування членів ДЕК-у
Прецедент
Редагування членів ДЕК-у
Короткий опис
Прецедент дає можливість клієнту редагувати членів комісії, голову та секретаря певного ДЕК-у.
Суб'єкти
Клієнт, Система.
Передумови
Користувач переходить на відповідну веб-сторінку.
Основний потік
Користувач обирає рік та сезон захисту та додає до нього членів комісії, голову та секретаря зі списку потенційних членів комісії.
Альтернативний потік
Клієнт не здійснює ніяких дій. Стан системи залишається незмінним.
Постумови
Якщо прецедент був успішний, то вносяться зміни у базу даних. В іншому випадку система робить запит на повторне введення даних.
Описуюча специфікація прецеденту Редагування розкладу ДЕК-у
Прецедент
Редагування членів ДЕК-у
Короткий опис
Прецедент дає можливість клієнту редагувати розклад певного ДЕК-у.
Суб'єкти
Клієнт, Система.
Передумови
Користувач переходить на відповідну веб-сторінку.
Основний потік
Користувач обирає рік та сезон захисту та додає до нього чи редагує дні та години засідань. Додатково користувач може обрати автоматичну генерацію розкладу та генерацію документу з розкладом.
Альтернативний потік
Клієнт не здійснює ніяких дій. Стан системи залишається незмінним.
Постумови
Якщо прецедент був успішний, то вносяться зміни у базу даних. В іншому випадку система робить запит на повторне введення даних.
Описуюча специфікація прецеденту Автоматична генерація розкладу
Прецедент
Автоматична генерація розкладу
Короткий опис
Прецедент передбачає автоматичну генерацію розкладу системою.
Суб'єкти
Система.
Передумови
Система отримує запит на автоматичну генерацію розкладу.
Основний потік
Система генерує розклад засідань відштовхуючись від існуючого розкладу на офіційному сайті університету.
Альтернативний потік
Клієнт не здійснює ніяких дій. Стан системи залишається незмінним.
Постумови
Якщо прецедент був успішний, то вносяться зміни у базу даних. В іншому випадку система повідомляє користувача про невдачу.
Описуюча специфікація прецеденту Генерація документу з розкладом
Прецедент
Генерація документу з розкладом
Короткий опис
Прецедент передбачає генерацію документу з розкладом системою.
Суб'єкти
Система.
Передумови
Система отримує запит на генерацію документу з розкладом.
Основний потік
Система генерує документу з розкладом на основі внесених даних про розклад засідань.
Альтернативний потік
Клієнт не здійснює ніяких дій. Стан системи залишається незмінним.
Постумови
Якщо прецедент був успішний, то система повертає користувачу сформований документ. В іншому випадку стан системи залишається незмінним.
Описуюча специфікація прецеденту Редагування даних про дипломи
Прецедент
Редагування даних про дипломи
Короткий опис
Прецедент дає можливість клієнту редагувати дані про дипломи та студентів, що стосуються певного захисту.
Суб'єкти
Клієнт, Система.
Передумови
Користувач переходить на відповідну веб-сторінку.
Основний потік
Користувач обирає рік, сезон захисту, та групу (або додає нову) і додає до неї чи редагує дні про дипломи та студентів. Додатково користувач може завантажити дані про дипломи з файлу.
Альтернативний потік
Клієнт не здійснює ніяких дій. Стан системи залишається незмінним.
Постумови
Якщо прецедент був успішний, то вносяться зміни у базу даних. В іншому випадку система робить запит на повторне введення даних.
Описуюча специфікація прецеденту Завантаження даних про дипломи з файлу
Прецедент
Завантаження даних про дипломи з файлу
Короткий опис
Прецедент передбачає завантаження відомостей про дипломи з файлу.
Суб'єкти
Система.
Передумови
Система отримує запит на читання відомостей про дипломи з певного файлу.
Основний потік
Система зчитує дані про дипломи з переданого їй файлу та заносить їх у базу даних.
Альтернативний потік
Клієнт не здійснює ніяких дій. Стан системи залишається незмінним.
Постумови
Якщо прецедент був успішний, то вносяться зміни у базу даних. В іншому випадку система повідомляє користувача про невдачу.
Описуюча специфікація прецеденту Редагування потенційних рецензентів
Прецедент
Редагування потенційних рецензентів
Короткий опис
Прецедент дає можливість клієнту вводити дані про потенційних рецензентів і редагувати їх.
Суб'єкти
Клієнт, Система.
Передумови
Користувач переходить на відповідну веб-сторінку.
Основний потік
Користувач може ввести дані про рецензента і додати його до бази даних. Або користувач може обрати з випадного списку існуючого рецензента та змінити дані про нього.
Альтернативний потік
Клієнт не здійснює ніяких дій. Стан системи залишається незмінним.
Постумови
Якщо прецедент був успішний, то вносяться зміни у базу даних. В іншому випадку система робить запит на повторне введення даних.
Описуюча специфікація прецеденту Редагування графіку рецензування
Прецедент
Редагування графіку рецензування
Короткий опис
Прецедент дає можливість клієнту редагувати графіки рецензування.
Суб'єкти
Клієнт, Система.
Передумови
Користувач переходить на відповідну веб-сторінку.
Основний потік
Користувач обирає рік, сезон захисту та рецензента і додає студентів, яких він рецензував, отриману ними оцінку і час рецензування.
Альтернативний потік
Клієнт не здійснює ніяких дій. Стан системи залишається незмінним.
Постумови
Якщо прецедент був успішний, то вносяться зміни у базу даних. В іншому випадку система робить запит на повторне введення даних.
Описуюча специфікація прецеденту Генерація бланку оплати
Прецедент
Генерація бланку оплати
Короткий опис
Прецедент передбачає генерацію бланку оплати системою.
Суб'єкти
Система.
Передумови
Система отримує запит на генерування бланку оплати для певного рецензенту.
Основний потік
Система генерує бланк оплати на основі отриманих даних про рецензента та даних з бази даних про рецензування.
Альтернативний потік
Клієнт не здійснює ніяких дій. Стан системи залишається незмінним.
Постумови
Якщо прецедент був успішний, то система повертає користувачу сформований документ. В іншому випадку стан системи залишається незмінним.
Висновок: на даній роботі я отримав навички моделювання діаграм прецедентів та навчитися реалізовувати їх.