Ім'я файлу: КурсоваРоботаАППЗ — копия.docx
Розширення: docx
Розмір: 1496кб.
Дата: 27.04.2020
скачати
Пов'язані файли:
Курсовая .docx

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

НАЦІОНАЛЬНИЙ ТРАНСПОРТНИЙ УНІВЕРСИТЕТ

Факультет транспортних та інформаційних технологій

Кафедра інформаційних систем і технологій


КУРСОВА РОБОТА

з дисципліни «Архітектура та проектування програмного забезпечення»

на тему: «Система бронювання замовлень таксі»

Студента 3 курсу групи ПР-ІІІ-2

Гриценка Зорислава Олександровича

Перевірив: Ст.викл. Сватко В.В.

Національна шкала ________________

Кількість балів: ___________________

Оцінка: ECTS ____________________

м. Київ – 2018 рік

ЗМІСТ

  1. ВСТУП……………………………………………………………………………………3

  2. ОСНОВНА ЧАСТИНА:

    1. Визначення вимог до програмного продукту………………………………………4

    2. Проектування програмного продукту за допомогою діаграм UML………………6

      1. Побудова діаграм варіантів використання (use cases)…………………………6

      2. Побудова діаграм класів…………………………………………………………9

      3. Побудова діаграм сценаріїв…………………………………………………….10

      4. Побудова діаграм діяльності…………………………………………………...12

    3. Застосування структурного аналізу і проектування для створення архітектури програмного продукту……………………………………………………………...15

      1. Побудова функціональної моделі інформаційної системи на основі методології SADT……………………………………………………………….15

      2. Побудова діаграми потоків даних інформаційної системи (DFD)…………...19

    4. Побудова логічної архітектури додатку…………………………………………...22

    5. Побудова фізичної архітектури додатку…………………………………………..23

    6. Документування архітектури за допомогою моделі «4+1»………………………24

  3. ВИСНОВКИ………………………………………………………………….………….26

  4. ПЕРЕЛІК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ ТА ПОСИЛАНЬ………………………27

ВСТУП

Інформаційна система (ІС) - система, що призначена для збору, передачі, обробки, зберігання й видачі інформації споживачам і складається з наступних основних компонентів:

  1. програмне забезпечення;

  2. інформаційне забезпечення;

  3. технічні засоби;

  4. обслуговуючий персонал.

Конкретні завдання, які повинні вирішуватися інформаційною системою, залежать від тої прикладної області, для якої призначена система. Області застосування інформаційних додатків різноманітні: банківська справа, страхування, медицина, транспорт, освіта й т.д. Важко знайти область ділової активності, у якій сьогодні можна було б обійтися без використання інформаційних систем. З іншого боку, очевидно, що, наприклад, конкретні завдання, розв'язувані банківськими інформаційними системами, відрізняються від завдань, рішення яких вимагається від медичних інформаційних систем.

Комп'ютерні інформаційні системи призначені зберігати більші обсяги даних, здійснювати в них швидкий пошук, вносити зміни, виконувати всілякі маніпуляції з даними (групувати, сортувати та ін.). Наприклад, система продажу квитків у кінотеатр/театр. Основою всякої інформаційної системи є база даних - організована сукупність даних на магнітних дисках.

ОСНОВНА ЧАСТИНА

    1. Визначення вимог до програмного продукту.

Програмний продукт «Система бронювання замовлень таксі» створюється з метою надання користувачеві можливості бронювання замовлень таксі.

Функціональні вимоги до додатку, які повинні бути реалізовані у програмному продукті: 

  1. Функція створення замовлень: 

    1. Функція додавання додаткових критерій; 

    2. Функція додавання адреси;

    3. Функція підтвердження замовлення;

    4. Функція анулювання замовлення;

  2. Функція обробки замовлення: 

    1. Функція перегляду актуальних замовлень ;

    2. Функція підтвердження виконання замовлення; 

    3. Функція відміни виконання замовлення; 

    4. Функція перегляду інформації замовлення; 

  3. Функція оплати замовлення:

  1. Функція оплати за допомогою платіжної карти.

  1. Функція завершення замовлення:

    1. Функція залишити коментар;

    2. Функція оцінювання поїздки;

    3. Функція оформлення бронювання/купівлі;

    4. Функція сплати коштів за квитки (в разі купівлі);

    5. Функція підтвердження проведенної операції;

    6. Функція блокування бронювання/купівлі квитків;

  2. Функція продажу/видачі квитків:

    1. Функція керування вільними місцями;

    2. Функція зняття бронювання;

    3. Функція блокування продажу квитків;

 

