Дослідження інформаційних систем автоматизованої обробки фінансової інформації супермаркетів

Онищук, Костянтин Богданович

Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/6302

Title:	Дослідження інформаційних систем автоматизованої обробки фінансової інформації супермаркетів
Authors:	Корпань, Ярослав Васильович Онищук, Костянтин Богданович
Issue Date:	Jan-2022
Abstract:	Мета роботи - розширення функцій касових апаратів за рахунок розробки інформаційних систем автоматизованої обробки фінансової інформації супермаркетів. Для досягненя поставленої мети в родоті були вирішені наступні задачі: проведено аналіз предметної області та існуючих рішень; проведено аналіз основних вимог до інформаційної системи; досліджено системи автоматизації обробки фінансової інформації супермаркетів; розроблено інформаційну систему для бухгалтерії супермаркету; розроблено UML-модель програмного забезпечення для касового апарату; розроблено алгоритм розрахунку клієнтів та ведення обліку залишків; проведено дослідження та аналіз розробленої системи; розроблено комплекс рекомендацій для роботи з інформаційної системи.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/6302
Appears in Collections:	174 Автоматизація, комп'ютерно-інтегровані технології та робототехніка (Автоматизація та комп'ютерно-інтегровані системи та компоненти)

Files in This Item:

File	Description	Size	Format
M_151_2022_Онищук+.pdf Restricted Access		1.64 MB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ КОМП’ЮТЕРНИХ
СИСТЕМ

Пояснювальна записка
до кваліфікаційної роботи
освітнього ступеню «магістр»

на тему: ДОСЛІДЖЕННЯ ІНФОРМАЦІЙНИХ СИСТЕМ
АВТОМАТИЗОВАНОЇ ОБРОБКИ ФІНАНСОВОЇ ІНФОРМАЦІЇ
СУПЕРМАРКЕТІВ

Виконав: студент 2 курсу, групи МАКІТ-2009
спеціальності 151 Автоматизація та
комп’ютерно-інтегровані технології,
освітня програма «Комп’ютерно-
інтегровані технологічні процеси і
виробництва»
Костянтин ОНИЩУК

Керівник: Ярослав КОРПАНЬ

Рецензент
( ім’я, ПРІЗВИЩЕ)

Черкаси 2021 року

2
ЗМІСТ

ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ .................................................................. 4
ВСТУП ................................................................................................................... 5
РОЗДІЛ 1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ІСНУЮЧИХ РІШЕНЬ ..... 8
1.1 Аналіз предметної області .............................................................................. 8
1.2 Постановка задачі ............................................................................................ 10
1.3 Огляд існуючих рішень .................................................................................. 12
РОЗДІЛ 2 АНАЛІЗ ОСНОВНИХ ВИМОГ ДО ІНФОРМАЦІЙНОЇ
СИСТЕМИ ............................................................................................................. 20
2.1 Основні функціональні вимоги...................................................................... 20
2.2 Основні критерії до інформаційної системи ................................................ 21
2.3 Вимоги до бази даних ..................................................................................... 21
РОЗІЛ 3 РОЗРОБКА ТА ДОСЛІДЖЕННЯ СИСТЕМИ АВТОМАТИЗАЦІЇ
ОБРОБКИ ФІНАНСОВОЇ ІНФОРМАЦІЇ СУПЕРМАРКЕТІВ ........................ 24
3.1 Аналіз вибору мови програмування для реалізації системи ...................... 24
3.2 Аналіз середовища розробки ......................................................................... 26
3.3 Дослідження серверного програмного забезпечення необхідного для
рішення поставленої задачі .................................................................................. 32
3.4 Вибір технічних засобів .................................................................................. 34
РОЗДІЛ 4 ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ ДЛЯ
БУХГАЛТЕРІЇ СУПЕРМАРКЕТУ ...................................................................... 35
4.1 Поняття об’єктно-орієнтованого моделювання ........................................... 35
4.2 Архітектурний базис UML ............................................................................. 37
4.3 Розробка діаграми розгортання ..................................................................... 41
4.4 Розробка діаграма прецедентів (UseCase) .................................................... 43
4.5 Розробка діаграми компонентів ..................................................................... 45
РОЗДІЛ 5 ДОСЛІДЖЕННЯ ТА АНАЛІЗ РОЗРОБЛЕНОЇ СИСТЕМИ ........... 49
5.1 Логічна структура програми .......................................................................... 49
5.2 Опис класів додатку ........................................................................................ 56

3
5.3 Список аномальних ситуацій і реакцій програми, які припускаються ..... 59
РОЗДІЛ 6 РОЗРОБКА КОМПЛЕКСУ РЕКОМЕНДАЦІЙ ДЛЯ РОБОТИ З
ІНФОРМАЦІЙНОЇ СИСТЕМИ ........................................................................... 61
6.1 Опис додатку ................................................................................................... 61
6.2 Вікно авторизації ............................................................................................. 61
6.3 Вікно продажів ................................................................................................ 63
6.4 Адміністраторська панель .............................................................................. 67
ВИСНОВКИ ........................................................................................................... 72
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ............................................................. 74

4
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ

FTP - File Transfer Protocol - Протокол передавання файлів
HTTP - HyperText Transfer Protocol - Протокол передачі
гіпертекстових документів
IDE - Integrated Development Environment — Інтегроване
середовище розробки
SQL - Structured query language - Мова структурованих запитів
URL - Uniform Resource Locator - Єдиний вказівник на ресурс
АБД - Адміністратор баз даних
БД - База даних
ОС - Операційна система
ПЗ - Програмне забезпечення
ПК - Персональний комп’ютер
СУБД - Система управління базами даних

5
ВСТУП

Завдяки стрімкому розвитку інформаційних технологій, на
сьогоднішній час кожна компанія, підприємство, навчальний заклад і т.п. в
Україні забезпечений комп’ютерами. Все це за для того щоб праця стала
ефективнішою. Всю роботу, яку не так давно, виконували люди, зараз
завдяки програмному забезпеченню із великою швидкістю, виконують
комп’ютери.
Люди за допомогою ПК щоденно виконують типові задачі, за
допомогою створеного на даний момент програмного забезпечення, це дуже
ефективно. Але інколи для більш ефективнішого виконання тих чи інших
задач потребується розробка вузькоспеціалізованого програмного засобу.
Протягом років створено багато автоматизованих програм для касових
апаратів та для самої бухгалтерії супермаркетів, але роки ідуть, обсяг даних
стає все більшим. Застаріле програмне забезпечення необхідно замінювати
новим – більш швидким та надійним.
На сьогоднішній день потреба в створені нового програмного
забезпечення для касового апарату та для бухгалтерії супермаркету за
допомогою новітніх технологій для легшої подальшої підтримки та для
ефективного і швидкого використання показує актуальність обраної теми.

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

6
- провести аналіз основних вимог до інформаційної системи;
- дослідити системи автоматизації обробки фінансової інформації
супермаркетів;
- розробити інформаційну систему для бухгалтерії супермаркету,
- розробити UML-модель програмного забезпечення для касового
апарату;
- розробити алгоритм розрахунку клієнтів та ведення обліку залишків;
- провести дослідження та аналіз розробленої системи;
- розробити комплекс рекомендацій для роботи з інформаційної системи.
Об’єкт дослідження – процеси автоматизованої обробки даних в
інформаційних системах супермаркетів.
Предмет дослідження - інформаційні системи автоматизованої
обробки фінансової інформації супермаркетів.
Методи дослідження базуються на використанні методів теорії
проектування систем, теорії системного аналізу, програмування та
алгоритмізації.
Наукова новизна одержаних результатів полягає в наступному:
- На підставі дослідження існуючих аналогів касових апаратів з
програмним забезпеченням сформульовані завдання.
- Розроблено UML-модель програмного забезпечення для касового
апарату. На відміну від існуючих моделей UML-модель має переваги, а саме
легкість навчання та засвоєння.
- Створено базу даних ведення обліку персоналу та залишків
продукції.
Практичне значення одержаних результатів полягає в доведенні
отриманих наукових результатів до конкретних рішень:
- Розроблено алгоритм розрахунку клієнтів та ведення обліку
залишків.
- Удосконалено програмне забезпечення для касового апарату.
Особистий внесок здобувача: всі результати роботи отримані автором

7
самостійно. Робота провірена на плагіат.
Апробація результатів Результати роботи доповідались і
обговорювалися на студентській науково-практичній конференції ЧДТУ (м.
Черкаси) в 2021 році.
Публікації
1. Миргородченко І. О. Програмний модуль вивчення граматики
англійської мови на платформі TELEGRAM / І.О. Миргородченко, К.Б.
Онищук, В.М. Лукашенко // Збірник тез доповідей студентської
науковопрактичної конференції ЧДТУ : 19–22 квітня 2021 р. [Електронний
ресурс] / [упоряд. Мельник І.В.] ; Мво освіти і науки України, Черкас. держ.
технол. унт. – Черкаси : ЧДТУ, 2021. – C. 128.
2. Онищук К. Б. Забезпечення для бухгалтерії мереж супермаркетів
/ К.Б. Онищук, І.О. Миргородченко, В.М. Лукашенко // Збірник тез доповідей
студентської науковопрактичної конференції ЧДТУ : 19–22 квітня 2021 р.
[Електронний ресурс] / [упоряд. Мельник І.В.] ; Мво освіти і науки України,
Черкас. держ. технол. унт. – Черкаси : ЧДТУ, 2021. – C. 129.

8
РОЗДІЛ 1
АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ІСНУЮЧИХ РІШЕНЬ

1.1 Аналіз предметної області
На даний момент наземні магазини теж грають велику роль в бізнесі,
не менш чим інтернет-магазини. Кожний бізнесмен який володіє для
прикладу онлайн магазином, з часом відкриває наземний магазин, що
зменшує час потрапляння продукту до кінцевого покупця. Таким чином
клієнт може прийти, подивитись, «поторгати» і купити те що йому
сподобалось розплатившись відразу на касі.
Кожний супермаркет має каси на виході для того, щоб кожен
покупець(клієнт), зміг, розрахуватися за вибраний ним же товар в
торгівельному залі. Касир безпосередньо здійснює розрахунок клієнта та
надає йому чек.
Дослідження інформаційних систем, а в подальшому їх створення є
досить актуальною задачою, яка спрощує роботу працівників супермаркету
та допомагає здійснювати контроль не тільки за товаром, наявністю,
кількістю, цінами, тощо, але й водночас виконувати розрахунки клієнтів та
вести звітність, що значно полегшує роботу. Крім цього, в Україні
застосування касових апаратів регулюється Законом України № 265/95-ВР
«Про застосування реєстраторів розрахункових операцій у сфері торгівлі,
громадського харчування та послуг». Цим законом визначено, що касовий
апарат є підвидом більш загального класу фіскальних пристроїв, котрі
іменуються терміном "реєстратор розрахункових операцій".
Робота касира полягає в скануванні товару який добавляється в
таблицю покупок, в послідующому чек. Касир може вибирати кількість
однотипного товару, а також крім товару сканувати картку лояльності
супермаркету. А по завершенню роботи обирати спосіб оплати який інпону
покупцеві.
Автоматична інформаційна система використовується не тільки для

