Учбовий приклад. Постановка завдання
Система бронювання квитків для авіакомпанії Короткий опис
На ринок вийшла нова авіакомпанія "GlobalAvia". Менеджери компанії вирішили замовити у вашої фірми розробку системи бронювання квитків. При замовленні фірма поставила ряд умов, які обов'язково повинні бути виконані. У першій версії системи вони хочуть бачити дві частини. Робота першої частини системи пов'язана із занесенням інформації. Друга частина системи призначена для спілкування з клієнтами.
При формулюванні вимог менеджери згадали, що рейси сплановані так, що до пункту призначення можна долетіти з пересадками. Одна з вимог полягала в тому, щоб система допомагала купувати квитки залежно від побажань користувача.
Аналіз постановки - повний опис
• Завдання є математичним. Система повинна уміти вирішувати однокритериальную задачу пошуку найкоротших шляхів на графах. Критерій - ціна.
• Система розподілена: оскільки в кожному аеропорту своя база напрямів польотів літаків, то знають про рейс тільки аеропорти-сусіди по рейсах.
Об'єкти системи: розподілене сховище рейсів, покупець квитків, менеджер рейсів.
• Розподілене сховище рейсів: назва рейсів, номери і вартість квитків.
• Покупець: ФІО, сума. Покупець задає параметри, пов'язані з сумою, яку він хоче витратити. Система повинна підібрати оптимальний маршрут. За відсутності прямих маршрутів система повинна спробувати знайти маршрути з пересадками. Якщо таких не знаходиться, система повинна сказати, що з такими обмеженнями не можна дістатися до місця призначення.
|
|
|
Серед причин:
• Відсутність рейсів в бажаному напрямі навіть з урахуванням пересадок.
8
• Брак грошей.
У відповідь, користувач повинен мати можливість поміняти параметри з урахуванням передісторії.
Менеджер рейсів: повинен мати наступні можливості:
• створення і видалення аеропортів в системі.
• створення і видалення рейсів в аеропортах.
Візуальний опис функціональної моделі засобами UML
Актори і варіанти використання в UML
Програмна система не функціонує сама по собі . Програмна система функціонує під впливом акторів (Actor) - користувачів, машин і інших програм. При цьому актор чекає, що система поводиться строго певним чином. Актор надає дію - система видає очікуваний результат. У випадку, якщо очікуваного результату немає, вимоги користувача не задоволені зі всіма витікаючими звідси результатами. Таким чином, актор в UML - людина , машина або програма, впливає на систему, є зовнішнім по відношенню до неї. Модель того, як дія приводить до результату, називається Варіантом використання (Use case). Актори і варіанти використання мають спеціальні позначення в UML:
|
|
|
Рис. 3.5.
Актори і варіанти використання спілкуються за допомогою посилки повідомлень. Повідомлення можуть йти в обидві сторони. Стрілка показує ініціатора спілкування (актор на малюнку) і може бути опущена.
Рис. 3.6.
Виділимо акторів і варіанти використання в розглянутому раніше прикладі з системою бронювання квитків (SRS). Аналіз постановки завдання показує наявність у системи двох акторів: "Користувач" і "Адміністратор". Визначимося з варіантами використання. Необхідно відзначити, що вибір акторів і варіантів використання до деякої міри умовний і може відрізнятися у різних фахівців з аналізу і проектування. Ухвалені проектні рішення визначають подальший вибір архітектури системи і істотно впливають на успіх всього процесу розробки. При цьому "хороших" варіантів може бути декілька.
Перелік Варіантів використання для наший завдання може бути, наприклад, таким:
• Забронювати квиток.
• Підібрати рейс.
• Працювати з даними.
• Управляти рейсами.
• Працювати з БД аеропорту.
Для візуального представлення акторів, варіантів використання і відносин між ними в UML передбачена спеціальна діаграма - діаграма варіантів використання. Нижче приведена діаграма для даного прикладу:
|
|
|
9
Рис. 3.7.
Приведемо деякі додаткові міркування:
• При такому моделюванні звертають увагу на поведінку системи, а не на її реалізацію.
• Хороша модель описує основну поведінку системи, не будучи дуже докладною.
• Подібна модель дозволяє перевірити, чи задовольнить система вимоги замовника.
• Система середніх розмірів може бути описана великою кількістю варіантів використання.
• Варіанти використання можуть описуватися різними сценаріями.
На останньому пункті зупинимося докладніше. Очевидно, назва варіанту використання не дає повного уявлення про те, як він запроваджується в життя. Для опису сценарію роботи варіанту використання UML містить спеціальні засоби. Основне з них - діаграма дії.
Діаграма дії це блок-схема, яка відображає динаміку в поведінці системи. Відмітимо, що ця діаграма може використовуватися не тільки для опису сценаріїв Варіанту використання.
Приведемо приклад відповідної діаграми для варіанту використання Бронювання квитків в системі SRS.
Рис. 3.8.
10
Дата добавления: 2018-05-09; просмотров: 554; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!