Нефункціональні вимоги, які повинні бути враховані при реалізації проекту створення додатку «Система бронювання таксі»: 

  1. Додаток повинен мати зрозумілий і простий інтерфейс. 

  2. Додаток повинен працювати швидко і правильно. 

  3. Додаток повинен мати просту логіку дій. 

  4. Додаток повинен підтримувати платіжну систему.

  5. Додаток повинен оновлюватися регулярно (не менше одного разу в два місяця).

  6. Додаток повинен містити достатньо інформації про замовлення, критерії замовлення, цінову політику.

  7. Додаток повинен підтримуватися на різних платформах, в різних браузерах та мати мобільну версію.


Ролі до створюваного програмного додатку:

  1. Адміністратор – людина, відповідальна за керування основною інформацією в додатку: надання технічної підтримки та ведення загальної звітності.

  2. Клієнт – людина, яка використовує готовий продукт в цілях замовлення, оплати послуг системи.

  3. Водій - людина, яка надає свої послуги, в цілях перегляду, підтверджені, виконанні замовлень .




    1. Проектування програмного продукту за допомогою діаграм UML.

Універсальна мова моделювання (Unified Modelling Language або UML) — це мова позначень або побудови діаграм, призначена для визначення, візуалізації і документування моделей зорієнтованих на об’єкти систем програмного забезпечення.

UML розроблено для побудови структури зорієнтованого на об’єкти програмного забезпечення, ця мова має дуже обмежену користь для програмування на основі інших парадигм.

Конструкції UML створюються з багатьох модельних елементів, які позначають різні частини системи програмного забезпечення. Елементи UML використовуються для побудови діаграм, які відповідають певній частині системи або точці зору на систему.

Побудова діаграм варіантів використання (use cases).



Рис. 1.2.1. - діаграма варіантів використання для користувача системи “Адміністратор”.

На рисунку 1.2.1. зображено діаграму варіантів використання для адміністратора. Даний користувач системи повинен надавати технічну підтримку авторизованим користувачам системи та вести загальну звітність.



Рис. 1.2.2. - діаграма варіантів використання для користувача системи “Клієнт”.

На рисунку 1.2.2. зображено діаграму варіантів використання для клієнта бронювання таксі. Основна задача даного користувача в створенні замовлення. Клієнт має вказати адресу , вибрати критерії і підтвердити замовлення. Має можливість оплати платіжною картою та залишити відгук про поїздку. В особистому кабінеті клієнт може переглянути історію замовлень та редагувати свої дані.



Рис. 1.2.3. - діаграма варіантів використання для користувача системи “Водій”.

На рисунку 1.2.3. зображено діаграму варіантів використання для водія системи таксі. Водій повинен приймати замовлення. Він має доступ до актуальних замовлень , з яких може вибрати та підтвердити замовлення. Водій завершує замовлення та може залишити відгук про клієнта. В особистому кабінеті може редагувати дані про себе або про свій автомобіль . Також має змогу переглянути виконані замовлення.


Побудова діаграм класів.


Рис. 1.2.4. - діаграма класів.

На рисунку 1.2.4. зображено діаграму класів до системи бронювання таксі. У нашому випадку майже очевидним є необхідний набір класів. Це класи "Список автомобілів" (ListCars) та "автомобіль" (Car). Список автомобілів може мати марку автомобіля та містити набір автомобілів (масив, список, або інша послідовність). Автомобіль можна охарактеризувати номером, класом автомобіля, роком випуску авто, маркою автомобіля. Дані про водія в свою чергу мають свою внутрішню структуру - ім'я та прізвище водія, паспортні данні, документи на автомобіль.

Побудова діаграм сценаріїв. Система призначена бронювання замовлень таксі.

Користувачами системи будуть:


  1. Адміністратор – людина, відповідальна за надання технічної підтримки, ведення загальної звітності.

  2. Клієнт – людина, яка використовує готовий продукт в цілях бронювання, оплати замовлень таксі.

  3. Водій - людина, яка надає свої послуги системі. Вибирає замовлення з функціоналу актуальних замовлень та виконує їх.