9
того, щоб спростити життя касира, але для представлення звітності
бухгалтерії про товарообіг за день, місяць, рік, тощо.
В супермаркеті знаходиться більше 100 тисяч одиниць товару, яку
звичайні людині запам’ятати не можливо, а крім цього ціни, кількості в
наявності тощо, не можливо. Інформаційна система виконує практично всю
роботу та вміщує в себе всю цю інформацію.
По завершенню дня касир повинен робити звіти по касі, що значно
спростить роботу бугалтеріїї при обробці фінансової інформації.
Друга ж частина ПЗ дозволяє редагувати дані, що не доступно
звичайному касиру, але доступно адміністратору та прийомщику товара,
який цим займається безпосередньо.
Коли до супермаркету привозять товар, приймальник товару його
приймає та вносить до БД програмного забезпечення. Якщо це нова одиниця
товару то товар вноситься як новий і стає доступний на касі для продажу, а
інші просто обновляється кількість. Приймальник та адміністратор
виконують безпосередньо контроль та адміністрування БД, щоб не допустити
пробиття на касі товару, якого не існує або ж не по існуючій ціні.
Адміністратор супермаркету ж слідкує в ПЗ за наявністю товару, ціною
та за його кількістю і вносить потрібні правки, якщо це необхідно.
Супермаркет — великий універсальний магазин в якому покупці самі
беруть потрібний їм товар і розраховуються на касі. Супермаркет пропонує
для вибору більше 100 тисяч одиниць товару, домогосподарських,
продовольчих, тощо.
Магазин — заклад або ж підприємство роздрібної торгівлі. Мають:
торговельні зали для обслуговування покупців, каса, підсобні приміщення, де
приймають, зберігають і готують до продажу товари; адміністративно-
побутові й технічні приміщення.
Магазини бувають різного типу, вони відрізняються за такими
параметрами: площа торгової зали, кількість товарних позицій, рівень
обслуговування покупців, технологія розміщення товару тощо.

10
Каса - це механічний або електронний пристрій, призначений для
обліку коштів під час здійснення розрахункових операцій.
Сучасні касові апарати - це електронні пристрої, що зазвичай мають
клавіатуру, механізми друку чеків та контрольної стрічки, дисплеї касира та
клієнта, грошову скриньку та розвинену можливість підключати різноманітні
периферійні пристрої: сканери штрих-коду, платіжні термінали, ваги, модеми
тощо. Вони можуть обліковувати як готівкові, так і безготівкові кошти,
містити попередньо запрограмований перелік товарів, що продаються,
виконуватизвіти, обмінюватись інформацією з обчислювальними машинами,
і навіть рекламувати товари чи послуги, що продаються.
Основна мета застосування касових апаратів - контроль з боку
власника бізнесу або держави за обігом коштів. Також сучасні касові апарати
дозволяють збирати корисну статистику та виконувати інші функції,
наприклад калькулятора чи платіжного терміналу.
Касир – це працівник, який забезпечує прийом готівки, зберігання та її
облік, оператор касового апаратом. Зазвичай водночас виступає в ролі
продавця.
Приймальник товару – це працівник який здійснює прийом товару від
постачальників, перевіряючи якість товару та термін зберігання, вносячи
його до БД магазину.
Адміністратор – це працівник, який здійснює контроль над
персоналом, а також контролює наявність та цінову політику товару в
супермаркеті для подальшої реалізаціїпродавцями.

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

11
ПЗ касира повинно надавати такі можливості:
• Основна кольорова гама – сіра, для створення дизайнерських
елементів мають бути використані лише ті кольори, що наявні на логотипі,
загальна кількість контрастних відтінків не повинна перевищувати п’яти.
• Використання не більш чотирьох різних шрифтів.
• Візуальна підтримка дій користувача.
• Робоче середовище касира.
• Контроль грошових коштів.
• Внесення/винесення грошей.
• Створення звітів.
• Калькулятор касира.
• Постійна синхронізація з БД ПЗ адміністрування.
• Редагування даних, а саме:
– додавання нових товарів;
– додавання (прихід) товарів, які є в наявності;
– пошук товарів та їх редагування.
• Перегляд залишків.
• Пошук.
• Управління користувачами.
Програма повинна бути інтуїтивно зрозумілою та комфортною у
використанні. Також програма повинна забезпечувати введення даних до
таблиць бази даних, повинна мати елементи управління базою даних, всі
поля для введення повинні бути підписані.
Система призначена для безперервного функціонування протягом
усього робочого дня.
Програма повинна реалізовувати можливість введення потрібної
інформації в базу даних автоматизованої системи. База даних повинна
містити інформацію про товар, знижки, ВР карти покупців, категорії, та
користувачів.

12

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

Програма ПРАЙМ
Програма ПРАЙМ – Автоматизація магазину роздрібної торгівлі.
Дане програмне забезпечення дозволяє:
- оформляти продажі, повернення, списання та призначати знижки;
- можна підключити чековий принтер, сканер штрих-кодів або інше
касове обладнання;
- підтримує роботу з фіскальними реєстраторами;
- дані надійно зберігаються в дата-центрі та захищені від втрат;
- продажі в магазині не зупиняться, навіть якщо зникне підключення до
Інтернету;
- можлива спільна робота кількох співробітників із різними правами
доступу.
На рис. 1.1 зображено інтерфейс програми в процесі роботи.
Програма має наступні функції [16]:
1. Фіксація продажів. Продаж штучного чи вагового товару.
Зчитування вагових етикеток.

13

Рис. 1.1. Програма ПРАЙМ

2. Встановити знижку на позицію в чеку. Можна вказати точне
значення знижки або відсоток ціни товару (рис. 1.2).

Рис. 1.2. Меню встановлення скидки

14
3. Робота з будь-якими сканерами штрих-коду: ручними,
стаціонарними, бездротовими тощо.
4. Пошук та додавання товарів за кодом, штрих-кодом або
найменуванням. Розбиття товарів на групи та підгрупи з будь-яким рівнем
вкладеності (рис. 1.3).

Рис. 1.2. Меню додавання товару по коду

5. Створення повернення покупцю. Також у розділі «Каса» є створення
списання товару або переміщення його на склад.
6. Можливість роботи кількох касирів. Вхід касира за допомогою пін-
коду або особистої картки.
7. Робота з різними видами оплати: готівка або банківська картка.
Можливість заокруглення суми чека до цілого.
8. Підключення фіскальних реєстраторів АТОЛ, Штрих-М, Іскра для
роботи з 54-ФЗ. Можливість друку чека на термальному принтері або
звичайному А4.

15
9. Робота з бонусними картками. Можна вказати покупця під час
здійснення продажу. Пошук покупця за ПІБ або номером телефону.
10. Підключення екрана покупця або клавіатури, що програмується.
11. Фіксація грошових операцій: вноси та виноси грошових коштів.
Облік відкриття та закриття зміни.
12. Розрахунок здавання покупцю. Контролює зміни цін.
13. Використовуючи програму можна виконувати повернення товару
від покупця, створювати списання чи переміщення товару складу (рис.1.4).

Рис. 1.4. Меню додаткових задач

Зручність використання даного ПЗ. Зразу можна виділити велике
текстове поле для введення даних, що зразу потрапляє на очі і дозволяє зразу
з орієнтуватися куди вводити штрих-код. Також можна побачити на екрані
блоки з швидким доступом до часто купуємих товарів, що є великим плюсом.
Інтерфейс касової програми інтуїтивно зрозумілий, а отже, не потрібно
витрачати час на навчання продавців.

16
Швидке додавання товарів у чек та застосування знижок. Розрахунок
здавання покупцю.
Підтримка різноманітного товарного обладнання. Робота з будь-якими
сканерами штрих-коду.
Пошук та додавання товарів за кодом, штрих-кодом або
найменуванням. Розбиття товарів на групи та підгрупи з будь-яким рівнем
вкладеності.
З мінусів зручності використання можна виділити, не зручне
розташування блоку для підрахунку суми.
Дизайн даного ПЗ є дуже інтуїтивно зрозумілим і простим, все в
одному тоні і нічого лишнього не мішає очам.
Функціональність даного програмного забезпечення дозволяє
створювати пре-чеки, що є великим плюсом, можна не «проводячи чек»
переглянути так скажімо корзину. Також до функціональності можна
віднести мобільність програми та те що вона є мультиплатформеною.

Каса МойСклад
Касса МойСклад - Зручна касова програма для будь-якого пристрою та
потужна товарооблікова система безкоштовно або за вигідною ціною
(рис.1.5).
Як правило користувач касових програм від системи вимагає:
- Простоту. Легко запустити, підключити фіскальний реєстратор та
почати працювати.
- Інтуїтивно-зрозумілий інтерфейс - звичайний касир може працювати
без навчання.
- Універсальність устаткування. Сумісність із популярним торговим
обладнанням та касовою технікою.
- Нові правила застосування ККТ. Підтримка онлайн-кас та вимог
нового 54-ФЗ.

17
- Надійна робота на різних платформах, зокрема мобільних: Windows,
Linuх, iOS, Android.
- Вартість. Невисокі щомісячні платежі або безкоштовна касова
програма.
- Підтримка. В ідеалі 24/7 за телефоном та email.

Рис. 1.5. Програма МойСклад

До переваг даного забезпечення можна віднести те, що працює на
любому пристрої будь то ноутбук чи телефон та легкість підключення
сканера та терміналу. Нижче на рисунку зображено програма в процесі
роботи.
До зручності можна віднести мультиплатформеність, та інтуїтивно
зрозумілий інтерфейс. Як видно вище на рисунку, чек та різні інші розділи
виносяться на окремі вікна, що трохи як на мене не досить зручно.
Дизайн даної програми виконаний в світлих тонах з використанням
кількох шрифтів та рисунків, що дуже приємно сприймається користувачем.
Міносом в дизайні є використання багато різних кольорів.
Функціональність даного ПЗ:

18
- Сумісність із перевіреними моделями ККТ для вашого сегменту.
- Відповідність законам про онлайн-каси та маркування, номенклатура
в чеку, два чека з передоплати.
- Створення декілька чеків (рис. 1.6).

Рис. 1.6. Створення чеків

- Ведення обліку товарообігу (рис.1.7).

Рис. 1.7. Облік оборотів

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

20
РОЗДІЛ 2
АНАЛІЗ ОСНОВНИХ ВИМОГ ДО ІНФОРМАЦІЙНОЇ СИСТЕМИ

2.1 Основні функціональні вимоги
Програма розробляється для ОС Windows і повинна бути
невимогливою до апаратних ресурсів.
Інтерфейс програми має бути мінімалістичним, сучасним та інтуїтивно
зрозумілим для низькокваліфікованого користувача.
Програма касира має виконувати такі функції:
– відображати інформацію про продукцію (назви товарів, ціну,
кількість тощо);
– створювати касові звіти (Х – звіт, Z -звіт);
– мати калькулятор для підрахунку готівки в касі;
– надавати можливість авторизації;
– проводити розрахунок покупця;
– після кожної розрахункової операції надавати чек.
Програма адміністрування має виконувати такі функції:
– надавати можливість авторизації;
– виконувати роботу з БД та її редагуванням;
– надавати можливість управління користувачами;
– дозволяти працювати з товарами супермаркету (редагувати їх,
добавляти, видаляти,тощо).
Основні функції БД:
– Можливість виконувати запити. Запити не повинні бути складні у
освоєнні та використанні, та повинні одразу виводити всю необхідну
інформацію, по якій він був здійснений.
– Зберігання та упорядкування даних.
– Підтримка SQL.

