ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/6382| Title: | Автоматизована система інформаційного забезпечення продажу квитків кінотеатру |
| Authors: | Чичужко, Марина Володимирівна Гудков, Кирило Сергійович |
| Issue Date: | Jun-2024 |
| Abstract: | Метою виконання даної кваліфікаційної роботи на здобуття освітнього ступеня «бакалавр» є створення автоматизованої системи інформаційного забезпечення продажу квитків кінотеатру. Основними завданнями кваліфікаційної роботи є огляд аналогів розроблюваної автоматизованої системи, побудова моделі розроблюваної системи та формування вимог до неї, дослідження функцій та синтез структури системи, ознайомлення з етапами життєвого циклу проекту автоматизації, вибір середовища розробки та операційної системи, побудова моделі обробки запитів до автоматизованої системи, опис інтерфейсу користувача. Розглянуто аналоги інформаційних систем продажу квитків на прикладі систем «Multiplex», «Вкіно» та «Kontramarka». Описано концептуальну модель розроблюваної системи та сформовано вимоги. Досліджено функції та синтез структури системи. Описано етапи життєвого циклу проекту автоматизації. Обгрунтовано вибір середовища розробки та вибір операційної системи. Описано модель обробки запитів до автоматизованої системи інформаційного забезпечення продажу квитків кінотеатру .та інтерфейс користувача. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/6382 |
| Appears in Collections: | 174 Автоматизація, комп'ютерно-інтегровані технології та робототехніка (Автоматизація та комп'ютерно-інтегровані системи та компоненти) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Б_174_2024_Гудков.pdf Restricted Access | 1.98 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
ЗМІСТ ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ………………….…...4 ВСТУП………………………………………………………………….…….…..5 1 ОГЛЯД ІСНУЮЧИХ АНАЛОГІВ ТА ТЕХНІЧНИХ РІШЕНЬ …..….…..6 1.1 Огляд системи «Multiplex»………………………………….……………6 1.2 Огляд системи «Вкіно» ..……………………………….……....….……..7 1.3 Огляд системи «Kontramarka» ..……………………………….….……...9 2 АНАЛIЗ ТЕХНIЧНОГО ЗАВДАННЯ ……………...…………….…...…14 2.1 Концептуальна модель розроблюваної системи……….…………...…14 2.2 Вимоги до системи………………………………………………...…….16 3 ДОСЛІДЖЕННЯ ФУНКЦІЙ ТА СИНТЕЗ СТРУКТУРИ СИСТЕМИ......23 3.1 Опис функцій системи…………………………………………………....23 3.2 Опис структури системи………………………………………………….25 3.3 Опис моделей бази даних………………………………………………...28 4 ЕТАПИ ЖИТТЄВОГО ЦИКЛУ ПРОЕКТУ АВТОМАТИЗАЦІЇ………...32 5 ОБГРУНТУВАННЯ ВИБОРУ СЕРЕДОВИЩА РОЗРОБКИ..………....…35 5.1 Мова Java……………………………………………….……...…………35 5.2 Середовище розробки NetBeans………………………….….………….35 5.3 Середовище розробки IntelliJ IDEA……………………………………36 5.4 Середовище розробки Eclipse…………………………………………..36 5.5 Середовище розробки Jdeveloper……………………………………….36 6 ОБГРУНТУВАННЯ ВИБОРУ ОПЕРАЦІЙНОЇ СИСТЕМИ.………....….39 7 МОДЕЛЬ ОБРОБКИ ЗАПИТІВ ДО АВТОМАТИЗОВАНОЇ СИСТЕМИ ІНФОРМАЦІЙНОГО ЗАБЕЗПЕЧЕННЯ ПРОДАЖУ КВИТКІВ КІНОТЕАТРУ……………………….…………………….............…...….…43 ЧДТУ.242259 ПЗ Змн. Арк. № докум. Підпис Дата Розробив Гудков Автоматизована система Літ. Лист Листів К Керівник Чичужко інформаційного забезпечення 2 Реценазент продажу квитків кінотеатру Кафедра РСКС Н.Контро ль Пояснювальна записка гр. АКІТС-2299 Затвфердив Лукашенко В.М.. е 7.1 Вхідні дані…………………………………………………………..……43 7.2 Моделювання максимальної інтенсивності потоку заявок………...…43 7.3 Розрахунок продуктивності системи на основі математичної моделі.46 7.4 Критерії вибору апаратної платформи………………………………....47 7.5 Критерії та методи оцінки продуктивності обчислювальних систем..48 7.6 Аналіз продуктивності і вибір обчислювальної системи…………..…48 7.7 Аналіз надійності та відмовостійкості обчислювальних систем……50 8 ОПИС ІНТЕРФЕЙСУ КОРИСТУВАЧА АВТОМАТИЗОВАНОЇ СИСТЕМИ ІНФОРМАЦІЙНОГО ЗАБЕЗПЕЧЕННЯ ПРОДАЖУ КВИТКІВ КІНОТЕАТРУ………………………………………………..….52 ВИСНОВКИ……………………………………………………………………...60 СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ………………………….…...………62 ДОДАТОК:А Програмна реалізація……………………………..…………….65 Лист ЧДТУ.242259.001 ПЗ т 3 Зм. Лист № докум. Підпис Дата ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ API Application Programming Interface REST Representational State Transfer HTTP Hyper Text Transfer Protocol XML Extensible Markup Language SSL Secure Sockets Layer БСЗ Бланки суворої звітності СУБД Система управління базами даних IDE Integrated Development Environment KVM Kernel-based Virtual Machine TPC Transaction Processing Performance Council DV Domain Validation OV Organization Validation EV Extended Validation CSR Certificate Signing Request Лист ЧДТУ.242259.001 ПЗ т 4 Зм. Лист № докум. Підпис Дата ВСТУП В умовах переходу суспільного розвитку в інформаційну епоху, стає можливим створення електронної економіки, для якої характерні трохи інші правила розвитку, в порівнянні з класичною економікою. Розвиток цього виду економіки безпосередньо залежить від розвитку всесвітньої мережі Internet, яка становить інфраструктуру цього виду економіки. Проявом електронної економіки є електронний бізнес. Електронний бізнес - це те, що виходить, коли поєднуються ресурси традиційних інформаційних систем з широтою поширення Web і поєднуються ключові системи бізнесу через мережі Intranet, Extranet. У свою чергу, електронна комерція є одним із різновидів електронного бізнесу, основною суттю якої є можливість торгівлі через мережу. Метою роботи кваліфікаційної роботи бакалавра є розробка елементів автоматизованої інформаційної системи управління збутом квитків, в результаті впровадження якої підвищується швидкість бізнес-процесів організації торгівлі. Завдання роботи полягає: в огляді аналогів системи; розробці концептуальної моделі та формуванні вимог до системи; дослідженні функцій та синтезу структури системи; ознайомленні з етапами життєвого циклу проекту автоматизації; обґрунтуванні вибору середовища розробки та операційної системи; дослідженні моделі обробки запитів до автоматизованої системи інформаційного забезпечення продажу квитків кінотеатру; опису інтерфейсу користувача та обґрунтуванні вибору способу захисту інформації. Лист ЧДТУ.242259.001 ПЗ т 5 Зм. Лист № докум. Підпис Дата 1 ОГЛЯД ІСНУЮЧИХ АНАЛОГІВ ТА ТЕХНІЧНИХ РІШЕНЬ Електронна система замовлення квитків – досить важлива у роботі кінотеатру, адже після її впровадження спрощується робота кінотеатру. Зменшується навантаження на персонал, клієнти мають можливість більш зручного замовлення квитків у електронному вигляді. 1.1 Огляд системи «Multiplex» Розглянемо аналог даної системи на прикладі кінотеатру «Multiplex». Головна сторінка містить список актуальних фільмів. Рисунок 1.1 – Список фільмів Після вибору конкретного кінотеатру в лівому меню можна споглядати фільми, що показуються в даному кінотеатрі, час сеансу. Також є можливість вибрати день показу. Для того щоб здійснити замовлення, потрібно вибрати час та місце в залі. Лист ЧДТУ.242259.001 ПЗ т 6 Зм. Лист № докум. Підпис Дата Рисунок 1.2 – Схема місць Після обрання місця система пропонує способи проведення оплати. В разі успішної транзакції система пропонує скачати квитки в електронному вигляді. Для комфортної роботи, розроблювана система повинна відповідати певним вимогам. Насамперед, повинна бути можливість вибору місця на плані залу, проведення оплати онлайн, перегляд часу найближчих сеансів. 1.2 Огляд системи «Вкіно» Дана система замовлення квитків «Вкіно». Даний сервіс дозволяє замовляти квитки з будь-якого кінотеатру обраного міста. На головній сторінці сайту (рисунок 1.3) можна обрати місто або виконати пошук по назві фільму чи кінотеатру. Після обрання міста нижче з’явиться список фільмів, що доступні для показу. Вкладка «Афіша» вказує користувачу на актуальні фільми, а вкладка «Кінотеатри» на доступні кінотеатри міста. Також на головній сторінці містяться посилання на завантаження мобільних додатків. Лист ЧДТУ.242259.001 ПЗ т 7 Зм. Лист № докум. Підпис Дата Рисунок 1.3 – Головна сторінка «Вкіно» При виконанні пошуку по назві кінотеатру та його вибору, з’явиться список фільмів, що доступні для показу та час сеансів. При обранні часу сеансу відкривається вікно бронювання квитків (рисунок 1.4). Рисунок 1.4 – Бронювання квитків Після обрання місця та натискання вкладки «Купить» система переносить користувача у вікно вибору способу оплати (рисунок 1.5). Лист ЧДТУ.242259.001 ПЗ т 8 Зм. Лист № докум. Підпис Дата Рисунок 1.5 – Вибір способу оплати 1.3 Огляд системи «Kontramarka» Розглянемо систему замовлення квитків «Kontramarka». Даний сервіс дозволяє замовляти квитки на концерти, фестивалі, театральні постанови та кінопокази обраного міста. На головній сторінці сервісу (рисунок 1.6) знаходиться банер з найактуальнішими заходами а також підпункти меню для переходу до конкретного виду заходів, що цікавлять користувача. Рисунок 1.6 – Головна сторінка сервісу Лист ЧДТУ.242259.001 ПЗ т 9 Зм. Лист № докум. Підпис Дата Після переходу до вкладки «Кіно» користувач бачить список доступних фільмів з їх коротким описом, можливістю купити квиток та його ціною (рисунок 1.7). Рисунок 1.7 – Вкладка «Кіно» Після натискання кнопки «Купить билет» користувач потрапляє до сторінки, на якій розміщені сеанси з обраним фільмом (рисунок 1.8). Вибірку можна відредагувати обравши конкретний кінотеатр, дату чи час показу. Лист ЧДТУ.242259.001 ПЗ т 10 Зм. Лист № докум. Підпис Дата Рисунок 1.8 – Список сеансів фільму Після натискання на час сеансу відкривається сторінка де пропонується обрати місця та оформити замовлення (рисунок 1.9). Рисунок 1.9 – Вибір місць Лист ЧДТУ.242259.001 ПЗ т 11 Зм. Лист № докум. Підпис Дата Для оформлення замовлення система пропонує ввести електронну адресу або номер телефону (рисунок 1.10). Рисунок 1.10 – Введення контактних даних Далі система пропонує оплатити замовлення (рисунок 1.11), обравши спосіб оплати (рисунок 1.12). Лист ЧДТУ.242259.001 ПЗ т 12 Зм. Лист № докум. Підпис Дата Рисунок 1.11 – Оплата замовлення Рисунок 1.12 – Обрання способу оплати Лист ЧДТУ.242259.001 ПЗ т 13 Зм. Лист № докум. Підпис Дата 2 АНАЛIЗ ТЕХНIЧНОГО ЗАВДАННЯ 2.1 Концептуальна модель системи Програма продажу повинна бути зручною для споживача. Це означає, що вона повинна зберігати його дані і переваги. Це спрощує замовлення для постійних клієнтів і підвищує рівень їх задоволення. Слід зробити так, щоб користувачі могли шукати необхідні квитки різними способами, як за допомогою звичайного перегляду представленої продукції, так і за допомогою пошукової системи. Вся інформація, що циркулює в квитковому господарстві, структурується, і заноситися в загальну базу даних. Програма, при необхідності, сама може відстежити продажу квитків і надати звіт в електронній формі. Замість звичайних операцій з паперовими документами кожна технологічна операція проводиться відповідними співробітниками (користувачами системи) через комп'ютерну квиткову систему. Таким чином, в будь-який момент часу співробітники оперативно отримують доступ до найактуальнішої інформації із загальної бази даних, змінюючи її в ході виконання операцій; в тому числі всі звіти, аналітичні довідки тощо не зберігається, а динамічно формуються в момент запиту їх користувачами. Паперовий документ, необхідний в діяльності квиткового господарства, може бути отриманий шляхом роздруківки з системи, або в момент скоєння відповідної операції, або пізніше за явною запитом користувача. Крім цього паперовий квиток роздруковується на спеціалізованому квитковому термопринтері безпосередньо в момент видачі (продаж глядачеві касиром, видача розповсюджувачу і т.п.). Впровадження описаних принципів дозволяє не тільки автоматизувати ведення квиткового господарства, а й отримати якісно нові можливості і перспективи в своїй діяльності. Лист ЧДТУ.242259.001 ПЗ т 14 Зм. Лист № докум. Підпис Дата Основні переваги електронної системи для підприємства: − оперативний централізований контроль над усіма технологічними процесами і їх учасниками; − можливість легкої інтеграції з іншими програмно-апаратними засобами, в тому числі з системами вхідного контролю глядачів; − різні схеми обслуговування глядачів і розповсюджувачів (поточна продаж, попередній продаж, адресний продаж, повернення квитків, разові заявки, постійний договір і ін.) ; − оперативне централізоване управління поточною реалізацією квитків в реальному режимі часу; − можливості оперативної інформаційної реклами на квиткових носіях; − бухгалтерський облік операцій в квитковому господарстві; − ведення бази даних клієнтів, адресний маркетинг, збір і аналіз статистичної інформації; − повний і чіткий облік інформації по кожному заходу, глядачеві, клієнту, окремому місці, квитку; − прозорість бізнес - інформації і даних; − автоматична публікація в Інтернет, інформації з бази даних про репертуар, наявності вільних місць та вартість квитків; − можливість віддаленого замовлення квитків користувачами мережі Інтернет, в реальному часі відстежуючи статуси місць в залах; − різні варіанти оплати (за магнітними картками, за безготівковим розрахунком та ін.) ; − можливість організації видалених (мобільних) кас з використанням підключення через модем і виділені лінії. Для глядача: − можливість отримання актуальної інформації, замовлення і бронювання квитків через Інтернет; Лист ЧДТУ.242259.001 ПЗ т 15 Зм. Лист № докум. Підпис Дата − бронювання квитків для колективних замовників з виписуванням рахунків на оплату; − надання глядачеві інформаційних і рекламних послуг; − повернення квитків; − можливість різних схем оплати. 2.2 Вимоги до системи Вимоги до сервера та задачі, які повинна забезпечувати система Система фізично розташовується на одному із доступних хостинг сервісів. Веб-клієнти – користувачі Інтернет, що заходять в браузері на сайт і мають можливість придбання квитків на будь-який сеанс з цього кінотеатру. Основним завданням серверного додатку є забезпечення безпечного доступу до бази даних кінотеатру з інтернету. База даних по можливості залишається в незмінному вигляді. Кількість змін потрібно мінімізувати. Функції, які повинна забезпечувати система (API): − надання в режимі реального часу довідкової інформації кінотеатру: списки фільмів, сеансів, тарифів, знижок; − надання попереднього бронювання місця на певний час, необхідне клієнту для оплати квитка; − контроль за часом бронювання, виведення місця з броні при несплаті; − продаж квитка при оплаті квитка клієнтом, реєстрація квитка як проданого, переклад з броні в продані, занесення даних клієнта в базу; − відмова від квитка: при відмові від оплати раніше броньованого квитка - переведення квитка в ранг вільно продається. Вимоги до архітектури Систему слід реалізувати у вигляді простого веб-сервісу, що надає набір необхідних API функцій для реалізації продажу квитків і надання Лист ЧДТУ.242259.001 ПЗ т 16 Зм. Лист № докум. Підпис Дата довідкової інформації про діяльність кінотеатру. Веб-сервіс реалізується на базі сучасної архітектури RESTful WEB SERVICES. Система приймає і обробляє прості HTTP-запити, результатом яких є набір даних з вихідної бази даних, представлений у вигляді XML структури. Вимоги до захисту даних Взаємодія з сервером здійснюється за принципом запит-відповідь по захищеному протоколу передачі даних SSL (Secure Sockets Layer). Всі запити повинні надавати SSL-сертифікат, який перевіряється сервером. Якщо наданий сертифікат не відповідає еталонному або зовсім не надано, сервер не відповідає не такий запит, генеруючи виключення. Вимоги до механізму продажу квитків В першу чергу користувач системи вибирає дату, потім фільм і місця. Після цього відбувається процедура оформлення замовлення, при цьому клієнт шле на сервер запит про бронювання місць. Якщо місця успішно заброньовані, користувачеві виписується рахунок на оплату, який діє протягом певного часу. Якщо час оплати рахунку закінчується, то система здійснює виведення місць з броні. Коли користувач ініціює операцію оплати, сервер перенаправляє користувача на сторінку авторизації платіжної системи ASSIST. Відлік терміну давності рахунку тимчасово призупиняється, поки від платіжної системи не буде отримано позитивну або негативну відповідь про оплату. Якщо від платіжної системи ASSIST отримано негативну відповідь про оплату рахунку клієнтом, то відлік терміну давності рахунку відновлюється. Вимоги до модульності платіжних систем При інтеграції з платіжною системою необхідно закласти модульність платіжних систем для того, щоб була можливість заміщення поточної Лист ЧДТУ.242259.001 ПЗ т 17 Зм. Лист № докум. Підпис Дата платіжної системи іншою. Це потрібно, щоб підтримувати стабільність продажу квитків у випадках відмови роботи або частих збоїв тої чи іншої платіжної системи. Вимоги до головної сторінки Головна сторінка містить список останніх фільмів. При виборі конкретного фільму користувач потрапляє у відповідний підрозділ сайту, що дозволяє переглянути список запланованих сеансів. На сторінці також присутні посилання на придбання квитка і перегляд розкладу. Даний функціонал доступний тільки після реєстрації, тому для неавторизованих користувачів відображається форма, на якій користувач може провести первинну реєстрацію або увійти в систему. Головна сторінка містить посилання на форму зворотного зв'язку. Вимоги до розкладу сеансів Дана сторінка дозволяє користувачеві ознайомитися з розкладом сеансів, також вона ознайомлює користувача з частотою показу того чи іншого фільму та дозволяє придбати квиток. Для отримання списку необхідно вибрати день показу. Ця сторінка містить список фільмів кожне поле якого містить: − час показу; − формат показу; − тарифи. При виборі певного сеансу можливо переглянути його опис. Також розклад містить посилання, по якому користувач може перейти до придбання квитка на даний показ. Лист ЧДТУ.242259.001 ПЗ т 18 Зм. Лист № докум. Підпис Дата Вимоги до розділу «Новини» Інформаційний блок містить статті, сторонні новини та іншу інформацію. Новини впорядковані за принципом: найпізніша новина на початку. Список новин розбитий на сторінки, на кожної виводиться 5 новин, панель навігації дозволяє перегортати їх. Вимоги до розділу «Інформація» На сторінці «Інформація» представлено список різного роду статей. Всі статті для найкращого сприйняття розбиті по розділах. При кліці на заголовок стаття відкривається повністю. Веб-адміністратор може помістити на сайт будь-які статті. Цей блок містить розділ відповідей на актуальні питання, а саме: − що таке електронний квиток; − як працює наша система; − правила продажу електронних квитків; − які способи оплати підтримуються. Вимоги до розділу «Контакти» Сторінка «Контакти» містить наступну інформацію: − юридична адреса кінотеатру; − контакти служби підтримки; − схема проїзду; − контактні дані партнерів. На сторінці також розташована форма зворотного зв'язку для відправки електронного листа. Лист ЧДТУ.242259.001 ПЗ т 19 Зм. Лист № докум. Підпис Дата Вимоги до розділу «Особистий кабінет» В особистий кабінет користувача входять наступні розділи: «Мої замовлення», «Мої квитки», «Мій профіль», «Повідомлення», «Вихід». Мої замовлення. В даному розділі зберігається інформація про замовлення. Замовлення відображаються у вигляді таблиці, в якій можна переглянути дату створення замовлення, суму замовлення і статус замовлення. Також для кожного замовлення доступна інформація про фільм, на який придбаний квиток, дата його показу. Кожне замовлення можливо переглянути більш детально і роздрукувати. Мої квитки. У цьому розділі зберігається інформація про сплачені квитки. Мій профіль. Даний розділ дозволяє користувачеві змінювати персональну інформацію про себе. Дана сторінка схожа на сторінку заповнення даних при реєстрації, за винятком того, що всі дані вже заповнені і їх можна змінити. Повідомлення. Необхідно дати можливість включення / відключення розсилки повідомлень окремо по електронній пошті і за допомогою sms- повідомлень. Вихід. Вимоги до розділу «Особистий кабінет касира» Особистий кабінет касира призначений для можливості зробити повернення грошових коштів по квитку, придбаному через Інтернет-сервіс. Також касир може роздрукувати будь-який квиток куплений через систему Інтернет-продажів. Для касира створюється спеціальний обліковий запис. Лист ЧДТУ.242259.001 ПЗ т 20 Зм. Лист № докум. Підпис Дата Вимоги до розділу «Реєстрація користувачів» Попередньої реєстрації, як такої, для фізичної особи в системі не передбачено. Замість цього використовується механізм openID, що дозволяє використовувати облікові записи таких сайтів, як «Google», «Facebook». Це дозволяє користувачеві, прив'язавшись один раз до цього облікового запису, використовувати його постійно. Так як системі необхідно знати деякі дані про користувача, йому доведеться ввести їх при оформленні першого замовлення, ці поля представлені нижче. Після входу на сайт користувачеві необхідно підтвердити свій мобільний телефон. Після підтвердження він зможе робити замовлення. Підтвердження полягає у введенні на сайті згенерованого коду, отриманого на мобільний телефон. Реєстрація для юридичних осіб, касирів і т.д. виробляється вручну веб - адміністратором в розділі управління сайтом. Поля для реєстрації фізичних осіб: − прізвище; − ім`я; − по батькові; − електронна адреса; − контактний телефон; − ім'я для входу в систему; − пароль; − підтвердження пароля; − Captcha. Вимоги до авторизації користувачів Авторизація на сайті здійснюється на спеціальній сторінці, на якій користувач повинен вибрати openID провайдера. Механізм openID дозволяє користувачеві використовувати для авторизації вже існуючий акаунт. Лист ЧДТУ.242259.001 ПЗ т 21 Зм. Лист № докум. Підпис Дата На цій же сторінці знаходиться посилання, яке дозволяє провести «службовий вхід», в цьому випадку користувачеві необхідно ввести ім'я та пароль, отримані від адміністратора сайту. Вимоги до розсилки повідомлень Система включає в себе модуль розсилки повідомлень по електронній пошті. Модуль розсилки повідомлень являє собою спеціальну службу, яка відстежує найбільш важливі події системи, такі як реєстрація користувача, продаж квитка, скасування замовлення, і здійснює доставку повідомлень особам, що мають відношення до даних подій. Вимоги до формування звітів На сайті присутня можливість переглядати звіти. Звіти необхідні для отримання зведеної інформації по продажах і операціях. Вимоги до розділу керування сайтом Даний розділ дозволяє адміністратору керувати сайтом і надає йому наступні можливості: − припинення придбання квитків через певну платіжну систему в разі її відмови; − введення нового і редагування старого контенту (новини, інформація, контакти). Лист ЧДТУ.242259.001 ПЗ т 22 Зм. Лист № докум. Підпис Дата 3 ДОСЛІДЖЕННЯ ФУНКЦІЙ ТА СИНТЕЗ СТРУКТУРИ СИСТЕМИ 3.1 Опис функцій системи Автоматизована система інформаційного забезпечення продажу квитків кінотеатру повинна забезпечувати: − функціонування білетної системи; − функціонування особистого кабінету користувача; − функціонування фінансового та технічного моніторингу; − функціонування мультиканальної системи продаж; − функціонування системи контролю управління доступом. Функція даної системи повинна забезпечувати наступні підфункції: − налаштування квиткового меню під будь-яку культурно-масову установу, доступ до послуг якої здійснюється за білетами або абонементами; − ефективне управління завантаженням і розкладом будь-яких ресурсів або об'єктів: басейни, концертні зали, тренажерні зали та інше; − формування тарифних планів і спеціальних пропозицій будь-якої складності; − система інформування відвідувачів, включаючи рекламу, інформаційно-навігаційні сервіси і екстрене оповіщення; − друк квитків на бланках суворої звітності (БСЗ). − підтримка будь-яких носіїв квитків: браслети, контактні та безконтактні карти, носії штрих-кодів і QR-коди та ін.; − можливість продажу електронних квитків; − підтримка мультиканальної системи продажів: касові вузли, автомати продажу квитків, інтернет портал, мобільні додатки. Лист ЧДТУ.242259.001 ПЗ т 23 Зм. Лист № докум. Підпис Дата Функція особистого кабінету користувача повинна забезпечувати наступні підфункції: − інформація про активні послуги, договори, абонементах, квитках і історія минулих покупок; − управління індивідуальним розкладом відвідування культурно- масового установи; − довідкова, рекламна інформація і індивідуальні пропозиції; − форми зворотного зв'язку; − онлайн покупка квитків або абонементів; − інтернет версія і мобільний додаток; − додавання функціональності за індивідуальними вимогами. Функція фінансового та технічного моніторингу повинна забезпечувати наступні підфункції: − онлайн моніторинг транзакцій з продажу квитків через каси, інтернет-портал, мобільний додаток і автомат продажу квитків; − моніторинг технічного стану периферійних пристроїв: квиткових принтерів, карт-рідерів, pos-терміналів; − налаштовувана рольова система управління доступом до фінансового і технічного моніторингу; − формування фінансових звітів, звітів по технічному стану і звітів по інцидентах. Функція мультиканальної системи продаж повинна забезпечувати наступні підфункції: − продажі в спеціалізованих квиткових касах і класичних касових вузлах; − онлайн-продажі через інтернет-портал; − онлайн-продажі через мобільний додаток; Лист ЧДТУ.242259.001 ПЗ т 24 Зм. Лист № докум. Підпис Дата − продажі через автоматичні каси або автомати продажу квитків. Функція системи контролю управління доступом повинна забезпечувати наступні підфункції: − функціонування турнікетів; − функціонування мобільних пристроїв контролю проходу; − функціонування зчитувачів для безконтактних білетних носіїв; − функціонування датчиків обліку відвідувачів. 3.2 Опис структури системи Для виконання описаних вище функцій автоматизована система інформаційного забезпечення продажу квитків кінотеатру повинна складатися з наступних підсистем (рисунок 3.1): − білетної підсистеми; − підсистеми особистого кабінету користувача; − підсистеми фінансового та технічного моніторингу; − підсистеми мультиканальної системи продаж; − підсистеми контролю управління доступом. Лист ЧДТУ.242259.001 ПЗ т 25 Зм. Лист № докум. Підпис Дата Лист ЧДТУ.242259.001 ПЗ т 26 Зм. Лист № докум. Підпис Дата Рисунок 3.1 – Структура аавтоматизованої системи інформаційного забезпечення продажу квитків кінотеатру Білетна підсистема призначена для: налаштування квиткового меню під будь-яку культурно-масову установу, доступ до послуг якої здійснюється за білетами або абонементами; ефективне управління завантаженням і розкладом будь-яких ресурсів або об'єктів; формування тарифних планів і спеціальних пропозицій будь-якої складності; інформування відвідувачів, включаючи рекламу, інформаційно-навігаційні сервіси і екстрене оповіщення; друку квитків; продажу електронних квитків. Особистий кабінет користувача містить інформацію про активні послуги, договори, абонементи, квитки і історію минулих покупок, інформацію про активні послуги. Також там розміщується довідкова, рекламна інформація та індивідуальні пропозиції і є можливість онлайн покупки квитків. Підсистема фінансового та технічного моніторингу забезпечує онлайн моніторинг транзакцій з продажу квитків через каси, інтернет-портал, мобільний додаток і автомат продажу квитків; моніторинг технічного стану периферійних пристроїв: квиткових принтерів, карт-рідерів, pos-терміналів; формує фінансові звіти, звіти по технічному стану і звіти по інцидентах Підсистема мультиканальної системи продаж забезпечує продажі в спеціалізованих квиткових касах і класичних касових вузлах, онлайн-продажі через інтернет-портал, онлайн-продажі через мобільний додаток, продажі через автоматичні каси або автомати продажу квитків Системи контролю управління доступом забезпечує функціонування турнікетів, функціонування мобільних пристроїв контролю проходу, функціонування зчитувачів для безконтактних білетних носіїв, функціонування датчиків обліку відвідувачів. Лист ЧДТУ.242259.001 ПЗ т 27 Зм. Лист № докум. Підпис Дата 3.3 Опис моделей бази даних На даному етапі проектування необхідно виділити модель, що описує структуру даних, якими буде оперувати автоматизована інформаційна система. Для побудови бази даних була обрана реляційна модель даних. При проектуванні логічної моделі було виділено кілька високорівневих сутностей і зв'язків між ними, після чого модель уточнювалась, і з'явилися нові сутності, атрибути та зв'язки (рисунок 3.2). Таким чином, був реалізований спадний підхід до проектування моделі. Рисунок 3.2 - Логічна модель бази даних Дана предметна область представлена п'ятьма сутностями: − «Клієнт»; − «Бронь»; − «Зал»; − «Фільм»; − «Місце»; − «Сеанс». Кожна сутність має набір атрибутів, а також обов'язковий первинний ключ. Розглянемо докладніше кожну сутність. Лист ЧДТУ.242259.001 ПЗ т 28 Зм. Лист № докум. Підпис Дата Сутність «Клієнт» містить всю необхідну інформацію про клієнта, який бронює квитки в кінотеатр. Є незалежною від інших сутностей, не містить мігруючих атрибутів. Включає в себе «ID_клієнта» (первинний ключ і однозначно ідентифікує дану сутність), «ПІБ» і «Номер телефону». Сутність «Бронь» визначає характеристики конкретної броні. Вона містить два атрибути броні: − «Номер броні», який необхідний для її визначення. Є первинним ключем для даної суті і генерується після передачі даних від користувача; − «4 цифри номера телефону». Параметр, за яким касир в кінотеатрі може упевнитися, який клієнт забронював конкретні місця. Дана сутність пов'язана з іншими сутностями і тому включає в себе кілька мігруючих ключів інших сутностей. До них належать такі атрибути: − «ID місця» - сурогатний ключ сутності; − «Номер залу»; − «Назва фільму»; − «Час сеансу»; − «Дата сеансу». Сутність «Місце» пов'язана з сутністю «Бронь», тому що для бронювання квитка обов'язковий вибір хоча б одного місця в залі. Сутність «місце» характеризується такими атрибутами, як: − «Стан» (можливі стану «вибрано», «зайнято», «вільно»); − «Номер ряду»; − «Номер місця»; − «Номер залу». У кінотеатрі є кілька залів, і в кожному є різна кількість рядів і місць в них. Сутність «Зал» характеризує дані про залі, в якому відбуваються сеанси. Він включає в себе наступні атрибути: Лист ЧДТУ.242259.001 ПЗ т 29 Зм. Лист № докум. Підпис Дата − «Номер залу». Є первинним ключем і однозначно ідентифікує дану сутність; − «Кількість рядів залі»; − «Кількість місць в рядах». Передбачається, що зал має прямокутну форму. Сутність «Фільм» характеризує дані про фільми, які показуються в кінотеатрі. Включає в себе атрибути: − «Назва фільму». Є первинним ключем і однозначно ідентифікує дану сутність; − «Дата початку прокату»; − «Дата закінчення прокату». Сутність «Сеанс» розкриває інформацію про кожному сеансі, який проходить в кінотеатрі. Має складовою первинний ключ з полів: − назва фільму (зовнішній ключ із сутності «Фільм»); − час сеансу; − дата сеансу. Також є ще один зовнішній ключ - «Номер залу». Взаємозв'язку між таблицями можна розглянути окремо для кожних двох пов'язаних сутностей. Сутність «Бронь» і сутність «Місце» взаємопов'язані по зв'язку один до багатьох, тому що для однієї броні може існувати тільки одне місце. Якщо людина бронює відразу кілька місць, це позначається як кілька бронювань для одного клієнта. На один сеанс клієнти можуть забронювати кількість квитків, обмежені тільки їх кількістю в залі, але одна бронь створюється тільки для одного сеансу. Аналогічно пов'язані сутності «Зал» і «Сеанс». Так як в одному залі відбувається багато сеансів, але один сеанс відразу в декількох залах відбуватися не може, між ними зв'язок «один до багатьох», де ключ із сутності «Зал» мігрує в сутність «Сеанс». Лист ЧДТУ.242259.001 ПЗ т 30 Зм. Лист № докум. Підпис Дата Сутності «Клієнт» і «Бронь» пов'язані зв'язком «один до багатьох», так як кожна бронь дійсна тільки для одного клієнта, а клієнт отримує підтвердження бронювання після вибору всіх необхідних даних на сайті кінотеатру. Тому ключ мігрує із сутності «Клієнт» в сутність «Бронь» і стає там первинним. Зв'язок «один до багатьох» існує між сутностями «Фільм» і «Сеанс», так як назва фільму є однією з частин первинного ключа сутності «Сеанс», а також між сутностями «Зал» і «Місце», так як номер залу визначає кількість вільних місць у ньому. Рисунок 3.3 – Фізична модель бази даних Після вибору конкретної СУБД логічна схема БД переводиться в фізичну вже в термінах конкретної СУБД. Для даної роботи була обрана СУБД PostgreSQL. Фізична схема створеної в рамках даної роботи бази даних представлена на рисунку 3.3. Лист ЧДТУ.242259.001 ПЗ т 31 Зм. Лист № докум. Підпис Дата 4 ЕТАПИ ЖИТТЄВОГО ЦИКЛУ ПРОЕКТУ АВТОМАТИЗАЦІЇ Очевидно, що функції, виконувані розробниками проекту, в ході його розвитку зазнають змін, як, в іншому, і сам проект. Спочатку він існує у вигляді заявки на розробку, потім - як функціональні та технічні вимоги, далі - як специфікації розробляється вироби, набір програмних модулів, скомпонована з модулів система і т.д. Цей перелік можна розглядати як один з прикладів моделі життєвого циклу програмного виробу, тобто уявлення еволюції розробки і подальшого використання програмної системи. Життєвий цикл - це проекція призначеного для користувача поняття «час життя» на поняття розробника «технологічний цикл (цикл розробки)». Необхідність внесення змін до чинних програми є по суті справи продовженням розробки програмного забезпечення після передачі його користувачеві і протягом всього часу життя програм. Діяльність, пов'язана з рішенням досить численних завдань такої триваючої розробки отримала назву супроводу програмного забезпечення. Історично розвиток концепцій життєвого циклу пов'язаний з пошуком для нього адекватних моделей. Як і будь-яка інша, модель життєвого циклу є абстракцією реального процесу, в якій опущені деталі, несуттєві з точки зору призначення моделі. Різноманітність призначень визначає різноманітність моделей. Ймовірно, найпоширенішим мотивом звернення до поняття життєвого циклу є потреба в систематизації робіт відповідно до технологічного процесу. Цьому призначенню добре відповідає так звана загальноприйнята модель життєвого циклу програмного забезпечення, згідно з якою програмні системи проходять в своєму розвитку дві фази: розробку та супровід. Фази розбиваються на ряд етапів (рисунок 4.1). Лист ЧДТУ.242259.001 ПЗ т 32 Зм. Лист № докум. Підпис Дата Рисунок 4.1 - Модель життєвого циклу проекту Розробка починається з ідентифікації потреби в новому додатку, а закінчується передачею об’єкту розробки в експлуатацію. Першим етапом фази розробки є постановка завдання і визначення вимог. Визначення вимог включає опис загального контексту завдання, очікувані функцій системи і її обмежень. На цьому етапі замовник спільно з розробниками приймає рішення, чи варто робити систему. У разі позитивного рішення починається етап специфікації вимог. Розробники програмного забезпечення намагаються осмислити висунуті замовником вимоги і зафіксувати їх у вигляді специфікацій системи. Важливо підкреслити, що призначення цих специфікацій - описувати зовнішня поведінка системи, що розробляється, а не її внутрішню організацію, тобто відповідати на питання, що вона повинна робити, а не як це буде реалізовано. Тут йдеться про призначення, а не про форму специфікацій, оскільки на практиці при відсутності відповідного мови Лист ЧДТУ.242259.001 ПЗ т 33 Зм. Лист № докум. Підпис Дата специфікацій, на жаль, нерідко доводиться вдаватися до опису «що» за допомогою «як». Перш ніж приступати до створення проекту по специфікаціям, вони повинні бути ретельно перевірені на відповідність вихідним цілям, повноту, сумісність (несуперечливість) і однозначність. Розробка проектних рішень, що відповідають на питання як, повинна бути реалізована система, щоб вона могла задовольняти специфікованою вимогам, виконується на етапі проектування. Оскільки складність системи в цілому може бути дуже великою, головним завданням цього етапу є послідовна декомпозиція системи до рівня очевидно реалізованих модулів або процедур. На наступному етапі реалізації, або кодування кожен з цих модулів програмується на своєму найкращому для цього додатка мовою. З точки зору автоматизації цей етап традиційно є найбільш розвиненим. Далі фаза розробки закінчується етапом тестування і передачею системи в експлуатацію. Фаза експлуатації і супроводу включає в себе всю діяльність щодо забезпечення нормального функціонування програмних систем, в тому числі фіксування розкритих під час виконання програм помилок, пошук причин і їх виправлення, підвищення експлуатаційних характеристик системи, адаптацію системи до навколишнього середовища, а також, при необхідності, і більш суттєві роботи по вдосконаленню системи. У зв'язку з цим дана фаза розбивається на два етапи: власне супровід і розвиток. У ряді випадків на дану фазу припадає більша частина коштів, які витрачаються в процесі життєвого циклу програмного забезпечення. Таким чином, даний проект по автоматизації містить сім етапів, розділених в часі. Лист ЧДТУ.242259.001 ПЗ т 34 Зм. Лист № докум. Підпис Дата 5 ОБГРУНТУВАННЯ ВИБОРУ СЕРЕДОВИЩА РОЗРОБКИ На сьогодні існує великий вибір засобів розробки програмних продуктів призначених для автоматизації інформаційного забезпечення продажу обліку та контролю квитків. Розгленемо декілька основних середовищ для розробки. 5.1 Мова Java Java - сильно типізованвана об'єктно-орієнтована мова програмування, розроблена компанією Sun Microsystems (в подальшому придбаною компанією Oracle). В даний час проект належить OpenSource і поширюється за ліцензією GPL. У OpenJDK вносять вклад великі компанії, такі як - Oracle, RedHat, IBM, Google, JetBrains. Так само на основі OpenJDK ці компанії розробляють свої збірки JDK. Як стверджує компанія Oracle - відмінності між OpenJDK і OracleJDK практично відсутні за винятком ліцензії, відтворення шрифтів в Swing та деяких бібліотек, на які ліцензія GPL не поширюється. Програми Java зазвичай транслюються в спеціальний байт- код, тому вони можуть працювати на будь-якій комп'ютерній архітектурі за допомогою віртуальної Java-машини. Дата офіційного випуску - 23 травня 1995 року. На 2019 рік Java - одна з найпопулярніших мов програмування. 5.2 Середовище розробки NetBeans NetBeans - найпотужніша середовище розробки з відкритим вихідним кодом, орієнтована на інтернет, мобільні і настільні додатки. Працює з Linux, Windows, MacOS і навіть Oracle Solaris. Незважаючи на те, що NetBeans дозволяє працювати на декількох мовах, в середовищі розробників вона вважається Java-орієнтованою. Вона прекрасно взаємодіє з JPA, JSP, Struts, Spring і бібліотекою Hibernate. Лист ЧДТУ.242259.001 ПЗ т 35 Зм. Лист № докум. Підпис Дата 5.3 Середовище розробки IntelliJ IDEA По правді кажучи, IntelliJ IDEA поширюється в двох версіях, одна з яких абсолютно безкоштовна - Free Community Edition. Причому для початківця розробника даного пакета вистачить з головою. У платній же версії ви отримуєте підтримку фреймворків Spring (Spring MVC framework, Spring Security, Spring Boot, Spring Integration і т. Д.), Node.js, Angular React, Grails, можливість використовувати додаткові мови (javascript, typescript, coffeescript) і взаємодіяти майже зі семи популярними серверами (Tomcat, TomEE, GlassFish, JBoss, WildFly, Weblogic, WebSphere, Geronimo, Virgo і т. д.). 5.4 Середовище розробки Eclipse Точну цифру привести практично неможливо, але практично будь-який Java-розробник з досвідом роботи понад 2 роки стикався з цією IDE. Переможцем у цій номінації Eclipse вдалося стати завдяки великої спільноти, тонні корисної інформації і незліченній кількості плагінів. Як і з попередніми екземплярами, Eclipse підтримує кілька мов, але сприймається як прихильник Java. 5.5 Середовище розробки JDeveloper Ще один продукт від Oracle з масою переваг, серед яких підтримка системи контролю версій і хмарного сервісу Oracle, він упакований SQL Developer, PL / SQL оброблювачем запитів, WebLogic Server, редакторами HTML, CSS, JavaScript, JSF, JSP, WSDL і ще величезною кількістю всіляких корисностей. Через те, що Internet-технології в своїй більшості є відкритими технологіями, для розробки самих доповнень можна використовувати будь- який текстовий редактор. Але для розробки додатків даної кваліфікаційної Лист ЧДТУ.242259.001 ПЗ т 36 Зм. Лист № докум. Підпис Дата роботи використовувався професійний пакет розробки Web-сторінок IntelliJ IDEA, який поєднує в собі швидкість візуальної розробки сайтів і точність ручної розробки. В якості мови використовується Java - потужна мова програмування, що підтримує безліч платформ. Вона є зручною і надійною для розробки серверних додатків. Для зберігання і вибірки даних використовується СУБД PostgreSQL. Вона як і більшість інших СУБД використовують SQL як мови запитів. SQL добре адаптований і простий у вивченні. Однак кожен оператор SQL виконується індивідуально на сервері бази даних. Це означає, що наший клієнтський додаток повинен кожен запит відправляти на сервер, чекати поки він буде оброблений, отримувати результат, робити деякі обчислення, потім відправляти наступні запити на сервер. Все це вимагає взаємодії між процесами, а також несе навантаження на мережу, якщо клієнт і сервер бази даних розташовані на різних комп'ютерах. PL / pgSQL дозволяє згрупувати блок обчислень і послідовність запитів всередині сервера бази даних, таким чином, ми отримуємо силу процедурної мови і простоту використання SQL при значній економії накладних витрат на клієнт-серверну взаємодію: − виключаються додаткові звернення між клієнтом і сервером; − проміжні непотрібні результати не передаються між сервером і клієнтом; − є можливість уникнути численних аналізів одного запиту. В результаті це призводить до значного збільшення продуктивності в порівнянні з додатком, яке не використовує збережених функцій. Крім того, PL / pgSQL дозволяє використовувати всі типи даних, оператори і функції SQL. Також використовується безкоштовний HTTP- Лист ЧДТУ.242259.001 ПЗ т 37 Зм. Лист № докум. Підпис Дата сервер Tomcat, який зарекомендував себе як безпечний, надійний, швидкий сервер з можливістю підключення модулів розширення. Для розмітки Web-сторінок використовувати мову гіпертекстової розмітки HTML (HyperText Markup Language). Сама мова реалізована у вигляді дескрипторів маркерів, які описують розміщення елементів сторінки, а також додаткові характеристики кожного елемента. Лист ЧДТУ.242259.001 ПЗ т 38 Зм. Лист № докум. Підпис Дата 6 ОБҐРУНТУВАННЯ ВИБОРУ ОПЕРАЦІЙНОЇ СИСТЕМИ В якості операційної системи на якій планується функціонування автоматизованої системи інформаційного забезпечення продажу квитків кінотеатру пропонується операційна система Red Hat Enterprise Linux Server. Дистрибутивів Linux, які можуть використовуватися в серйозних компаніях і мають хорошу підтримку не так багато. Це Ubuntu від Canonical, Red Hat Enterprise Linux і SUSE Linux. Ці дистрибутиви підтримуються не розробниками любителями, а серйозними компаніями, тому можна розраховувати на те, що вони більш стабільні і будуть своєчасно отримувати оновлення. А зараз ми більш детально розглянемо продукт компанії Red Hat - Red Hat Linux Enterprise. Red Hat Linux - це один з найстаріших дистрибутивів Linux, який був заснований в 1993 році. Як інші давні дистрибутиви, Red Hat Linux має багато послідовників, наприклад: Caldera, Mandrake, TurboLinux, Yellow Dog і Red Flag. У 2003 році Red Hat Linux розділився на дві редакції - Red Hat Enterprise Linux і Fedora Linux, це провело чітку грань між комерційною та безкоштовною версією. Fedora - це 100% вільне програмне забезпечення, в ній містяться всі найновіші технології і в той же час, це хороша система для персонального комп'ютера. Red Hat Enterprise Linux забезпечує дуже високу надійність і великий термін підтримки. Кожен випуск підтримується протягом 10 років. Користувачі Red Hat 5 можуть придбати розширену підтримку протягом більш ніж 10 років. Вихідний код Red Hat Linux повністю відкритий, і будь-хто може його повністю безкоштовно завантажувати або поширювати і навіть створювати конкурентні відгалуження. Наприклад, CentOS і Scientific Linux - це популярні відгалуження, що використовують кодову базу Red Hat практично Лист ЧДТУ.242259.001 ПЗ т 39 Зм. Лист № докум. Підпис Дата без змін. Oracle має свою систему, засновану на вихідному коді Red Hat - Oracle Unbreakable Linux. Це точно той же Red Hat Linux, тільки з можливістю використання ядра від Oracle з різними патчами для збільшення безпеки. Користувачі Linux звикли отримувати все програмне забезпечення безкоштовно, не дивлячись на те, що це не є обов'язковою вимогою більшості ліцензій вільного програмного забезпечення. Але Red Hat - платна операційна система. Але є три способи отримати дистрибутив безкоштовно повністю легально: − ви можете зібрати систему з вихідних кодів, хоча це і не зовсім просте завдання; − можна використовувати одне з відгалужень на основі Red Hat, яка вже надає всі готові пакети, наприклад, CentOS; − завантажити образ системи можна на офіційному сайті, але для цього вам потрібно зареєструватися учасником програми для розробників. Ця версія точно така ж, як і платна, тут використовуються ті ж репозиторії і інструменти, наприклад, менеджер підписок і портал клієнтів Red Hat. Але ви не зможете використовувати систему в якості сервера, тільки для тестування і розробки. Також можна купити Red Hat Linux якщо ви хочете систему для серверів і у вас є достатньо коштів. Компанія Red Hat випускає кілька редакцій своєї системи для використання в різних областях. Є версії для JBoss Middleware, сервера KVM (Kernel-based Virtual Machine), хмари, сховища, мобільної розробки, платформ управління, настільних комп'ютерів, інтернету речей і звичайно ж сервера. Ця операційна система може працювати на всьому, починаючи від пристроїв що вбудовані і до суперкомп'ютерів. У Red Hat є навіть спеціальна система Atomic Host для популярних зараз контейнерів. Це спеціально оптимізована Red Hat 7 для управління Лист ЧДТУ.242259.001 ПЗ т 40 Зм. Лист № докум. Підпис Дата контейнерами Docker. Atomic Host спрощує створення і розгортання контейнерів, забезпечуючи центральну консоль управління, в якій є таке програмне забезпечення, як: Docker, Kubernetes, SELinux, Systemd і інші стандартні компоненти. Red Hat має партнерські відносини з багатьма великими компаніями в сфері інформаційних технологій, це Dell, SAP, Cisco, Hewlett-Packard, Intel, IBM, Amazon і навіть Microsoft. Як і в більшості проектів вільного програмного забезпечення ви отримуєте функціональну сумісність, а не зав'язаність на тому чи іншому апаратному забезпеченні. У Red Hat Linux є версія системи для робочого столу і робочих станцій, але про них не так багато чутно. Red Hat дуже добре показує себе на робочому столі, це безпечна і стабільна операційна система, проста в налаштуванні і управлінні. Для звичайних користувачів тут є один мінус - не завжди можна отримати найновішу версію програмного забезпечення, адже в дистрибутив потрапляють тільки добре налагоджені версії. Але для підприємств це в самий раз. У цій системі використовується система управління пакетами на основі rpm. Вона дуже схожа на deb але відрізняється деякими особливостями реалізації. Відмінностей у функціональності мінімум, хіба що, трохи менше програм, ніж для формату deb. За замовчуванням система поставляється з великою кількістю різного програмного забезпечення. В якості системи забезпечення безпеки використовується SELinux. Red Hat дуже добре попрацювала над безпекою своєї системи, були створені навіть різні профілі безпеки, що містять набори правил SELinux, для різних ситуацій. Для настройки iptables в Red Hat використовується утиліта firewalld, це не окремий брандмауер, а просто ще одна надбудова над iptables. Він спрощує настройку і реалізує деякі додаткові функції. Лист ЧДТУ.242259.001 ПЗ т 41 Зм. Лист № докум. Підпис Дата Система ініціалізації - systemd. Саме RedHat була одним з ініціаторів переходу Linux дистрибутивів на Systemd, як і зараз намагається прискорити перехід на wayland включенням його в Fedora за замовчуванням. Як оточення робочого столу використовується Gnome 3 з усім його стеком програм. Тут є офісний пакет LibreOffice, браузер Firefox, Gnome Музика, Gnome Відео, Empathy і інше програмне забезпечення, яке може знадобитися при повсякденній роботі. В якості файлової системи за умовчанням пропонується використовувати XFS. Вона дає максимальну продуктивність при роботі з великими файлами. Основний мінус Red Hat Linux - це досить старі версії програмного забезпечення. Це відбувається через те, що система повинна містити тільки стабільні програми, а щоб переконатися в стабільності і дочекатися виправлення всіх проблем потрібно деякий час. Хоча це може викликати деякі проблеми. Наприклад, Red Hat 6 містить в своєму складі PHP 5.3.3, а Red Hat 7 - 5.4. Обидві версії вже застаріли, не підтримуються і небезпечні. Red Hat портує виправлення безпеки, але більшість нових проектів вимагають більш нової версії php. Підтримка у Red Hat дуже якісна і, як правило, отримує дуже багато позитивних відгуків від користувачів. Також компанія пропонує повний набір навчальних і сертифікованих курсів. Вони спеціально розраховані на програмне забезпечення Red Hat але основні аспекти Linux всюди однакові. Також у Red Hat є відмінна документація по операційній системі. Це відмінна операційна система, особливо для корпоративних користувачів. Крім того, в якості CentOS вона може стати відмінним рішенням для користувачів домашніх комп'ютерів. Лист ЧДТУ.242259.001 ПЗ т 42 Зм. Лист № докум. Підпис Дата 7 МОДЕЛЬ ОБРОБКИ ЗАПИТІВ ДО АВТОМАТИЗОВАНОЇ СИСТЕМИ ІНФОРМАЦІЙНОГО ЗАБЕЗПЕЧЕННЯ ПРОДАЖУ КВИТКІВ КІНОТЕАТРУ 7.1 Вхідні дані Продуктивність системи визначається виходячи з кількості запитів до баз даних, яке, в свою чергу, залежить від загального числа користувачів системи. Кількість місць в кінотеатрі становить 350, кількість сеансів в день може становити до 10. Таким чином, кількість проданих квитків за день складе не більше 350 * 10 = 3500. Кількість клієнтів, які звернулися до системи для отримання інформації або для придбання квитків, може значно перевищувати кількість квитків для продажу. В якості вихідних даних для розрахунку продуктивності системи (з урахуванням збільшення кількості користувачів) покладемо: AskUserDay = 17 - середня кількість запитів до системи на одного користувача в день; N = 10000 - кількість користувачів системи. 7.2 Моделювання максимальної інтенсивності потоку заявок Кількість запитів на тиждень визначиться як: AskWeek = N * AskUserDay * 5 (7.1) де, AskWeek - кількість запитів в тиждень. Виходячи з (7.1) кількість запитів в тиждень складе 850000. Лист ЧДТУ.242259.001 ПЗ т 43 Зм. Лист № докум. Підпис Дата Припустимо, що інтенсивність запитів по днях тижня відповідає нормальному розподілу, містить деяку постійну складову і описується функцією: (7.2) де, day(d) - денна інтенсивність потоку запитів (кількість запитів в день); AskWeek - кількість запитів за тиждень; d - час (день тижня); - математичне очікування (час максимального потоку); - середньоквадратичне відхилення; k1, k2 - коефіцієнти співвідношення постійної і нормальної складових потоку запитів. Графік розподілу інтенсивності потоку заявок по днях тижня наведено на рисунку 7.1. 5 5 10 500000 5 4.5 10 4 5 10 5 3.5 10 5 3 10 5 day(d) 2.5 10 2 5 10 1.5 5 10 5 1 10 5 4 10 0 0 1 2 3 4 5 0 d 5 Рисунок 7.1 - Розподіл інтенсивності потоку заявок по днях тижня Лист ЧДТУ.242259.001 ПЗ т 44 Зм. Лист № докум. Підпис Дата Максимальна інтенсивність потоку запитів припадає на 3-й день робочого тижня. Проинтегрировав функцію (7.2) на ділянці 2-3 отримаємо кількість запитів до БД протягом 3-го дня: (7.3) де M - кількість запитів до системи протягом 3-го дня. Розрахунки показують, що кількість запитів до системи протягом 3-го дня може скласти до 215 565 запитів. Інтенсивність потоку заявок протягом дня також розподіляється нерівномірно. Припустимо, що інтенсивність запитів протягом дня також відповідає нормальному розподілу, містить два виражених максимуму (дообідній і післяобідній) і описується функцією: (7.4) Графік розподілу інтенсивності потоку заявок протягом дня наведено на рисунку 7.2. 2000 max = 1738 1600 1200 ( t) 800 400 0 1 2 3 4 5 6 7 8 t Рисунок 7.2 - Розподіл інтенсивності потоку заявок протягом дня Лист ЧДТУ.242259.001 ПЗ т 45 Зм. Лист № докум. Підпис Дата Розрахунки показують, що максимальна інтенсивність потоку заявок протягом дня може скласти до 1738 заявок на хвилину. 7.3 Розрахунок продуктивності системи на основі математичної моделі Для оцінки продуктивності системи скористаємося показником tpmC, який представляє пікову швидкість виконання транзакцій (виражається в кількості транзакцій в хвилину). На обробку одного запиту доводиться в середньому до 50 транзакцій (http://www.bizcom.ru/rus/texts/abs_evt-4.htm), не рахуючи необхідних для забезпечення збереження даних і безпеки. Таким чином, середня продуктивність обчислювального комплексу по тесту TPC (з урахуванням продуктивності СУБД) повинна бути не нижче, ніж 86 910 транзакцій в хвилину. Система повинна мати певну надмірність обчислювальних ресурсів. Продуктивність комплексу повинна перевищувати як середню заплановану продуктивність системи, так і плановану пікову продуктивність. Середня планована продуктивність системи повинна складати не більше 35-40% від необхідної розрахункової продуктивності. Пікова продуктивність повинна складати 90% від необхідної розрахункової продуктивності (http://www.spb.sterling.ru/services/cc/about/index.htm). З урахуванням вищесказаного продуктивність системи повинна складати: 86910 / 0.9 = 96567 транзакцій за хвилину. Лист ЧДТУ.242259.001 ПЗ т 46 Зм. Лист № докум. Підпис Дата 7.4 Критерії вибору апаратної платформи Вибір тієї чи іншої апаратної платформи і конфігурації визначається рядом загальних вимог, які пред'являються до характеристик сучасних обчислювальних систем (http://www.citforum.ru/database/skbd/glava_2.shtml). До них відносяться: − відношення вартість / продуктивність; − надійність та відмовостійкість; − масштабованість; − сумісність і мобільність програмного забезпечення. Відношення вартість / продуктивність. Для порівняння різних комп'ютерів між собою зазвичай використовуються стандартні методики вимірювання продуктивності. Ці методики дозволяють розробникам і користувачам використовувати отримані в результаті випробувань кількісні показники для оцінки тих чи інших технічних рішень, і, врешті-решт, саме продуктивність і вартість дають раціональну основу для вирішення питання, яку систему вибрати. Надійність і відмовостійкість. Підвищення надійності засноване на принципі запобігання несправностей шляхом зниження інтенсивності відмов і збоїв за рахунок застосування електронних схем і компонентів з високої і надвисокої ступенем інтеграції, зниження рівня перешкод, полегшених режимів роботи схем, забезпечення теплових режимів їх роботи, а також за рахунок вдосконалення методів збірки апаратури . Відмовостійкість - це властивість обчислювальної системи, що забезпечує можливість продовження дій, заданих програмою, після виникнення несправностей. Введення відмовостійкості вимагає надлишкового апаратного і програмного забезпечення. Масштабованість є можливість нарощування числа і потужності процесорів, обсягів оперативної і зовнішньої пам'яті і інших ресурсів Лист ЧДТУ.242259.001 ПЗ т 47 Зм. Лист № докум. Підпис Дата обчислювальної системи. Масштабованість повинна забезпечуватися архітектурою і конструкцією обчислювальної системи, а також відповідними засобами програмного забезпечення. Сумісність і мобільність програмного забезпечення. Підхід, що дозволяє зберігати існуючий заділ програмного забезпечення під час переходу на нові більш продуктивні моделі комп'ютерів. 7.5 Критерії та методи оцінки продуктивності обчислювальних систем Продуктивність обчислювальної системи можна оцінити або за часом, за який виконується певний обсяг роботи, або за кількістю операцій (команд, транзакцій) виконуваних за одиницю часу. В даний час для оцінки продуктивності комп'ютерних систем застосовують показники MIPS, MFLOPS (GFLOPS) і системи тестів SPEC, TPC і ін.. 7.6 Аналіз продуктивності і вибір обчислювальної системи Аналіз продуктивності обчислювальних систем виконаний на основі рейтингів, отриманих в результаті виконання тестів TPC. У таблиці 7.1 наведені рейтинги тестів TPC для НЕ кластерних рішень. Лист ЧДТУ.242259.001 ПЗ т 48 Зм. Лист № докум. Підпис Дата Таблиця 7.1 - Рейтинги тестів TPC. Не кластерні рішення Rank 1 2 3 4 Company TTA TTA TTA TTA KTNF Jet-speed UNIWIDE System ATEC A208G2 KR580S1 HHA2212 RC124 Performance 152,33 139,909 76,172 76,168 (tpmC) Price/tpmC 1.42 USD 1.46 USD 2.75 USD 2.72 USD Watts/KtpmC NR NR NR NR System 11/20/18 05/09/17 11/23/18 11/23/18 Availability Goldilocks v3.1 Goldilocks v3.1 Goldilocks v3.1 Goldilocks v3.1 Database Standard Standard Standard Edition Standard Edition Edition Edition Red Hat Red Hat Red Hat Operating Enterprise Enterprise CentOS 6.6 Enterprise Linux System Linux Server Linux Server Server 7.5 7.5 7.5 JBoss Web Red Hat JBOSS JBoss Web JBoss Web TP Monitor Server 3.1 Web Server Server 3.1 Server 3.1 Date 11/19/18 05/08/17 11/22/18 11/22/18 Submitted Оцінка обчислювальних систем проводиться за показником tpm-C, який представляє пікову швидкість виконання транзакцій (виражається в кількості транзакцій в хвилину). Додатковим показником є $ / tpm-C, який представляє собою нормалізовану вартість системи (вартість однієї транзакції). Лист ЧДТУ.242259.001 ПЗ т 49 Зм. Лист № докум. Підпис Дата На підставі таблиці 7.1, можна зробити висновок, що автоматизована система інформаційного забезпечення продаж квитків кінотеатру може бути реалізована на основі систем KTNF KR580S1 або Jet-speed HHA2212 фірми TTA. Характеристики системи KTNF KR580S1 наведені в таблиці 7.2. Таблиця 7.2 - Характеристики системи KTNF KR580S1 фірми TTA Total System Cost: 215 793 USD Performance: 152,330 tpmC Price/Performance: 1.42 USD per tpmC Database Manager: Goldilocks v3.1 Standard Edition Operating System: Red Hat Enterprise Linux Server 7.5 Transaction Monitor: JBoss Web Server 3.1 CPU Type: Intel Xeon Silver 4114 - 2.20 GHz Total # of Processors: 2 Total # of Cores: 20 Total # of Threads: 40 7.7 Аналіз надійності та відмовостійкості обчислювальних систем Зниження часу простою системи може бути досягнуто за рахунок підвищення готовності. Одиницею вимірювання є коефіцієнт готовності, який визначає ймовірність перебування системи в працездатному стані в будь-який момент часу. Лист ЧДТУ.242259.001 ПЗ т 50 Зм. Лист № докум. Підпис Дата Сервер Sun Enterprise 10000 (Starfire), забезпечує в одному вузлі доступність на рівні 99,95% - результат, якого інші виробники досягають тільки на кластерних системах. Високим ступенем готовності відрізняються кластерні рішення. За різними джерелами готовність кластерних рішень оцінюється на рівні 99.95- 99.999%. Кластерна архітектура S / 390 Parallel Sysplex дозволяє досягти ступеня доступності ресурсів системи в п'ять дев'яток, т. Е. 99,999%, що становить 5 хвилин простою (відсутність відгуку системи) в рік. Кластер АТ «Невська косметика» має надійність 99,997%. На основі вище викладеного можна зробити висновок про приблизно однаковий рівень надійності систем, побудованих на кластерних рішеннях або на машинах класу «мейнфрейм». Лист ЧДТУ.242259.001 ПЗ т 51 Зм. Лист № докум. Підпис Дата 8 ОПИС ІНТЕРФЕЙСУ КОРИСТУВАЧА АВТОМАТИЗОВАНОЇ СИСТЕМИ ІНФОРМАЦІЙНОГО ЗАБЕЗПЕЧЕННЯ ПРОДАЖУ КВИТКІВ КІНОТЕАТРУ Інтерфейс автоматизованої системи інформаційного забезпечення продажу квитків кінотеатру призначений для управління автоматизованою системою та складається з наступних частин: − інтерфейсу користувача; − інтерфейсу системного адміністратора; − інтерфейсу менеджера кінотеатру; − інтерфейсу бухгалтера; − меню інтерфейсу обслуговуючого персоналу. 8.1 Головне меню інтерфейсу користувача Головне меню інтерфейсу користувача призначене для управління квитковою підсистемою, особистим кабінетом, та складається з наступних пунктів (рисунок 8.1): − репертуар; − профіль. − контакти; − допомога; − про нас; − правила; − новини. В пункті «Контакти» знаходиться інформація для зв’язку з адміністрацією кінотеатру. Пункт «Допомога» містить відповіді на найпоширеніші запитання. Сторінка «Про нас» містить інформацію про кінотеатр, обладнання, що використовується. На сторінці «Правила» описано Лист ЧДТУ.242259.001 ПЗ т 52 Зм. Лист № докум. Підпис Дата правила поводження в кінотеатрі та покупки квитків. Після переходу на сторінку «Новини» користувачу буде представлена інформація про найважливіші події та життя кінотеатру. Рисунок 8.1 – Головне меню На головній сторінці можна бачити банер з найактуальнішими фільмами їх жанри та тривалість. Також можна переглянути трейлер натиснувши на відповідну кнопку. Для реєстрації та входу на сайт потрібно зайти у пункт профіль та вибрати необхідний підпункт (рисунок 8.2). Рисунок 8.2 – Підпункти кнопки «Профіль» Лист ЧДТУ.242259.001 ПЗ т 53 Зм. Лист № докум. Підпис Дата При переході до пункту реєстрації відкривається сторінка вводу електронної адреси та паролю (рисунок 8.3). Рисунок 8.3 – Сторінка реєстрації Після введення електронної адреси та паролю на наступній сторінці потрібно ввести ім’я, прізвище та номер телефону (рисунок 8.4). Рисунок 8.4 – Введення імені, прізвища та номера телефону Лист ЧДТУ.242259.001 ПЗ т 54 Зм. Лист № докум. Підпис Дата Наступне вікно повідомляє користувача про необхідність перевірки електронної пошти для активації акаунту (рисунок 8.5). Рисунок 8.5 – Інформаційне повідомлення Після переходу за посиланням, що прийшло на електронну пошту відкривається сторінка активації акаунту (рисунок 8.6). Рисунок 8.6 – Сторінка активації облікового запису Після входу в акаунт зміниться вигляд та вміст пункту «Профіль» (рисунок 8.7). Лист ЧДТУ.242259.001 ПЗ т 55 Зм. Лист № докум. Підпис Дата Рисунок 8.7 – Пункти керування обліковим записом У пункті «Мій обліковий запис» можна переглянути та відредагувати дані користувача. Після натискання кнопки відредагувати вміст полів можна змінити та зберегти (рисунок 8.8). Рисунок 8.8 – Дані про користувача У вкладці «Репертуар» знаходяться актуальні фільми та розклад їх показу (рисунок 8.9). Лист ЧДТУ.242259.001 ПЗ т 56 Зм. Лист № докум. Підпис Дата Рисунок 8.9 – Вміст пункту «Репертуар» Після вибору часу сеансу відкривається сторінка вибору місця в залі (рисунок 8.10). Рисунок 8.10 – Вибір місця Лист ЧДТУ.242259.001 ПЗ т 57 Зм. Лист № докум. Підпис Дата Після натискання готово система показує суму, яку потрібно буде сплатити, час показу, назву фільму та адрес електронної пошти, на який прийдуть квитки (рисунок 8.11). Рисунок 8.11 – Підведення підсумків На наступній сторінці виконується оплата (рисунок 8.12). Лист ЧДТУ.242259.001 ПЗ т 58 Зм. Лист № докум. Підпис Дата Рисунок 8.12 – Виконання оплати Лист ЧДТУ.242259.001 ПЗ т 59 Зм. Лист № докум. Підпис Дата ВИСНОВКИ В даній кваліфікаційній роботі бакалавра розглянуто створення автоматизованої системи інформаційного забезпечення продажу квитків кінотеатру. В першому розділі розглянуто аналоги інформаційних систем продажу квитків на прикладі систем «Multiplex», «Вкіно» та «Kontramarka». В другому розділі описано концептуальну модель розроблюваної системи та сформовано вимоги до архітектури, захисту даних, механізму продажу квитків. Описано вимоги до системи, які полягають в наданні попереднього бронювання місця на певний час, продажі квитка при оплаті квитка клієнтом, наданні в режимі реального часу довідкової інформації кінотеатру. В третьому розділі проведено дослідження функцій та синтез структури системи, яка складається із білетної підсистеми, підсистеми особистого кабінету користувача, підсистеми фінансового та технічного моніторингу, підсистеми мультиканальної системи продаж, підсистеми контролю управління доступом. Описано моделі бази даних. В четвертому розділі описано етапи життєвого циклу проекту автоматизації, які полягають в визначенні вимог, специфікації вимог, проектуванні, реалізації, тестуванні, супроводі, розвитку. В п’ятому розділі описано обґрунтування вибору середовища розробки. Описано мову програмування, систему керування базами даних, та мову гіпертекстової розмітки HTML. В шостому розділі описано обґрунтування вибору операційної системи. Описано характеристики дистрибутиву, способи його отримання, плюси та мінуси. В сьомому розділі описано модель обробки запитів до автоматизованої системи інформаційного забезпечення продажу квитків кінотеатру, виконано Лист ЧДТУ.242259.001 ПЗ т 60 Зм. Лист № докум. Підпис Дата розрахунок необхідної продуктивності системи та обрано, на основі розрахунку апаратну платформу, на якій планується реалізувати автоматизовану систему інформаційного забезпечення продажу квитків кінотеатру. В восьмому розділі описано інтерфейс користувача автоматизованої системи інформаційного забезпечення продажу квитків кінотеатру. Розглянуто реєстрацію, авторизацію, вибір місця та покупку квитків. В подальшому планується розвиток автоматизованої системи інформаційного забезпечення продажу квитків кінотеатру в напрямку розширення сервісних функцій, які створюють додаткові зручності та покращують якість обслуговування клієнта. Також планується розширити можливості системи до обслуговування групи кінотеатрів, в перспективі, кінотеатрів цілого міста. Лист ЧДТУ.242259.001 ПЗ т 61 Зм. Лист № докум. Підпис Дата СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 1. Advatages of Java at ibm.com. [Електронний ресурс].– Режим доступу: https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/performance /advantages_java.html 2. Spring | Home. [Електронний ресурс].– Режим доступу: https://spring.io/ 3. PostgreSQL : About. [Електронний ресурс].– Режим доступу: https://www.postgresql.org/about/ 4. MVC Pattern -Anshul vyas - Medium. [Електронний ресурс].– Режим доступу: https://medium.com/@anshul.vyas380/mvc-pattern-3b5366e60ce4 5. MVC Design Pattern – JournalDev. [Електронний ресурс].– Режим доступу: https://www.journaldev.com/16974/mvc-design-pattern 6. What is REST – Learn to create timeless REST APIs. [Електронний ресурс].– Режим доступу: https://restfulapi.net/ 7. Boyko V. Increase of measuring systems accuracy / V. Boyko, A. Zori, [and at.]. – Donetsk: RVV DonNTU, 2017. – 276 p. 8. Браткевич В. В. Інформатика. Комп’ютерна техніка. Комп’ютерні технології: Підручник для студ. вищих навч. закладів / В. В. Браткевич, М. В. Бутов, І. О. Золотарьова. – К.: ВЦ Академія, 2019. – 704 с. 9. Буйницька О. П. Інформаційні технології та технічні засоби навчання. Навч. посіб. / О. П. Буйницька – К.: Центр учбової літератури, 2018. – 240 с 10. Зорі А.А. Вступ до фаху з електроніки та комп’ютерної інженерії: навч.посібник./ В.М.Лукашенко, В.М.Співак, М.В.Чичужко, 2016.- 312 с. 11. Дибкова Л. М. Інформатика і комп’ютерна техніка: Навч. посібник / Л. М. Дибкова. – 3- тє вид., доп. – К.: Академвидав, 2018.– 464 с. Лист ЧДТУ.242259.001 ПЗ т 62 Зм. Лист № докум. Підпис Дата 12. Інформатика. Комп’ютерна техніка. Комп’ютерні технології: Підручник для студентів вищих навч. закладів / За ред. О. І. Пушкаря. – К.: Видавничий центр «Академія», 2019. 13. Левшин М. М. Практикум для користувачів персональних комп’ютерів: Посібник для студентів неспеціальних факультетів / М. М. Левшин, Ю. З. Прохур, Р. Я. Ріжняк, Т. В. Фурсикова; За ред. М. М. Левшина. – Тернопіль: Навч. книга – Богдан, 2017.– 244 с 14. Морзе Н. В. Основи інформаційно-комунікаційних технологій / Н. В. Морзе. – К. : Видавнича група BHV, 2019. – 298 с 15. Самсонов В. В. Методи та засоби Інтернет-технологій: Навч. посібник / В. В. Самсонов, А. Л. Єрохін. – Х. : Компанія СМІТ, 2017. – 264 с. 16. Сучасні інформаційні засоби навчання: Навч. посібник / П. К. Гороль, Р. С. Гуревич, Л. Л. Коношевський, О. В. Шестопалюк. – К.: Освіта України, 2018. – 536 с. 17. 18. Bloch, Joshua. Effective Java Programing Language Guide. Addison- Wesley, Boston, 2001. – 456 с. 19. The Collections Framework. Sun Microsystems. [Електронний ресурс] : Режим доступу: https://java.sun.com/javase/8/docs/technotes/guides/collections/index.html. 20. Рейтинги тестів обчислювальних систем [Електронний ресурс] : Режим доступу: http://www.tpc.org/new_result/tpcc_perf_results.asp?resulttype=noncluster 21. https://discordjs.guide/#before-you-begin 22. https://nodejs.org/uk 23. https://techukraine.net/%D1%8F%D0%BA- %D1%81%D1%82%D0%B2%D0%BE%D1%80%D0%B8%D1%82%D0% B8-discord-%D0%B1%D0%BE%D1%82%D0%B0/ 24. https://discordpy.readthedocs.io/en/stable/ Лист ЧДТУ.242259.001 ПЗ т 63 Зм. Лист № докум. Підпис Дата 25. https://poradnuk.com/hitech/yak-dodati-bota-v-diskord.html Лист ЧДТУ.242259.001 ПЗ т 64 Зм. Лист № докум. Підпис Дата