Основні функції розроблюваного додатку:

  1. Дані водія - документ в якому знаходиться інформація про користувача системи (водія):паспортні, платіжні, автомобільні дані ,номер сотового телефону та рейтинг ;

  2. Дані клієнта – документ в якому знаходиться інформація про клієнта системи. В ній міститься номер телефону, платіжні дані та рейтинг;

  3. Журнал історії замовлень – документ в якому будуть фіксуватись виконані або відмінені замовлення ;

  4. Актуальні замовлення – функціонал в який надходять замовлення від клієнта ;

  5. Бронювання таксі – функціонал , де клієнт створює замовлення .

  6. Оплата – функціонал розрахування клієнта з системою .

  7. Довідкова інформація – документ, в якому міститься юридична інформація, інформація про тарифи. Також там буде знаходитись технічна підтримка.

  8. Загальна звітність – документ , в який буде вноситись звітність про систему.




Рис. 1.2.5. - діаграма сценаріїв для користувача системи “Адміністратор”.


Рис. 1.2.6. - діаграма сценаріїв для користувача системи “Касир”.


Рис. 1.2.7. - діаграма сценаріїв для користувача системи “Клієнт”.

Побудова діаграм діяльності.


Рис. 1.2.8. - діаграма діяльності для користувача системи “Адміністратор”.

На рисунку 1.2.8. зображено діаграму діяльності для адміністратора системи бронювання замовлень таксі. Робота адміністратора полягає в тому щоб забезпечувати користувачів системи технічною підтримкою . Також адміністратор повинен вести загальну звітність .



Рис. 1.2.9. - діаграма діяльності для користувача системи “Водій”.

На рисунку 1.2.9. зображено діаграму діяльності водія системи бронювання замовлень таксі. Основна робота водія – виконання замовлень. Алгоритм виконання його роботи починається з перегляду актуальних замовлень , далі водій обирає потрібне для нього замовлення, після чого підтверджує замовлення. Водій завершує замовлення та залишає відгук .


Рис. 1.2.10. - діаграма діяльності для користувача системи “Клієнт”.

На рисунку 1.2.10. зображено діаграму діяльності для клієнта системи бронювання замовлень таксі. Основна задача клієнта – бронювання замовлень таксі. Алгоритм виконання його задачі починається з вказання адреси, звідки та куди буде прокладено маршрут. Далі клієнт може вказати додаткові критерії замовлення, після цих операцій має підтвердити замовлення. По закінченню замовлення клієнт повинен оплати послугу, або готівкою , або платіжною картою. Після чого може залишити відгук або оцінку наданих послуг водія.

    1. Застосування структурного аналізу і проектування для створення архітектури програмного продукту.

Побудова функціональної моделі інформаційної системи на основі методології SADT. Графіка блоків та дуг SADT–діаграми відображає функцію у вигляді блоку, а інтерфейси входу/виходу представляються дугами, відповідно вхідними у блок та вихідними з нього.



Рис. 1.3.1. - загальне представлення SADT-діаграми.

Управляюча інформація входить у блок зверху. Для нашого програмного продукту доцільно внести таку управляючу інформацію: логіка оплати картою –;Тариф – визначає скільки клієнт має оплати , вираховуючи n₴ за 1км . Вихідні дані (вхід), які підлягають обробці, знаходяться зліва блоку - в нашому випадку це дані замовлення , а саме це маршрут та додаткові критерії. Результати обробки (вихід), показані справа – замовлення ,оплата, документація та звіти. Механізм (людина або програма), які здійснюють операцію, зображується дугою, що входить у блок знизу. В даному програмному продукті користувачами системи будуть водій та клієнт.



Рис. 1.3.2. - деталізована SADT-діаграма.

На рисунку 1.3.2. зображено деталізовану SADT-діаграму. На цій діаграмі можна помітити функції системи бронювання замовлень таксі. Вхідними даними у нас є дані замовлення , з них система формує замовлення ,на формування замовлення можуть впливати дані клієнта ,тариф(вказується ціна проїзду за кілометр, на яку може впливати завантаженість в годину пік) . Далі система обробляє замовлення, де водій може переглянути дані замовлення та клієнта. Після чого виконується замовлення, управляється логікою оплати картою , в результаті вихідна інформація це – звіт та документація.



Рис. 1.3.3. - більш деталізована SADT-діаграми блоку А2.