21
2.2 Основні критерії до інформаційної системи
Програмне забезпечення інформаційної системи повинно працювати з
базою даних, а також задовольняти ряду наступних критеріїв:
1. Правильність – ПЗ повинно надавати правильні результати для
будь-яких даних з заздалегідь визначеного діапазону.
2. Ефективність – ПЗ повинно надавати результати за сприйнятий час
і не бути ресурсоємким.
3. Універсальність – ПЗ повинно бути розраховане на широкий
спектр задач та за можливості на великий об’єм вхідних даних.
4. Функціональність – ПЗ повинно забезпечувати усі необхідні
потреби користувача та не реалізовувати не потрібних функцій.
5. Зручність – ПЗ повинно бути зручним у використанні та з легкістю
засвоюватись, а програмний інтерфейс – інтуїтивнозрозумілим.
6. Переносимість – повинно забезпечуватись перенесення з однієї
машини на іншу без змін, а бо з їх мінімальною присутністю.
7. Читабильність – використані тексти в програмі повинні бути
максимально простими та читабельними для сприйняття користувачем.
8. Модифікованість – ПЗ повинно надавати можливість для змін та
доповнень.

2.3 Вимоги до бази даних
З сучасних пoзицiй cлiд порізно poзглядaти вимоги, пропоновані до
тpaнзaкцiйниx (oпepaцiйним) баз даних i до сховищ даних.
Аналіз показав що можна виділити наступні ocнoвнi вимoги, якi
пpeд'являютьcя до oпepaцiйниx баз даних, a oтжe, i дo CУБД, на яких вони
будуються.
1. Пpocтoтa оновлення дaниx. Пiд операцією оновлення розуміють
дoдaвaння, видaлeння i змiни дaниx.
2. Bиcoкa швидкoдiя (мaлий час вiдгуку на зaпит). Чac вiдгуку –
проміжок чacу від мoмeнту зaпиту дo БД i фактичним oтpимaнням дaниx.

22
Cxoжим є тepмiн «час дocтупу» - проміжок чacу мiж видaчeю команди зaпиcу
(зчитувaння) i фактичним oтpимaнням дaниx. Пiд дocтупoм розуміється
операція пoшуку, читання даних aбo зaпиcу їx.
3. Нeзaлeжнicть даних.
4. Cпiльнe використання даних багатьма кopиcтувaчaми.
5. Бeзпeкa даних – зaxиcт даних від нaвмиcнoгo чи нeнaвмиcнoгo
порушення секретності, спотворення aбo руйнування.
6. Cтaндapтизaцiя пoбудoви та eкcплуaтaцiї БД (фактично CУБД).
7. Aдeквaтнicть вiдoбpaжeння даних вiдпoвiднoї предметної oблacтi.
8. Дoбpoзичливий та зрозумілий інтерфейс кopиcтувaчa.
Нaйвaжливiшими є пepшi два суперечливих вимoги, дому що
підвищення швидкoдiї вимагає cпpoщeння cтpуктуpи БД, щo, у cвoючepгу,
уcклaднює пpoцeдуpу оновлення дaниx, збiльшує їх нaдмipнicть.
Нeзaлeжнicтьдaниx – можливість змiни лoгiчнoї i фізичної cтpуктуpи
БД без змiни представлень кopиcтувaчiв. Нeзaлeжнicть даних передбачає
інваріантність до xapaктepу зберігання дaниx, програмного забезпечення та
технічних зacoбiв. Boнa зaбeзпeчує мінімальні змiни cтpуктуpи БД при
змiнax стратегії дocтупу до дaниx i структури самих виxiдниx дaниx. Цe
дocягaєтьcя "змiшaнням" всих змiн на етапи кoнцeптуaльнoгo i логічного
пpoeктувaння з мінімальними змiнaми на eтaпi фізичного пpoeктувaння.
Бeзпeкa даних включає їх цiлicнicть i зaxиcт. Цiлicнicть дaниx –
cтiйкicть збepeжeниx даних до pуйнувaння i знищeння, пoв'язaниx з
несправностями технічних зacoбiв, cиcтeмними пoмилкaми i помилковими
дiями кopиcтувaчiв.
Boнa пpипуcкaє:
• вiдcутнicть нeтoчнo ввeдeниx даних aбo двох однакових записів про
oднин i тe же фaкт;
• зaxиcт від помилок при oнoвлeннi БД;
• нeмoжливicть видалення пopiзнo (кacкaднe видaлeння) пoв'язaниx
даних piзниx тaблиць;

23
• нecпoтвopeння даних при poбoтi в багатокористувацькому i в
poзпoдiлeниx бaзax дaниx;
• збереження даних при збoяx тexнiки (відновлення дaниx).
Цiлicнicть забезпечується тpигepaми цiлicнocтi – спеціальними
дoдaткaми-пpoгpaмaми, що працюють за певних умoв. Для дeякиx CУБД
(нaпpиклaд, Access, Paradox) тpигepи є вбудoвaними.
Зaxиcт даних від нecaнкцioнoвaнoгo дocтупу передбачає обмеження
дocтупу до конфіденційних дaниx i може дocягaтиcя:
• ввeдeнням системи пapoлiв;
• oтpимaнням дoзвoлiв від адміністратора бaзи дaниx (AБД);
• зaбopoнoю вiд AБД на дocтуп до дaниx;
• формуванням видiв - тaблиць, пoxiдниx від виxiдниx i
пpизнaчeниx конкретним кopиcтувaчaм.
Тpи останні процедури легко викoнуютьcя в рамках мови
структурованих запитів Structured Query Language (SQL), який ще чacтo
називають SQL2.
Cтaндapтизaцiя зaбeзпeчує спадкоємність пoкoлiнь CУБД, що cпpoщує
взaємoдiю БД одного пoкoлiння CУБД з oднaкoвими i piзними мoдeлями
дaниx. Cтaндapтизaцiя (ANSI / SPARC) здiйcнeнa в знaчнiй мipi в чacтинi
iнтepфeйcу кopиcтувaчa CУБД i мoви SQL. Цe дoзвoлилo уcпiшнo виpiшити
зaвдaння взаємодії piзниx peляцiйниx CУБД як за допомогою мoви SQL, тaк i
з застосуванням дoдaтку Open Data Base Connection (ODBC). Пpи цьому
мoжe бути здiйcнeний як лoкaльний, тaк i віддалений дocтуп до дaниx
(технологія клiєнт-cepвep aбo мepeжeвий вapiaнт).

24
РОЗІЛ 3
ДОСЛІДЖЕННЯ СИСТЕМИ АВТОМАТИЗАЦІЇ ОБРОБКИ
ФІНАНСОВОЇ ІНФОРМАЦІЇ СУПЕРМАРКЕТІВ

3.1 Аналіз вибору мови програмування для реалізації системи
Аналіз мов програмування, які можна використати для підготовки
програмного забезпечення для інформаційних систем показав, що для
розробки необхідного ПЗ доцільно обрати мову програмування JAVA, а
також SQL для роботи з БД.
Java [18] - у цієї мови є багато переваг перед іншими мовами
програмування, що дозволяє вирішувати з її допомогою практично будь-які
завдання.
Мова Java має ряд переваг. Одна з основних переваг мови Java –
незалежність від платформи, на якій виконуються програми: один і той же
код можна запускати під управлінням операційних систем Windows, Solaris,
Linux, Machintosh та ін. Це дійсно необхідно, коли програми завантажуються
через Інтернет для подальшого виконання під управлінням різних
операційних систем.
Характерні особливості мови програмування Java:
1. Простота.
При розробці Java було приділено велику увагу простоті мови, тому
програми на Java, в порівнянні з програмами на інших мовах, простіше
писати, компілювати, налагоджувати і вивчати. Це дозволяє створювати
модульні програми, вихідний код яких може використовуватися багато разів.
2. Об’єктно-орієнтованість.
Java – повністю об'єктно-орієнтована мова, навіть більшою мірою, ніж
C++. Всі сутності в мові Java є об'єктами, за винятком небагатьох основних
типів (primitivetypes), наприклад чисел. Оскільки за допомогою об'єктно-
орієнтованого програмування легко розробляти складні проекти, воно
замінило собою більш давнє структурне програмування.

25
3. Розподіленість.
Java володіє великою бібліотекою програм для передачі даних на
основі таких протоколів TCP/IP, HTTP або FTP. Програми, написані на мові
Java, можуть відкривати об'єкти і отримувати до них доступ через мережу за
допомогою і URL-адрес так же легко, як в локальній мережі.
4. Безпечність.
Мова Java призначена для використання в мережевому або
розподіленому середовищі. З цієї причини велика увага була приділена
безпеці. Мова Java дозволяє створювати системи, захищені від вірусів і
стороннього втручання.
5. Незалежність від архітектури;
Компілятор генерує об'єктний файл, формат якого не залежить від
архітектури комп'ютера, - скомпільована програма може виконуватися на
будь-яких процесорах під управлінням системи виконання програм мови
Java. Для цього компілятор мови Java генерує команди, байт-коду, не залежні
від конкретної архітектури комп'ютера. Байт-код розроблений таким чином,
щоб на будь-якій машині його можна було легко інтерпретувати або на льоту
перевести в машино залежний код.
6. Машинонезалежність.
На відміну від мов С і C + +, в специфікації Java немає аспектів, що
залежать від системи реалізації. І розмір основних типів даних, і арифметичні
операції над ними точно визначені.
7. Інтерпритованість.
Інтерпретатор мови Java може пересилатися на будь-яку машину і
виконувати байт-код безпосередньо на ній. Оскільки редагування зв'язків -
більш легкий процес, розробка програм може стати набагато швидше і
ефективніше.
8. Висока продуктивність.
Хоча зазвичай інтерпретовані байт-коди мають більш ніж достатню
продуктивність, бувають ситуації, в яких потрібно ще більш висока

26
ефективність. Байт-коди можна "на льоту" (під час виконання) транслювати в
машинні коди для конкретного процесора, на якому виконується даний
додаток.
9. Динамічність.
У багатьох випадках мова Java є більш динамічною, ніж мови С або
C++. Вона була розроблена так, щоб легко адаптуватися до постійно
змінного середовища. У бібліотеки можна вільно додавати нові методи і
об'єкти, не завдаючи жодної шкоди. Мова Java дозволяє легко отримувати
інформацію про хід виконання програми.