На рисунку 1.3.3. зображено більш деталізовану SADT-діаграму. В діаграмі більш детально реалізовано обробку замовлення та оплати клієнта . Сформоване замовлення зберігається системою в БД. Водій може переглядати вже сформоване замовлення в актуальних замовленнях . Оплата замовлення здійснюється клієнтом після виконання замовлення , на яку впиває тариф(ціна за маршрут та додаткові послуги , якщо вони були) та логіка оплати картою (переводом суми за поїздку з клієнтської платіжної карти на карту водія ). Вихідні дані : документація та звіт.


Побудова діаграми потоків даних інформаційної системи (DFD).



Рис. 1.3.6. - загальне представлення DFD-діаграми.

Для початку побудуємо контекстну діаграму, для чого визначимо зовнішні сутності і потоки даних між програмою і зовнішніми сутностями. Зовнішньою сутністю по відношенню до програми є Користувач. Він формує бронювання замовлення таксі, а потім отримує від програми описання вибраного кінотеатру/театру, опис сеансу і квиток. На рис. 1.3.6. наведена контекстна діаграма даної програми.



Рис. 1.3.7. - деталізована DFD-діаграма.

Після деталізації отримано три процеси: Впорядкування сеансів, Оформлення продажу квитків, Оформлення купівлі квитків. Для збереження сеансів служить БД Сеанси. Для збереження даних про кінотеатр/театр служить БД Кінотеатр/театр. Для збереження особистих даних користувачів служить БД Особисті дані. Тепер визначимо потоки даних.

Деталізуюча діаграма потоків даних зображена на рис 1.3.7.



Рис. 1.3.8. - більш деталізована DFD-діаграми блоку 1.1.

Більш деталізована діаграма має чотири процеси: Визначення фільмів/мультфільмів/спектаклів по сеансам, Визначення додаткової інформації сеансу, Обробка даних і Вивід даних на екран. Для збереження сеансів служить БД Сеанси. Для збереження даних про кінотеатр/театр служить БД Кінотеатр/театр.

Деталізуюча діаграма потоків даних зображена на рис 1.3.8.


Рис. 1.3.9. - більш деталізована DFD-діаграми блоку 1.2.

Більш деталізована діаграма має чотири процеси: Обчислення вільних місць, Визначення бронювання/купівлі, Обробка даних і Вивід даних на екран. Для збереження даних про кінотеатр/театр служить БД Кінотеатр/театр.

Деталізуюча діаграма потоків даних зображена на рис 1.3.9.



Рис. 1.3.10. - більш деталізована DFD-діаграми блоку 1.3.

Більш деталізована діаграма має чотири процеси: Обчислення вільних місць, Визначення бронювання/купівлі, Обробка даних і Вивід даних на екран. Для збереження даних про кінотеатр/театр служить БД Кінотеатр/театр.

Деталізуюча діаграма потоків даних зображена на рис 1.3.9.

Побудова логічної архітектури додатку. Система призначена для продажу квитків у кінотеатр/театр.

Користувачами системи будуть:

  1. Адміністратор – людина, відповідальна за керування основною інформацією в додатку: формування розкладу сеансів, додавання детальної інформації про сеанс та ін.;

  2. Клієнт – людина, яка використовує готовий продукт в цілях перегляду доступних сеансів, бронювання та купівлі квитків у кінотеатрі/театрі.

  3. Касир - людина, яка веде облік доступних місць, виконує зняття бронювання, продаж квитків та керує блокуванням бронювання/купівлі/продажу квитків після завершення сеансу.

Користувачі системи будуть взаємодіяти з системою за допомогою desktop-ного інтерфейсу, web-інтерфейсу та мобільного клієнту. desktop-ний інтерфейс буде використовуватись адміністратором та касиром кінотеатру/театру, для виконання своїх обов’язків. web-інтерфейс та мобільний клієнт буде використовуватись клієнтами для перегляду необхідної інформації.

Сервісами системи будуть:

  1. Розклад сеансів, в якому буде відображатися інформація про сеанси фільмів;

  2. Адміністрування для можливості налаштування інтерфейсу під конкретні побажання користувача.

Під шаром сервісів розміщується шар бізнес-логіки, що складається з 5 компонентів, що вирішують поставлені основні бізнес-задачі. А саме:

  1. Розклад сеансів – функціонал формування та перегляду розкладу сеансів;

  2. Детальна інформація – функціонал внесення та перегляду детальної інформації про сеанс;

  3. Система бронювання – функціонал вибору та бронювання місць;

  4. Система купівлі – функціонал вибору місць та сплати коштів за квитки;

  5. Квиток – документ, у якому буде вказуватися операції, що відбулися з квитком (бронювання, купівля);

Дані будуть зберігатись в базі даних, яка буде розміщуватись на двох серверах, які будуть мж собою з’єднанні, з метою постійного обміну інформацією. Крім того, система буде обмінюватися даними з іншою інформаційною системою.

Наскрізною функціональністю системи буде:

  1. механізм журналювання;

  2. забезпечення безпеки даних системи;

  3. механізм контролю версій системи.



Рис. 1.3.11. - логічна архітектура системи продажу квитків у кінотеатр/театр.

Побудова фізичної архітектури додатку. Для побудови фізичної архітектури додатку достатньо розмістити логічні шари на серверах. Таким чином ми отримаємо фізичну архітектуру проектованого додатку. На рисунку 1.3.12. наведено приклад фізичної архітектури додатку, побудованої на основі логічних шарів.



Рис. 1.3.12. - фізична архітектура системи продажу квитків у кінотеатр/театр.

Документування архітектури за допомогою моделі «4+1».



Рис. 1.3.13. – діаграма моделі «4+1».

  1. Як користувачі використовуватимуть додаток?

Додаток “Система бронювання замовлень таксі” передбачає існування трьох користувачів: адміністратор, - людина, відповідальна за керування основною інформацією в додатку: формування довідкової інформації , надання користувачам технічну підтримку .; водій - користувач системи, який надає послуги системі у вигляді перегляду \підтвердженні\виконані замовлень; а також клієнт - людина, яка використовує готовий продукт в цілях замовлення , оплати послуг таксі.

  1. Як додаток впроваджуватиметься (deployed) і управлятиметься?

Додаток розумно буде впроваджувати паралельно до основної системи, щоб в разі бажання внести певні зміни в систему їх можна було додати без негативного впливу.
Цей додаток буде представлений як електронне джерело в комп’ютерній та мобільній версії для користувачів системи (клієнт,водій,адмінстратор) .

  1. Яким якісним вимогам повинно задовольняти додаток (безпека, продуктивність, можливість розпаралелювання, інтернаціоналізація, конфігурування)?

Додаток повинен задовольняти таким якісним вимогам:

  • Здатність до відновлення (здатність відновлювати визначений рівень працездатності та цілісність даних після відмови, необхідні для цього час і ресурси).

  • Розпаралелювання (для одночасної роботи на декількох носіях, і при потребі швидке оновлення даних на сервері після внесення змін з декількох носіїв).

  • Функціональна придатність (здатність вирішувати потрібний набір задач).

  • Захищеність та безпека (здатність запобігати неавторизованому доступу до пз).

  • Стійкість до відмов (здатність підтримувати заданий рівень працездатності при відмовах і порушеннях правил взаємодії з середовищем).

  • Інтентернаціоналізація .



  1. Яким чином має бути спроектований додаток, щоб залишатися гнучким і простим в підтримці з часом?

Цей додаток має бути з простим та зрозумілим інтерфейсом, не містити нічого зайвого, в разі оновлення сповістити користувача про нові/покращенні можливості додатку.

  1. Які архітектурні напрями можуть вплинути на додаток зараз або після впровадження?

  • Внесення нової функціональності.

  • Зміна кількості серверів.

  • Додавання певних обмежень або вимог.


ВИСНОВКИ

Під час виконання курсової роботи отримали практичні навички в побудові логічної та фізичної архітектури проектованого додатку на основі функціональних та нефункціональних вимог. 

Вивчили діаграми варіантів використання, діаграми класів, діаграми сценаріїв, діагами діяльності та їх застосування в процесі проектування інформаційних систем, навчилися будувати функціональну діаграму за методологією SADT та компонентну діаграму за методологією DFD.

Провели документування архітектури за допомогою моделі «4+1».
СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ

  1. https://studfiles.net/preview/5375896/page:3/

  2. http://ususoft.com.ua/uk/programma_dlya_pitaniya.php

  3. https://dev.mysql.com/doc/workbench/en/

  4. https://docs.oracle.com/javase/tutorial/

скачати

© Усі права захищені
написати до нас