3.2 Аналіз середовища розробки
Для розробки даного програмного продукту було використано
середовище MySqlWorkBeanch для створення бази даних за допомогою мови
запитів SQL та IDE NetBeans для створення ПЗ для роботи з цією базою з
використанням мови програмування Java.
MySQLWorkbench [10] — інструмент для візуального проектування баз
даних, що інтегрує проектування, моделювання, створення й експлуатацію
БД в єдине безкоштовне оточення для системи баз даних MySQL. Є
наступником DBDesigner 4 зFabForce.
Можливості програми:
• Дозволяє наочно представити модель бази даних в графічному
вигляді.
• Наочний і функціональний механізм установки зв'язків між
таблицями, в тому числі «багато до багатьох» із створенням таблиці зв'язків.
• ReverseEngineering — відновлення структури таблиць з вже
існуючої на сервері БД (зв'язки відновлюються в InnoDB, при використанні
MyISAM зв'язки необхідно встановлювати вручну).
• Зручний редактор SQL запитів, що дозволяє відразу ж відправляти
їх серверові і отримати відповідь у вигляді таблиці.
• Можливість редагування даних у таблиці в візуальному режимі.

27
SQL (англ. Structuredquerylanguage — мова структурованих запитів) [11] —
декларативна мова програмування для взаємодії користувача з базами даних,
що застосовується для формування запитів, оновлення і керування
реляційними БД, створення схеми бази даних та її модифікації, системи
контролю за доступом до бази даних. Сама по собі SQL не є ані системою
керування базами даних, ані окремим програмним продуктом. На відміну від
дійсних мов програмування (C або Pascal), SQL може формувати
інтерактивні запити або, бувши вбудованою в прикладні програми, виступати
як інструкції для керування даними. Окрім цього, стандарт SQL містить
функції для визначення зміни, перевірки та захисту даних.
SQL — це діалогова мова програмування для здійснення запиту і
внесення змін до бази даних, а також керування базами даних. Багато баз
даних підтримує SQL з розширеннями до стандартної мови. Ядро SQL
формує командна мова, яка дозволяє здійснювати пошук, вставку, оновлення
і вилучення даних за допомогою використання системи керування і
адміністративних функцій. SQL також включає CLI (CallLevelInterface) для
доступу і керування базами даних дистанційно.
NetBeans IDE [12] — вільне інтегроване середовище розробки (IDE)
для мов програмування Java, JavaFX, C/C++, PHP, JavaScript, HTML5, Python,
Groovy. Середовище може бути встановлене і для підтримки окремих мов, і у
повній конфігурації. Середовище розробки NetBeans за замовчуванням
підтримує розробку для платформ J2SE і J2EE.
Поширюється у сирцевих текстах під ліцензією ApacheLicense. Проект
NetBeans IDE підтримувався і спонсорувався фірмою SunMicrosystems і після
придбання Sun — Oracle. У жовтні 2016 року Oracle передав NetBeans у
власність ApacheSoftwareFoundation, яка займається розробкою і підтримкою
проекту.
NetBeans IDE доступна для платформ Microsoft Windows, GNU/Linux,
FreeBSD, і Solaris (як SPARC, так x86). Для інших платформ доступна
можливість зібрати NetBeans самостійно із сирцевих текстів.

28
За якістю і можливостям останні версії NetBeans IDE змагається з
найкращими інтегрованими середовищами розробки для мови Java,
підтримуючи рефакторинг, профілювання, виділення синтаксичних
конструкцій кольором, автодоповнення мовних конструкцій на льоту,
шаблони коду та інше.
Реалізація поставленої задачі з використанням проаналізованих вище
середовищ досить проста:
Tovary
CREATE TABLE `tovary` (
`idTovary` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(100) NOT NULL,
`odin_vimir` varchar(45) NOT NULL,
`price` double NOT NULL,
`kol` double NOT NULL,
`kod` varchar(45) NOT NULL,
`art` varchar(45) NOT NULL,
`id_category` int(11) NOT NULL,
`id_sale` int(11) NOT
NULL, PRIMARY KEY
(`idTovary`), UNIQUE
KEY `kod_UNIQUE`
(`kod`), UNIQUE KEY
`art_UNIQUE` (`art`), KEY
`idtovary_idx`
(`id_category`), KEY `
id_sale_idx`(`id_sale`),
CONSTRAINT ` id_sale` FOREIGN KEY (`id_sale`) REFERENCES
`sales` (`id`), CONSTRAINT `id_category` FOREIGN KEY (`id_category`)
REFERENCES
`category` (`id`)

29
) ENGINE=InnoDB AUTO_INCREMENT=23 DEFAULT
CHARSET=utf8mb4
COLLATE=utf8mb4_0900_ai_ci COMMENT='Alltovari';

Users
CREATE TABLE `users` (
`idusers` int(11) NOT NULL AUTO_INCREMENT,
`lvl_dostup` int(11) NOT NULL,
`login` varchar(45) NOT NULL,
`password` varchar(45) NOT NULL,
`pib` varchar(45) NOT NULL,
PRIMARY KEY (`idusers`),
UNIQUE KEY `login_UNIQUE` (`login`)
) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT
CHARSET=utf8mb4
COLLATE=utf8mb4_0900_ai_ci;

Category
CREATE TABLE `category` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(45)
NOT NULL,
PRIMARY KEY
(`id`)
) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT
CHARSET=utf8mb4
COLLATE=utf8mb4_0900_ai_ci;

Sales
CREATE TABLE `sales` (

30
`id` int(11) NOT NULL AUTO_INCREMENT,
`kod_sale` varchar(45) NOT NULL,
`size_sale` int(11)
NOT NULL,
PRIMARY KEY
(`id`)
) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT
CHARSET=utf8mb4
COLLATE=utf8mb4_0900_ai_ci;

Vr_karti
CREATE TABLE `vr_karti` (
`idvr_karti` int(11) NOT NULL AUTO_INCREMENT,
`number_card` varchar(15) NOT NULL,
`balance` double
NOT NULL,
PRIMARY KEY
(`idvr_karti`),
UNIQUE KEY `number_card_UNIQUE` (`number_card`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT
CHARSET=utf8mb4
COLLATE=utf8mb4_0900_ai_ci;

Zvit
CREATE TABLE `zvit` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`suma` double NOT NULL,
`sum_sale` double NOT NULL,
`kasir` int(11) NOT NULL,
`card` tinyint(4)

31
NOT NULL,
PRIMARY KEY
(`id`),
KEY `kasir_idx` (`kasir`),
CONSTRAINT `kasir` FOREIGN KEY (`kasir`) REFERENCES `users`
(`idusers`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT
CHARSET=utf8mb4
COLLATE=utf8mb4
_0900_ai_ci; Запити
до бази даних:

Запит 1
SELECT count(zvit.id), sum(zvit.suma), sum(zvit.sum_sale),
sum(zvit.card), (SELECT count(zvit.card) AS nocard FROM
kasa.zvitwherezvit.card = 0) AS nocard, count(distinctkasir),
min(zvit.suma), max(zvit.suma), (SELECT min(zvit.sum_sale)
FROM kasa.zvit WHERE zvit.sum_sale>0),
max(zvit.sum_sale), (sum(zvit.suma) -
sum(zvit.sum_sale)) AS zagal, avg(zvit.suma),
avg(zvit.sum_sale)
FROM kasa.zvit

Запит 2
SELECT kasa.tovary.idtovary, kasa.tovary.name,
kasa.tovary.odin_vimir, max(kasa.tovary.price),
kasa.tovary.kol, kasa.tovary.kod, kasa.tovary.art,
kasa.category.name, kasa.sales.size_sale
FROM kasa.tovary
INNER JOIN kasa.category ON kasa.tovary.id_category =

32
kasa.category.id INNER JOIN kasa.sales ON
kasa.tovary.id_sale =kasa.sales.id
WHERE (kasa.tovary.name LIKE '%Чай%' OR
kasa.tovary.name LIKE '%Приправа%') AND
kasa.tovary.price BETWEEN 5 AND20
GROUP BY kasa.tovary.name

Запит 3
resultSet = statement.executeQuery("select *
fromkasa.tovarywheretovary.kod = "+ kod);

Запит 4
statement.executeUpdate("UPDATE tovary SET tovary.kol = tovary.kol - "
+kol+" WHERE tovary.name = '"+name+"'");

Запит 5
statement.executeUpdate("INSERT INTO kasa.zvit (suma, sum_sale ,kasir,
card)"
+ "VALUES ("+sum+", "+sum_sale+", "+id_kasir+", "+card+")");

3.3 Дослідження серверного програмного забезпечення необхідного
для рішення поставленої задачі
Сервер бази даних
Для створення сервера було вибрано ПЗ MySql Server.
MySQL [13] - багато-компактний сервер баз даних. Він відрізняється
високою швидкістю, доступністю, легкістю і стійкістю в використанні.
Компанія tcx розробила сервер MySQL для внутрішніх потреб.
Головним завданням була швидка обробка баз даних великого обсягу.
Компанія стверджує, що MySQL застосовується з 1996 року на сервері, що
має понад 40 БД. В цілому ці бази містять близько 10 000 таблиць, більше

33
500 з яких мають 7 мільйонів рядків.
MySQL - ідеальна розробка для середніх і малих додатків. Багато
платформи використовують вихідні цього сервера. Значний приріст
виробництва забезпечується використанням повних можливостей MySQL на
Unix-серверах.
MySQL при стандарті ANSI 92 підтримує мову запитів SQL. До цього
стандарту розроблено безліч розширень, яких немає ні в інших системах
управління базами даних.
Основний перелік можливостей сервера:
• Можливість підтримки необмеженого числа користувачів, що
одночасно працюють в базах даних.
• Максимальна кількість табличних рядків - 50млн.
• Висока швидкість виконання команд. Сервер MySQL вважається
одним з найшвидших.
• Проста, але ефективна система безпеки. Недоліки сервера MySQL:
• Швидкість сервера вплинула на деякі параметри. Розробники
пожертвували деякими вимогами в СУБД.
В MySQL відсутні:
• Підтримка вкладених запитів. Однак розробники обіцяють
включити цю можливість в наступну версію сервера.
• Підтримка уявлення.
• Підтримка різних транзакцій.
• Підтримка зовнішніх ключів.
• Підтримка збережених процесів і тригерів.
Творці сервера стверджують, що саме останні три пункти вплинули на
швидкість. Якщо ці можливості будуть реалізовані, сервер перестане
славиться своїм швидкодією. Перераховані можливості не є визначальними
при створенні додатків. У загальному підсумку, швидкість і невисока
вартість сформували високу популярність MySQL.
Робота сервера БД забезпечується СУБД. При цьому клієнт посилає

34
запит до БД на сервер. У реляційних БД запит записується на мові SQL.
Процедура розгляду заяв про виконується на сервері БД. Сервер вибирає
записи, відповідні заданим критеріям, і відсилає їх по мережі клієнтові.
Обробка запиту може бути розподілена по комп'ютерам-серверам декількох
типів від ПК до мейнфреймів. Загальнодоступною робочою станцією для
кінцевих користувачів мережі, запускають клієнтський процес і формують
запити до БД, є, як правило, ПК.

3.4 Вибір технічних засобів
Аналіз апаратного забезпечення показав, що для повноцінної роботи
бази даних для продажу продуктового магазину необхідно, щоб комп’ютер
відповідав характеристикам представленим в табл. 3.1.
Таблиця 3.1
Технічні вимоги для роботи програми «Продаж в продуктовому
магазині»
№ п/п Назва Значення
1. Процесор із тактовою частотою Не менше 1ГГц
2. Оперативна пам'ять не менше 1 Гб.
3. Вільного місця на жорсткому диску 150 Мб.
4. Встановлена операційна система Windows 7
5. Встановлений JDK пакет, обов’язково JDK 1.7 і вище

35
РОЗДІЛ 4
ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ ДЛЯ БУХГАЛТЕРІЇ
СУПЕРМАРКЕТУ

4.1 Поняття об’єктно-орієнтованого моделювання
Розробка сучасних програмних продуктів неможлива без
попереднього моделювання. Накопичений досвід провідних компаній
світу, які спеціалізуються на розробці програмних засобів, засвідчує: чим
більшим і складнішим є проект, тим важливішим стає моделювання
майбутньої системи.
Моделювання будь-якої системи супроводжується створенням
множини моделей для відображення різних аспектів системи. Моделі
можуть мати різні рівні абстракції, які відображають одні й ті ж аспекти
системи з різним ступенем деталізації.
Моделювання дає змогу розв’язати такі задачі:
− візуалізація системи – візуальне відображення програмної системи
у її поточному чи бажаному стані;
− специфікація системи – визначення структури і/або поведінки
системи;
− конструювання системи – отримання шаблону, який допоможе
сконструювати систему;
− документування системи – фіксація прийнятих рішень на основі
отриманих моделей.
При розробці програмних систем існує декілька методів моделювання,
які відрізняються своєю орієнтацією на стиль програмування. Зазвичай,
вирізняють п’ять стилів:
- процедурно-орієнтований – спрямований на представлення
програми як множини процедур, які за чергою викликаються;
- об’єктно-орієнтований – спрямований на представлення програми
як набору взаємодіючих об’єктів;

36
- логіко-орієнтований – спрямований на виконання цілей, які
передано у термінах обчислення предикатів;
- орієнтований на правила – виконання правил «якщо-то»;
- орієнтований на обмеження.
Як стверджують автори [1], неможливо визнати один стиль
програмування найкращим у всіх областях практичного застосування, однак
об’єктно-орієнтований стиль найприйнятніший для найширшого кола задач.
Алгоритмічний метод моделювання передбачає процедурно-
орієнтований стиль програмування, у рамках якого програміст створює
процедури, що викликають одна одну для виконання поставлених задач і
обробки даних.
Головним будівельним блоком є процедура чи функція, а увага
приділяється насамперед питанням передачі керування і декомпозиції
великих алгоритмів на менші. Нічого поганого у цьому немає, якщо не
зважати на те, що системи важко адаптуються при зміні вимог чи збільшенні
розміру додатка.
За використання об’єктно-орієнтованого стилю програміст створює
програмні об’єкти і наділяє їх визначеною поведінкою, реакцією на зміни
зовнішніх умов. Такі об’єкти взаємодіють між собою, виконують визначені
задачі, приймають, обробляють і передають дані.
На об’єктно-орієнтованому програмуванні базується об’єктно-
орієнтований метод моделювання. Якщо об’єктно-орієнтоване
програмування спрямоване на правильне й ефективне використання об’єктів
у рамках конкретних мов, то об’єктно-орієнтоване моделювання спрямоване
на правильне й ефективне структурування складних систем.
Об’єктно-орієнтований метод моделювання передбачає такий аналіз
предметної області, за якого уже на початкових етапах розробки програмної
системи можна було б вирізняти набори взаємодіючих об’єктів.
Об’єктно-орієнтована модель має чотири головні властивості:

37
- абстрагування – виокремлення істотних характеристик об’єкта, що
вирізняють його з-поміж інших видів об’єктів;
- інкапсуляція – приховування внутрішньої реалізації об’єкта за
наданим цим об’єктом інтерфейсом;
- модульність – здатність системи розкладатися на внутрішньо
сильно чи слабко зв’язані між собою модулі;
- ієрархія – упорядкування абстракцій і розташування їх за рівнями.
Ці властивості є головними, і за відсутності будь-якого з них модель не
буде об’єктно-орієнтованою.
Існує також три додаткових властивості, корисні в об’єктній моделі, без
яких, однак, можна обійтися:
- типізація – створення об’єктів на основі шаблонів визначеного
типу;
- паралелізм – здатність системи обробляти декілька повідомлень чи
задач паралельно;
- збережуваність – здатність системи зберігати не тільки дані,
але й об’єкти у проміжку між окремими запусками системи.
Об’єктно-орієнтоване моделювання програмних систем довело свою
корисність при побудові систем будь-якого розміру і складності у різних
областях людської діяльності. Окрім того, сучасні мови програмування,
інструментальні засоби та операційні системи, здебільшого, є тією чи
іншою мірою об’єктно-орієнтованими, а це дає вагомі підстави трактувати
світ у термінах об’єктів.

4.2 Архітектурний базис UML
Уніфікована мова моделювання (UnifiedModelingLanguage, UML) [14] –
це графічна мова для специфікації, візуалізації, конструювання і
документування програмних систем. За допомогою UML можна розробити
детальний план такої системи, який відображатиме і концептуальні елементи
системи (системні функції та бізнес-процеси), і особливості її реалізації

38
(класи, схеми баз даних, програмні компоненти багаторазового використання
тощо).
Мову UML [1] призначено для моделювання програмних систем. Самі
автори UML визначають її як графічну мову моделювання загального
призначення, яку використовують для специфікації, візуалізації,
конструювання і документування усіх артефактів, які створюються під час
розробки програмних систем.
- специфікація – це декларативний опис того, як усе побудоване або
працює. UML надає достатньо формальні та універсальні засоби для
специфікації усіх можливих артефактів, що дає змогу знизити ризик
неоднозначного сприйняття специфікації;
- візуалізація – представлення інформації у графічній формі,
придатній для сприйняття людиною. Часто моделювання є єдиним засобом,
який дає змогу уявити систему загалом як одне ціле. Проблема полягає в
обмеженому сприйнятті людиною складних сутностей. Моделювання
передбачає розділення складної системи на дещо простіші складові та окремо
розглядає кожну з цих складових. Також моделювання дає змогу створювати
високорівневі моделі всієї системи, відкидаючи деталі, несуттєві для цього
рівня абстракції;
- конструювання – отримання набору програмних модулів, які
утворюють застосування або його компонент. Розроблені моделі системи
утворюють деякий базовий каркас, на основі якого можна будувати систему.
Сучасні CASE-засоби дають змогу деякою мірою автоматизувати
конструювання програмного коду на підставі розроблених моделей;
- документування проектних рішень. Для підтримки та розвитку
програмних продуктів потрібна вичерпна та якісна документація.
Моделювання дає змогу одержати документи, які визначають високорівневу
організацію системи. Такі документи необхідні для початкового
ознайомлення з системою.

39
Діаграма UML – це графічне зображення елементів cистеми у формі
зв’язаного графа з вершинами (сутностями) і ребрами (відношеннями).
Діаграми можуть містити будь-яку комбінацію сутностей, однак у практиці
моделювання застосовують порівняно невелику кількість типових
комбінацій, а саме:
− діаграми класів (classdіagram) [3] – зображають класи, інтерфейси,
об’єкти і кооперації, а також відношення між ними. Ці діаграми
відображають статичні аспекти системи;
− діаграми об’єктів (objectdіagram) – зображають об’єкти і
відношення між ними. Це статичні знімки екземплярів сутностей,
зображених на діаграмах класів;
− діаграми прецедентів (usecasedіagram) – зображають прецеденти й
акторів, а також відношення між ними. Ці діаграми відображають статичні
аспекти системи;
− діаграми взаємодії – зображають об’єкти та повідомлення, якими
об’єкти можуть обмінюватися. Зазвичай, розглядають два часткові випадки
таких діаграм: діаграми послідовностей (sequencedіagram), що відображають
часову упорядкованість повідомлень, і діаграми кооперації
(collaboratіondіagram), на яких зображають структурну організацію об’єктів,
що обмінюються повідомленнями. Ці типи діаграм є ізоморфними. Діаграми
взаємодії відображають динамічні аспекти системи;
− діаграми станів (statechartdіagram) – зображають автомат, що
налічує стани, переходи, події і види дій. Ці діаграми відображають
динамічні аспекти системи;
− діаграми діяльностей (actіvіtydіagram) – це окремий випадок
діаграми станів (на діаграмі зображають переходи потоку керування від
одного виду діяльності до іншого усередині системи);
− діаграми компонентів (componentdіagram) – зображають сукупність
компонентів та існуючі між ними залежності. Ці діаграми відображають
статичні аспекти системи;

40
− діаграми розміщення (deploymentdіagram) – зображають
конфігурацію вузлів системи і розміщених у них компонентів. Ці діаграми
відображають статичні аспекти системи. Вони зв’язані з діаграмами
компонентів, оскільки у вузлі розміщують один чи декілька компонентів.
Програмна система (або деяка інша система) – це сутність аналізу та
проектування, яку розглядають з різних позицій за допомогою моделей, які
відображають діаграмами. Діаграма – графічна проекція елементів системи.
Один елемент можна зображати на різних діаграмах. Кожна діаграма
відображатиме одне з можливих представлень елементів системи.
Елементи мови UML комбінуються один з одним за певними
семантичними правилами, які дають змогу коректно та однозначно
визначати:
- назви, які можна надавати сутностям, відношенням і діаграмам;
- область дії – контекст, в якому назва має певне значення;
- видимість – контекст, в якому назва може використовуватися
іншими елементами;
- цілісність – узгоджена поведінка та взаємодія елементів;
- виконання – правильне розуміння поведінки системи в динаміці.
Для моделювання програмних систем необхідно розглядати їх з різних
позицій. Усі, хто має відношення до проекту, – кінцеві користувачі,
аналітики, прикладні програмісти, системні адміністратори, тестувальники,
менеджери проектів тощо – переслідують власні інтереси, і кожен дивиться
на створювану систему по різному в різні моменти її життя.
Абстрактний граф моделі, який складається з множини різнотипних
сутностей і відношень, не підлягає конструюванню загалом. З нього
виокремлюють тільки сутності та відношення, актуальні для певної точки
зору (представлення).
Набір представлень моделі є ще менш формальним і догматичним, ніж
набір канонічних типів діаграм. Найпопулярнішим вважають набір
представлень, описаних авторами UML:

41
− представлення прецедентів (Usecaseview) – це опис поводження
системи з позиції зовнішніх користувачів, аналітиків і тестувальників;
− логічне представлення (Logicalview) – це опис системи з позиції
проектування. Він охоплює класи, інтерфейси та кооперації, що формують
словник предметної області та її розв’язок;
− представлення процесів (Processview) – це опис взаємодії процесів
під час роботи системи. Він віддзеркалює такі аспекти, як паралелізм,
синхронізація, продуктивність, масштабованість і пропускна здатність;
− представлення компонентів (Componentview) – це опис конфігурації
системи з позиції реалізації, який охоплює компоненти і файли, що
використовуються для збирання і випуску готового програмного продукту;
− представлення розміщення (Deploymentview) віддзеркалює
топологію зв’язків апаратних засобів і розміщення на них компонентів.

4.3 Розробка діаграми розгортання
Діаграма розгортання (англ. Deploymentdiagram) [26] – діаграма в UML,
на якій відображаються обчислювальні вузли під час роботи програми,
компоненти, і об'єкти, що виконуються на цих вузлах. Компоненти
відповідають представленню робочих примірників одиниць коду.
Компоненти, що не мають представлення під час роботи програми на таких
діаграмах не відображаються; зате їх можна відобразити на діаграмах
компонентів. Діаграма розгортання відображає робочі екземпляр компоненів,
а діаграма компонентів, у свою чергу, відображає зв'язки між типами
компонентів.
Розроблений веб-сайт майстерні друку запускається на комп'ютері,
який має деяку апаратну конфігурацію і працює під управлінням певної
операційної системи. Веб-орієнтовані програми часто вимагають для своєї
роботи деякої ІТ-інфраструктури, зберігають інформацію в базах даних,
розташованих на серверах , викликають веб-сервіси, використовують
загальні ресурси і т. д. У таких випадках непогано б мати графічне

42
представлення інфраструктури, на яку буде розгорнуто програму. Ось для
цього і потрібні діаграми розгортання, які іноді називають діаграмами
розміщення. Думаю, очевидно, що такі діаграми є сенс будувати тільки для
апаратно-програмних систем, тоді як UML дозволяє будувати моделі будь-
яких систем, не обов'язково комп'ютерних. По-перше, графічне
представлення ІТ-інфраструктури може допомогти більш раціонально
розподілити компоненти системи по вузлах мережі, від чого, як відомо,
залежить в тому числі і продуктивність системи. По-друге, така діаграма
може допомогти вирішити безліч допоміжних завдань, пов'язаних,
наприклад, із забезпеченням безпеки.Діаграма розгортання показує
топологію системи і розподіл компонентів системи за її вузлів, а також
сполуки–маршрути передачі інформації між апаратними вузлами. Це єдина
діаграма, на якій застосовуються "тривимірні" позначення: вузли системи
позначаються кубиками. Всі інші позначення в UML – плоскі фігури.
На діаграмі розгортання передбачено два стереотипи для вузлів
«executionEnvironment» і «device». Вузол зі стереотипом
«executionEnvironment» дозволяє моделювати апаратно-програмну
платформу, на якій відбувається виконання програми. Прикладами
середовища виконання є: операційна система, система керування базами
даних тощо. Вузол зі стереотипом «device» також моделює апаратно-
програмну платформу, але допускає можливість вкладення одного вузла в
інший. Якщо вузли пов'язані між собою відношенням асоціації, то це означає
те ж, що і в інших контекстах: можливість обміну повідомленнями. Стосовно
до обчислювальних мереж, що складається з вузлів, асоціація означає
наявність каналу зв'язку. Якщо потрібно вказати додаткову інформацію про
властивості каналу, то це можна зробити, використовуючи загальні
механізми: стереотипи, обмеження та іменовані значення.
У якості апаратного засобу виступає персональний комп’ютер (PC) зі
стереотипом, на якому встановлюються браузери Chrome, Firefox або Opera,
які позначені у вигляді компонентів на діаграмі. Всі вони відправляють GET-

43
запит до HTTP сервера Node.js. Після прийому на сервері в якості обробника
виступає інтерпретатор JS, який оброблює код та робить відповідні запити до
бази даних. Після цього сервер вертає відповідь до клієнта і генерується
відповідне представлення.Це є основним завданням Node.js, яка обробляється
так званим ядром веб-сервера. Для кожного HTTP запиту повинен
запускатися генератор контенту. Деякі модулі можуть реєструвати власні
генератори контента, визначаючи функцію обробника.

4.4 Розробка діаграма прецедентів (UseCase)
UML діаграма прецедентів [26] – діаграма, на якій зображено
відношення між акторами та прецедентами в системі. Також, перекладається
як діаграма варіантів використання.
Діаграма прецедентів є графом, що складається з множини акторів,
прецедентів (варіантів використання) обмежених границею системи
(прямокутник), асоціацій між акторами та прецедентами, відношень серед
прецедентів, та відношень узагальнення між акторами. Діаграми прецедентів
відображають елементи моделі варіантів використання.
Суть даної діаграми полягає в наступному: проектована система
представляється у вигляді безлічі сутностей чи акторів, що взаємодіють із
системою за допомогою так званих варіантів використання. Варіант
використання (англ. usecase) використовують для описання послуг, які
система надає актору. Іншими словами, кожен варіант використання визначає
деякий набір дій, який виконує система при діалозі з актором. При цьому
нічого не говориться про те, яким чином буде реалізована взаємодія акторів
із системою.
У мові UML є кілька стандартних видів відношень між акторами і
варіантами використання:
- асоціації (англ. association relationship);
- включення (англ. include relationship);
- розширення (англ. extend relationship);

44
- узагальнення (англ. generalization relationship).
При цьому загальні властивості варіантів використання можуть бути
представлені трьома різними способами, а саме – за допомогою відношень
включення, розширення і узагальнення.
Відношення асоціації – одне з фундаментальних понять у мові UML і в
тій чи іншій мірі використовується при побудові всіх графічних моделей
систем у формі канонічних діаграм.
Включення (англ. include) у мові UML – це різновид відношення
залежності між базовим варіантом використання і його спеціальним
випадком. При цьому відношенням залежності (англ. dependency) є таке
відношення між двома елементами моделі, при якому зміна одного елемента
(незалежного) приводить до зміни іншого елемента (залежного).
Відношення розширення (англ. extend) визначає взаємозв'язок базового
варіанта використання з іншим варіантом використання, функціональна
поведінка якого задіюється базовим не завжди, а тільки при виконанні
додаткових умов.
Раціональний уніфікований процес розробки моделі складної системи
являє собою розбиття її на складові частини з мінімумом взаємних зв'язків на
основі виділення пакетів. У самій мові UML пакет “Варіанти використання” є
підпакетом пакета “Елементи поведінки”. Останній специфікує поняття, за
допомогою яких визначають функціональність модельованих систем.
Елементи пакета варіантів використання є первинними по відношенню до
тих, за допомогою яких можуть бути описані сутності, такі як системи і
підсистеми. Однак внутрішня структура цих сутностей ніяк не описується.
Базові елементи цього пакета – варіант використання і актор.
Оскільки в загальному випадку актор завжди знаходиться поза
системою, його внутрішня структура ніяк не визначається. Для актора має
значення тільки його зовнішнє представлення, тобто те, як він сприймається з
боку системи. Актори взаємодіють з системою за допомогою передачі і
прийому повідомлень від варіантів використання. Повідомлення являє собою

45
запит актором сервісу від системи і отримання цього сервісу. Ця взаємодія
може бути виражене за допомогою асоціацій між окремими акторами і
варіантами використання. Крім цього, з акторами можуть бути пов'язані
інтерфейси, які визначають, яким чином інші елементи моделі взаємодіють з
цими акторами.

4.5 Розробка діаграми компонентів
Мова UML [14] – це графічна мова моделювання, призначена для
специфікації, візуалізації, проектування та документування всіх артефактів,
створюваних при розробці програмних систем. Основне призначення UML –
надати, з одного боку, досить формальний, з іншого боку, досить зручний та
універсальний засіб, що дозволяє до деякої міри знизити ризик розбіжностей
у тлумаченні специфікацій.
Для проведення моделювання сайту була обрана діаграма компонентів,
тому що вона в цілому відображує частини розроблену системи та відносини
між ними. Це дає можливість спроектувати архітектуру системи та побачити
усі її основні та допоміжні частини, як єдину структуру.
Діаграма компонентів описує особливості фізичного представлення
системи. Вона дозволяє визначити архітектуру розроблюваної системи,
встановивши залежності між програмними компонентами, в ролі яких може
виступати вихідний і виконуваний код. Основними графічними елементами
діаграми компонентів є компоненти, інтерфейси і залежності між ними.
Діаграма компонентів розробляється для наступних цілей:
- візуалізації загальної структури вихідного коду програмної системи;
- специфікації виконуваних варіантів програмної системи;
- забезпечення багаторазового використання окремих фрагментів
програмного коду;
- представлення концептуальної і фізичної схем баз даних.
Діаграма компонентів забезпечує узгоджений перехід від логічного
представлення до конкретної реалізації проекту у формі програмного коду.

46
Одні компоненти можуть існувати тільки на етапі компіляції програмного
коду, інші на етапі його виконання. Ця діаграма відображає загальні
залежності між компонентами, розглядаючи останні як класифікатори.
Для представлення фізичних сутностей в мові UML застосовується
спеціальний термін – “component” (компонент). Компонент реалізує деякий
набір інтерфейсів і служить для загального позначення елементів фізичного
представлення моделі. Для графічного представлення компонента
використовується спеціальний символ – прямокутник зі вставленими зліва
двома більш дрібними прямокутниками. Усередині великого прямокутника
записується ім'я компонента і, при необхідності, деяка додаткова інформація.
Зображення цього символу може незначно варіюватися залежно від
характеру асоційованої з компонентом інформації.
Ім'я компонента підпорядковується загальним правилам іменування
елементів моделі в мові UML і може складатися з будь–якого числа букв,
цифр і деяких розділових знаків.
Окремий компонент може бути представлений на рівні типу або на
рівні екземпляра. Графічне зображення в обох випадках однакове, але
правила запису імені компонента відрізняються. Якщо компонент
представляється на рівні типу, то в якості його імені записується тільки ім'я
типу з великої літери. Якщо ж компонент представляється на рівні
екземпляра, то в якості його імені записується <ім'я компонента> ':' <ім'я
типу>. При цьому весь рядок імені підкреслюється.
В якості простих імен прийнято використовувати імена виконуваних
файлів (із зазначенням розширення ехе після крапки–роздільника),
динамічних бібліотек (DLL розширення), веб–сторінок, (розширення HTML),
текстових файлів (TXT розширення або DOC) або файлів довідки, файлів баз
даних (БД) або файлів з вихідними текстами програм (розширення html, cpp
для мови C ++ розширення для мови Java .java), скрипти (pi, asp) та інші.
Оскільки конкретна реалізація логічного представлення моделі системи
залежить від використовуваного програмного інструментарію, то й імена

47
компонентів визначаються особливостями синтаксису відповідної мови
програмування.
В окремих випадках до простого імені компоненту може бути додана
інформація про ім'я пакету і про конкретну версію реалізації даного
компонента. У цьому випадку номер версії записується як помічене значення
у фігурних дужках. В інших випадках символ компоненту може бути
розділений на секції, щоб явно вказати імена реалізованих в ньому
інтерфейсів.
Оскільки компонент як елемент фізичної реалізації моделі представляє
окремий модуль коду, іноді його коментують з вказівкою додаткових
графічних символів, що ілюструють конкретні особливості його реалізації. Ці
додаткові позначення для приміток не специфіковані в мові UML, проте їх
застосування спрощує розуміння діаграми компонентів, підвищуючи
наочність фізичного представлення.
В UML виділяють три види компонентів:
- розгортання, які забезпечують безпосереднє виконання системою
своїх функцій. Такими компонентами можуть бути спільні бібліотеки з
розширенням DLL, веб–сторінки на мові розмітки гіпертексту з розширенням
HTML і файли довідки з розширенням HLP;
- робочі продукти. Як правило, це файли з вихідними текстами
програм, наприклад, з розширеннями html або срр для мови C ++;
- виконання, що представляють собою виконувані модулі – файли з
розширенням ехе.
Діаграма компонентів веб–сайту, яка дозволяє побачити яким чином
взаємодіють між собою сторінки веб сайту. У якості сутностей, які групують
сторінки одного типу використовуються пакети. Якщо проводиться
моделювання великих систем або систем з багатьма частинами, там буде
багато різних класифікаторів у моделі. Управління всіма класами в даному
випадку буде представляти собою складне завдання. Тому, UML надає
організаційний елемент, який називається пакет. Пакети дозволяють

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

49
РОЗДІЛ 5
ДОСЛІДЖЕННЯ ТА АНАЛІЗ РОЗРОБЛЕНОЇ СИСТЕМИ

5.1 Логічна структура програми
Клієнтський додаток ПЗ для бугалтерії супермаркетів розділений на
два додатки. А саме: програмне забезпечення касира та адміністрування. Такі
вікна доступні для касира:
• «Авторизація»;
• «Робоче вікно продажів».
Код який реалізує головну сторінку (робоче вікно продажів):
DefaultTableModelmodel = (DefaultTableModel) jTable1.getModel();
intkol;
switch (evt.getKeyCode()) {
case 10: //Добавляем товар с Бд по штрих код if
("".equals(jTextField1.getText())) return; try {
if (tovar.loadTovar(jTextField1.getText())) {
String s = (String) JOptionPane.showInputDialog( rootPane,
"Введитеколичество: ", "Количество",
JOptionPane.INFORMATION_MESSAGE, null, null, "1");
if ((s != null) && (s.length() > 0)) { kol = Integer.parseInt(s);
} else {
kol = 1;
}
doublesum = tovar.getPrice() * kol; i++;
Object[] t = {i, tovar.getName(), tovar.getEd(), tovar.getPrice(), kol, sum};
model.addRow(t);
} else {
vc.loadCard(jTextField1.getText());
guest_show.setText("Гість: " + vc.getCard());
}

50
} catch (SQLExceptionex) {
Logger.getLogger(NewJFrame1.class.getName()).log(Level.SEVERE, null, ex);
}
jTextField1.setText(null); break;
case 123: //Подщитиваем чек
for (int j = 0; j <model.getRowCount(); j++) { Object m = model.getValueAt(j,
5);// (row,column) sum_tick +=Double.parseDouble(m.toString());
}
amount = sum_tick; sum_ticket.setText(fmt(sum_tick) + " грн.");
if (vc.getBalance() > 0 &&vc.getBalance() <amount&&vc.getStatus()) { int n =
JOptionPane.showOptionDialog(rootPane, "Сума до сплати: "
+ Double.toString(amount) + "грн.\nСписати з скарбнички: "
+ fmt(vc.getBalance()) + " грн. ?", "Скарбничка",
JOptionPane.YES_NO_OPTION,
JOptionPane.QUESTION_MESSAGE,
null, option, option[0]);
if (JOptionPane.YES_OPTION == n) { amount -= vc.getBalance();
jLabel8.setText(fmt(vc.getBalance())); try {
vc.zeroBalance();
} catch (SQLExceptionex) {
Logger.getLogger(NewJFrame1.class.getName()).log(Level.SEVERE, null, ex);
}
}
}
if (amount>= 49.99 && !vc.getStatus()) {
String s = (String) JOptionPane.showInputDialog( rootPane, "ВВедіть номер ВР
карти: ", "Нова ВР карта",
JOptionPane.INFORMATION_MESSAGE, null, null,
"30000xxxx");
//If a stringwasreturned, sayso. if (s != null&&s.length() > 8 ) {

51
try {
vc.createCard(s);
} catch (SQLExceptionex) {
Logger.getLogger(NewJFrame1.class.getName()).log(Level.SEVERE, null, ex);
}
}
guest_show.setText("Гість: " + vc.getCard());
}
this.jLabel1.setText(fmt(amount) + " грн."); visibleRes(true);
break; case122:
jDialog1.setVisible(true); break;
}
Головне вікно додатку (робоче вікно продажів) має вигляд показаний
на рис. 5.1. В цьому вікні виконується безпосередньо основна частина роботи
з додатком, а саме – продаж товарів та створення звітів. Це робоче місце, до
якого має доступ тільки касир.

Рис. 5.1. Головна сторінка програми (робоче вікно продажів)

52
На даній формі розміщені такі компоненти:
• jMenu;
• jTable;
• jLabel;
• jTextFiled.
Вікно авторизації має наступний вигляд, показаний на рис. 5.2 і
призначене для отримання доступу до вікна продажів та адміністраторскої
панелі. Кожен користувач має різний рівень доступу до даних програми і
може виконувати тільки те, що дозволено на певному рівні доступу.

Рис. 5.2. Вікно авторизації

53
На даній формі розміщені такі компоненти:
• jLabel;
• jTextFiled;
Сценарій використання програми касира для розрахунку покупця
виглядає наступним чином:
1. Діючі лиця: касир, каса, покупець;
2. Ціль: продати вибраний товар покупцям;
3. Передумова: покупець прийшов до каси і виклав свій товар, щоб
його оплатити;
4. Успішний сценарій:
- Касир авторизується (авторизація проходить 1 раз).
- Касир починає виконувати продаж: сканує товар і по завершенню
сканування переходить до розрахунку.
- Покупець виконує розрахунок одним із методів: готівкою або
бонусами.
- Після оплати каса видає чек.
Сценарій використання програми касира по завершенню роботи з
касою:
1. Діючі лиця: касир, каса.
2. Ціль: завершити роботу з касою та створити всі необхідні звіти.
3. Передумова: касир закінчив працювати з касою
4. Успішний сценарій:
- Касир переходить до створення звітів.
- Каса створює звіти:
o X-звіт
o Z-звіт
Касир виконує підрахунок готівки за допомогою вбудованого
калькулятора.
На рис. 5.3 представлена use-case діаграма програми касира.

54

Рис. 5.3. Use-Case діаграма програми касира

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

Рис. 5.4. Адміністраторська панель

55
Вікно розділене на певні вкладки, на яких виконуються різні функції,
такі як:
• Додавання товарів.
• Постулення товарів.
• Додавання та видалення користувачів.
• Пошук товарів за параметром.
• Перегляд залишків.
• Редагування товарів.
На даній формі розміщені такі компоненти:
• jLabel;
• jTextFiled;
• jButton;
• jTabbedPanel;
• jTable.
Вікно авторизації адміністратора представлено на рис. 5.5.

Рис. 5.5. Вікно авторизації адміністратора

Програма адміністрування Use-Case діаграму представлену на рис. 5.6.

56

Рис. 5.6. Use-Case діаграма додатку «Адміністрування»

5.2 Опис класів додатку
Для підключення до бази даних було створено окремий клас DBWorker
(рис. 5.7). За допомогою даного класу відбувається безпосереднє з’єднання
клієнтського додатку з базою даних.

Рис. 5.7. Клас DBWorker

57
Весь додаток розділений на окремі класи. Кожен клас відповідає
окремій таблиці в базі даних, що значно полегшує роботу.
Всі класи програми «касира» зображені на діаграмі класів (рис. 5.8).

Рис. 5.8. Діаграма класів програми «Касира»

Калькулятор (Calc).
1. money – Загальна сума порахованих грошей;
2. tmp – Окрема сума грошей конкретного номіналу.
Товар (Tovar).

58
1. id – номер товару;
2. name – назва товару;
3. ed_iz – одиниця виміру товару;
4. price – ціна товару;
5. kol – кількість товару;
6. kod – штрих-код товару;
7. art – артикул товару;
8. dBworker – змінна підключення до БД;
9. resultSet – в дану зміну поміщується відповідь від БД; 10.statement
– в дану зміну поміщується запит до БД.
Користувачі (Users).
1. id – ід користувача;
2. access_level – рівень доступу користувача
3. login – логін користувача;
4. auth – приймає значення: успішне/ не успішне авторизування;
Робота з БД (DBWorker)
1. HOST – адреса БД;
2. USERNAME – ім’я користувача;
3. PASSWORD – пароль користувача;
4. Connection – вміщує в себе з’єднання з БД;
Бонусна карта (VrCard)
1. id – ід карти;
2. number_cards – номер карти;
3. balance – баланс карти;
4. status – статус карти;
Форма авторизації (NewJFrame) – клас форми авторизації, створений
програмно та доповнений.
Форма продажу (NewJFrame1) – клас форми продажу, основний клас
програми, створений програмно та доповнений.
На рис. 5.9 зображена діаграма класів програми «Адміністрування».

59

Рис. 5.9. Діаграма класів програми «Адміністрування»

Адміністраторська панель (AdminPanel) – клас програми
«Адміністрування», являється основним класом програми, створений
системно та доповнений. Всі інші класи описані вище.

5.3 Список аномальних ситуацій і реакцій програми, які
припускаються
1. Можливий випадок коли користувач вводитиме некорректі дані при
додаванні нової інформації. На цей випадок в кожну форму доданий
функціонал що виводить повідомлення про помилку в ведених даних

60
2. Можливий випадок коли користувач вводитиме унікальні дані, які
вже зайняті в системі при додаванні нової інформації. На цей випадок в
кожну форму доданий функціонал що виводить повідомлення про помилку в
ведених даних.
3. Якщо з різних причин не спрацює тригер, що додає дані в таблицю
журнал, після додавання даних в базу даних, то користувач має змогу вручну
додати дані.
4. Якщо з якигось причин запит не буде виконано на сторінці бази
даних, то повідомлення про помилку з SQL помилкою буде виведено
користувачу додатка.

61
РОЗДІЛ 6
РОЗРОБКА КОМПЛЕКСУ РЕКОМЕНДАЦІЙ ДЛЯ РОБОТИ З
ІНФОРМАЦІЙНОЇ СИСТЕМИ

6.1 Опис додатку
Додаток база даних «Продажу в продуктовому магазині» призначений
для виконання продажу товарів та продуктів магазину. Цей додаток дозволяє
взаємодіяти користувачу з базою даних та вносити зміни до неї.

6.2 Вікно авторизації
Як тільки додаток було запущено, на екрані з’явиться вікно авторизації
(рис. 6.1) де потрібно ввести логін та пароль користувача після чого
натиснути кнопку Enter на клавіатурі. Якщо дані були введені правильно то
відобразиться наступне вікно в залежності від рівня доступу користувача
який було задано адміністратором. Ознайомитись з роботою інших вікон ви
можна в наступних розділах.

Рис.6.1. Вікно авторизації

62
Представлений інтерфейс реалізовується кодом:
privatevoidjPassKeyPressed(java.awt.event.Key
Eventevt) { Usersuser = newUsers();
if(evt.getKeyCo
de() == 10){
try {
user.loadUser(jLogin.getText());
if(jPass.getText().equals(user.getP
assword())){
if(user.getAccess_level() !=
2) {
AdminPanel.main(args);
AdminPanel.lvl(user.getAcc
ess_level());
} else {
NewJFrame1.frame.setVisible(true)
;
NewJFrame1.setPib(user.getPIB(),u
ser.getId());
}
user.setA
uth(true);
auth =
user.getA
uth();
jLabel5.setText("Успешно!");
jLabel5.setForeground(Color.green);
dispatchEvent(newWindowEvent(newNe
wJFrame(),
WindowEvent.WINDOW_CLOSING));

63
}
else
{
user.setA
uth(false)
; auth =
user.getA
uth();
jLabel5.setText("Ошибка!
Провертеправильностьввода!");
jLabel5.setForeground(Color.red);
}
} catch (SQLExceptionex) {
Logger.getLogger(NewJFrame.class.getName()).log(Level.SEVERE,
null, ex);
}
}
}

6.3 Вікно продажів
У даному вікні (рис. 6.2) потрібно в поле, яке знаходиться в самому
верху ввести штрих-код товару та натиснути клавішу Enter, що знаходиться
на клавіатурі.

64

Рис. 6.2. Вікно продажів

Після чого з’явиться вікно в якому необхідно вказати кількість цього
товару який буде добавлено в чек (рис 6.3). Потім цей товар добавиться в
таблицю, що знаходиться нижче (рис 6.4).

Рис. 6.3. Додавання товару в чек

Рис. 6.4. Чек

65
Якщо у покупця є карта власного рахунку її потрібно ввести в те ж
саме поле. У разі, якщо карта відсутня і сума чеку більше 49.9 з’явиться вікно
з додаванням нової карти (рис. 6.5).

Рис. 6.5. Добавлення нової карти

У цьому вікні необхідно ввести код нової карти та натиснути «ОК», у
разі відмови натиснути «Cancel».
Коли всі товари додані до чеку, його необхідно закрити, для цього
натисніть клавішу F12 після чого з’явиться наступна панель розрахунку (рис.
6.6):

Рис. 6.6. Розрахунок

В полі «Получено» вводиться сума яку дав покупець та натискається
ENTER, після чого з’явиться вікно в якому дрібні гроші запропонує
перевести до скарбнички (рис. 6.7). Після чого додаток автоматично
розщитає суму решти яку необхідно видати покупцеві.

66

Рис. 6.7. Переведення дрібних грошей в скарбничку

Для відкриття нового чеку натисніть F12 знову.
Якщо у покупця є вже карта і ви її ввели, а також на карті баланс
більше 0, тоді з’явиться вікно в якому покупцеві буде запропоновано списати
з скарбнички накопичення (рис. 6.8). Ця сума буде відмінусована від суми
чеку та добавлена в поле «знижка».

Рис. 6.8. Списання коштів з скарбнички

По завершенню роботи необхідно зняти звіти. Для цього в меню в
пункті інструменти необхідно вибрати пункт X, Z або повний звіт. Програма
сформує звіт автоматично (рис. 6.9).
Для виходу із програми, натисніть пункт меню «Вихід».

67

Рис. 6.9. Х-звіт

6.4 Адміністраторська панель
Дане вікно розділено на декілька панелей, а саме:
• Поступлення;
• Добавлення;
• Добавлення/видалення користувачів;
• Пошук.
Адміністраторська панель реалізовується кодом:
privatevoid jButton3ActionPerformed(java.awt.event.ActionEventevt) {
DefaultTableModelmodel = (DefaultTableModel)jTable2.getModel();
List<String>list = newArrayList<>();
Stringquery = null;
for(int i = 0; i<model.getRowCount(); i++){ try {
for(intcount = 0; count<model.getColumnCount(); count++){
list.add(model.getValueAt(i, count).toString());
}

68
query = "INSERT INTO kasa.tovary (name, odin_vimir, "
+ "price, kol, kod, art, id_category, id_sale) VALUES
('"+list.get(1)+"', "
+ "'"+list.get(2)+"', '"+list.get(3)+
"', '"+list.get(4)+"', '"+list.get(5)+"', '"+list.get(6)+"',("
+ "SELECT kasa.category.id FROM kasa.category WHERE
kasa.category.name = '"+list.get(7)+"'), 1);";
JOptionPane.showMessageDialog(rootPane, query);
Statementstatement = dBWorker.getConnection().createStatement();
statement.executeUpdate(query);
list.clear();
} catch (SQLExceptionex) {
Logger.getLogger(AdminPanel.class.getName()).log(Level.SEVERE,
null, ex);
}
}
introw = jTable2.getRowCount();
for(int t = 0; t<row; t++) model.removeRow(0); n = 0;
}
List<String>list_code = newArrayList<>();
privatevoid jButton2ActionPerformed(java.awt.event.ActionEventevt) {
//Проверяеместьлизапись в таблице for (String list_code1 : list_code) {
if (jTextField1.getText().equals(list_code1)) {
JOptionPane.showMessageDialog(AdminPanel.this, "Этот товар
уже добавлен!",
"Ошибкадобавления", JOptionPane.ERROR_MESSAGE);
return; //Выдатьсообщения о ошибке
}
}
DefaultTableModelmodel = (DefaultTableModel)jTable1.getModel();

69
Stringquery = "Select * Fromkasa.tovary WHERE kod =
"+jTextField1.getText();
try {
Statementstatement = dBWorker.getConnection().createStatement();
ResultSetresultSet = statement.executeQuery(query);
if(resultSet.next()){ //Добавляем товар в таблицуПоступления
n++;
Doubleprice = Double.parseDouble(jTextField3.getText()) * 1.3;
Object[] data = {n, resultSet.getString(2) ,jTextField1.getText(),
Integer.parseInt(jTextField2.getText()),
Double.parseDouble(jTextField3.getText()), fmt(price)};
model.addRow(data); list_code.add(jTextField1.getText());
} else{
JOptionPane.showMessageDialog(AdminPanel.this, "Товар не
найден!", "Ошибкадобавления",
JOptionPane.ERROR_MESSAGE);
return;
}
} catch (SQLExceptionex) {
Logger.getLogger(AdminPanel.class.getName()).log(Level.SEVER
E, null, ex);
}
//Чистим поля ввода jTextField1.setText(null);
jTextField2.setText(null); jTextField3.setText(null);
}

Панель поступлення має наступний вигляд (Рис. 6.10), та призначена
для прийому товарів, які вже є в базі даних.

70

Рис. 6.10. Панель поступлення

В цій панелі необхідно заповнити всі поля та натиснути добавити, після
чого товар буде доданий до таблиці. Коли всі товари додані, натискається
кнопка «Зберегти». Аналогічна робота і з наступними вікнами, такими як:
добавлення (рис. 6.11) та добавлення (рис. 6.12) та видалення користувачів

Рис. 6.11. Панель добавлення

71

Рис. 6.12. Панель добавлення та видалення користувачів

Панель пошук має наступний вигляд та предназначен для пошуку
товарів з можливим вказанням параметрів (рис. 6.13).

Рис. 6.13. Панель пошуку

72
ВИСНОВКИ

В ході виконання даної роботи було досягнуто основної мети, а саме:
розширення функцій касових апаратів за рахунок розробки інформаційних
систем автоматизованої обробки фінансової інформації супермаркетів. А
також було виконано наступне, що допомогло досягнути мети виконуваної
роботи:
- проведено аналіз предметної області та існуючих рішень (провести
дослідження існуючих аналогів касових апаратів з програмним
забезпеченням), проаналізувати поставлену задачу;
- проведено аналіз основних вимог до інформаційної системи;
- досліджено системи автоматизації обробки фінансової інформації
супермаркетів;
- розроблено інформаційну систему для бухгалтерії супермаркету,
- розроблено UML-модель програмного забезпечення для касового
апарату;
- розроблено алгоритм розрахунку клієнтів та ведення обліку залишків;
- проведено дослідження та аналіз розробленої системи;
- розроблено комплекс рекомендацій для роботи з інформаційної
системи.
Під час дослідження інформаційні системи автоматизованої обробки
фінансової інформації супермаркетів які базуються на використанні методів
теорії проектування систем, теорії системного аналізу, програмування та
алгоритмізації було досягнуто наступної наукової новизни:
- На підставі дослідження існуючих аналогів касових апаратів з
програмним забезпеченням сформульовані завдання.
- Розроблено UML-модель програмного забезпечення для касового
апарату. На відміну від існуючих моделей UML-модель має переваги, а саме
легкість навчання та засвоєння.

73
- Створено базу даних ведення обліку персоналу та залишків
продукції.
А також полягає в доведенні отриманих наукових результатів до
конкретних рішень:
- Розроблено алгоритм розрахунку клієнтів та ведення обліку
залишків.
- Удосконалено програмне забезпечення для касового апарату.
Не обійшлося і без особистого внеску, всі результати роботи отримані
автором самостійно. Робота провірена на плагіат.
Досліджене та розроблене програмне забезпечення включає в себе базу
даних та містить в собі інформацію про товари, користувачів, знижки та
карти покупців. Програма є інтуїтивно зрозумілою та комфортною у
використанні. Додаток дозволяє швидко і зручно працювати з ним.
Програмний продукт поділяється на дві програми, а саме: ПЗ касира та
адміністратора. Це розроблено для того, щоб мінімізувати не санкціонований
доступ до тої частини програми, яка не призначена для конкретного
працівника.
Розроблений додаток за допомогою мови програмування Java, що
взаємодіє з базою даних, та розширює її можливості. Додаток є зручним для
використання, за допомогою нього користувач має змогу працювати з базою
даних, контролювати розрахункові операції та наявність товару.

74
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. UML для бізнес-моделювання [Електронний ресурс] режим доступу:
https://evergreens.com.ua/ua/articles/uml-diagrams.html
2. Построение диаграммы классов [Електронний ресурс] режим доступу:
https://flexberry.github.io/ru/gpg_class-diagram.html
3. Джошуа Блох, Effective Java (Java. Эффективное программирование)
2001р. -141с.
4. РРО та касова дисципліна [Електронний ресурс] режим доступу:
https://www.golovbukh.ua/rubric/21-rro-ta-kasov-operats
5. Av.Market. [Електронний ресурс]. – Режим доступу:
http://avmarket.com.ua/article/1454-sravnitelnyy-test-napolnyh-kolonok-
canton-gle-496/
6. Практическая электроника. [Електронний ресурс]. – Режим доступу:
https://www.ruselectronic.com/achh-and-fchh/
7. MySQL Workbench [Електронний ресурс]. – Режим доступу:
https://uk.wikipedia.org/wiki/MySQL_Workbench
8. SQL [Електронний ресурс]. – Режим доступу:
https://uk.wikipedia.org/wiki/SQL
9. NetBeans IDE [Електронний ресурс]. – Режим доступу:
https://uk.wikipedia.org/wiki/NetBeans
10. MySQL [Електронний ресурс]. – Режим доступу:
https://uk.wikipedia.org/wiki/MySQL
11. Unified Modeling Language [Електронний ресурс]. – Режим доступу:
https://uk.wikipedia.org/wiki/Unified_Modeling_Language
12. Грофф Дж., Вайнберг П. SQL: полное руководство: Пер. с англ. – К.:
Издательская группа BHV, 2000. – 608 с.
13. Дейт К.Дж. Введение в системы баз данных: Пер. с англ. – 6-е изд. – К.:

75
Диалектика, 1998. – 784 с.
14. Грофф Дж., Вайнберг П. SQL: полное руководство: Пер. с англ. – К.:
Издательская группа BHV, 2000. – 608 с.

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