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

Семенчук, Катерина Максимівна
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9084
Title:	Програмне забезпечення системи розрахунку оптимального розміру замовлення за моделлю Уілсона
Authors:	Первvнінський, Станіслав Михайлович Семенчук, Катерина Максимівна
Keywords:	управління запасами;модель Уілсона;оптимальне замовлення;програмне забезпечення
Issue Date:	2023
Abstract:	Семенчук Катерина Максимівна, кваліфікаційна робота магістра на тему «Програмне забезпечення системи розрахунку оптимального розміру замовлення за моделлю Уілсона». Напрям підготовки 121 «Інженерія програмного забезпечення», ЧДТУ, Черкаси 2023. В даній кваліфікаційній роботі магістра проводяться дослідження систем роздрібної торгівлі та вивчення їх основних функцій, зокрема систем де використовуються функції управління запасами продукції. В магістерській роботі описано предметну область, структуру систем управління роздрібною торгівлею, зокрема запасами, запропоновано використання моделі Уілсона для більш ефективного управління запасами в системах управління роздрібною торгівлею, розроблено модель акторів та прецедентів, модель послідовності та проведено функціональне тестування системи. Результатом моєї роботи є побудована автоматизована система з використанням моделі Уілсона. Обсяг магістерської роботи складає _ сторінок, з них _ додатки. При написанні магістерської роботи була використана література та Інтернет джерела. Використані програмні засоби: JDBC, Java, MySQL, Spring Framework, Spring Security.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/9084
Appears in Collections:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)
Files in This Item:
File	Description	Size	Format
Семенчук Катерина. Маг. 2022.pdf Restricted Access		2.74 MB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
ЧДТУ.2281.005 ПЗ  
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
«магістра» 
освітній рівень 
  
на тему:  Програмне забезпечення системи розрахунку оптимального 
розміру замовлення за моделлю Уілсона 
 
 
 
Виконала:студентка 2 курсу, групи МПЗ-2104 
Спеціальність:  
121 «Інженерія програмного забезпечення»  
(шифр і назва напряму підготовки) 
 
 
Студент Семенчук К.М. 
 (прізвище та ініціали) 
Керівник Д.т.н., проф., Первунінський С.М. 
 (прізвище та ініціали) 
Рецензент  
 (прізвище та ініціали) 
 
 
 
 
 
 
 
Черкаси 2023 
5 
 
ЧДТУ.2281.005 ПЗ  
Черкаський державний технологічний університет 
 
Факультет інформаційних технологій і систем __________________________________  
Кафедра програмного забезпечення автоматизованих систем _____________________  
Освітній рівень магістр _____________________________________________________  
Спеціальність 121 «Інженерія програмного забезпечення» ________________________  
Освітня програма 121 «Інженерія програмного забезпечення» _____________________  
 
 
 ЗАТВЕРДЖУЮ: 
Зав. кафедри _ ______Голуб С.В. 
“_____” _______________20 __ р. 
 
ЗАВДАННЯ 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
студенту  Семенчук Катерині Максимівні____________________________________        
(прізвище, ім’я, по батькові) 
1. Тема проекту (роботи) Програмне забезпечення системи розрахунку оптимального розміру 
замовлення за моделлю Уілсона ______________________________________________ ___ 
Керівник проекту (роботи) Первунінський Станіслав Михайлович д.т.н._____________                   
професор (прізвище, ім’я , по батькові, науковий ступінь, вчене звання 
затверджена наказом Черкаського державного технологічного університету від «14» жовтня 
2022р. №275/04 
2. Строк подання студентом (роботи) “02” грудня__2022_р. 
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення, моделювання 
процесів предметної області, моделі оптимального замовлення, архітектура програмного 
забезпечення, тестування програмного забезпечення________________________________ 
 
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити) 
Існуючі методи та засоби розв’язання поставлених завдань___________________________ 
Теоретичні та експериментальні дослідження ______________________________________ 
Впровадження результатів досліджень у практику проектування програмного забезпечення 
інформаційних систем ______________________________________________ 
Розробка та тестування програмного забезпечення__________________________________   
Висновки_____________________________________________________________________ 
Додатки ____________________________________________________________ 
5. Перелік графічного  матеріалу (з точним  зазначенням обов’язкових креслень, плакатів)  
Постановка завдання. 
UML моделювання. 
Структура системи 
 
6. Дата видачі завдання _____02.09.2022р._________________________________________ 
6 
 
ЧДТУ.2281.005 ПЗ  
 
Календарний план 
(прізвище, ініціали) 
№ Назва етапів випускної магістерської Строк виконання етапів 
Примітка 
з/п роботи проекту (роботи) 
1 Підготовча стадія вересень Виконано 
1.1 Постановка задачі вересень Виконано 
1.2 Підготовка завдання вересень Виконано 
1.3 Погодження завдання вересень Виконано 
1.4 Затвердження завдання вересень Виконано 
2 Основна стадія жовтень Виконано 
2.1 Підбір матеріалів вересень Виконано 
2.2 Аналіз шляхів рішення поставленої задачі вересень Виконано 
2.3 Оформлення первісної редакції роботи вересень Виконано 
3 Заключна стадія листопад Виконано 
Оформлення пояснювальної записки 
3.1 роботи  листопад Виконано 
 в кінцевій редакції листопад  
3.2 Затвердження роботи грудень Виконано 
3.3 Рецензування роботи грудень Виконано 
 
 
 
 
 
 
 
 
Студент      _______________           Семенчук К.М. 
     (підпис)         (прізвище та ініціали) 
 
 
Керівник      _______________            Первунінський С.М 
     (підпис)         (прізвище та ініціали) 
 
 
  
7 
 
ЧДТУ.2281.005 ПЗ  
ЗМІСТ 
СПИСОК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ………….………..……5 
ВСТУП………………………………………………………………………………6 
1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ  
ПОСТАВЛЕНИХ ЗАВДАНЬ…………………………………………………...11 
1.1 Принципи створення інформаційних систем ……………………….….…...11 
1.2 Опис предметної області …………………..…………………………………15 
1.3Аналіз програмних аналогів………………………………………...……....22 
Висновки до першого розділу…………………………………………………....27 
2.ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ…………28 
2.1Теоретичні дослідження …………………………………………………........28 
2.2 Експериментальні дослідження……………...…………………..…….….....32 
Висновки другого розділу……………………………………………………..…39 
3.ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ……………………………………………..…40 
3.1 Моделювання предметної області.…………………………………….…....40 
3.1.1 Предметна область моделювання. ………………………..………………40 
3.1.2. Модель предметної області. Словник предметної області……………..42 
3.1.3 Елементи моделювання предметної області………………………….….43 
3.1.4. Робоча область моделювання…………………………………………….44 
3.2 Формування та аналіз вимог до програмного забезпечення …………..…45 
3.2.1 Первинні і детальні вимоги………………………………………………..45 
3.2.2 Вимоги замовника і розробника…………………………………………..46 
3.2.3 Функціональні і нефункціональні вимоги………………………………..47 
3.2.4. Формування вимог за допомогою діаграми прецедентів……………….48 
3.2.5. Проектування логічної структури програмного комплексу…………….51 
3.2.5.1 Діаграма класів…………………………………………………………....51 
3.2.5.2 Діаграма пакетів………………………………………………………..…54 
3.3 Архітектурне проектування…………………………………………………..56  
3.3.1 Діаграма компонентів……………………………………………………….56 
3.3.2 Діаграма розгортання……………………………………………………….58 
3.3.3 Моделювання поведінки системи………………………………................60 
3.3.3.1 Діаграма діяльності………………………………………………………60  
3.3.3.2 Діаграма послідовності………………………………………………..…62 
3.3.3.3Діаграма комунікації……………………………………………………....66 
 
 
 
ЧДТУ.2281.005 ПЗ 
Зм. Ли ст № докумемента Підпис Дата 
Розроб. Семенчук К.М. Літ. Лист Листів 
Програмне забезпечення системи 
Керівник Первунінський С. М.   8 8 
розрахунку оптимального розміру 
 
замовлення за моделлю Уілсона ФІТІС, кафедра ПЗАС,  
Н.контр. Півень О.Б. 
(Пояснювальна записка ) 
Затв. Голуб  С..В..  гр. МПЗ-2104 
ЧДТУ.2281.005 ПЗ  
3.3.3.4 Діаграма скінченого автомату…………………………………………..68 
Висновки третього розділу……………………………………………………...70 
4. КОНСТРУЮВАННЯ ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ ………………………………………….………………..…...70 
4.1 Обґрунтування вибору засобів реалізації…………………….…………….70 
4.2. Опис структурної (функціональної) схеми…………………………….….78 
4.3. Опис логічної схеми системи……………………………………………….79 
4.4 Розробка бази даних……………………………………………………….…80 
4.5 Розробка інтерфейсу користувача…………………………………………...85 
4.6 Опис розробки програмних компонентів ………………………………….90 
4.7 Тестування системи………………….………………………………………93 
4.7.1 Модульне тестування …………………..…………..…………….……….93  
4.7.2 Інтеграційне тестування………….………………………………………..97  
4.7.3 Системне тестування……………………………………….……………...100 
4.7.4 Приймальне тестування…………………………………………….……..101 
  Висновки до четвертого розділу………………………………………………103 
ЗАГАЛЬНІ ВИСНОВКИ………………………………………………………...104 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ…………………………….………....105 
Додатки…………………………………………………………………………..109 
 
  
9 
 Лист 
ЧДТУ.2281.005  ПЗ 
Зм. Лист № документа Підпис Дата  
  
ЧДТУ.2281.005 ПЗ  
АНОТАЦІЯ  
Семенчук Катерина Максимівна, кваліфікаційна робота магістра на тему 
«Програмне забезпечення системи розрахунку оптимального розміру 
замовлення за моделлю Уілсона». Напрям підготовки 121 «Інженерія 
програмного забезпечення», ЧДТУ, Черкаси 2023.  
В даній кваліфікаційній роботі магістра проводяться дослідження систем 
роздрібної торгівлі та вивчення їх основних функцій, зокрема систем де 
використовуються функції управління запасами продукції. В магістерській 
роботі описано предметну область, структуру систем управління роздрібною 
торгівлею, зокрема запасами, запропоновано використання моделі Уілсона для 
більш ефективного управління запасами в системах управління роздрібною 
торгівлею, розроблено модель акторів та прецедентів, модель послідовності та 
проведено функціональне тестування системи. Результатом моєї роботи є 
побудована автоматизована система з використанням моделі Уілсона. 
Обсяг магістерської роботи складає _ сторінок, з них _ додатки. При 
написанні магістерської роботи була використана література та Інтернет 
джерела. 
Використані програмні засоби: JDBC, Java, MySQL, Spring Framework, 
Spring Security.  
Ключові слова: управління запасами, модель Уілсона, оптимальне 
замовлення, програмне забезпечення.  
  
10 
 
ЧДТУ.2281.005 ПЗ  
ANNOTATION 
Kateryna Maksimivna Semenchuk, master's qualification thesis on the topic 
"Software support of the system for calculating the optimal order size according to 
the Wilson model." Field of training 121 "Software engineering", ChSTU, Cherkasy 
2023. 
In this master's thesis, retail systems are researched and their main functions 
are studied, in particular, systems where the functions of product inventory 
management are used. The master's thesis describes the subject area, the structure of 
retail management systems, in particular stocks, proposes the use of the Wilson model 
for more efficient management of stocks in retail management systems, develops a 
model of actors and precedents, a sequence model, and conducts functional testing of 
the system. The result of my work is a built automated system using the Wilson model. 
The volume of the master's work is _ pages, of which _ are appendices. When 
writing the master's thesis, literature and Internet sources were used. 
Used software tools: JDBC, Java, MySQL, Spring Framework, Spring 
Security. 
Key words: inventory management, Wilson's model, optimal ordering, 
software. 
  
11 
 
ЧДТУ.2281.005 ПЗ  
 
СПИСОК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ 
SQL – Structured query language – мова структурованих запитів 
БД – база даних 
Гб – гігабайт, кратна одиниця виміру кількості інформації, що 
дорівнює 1024 мегабайтам 
JSP – технологія, що дозволяє веб-розробникам динамічно 
генерувати HTML, XML та інші веб-сторінки 
ПЗ – програмне забезпечення 
ПП  програмний продукт 
СУБД – система управління базами даних 
ТЗ – технічне завдання 
Spring  універсальний фреймворк з відкритим вихідним кодом для 
Java-платформи 
 
  
12 
 
ЧДТУ.2281.005 ПЗ  
ВСТУП  
Актуальність теми: Стрімкий розвиток товарних і фінансових ринків  
стало потужним поштовхом до інтенсивного наростання процесів 
інформатизації у всіх сферах життя суспільства. Змінилися підходи до оцінки 
ролі інформації та інформаційного обслуговування виробничо-господарської, 
управлінської діяльності та різних категорій користувачів.  
Сучасне суспільство живе в період, що характеризується небувалим 
збільшенням інформаційних потоків. Найбільше зростання обсягу інформації 
спостерігається в промисловості, торгівлі, фінансово-банківській сфері.  
Ринкові відносини пред'являють підвищені вимоги до своєчасності, 
достовірності, повноти інформації, без якої немислима ефективна 
маркетингова, фінансово-кредитна, торговельна діяльність. Роль інформації в 
суспільному житті істотно змінюється. Інформація набуває перетворюючий, 
визначальний характер. Якісно нове обслуговування інформаційних процесів 
людської діяльності пов'язано з використанням сучасної персональної 
електронно-обчислювальної техніки, систем телекомунікацій, створенням 
мереж ЕОМ.  
Актуальність питань інформатизації всіх сфер суспільно-економічного 
життя цілком очевидна. Потреба у розробці та застосуванні ефективних і 
адекватних реальної дійсності комп'ютерних програм і технологій сьогодні 
зростає.  
Автоматизація в загальному вигляді являє собою комплекс дій та заходів 
технічного, організаційного та економічного характеру, який дозволяє знизити 
ступінь участі або повністю виключити безпосередню участь людини у 
здійсненні тієї чи іншої функції виробничого процесу, процесу управління.  
Таким чином, системи управління запасами можна розглядати як людино-
машинну систему з автоматизованою технологією одержання результатної 
інформації, необхідної для інформаційного обслуговування фахівців та 
оптимізації процесу управління в різних сферах людської діяльності, в тому 
13 
 
ЧДТУ.2281.005 ПЗ  
числі і в торгівлі. Роздрібна торгівля – один з найбільш складних видів бізнесу, 
що включає безліч елементів: виробництво, закупівлю, управління 
ланцюжками постачань, внутрішню логістику, доставку, торгівлю, взаємини з 
клієнтами і т.д. Такий широкий спектр бізнеспроцесів робить управління 
роздрібним бізнесом досить трудомістким тому, що вимагає аналізу великого 
обсягу різнорідних даних [3].  
Сьогодні поняття “комплексна автоматизація”, “інтегровані інформаційні 
системи”, “ІT-рішення по управлінню бізнес-процесами компанії” стали більш 
зрозумілими і прийнятними для менеджерів торговельного підприємства. Для 
вітчизняних підприємств сфери роздрібної торгівлі досить важливим кроком є 
безпосередньо вибір автоматизованої системи управління. В цілому, оцінюючи 
обсяг ринку програмного забезпечення України, слід зазначити, що програм на 
ньому представлено досить багато. Однак, незважаючи на це, досить складно 
знайти в них істотні відмінності, за винятком вартості. Кожна компанія, що 
пропонує свій програмний продукт, позиціонує його як той, що відповідає 
потребам і вимогам будь-якого підприємства, незалежно від його розміру і 
галузі. Якщо ж розглядати безпосередньо сферу торгівлі, то при виборі 
програмного продукту потрібен особливий підхід – дана галузь має велику 
кількість специфічних особливостей, які необхідно враховувати при 
автоматизації бізнес-процесів [3].  
Більшість спеціалістів при вирішенні питання управління компанією 
віддають перевагу комплексній системі автоматизації (переважно класу ERP). 
ERP-система (англ. Enterprіse Resource Plannіng System – система планування 
ресурсів підприємства) – це корпоративна інформаційна система, яка 
призначена для автоматизації обліку і управління. Як правило, ERPсистеми 
будуються по модульному принципу й охоплюють усі ключові процеси 
діяльності компанії [1]. Серед представлених на ринку систем управління також 
варто виділити такі основні продукти як SAP for Retaіl, Oracle Retaіl, LS Retaіl 
14 
 
ЧДТУ.2281.005 ПЗ  
NAV (на базі Mіcrosoft Dynamіcs NAV) і 1С Роздріб на базі 1С Підприємство. 
[2].  
Отже, при застосуванні автоматизованих систем управління на 
торгівельних підприємствах відбувається підвищення керованості і гнучкості 
бізнесу, збільшення його ринкової вартості й інвестиційної привабливості, а 
також поліпшення іміджу безпосередньо менеджменту, який використовує 
найбільш прогресивні інструменти управління. Якщо говорити про зміни, що 
піддаються кількісній оцінці, то вони спостерігаються переважно в складі 
скорочення видаткових статей операційної діяльності і підвищення показників 
оборотності й ефективності [1].  
Мета дослідження: підвищення ефективності методик розробки 
програмного забезпечення інформаційної системи розрахунку оптимального 
розміру замовлення за моделлю Уілсона 
Об’єкт дослідження: процес розробки програмного забезпечення 
процесів управління роздрібною торгівлею.  
Предмет дослідження: процес проектування і конструювання 
програмного забезпечення інформаційної системи управління роздрібною 
торгівлею з розрахунком рівня запасу по методу Уілсона.  
Завдання дослідження: Дослідити предметну область. Проаналізувати 
існуючі моделі предметної області. Провести моделювання процесів 
предметної області. Дослідження процесів об’єктно-орієнтованого 
проектування програмного забезпечення інформаційної системи. Розробка 
методики проектування програмного забезпечення інформаційної системи 
Наукова новизна одержаних результатів полягає в тому, що 
удосконалено метод об’єктно-орієнтованого проектування програмних систем 
управління роздрібною торгівлею шляхом застосування математичної моделі 
Уілсона на етапі моделювання предметної області функціонування 
програмного забезпечення інформаційної системи. Це дозволяє підвищити 
оперативність інформаційного забезпечення процесів управління запасами. 
15 
 
ЧДТУ.2281.005 ПЗ  
Практичне значення одержаних результатів. Отримані результати 
дозволяють розробляти методики об’єктно-орієнтованого проектування та 
конструювання програмного забезпечення інформаційної системи управління 
запасами для різних умов роботи.  
Інструментарій. В якості мови програмування було обрано Java, у цієї  
мови є багато переваг перед іншими мовами програмування, що дозволяє 
вирішувати з її допомогою практично будь-які завдання.  
Також було обрано Spring Framework (або коротко Spring ) . Це 
універсальний фреймворк з відкритим вихідним кодом для Java- платформи. 
Також існує форк для платформи. NET Framework, названий Spring.NET.  
Для розробки БД було обрано MySQL. MySQL є рішенням для малих і 
середніх додатків. Входить до складу серверів WAMP, AppServ, LAMP і в 
портативні збірки серверів Денвер, XAMPP. Зазвичай MySQL  
використовується як сервер, до якого звертаються локальні або видалені 
клієнти, проте в дистрибутив входить бібліотека внутрішнього сервера, що 
дозволяє включати MySQL в автономні програми.  
Сформульовані результати досліджень:  
- Проаналізовані існуючі методи та засоби розв’язання 
поставлених завдань.  
- Проведено теоретичні дослідження.  
- Проведено проектування програмного забезпечення.  
- Проведено моделювання предметної області.  
Розроблено та протестовано програмне забезпечення.  
Практичне значення одержаних результатів полягає в можливості 
використання та впровадження програмного забезпечення.  
По темі магістерської випускної роботи були опубліковані тези  
Первунінський С.М., Семенчук К.М. Тези доповіді на V Міжнародної 
студентської наукової конференції «Наука сьогодення: від досліджень до 
стратегічних рішень» (02.12.2022, м. Київ, Україна) на тему «Актуальність 
16 
 
ЧДТУ.2281.005 ПЗ  
розробки системи розрахунку даних для управління оптимальної закупівлі 
товару». 
Зв'язок з науковими програмами, планами, темами: По темі 
магістерської кваліфікаційної роботи участь у наукових темах не проводилась.  
Ключові слова: інформаційна система, моделювання, програмне 
забезпечення, тестування програмного забезпечення, вимоги, модель Уілсона.  
    
  
17 
 
ЧДТУ.2281.005 ПЗ  
РОЗДІЛ 1 
ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ 
ЗАВДАНЬ 
1.1 Принципи створення інформаційних систем  
Визначення вимог до системи та аналіз є першим етапом створення ІС, на 
якому вимоги замовника уточнюються, узгоджуються, формалізуються та 
документуються. Фактично на цьому етапі дається відповідь на запитання: "Для 
чого призначена і що має робити інформаційна система?"   
Метою системного аналізу є перетворення загальних, розпливчастих 
знань про вихідну предметну область (вимог замовника) у точні визначення та 
специфікації для розробників, а також генерація функціонального опису 
системи. На цьому етапі визначаються та специфікуються:  
- зовнішні та внутрішні умови роботи системи;  
- функціональна структура системи;  
- розподіл функцій між людиною та системою, інтерфейси;  
- вимоги до технічних, інформаційних та програмних компонентів 
системи,  
- вимоги до якості та безпеки;  
- склад технічної та користувальницької документації; -  умови 
впровадження та експлуатації.  
Розробка перерахованих вище специфікацій при створенні ІС, 
призначеної для автоматизації управлінських процесів, у загальному випадку 
проходить чотири стадії.  
Перша стадія аналізу - структурний аналіз підприємства - починається з 
дослідження того, як організовано систему управління підприємством, з 
обстеження функціональної та інформаційної структури системи управління, 
визначення існуючих та можливих споживачів інформації. За результатами 
обстеження аналітик на першій стадії будує узагальнену логічну модель 
вихідної предметної галузі, що відображає її функціональну структуру, 
18 
 
ЧДТУ.2281.005 ПЗ  
особливості основної діяльності та інформаційний простір, в якому ця 
діяльність здійснюється. На цьому матеріалі аналітик будує функціональну 
модель "Як є".  
Друга стадія роботи, до якої обов'язково залучаються зацікавлені 
представники замовника, а за потреби і незалежні експерти, полягає в аналізі 
моделі "Як є", виявленні її недоліків та вузьких місць, визначення шляхів 
удосконалення системи управління на основі виділених критеріїв якості.  
Третя стадія аналізу, що містить елементи проектування, - створення 
вдосконаленої узагальненої логічної моделі, що відображає реорганізовану 
предметну область або її частину, яка підлягає автоматизації - модель "Як має 
бути"  
 Закінчується  процес  (четверта  стадія)  розробкою  "Карти  
автоматизації", що є модель реорганізованої предметної області, на якій 
обов'язково позначені "кордони автоматизації".  
У більшості випадків модель "Як є" покращується системним аналітиком 
за рахунок усунення очевидних невідповідностей та вузьких місць, а отриманий 
таким чином варіант моделі розглядається надалі як попередня модель "Як має 
бути", яка згодом доповнюється відповідно до стратегії розвитку підприємства.  
На стадії аналізу вимог до проектованої системи та вводяться:  
- класи користувачів та відповідні діаграми бізнес-транзакцій;  
- моделі (діаграми) процесів прикладної діяльності та відповідні переліки 
функціональних завдань ІВ;  
- класи об'єктів предметної області та відповідні діаграми 
"сутністьзв'язок", що відображають інформаційну модель цієї предметної 
області;  
- топологія розташування підрозділів та користувачів, що обслуговуються 
даною ІС;  
- параметри захисту даних, інформації та самої системи.  
19 
 
ЧДТУ.2281.005 ПЗ  
Основним документом, що відображає результати робіт першого етапу 
створення ІС, є технічне завдання на проект (розробку), що містить, крім 
перерахованих вище визначень і специфікацій, також відомості про черговість 
створення системи, відомості про виділені ресурси, директивні терміни 
проведення окремих етапів роботи, організаційні процедури і заходи щодо 
приймання етапів, захисту проектної інформації тощо.  
Наступний етап – проектування. У реальних умовах проектування - це 
пошук, моделювання способу розробки, який задовольняє вимоги 
функціональності системи засобами наявних технологій з урахуванням заданих 
початкових умов та обмежень. Проектування інформаційних систем завжди 
починається з визначення мети проекту. Основне завдання будь-якого 
успішного проекту полягає в тому, щоб на момент запуску системи та протягом 
усього часу її експлуатації можна було забезпечити:  
- необхідну функціональність системи та ступінь адаптації до умов її 
функціонування, що змінюються;  
- необхідну пропускну здатність системи та мінімальний час реакції 
системи на запит;  
- безвідмовну роботу системи у потрібному режимі, готовність та 
доступність системи для обробки запитів користувачів;  
- простоту експлуатації та супроводу системи; - необхідну безпеку 
даних та права доступу користувачів.  
Продуктивність та надійність є головними факторами, що визначають  
ефективність системи. Хороше проектне рішення є основою 
високопродуктивної системи.  
Проектування інформаційних систем охоплює три основні сфери:  
- проектування структур даних, які будуть реалізовані у базі даних;  
- проектування програм, екранних форм, звітів, які забезпечуватимуть 
виконання запитів до даних;  
20 
 
ЧДТУ.2281.005 ПЗ  
- проектування конкретного середовища чи технології, а саме: топології 
мережі, конфігурації апаратних засобів, використовуваної архітектури, 
паралельної обробки, розподіленої обробки даних тощо.  
На основі результатів системного аналізу на стадії попереднього проекту 
розробляються:  
- проект програмно-апаратної реалізації, проект користувальницьких 
інтерфейсів та технології роботи користувачів у системі;  
- архітектура  розподіленої  системи  та  специфікації  
телекомунікаційної мережі;  
- моделі (діаграми) потоків даних;  
- функціональні блок-схеми прикладного та системного програмного 
забезпечення (останні — відповідно до прийнятих моделей середовища ІС та 
профілів стандартів).  
Стадія попереднього проектування може передбачати прототипування 
фрагментів, важливих з точки зору користувача для перевірки відповідності 
вимогам на ранній фазі розробки.  
На стадії детального проектування розробляються:  
- комплекси функціональних програм ІВ та проект реалізації 
середовища ІВ;  
- структури даних, засоби ведення бази даних;  
- мережеві адреси, протоколи телекомунікацій та інші компоненти 
середовища обміну інформацією, що включаються до складу проектованої  
ІС;  
- правила розмежування доступу користувачів та засоби їх реалізації.  
Стадія реалізації ІС передбачає розробку та тестування компонентів та 
комплексне тестування системи.  
Стадія експлуатації та супроводу передбачає контроль функціонування 
ІС, внесення необхідних змін до інформаційної бази у процесі поточної роботи 
21 
 
ЧДТУ.2281.005 ПЗ  
та модернізацію функцій ІС силами прикладних фахівців за допомогою 
інструментальних засобів, вбудованих у систему.  
Етапи розробки, тестування, впровадження, експлуатації та супроводу  
ІВ об'єднуються терміном – реалізація. Реалізація ІС є надзвичайно складним 
багатоаспектним процесом, який здійснюється на базі сукупностей (профілів) 
гармонізованих міжнародних стандартів, специфікацій та угод. Така практика 
є запорукою того, що створювана інформаційна система буде реалізована як 
"відкрита система". Іншими словами така ІС буде масштабована, мобільна, 
переносима, мати дружні інтерфейси і т.д.  
Життєвий цикл ІС формується відповідно до принципу низхідного 
проектування і, як правило, має спірально-ітераційний характер. Реалізовані 
етапи, починаючи з ранніх, циклічно повторюються відповідно до змін вимог і 
зовнішніх умов, запровадженням додаткових обмежень тощо. , прийняті на 
попередньому етапі Життєвий цикл ІВ закінчується, коли припиняється її 
програмний та технічний супровід.  
1.2 Опис предметної області   
Роздрібна торгівля – кінцева форма реалізації товарів кінцевому 
споживачеві у невеликих обсягах через магазини, павільйони, лотки, намети та 
інші точки роздрібної торгової мережі. Комерційно-збутова робота на 
підприємствах роздрібної торгівлі, на відміну від підприємств оптової торгівлі, 
має свої особливості. Підприємства роздрібної торгівлі реалізують товари 
безпосередньо населенню, тобто фізичним особам, використовуючи свої, 
специфічні способи та методи роздрібної реалізації, і нарешті завершують 
звернення від виробника продукції.  
Торговельне обслуговування населення передбачає наявність спеціально 
влаштованих та обладнаних приміщень, пристосованих для найкращого 
обслуговування покупців, підбір та формування торговельного асортименту та 
можливість його оперативної зміни відповідно до попиту населення, що 
змінилося, постійне вивчення та облік споживчих запитів покупців, можливість 
22 
 
ЧДТУ.2281.005 ПЗ  
пропонувати та продавати товари кожній особі . Розвиток роздрібної торгівлі 
вимагає створення спеціальних служб з вивчення та прогнозування споживчого 
попиту, формування оптимального асортименту товарів, аналізу та визначення 
прогресивних форм та методів роздрібної торгівлі на рівні області, регіону, 
області та району за незмінної підтримки органів державної та муніципальної 
влади з метою контролю за розвитком роздрібної торгівлі, освоєнням нових 
видів продукції та товарів.  
  
Рис.1.1 – Основні компоненти системи управління запасами  
 
Правильна організація комерційної роботи у рамках роздрібної торгівлі 
сприяє зростанню товарообігу, досить повному задоволенню сукупного попиту 
населення та досягненню комерційного успіху.  
Серед нових методів продажу, що включають комплекс прийомів та 
способів реалізації товарів, на перший план висуваються самообслуговування, 
обслуговування через прилавок, за зразками з відкритою викладкою та за 
попередніми замовленнями.  
Торговий процес, тобто процес купівлі-продажу товарів, є функцією 
торгового підприємства, що здійснює свою діяльність на основі повного 
економічного розрахунку. Підприємства роздрібної торгівлі в умовах 
функціонування ринкової економіки є самостійною ланкою торгівлі та сфери 
послуг.  
Торговельна мережа дає можливість швидко, зручно, з мінімальними 
витратами сил та часу придбати необхідні товари та послуги в умовах вільного 
вибору та широкого асортименту, недалеко від місця роботи та житла у зручній 
та необхідній кількості.  
23 
 
ЧДТУ.2281.005 ПЗ  
До основних торгових функцій підприємства роздрібної торгівлі 
належать:  
- реклама товарів та послуг;  
- надання торгових послуг покупцям;  
- складання заявок на ввезення товарів;  
- формування асортименту товарів;  
- вивчення купівельного попиту на товари.  
До основного виду діяльності підприємства можна віднести здійснення 
роздрібної торгівлі виходячи з торгової ліцензії та інших документів.  
Процес постачання продукції роздрібну торговельну мережу полягає у 
організації та доставці товарів від виробників у роздрібну торговельну мережу 
у кількості та асортименті, відповідних попиту населення.  
Процес доставки товару можна поділити на такі основні етапи:  
- організація закупівлі товарів;  
- поширення торговими підприємствами;  
- організація доставки;  
- приймання та зберігання товарів.   
Закупівельна діяльність торгових організацій має бути системно 
організована та економічно обґрунтована. Це вимагає від торгових організацій 
систематичного вивчення джерел закупівлі та постачальників продукції. 
Систематичне вивчення торгової кон'юнктури, встановлення постійного зв'язку 
з постачальниками дозволяють своєчасно визначати зміни кон'юнктури ринку, 
вивчати виробничі можливості для розширення асортименту продукції, що 
випускається. Все це дозволяє пред'являти більш обґрунтовані вимоги до 
постачальників за кількістю, якістю, асортиментом товарів. Доставка товару в 
магазин, залежно від замовлення, має дві форми: транзитну та складську.  
Ввезення продукції саме від підприємств-виробників, минаючи проміжні 
склади оптово-роздрібних організацій, називається транзитом.  
24 
 
ЧДТУ.2281.005 ПЗ  
Під складської формою товарообігу розуміється надходження товарів у 
магазини зі складів оптово-роздрібних організацій, які, приймаючи великі 
партії товарів від постачальників, виконують всі необхідні операції 
(розпаковування, сортування, контроль якості тощо) підготувати товари для 
подальшого просування в роздрібній мережі.  
Вибір тієї чи іншої форми товарообігу вимагає врахування конкретних 
умов і залежить від специфіки асортименту товарів, місцезнаходження 
постачальника та покупця, від місткості магазину (обсягу товарообігу, розміру 
торгових та складських площ), умови транспортування та можливість тієї чи 
іншої форми доставки.  
Транзитна доставка товарів у магазині знижує витрати на навантаження 
та розвантаження, прискорює просування товарів у роздрібній мережі, 
покращує їх зберігання.  
У більшості випадків транзитне ввезення товарів здійснюється з 
промислових підприємств, розташованих в одному місті. При постачанні 
магазинів продукцією застосовуються дві форми доставки: централізована та. 
децентралізовано (самовивіз).  
Централізовано – доставка товарів постачальниками. Централізована 
доставка використовується при транзитно-складській формі руху товарів.  
Надходження товарів від постачальників здійснюється на підставі 
господарських договорів, укладених між постачальниками та покупцями. У 
договорах, що укладаються між постачальниками та покупцями, визначаються: 
види товарів, комерційні умови постачання, кількісні та вартісні показники 
товарів, строки виконання договорів, порядок розрахунків, а також 
відповідальність сторін за неналежне виконання договорів. договір.  
25 
 
ЧДТУ.2281.005 ПЗ  
 
Рис.1.2 – Класифікація систем контролю стану запасів  
 
У процесі руху товару від виробника до споживача кінцевою ланкою є 
роздрібна торгівля. У роздрібній торгівлі матеріальні ресурси переходять у 
власність споживача. До роздрібної торгівлі належить реалізація товарів 
населенню для особистого споживання, організаціям, підприємствам, 
установам колективного споживання чи побутових потреб. Товари 
реалізуються в основному через роздрібних торговців та підприємства 
громадського харчування. Реалізація товарів народного споживання 
здійснюється із складів підприємств-виробників, посередницьких  
організацій, фірмових магазинів, заготівельних пунктів тощо.  
Роздрібні функції:  
- досліджує ситуацію, що склалася на товарному ринку;  
- визначає попит та пропозицію на окремі види товарів;  
- здійснює пошук товарів, необхідних для роздрібної торгівлі;  
- здійснює підбір товарів, їх сортування при складанні необхідного 
асортименту;  
- здійснює операції з приймання, зберігання, маркування товарів, 
встановлює на них ціни;  
- надає постачальникам, споживачам транспортно-експедиторські, 
консультаційні, рекламні, інформаційні та інші послуги.  
26 
 
ЧДТУ.2281.005 ПЗ  
Найбільшого розвитку у роздрібній торгівлі отримали передусім 
підприємства легкої та текстильної промисловості. У торгових підрозділах 
органів державної влади відбувається певне накопичення основних даних щодо 
реалізації товарів та товарно-матеріальних цінностей за асортиментною та 
внутрішньогруповою структурою, а також даних про обсяг незадоволеного 
попиту. Найбільш точні дані про внутрішньогрупову структуру асортименту 
товарів можна отримати тільки в основному ланці системи роздрібної торгівлі, 
але така робота вимагає організації та ведення чіткого обліку обсягів продажів 
за асортиментними групами з одночасною реєстрацією незадоволеного попиту 
та вимог окремих клієнтів. У передових країнах світу для вирішення цієї 
проблеми використовуються єдині універсальні штрихкоди для кожного 
товару, що є його індикатором, та спеціальні етикетки для харчових продуктів, 
пристосовані для автоматичного зчитування за допомогою касових терміналів. 
Інформація про продаж товарів передається телефонними, телетайпними, 
телефаксними каналами зв'язку до обчислювального центру торгової компанії. 
Метою активного стимулювання збуту товарів реклама. Рекламна компанія 
повинна формуватися за різними напрямками, починаючи від найпростіших її 
ідей – оформлення вітрин та вітрин – до організації рекламних виставок товарів 
з використанням друкованої, транспортної, радіо- та теле-, відеореклами та 
інших видів реклами.  
Різні форми та методи роздрібної торгівлі не можуть бути ефективними 
без якісного надання комплексу додаткових послуг, серед яких виділяють три 
види:  
- пов'язані із придбанням товарів, тобто. отримання замовлень, грамотні 
консультації, упаковка товарів та їх доставка додому;  
- послуги,  що  надаються  покупцям  після  придбання  товару:  
встановлення та налагодження складних видів електронної техніки 
(комп'ютери, телефони, музичні центри);  
27 
 
ЧДТУ.2281.005 ПЗ  
- послуги, пов'язані з ефективним продажем товарів: сприятлива та 
комфортна атмосфера з високою культурою обслуговування; організація 
буфетів, кафе «бістро», кімнат відпочинку та дитячих кімнат, схованок, 
автостоянок, ремонтних майстерень тощо [5].  
Впровадження системи автоматизації у торгових підприємствах, як і 
будь-яке серйозне перетворення для підприємства, процес складний і 
найчастіше болючий. Тим не менш, деякі проблеми, що виникають при 
впровадженні системи, досить добре вивчені, формалізовані та мають 
ефективні методики вирішення. Завчасне вивчення цих проблем та підготовка 
до них значно полегшують процес впровадження та підвищують ефективність 
подальшого використання системи.  
Метою автоматизації торгівлі є підвищення ефективності управління 
підприємством, і як наслідок збільшення обсягу продажу та збільшення 
прибутковості. Цей ефект досягається, з одного боку, за рахунок оперативного 
обліку та постійного контролю за рухом товарів, а з іншого – за рахунок 
впровадження CRM-технологій, що дозволяють залучати покупців та значно 
підвищувати конкурентоспроможність підприємства.  
Нижче наведено основні проблеми та завдання, які у більшості випадків 
виникають при впровадженні систем автоматизації та рекомендації щодо їх 
вирішення.  
Основні проблеми та завдання, що вимагають особливої уваги при їх 
вирішенні:  
1. Відсутність постановки управлінського завдання для підприємства.  
2.Необхідність часткової чи повної реорганізації структури підприємства.  
3. Необхідність зміни бізнес-технологій у різних аспектах.  
Отже, під автоматизацією торгівлі розуміється комплекс заходів, 
вкладених у впровадження сучасних інформаційних технологій на 
підприємствах торгівлі. Такими заходами є:  
28 
 
ЧДТУ.2281.005 ПЗ  
-  оснащення торгового підприємства необхідними технічними засобами 
(комп'ютери, мережеве обладнання, електронне торговельне обладнання, у 
тому числі сканери штрих-кодів, фіскальні реєстратори, принтери чеків та 
етикеток, термінали збору даних та ін.);  
 Отже, автоматизована система обробки інформації допомагає людині 
здійснювати своєї діяльності, надаючи набір функцій, реалізованих кінцевими 
автоматами. Набір кінцевих автоматів можна зібрати в автоматизовану 
систему, яка налаштовується людиною виконання певної послідовності дій 
задля досягнення бажаного результату [6].  
Існуючі системи контролю рівня запасів варіюють від найбільш простих 
до достатньо складних в залежності від розміру підприємства, політики і 
технології менеджменту, обсягу, видів і інших особливостей запасів.  
1.3 Аналіз програмних аналогів  
1.3.1 Можливості ABM Inventory  
Автоматизація процесів керування товарними запасами в системі ABM 
Inventory надає гнучкий аналітичний інструментарій. Понад 40 звітів 
дозволяють відстежувати динаміку продажів, out-of-stock, запасів та їхніх  
надлишків  по  всій  компанії,  у  кожному  складі,  магазині  та  
постачальника.[34]  
Автоматичне поповнення запасів та автозамовлення постачальникам  
Щодня по кожному SKU автоматично аналізуються фактичні продажі, 
оцінюються наявні надлишки та нестача на кожній точці зберігання, 
враховуються специфічні умови постачання. На підставі цих даних 
визначається буфер для кожного товару, та система ABM Inventory формує 
автозамовлення на постачальників.  
Управління акціями та сезонами  
Автоматичний розрахунок необхідної кількості товару для проведення 
акції, підготовка та вихід з акції. Система дозволяє враховувати сезонні 
29 
 
ЧДТУ.2281.005 ПЗ  
коливання попиту, вихідні дні, коли постачальники не працюють, та відхилення 
у замовленнях.  
 Оперативний контроль  
Система сигналізує про нестачу ключових товарів, що генерують 
основний оборот (до 80%). Менеджер бере показник у роботу, щоб не 
допустити втрачених продажів. Звіт про точність виконання замовлень 
постачальниками містить інформацію про кількість замовлених товарів і 
поставок, здійснених контрагентом.  
 Аналіз та управління асортиментом  
Звіти в системі надають фінансові показники, які дозволяють легко 
виявити і порівняти швидко-оборотні SKU з повільно-оборотними, а також 
нерухомими SKU. Товари ранжуються за прибутковістю й оборотністю. Є 
зручний механізм виведення товарів із асортименту.  
 Оцінка надійності постачальників  
Автоматизація систем управління запасами надає інформацію про оборот 
постачальника, його топові позиції, втрачені продажі, надлишки, резерви і 
оборотність товарів, динаміку показників і результуючий показник надійності 
постачальника.  
 Комплексна аналітика  
Динаміка запасів компанії. Щотижня система автоматично розраховує 
ефективність управління запасами в цілому та в кожній точці зберігання. Як 
змінюється ситуація та що впливає на ці зміни.  
Аналіз втрачених продаж. Аналіз нестачі товару у кожній точці 
зберігання та його впливу на фінансові результати компанії.  
Динаміка надлишкових запасів. Докладний звіт про надлишки.  
Звіти відображають тенденції за останні 6 та 52 тижні, а також докладні звіти із 
зазначенням позицій, які створили найбільші втрачені продажі та надлишки на 
останньому тижні.  
30 
 
ЧДТУ.2281.005 ПЗ  
 
Рис.1.3 – Динаміка втрачених продажів за минулий та попередній тиждень 
 
1.3.2 Система Chameleon Cloud  
Розглянемо систему обліку Chameleon Cloud, щоб управляти товарними 
запасами.  
Щоб грамотно спланувати кількість закуповуваних товарів (з 
урахуванням запасу, звичайно), не обійтися без аналізу продажів за попередній 
період. Менеджер повинен розуміти: які позиції і як швидко продаються. Ці дані 
можна отримати зі звітів «Динаміка продажів» і «Звіт з продажу». Перший 
покаже загальні результати за обраний період (день, місяць, рік і т.д.). Другий - 
більш детальну інформацію в розрізі постачальників, товарних груп, окремих 
продуктів та іншого.  
 
Рис.1.4 - Звіт «Динаміка продажів» в інтерфейсі Chameleon Cloud 
31 
 
ЧДТУ.2281.005 ПЗ  
 
Рис.1.5. - «Звіт з продажу» в інтерфейсі Chameleon Cloud 
 
Постійне відстеження попиту, сезонних вподобань покупців теж значно 
спрощують прогнозування закупівель і запасів. Непопулярні позиції можуть 
вилитися у великий відсоток залишків і недоотримання прибутку. Тому дуже 
важливо дивитися на попередній досвід продажів в магазині і переваги 
покупців.  
В системі обліку Chameleon Cloud для цього є звіт «Топ товарів». Він 
показує, які продукти найчастіше купують. Про те, як управляти асортиментом, 
ми детально розповідали в одному з наших недавніх матеріалів.  
Звіти по залишках - ключовий інструмент менеджера в управлінні 
товарними запасами. В системі обліку Chameleon Cloud передбачено кілька 
можливостей відслідковувати надлишки. Один з них - звіт «Залишки». Його 
можна сформувати в розрізі різних параметрів, в залежності від завдань 
користувача: торгових точок, постачальників, груп товарів, рівнів цін і серіям і 
т.д. Періодично відстежуючи дані цього звіту, можна тримати залишки під 
контролем. Вчасно формувати замовлення, якщо залишки мінімальні. Або 
планувати маркетингові заходи, якщо вони в надлишку.  
У роздрібі дуже важливий мінімальний обсяг товарного запасу. Його 
називають незнижуваним залишком. Менеджмент самостійно встановлює цей 
показник на торговій точці, виходячи з попиту, сезонності, результатів 
32 
 
ЧДТУ.2281.005 ПЗ  
продажів і інших чинників. Якщо запас товарів наближається до встановленої 
межі, необхідно оперативно формувати закупівлю.  
У софті для цього є звіт «Аналіз критичних залишків». У ньому 
відображається товари, залишки, які на критичному рівні або взагалі відсутні.  
Після чого менеджер зможе швидко провести правильні замовлення товарів.  
Або ж цей звіт можна використовувати, щоб контролювати запаси 
ходових позицій. Відстежуючи залишки по конкретній групі товарів, можна 
вчасно робити їх закупівлі.  
Вже згадували, що інвентаризація важлива для управління товарними 
запасами і контролю залишків. Вона допомагає виявляти надлишки, 
невраховані товари, недостачі і коригувати запаси з урахуванням отриманої 
інформації.  
Якщо магазин використовує товарооблікову програму, інвентаризація 
проходить без зупинки торгового процесу. Продавці можуть обслуговувати 
покупців, а менеджмент в цей час за кілька годин проведе інвентаризацію.  
У софті для цієї функції є документ «Інвентаризація». Він показує 
інформацію про стан товарних запасів на торговій точці на момент проведення 
звірки. Зробити це можна по всьому асортименті або вибірково по товарних 
групах, по одній або декількох позиціях.  
  
33 
 
ЧДТУ.2281.005 ПЗ  
Висновки до першого розділу 
Впровадження інформаційної системи автоматизації на підприємствах 
торгівлі, як і будь-яке серйозне перетворення на підприємстві, є складним 
процесом. Тим не менш, деякі проблеми, що виникають при впровадженні 
системи, досить добре вивчені, формалізовані і мають ефективні методології 
рішення. Завчасне вивчення цих проблем і підготовка до них значно 
полегшують процес впровадження і підвищують ефективність подальшого 
використання системи.  
Метою автоматизації торгівлі є підвищення ефективності управління 
підприємством, і як наслідок збільшення обсягу продажів і зростання 
прибутковості. Такий ефект досягається з одного боку за рахунок оперативного 
обліку та безперервного контролю за рухом ТМЦ, а з іншого - за рахунок 
впровадження CRM-технологій, що дозволяють залучити покупця і суттєво 
підвищити конкурентоспроможність підприємства.  
Управління запасами пов’язане з проблемою досягнення оптимальної 
рівноваги між двома конкуруючими чинниками: мінімізацією  
капіталовкладень у запаси та максимізацією рівня надійності обслуговування 
споживачів продукцією даного підприємства.  
Проаналізувавши інформаційні системи для управління товарними 
запасами, можемо зробити висновок, що всі вони професійні, постійно 
розвиваються, доповнюються, але з точки зору малого бізнесу мають певні 
недоліки: є доволі дорогими, і багато підприємців, які працюють за спрощеною 
системою оподаткування і не мають великих складів, не можуть собі їх 
дозволити з фінансової точки зору; самі системи є дуже складними. Тому для 
умов малих підприємств є доцільним розробка більш простої інформаційної 
системи, яка б дозволяла швидко аналізувати обсяги продажів, і розраховувати 
планові показники управління запасами (обсяги поставок окремих груп товарів, 
а також їх періодичність).  
     
34 
 
ЧДТУ.2281.005 ПЗ  
 
РОЗДІЛ 2 
ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ  
2.1. Теоретичні дослідження  
Проаналізувавши різні джерела та ознайомившись з різними методами 
обліку запасів було прийнято рішення в процесі створення 
економікоматематичної моделі використовувати принцип АВС-аналізу. Цей 
метод є простим та, водночас, досить потужним інструментом аналізу, котрий 
дозволить виявити об’єкти, що потребують першочергової уваги. Це досить 
актуально при дефіциті управлінських ресурсів. Запропонована в роботі 
інформаційна система управління запасами складається з трьох 
функціональних блоків: в першому блоці проходить збір інформації. 
Інформаційна система оптимізації складських запасів в якості вхідних даних 
буде використовувати звітність продажів компанії; другий блок виконує 
обробку вхідних даних; третій інформаційної системи призначений для 
вдосконалення існуючого алгоритму та формування ефективної стратегії 
управління товарними запасами. Схема інформаційних потоків системи 
наведена на рис.2.1.  
 
Рис.2.1 - Схема функціонування інформаційної системи управління 
торговими запасами 
35 
 
ЧДТУ.2281.005 ПЗ  
Метою ж створення запасів на підприємстві є: 1) утворення певного 
буфера між послідовними поставками матеріалів, сировини, що комплектують 
і усунення необхідності безперервних поставок; 2) зниження загальних 
щорічних витрат на утримання запасів до мінімуму за умови задовільного 
обслуговування споживачів. Але створення запасів завжди сполучене з 
додатковими фінансовими витратами. Витрати, пов’язані зі створенням і 
утриманням запасів можна розбити на кілька груп: - відволікання частини 
фінансових коштів на підтримку запасів; - витрати на утримання спеціально 
обладнаних приміщень (складів); - оплата праці спеціального персоналу; - 
додаткові податки; - постійний ризик псування, нереалізації товару, 
розкрадання. У свою чергу відсутність необхідного обсягу запасів приводить 
також до витрат, які можна визначити в наступній формі втрат: - втрати від 
простою виробництва, - втрата від упущеного прибутку через відсутність 
товару на складі в момент виникнення підвищеного попиту, - втрати від 
закупівлі дрібних партій товарів по більш високих цінах; - втрата потенційних 
покупців і ін. Досягнення оптимальної домірності масштабів виробництва й 
запасів є однієї з головних завдань в управлінні запасами. Прийнято вважати, 
що ефективність управління запасами характеризують показники оборотності. 
До них відносяться: 1. Коефіцієнт оборотності (число оборотів). Обчислюється 
шляхом розподілу обсягу обороту (реалізації, продажів, відвантаження) на 
середню величину запасу за звітний період. 2. Час одного обороту запасу 
характеризує тривалість одного обороту запасу в днях і показує, скільки днів у 
середньому перебував у запасі даний вид матеріального ресурсу від моменту 
його надходження на склад до моменту реалізації.  
3. Запасоємність – показник, що відбиває відношення величини запасів до 
обсягу реалізації (продажів) за період. У логістичній системі мікрорівня його 
динаміка характеризує зміна ефективності відповідних бізнес-процесів. Однак 
на практиці, часто переоцінюють значення цих показників.  
36 
 
ЧДТУ.2281.005 ПЗ  
Розглянемо два приклади. На рис. 3. графічно зображена залежність між 
числом оборотів запасів і витратами на їх утримання.  
  
Рис.2.2  - Залежність між кількістю оборотів запасів і витратами на їх 
утримання  
 
Після восьми оборотів крива стає усе більш плоскою, тому підвищення 
числа оборотів до 10 і більш не принесе особливого ефекту. У цьому випадку 
потрібні підходи інноваційного характеру [4].  
  
Рис.2.3  - Залежність між інвестиціями в запаси та рівнем обслуговування 
споживачів  
 
На рис. 2.3 продемонстрована крива залежності між інвестиціями в запаси 
й рівнем обслуговування споживачів.[35]   
Ідея використання базової моделі EOQ (Economic Ordering Quantity), 
тобто, моделі оптимального рівня запасів, полягає в визначенні такого рівня 
37 
 
ЧДТУ.2281.005 ПЗ  
запасів, підтримання якого мінімізує сукупні витрати на управління ними. При 
цьому, сукупні витрати розбиваються на три однорідні групи: витрати 
зберігання, витрати, пов'язані з формуванням запасів і витрати, що виникають 
внаслідок недоліку товарних запасів. В таблиці 3 більш детально подана ця 
класифікація, а також вплив, який здійснює збільшення рівня запасів на 
поведінку витрат кожної групи.  
Зростання рівня запасів супроводжується збільшенням витрат зберігання 
в прямопропорційній залежності (пряма А на рис.1.4), бо росте обсяг капіталу, 
імобілізованого в запаси, складські витрати, витрати, пов'язані з старінням і 
псуванням товарів.  
  
  
  
Рис.2.4. -  Залежність рівня витрат від обсягу товарних запасів.  
 
На другу і третю групу витрат збільшення рівня запасів справляє 
протилежну дію і веде до їхнього зниження за рахунок ефекту економії від 
масштабу діяльності, використання оптових знижок постачальників, 
відвертання дефіциту товарних запасів і зниження рівня обслуговування 
клієнтів при коливаннях попиту. При цьому, темпи зниження витрат 
38 
 
ЧДТУ.2281.005 ПЗ  
зменшуються з зростанням рівня запасів. Закон зменшення витрат управління 
запасами, які відносяться до другої і третьої групи, описується кривої 
гіперболічного вигляду (крива В на рис. 2.4).[36]  
Динаміка сукупних витрат, що є сумою витрат перерахованих груп, 
визначається двома протилежними тенденціями при збільшенні рівня запасів: 
одна складова цих витрат росте, інша – зменшується. Ефектом двох зустрічних 
процесів є характер поведінки сукупних витрат, що описується кривою С на 
рис.1.4. Їхня поведінка характеризується наявністю оптимальної крапки Q*, 
тобто, таким розміром запасів, при якому сукупні витрати досягають 
мінімального рівня. Якщо рівень запасів менш Q*, те збільшення їхнього обсягу 
веде до зниження сукупних витрат. Це досягається за рахунок того, що витрати 
зберігання ростуть повільніше, ніж зменшуються витрати другої і третьої 
групи. В крапці оптимального рівня запасів Q*, в якій лінії А и В 
перетинаються, темпи зміни витрат різноманітних груп врівноважуються, і 
сукупні витрати стають мінімальними. При подальшому збільшенні запасів, 
темпи зростання витрат зберігання перевищують темпи зниження витрат другої 
і третьої групи, і сукупні витрати зростають.  
2.2 Експериментальні дослідження  
Для вирішення проблем, пов'язаних із запасами призначені моделі 
управління запасами. Математичні моделі управління запасами (УЗ) 
дозволяють знайти оптимальний рівень запасів деякого товару, який дозволяє 
мінімізувати сумарні витрати на закупку, оформлення й доставку замовлення, 
зберігання товару, а також збитки від його дефіциту. Моделі повинні 
відповідати на два основні питання: скільки замовляти продукції та коли 
замовляти [23].  
Відповідь на перше запитання виражається через розмір замовлення, що 
визначає оптимальну кількість ресурсів, яку необхідно постачати кожного разу, 
коли відбувається розміщення замовлення. Залежно від ситуації, розмір 
замовлення може змінюватися в часі.  
39 
 
ЧДТУ.2281.005 ПЗ  
Відповідь на друге питання залежить від типу системи управління 
запасами. Якщо система передбачає періодичний контроль стану запасу через 
рівні проміжки часу (наприклад, щотижня або щомісяця), момент надходження 
нового замовлення зазвичай збігається з початком кожного інтервалу часу. 
Якщо ж у системі передбачений безперервний контроль стану запасів, точка 
замовлення зазвичай визначається рівнем запасів, при якому необхідно 
розміщувати нове замовлення.  
Існує безліч різноманітних моделей, кожна з яких підходить до певного 
випадку. Всі моделі управління запасами можна розділити на групи:   
- детерміновані моделі управління запасами;  
– моделі оперативного управління запасами при випадковому попиті;  
– моделі управління запасами в системі з періодичними перевірками при 
випадковому попиті;  
– моделі управління запасами протягом одного періоду; – динамічні 
моделі управління запасами.  
Модель Уілсона управління запасами  
Модель Уілсона є найпростішою моделлю УЗ й описує ситуацію закупівлі 
продукції в зовнішнього постачальника, що характеризується наступними 
припущеннями: 
– інтенсивність споживання є відомою й постійною величиною; 
– замовлення доставляється зі складу, на якому зберігається раніше 
привезений товар; 
– час доставки замовлення є величиною відомою й постійною; 
– кожне замовлення поставляється у вигляді однієї партії; 
– витрати на здійснення замовлення не залежать від розміру замовлення; 
– витрати на зберігання запасу пропорційні його розміру; 
– відсутність запасу (дефіцит) є неприпустимим. 
До вхідних параметрів моделі Уілсона відносять наступні: 
1 v – інтенсивність (швидкість) споживання запасу, [од. тов. / од. часу t]; 
40 
 
ЧДТУ.2281.005 ПЗ  
2 s – витрати на зберігання запасу, [грн. /од. тов.* од. часу t]; 
3 K – витрати на здійснення замовлення, що включають оформлення й 
доставку замовлення, [грн.]; 
4 tд – час доставки замовлення, [од. часу t]. 
До вихідних параметрів моделі Уілсона відносять: 
1 Q – розмір замовлення, [од. тов.]; 
2 L – загальні витрати на керування запасами в одиницю часу, [грн./од. 
часу t]; 
3 t – період доставки, тобто час між подачами замовлення або між 
доставками, [од. часу t]; 
4 h0 – точка замовлення, тобто розмір запасу на складі, при якому треба 
подавати замовлення на доставку чергової партії, [од. тов.]. 
Максимальна кількість продукції, що перебуває в запасі, збігається з 
розміром замовлення Q. 
Оптимальний розмір замовлення запасів у моделі Уілсона визначається за 
формулою  
 
2Kv
Q w ,                                                (2.1) 
                                             s
 
де Qw – оптимальний розмір замовлення в моделі Уілсона, 
v – інтенсивність (швидкість) споживання запасу; 
s – витрати на зберігання запасу; 
K – витрати на здійснення замовлення, що включають оформлення й 
доставку замовлення. 
Для знаходження загальних витрат використовують таку формулу: 
 
v Q
L  K  s , 
Q 2
41 
 
ЧДТУ.2281.005 ПЗ  
 
де L – загальні витрати на керування запасами в одиницю часу; 
Q – розмір замовлення. 
Період доставки визначають за наступною формулою: 
 
Q
  , 
v
де τ – період доставки. 
Точку замовлення визначають за формулою: 
 
h0  vtä . 
Запропонована модель управління запасами підприємства дає можливість 
визначати точку замовлення продукції, що є актуальним при великій кількості 
асортименту продукції. 
Модель Уілсона без обмежень 
В якості найпростішої моделі управління запасами розглянемо модель 
оптимізації поточних товарних запасів, що дозволяють підвищити ефективність 
роботи торгового підприємства. Така модель будується в такій ситуації: деяке 
торговельне підприємство протягом фіксованого періоду часу збирається 
завести і реалізувати товар конкретного (заздалегідь відомого) обсягу і при 
цьому необхідно змоделювати роботу підприємства так, щоб сумарні витрати 
були мінімальні. При побудові цієї моделі використовуються наступні вихідні 
припущення: 
1 Плануються запаси тільки одного товару або однієї товарної групи.  
2 Рівень запасів знижується рівномірно в результаті рівномірно 
виробленої продажу.  
3 Попит в планованому періоді заздалегідь повністю визначений.  
42 
 
ЧДТУ.2281.005 ПЗ  
4 Надходження товарів здійснюється строго у відповідності до плану, 
відхилення не допускаються, штраф при незадоволенні попиту нескінченно 
великий.  
5 Витрати на управління запасами складаються тільки з витрат із 
завезення і зберігання запасів. 
Сумарні витрати будемо вважати залежними від величини однієї 
поставки q. Таким чином, задача оптимального регулювання запасів зводиться 
до знаходження оптимального розміру q0 однієї постановки. Знайшовши 
оптимальне значення керованої змінної q, можна обчислити і інші параметри 
моделі, а саме кількість поставок n0, оптимальний інтервал часу tso між двома 
послідовними поставками, мінімальні (теоретичні) сумарні витрати Q0. 
Введемо наступні позначення для заздалегідь відомих параметрів моделі:  
T – повний період часу, для якого будується модель; 
R – весь обсяг (повний попит) замовлення за час T; 
C1 – вартість зберігання однієї одиниці товару в одиниці часу;  
Cs – витрати із завезення однієї партії товару. 
Позначимо через Q невідому поки сумарну вартість створення запасів 
тобто цільову функцію. Завдання моделювання полягає в побудові цільової 
функції Q=Q(q). Сумарні витрати, складатимуться з витрат із завезення і 
зберігання товару. 
Витрати на зберігання товару Q1 визначаються за наступною формулою: 
Q1 = С1 * Т q/2, 
де С1 – вартість зберігання однієї одиниці товару; 
Т – повний період часу, для якого будується модель; 
q/2 – рівень запасів. 
Враховуючи при цьому, що рівень запасів знижується рівномірно в 
результаті рівномірного продажу, тобто якщо в початковий момент створення 
запасу він дорівнює q, то в кінці періоду часу ts він дорівнює 0 і тоді «середній» 
запас рівний: 
43 
 
ЧДТУ.2281.005 ПЗ  
q  0 q
 . 
2 2
Повні витрати із завезення товару Q2 визначають за такою формулою: 
R
Q2  Cs * , 
q
де С s – вартість завезення однієї партії товару, 
R
q  – кількість поставок. 
Вартість завезення однієї партії товару на кількість поставок n, які 
R
очевидно рівні q . 
Тоді сумарні витрати управління поточними запасами можна знайти за 
формулою (2.2): 
C1Tq Cs RQ   .(2.2) 
                                    2 q                                                
Із загального вигляду формули (3.2), бачимо, що цільова функція Q є 
нелінійною функцією величини q, що змінюється в межах від 0 до R: 
0 < q  R. 
Формалізоване завдання строго математично записується у вигляді: 
 
CTq CsRQ  1   min,q 0;R.
2 q
 Щоб переконатися, що в точці q = q0 функція Q(q) дійсно досягає 
свого мінімуму, обчислимо другу похідну: 
 
2C
Q(q)  sR иQ(q )  0.
0
q3
44 
 
ЧДТУ.2281.005 ПЗ  
Отже, оптимальний розмір однієї поставки визначається за формулою 
(2.3): 
2C
q s R
0  .                                          (2.3) 
                                                TC
Використовуючи формулу (1.2) можемо визначити оптимальний середній 
поточний запас, який обчислюється за наст3пною формулою: 
q0 C
 s R
, 
2 2C1T
а оптимальне число поставок визначається за формулою (1.3): 
 
R RC
n0   1
,                                              (2.4) 
q 2C
                                         s
при цьому оптимальний інтервал між двома послідовними поставками tso 
визначається за формулою (1.4): 
T 2C T
t s
s0   .                                             (2.5) 
n RC
                                     0 1
Оптимальні (теоретичні) витрати Q0 обчислюються за за формулою (1.5): 
 
C Tq C R
Q 1 s
0    2RTC1Cs .(2.6) 
                              2 q                            
 
  
45 
 
ЧДТУ.2281.005 ПЗ  
Висновки до другого розділу 
Для вирішення проблем, пов'язаних із запасами призначені моделі 
управління запасами. Математичні моделі управління запасами дозволяють 
знайти оптимальний рівень запасів деякого товару, який дозволяє мінімізувати 
сумарні витрати на закупку, оформлення й доставку замовлення, зберігання 
товару, а також збитки від його дефіциту. Моделі повинні відповідати на два 
основні питання: скільки замовляти продукції та коли замовляти [23].  
Відповідь на перше запитання виражається через розмір замовлення, що 
визначає оптимальну кількість ресурсів, яку необхідно постачати кожного разу, 
коли відбувається розміщення замовлення. Залежно від ситуації, розмір 
замовлення може змінюватися в часі.  
Відповідь на друге питання залежить від типу системи управління 
запасами. Якщо система передбачає періодичний контроль стану запасу через 
рівні проміжки часу (наприклад, щотижня або щомісяця), момент надходження 
нового замовлення зазвичай збігається з початком кожного інтервалу часу. 
Якщо ж у системі передбачений безперервний контроль стану запасів, точка 
замовлення зазвичай визначається рівнем запасів, при якому необхідно 
розміщувати нове замовлення.  
Існує безліч різноманітних моделей, кожна з яких підходить до певного 
випадку. Всі моделі управління запасами можна розділити на групи:   
– моделі оперативного управління запасами при випадковому 
попиті;  
– моделі управління запасами в системі з періодичними 
перевірками при випадковому попиті;  
– моделі управління запасами протягом одного періоду;  
– динамічні моделі управління запасами [24].  
  
    
  
46 
 
ЧДТУ.2281.005 ПЗ  
РОЗДІЛ 3  
ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ  
3.1 Моделювання предметної області  
3.1.1 Предметна область моделювання 
Програмна модель - це формалізоване опис програмної системи на 
певному рівні абстракції. Кожна модель визначає певний аспект системи, 
використовує набір діаграм та документів у заданому форматі, відображає 
точку зору та є предметом діяльності різних людей з певними інтересами, 
ролями чи завданнями. Графічні (візуальні) моделі є засобами візуалізації, 
опису, проектування та документування архітектури системи. Моделі є 
основою взаємодії учасників проекту та гарантують правильність архітектури. 
У міру збільшення складності систем важливо мати добрі методи моделювання. 
Хоча на успіх проекту впливає багато чинників, дуже важливо мати суворий 
стандарт мови моделювання.  
Склад моделей, що використовуються у кожному конкретному проекті, 
та рівень їх деталізації загалом залежать від наступних факторів:  
- складність проектованої системи;  
- необхідність повноти його опису;  
- знання та навички учасників проекту; - час, зарезервований для дизайну.  
Структурний аналіз та проектування використовують різні моделі, які 
описують:  
- функціональну структуру системи;  
- послідовність дій, які необхідно виконати;  
- передачу інформації між функціональними процесами; Найбільш 
поширеними моделями перших трьох груп є:  
- функціональна модель SADT (структурований метод аналізу та 
проектування);  
47 
 
ЧДТУ.2281.005 ПЗ  
- модель IDEF3;  
- діаграми потоків даних DFD (Data Flow Diagrams).  
Метод SADT є набором правил і процедур, призначених для побудови 
функціональної моделі об'єкта в будь-якій області. Функціональна модель 
SADT показує функціональну структуру об'єкта, тобто дії, які він виконує та 
відносини між цими діями. Моделі SADT (IDEF0) зазвичай застосовуються для 
моделювання організаційних систем (бізнес-процесів). Слід зазначити, що 
метод SADT успішно працює лише при описі чітко визначених та 
стандартизованих бізнес-процесів у корпораціях, тому в США він прийнятий 
як типовий.  
Перевагами використання SADT-моделей є: повнота опису 
бізнеспроцесу, жорсткі вимоги до методу (внаслідок типової моделі), 
відповідність підходу до опису процесів стандартам ISO 9000. Оскільки бізнес-
процеси в Україні почали формуватися та розвиватися нещодавно, вони погано 
типізовані, тому розумніше орієнтуватися менш жорсткі моделі.  
Метод моделювання IDEF3 призначений для моделей процесів, де 
важливо розуміти послідовність дій та взаємозалежності між ними. В основі 
моделі IDEF3 лежить так званий процесний сценарій, у якому виділяється 
послідовність дій та підпроцесів аналізованої системи.  
Діаграми потоків даних (DFD) є ієрархією функціональних процесів, 
пов'язаних з потоками даних. Мета цього уявлення — показати, як кожен 
процес перетворює свої входи на виходи, і показати залежності між цими 
процесами. Модель системи визначається як ієрархія діаграм потоків даних, що 
описують асинхронний процес перетворення інформації від її обслуговування 
до системи до доставки результатів споживачеві. Діаграми потоків даних 
спочатку створювалися як інструмент проектування інформаційних систем 
(SADT — інструмент моделювання систем загалом) і мають більший набір 
елементів, які адекватно відображають специфіку таких систем.  
3.1.2. Модель предметної області. Словник предметної області 
48 
 
ЧДТУ.2281.005 ПЗ  
Розглянуті моделі приблизно однакові за можливостями засобів 
візуального моделювання. Основним критерієм вибору тієї чи іншої методу є 
ступінь володіння із боку консультанта чи аналітика, грамотність уявного 
висловлювання своїх думок мовою моделювання.  
Найбільш поширеним інструментом моделювання даних (предметна 
галузь) є модель Entity-Relationship Model (ERM). Ця модель є підмножиною 
об'єктної моделі предметної області.  
Концептуальною основою для об'єктно-орієнтованого аналізу та 
проектування (OOAD) програмного забезпечення є об'єктна модель. Його 
основні принципи - абстракція, інкапсуляція, модульність та ієрархія; основні 
поняття – об'єкт, клас, атрибут, операція, інтерфейс.  
Більшість сучасних методів OOAP ґрунтуються на використанні 
уніфікованої мови моделювання (UML).  
 Мова  UML  використовується  всіма  великими  компаніями- 
розробниками програмного забезпечення (Microsoft, Oracle, IBM, 
HewlettPackard, Sybase). Крім того, майже всі світові виробники CASE-
інструментів підтримують UML у своїх продуктах.   
Стандарт UML містить наступний набір діаграм:  
1) структурні моделі:  
- діаграми класів;  
- схеми компонентів;  
- схеми розгортання;  
2) поведінкові моделі:  
- діаграми варіантів використання (діаграми варіантів 
використання);  
- діаграми взаємодії (interaction charts): діаграми послідовності 
(sequence charts) та кооперативні діаграми (collaboration charts); - діаграми 
станів (діаграми станів); - діаграми діяльності.  
49 
 
ЧДТУ.2281.005 ПЗ  
UML має механізми розширення, що дозволяють розробникам адаптувати 
мову моделювання до своїх конкретних потреб без зміни його метамоделі. 
Наявність механізмів розширення принципово відрізняє UML від засобів 
моделювання, як IDEF0, IDEF1X, IDEF3, DFD і ERM. Перелічені мови є строго 
типізованими, оскільки не допускають довільної інтерпретації семантики 
елементів моделі. UML, хоч і припускає цю інтерпретацію, є мовою з вільною 
типізацією.  
3.1.3 Елементи моделювання предметної області 
Агрегація (aggregation) - спеціальна форма асоціації, що визначає 
відношення «частина-ціле» між агрегатом (цілим) та частинами  
Актор (actor) - пов'язаний набір ролей, який виконують користувачі при 
взаємодії з елементами Use Case  
Діяльність (activity) - стан, у якому проявляється деяка поведінка 
Діаграма (diagram) - графічне представлення набору елементів, зазвичай у 
вигляді зв'язкового графа, у вершинах якого знаходяться предмети, а дуги є їхні 
відносини  
Діаграма Use Case (use case diagram) - діаграма показує набір елементів 
Use Case, акторів та його відносин. Діаграма Use Case відноситься до статичного 
уявлення Use Case, що створюється для системи  
Діаграма взаємодії (interaction diagram) - діаграма, що показує взаємодію, 
що включає набір об'єктів та їх відносин, а також повідомлення, що 
пересилаються між об'єктами. Діаграми взаємодії відносяться до динамічного 
уявлення системи. Це загальний термін, що застосовується до різних видів 
діаграм, на яких зображено взаємодію об'єктів, включаючи діаграми 
співробітництва та діаграми послідовності  
Діаграма діяльності (activity diagram) - діаграма, що показує переходи від 
одного виду діяльності до іншого. Діаграми діяльності відносяться до 
динамічного уявлення системи. Діаграма діяльності є спеціальним різновидом 
50 
 
ЧДТУ.2281.005 ПЗ  
діаграми схем станів, в якій всі або більшість станів є станами дій, а всі або 
більшість переходів спрацьовують при завершенні дій у вихідних станах  
Діаграма класів (class diagram) - діаграма, що показує набір класів, 
інтерфейсів, кооперацій, і навіть їх відносини. Діаграма класів відноситься до 
статичного проектного представлення системи. Ця діаграма показує набір 
декларативних (статичних) елементів  
Діаграма об'єктів (object diagram) - діаграма, що показує набір об'єктів та 
його відносин у певний час. Діаграма об'єктів відноситься до статичного 
проектного уявлення або статичного уявлення процесів системи  
Діаграма послідовності (sequence diagram) - діаграма взаємодії, що 
виділяє тимчасову послідовність передачі повідомлень  
Діаграма розміщення (deployment diagram) - діаграма, що показує набір 
вузлів та його відносини. Діаграма розміщення відноситься до статичного 
уявлення розміщення системи  
Діаграма співпраці (collaboration diagram) - діаграма взаємодії, що виділяє 
структурну організацію об'єктів, що посилають та приймають повідомлення; 
діаграма, яка демонструє організацію взаємодії між екземплярами та їх зв'язок 
один з одним  
Діаграма схем станів (statechart diagram) - діаграма, що показує кінцевий 
автомат. Діаграми схем станів відносяться до динамічного представлення 
системи.  
3.1.4. Робоча область моделювання 
App.diagrams.net — це безкоштовний додаток для побудови діаграм, що 
дозволяє користувачам створювати схеми, моделі та діаграми та обмінюватися 
ними у веб-браузері.  
Інтернет-сервіс та відкрите ПЗ від розробника призначено для побудови 
робочих схем та діаграм у різних нотаціях. Онлайн-інструмент працює з Google 
та Dropbox. Користувачі можуть працювати над діаграмами в автономному 
51 
 
ЧДТУ.2281.005 ПЗ  
режимі та зберігати їх локально за допомогою настільної програми для macOS, 
Windows та Linux.  
Інструмент app.diagrams.net забезпечує інтуїтивно зрозумілий інтерфейс 
з функцією перетягування, шаблонами діаграм, що  
налаштовуються, і великою бібліотекою графічних елементів. 
Користувачі можуть створювати та редагувати різні діаграми, включаючи блок-
схеми, організаційні діаграми, діаграми процесів (BPMN), діаграми сутність-
зв'язок (ER), схеми уніфікованою мовою моделювання (UML), мережеві 
діаграми та багато іншого. draw.io Багата функціональність дозволяє 
користувачам відстежувати та відновлювати зміни, імпортувати та 
експортувати різні формати, а також автоматично публікувати роботи та 
ділитися ними.[37] 
3.2 Формування та аналіз вимог до програмного забезпечення 
3.2.1 Первинні і детальні вимоги 
Вимоги інженерного процесу це чотириетапний процес, який 
включає: техніко-економічне обґрунтування, збір вимог, специфікація 
вимог до програмного забезпечення, меревірка вимог до програмного 
забезпечення.Посилаючись на інформацію, аналітики докладно вивчають, 
чи можлива розробка бажаної системи та її функціональних можливостей. 
Це техніко-економічне обгрунтування спрямоване на цілі організації. 
У цьому дослідженні аналізується, чи програмний продукт може бути 
практично матеріалізований з точки зору реалізації, вкладу проекту в 
організацію, обмежень витрат і відповідно до цінностей і цілей організації. 
У ньому розглядаються технічні аспекти проекту та продукту, такі як 
зручність використання, ремонтопридатність, продуктивність та 
можливість інтеграції. 
Результатом цього етапу має стати звіт про техніко-економічне 
обґрунтування, який має містити адекватні коментарі та рекомендації для 
керівництва щодо того, чи слід здійснювати проект. 
52 
 
ЧДТУ.2281.005 ПЗ  
Якщо техніко-економічне обґрунтування позитивно ставиться до 
виконання проекту, наступний етап починається зі збору вимог 
користувача. Аналітики та інженери спілкуються з клієнтом та кінцевими 
користувачами, щоб дізнатися їхні ідеї про те, що програмне забезпечення 
має надавати та які функції вони хочуть включити до програмного 
забезпечення. 
SRS – це документ, створений системним аналітиком після збору 
вимог різних зацікавлених сторін. 
SRS визначає, як передбачуване програмне забезпечення 
взаємодіятиме з апаратним забезпеченням, зовнішніми інтерфейсами, 
швидкістю роботи, часом відгуку системи, переносимість програмного 
забезпечення різні платформи, ремонтопридатність, швидкість відновлення 
після збою, безпеку, якість, обмеження тощо. 
Вимоги, отримані від клієнта, написані природною мовою. Системний 
аналітик зобов'язаний документувати вимоги технічною мовою, щоб вони 
могли бути зрозумілі та корисні для команди розробників програмного 
забезпечення. 
Після того, як специфікації вимоги розроблені, вимоги, згадані в 
цьому документі, підтверджуються. Користувач може попросити про 
незаконне, непрактичне рішення, або експерти можуть неправильно 
інтерпретувати вимоги.  
3.2.2 Вимоги замовника і розробника  
Vінімальними вимогами для розробки програми і розгортання бази 
даних MySQL будуть 64-бітний процесор оскільки 32-бітний не зможе 
надати достатньо можливостей для розгортання масштабної бази даних. 
Щонайменше 3 гігабайти оперативної пам`яті, звісно як і у випадку з 
процесором можливо запустити базу навіть на 512 мегабайтах, але для 
розробки в сучасних IDE та для стабільної роботи та подальшого росту бази 
необхідні як мінімум 2 гб. Процесор з 2 ядрами, MySQL - це процес, 
53 
 
ЧДТУ.2281.005 ПЗ  
заснований на процесах. Це означає, що він може робити рівно один процес. 
Крім того, якщо у нас є лише один процесор, нам доведеться більше 
переключатися на контекст, щоб задовольнити потреби користувачів та бази 
даних. Також для зберігання даних нам знадобиться жорсткий диск, 
рекомендовано мати диск з об`ємом 128 гб та більше. Дисплей для 
виведення інформації та периферія для введення. 
Для користувача : особливі вимоги відстуні, для використання 
функціоналу додатку буде достатньо будь-якого сучасного комп`ютера. 
3.2.3 Функціональні і нефункціональні вимоги  
Розроблена система повинна виконувати наступні функції:  
1 Внесення даних по постачальникам.  
2 Внесення даних по комплектуючим деталям.  
3 Внесення даних по продажам товарів  
4 Розрахунок кількості проданих деталей за місяць.  
5 Внесення витрат на зберігання деталей за місяць.  
6 Внесення витрат на заказ комплектуючих товару.  
7 Внесення часу поставки товару.  
8 Розрахунок оптимального розміру заказу.  
9 Розрахунок загальних витрат на товар.  
10 Розрахунок періоду поставки товару.  
11 Розрахунок точки замовлення.  
Повинно бути візуалізовано:  
1 Список придбаного товару.  
2 Дані по продажам товару.  
3 Розмір замовлення.  
4 Загальна вартість замовлення.  
5 Період доставки.  
6 Точка замовлення.  
  Розглянемо функціональні можливості системи:  
54 
 
ЧДТУ.2281.005 ПЗ  
  Зручність використання.  
  Інтерфейс користувача повинен бути Windows-сумісним.  
Інтерфейс користувача повинен бути простим і не вимагати додаткового 
навчання для користувачів.  
Надійність  
Система повинна бути в працездатному стані 24 год в день 7 днів на 
тиждень, час простою - не більше 10%. Середній час безвідмовної роботи має 
перевищувати 300 ч.  
3.2.4. Формування вимог за допомогою діаграми прецедентів  
Ідентифікувати прецеденти і дійові особи це один з найважливіших 
моментів проектування системи. При ідентифікації виконуються наступні 
кроки:  
- чітко розмежується система і її оточення;  
- визначається, які дійові особи і як саме вони взаємодіють з 
системою, який функціонал (варіанти використання) очікується від системи;  
- визначається і описується в словнику предметної області (глосарії) 
загальні поняття, які необхідні для детального опису функціоналу системи 
(прецедентів).  
Подібний вид діяльності зазвичай виконується в такій послідовності:  
1 Визначення дійових осіб.  
2 Визначення прецедентів (варіантів використання).  
3 Складання опису кожного прецеденту.  
4 Опис моделі прецедентів в цілому (цей етап включає в себе 
створення словника предметної області).  
Спочатку вимоги оформляються у вигляді звичайного текстового 
документа, який створюється або самим користувачем, або користувачем і 
розробником разом. Далі вимоги оформляють у вигляді таблиці. У ліву колонку 
поміщають прецеденти, а в праву - дійових осіб, що беруть участь в прецеденті.  
55 
 
ЧДТУ.2281.005 ПЗ  
Для розробленої системи магістерської роботи було створено наступні 
дійові особи або актори:  
- користувач.  
- система.  
Далі виділено наступні прецеденти для системи:  
- розрахунок кількості проданих деталей за місяць;  
- розрахунок оптимального розміру заказу;  
- розрахунок загальних витрат на товар;  
- розрахунок періоду поставки товару; -  розрахунок точки 
замовлення.  
Виділено наступні прецеденти для користувача:  
- запуск системи;  
- внесення даних по постачальникам;  
- внесення даних по комплектуючим деталям;  
- внесення даних по продажам товарів;  
- внесення витрат на зберігання деталей за місяць;  
- внесення витрат на заказ комплектуючих товару;  
- внесення часу поставки товару;  
- оцінка результатів роботи системи по обробці даних;  
- контроль працездатності системи;  
- контроль результатів діяльності системи.  
Виходячи з цих даних, розроблено таблицю прецедентів і акторів. 
(Табл.3.1) Діаграма прецедентів є графом, що складається з множини акторів, 
прецедентів (варіантів використання) обмежених границею системи 
(прямокутник), асоціацій між акторами та прецедентами, відношень серед 
прецедентів, та відношень узагальнення між акторами.[1] Діаграми прецедентів 
відображають елементи моделі варіантів використання.  
  
 Таблиця 3.1 - Таблиця прецедентів і акторів системи  
56 
 
ЧДТУ.2281.005 ПЗ  
Прецедент Актор 
Розрахунок кількості проданих система 
деталей за місяць.  
Розрахунок оптимального розміру система 
заказу. 
Розрахунок загальних витрат на система 
товар.  
Розрахунок періоду поставки система 
товару.  
Розрахунок точки заказу. система 
Запуск систем користувач 
Внесення витрат на заказ користувач 
комплектуючих товару. 
Внесення часу поставки товару. користувач 
Оцінка результатів роботи системи користувач 
по обробці даних 
Контроль працездатності системи користувач 
Контроль результатів діяльності  користувач 
 
Суть даної діаграми полягає в наступному: проектована система 
представляється у вигляді безлічі сутностей чи акторів, що взаємодіють із 
системою за допомогою так званих варіантів використання. Варіант 
використання (англ. use case) використовують для описання послуг, які система 
надає актору. Іншими словами, кожен варіант використання визначає деякий 
набір дій, який виконує система при діалозі з актором. При цьому нічого не 
говориться про те, яким чином буде реалізована взаємодія акторів із системою.  
При цьому загальні властивості варіантів використання можуть бути 
представлені трьома різними способами, а саме — за допомогою відношень 
включення, розширення і узагальнення. 
Відношення асоціації — одне з фундаментальних понять у мові UML і в 
тій чи іншій мірі використовується при побудові всіх графічних моделей систем 
у формі канонічних діаграм.  
57 
 
ЧДТУ.2281.005 ПЗ  
Відношення розширення (англ. extend) визначає взаємозв'язок базового 
варіанта використання з іншим варіантом використання, функціональна 
поведінка якого задіюється базовим не завжди, а тільки при виконанні 
додаткових умов [37].  
При моделюванні системи було створено 2 актори:  користувач і система  
 
Рис. 3.1. – Графічне представлення прецедентів для актора 
«користувач» 
 
3.2.5. Проектування логічної структури програмного комплексу 
3.2.5.1 Діаграма класів 
Центральне місце у об’ектно-оорієнтованому програмуванні займає 
розробка логічної моделі системи як діаграми класів. Діаграма класів (class 
diagram) єь уявленням статичної структури моделі системи у термінології 
класів об'єктно-орієнтованого програмування. Діаграма класів може 
відображати, зокрема, різні взаємозв'язки між окремими сутностями 
предметної області, такими як об'єкти та підсистеми, а також описувати їхню 
внутрішню структуру та типи відносин.  
Діаграма класів є граф, вершинами якого є елементи типу 
«класифікатор», пов'язані різними типами структурних відносин. Діаграма 
58 
 
ЧДТУ.2281.005 ПЗ  
класів також може містити інтерфейси, пакети, відносини і навіть окремі 
екземпляри, такі як об'єкти і зв'язки.  
Клас (class) в мові UML служить для позначення безлічі об'єктів, які 
мають однакову структуру, поведінку і відносини з об'єктами інших класів. 
Графічно клас зображується як прямокутника, який додатково може бути 
розділений горизонтальними лініями на розділи чи секції. У цих розділах 
можуть вказуватися ім'я класу, атрибути (змінні) та операції (методи).  
Ім'я класу має бути унікальним у межах пакета, який описується деякою 
сукупністю діаграм класів чи однією діаграмою. Воно вказується у першій 
верхній секції прямокутника. На додаток до загального правила найменування 
елементів мови UML, ім'я класу записується по центру секції імені 
напівжирним шрифтом і має починатися з великої літери. Рекомендується як 
імена класів використовувати іменники, записані без пробілів. Імена класів 
утворюють словник предметної області.  
У першій секції позначення класу можуть бути посилання на стандартні 
шаблони або абстрактні класи, від яких утворений даний клас і від яких він 
успадковує властивості та методи. Додатково в цій секції може наводитися 
інформація про розробника даного класу та статус стану розробки, а також 
записуватися й інші загальні властивості цього класу, що стосуються інших 
класів діаграми або стандартних елементів мови UML.  
Квантор видимості може набувати одного з трьох можливих значень і 
відображається за допомогою відповідних спеціальних символів:  
"+" означає атрибут з областю видимості типу загальнодоступний 
(public). Атрибут з цією областю видимості доступний або видно з іншого класу 
пакета, в якому визначена діаграма;  
"#" позначає атрибут з областю видимості типу захищений (protected). 
Атрибут з цією областю видимості недоступний чи невидимий всім класів, крім 
підкласів даного класу;  
59 
 
ЧДТУ.2281.005 ПЗ  
"-" позначає атрибут з областю видимості типу закритий (private). 
Атрибут з цією областю видимості недоступний чи невидимий всім класів без 
винятку.  
Нижче представлена діаграма класів по темі магістерської роботи. Було 
створено 4 класи: товари, продаж, постачальник і розрахунок. Кожен клас має 
наступні атрибути:  
Клас «товар»: код продукту, його назва, кількість на складі, та код 
постачальника.  
Клас «продаж»: код продажу, код товару, кількість товару, який 
продається, дата продажу, ціна і загальна сума продажу. Сума продажу 
розраховується автоматично, як множення ціни за одиницю на кількість.  
Клас «Постачальник»: код постачальника та його юридична назва.  
Клас «Розрахунок»: номер запису, код продукту, кількість проданих 
деталей за попередній місяць,  витрати за зберігання товару за місяць 
(вводиться користувачем), витрати на доставку товару, час доставки товару, 
розмір замовлення, загальна вартість замовлення, період доставки та точка 
замовлення. Пакет (package) – це інструмент групування, що дозволяє взяти 
будь-яку конструкцію UML та об'єднати її елементи в одиниці високого рівня. 
В основному, пакети служать для об'єднання класів у групи, і саме цей спосіб 
їх застосування тут описується, але пам'ятайте, що пакети можуть 
застосовуватися для будь-якої іншої конструкції мови UML.  
  
60 
 
ЧДТУ.2281.005 ПЗ  
 
Рис. 3.2. -  Діаграма класів «Розрахунок рішення ТЗ»  
 
3.2.5.2 Діаграма пакетів  
Діаграма пакетів служить, насамперед, в організацію елементів у групи за 
ознакою з метою спрощення структури та організації роботи з моделлю 
системи.  
Класи складають структурний кістяк об'єктно-орієнтованої системи. 
Хоча вони винятково корисні, але потрібно щось більше для структурування 
великих систем, які можуть складатися із сотень класів.  
У моделі UML кожен клас може включатись лише в один пакет. Пакети 
можуть також входити до інших пакетів, тому ми залишаємося в ієрархічній 
структурі, в якій пакети верхнього рівня розпадаються на підпакети зі своїми 
власними підпакетами, і так далі, до самого низу ієрархії класів. Пакет може 
містити підпакети, і класи.  
Кожен пакет представляє простір імен (namespace), але це означає, кожен 
клас всередині власного пакета повинен мати унікальне ім'я. Якщо я хочу 
61 
 
ЧДТУ.2281.005 ПЗ  
створити пакет з ім'ям Date, а клас Date вже існує в пакеті System, то я мушу 
помістити його в окремий пакет. Щоб відрізнити один клас від іншого, я можу 
використати повністю певне ім'я (fully qualified name), тобто ім'я, яке вказує на 
структуру пакета, що володіє. На діаграмах пакети зображуються у вигляді 
папок із закладками. Можна відображати лише ім'я пакета або ім'я разом із 
вмістом. У будь-якому випадку можна використовувати або певні імена, або 
звичайні імена. Зображення вмісту за допомогою піктограм класів дозволяє 
показати всі особливості класу, аж до зображення діаграми класів усередині 
пакета. Просте перерахування імен має сенс, якщо ви хочете лише показати, які 
класи входять до тієї чи іншої пакет.  
UML дозволяє класам у пакетах бути відкритими (public) чи закритими 
(private). Відкриті класи є частиною інтерфейсу пакета і можуть бути 
використані класами з інших пакетів; закриті класи недоступні ззовні. У різних 
середовищах програмування діють різні правила щодо їх видимості 
групуючими конструкціями; необхідно дотримуватись правил свого 
програмного оточення, навіть якщо це йде врозріз із правилами UML.  
У разі корисно скоротити інтерфейс пакета, експортуючи лише невелике 
підмножина операцій, пов'язані з відкритими класами пакета. Можна зробити 
це, надавши всім класам модифікатор видимості private (закритий), щоб вони 
були доступні тільки класам даного пакета, а також створивши додаткові 
відкриті класи для зовнішнього використання. Ці додаткові класи, звані Facades 
(Фасади), делегують відкриті операції своїм сором'язливішим по пакету.  
Діаграма пакетів (package diagram) показує пакети та залежності між 
ними. За наявності пакетів для класів представлення та пакетів для класів 
предметної області пакет представлення залежить від пакета предметної 
області, якщо будь-який клас пакета представлення залежить від класу пакета 
предметної області. Таким чином, міжпакетна залежність узагальнює 
залежності між вмістом.  
62 
 
ЧДТУ.2281.005 ПЗ  
По темі магістерської роботи було розроблено діаграму, яка містить 4 
пакети: Продаж, Товари, Постачальник і Розрахунок залишку.  
 
Рис. 3.3 - Діаграма пакетів (Package diagram).  
 
3.3 Архітектурне проектування 
3.3.1 Діаграма компонентів 
Діаграма компонентів (Component diagram) показує набір компонентів та 
відносини між ними. Графічно діаграма компонентів представляються у вигляді 
графа з ребрами і вершинами. Вони показують організацію наборів компонентів 
та залежності між ними. Діаграми компонентів застосовуються для 
моделювання статичного виду системи з погляду реалізації. Сюди відноситься 
моделювання фізичних сутностей, розгорнутих у вузлі, наприклад виконуваних 
програм, бібліотек, таблиць, файлів та документів. По суті, діаграми 
компонентів - це не що інше, як діаграми класів, сфокусовані на системних 
компонентах. Діаграма компонентів має загальні властивості, властиві всім 
діаграмам, - ім'ям і графічним змістом, який відображає одну з проекцій моделі. 
Відрізняється вона від інших діаграм своїм специфічним змістом. Діаграми 
компонентів зазвичай включають: • компоненти; •інтерфейси;  •відносини 
залежності, узагальнення, асоціації та реалізації. Подібно до інших діаграм, 
діаграми компонентів можуть містити примітки та обмеження.Діаграми 
63 
 
ЧДТУ.2281.005 ПЗ  
компонентів можуть також містити пакети або підсистеми. Іноді буває корисно 
помістити в діаграму компонентів ще й екземпляри (наприклад, необхідно 
візуалізувати один екземпляр із сімейства компонентних систем). Діаграми 
компонентів використовуються для моделювання статичного виду системи з 
точки зору реалізації. Цей вид в першу чергу пов'язаний з управлінням 
конфігурацією частин системи, складеною з компонентів, які можна з'єднувати 
між собою різними способами. У більшості сучасних об'єктно-орієнтованих 
мов програмування код пишеться в інтегрованих середовищах розробки, які 
зберігають вихідні тексти у файлах. Діаграми компонентів можна 
застосовувати для моделювання управління конфігуруванням цих файлів, які є 
компонентами - робочі продукти;   
•моделювання версій, що виконуються.   
Версія - це відносно повний та узгоджений набір артефактів, що надається 
внутрішньому або зовнішньому користувачеві. Для системи, складеної з 
компонентів, версія перш за все має на увазі ті частини, які потрібно поставити 
для отримання працюючої системи. При моделюванні версій за допомогою 
діаграм компонентів ви візуалізуєте, специфікуєте та документуєте рішення, 
прийняті щодо фізичних складових системи, тобто компонентів розміщення;   
•моделювання фізичних баз даних.   
Модель фізичної бази даних представляє способи зберігання інформації 
в таблицях реляційної бази даних або сторінках об'єктноорієнтованої БД. Для 
представлення цих та інших видів фізичних баз даних ви можете скористатися 
діаграмами компонентів; •моделювання адаптивних систем. Деякі системи 
абсолютно статичні - їх компоненти з'являються, беруть участь у виконанні, а 
потім видаляються із системи. Інші системи динамічніші: вони включають 
мобільних агентів або компоненти, які мігрують з метою вирівнювання 
навантаження та відновлення після збоїв.  
По темі магістерської роботи діаграма компонентів показує залежність 
між наступними компонентами:   
64 
 
ЧДТУ.2281.005 ПЗ  
- Компанія і Замовлення.  
- Склад і Товар.  
- Замовлення, Товар і Постачальник.   
- Залишок Товару і Товар.  
- Адміністратор і Залишок товару  
 
Рис 3.4 — Діаграма компонентів (Component diagram). 
 
3.3.2 Діаграма розгортання 
Діаграми розгортання використовуються для візуалізації апаратних 
процесорів/вузлів/пристроїв системи, каналів зв'язку між ними та розміщення 
програмних файлів на цьому апаратному забезпеченні.  
Діаграма розгортання – це тип UML-діаграми, яка показує архітектуру 
виконання системи, включаючи такі вузли, як апаратні або програмні 
середовища виконання, а також проміжне програмне забезпечення, яке їх 
з'єднує.  
Діаграми розгортання зазвичай використовуються для візуалізації 
фізичного апаратного та програмного забезпечення системи.  
65 
 
ЧДТУ.2281.005 ПЗ  
Використовуючи його, можна зрозуміти, як система буде фізично розгорнута 
на апаратному забезпеченні.  
Діаграми розгортання допомагають моделювати апаратну топологію 
системи проти іншими типами UML-диаграмм, які переважно описують логічні 
компоненти системи.  
Щоб намалювати діаграму розгортання, необхідно спочатку 
ознайомитися з наступними позначеннями діаграми розгортання та елементами 
діаграми розгортання. Вузол - позначення діаграми розгортання  
Вузол, представлений у вигляді куба, є фізичною сутністю, яка виконує 
одну або кілька компонентів, підсистем або виконуваних файлів. Вузол може 
бути апаратним чи програмним елементом. Артефакти - позначення діаграм 
розгортання. Артефакти – це конкретні елементи, викликані процесом 
розробки. Прикладами артефактів є бібліотеки, архіви, файли конфігурації, 
виконувані файли і т.д. Шлях зв'язку - позначення схеми розгортання. Це 
представлено суцільною лінією між двома вузлами. Він показує шлях зв'язку 
між вузлами. Пристрій – це вузол, що використовується уявлення фізичного 
обчислювального ресурсу у системі. Приклад пристрою є сервер додатків.  
На діаграмі розгортання представлено зв'язок між складовими 
архітектури програмного забезпечення: між клієнтом та сервером.  
 
 
 
 
 
Рис. 3.5 - Діаграма розгортання 
 
 
3.3.3 Моделювання поведінки системи 
3.3.3.1 Діаграма діяльності 
66 
 
ЧДТУ.2281.005 ПЗ  
При моделюванні поведінки проектованої чи аналізованої системи 
виникає необхідність як уявити процес зміни її станів, а й деталізувати 
особливості алгоритмічної і логічної реалізації виконуваних системою 
операцій. Для моделювання процесу виконання операцій у мові UML 
використовуються звані діаграми діяльності. Графічна нотація, що 
застосовується в них, багато в чому схожа на нотацію діаграми станів, оскільки 
на діаграмах діяльності також присутні позначення станів і переходів. 
Відмінність полягає в семантиці станів, які використовуються для уявлення не 
діяльностей, а дій, та у відсутності на переходах сигнатури подій. Кожен стан 
на діаграмі діяльності відповідає виконанню деякої елементарної операції, а 
перехід у наступний стан спрацьовує лише при завершенні цієї операції в 
попередньому стані. Графічно діаграма діяльності представляється у формі 
графа діяльності, вершинами якого є стан дії, а дугами – переходи від одного 
стану дії до іншого. У контексті мови UML діяльність (activity) є деякою 
сукупністю окремих обчислень, що виконуються автоматом. При цьому окремі 
елементарні обчислення можуть призводити до деякого результату або дії. На 
діаграмі діяльності відображається логіка чи послідовність переходу від однієї 
діяльності до іншої, при цьому увага фіксується на результаті діяльності. Сам 
результат може призвести до зміни стану системи або повернення деякого 
значення. Стан дії (action state) є спеціальним випадком стану з деякою вхідною 
дією і принаймні одним переходом, що виходить зі стану. Графічно стан дії 
зображується фігурою, що нагадує прямокутник, бічні сторони якого замінені 
опуклими дугами. Усередині цієї фігури записується вираз дії (action-
expression), який має бути унікальним у межах однієї діаграми діяльності.  
Дія може бути записана природною мовою, деякою псевдокодом або 
мовою програмування. Жодних додаткових чи неявних обмежень під час 
запису дій не накладається. При побудові діаграми діяльності 
використовуються ті переходи, які переводять діяльність у наступне стан 
відразу, щойно закінчиться дію у попередньому стані. На діаграмі такий перехід 
67 
 
ЧДТУ.2281.005 ПЗ  
зображується суцільною лінією зі стрілкою. Розгалуження на діаграмі 
діяльності позначається невеликим ромбом, усередині якого немає жодного 
тексту  
Діаграми діяльності можуть бути використані не тільки для специфікації 
алгоритмів обчислень або потоків управління в програмних системах. Не менш 
важлива сфера їх застосування пов'язана з моделюванням бізнес-процесів. Для 
моделювання цих особливостей у мові UML використовується спеціальна 
конструкція, що отримала назву доріжки (swimlanes). Мається на увазі 
візуальна аналогія з доріжками в басейні, якщо дивитися на відповідну 
діаграму. При цьому всі стани на діаграмі діяльності діляться на окремі групи, 
які відокремлюються один від одного  
вертикальними лініями. Дві сусідні лінії утворюють доріжку, а група станів між 
цими лініями виконується окремим підрозділом (відділом, групою, 
відділенням, філією) компанії. У випадку дії на діаграмі діяльності 
виконуються над тими чи іншими об'єктами. Ці об'єкти або ініціюють 
виконання дій, або визначають певний результат цих дій.   
Діаграма діяльності показує алгоритм роботи програми:  
1. Внесення даних по постачальникам.  
2. Внесення даних по товару.  
3. Перевірка даних на валідність.  
4. Контроль результатів.  
5. Розрахунок точки замовлення.  
6. Виведення результатів на екран.  
68 
 
ЧДТУ.2281.005 ПЗ  
  
Рис. 3.6 - Діаграма діяльності  
 
3.3.3.2 Діаграма послідовності 
Для специфікації динаміки поведінки систем у UML використовуються 
діаграми стану і діяльності, однак, час у явному виді в них не присутній. 
Часовий аспект поводження може мати істотне значення. У UML для 
представлення тимчасових особливостей передачі і прийому повідомлень між 
об'єктами використовується діаграма послідовності.  
На діаграмі послідовності зображуються тільки ті об'єкти, що 
безпосередньо беруть участь у взаємодії і не показуються можливі статичні 
асоціації з іншими об'єктами. Діаграма послідовності має два виміри. Одне - у 
виді вертикальних ліній, кожна з яких зображує лінію життя окремого об'єкта, 
що приймає участь у взаємодії. Графічно кожен об'єкт зображується 
прямокутником і розташовується у верхній частині своєї лінії життя (рис.2.5). 
Усередині прямокутника вказується ім'я об'єкта й ім'я класу, розділені 
двокрапкою. При цьому весь запис підкреслюється, що є ознакою об'єкта, який 
являє собою екземпляр класу.  
69 
 
ЧДТУ.2281.005 ПЗ  
Другий вимір діаграми послідовності - вертикальна тимчасова вісь, 
спрямований зверху вниз. Початковому моментові часу відповідає сама верхня 
частина діаграми. При цьому взаємодії об'єктів реалізуються за допомогою 
повідомлень, що посилаються одними об'єктами іншим. Повідомлення 
зображуються у виді горизонтальних стрілок з ім'ям повідомлення і так само 
утворюють порядок за часом свого виникнення. Іншими словами, 
повідомлення, розташовані на діаграмі послідовності вище, ініціюються раніш 
тих, котрі розташовані нижче. При цьому масштаб на осі часу не вказується, 
оскільки діаграма послідовності моделює лише тимчасову упорядкованість 
взаємодій типу "раніше-пізніше".  
Лінія життя об'єкта (object lіfelіne) зображується пунктирною 
вертикальною лінією, асоційованою з єдиним об'єктом на діаграмі 
послідовності. Лінія життя служить для позначення періоду часу, у плині якого 
об'єкт існує в системі і, отже, може потенційно брати участь у всіх її взаємодіях. 
Якщо об'єкт існує в системі постійно, то і його лінії життя повинна 
продовжуватися по всій площині діаграми послідовності від самої верхньої її 
частини до самої нижньої.  
Окремі об'єкти, виконавши свою роль у системі, можуть бути знищені 
(зруйновані), щоб звільнити займані ними ресурси. Для таких об'єктів лінія 
життя переривається в момент його знищення. Для позначення моменту 
знищення об'єкта в мові UML використовується спеціальний символ у формі 
латинської букви X. Нижче цього символу пунктирна лінія не зображується, 
оскільки даного об'єкта в системі вже не існує, і цей об'єкт повинний бути 
виключений із усіх наступних взаємодій.  
У процесі функціонування об'єктно-орієнтованих систем одні об'єкти 
можуть знаходиться в активному стані, безпосередньо виконуючи визначені дії, 
або в стані пасивного чекання повідомлень від інших об'єктів. Для явного 
виділення подібної активності об'єктів, у мові UML застосовується спеціальне 
поняття, що одержало назву фокуса керування (focus of control). Фокус 
70 
 
ЧДТУ.2281.005 ПЗ  
керування зображується у формі витягнутого вузького прямокутника, верхня 
сторона якого позначає початок одержання фокуса керування об'єкта (початок 
активності), а її нижня сторона - закінчення фокуса управління (закінчення 
активності). Цей прямокутник розташовується нижче позначення відповідного 
об'єкта і може заміняти його лінію життя, якщо на всьому її протязі він є 
активним.  
З іншого боку, періоди активності об'єкта можуть чергуватися з 
періодами його пасивності або чекання. У цьому випадку у такого об'єкта 
мається кілька фокусів керування.  
В окремих випадках ініціатором взаємодії в системі може бути актор або 
зовнішній користувач. У цьому випадку актор зображується на діаграмі 
послідовності найпершим об'єктом ліворуч зі своїм фокусом керування.  
Кожна взаємодія описується сукупністю повідомлень, якими об'єкти, що 
беруть участь у ньому, обмінюються.  
У цьому змісті повідомлення являє собою закінчений фрагмент 
інформації, що відправляється одним об'єктом іншому. При цьому прийом 
повідомлення ініціює виконання визначених дій, спрямованих на рішення 
окремої задачі тим об'єктом, якому це повідомлення відправлене.  
Таким чином, повідомлення не тільки передають деяку інформацію, але і 
вимагають або припускають від приймаючого об'єкта виконання очікуваних 
дій. Повідомлення можуть ініціювати виконання операцій об'єктом 
відповідного класу, а параметри цих операцій передаються разом з 
повідомленням. На послідовності всі повідомлення упорядковані за часом свого 
виникнення в системі, що моделюється.  
У такому контексті кожне повідомлення має напрямок від об'єкта, що 
ініціює і відправляє повідомлення, до об'єкта, що його одержує. Іноді 
відправника повідомлення називають клієнтом, а одержувача - сервером.  
При цьому повідомлення від клієнта має форму запиту деякого сервісу, а 
реакція сервера на запит після одержання повідомлення може бути зв'язана з 
71 
 
ЧДТУ.2281.005 ПЗ  
виконанням визначених дій або передачі клієнтові необхідної інформації теж у 
формі повідомлення.  
В окремих випадках об'єкт може посилати повідомлення самому собі, 
ініціюючи так називані рефлексивні повідомлення.  
Користувач Система База даних
1: Внесення даних по постачальникам
2: Запис даних по постачальника в БД
3: Внесення даних по комплектуючим деталям
4: Запис даних по комплектуючим деталям в БД
5: Внесення даних по продажам товарів
6: Запис даних по продажам товарів в БД
7: Внесення витрат на зберігання деталей за місяць
8: Запис витрат на зберігання деталей за місяць в БД
9: Внесення витрат на заказ комплектуючих товару
10: Запис витрат на заказ комплектуючих товару в БД
11: Внесення часу поставки товару
12: Запис часу поставки товару в БД
13: Оцінка результатів роботи системи
14: Оцінка результатів роботи системи по обробці даних
15: Контроль працездатності системи
16: Контроль результатів діяльності системи
17: Розрахунок кількості проданих деталей за місяць
18: Розрахунок оптимального розміру заказу
19: Розрахунок загальних витрат на товар.
20: Розрахунок періоду поставки товару
21: Розрахунок точки заказу
22: Отримання результатів обробки даних
 
Рис. 3.7. -  Діаграма послідовності «Розрахунок коефіціента» 
 
Такі повідомлення зображуються прямокутником зі стрілкою, початок і 
кінець якої збігаються.  
72 
 
ЧДТУ.2281.005 ПЗ  
По темі магістерської роботи було створено діаграму послідовності: 
здійснення розрахунку точки замовлення.  
Повідомлення зображуються горизонтальними стрілками, що з'єднують 
лінії життя або фокуси керування двох об'єктів на діаграмі послідовності. При 
цьому неявно передбачається, що час передачі повідомлення досить малий в 
порівнянні з процесами виконання дій об'єктами.  
Вважається також, що за час передачі повідомлення з відповідними 
об'єктами не може відбутися ніяких подій. Іншими словами, стани об'єктів 
залишаються без зміни. Якщо ж це припущення не може бути визнано 
справедливим, то стрілка повідомлення зображується під деяким нахилом, так 
щоб кінець стрілки розташовувався нижче її початку.  
Таким чином, у мові UML кожне повідомлення асоціюється з деякою 
дією, що повинна бути виконана об'єктом. При цьому дія може мати деякі 
аргументи або параметри, у залежності від конкретних значень яких може бути 
отриманий різний результат.  
Відповідні параметри буде мати і повідомлення, яке викликало цю дію. 
Більш того, значення параметрів окремих повідомлень можуть містити умовні 
вирази, утворити розгалуження або альтернативні шляхи основного потоку 
керування.[37]  
3.3.3.3Діаграма комунікації  
Діаграма комунікації (communication diagram) - призначена для подання 
взаємодії в контексті внутрішньої архітектури системи та повідомлень, що 
передаються.  
На ній можуть бути зображені структурні відносини між елементами. 
Однак, час не відображається і необхідно вказувати порядкові номери 
повідомлень.  
Зазвичай взаємодія, моделюється діаграмою комунікації, відповідає 
реалізації деякої операції класу чи варіанта використання.  
73 
 
ЧДТУ.2281.005 ПЗ  
Можуть бути кілька екземплярів одного й того ж класу, які грають різні 
ролі. Діаграма комунікації дозволяє візуалізувати лінії життя, які відповідають, 
як правило, екземплярам класів, зв'язки, які відповідають екземплярам 
асоціацій та повідомлення. Зображуються лише лінії життя, які безпосередньо 
причетні до реалізації моделюємої взаємодії.  
Графічною нотацією для представлення діаграм комунікації є кадр у 
формі прямокутника. У контексті комунікації лінією життя називають окремого 
учасника взаємодії, яким зазвичай є екземпляр класу. Зображуються у формі 
прямокутника. З'єднувач (connector) - ставлення, що забезпечує взаємозв'язок 
чи комунікацію між двома чи більше екземплярами класифікаторів.  
Поєднує, як правило, дві лінії життя. Зображується відрізком прямої лінії. 
На кожному кінці цієї лінії додатково можуть бути явно вказані імена ролей 
відповідної асоціації.  
Специфікують окрему одиницю комунікації між двома лініями життя, 
одна з яких передає, а інша приймає від першої певну інформацію.  
Аналогічний синтаксис використовується для визначення повідомлень на 
діаграмі послідовності. Розглянемо лише відмінності. Попередні повідомлення 
- розділені комами номери повідомлень. Сенс: це повідомлення не може бути 
передане, доки не будуть надіслані всі повідомлення з цього списку.  
Вираз послідовності - розділений точками список окремих термів 
послідовностей, після якого слідує двокрапка. Кожен із терм представляє 
окремий рівень процедурної вкладеності у формі закінченої ітерації. Верхній 
рівень відповідає лівому терму послідовності. Кожен із термів послідовності 
має наступний синтаксис: [<ціле число> | <ім'я>] [<рекурентність>]. Число 
вказує на порядковий номер повідомлення в процедурній послідовності 
верхнього рівня. Ім'я у вигляді букви деякого алфавіту використовується 
специфікації паралельних потоків чи ниток управління. Рекурентність 
використовується для визначення ітеративного або умовного характеру 
виконання передачі повідомлень.  
74 
 
ЧДТУ.2281.005 ПЗ  
На діаграмі комунікації представлений зв'язок обміну інформацією між 
трьома об’єктами: користувач, система та БД.  
На рисунку  наведено приклад діаграми комунікації.  
  
Рис. 3.8 - Діаграма комунікації  
 
3.3.3.4 Діаграма скінченого автомату 
Діаграми скінчених автоматів (англ. state machine) використовуються для 
опису поведінки, що реалізується в рамках варіанта використання, або 
поведінки екземпляра сутності (класу, об'єкта, компонента, вузла або системи в 
цілому). При розробці діаграм автоматів слід дотримуватись наступних правил 
та рекомендацій. 
1. Наявність у екземпляра сутності кількох станів, що відрізняються від 
простої схеми «справний – несправний» або «активний – неактивний», є 
ознакою необхідності побудови діаграми автоматів. При виділенні станів і 
переходів слід пам'ятати, що тривалість спрацьовування переходів повинна 
бути істотно меншою, ніж знаходження об'єкта, що моделюється, у відповідних 
станах.  
2. Автомат (діаграма) обов'язково повинен починатися знаком 
початкового стану та закінчуватися знаком кінцевого. Початковий стан 
вказується лише один раз, а кінцевих може бути кілька з метою мінімізації 
перетинів переходів. Для підавтоматів рекомендується дотримуватися цього 
правила або використовувати точки входу / виходу. Допускається не вказувати 
початкових/кінцевих станів та точок входу/виходу для складових станів чи 
підавтоматів, коли початковий підстан (підстан) очевидний. 
75 
 
ЧДТУ.2281.005 ПЗ  
3. Для полегшення сприйняття діаграми рекомендується використовувати 
декомпозицію із прихованням складових станів. 
4. Діаграма не повинна містити ізольованих станів та переходів. Переходи 
та їх специфікація повинні бути задані таким чином, щоб на графі кожен стан 
був потенційно досяжний з початкового і з будь-якого стану був потенційно 
досяжний кінцевий.  
5. Тригерні переходи за умовою на діаграмі можна показати трьома 
способами. 
6. У кожний момент часу автомат або підавтомат повинен перебувати 
лише в одному стані. Це означає, що специфікація переходів з одного стану не 
повинна допускати потенційної можливості переходу у два та більше станів. На 
наступному малюнку наведено приклади фрагментів діаграм із конфліктними 
переходами. 
Винятком із цього правила є паралельний перехід у стани паралельних 
підавтоматів одного складового стану. 
По темі магістерської кваліфікаційної роботи була сформована діаграма 
скінечних автоматів, яка показую стани внесення даних в систему, зберігання і 
обробку в БД і виведення на екран. 
  
Рис. 3.9 - Діаграма скінчених автоматів 
  
76 
 
ЧДТУ.2281.005 ПЗ  
Висновки до третього розділу 
В цьому розділі були висвітлена теорія формування аналізу вимог до 
інформаційних систем. Предствлені діаграми за допомогою UML.  
Моделювання необхідно для розуміння системи. При цьому єдиної 
моделі ніколи не буває досить. Навпроти, для розуміння будь-якої 
нетривіальної системи доводиться розробляти велику кількість взаємозалежних 
моделей. У застосуванні до програмних систем це означає, що необхідна мова, 
за допомогою якої можна з різних точок зору описувати уявлення про 
архітектуру системи протягом циклу їх розробки.  
За допомогою графічної нотації UML візуалізується система, за 
допомогою специфікацій UML - описуються її деталі. Таким чином, можна 
будувати модель інкрементно, тобто покроково - спочатку намалювати 
діаграму, а потім додати семантику в специфікацію моделі, або навпаки - 
розпочати із специфікації (можливо, застосувавши зворотне проектування до 
існуючої системи), а потім на її основі створювати діаграми.  
UML придатний для моделювання будь-яких систем: від інформаційних 
систем масштабу підприємства до розподілених програм орієнтованих під Web 
і навіть вбудованих систем реального часу. Це дуже виразна мова, що дозволяє 
розглянути систему із всіх точок зору, що мають відношення до її розробки й 
наступного розгортання. Незважаючи на достаток можливостей вираження, ця 
мова проста для розуміння й використання.  
По темі магістерської роботи було створено наступні діаграми: діаграма 
розгортання, діаграма комунікації, діаграма діяльності, діаграма компонентів, 
діаграма пакетів, діаграма класів, діаграма послідовностей та діаграма 
прецедентів.   
  
    
 
 
 
77 
 
ЧДТУ.2281.005 ПЗ  
РОЗДІЛ 4 
КОНСТРУЮВАННЯ ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
4.1 Обґрунтування вибору засобів реалізації.  
JDBC (англ. Java DataBase Connectivity - з'єднання з базами даних на Java) 
- платформенно - незалежний промисловий стандарт взаємодії Java додатків з 
різними СУБД, реалізований у вигляді пакета java.sql, що входить до складу 
Java SE.  
JDBC заснований на концепції так званих драйверів, що дозволяють 
отримувати з'єднання з базою даних за спеціально описаного URL. Драйвери 
можуть завантажуватися динамічно ( під час роботи програми). 
Завантажившись, драйвер сам реєструє себе і викликається автоматично, коли 
програма вимагає URL, що містить протокол, за який драйвер відповідає.  
JDBC API містить два основних типи інтерфейсів: перший - для 
розробників додатків і другий ( більш низького рівня ) - для розробників 
драйверів.  
З'єднання з базою даних описується класом, що реалізує інтерфейс 
java.sql.Connection.  
Маючи з'єднання з базою даних, можна створювати об'єкти типу 
Statement, службовці для виконання запитів до бази даних на мові SQL.  
Існують наступні види типів Statement, що розрізняються за 
призначенням :  
- java.sql.Statement - Statement загального призначення;  
- java.sql.PreparedStatement - Statement, службовець для виконання 
запитів, що містять підставляються параметри  
(позначаються символом '?' в тілі запиту ) ;  
78 
 
ЧДТУ.2281.005 ПЗ  
- java.sql.CallableStatement - Statement, призначений для виклику 
збережених процедур.  
Інтерфейс java.sql.ResultSet дозволяє легко обробляти результати запиту.  
Перевагами JDBC вважають:   
- Легкість розробки: розробник може не знати специфіки бази даних, 
з якою працює;   
- Код не змінюється, якщо компанія переходить на іншу базу даних;   
- Не потрібно встановлювати громіздку клієнтську програму;   
- До будь-якої базі можна під'єднатися через легко описуваний URL.  
Java — об'єктно-орієнтована мова програмування, випущена компанією 
Sun Microsystems у 1995 році як основний компонент платформи Java. У 
офіційній реалізації, Java програми компілюються у байткод, який при 
виконанні інтерпретується віртуальною машиною для конкретної платформи.  
Мова значно запозичила синтаксис із C і C++. Зокрема, взято за основу 
об'єктну модель С++, проте її модифіковано. Усунуто можливість появи деяких 
конфліктних ситуацій, що могли виникнути через помилки програміста та 
полегшено сам процес розробки об'єктно-орієнтованих програм. Ряд дій, які в 
С/C++ повинні здійснювати програмісти, доручено віртуальній машині. 
Передусім, Java розроблялась як платформо-незалежна мова, тому вона має 
менше низькорівневих можливостей для роботи з апаратним забезпеченням. За 
необхідності таких дій java дозволяє викликати підпрограми, написані іншими 
мовами програмування.  
Java вплинула на розвиток J++, що розроблялась компанією Microsoft. 
Роботу над J++ було зупинено через судовий позов компанії Sun Microsystems, 
оскільки ця мова програмування була модифікацією Java. Пізніше в новій 
платформі Microsoft .NET випустило J#, щоб полегшити міграцію програмістів 
J++ або Java на нову платформу. З часом нова мова програмування С#, стала 
79 
 
ЧДТУ.2281.005 ПЗ  
основною мовою платформи, перейнявши багато чого з Java. J# востаннє 
включався в версію Microsoft Visual Studio 2005. Мова сценаріїв JavaScriptмає 
схожу із Java назву і синтаксис, але не пов'язана із Java.  
В якості мови програмування було обрано Java, у цієї мови є багато 
переваг перед іншими мовами програмування, що дозволяє вирішувати з її 
допомогою практично будь-які завдання.  
У намірах проектувальників Java мала замінити C++ — об'єктного 
наступника мови C.[7] Проектувальники почали з аналізу властивостей C++, які 
є причиною найбільшого числа помилок, щоби створити просту, безпечну і 
безвідмовну мову програмування.  
В Java існує система винятків або ситуацій, коли програма зустрічається 
з неочікуваними труднощами, наприклад:  
- операції над елементом масиву поза його межами або над порожнім 
елементом  
- читання з недоступного каталогу або неправильної адреси  
URL  
- ввід недопустимих даних користувачем  
Одна з особливостей концепції віртуальної машини полягає в тому, що 
помилки (виключення) не призводять до повного краху системи. Крім того, 
існують інструменти, які «приєднуються» до середовища періоду виконання і 
кожен раз, коли сталося певне виключення, записують інформацію з пам'яті для 
відлагодження програми. Ці інструменти автоматизованої обробки виключень 
надають основну інформацію щодо виключень в програмах на Java.  
Проте, мову програмування Java не рекомендується використовувати в 
системах, збій в роботі яких може призвести до смерті, травм чи значних 
фізичних ушкоджень (наприклад, програмне забезпечення для керування 
атомними електростанціями, польотами, систем життєзабезпечення чи систем 
80 
 
ЧДТУ.2281.005 ПЗ  
озброєння) через ненадійність програм, написаних на мові програмування 
Java.[8], пункт ліцензії Microsoft 7.7.h.  
Spring Framework (або коротко Spring ) - універсальний фреймворк з 
відкритим вихідним кодом для Java- платформи. Також існує форк для 
платформи. NET Framework, названий Spring.NET.  
Перша версія була написана Родом Джонсоном, який вперше опублікував 
її разом з виданням своєї книги « Expert One - on - One Java EE Design and 
Development » ( Wrox Press, жовтень 2002 року).  
Фреймворк був вперше випущений під ліцензією Apache 2.0 license в 
червні 2003 року. Перший стабільний реліз 1.0 був випущений в березні 2004. 
Spring 2.0 був випущений в жовтні 2006, Spring 2.5 - в листопаді 2007, Spring 
3.0 в грудні 2009, і Spring 3.1 в грудні 2011. Поточна версія - 4.0.  
Незважаючи на те, що Spring Framework не забезпечував якусь конкретну 
модель програмування, він став широко поширеним в Java співтоваристві 
головним чином як альтернатива і заміна моделі Enterprise  
JavaBeans. Spring Framework надає велику свободу Java- розробникам в 
проектуванні, крім того, він надає добре документовані і легкі у використанні 
засоби вирішення проблем, що виникають при створенні додатків 
корпоративного масштабу.  
Тим часом, особливості ядра Spring Framework застосовні в будь-якому 
Java- додатку, і існує безліч розширень і удосконалень для побудови веб 
додатків на Java Enterprise платформі. З цих причин Spring придбав велику 
популярність і визнається розробниками як стратегічно важливий фреймворк.  
Spring Framework являє собою багаторівневу архітектуру, що складається 
з семи чітко визначених модулів. Модулі Spring побудовані на базі основного 
контейнера, який визначає як створюються, конфігуруються і управляються 
JavaBeans. Дані модулі наведені на рисунку 4.1  
81 
 
ЧДТУ.2281.005 ПЗ  
 
Рис. 4.1 – Контейнери  
 
Кожен з модулів (або компонентів), які включає в себе Spring Framework 
може бути використаний самостійно або спільно з одним або декількома з 
інших компонентів. Функціональність кожного компонента полягає в 
наступному.  
Основний контейнер забезпечує необхідну функціональність Spring 
Framework. Головним компонентом контейнера є BeanFactory - реалізація 
патерну Фабрика (Factory ). BeanFactory застосовує інверсію управління для 
розділення конфігурації програми та опису залежностей і, безпосередньо, коду 
програми.  
Spring context - це файл конфігурації, який забезпечує Spring контекстної 
інформацією. Він включає в себе такі функції як JNDI ( Java Naming and 
Directory Interface ), EJB ( Enterprise JavaBeans ), e - mail, валідацію, 
інтернаціоналізацію і планування.  
Модуль Spring AOP інтегрує функціональність аспектно- орієнтованого 
програмування безпосередньо в Spring Framework за допомогою власного 
властивості управління конфігурацією. В результаті ви можете легко включити 
будь-який об'єкт, керований Spring Framework. Модуль Spring AOP надає 
82 
 
ЧДТУ.2281.005 ПЗ  
послуги управління транзакціями для об'єктів в будь-якому додатку, 
заснованому на Spring. Зі Spring AOP ви можете включити декларативне 
управління транзакціями в ваші програми, не покладаючись на компоненти 
EJB.  
Spring JDBC DAO ( Java DataBase Connectivity Data Access Object - 
з'єднання з базами даних Java на основі патерну DAO ) рівень абстракції 
предаставляет сувору ієрархію винятків для їх обробки і повідомлень про 
помилки, що з'явилися при роботі з базою даних. Ієрархія винятків спрощує 
обробку помилок і значно зменшує кількість коду, який необхідно було б 
написати (наприклад операції відкриття і закриття з'єднань).  
Spring Framework використовує додаткові модулі - фреймворки об'єктно- 
реляційного відображення ( JDO, Hibernate і IBATIS SQL Maps ) для отримання 
власного інструменту ORM. Все це відповідає базовим угодам Spring та ієрархії 
виключень DAO.  
Модуль Spring Web грунтується на модулі контексту програми, 
предоставляющем контекст для веб -додатків. В результаті Spring Framework 
підтримує інтеграцію з Jakarta Struts. Веб модуль також полегшує завдання 
обробки запитів, що складаються з декількох частин, і зв'язування параметрів 
запитів з предметною областю.  
Model - view - controller ( MVC, «Модель - вистава- поведінка », «Модель 
- подання-контролер » ) фремворк - повнофункціональна реалізація патерну 
MVC для створення веб -додатків. MVC Framework легко  
налаштовується і містить безліч технологій, включаючи JSP, Velocity, 
Tiles, iText і POI.  
Функціональність Spring Framework може бути використана на 
будьякому J2EE- сервері, більша її частина також може адаптуватися до 
некерованих середах. Основа Spring - це можливість повторного використання 
83 
 
ЧДТУ.2281.005 ПЗ  
функціональності і доступ до об'єктів даних, що не прив'язаних до конкретних 
сервісів J2EE. Такі об'єкти можуть бути повторно використані в середовищі 
J2EE (веб- або EJB ), автономних програмах, тестових середовищах, і так далі, 
без будь-яких турбот.  
Spring Security це Java / JavaEE framework, що надає механізми побудови 
систем аутентифікації та авторизації, а також інші можливості забезпечення 
безпеки для корпоративних додатків, створених за допомогою Spring 
Framework. Проект був розпочатий Беном Алексом (Ben Alex) наприкінці 2003 
року під ім'ям «Acegi Security», перший реліз вийшов у 2004 році. Згодом 
проект був поглинений Spring'ом і став його офіційним дочірнім проектом. 
Вперше публічно представлений під новим ім'ям Spring Security 2.0.0 в квітні 
2008 року.  
Ключові об'єкти контексту Spring Security :  
1 SecurityContextHolder, в ньому міститься інформація про поточний 
контексті безпеки програми, який включає в себе детальну інформацію про 
користувача ( Principal ) працюючому в даний час з додатком. За замовчуванням 
SecurityContextHolder іспользуетThreadLocal для зберігання такої інформації, 
що означає, що контекст безпеки завжди доступний для методів виконуються в 
тому ж самому потоці. Для того що б змінити стратегію зберігання цієї 
інформації можна скористатися статичним методом класу 
SecurityContextHolder.setStrategyName ( String strategy ). Більш докладно 
SecurityContextHolder  
2 SecurityContext, містить об'єкт Authentication і в разі необхідності 
інформацію системи безпеки, пов'язану із запитом від користувача.  
3 Authentication представляє користувача ( Principal ) з точки зору Spring 
Security.  
84 
 
ЧДТУ.2281.005 ПЗ  
4 GrantedAuthority відображає дозволу видані користувачеві в масштабі 
всього програми, такі дозволи (як правило називаються «ролі» ), наприклад 
ROLE_ANONYMOUS, ROLE_USER, ROLE_ADMIN.  
5 UserDetails надає необхідну інформацію для побудови об'єкта 
Authentication з DAO об'єктів програми або інших джерел даних системи 
безпеки. Об'єкт UserDetailsсодержіт ім'я користувача, пароль, прапори : 
isAccountNonExpired, isAccountNonLocked, isCredentialsNonExpired, isEnabled і 
Collection - прав ( ролей) користувача.  
6 UserDetailsService, використовується щоб створити UserDetails об'єкт 
шляхом реалізації єдиного методу цього інтерфейсу Аутентифікація:  
1 Користувачеві буде запропоновано увійти в систему надавши ім'я ( 
логін або email) і пароль. Ім'я користувача і пароль об'єднуються в екземпляр 
класу UsernamePasswordAuthenticationToken ( екземпляр інтерфейсу 
Authentication ) після чого він передається екземпляру AuthenticationManager 
для перевірки.  
2 У разі якщо пароль не відповідає імені користувача буде викинуто 
виключення BadCredentialsException з повідомленням " Bad Credentials ".  
3 Якщо аутентифікація пройшла успішно повертає повністю заповнений 
примірник Authentication.  
4 Для користувача встановлюється контекст безпеки шляхом виклику 
методу SecurityContextHolder.getContext ( ). SetAuthentication (...), куди 
передається об'єкт який повернув AuthenticationManager.  
Згідно вимог поставленої задачі висуваються наступні вимоги до 
технічних характеристик комп'ютера з мінімальною конфігурацією, на якому 
розроблена система буде успішно робити:  
1 процесор Intel Pentium 1,6 Ггц і вище;  
2 як мінімум 1 Гб оперативної пам'яті;  
3 2 Гб вільного місця на жорсткому диску;  
85 
 
ЧДТУ.2281.005 ПЗ  
4 монітор і графічна карта повинні бути оснащені матрицею IPS або E-
IPS з розподільчою здатністю 1024 768 (оптимальна розподільча здатність 
1920 на1080);  
4.2 Опис структурної (функціональної) схеми  
Розробка функціональної структури програмного забезпечення  
Після розгляду технічних вимог до програмного забезпечення можливим 
уточнення його структури, тобто. визначення структурних компонентів та 
зв'язків між ними. В результаті розробки структури буде отримано 
функціональну схему та опис компонентів.  
Структура програмного забезпечення може бути представлена у вигляді 
структурної схеми з описом компонентів.  
Структурна схема відображає склад і взаємодію з управління частин 
програмного забезпечення, що розробляється.  
Система складається з трьох взаємозалежних програмних модулів: 
модуль товарів; модуль постачальників; модуль продажу.  
Модуль продажу призначений для внесення даних по продажу товару від 
адміністратора системи. І в цей модуль входить блок розрахунку точки 
замовлення товару по модулі Уілсона  
Повна структурна схема проектованого програмного забезпечення 
представлена рисунку  
 
Рис. 4.2 – Структурна схема  
 
86 
 
ЧДТУ.2281.005 ПЗ  
4.3. Опис логічної схеми системи 
Логічна схема або схема даних - схема взаємодії компонентів 
програмного забезпечення з описом інформаційних потоків, складу даних у 
потоках та зазначенням використовуваних файлів та пристроїв.   
Логічні схеми більш інформативні, ніж структурні. Усі компоненти як 
структурних, і функціональних схем мають бути описані. При структурному 
підході особливо ретельно опрацьовуються специфікації міжпрограмних 
інтерфейсів, оскільки від якості їх опису залежить кількість найдорожчих 
помилок. До найдорожчих ставляться помилки, які виявляються при 
комплексному тестуванні, оскільки їх усунення можуть знадобитися серйозні 
зміни вже налагоджених текстів.  
Таким чином, вона також розбивається на три програмні модулі: модуль 
внесення даних; модуль розрахунку;  
Логічна схема програмного забезпечення загального виду представлена 
рисунку 4.3.  
 
Рис. 4.3 – Логічна схема  
 
87 
 
ЧДТУ.2281.005 ПЗ  
4.4 Розробка бази даних  
MySQL (МФА : - вільна реляційна система управління базами даних. 
Розробку і підтримку MySQL здійснює корпорація Oracle, що отримала права 
на торговельну марку разом з поглиненої Sun Microsystems, яка раніше 
придбала шведську компанію MySQL AB. Продукт поширюється як під GNU 
General Public License, так і під власною комерційною ліцензією. Крім цього, 
розробники створюють функціональність за замовленням ліцензійних 
користувачів. Саме завдяки такому замовленню майже в найраніших версіях 
з'явився механізм реплікації.  
MySQL є рішенням для малих і середніх додатків. Входить до складу 
серверів WAMP, AppServ, LAMP і в портативні збірки серверів Денвер, 
XAMPP. Зазвичай MySQL використовується як сервер, до якого звертаються 
локальні або видалені клієнти, проте в дистрибутив входить бібліотека 
внутрішнього сервера, що дозволяє включати MySQL в автономні програми.  
Гнучкість СУБД MySQL забезпечується підтримкою великої кількості 
типів таблиць : користувачі можуть вибрати як таблиці типу MyISAM, що 
підтримують повнотекстовий пошук, так і таблиці InnoDB, що підтримують 
транзакції на рівні окремих записів. Більш того, СУБД MySQL поставляється із 
спеціальним типом таблиць EXAMPLE, що демонструє принципи створення 
нових типів таблиць. Завдяки відкритій архітектурі і GPL - ліцензуванню, в 
СУБД MySQL постійно з'являються нові типи таблиць.  
MySQL має подвійне ліцензування. MySQL може поширюватися 
відповідно до умов ліцензії GPL. Однак за умовами GPL, якщо яка-небудь 
програма включає вихідні коди MySQL, то вона теж повинна 
розповсюджуватися по ліцензії GPL. Це може розходитися з планами 
розробників, які не бажають відкривати вихідні тексти своїх програм. Для таких 
випадків передбачена комерційна ліцензія, яка також забезпечує якісну 
сервісну підтримку.  
88 
 
ЧДТУ.2281.005 ПЗ  
БД системи складається з 4 таблиць  
Перша таблиця, це таблиця даних про продукцію, яка знаходиться 
на фірмі:  
-- Dumping structure for table selling.product  
CREATE TABLE IF NOT EXISTS `product` (  
  `id` int(10) NOT NULL AUTO_INCREMENT,  
  `name` varchar(50) NOT NULL DEFAULT '0',  
  `price` float NOT NULL DEFAULT '0',  
  `quantity` int(11) NOT NULL DEFAULT '0',  
  `supplier_id` int(11) NOT NULL DEFAULT '0',  
  PRIMARY KEY (`id`)  
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT 
CHARSET=utf8;  
  
-- Dumping data for table selling.product: ~3 rows (approximately)  
/*!40000 ALTER TABLE `product` DISABLE KEYS */;  
INSERT INTO `product` (`id`, `name`, `price`, `quantity`, `supplier_id`)  
VALUES  
  (1, 'processor', 442, 268, 1),  
  (2, 'computer', 2221, 486, 2);  
/*!40000 ALTER TABLE `product` ENABLE KEYS */;  
Ця таблиця містить наступну інформацію: код продукту, його назва, 
закуплена кількість, та код постачальника.  
Друга таблиця, це таблиця даних про продаж продукції, яка 
знаходиться на фірмі:  
-- Dumping structure for table selling.sales  
CREATE TABLE IF NOT EXISTS `sales` (  
  `id` int(10) NOT NULL AUTO_INCREMENT,  
  `product_id` int(10) NOT NULL DEFAULT '0',  
89 
 
ЧДТУ.2281.005 ПЗ  
  `quantity` int(10) NOT NULL DEFAULT '0',  
  `date` datetime NOT NULL,  
  `price` float NOT NULL DEFAULT '0',  
  `purchase_amount` float NOT NULL DEFAULT '0',  
  PRIMARY KEY (`id`)  
 )  ENGINE=InnoDB  AUTO_INCREMENT=43  DEFAULT  
CHARSET=utf8;  
  
-- Dumping data for table selling.sales: ~18 rows (approximately)  
/*!40000 ALTER TABLE `sales` DISABLE KEYS */;  
INSERT INTO `sales` (`id`, `product_id`, `quantity`, `date`, `price`, 
`purchase_amount`) VALUES  
  (30, 1, 2, '2022-11-19 17:03:58', 5, 10),  
  (31, 1, 2, '2022-11-19 17:09:52', 55, 110),  
  (32, 1, 22, '2022-11-19 17:10:38', 5.14, 113.08),  
  (33, 1, 5, '2022-11-19 17:43:13', 5, 25),  
  (34, 1, 5, '2022-11-19 17:43:58', 50, 250),  
  (36, 2, 15, '2022-11-20 19:01:21', 5, 75),  
  (37, 2, 12, '2022-11-20 19:04:29', 52, 624),  
  (38, 1, 5, '2022-11-20 19:04:53', 5, 25),  
  (39, 2, 3, '2022-11-20 19:05:14', 3, 9),  
  (40, 2, 15, '2022-11-20 19:05:36', 15, 225),  
  (41, 1, 5, '2022-11-20 19:05:58', 5, 25),  
  (42, 2, 5, '2022-11-20 19:07:05', 5, 25);  
/*!40000 ALTER TABLE `sales` ENABLE KEYS */;  
Друга таблиця містить наступну інформацію по продажам: код товару, 
кількість товару, який продається, дата продажу, ціна і загальна сума продажу. 
Сума продажу розраховується автоматично, як множення ціни за одиницю на 
кількість.  
90 
 
ЧДТУ.2281.005 ПЗ  
Третя таблиця, це таблиця даних про постачальники:  
-- Dumping structure for table selling.supplier  
CREATE TABLE IF NOT EXISTS `supplier` (  
  `id` int(10) NOT NULL AUTO_INCREMENT,  
  `name` varchar(50) NOT NULL DEFAULT '0',  
  PRIMARY KEY (`id`)  
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT 
CHARSET=utf8;  
  
-- Dumping data for table selling.supplier: ~0 rows (approximately)  
/*!40000 ALTER TABLE `supplier` DISABLE KEYS */;  
INSERT INTO `supplier` (`id`, `name`) VALUES  
  (1, 'ПП Василенко'),  
  (2, 'ПП Петренко');  
/*!40000 ALTER TABLE `supplier` ENABLE KEYS */;  
Ця таблиця містить інформацію: код поставщика та його юридична назва.  
Четверта таблиця, це таблиця даних, які розраховуються по моделі 
Уілсона:  
-- Dumping structure for table selling.wilson_model  
CREATE TABLE IF NOT EXISTS `wilson_model` (  
  `id` int(10) NOT NULL AUTO_INCREMENT,  
  `product_id` int(10) NOT NULL,  
  `sold_in_month` int(10) NOT NULL DEFAULT '0',  
  `warehousing_cost` float NOT NULL DEFAULT '0',  
  `delivery_cost` float NOT NULL DEFAULT '0',  
  `delivery_time` int(10) NOT NULL DEFAULT '0',  
  `rec_order_size` int(11) NOT NULL DEFAULT '0',  
  `general_costs` float NOT NULL DEFAULT '0',  
  `rec_delivery_period` int(11) NOT NULL DEFAULT '0',  
91 
 
ЧДТУ.2281.005 ПЗ  
  `rec_order_point` int(11) NOT NULL DEFAULT '0',  
  PRIMARY KEY (`id`)  
 )  ENGINE=InnoDB  AUTO_INCREMENT=24  DEFAULT  
CHARSET=utf8;  
  
-- Dumping data for table selling.wilson_model: ~0 rows 
(approximately)  
/*!40000 ALTER TABLE `wilson_model` DISABLE KEYS */;  
INSERT INTO `wilson_model` (`id`, `product_id`, `sold_in_month`,  
`warehousing_cost`,  `delivery_cost`,  `delivery_time`, 
 `rec_order_size`, `general_costs`, `rec_delivery_period`, `rec_order_point`) 
VALUES  
  (27, 1, 2282, 5, 112, 21, 319, 1579, 4, 1597),  
  (28, 2, 59, 123, 41.21, 44, 6, 739.89, 3, 86);  
/*!40000 ALTER TABLE `wilson_model` ENABLE KEYS */;  
/*!40014 SET FOREIGN_KEY_CHECKS=1 */;  
 /*!40101  SET  
CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;  
Ця таблиця містить наступну інформацію: номер запису, код продукта, 
кількість проданих деталей за попередній місяць,  витрати за зберігання товару 
за місяць (вводиться користувачем), витрати на доставку товару, час доставки 
товару, розмір замовлення, загальна вартість замовлення, період доставки та 
точка замовлення.  
 
 
4.5 Розробка інтерфейсу користувача 
При відкритті системи, адміністратор системи має можливість вносити 
дані по кількості товарів, які він придбав у постачальника та вводити дані по 
продажу товарів.  
92 
 
ЧДТУ.2281.005 ПЗ  
 
Рис. 4.4 – Внесення даних по товару  
 
Якщо кількість товару, який знаходиться в компанії потрібно змінити, то 
потрібно натиснути кнопку «Змінити кількість товару» і відкриється діалогове 
вікно, в якому зі списку обирається тип товару та вводиться його кількість.  
  
Рис. 4.5 – Зміна кількості товару  
 
Після вводу цих даних автоматично змінюються дані в полі по наявносто 
товару в компанії  
93 
 
ЧДТУ.2281.005 ПЗ  
  
Рис. 4.6 – Змінена кількість товару  
 
При продажу товару вводяться дані по продажі. Дані по покупцям не 
вводяться, тому що ця інформація не є необхідною для поставленої задачі в 
магістерській роботі.  
  
Рис. 4.7 – Ввод даних по продажу товару  
 
94 
 
ЧДТУ.2281.005 ПЗ  
Після вводу даних по продажу, данів полі товару в головному вікні 
адміністратора змінюються.  
 
Рис. 4.8 – Змінені дані по продажу товару 
 
Наступним кроком є розрахунок параметрів по моделі Уілсона. Для 
розрахунків цих параметрів необхідно внести ще наступні додаткові дані: 
витрати за зберігання товару за місяць (вводиться користувачем), витрати на 
доставку товару, час доставки товару. Ці дані зберігаються в базі даних та 
відносяться до конкретного товару. Дані Продано за місяць розраховуються 
автоматично з бази даних.  
95 
 
ЧДТУ.2281.005 ПЗ  
 
Рис. 4.9 – Дані для розрахунку  
Якщо необхідно їх змінити, то потрібно натиснути кнопку змінити вхідні 
дані.  
 
Рис. 4.10 – Зміна даних для розрахунку  
Після цього потрібно натиснути кнопку Виконати розрахунки і ми 
отримаємо дані, розраховані по моделі Уілсона, необхідні для того, щоб знати 
коли і в якій кількості потрібно заказувати новий товар. Необхідні нам 
параметри це: розмір замовлення, загальна вартість замовлення, період 
доставки та точка замовлення.   
Як бачимо з результатів розрахунку, товар необхідно заказувати в 
кількості 44 одиниці, загальні витрати заказу будуть 244 грн., період доставки 
буде 25 днів і заказ требі роботи, коли на складі буде 41 одиниця товару, тоді 
не буде простою компанії без товару.  
96 
 
ЧДТУ.2281.005 ПЗ  
  
 
Рис. 4.11 – Розрахунок необхідних параметрів.  
4.6  Опис розробки програмних компонентів 
Модуль внесення даних для розрахунку. 
public  void  inputWilsonModelForProduct(WilsonModel  wm) 
 throws SQLException {  
  String query = "select wilson_model.product_id from wilson_model where 
wilson_model.product_id="  
+ wm.getProductId();  
try {  
resultSet = dbConnector.statement.executeQuery(query);  
} catch (SQLException e1) {       
e1.printStackTrace();  
97 
 
ЧДТУ.2281.005 ПЗ  
     }  
  if (!doesProductHaveWilsonModel()) {    query = "INSERT INTO 
`wilson_model` (`product_id`,  
`sold_in_month`, "  
+ "`warehousing_cost`, `delivery_cost`,  
`delivery_time`, `rec_order_size`,"  
+  " `general_costs`, `rec_delivery_period`,  
`rec_order_point`) VALUES (" + wm.getProductId() + ", "  
     } else {  
query = "UPDATE `wilson_model` SET sold_in_month= " +  
wm.getSoldInMonth() + ", warehousing_cost = "  
+ wm.getWarehousingCost() + ", delivery_cost = "  
+ wm.getDeliveryCost() + ", delivery_time = "  
     + wm.getDeliveryTime() + ", rec_order_size=" + wm.getRecOrderSize() + 
", general_costs="  
+ wm.getGeneralCosts()  +  ",  
`rec_delivery_period`=+" + wm.getRecDeliveryPeriod()  
+ ", `rec_order_point`=" + wm.getRecOrderPoint()  
+ " WHERE product_id = " + wm.getProductId();  
}  
try {  
 dbConnector.statement.executeUpdate(query);    
 } catch (SQLException e) {      
 e.printStackTrace();  
}  
}  
Модуль розрахунку 
98 
 
ЧДТУ.2281.005 ПЗ  
public WilsonModel findWilsonModelForProduct(String query) throws 
SQLException {     if (dbConnector.connection == null || 
dbConnector.statement == null)  
{  
System.err.println("There is no database to execute the query.");  
return null;  
}  
resultSet = dbConnector.statement.executeQuery(query);  
   int productId = 0;   int soldInMonth = 0;   double 
warehousingCost = 0;   double deliveryCost = 0;  
   int deliveryTime = 0;  
    int recOrderSize = 0;  
   double generalCosts = 0;  
   int recDeliveryPeriod = 0;  
   int recOrderPoint = 0;  
Object[] values = { productId, soldInMonth, warehousingCost, deliveryCost, 
deliveryTime, recOrderSize,  
generalCosts, recDeliveryPeriod, recOrderPoint };  
  
  WilsonModel wilsonModel;   if 
(isWilsonModelForProductFilled()) {    for (int i = 1; i < 10; 
i++) {     values[i - 1] = resultSet.getObject(i);  
       }  
       int i = 0;   
 wilsonModel = new WilsonModel((int) values[i++], (int) values[i++], 
(float) values[i++],  
 (float)  values[i++],  (int)  values[i++],  (int) values[i++], 
(float) values[i++], (int) values[i++],  
     (int) values[i++]);    return wilsonModel;  
99 
 
ЧДТУ.2281.005 ПЗ  
  
  } else    return null;  
  
   }  
public boolean isWilsonModelForProductFilled() throws SQLException 
{  return resultSet.next();  
4.7 Тестування системи 
4.7.1 Модульне тестування  
Проаналізувавши існуючі методи для тестування, було обрано методи 
функціонального тестування, випадкове тестування, структурне тестування. Ці 
методи широко відомі і детально описані в літературі. В традиційній 
класифікації їх відносять до методів “чорного ящика”. Вони застосовуються для 
тестування зовнішніх та внутрішніх функцій системи і припускають наявність 
специфікації, використовуваної як еталон. Методи відрізняються між собою 
підходами до вибору даних з множини входів функцій.  
Завданням функціонального тестування є перевірка відповідності 
програми своїм специфікаціям. При даному підході текст програми не 
доступний, і програма розглядається як «чорний ящик».  
Найпоширенішими видами функціонального тестування є методи 
випадкового тестування, еквівалентної розбивки й аналізу граничних умов.  
Було розроблено тести для програмного забезпечення:  
– перевірка зчитування параметрів системою;  
– перевірка обробки виняткової ситуації при неправильно введених 
даних;  
– помилка в логіці функціонування системи; – коректність обрахунків 
та виведення.  
100 
 
ЧДТУ.2281.005 ПЗ  
Відповідно до обраних методів та принципів тестування програмного 
забезпечення було проведено тестування системи, яке представлено у вигляді 
таблиці (табл. 4.1).  
Таблиця 4.1 Рівні тестування 
Рівень тестування  Призначення  
Тестування окремих елементів  Перевірка результатів роботи 
окремих методів і функцій системи.  
Інтеграційне тестування  Орієнтоване на перевірку 
зв’язків і взаємодії компонентів 
системи  
Виняткові ситуації  Перевірка правильності обробки 
виняткових ситуацій, які можуть 
виникнути в процесі роботи системи.  
Загальне тестування системи  Перевірка  правильності 
функціонування системи, пошук і 
виявлення дефектів у системи і їх 
усунення.   
  
Тестування модуля виведення інформації показало придатність системи 
до її використання на реальних об’єктах. Отримані результати при роботі з 
програмним комплексом відповідають параметрам, що були поставлені у 
технічному завданні.   
Unit testing - один з обов'язкових інструментів в арсеналі будь-якого 
розробника ПЗ.   
Модульне тестування — це метод тестування програмного забезпечення, 
у якому створюються модулі, тобто невеликі частини програми, поведінка 
кожної з яких перевіряється окремо. Модульне тестування виконується на етапі 
101 
 
ЧДТУ.2281.005 ПЗ  
розробки програми. Модулем може бути будь-що, наприклад, процедура або 
функція.  
1. По-перше, ініціалізація невеликого фрагмента програми.  
2. Для цього викликається метод, що застосовується як стимул до 
тестованої системи.  
3. Останній етап: спостереження за поведінкою модуля, що 
перевіряється. Якщо поведінка, що спостерігається, відповідає очікуванням 
користувача, то модульний тест проходить. Цей покроковий процес також 
називається AAA (Arrange, Act, Assert).  
Модульний тест буває двох видів: з урахуванням стану, і навіть з 
урахуванням взаємодії. Якщо відстежується отриманий стан, це модульне 
тестування на основі стану.  
Якщо тестування відбувається при використанні певних методів, це 
модульне тестування на основі взаємодії.  
  
Рис. 4.13 –  Місце модульного тестування в класифікації видів 
тестування 
 
Модульні тести застосовуються для перевірки різних аспектів програми, 
не витрачаючи багато часу та зусиль з боку розробників.  
Такі тести:  
102 
 
ЧДТУ.2281.005 ПЗ  
• Працюють, навіть якщо в системі, що тестується, є помилка. На 
хороші модульні тести не впливатимуть зовнішні чинники, такі як довкілля чи 
порядок виконання. Якщо це станеться, то це безперечно недолік дизайну.  
• Хороший модульний тест зрозумілий і розповідає історію про 
поведінковий аспект програми. За допомогою тестових прикладів легко 
зрозуміти який сценарій був протестований. Якщо тест не проходить, 
виправити помилки можна швидко і без налагодження коду.  
• Модульні тести написані таким чином, що їх можна 
використовувати багаторазово.  
Unit-тести і система, що тестується, не повинні звертатися до мережевих 
ресурсів, файлових систем і баз даних, щоб виключити загальний вплив 
зовнішніх факторів, що робить такий тест дійсно модульним, а не 
інтеграційним. Вони прості у написанні, і їх легко підтримувати.  
Іноді розробники пропускають unit-тестування через брак часу, не 
розуміючи, чого це може призвести. Це спричиняє збільшення витрат на 
виправлення дефектів під час інтеграції, на бета-тестування та подальше 
тестування системи. Правильне модульне тестування під час розробки 
програми заощаджує час та гроші. Ось основні його переваги:  
1. Є можливість виправити дефекти на ранній стадії розробки, 
заощадивши ресурси.  
2. Це допомагає розробнику швидко розібратися з кодовою базою та 
швидко внести необхідні зміни.  
3. Хороші модульні тести зазвичай є проектною документацією.  
4. Модульні тести можна використовувати повторно і за необхідності 
швидко перенести на новий проект. Вам лише слід трохи підправити код, щоб 
він знову запустився.  
Модульне тестування поділяється на ручне та автоматичне. 
Автоматизація модульних тестів – хороша практика, її також можна виконувати 
103 
 
ЧДТУ.2281.005 ПЗ  
вручну. При ручному підході використовується документ із покроковими 
інструкціями. Перерахуємо по пунктах усі складові автоматизованого підходу:  
1. Розробник пише модульні тести, щоб перевірити функціональність 
конкретної частини програми. Вони закоментовані та будуть видалені пізніше, 
після успішного розгортання програми.  
2. Функція повинна бути ізольована, щоб її можна було перевірити 
ретельніше. Найкраща практика unit-тестування — копіювати та вставляти код 
у тестове середовище, замість роботи у природному середовищі.  
Ізольований код допомагає виявити та усунути залежності між кодом, що 
тестується, і просторами даних.  
3. Існує середовище модульного тестування розробки 
автоматизованих тестових випадків. Це середовище автоматизації допомагає 
писати код і перевіряє, чи правильно написаний код. Під час виконання 
модульних тестів платформа реєструє статус тестових випадків. Залежно від 
серйозності збоїв, структура може зупинити подальше тестування.  
4. Робочий процес модульного тестування поділено на чотири 
категорії: це створення тестових прикладів, огляд, базовий рівень та виконання 
тестових прикладів.  
Для проведення модульного тестування програми було використано 
бібліотеки JUnit JUnit.org та TestNG testNG.org  
Було проведено наступне модульне тестування:  
1. Внесення валідних даних по товару    - Passed  
2. Внесення валідних даних по постачальникам   - Passed  
3. Внесення валідних даних по продпажу товару  - Passed  
4. Внесення валідних даних для розрахунку  - Passed  
 
 4.7.2 Інтерграційне тестування.  
104 
 
ЧДТУ.2281.005 ПЗ  
Інтеграційне тестування — це тип тестування, у якому програмні модулі 
логічно поєднуються та тестуються як група. Як правило, програмний продукт 
складається з декількох програмних модулів, написаних різними 
програмістами. Метою тестування є виявлення помилок у взаємодії між цими 
програмними модулями і в першу чергу спрямоване на перевірку обміну 
даними між самими цими модулями. Ось чому його також називають «I&T» 
(інтеграція та тестування), «тестування рядків» і іноді «тестування потоків».  
Кожен програмний модуль проходить окремі етапи тестування (модульне 
тестування), але, незважаючи на це, дефекти можуть залишатися з ряду причин:  
Оскільки, як правило, модулі розробляються різними фахівцями, їх 
розуміння та логіка програмування можуть відрізнятися. Тут стає необхідним 
інтеграційне тестування, щоб перевірити взаємодію модулів один з одним.  
Під час розробки модуля клієнти часто змінюють вимоги, і якщо у вас 
стислі терміни, вимоги можуть просто не встигнути пройти модульне 
тестування, а отже, інтеграція системи може бути ускладнена.   
Інтеграційне тестування відрізняється від інших типів тестування тим, що 
воно зосереджується в основному на інтерфейсах і потоках даних (між 
модулями). Тут пріоритет перевірки надається інтеграції посилань, а не 
блокуванню функцій, які вже були перевірені.  
Інтеграційне тестування призначене для перевірки зв’язку між 
компонентами, а також взаємодії з різними частинами системи (операційна 
система, апаратне забезпечення або зв’язок між різними системами).  
Рівні тестування інтеграції:  
• Рівень інтеграції компонентів (тестування інтеграції компонентів)  
Взаємодія між компонентами системи перевіряється після тестування 
компонентів.  
• Рівень системної інтеграції (System Integration Testing)  
105 
 
ЧДТУ.2281.005 ПЗ  
Взаємодія між різними системами перевіряється після тестування 
системи.  
Підходи до інтеграційного тестування:  
• Знизу вгору (інтеграція знизу вгору)  
Усі низькорівневі модулі, процедури або функції збираються разом, а 
потім тестуються. Після цього збирається наступний рівень модулів для 
інтеграційного тестування. Такий підхід вважається корисним, якщо всі або 
майже всі модулі розробленого рівня готові. Також цей підхід допомагає 
визначити рівень готовності програми за результатами тестування (див. також 
Інтеграційне тестування - знизу вгору)  
• Інтеграція зверху вниз  
Спочатку тестуються всі модулі високого рівня, і поступово, один за 
іншим, додаються низькорівневі. Усі модулі нижчого рівня моделюються 
заглушками зі схожою функціональністю, потім, у міру готовності, 
замінюються реальними активними компонентами. Тому тестуємо зверху вниз. 
(див. також інтеграцію зверху вниз)  
• Big Bang (інтеграція "Big Bang")  
Всі або майже всі розроблені модулі збираються разом як цілісна система 
або її основна частина, після чого проводиться інтеграційне тестування. Такий 
підхід дуже хороший для економії часу. Однак, якщо тестові випадки та їх 
результати не будуть записані належним чином, то сам процес інтеграції буде 
значно ускладнений, що стане перешкодою для команди тестування для 
досягнення основної мети інтеграційного тестування.  
Було проведено наступне інтеграційне тестування:  
1. Вибір товару із списку після внесення    - Passed  
2. Зміна кількості товару після внесення даних   - Passed  
3. Розрахунок  параметрів  замовлення  після  - Passed  
внесення даних   
106 
 
ЧДТУ.2281.005 ПЗ  
4.7.3 Системне тестування  
Тестування системи — це тип тестування програмного забезпечення, яке 
виконується на повній інтегрованій системі для оцінки відповідності системи 
відповідним вимогам. У системному тестуванні компоненти, пройдені 
інтеграційним тестуванням, приймаються як вхідні дані. Метою інтеграційного 
тестування є виявлення будь-яких порушень між інтегрованими одиницями. 
Тестування системи виявляє дефекти як в інтегрованих блоках, так і в системі 
в цілому. Результатом тестування системи є спостережувана поведінка 
компонента або системи під час її тестування. Тестування системи проводиться 
для всієї системи в контексті або специфікацій системних вимог, або 
специфікацій функціональних вимог, або в контексті обох. Тестування системи 
перевіряє дизайн і поведінку системи, а також очікування замовника. Це 
виконується для тестування системи за межами, зазначеними в специфікації 
вимог до програмного забезпечення (SRS). Тестування системи в основному 
виконується групою тестувальників, незалежною від групи розробників, яка 
допомагає неупереджено перевірити якість системи. Він має як функціональне, 
так і нефункціональне тестування. Тестування системи виконується після 
інтеграційного тестування та перед приймальним тестуванням.  
  
Рис. 4.14 –  Місце системного тестування в класифікації видів 
тестування 
Було проведено наступне системне тестування:  
1. Стресове тестування  - Passed  
2. Нагрузочне тестування  - Passed 3.  Кросбраузерне тестування  - 
Passed  
107 
 
ЧДТУ.2281.005 ПЗ  
4.4.4 Приймальне тестування  
Приймальне тестування — це останній етап тестування програмного 
забезпечення, що виконується після тестування системи та перед тим, як 
зробити систему доступною для фактичного використання.  
  
Рис. 4.15 –  Місце приймального тестування в класифікації видів тестування 
Типи приймальних тестуваня:  
User Acceptance Testing (UAT): Прийнятне тестування користувача 
використовується для визначення того, чи правильно продукт працює для 
користувача. Специфічні вимоги, якими досить часто користуються замовники, 
в першу чергу вибираються з метою тестування. Це також називається 
тестуванням кінцевого користувача.  
Business Acceptance Testing (BAT): BAT використовується для 
визначення того, чи відповідає продукт бізнес-цілям чи ні. BAT головним 
чином зосереджується на прибутках бізнесу, які є досить складними через 
мінливі ринкові умови та нові технології, тому поточне впровадження, 
можливо, доведеться змінити, що призведе до додаткових бюджетів.  
Contract Acceptance Testing (CAT): CAT — це контракт, який визначає, що 
після запуску продукту протягом заздалегідь визначеного періоду необхідно 
виконати приймальне тестування, і він повинен пройти всі прийнятні випадки 
використання. Іноді цей контракт укладається ще до запуску продукту.   
Regulations Acceptance Testing (RAT): RAT використовується для 
визначення того, чи порушує продукт правила та норми, визначені урядом 
країни, де він випускається. Це може бути ненавмисно, але негативно вплине 
108 
 
ЧДТУ.2281.005 ПЗ  
на бізнес. Як правило, продукт або програма, які мають бути випущені на ринок, 
мають проходити під RAT, оскільки різні країни чи регіони мають різні правила 
та норми, визначені їх керівними органами. Якщо будь-які правила та норми 
порушуються для будь-якої країни, то для цієї країни чи конкретного регіону, 
продукт не буде випущено в цій країні чи регіоні. Якщо продукт буде 
випущено, навіть якщо є порушення, то лише постачальники продукту будуть 
нести пряму відповідальність.  
Operational Acceptance Testing (OAT): OAT використовується для 
визначення готовності продукту до експлуатації та є нефункціональним 
випробуванням. Це в основному включає тестування відновлення, сумісності, 
ремонтопридатності, надійності тощо. OAT гарантує стабільність продукту 
перед його випуском у виробництво.  
Альфа-тестування: Альфа-тестування використовується для визначення 
продукту в середовищі тестування розробки спеціалізованою командою 
тестувальників, яку зазвичай називають альфа-тестерами.  
Бета-тестування: бета-тестування використовується для оцінки продукту 
шляхом ознайомлення з ним справжніх кінцевих користувачів, яких у своєму 
середовищі зазвичай називають бета-тестерами. Від користувачів збираються 
відгуки та виправляються недоліки. Крім того, це допомагає покращити 
продукт, щоб забезпечити багатий досвід користувача.  
Так як система розроблялась для виконання магістерської роботи, то 
приймальне тестування було проведено мною і пройло успішно.  
     
109 
 
ЧДТУ.2281.005 ПЗ  
Висновки до четвертого розділу 
Засобами програмної розробки проекту магістерської роботи вибрано 
JDBC, Java, MySQL, Spring Framework, Spring Security.  
JDBC (англ. Java DataBase Connectivity - з'єднання з базами даних на Java) 
- платформенно - незалежний промисловий стандарт взаємодії Java додатків з 
різними СУБД, реалізований у вигляді пакета java.sql, що входить до складу 
Java SE.  
JDBC заснований на концепції так званих драйверів, що дозволяють 
отримувати з'єднання з базою даних за спеціально описаного URL. Драйвери  
можуть завантажуватися динамічно ( під час роботи програми). 
Завантажившись, драйвер сам реєструє себе і викликається автоматично, коли 
програма вимагає URL, що містить протокол, за який драйвер відповідає.  
БД системи складається з 4 таблиць. Перша таблиця, це таблиця даних 
про продукцію, яка знаходиться на фірмі:. Друга таблиця, це таблиця даних про 
продаж продукції, яка знаходиться на фірмі. Наступна таблиця містить дані про 
поставщиків. Четверта таблиця це таблиця даних, які розраховуються по моделі 
Уілсона.   
Також в главі представлено інтерфейс основних вікон програми та 
проведено функціональне тестування системи.  
  
  
  
  
  
 
 
 
 
    
110 
 
ЧДТУ.2281.005 ПЗ  
ЗАГАЛЬНІ ВИСНОВКИ  
При застосуванні автоматизованих систем управління на торгівельних 
підприємствах відбувається підвищення керованості і гнучкості бізнесу, 
збільшення його ринкової вартості й інвестиційної привабливості, а також 
поліпшення іміджу безпосередньо менеджменту, який використовує найбільш 
прогресивні інструменти управління.   
В першому розділі описані моделі управління запасами. Математичні 
моделі управління запасами дозволяють знайти оптимальний рівень запасів 
деякого товару, який дозволяє мінімізувати сумарні витрати на закупку, 
оформлення й доставку замовлення, зберігання товару, а також збитки від його 
дефіциту. [52]  
В другому розділі описана предметна область. Роздрібна торгівля це 
кінцева форма реалізації товарів кінцевому споживачеві у невеликих обсягах 
через магазини, павільйони, лотки, намети та інші точки роздрібної торгової 
мережі. Комерційно-збутова робота на підприємствах роздрібної торгівлі, на 
відміну від підприємств оптової торгівлі, має свої особливості. Підприємства 
роздрібної торгівлі реалізують товари безпосередньо населенню, тобто 
фізичним особам, використовуючи свої, специфічні способи та методи 
роздрібної реалізації.  
В третьому розділі були висвітлена теорія формування аналізу вимог до 
інформаційних систем. Предствлені діаграми за допомогою UML: діаграма 
розгортання, діаграма комунікації, діаграма діяльності, діаграма компонентів, 
діаграма пакетів, діаграма класів, діаграма послідовностей та діаграма 
прецедентів.   
Також в четвертому розділі представлено інтерфейс основних вікон 
програми та проведено функціональне тестування системи.  
 
111 
 
ЧДТУ.2281.005 ПЗ  
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
 
1. Автоматизовані системи управління  роздрібною 
 торгівлею [Електронний  ресурс].  –  Режим  доступу: 
http://nauka.kushnir.mk.ua/?p=10048  
2. Положення (стандарт) бухгалтерського обліку 9 " Запаси», Наказ 
Мінфіна України № 87 від 31.03.1999 + № 304 від 30.11.2000.  
3. Господарський кодекс України від 16 січня 2003 року N 436-IV(діє 
з 01.01.2004) // Із змінами і доповненнями, внесеними Законами України від 9 
січня 2007 року N 549-V, ОВУ, 2007 р., N 8, ст. 276  
4. ЗАКОН УКРАЇНИ «Про господарські товариства» // від 19 вересня 
1991 року N 1576-XII (Із змінами і доповненнями, внесеними Законами України 
станом на 19 лютого 2004 року N 1519-IV)  
5. Андрєєва Г. І. Економічний аналіз : навч.-метод. посібник / Г. І. 
Андрєєва. – К. : Знан.ня, 2008. – 263 с.  
6. Белявцева В.В. Автоматизированные технологии организации 
управленческого учета в торговле // Економіка: проблеми теорії та практики: 
Зб.наук.пр. – Вип. 206 – Дніпропетровськ: Наука і освіта, 2005. – С. 224-229.  
7. Бланк И. А. Финансовый менеджмент : учебный курс / И. А. Бланк. 
– Изд. 2-е, перераб. и доп. – К. : Эльга : Ника-Центр, 2006. – 656 с.  
8. Василенко Л. П. Фінанси підприємства у схемах і таблицях : 
наочний навчальний посібник / Л. П. Василенко, Л. В. Гут, О. П. Оксеєнко ; 
Київський нац. торг.-екон. ун-т, Чернівецький торг.-екон. ін-т. – К. : Дакор, 
2006. – 343 с.  
9. Виноградська А.М. Комерційна діяльність торговельного 
підприємства : Навчальний посібник. - К.: Київ. нац. торг.-екон. ун-т, 2005. - 278 
с.  
112 
 
ЧДТУ.2281.005 ПЗ  
10. Внутрішній економічний механізм підприємства : навч. посібник / 
П. В. Круш [та ін.] ; Нац. технічний ун-т України "Київський політехнічний ін-
т". – К. : Центр учбової літератури, 2008. – 205 с.  
11. Гетьман О.О., Шаповал В.М. Економіка підприємства: навчальний 
посібник для студентів вищих навчальних закладів.- Київ, Центр навчальної 
літератури, 2006. – 488 с.  
12. Гетьман О. О. Економічна діагностика : навч. посіб. / О. О. Гетьман, 
В. М. Шаповал ; М-во освіти і науки України, Український державний хіміко-
технологічний ун-т, Дніпропетровський ун-т економіки та права. – К. : Центр 
навчальної літератури, 2007. – 307 с.  
13. Економіка підприємства (в питаннях і відповідях) : навч. посібник / 
І. І. Цигилик [та ін.]. – 2-ге вид., переробл. і доповн. – К. : Центр учбової 
літератури, 2007. – 212 с.  
14. Кармазін В.А. Економічний аналіз : практикум / В. А. Кармазін, О. 
М. Савицька. – К. : Знання, 2007. – 255 с.  
15. Комерційна діяльність : навч. посіб. / Н. О. Криковцева [та ін.]. – К. 
: Центр учбової літератури, 2007. – 294 с.  
16. Комерційна діяльність : підручник / [В. В. Апопій та ін.] ; за ред. В. 
В. Апопія. – 2-ге вид., переробл. і доповн. – К. : Знання, 2008. – 559 с.  
17. Новітній маркетинг : навч. посібник / [Є. В. Савельєв та ін.] ; за ред. 
Є. В. Савельєва. – К. : Знання, 2008. – 421 с.  
18. Організація торгівлі : підручник / В. В. Апопій [та ін] ; за ред. В. В. 
Апопія ; М-во освіти і науки України, Львівська комерційна академія. – Вид. 2-
ге, переробл. і доповн. – К. : Центр учбової літератури, 2008. – 629 с.  
19. Партин Г.О. Управлінський облік : навч. посібник / Г. О. Партин, А. 
Г. Загородній. – 2-ге вид., виправл. і доповн. – К. : Знання, 2007. – 304 с.  
20. Савицька Г. В. Економічний аналіз діяльності підприємства : 
навчальний посібник / Г. В. Савицька. – 3-тє вид., виправл. і доповн. – К. : 
Знання, 2007. – 669 с.  
113 
 
ЧДТУ.2281.005 ПЗ  
21. Сизоненко В.О. Сучасне підприємництво : навч. посібник / В. О. 
Сизоненко. – К. : Знання-Прес, 2008. – 440 с.  
22. Управління витратами : навч. посібник / [М. Г. Грещак та ін.] ; за 
ред. М. Г. Грещака ; Держ. вищ. навч. заклад "Київський нац. екон. ун-т ім. В. 
Гетьмана". – К. : КНЕУ, 2008. – 259 с.  
23. Фінанси / О. Р. Романенко [та ін.] ; М-во освіти і науки України, 
Київський нац. екон. ун-т імені Вадима Гетьмана. – 2-ге вид., без змін. – К. : 
КНЕУ, 2007. – 387 с.  
24. Цал-Цалко Ю. С. Фінансовий аналіз : підручник / Ю. С. Цал-Цалко. 
– К. : Центр учбової літератури, 2008. – 566 с.  
25. Цигилик І.І. Основи підприємництва : навч. посібник / І. І. Цигилик, 
З. М. Криховецька, Т. М. Паневник. – 2-ге вид., переробл. та доповн. – К. : Центр 
учбової літератури, 2007. – 224 с.  
26. Швиданенко Г. О. Управління капіталом підприємства : навч. 
Посібник / Г. О. Швиданенко, Н. В. Шевчук ; М-во освіти і науки України, 
Держ. вищ. навч. заклад "Київський нац. екон. ун-т ім. В. Гетьмана". – К. : 
КНЕУ, 2007. – 436 с.  
27. Швиданенко Г.О. Бізнес-діагностика підприємства / Г. О. 
Швиданенко,   
28. А. І. Дмитренко, О. І. Олексюк ; М-во освіти і науки України, Держ. 
вищ. навч. заклад "Київський нац. екон. ун-т ім. В. Гетьмана". – К., 2008. – 340 
с.  
29. Шморгун Н.П. Фінансовий аналіз : навч. посібник для студ. вищих 
навчальних закладів / Н. М. Шморгун, І. В. Головко ; М-во освіти і науки 
України, Київський нац. ун-т ім. Т. Шевченка. – К. : Центр навчальної 
літератури, 2006. – 525 с.  
30. Бука Дж., Кенігсберг Е. Наукове управління запасами. – М.: 
«Наука», 1967. – 378 с.  
114 
 
ЧДТУ.2281.005 ПЗ  
31. Замків О.О., Толстопятенко А.В., Черемних Ю.Н. Математичні 
методи в економіці. – М.: ДІС, 1997. – 571 с.  
32. Марченко А. В. Проектування інформаційних систем / А. В. 
Марченко. –  К.,  2016  [Електронний  ресурс].  –  Режим 
 доступу: https://elearning.sumdu. 
edu.ua/free_content/lectured:de1c9452f2a161439391120 
eef364dd8ce4d8e5e/20160217112601/content20160217112601.pdf.  
33. В.О.Грязнова, С.В. Єфіменко. Основи методології програмування. - 
К.: ВПЦ "Київський університет", 2005 р.  
34. Можливості IBM Inventori [Електронний ресурс]. – Режим доступу: 
https://abmcloud.com/uk/abm-soft/abm-inventory/  
35. Аналіз систем управління запасами [Електронний ресурс]. – Режим 
доступу: http://publications.ntu.edu.ua/visnyk/26_2_2013/313-324.pdf  
36. Автоматизація управління запасами торгівельного підприємства 
[Електронний ресурс]. – Режим доступу: https://xreferat.com/113/1285-
2avtomatizac-ya-upravl-nnya-zapasami-torg-vel-nogo-p-dpri-mstva.html  
37. Створення UML діаграмм - [Електронний ресурс]. – Режим 
доступу: https://app.diagrams.net/  
   
115 
 
 
ДОДАТОК А 
 
 
 
 
 ЗАТВЕРДЖЕНО: 
 Зав. кафедрою ПЗАС, професор 
 _____________ Голуб С.В. 
 „____” _________________ 2023 р. 
 
 
 
 
 
 
 
Програмне забезпечення системи розрахунку оптимального розміру 
замовлення за моделлю Уілсона 
 
 
 
Специфікація 
482. ЧДТУ 2281.005   
Листів 2 
 
 
 
 
 
 
Розробник ________________ Семенчук К.М. 
Керівник ________________ Первунінський С.М. 
 
 
 
 
 
2023 
 
107 
 
Позначення Найменування Примітка 
 Документація  
482.ЧДТУ. 2281-01 12 01 Текст програми  
482.ЧДТУ. 2281-01 34 01 Інструкція користувачеві  
482.ЧДТУ. 2281-01 90 01 Графічні матеріали  
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
 
  
  
108 
 
  
ДОДАТОК Б  
  
  
  
  
  
  
  
  
Програмне забезпечення системи розрахунку оптимального розміру 
замовлення за моделлю Уілсона  
  
   
  
  
  
  
Текст програми  
482.ЧДТУ. 2281-01 12 01  
Листів 14  
  
  
  
 Розробник  ________________       Семенчук К.М.  
  
  
  
2023  
 
 482.ЧДТУ. 2281-01 12 01    
2 
>  
 <  -- --------------------------------------------------------  
-- Host:                         127.0.0.1  
-- Server version:               5.6.19 - MySQL Community Server (GPL)  
-- Server OS:                    Win64  
-- HeidiSQL version:             7.0.0.4053  
-- Date/time:                    2017-11-20 19:07:29  
-- --------------------------------------------------------  
  
 /*!40101  SET  
@OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;  
/*!40101 SET NAMES utf8 */;  
/*!40014 SET FOREIGN_KEY_CHECKS=0 */;  
  
-- Dumping database structure for selling  
CREATE DATABASE IF NOT EXISTS `selling` /*!40100 DEFAULT  
CHARACTER SET utf8 */;  
USE `selling`;  
  
  
-- Dumping structure for table selling.product  
CREATE TABLE IF NOT EXISTS `product` (  
  `id` int(10) NOT NULL AUTO_INCREMENT,  
  `name` varchar(50) NOT NULL DEFAULT '0',  
  `price` float NOT NULL DEFAULT '0',  
  `quantity` int(11) NOT NULL DEFAULT '0',  
  `supplier_id` int(11) NOT NULL DEFAULT '0',  
  PRIMARY KEY (`id`)  
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;  
 
110  
  
 482.ЧДТУ. 2281-01 12 01    
  3 
-- Dumping data for table selling.product: ~3 rows (approximately)  
/*!40000 ALTER TABLE `product` DISABLE KEYS */;  
INSERT INTO `product` (`id`, `name`, `price`, `quantity`, `supplier_id`) VALUES  
   (1, 'processor', 442, 268, 1),  
   (2, 'computer', 2221, 486, 2);  
/*!40000 ALTER TABLE `product` ENABLE KEYS */;  
  
  
-- Dumping structure for table selling.sales  
CREATE TABLE IF NOT EXISTS `sales` (  
  `id` int(10) NOT NULL AUTO_INCREMENT,  
  `product_id` int(10) NOT NULL DEFAULT '0',  
  `quantity` int(10) NOT NULL DEFAULT '0',  
  `date` datetime NOT NULL,  
  `price` float NOT NULL DEFAULT '0',  
  `purchase_amount` float NOT NULL DEFAULT '0',  
  PRIMARY KEY (`id`)  
) ENGINE=InnoDB AUTO_INCREMENT=43 DEFAULT CHARSET=utf8;  
  
-- Dumping data for table selling.sales: ~18 rows (approximately)  
/*!40000 ALTER TABLE `sales` DISABLE KEYS */;  
 INSERT  INTO  `sales`  (`id`,  `product_id`,  `quantity`,  `date`,  `price`,  
`purchase_amount`) VALUES  
   (30, 1, 2, '2022-11-19 17:03:58', 5, 10),  
   (31, 1, 2, '2022-11-19 17:09:52', 55, 110),  
(32, 1, 22, '2022-11-19 17:10:38', 5.14, 113.08),  
(33, 1, 5, '2022-11-19 17:43:13', 5, 25),  
(34, 1, 5, '2022-11-19 17:43:58', 50, 250),  
   (36, 2, 15, '2022-11-20 19:01:21', 5, 75),  
111  
  
 482.ЧДТУ. 2281-01 12 01    
   (37, 2, 12, '2022-11-20 19:04:29', 52, 624),  4 
   (38, 1, 5, '2022-11-20 19:04:53', 5, 25),  
   (39, 2, 3, '2022-11-20 19:05:14', 3, 9),  
   (40, 2, 15, '2022-11-20 19:05:36', 15, 225),  
  (41, 1, 5, '2022-11-20 19:05:58', 5, 25),  
 (42, 2, 5, '2022-11-20 19:07:05', 5, 25);  
/*!40000 ALTER TABLE `sales` ENABLE KEYS */;  
  
  
-- Dumping structure for table selling.supplier  
CREATE TABLE IF NOT EXISTS `supplier` (  
  `id` int(10) NOT NULL AUTO_INCREMENT,  
  `name` varchar(50) NOT NULL DEFAULT '0',  
  PRIMARY KEY (`id`)  
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;  
  
-- Dumping data for table selling.supplier: ~0 rows (approximately)  
/*!40000 ALTER TABLE `supplier` DISABLE KEYS */;  
INSERT INTO `supplier` (`id`, `name`) VALUES  
   (1, 'ПП Василенко'),  
   (2, 'ПП Петренко');  
/*!40000 ALTER TABLE `supplier` ENABLE KEYS */;  
  
  
-- Dumping structure for table selling.wilson_model  
CREATE TABLE IF NOT EXISTS `wilson_model` ( 
  `id` int(10) NOT NULL AUTO_INCREMENT,  
  `product_id` int(10) NOT NULL,  
  `sold_in_month` int(10) NOT NULL DEFAULT '0',  
112  
  
 482.ЧДТУ. 2281-01 12 01    
  `warehousing_cost` float NOT NULL DEFAULT '0',  5 
  `delivery_cost` float NOT NULL DEFAULT '0',  
  `delivery_time` int(10) NOT NULL DEFAULT '0',  
  `rec_order_size` int(11) NOT NULL DEFAULT '0',  
  `general_costs` float NOT NULL DEFAULT '0',  
  `rec_delivery_period` int(11) NOT NULL DEFAULT '0',  
  `rec_order_point` int(11) NOT NULL DEFAULT '0',  
  PRIMARY KEY (`id`)  
) ENGINE=InnoDB AUTO_INCREMENT=24 DEFAULT CHARSET=utf8;  
  
-- Dumping data for table selling.wilson_model: ~0 rows (approximately)  
/*!40000 ALTER TABLE `wilson_model` DISABLE KEYS */;  
 INSERT  INTO  `wilson_model`  (`id`,  `product_id`,  `sold_in_month`,  
 `warehousing_cost`,  `delivery_cost`,  `delivery_time`,  `rec_order_size`,  
`general_costs`, `rec_delivery_period`, `rec_order_point`) VALUES  
   (27, 1, 2282, 5, 112, 21, 319, 1579, 4, 1597),  
   (28, 2, 59, 123, 41.21, 44, 6, 739.89, 3, 86);  
/*!40000 ALTER TABLE `wilson_model` ENABLE KEYS */;  
/*!40014 SET FOREIGN_KEY_CHECKS=1 */;  
 /*!40101  SET  
 CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT  */; 
   ExpertRiskSelectPanel expertRiskSelectPanel;  
   JPanel tablePanel = new JPanel();  
   JScrollPane tableScroll;  
  JScrollPane averageRiskTableScroll; private 
ProjectSelectPanel projectSelectPanel; private 
JTable riskTable; private JTable 
averageRiskTable;  
113  
  
 482.ЧДТУ. 2281-01 12 01    
StageSelectPanel stageSelectPanel;  private JButton showStageResults = new 6 
JButton("Результат етапу");  boolean resultShown = false;  
  
  Window(int windowWidth, int windowHeight) {    
 setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);    
 setLayout(null);     setSize(windowWidth, 
windowHeight);  
   }  
  
 public void setStageSelectAndExpertRiskSelectPanels(List<Stage> stages, 
List<Expert> experts, List<Risk> risks) {   if (stageSelectPanel == null)    
stageSelectPanel = new StageSelectPanel(stages);  
     else {  
      stageSelectPanel.getStageListBox().removeAllItems();    
   for (Stage s : stages)  
      
   stageSelectPanel.getStageListBox().addItem(s.getName());  
     }  
  if (expertRiskSelectPanel == null)    expertRiskSelectPanel = new 
ExpertRiskSelectPanel(experts, risks);  
    getContentPane().add(stageSelectPanel);    
 getContentPane().add(expertRiskSelectPanel);    
 stageSelectPanel.setBounds(10, 120, 375, 70);  
 expertRiskSelectPanel.setBounds(400, 10, 600, 170);   setVisible(true);  
}  
public void setProjectSelectPanel(List<Project> projects) {   
projectSelectPanel = new ProjectSelectPanel(projects);   
getContentPane().add(projectSelectPanel);   
projectSelectPanel.setBounds(10, 10, 375, 70); package formulas;  
114  
  
 482.ЧДТУ. 2281-01 12 01  7   
  
public class WilsonModelFormulas {  
  
   public static int calculateSizeOfOrder(double deliveryCost, int soldInMonth  
, double warehousingCost) {   return (int) 
Math.sqrt((2*deliveryCost*soldInMonth)/  
         warehousingCost);  
   }  
    
 public static double calculateGeneralCosts(double deliveryCost, int soldInMonth, int 
sizeOfOrder,double warehousingCost) {  
     return  
 deliveryCost*(soldInMonth/sizeOfOrder)+warehousingCost*(sizeOfOrder/2);    
   }  
    
 public static int calculateDeliveryPeriod(int sizeOfOrder,int soldInMonth) {   return 
(int) (sizeOfOrder*1.0/soldInMonth*30);  
      
   }  
    
public static int calculateDeliveryPoint(int soldInMonth, int deliveryTime) {  
return soldInMonth*deliveryTime/30;  
}  
 
} package 
dbaccess;  
  
import java.sql.ResultSet; import 
java.sql.SQLException;  
115  
  
 482.ЧДТУ. 2281-01 12 01    
8 
  
import bean.WilsonModel;  
  
public class DBAccessObject {  
  
   DBConnector dbConnector;  
   ResultSet resultSet;  
  
  public DBAccessObject(DBConnector dbConnector) {    
 this.dbConnector = dbConnector;  
   }  
  
  public WilsonModel findWilsonModelForProduct(String query) throws 
SQLException {     if (dbConnector.connection == null || 
dbConnector.statement == null)  
{  
       System.err.println("There is no database to execute the query.");  
       return null;  
     }  
    resultSet = dbConnector.statement.executeQuery(query);  
   int productId = 0;   int soldInMonth = 0;   double 
warehousingCost = 0;   double deliveryCost = 0;  
   int deliveryTime = 0;  
    int recOrderSize = 0;    
 double generalCosts = 0;    
 int recDeliveryPeriod = 0;    
 int recOrderPoint = 0;  
    Object[] values = { productId, soldInMonth, warehousingCost, 
deliveryCost, deliveryTime, recOrderSize,  
116  
  
 482.ЧДТУ. 2281-01 12 01    
9 
         generalCosts, recDeliveryPeriod, recOrderPoint };  
  
  WilsonModel wilsonModel;   if 
(isWilsonModelForProductFilled()) {    for (int i = 1; i < 10; 
i++) {     values[i - 1] = resultSet.getObject(i);  
       }  
       int i = 0;   
      wilsonModel = new WilsonModel((int) values[i++], (int) 
values[i++], (float) values[i++],  
          (float)  values[i++],  (int)  values[i++], 
 (int) values[i++], (float) values[i++], (int) values[i++],  
     (int) values[i++]);    return wilsonModel;  
  
  } else    return null;  
  
   }  
public boolean isWilsonModelForProductFilled() throws SQLException {  
return resultSet.next();  
 
}  
public  void  inputWilsonModelForProduct(WilsonModel  wm) 
 throws SQLException {  
  String query = "select wilson_model.product_id from wilson_model where 
wilson_model.product_id="  
         + wm.getProductId();  
  
     try {  
117  
  
 482.ЧДТУ. 2281-01 12 01    
10 
       resultSet = dbConnector.statement.executeQuery(query);  
    } catch (SQLException e1) {      
 e1.printStackTrace();  
     }  
  if (!doesProductHaveWilsonModel()) {    query = "INSERT INTO ̀ wilson_model` 
(`product_id`,  
`sold_in_month`, "  
           +  "`warehousing_cost`,  `delivery_cost`,  
`delivery_time`, `rec_order_size`,"  
           +  "  `general_costs`,  `rec_delivery_period`,  
`rec_order_point`) VALUES (" + wm.getProductId() + ", "  
          +  wm.getSoldInMonth()  +  ",  "  +  
wm.getWarehousingCost() + ", " + wm.getDeliveryCost() + ", "  
          +  wm.getDeliveryTime()  +  ",  "  +  
wm.getRecOrderSize() + ", " + wm.getGeneralCosts() + ", "  
          +  wm.getRecDeliveryPeriod()  +  ",  "  +  
wm.getRecOrderPoint() + ")";  
     } else {  
       query = "UPDATE `wilson_model` SET sold_in_month= " +  
wm.getSoldInMonth() + ", warehousing_cost = "  
 
         + wm.getWarehousingCost() + ", delivery_cost = "  
+ wm.getDeliveryCost() + ", delivery_time = "  
     + wm.getDeliveryTime() + ", rec_order_size=" + wm.getRecOrderSize() + ", 
general_costs="  
           +  wm.getGeneralCosts()  +  ",  
`rec_delivery_period`=+" + wm.getRecDeliveryPeriod()  
           + ", `rec_order_point`=" + wm.getRecOrderPoint()  
+ " WHERE product_id = " + wm.getProductId();  
     }  
118  
  
 482.ЧДТУ. 2281-01 12 01  11   
     try {  
      dbConnector.statement.executeUpdate(query);  
   } catch (SQLException e) {      
 e.printStackTrace();  
     }  
   }  
  
 public boolean doesProductHaveWilsonModel() throws SQLException {   
return resultSet.next();  
   }  
  
} package 
dbaccess;  
  
import java.sql.Connection; import 
java.sql.DriverManager; import 
java.sql.SQLException; import 
java.sql.Statement;  
  
public class DBConnector {  
 
Connection connection;  
Statement statement;  
  
 public DBConnector(String url, String driverName, String user, String passwd) {  
     try {  
       Class.forName(driverName);  
       System.out.println("Opening db connection");  
119  
  
 482.ЧДТУ. 2281-01 12 01    
12 
  
      connection = DriverManager.getConnection(url, user, passwd);  
     statement = connection.createStatement();  
     } catch (ClassNotFoundException ex) {  
       System.err.println("Cannot find the database driver classes.");  
       System.err.println(ex);  
     } catch (SQLException ex) {  
       System.err.println("Cannot connect to this database.");  
       System.err.println(ex);  
     }  
  
   }  
  
 public Connection getConnection() {   return 
connection;  
   }  
  
public Statement getStatement() {  return 
statement;  
}  
} package 
dbaccess;  
  
import java.sql.ResultSet; import 
java.sql.ResultSetMetaData; import 
java.sql.SQLException; import 
java.sql.Types; import 
java.text.DateFormat; import 
java.text.SimpleDateFormat; 
120  
  
 482.ЧДТУ. 2281-01 12 01    
13 
import java.util.ArrayList; import 
java.util.Date; import java.util.List;  
  
import javax.swing.table.AbstractTableModel;  
  
public class SalesDBAdapter extends AbstractTableModel {  
  DBConnector dbConnector;  
 ResultSet resultSet;  
   String[] columnNames = { "Назва", "К-сть", "Час", "Ціна", "Сума" };  
   List rows;  
   ResultSetMetaData metaData;  
   SimpleDateFormat dbDateFormat = new SimpleDateFormat("yyyy-MM-dd  
HH:mm:ss");  
   
SimpleDateFormat userDateFormat = new SimpleDateFormat("dd-MMyyyy 
HH:mm:ss");  
  
public SalesDBAdapter(DBConnector dbConnector) {  
 this.dbConnector = dbConnector;  
}  
 
public void executeRowsFillQuery(String query) {   if 
 (dbConnector.getConnection()  ==  null  ||  dbConnector.  
getStatement() == null) {  
       System.err.println("There is no database to execute the query.");  
       return;  
  
     }  
121  
  
 482.ЧДТУ. 2281-01 12 01  14   
     try {  
      resultSet = dbConnector.getStatement().executeQuery(query);  
     metaData = resultSet.getMetaData();  
  
       int numberOfColumns = columnNames.length;  
  
      rows = new ArrayList();       while 
(resultSet.next()) {         List newRow = new 
ArrayList();         for (int i = 1; i <= 
getColumnCount(); i++) {           if (i == 3) {  
            newRow.add(userDateFormat.format((Date) 
resultSet.getObject(i)));  
             continue;  
           }  
           newRow.add(resultSet.getObject(i));  
         }  
         rows.add(newRow);  
     }  
 // close(); Need to copy the metaData, bug in jdbc:odbc driver. 
fireTableChanged(null); // Tell the listeners a new table has  
arrived.  
     } catch (SQLException ex) {  
       System.err.println(ex);  
     }  
   }  
  
  public void close() throws SQLException {    
 System.out.println("Closing db connection");    
122  
  
 482.ЧДТУ. 2281-01 12 01  15   
 resultSet.close();     dbConnector.getStatement().close();  
   dbConnector.getConnection().close();  
   }  
  
   public void finalize() throws Throwable {  
     close();  
     super.finalize();  
   }  
  
   //////////////////////////////////////////////////////////////////////////  
   //  
   // Implementation of the TableModel Interface  
   //  
 //////////////////////////////////////////////////////////////////////////   
   // MetaData  
  
public String getColumnName(int column) { if 
(columnNames[column] != null) { 
return columnNames[column];  
 } else {    
 return "";  
   }  
}  
  
   public Class getColumnClass(int column) {  
  int type;   try {  
       type = metaData.getColumnType(column + 1);  
    } catch (SQLException e) {      
 return super.getColumnClass(column);  
123  
  
 482.ЧДТУ. 2281-01 12 01  16   
     }  
  
  switch (type) {   case Types.CHAR:   case 
Types.VARCHAR:   case 
Types.LONGVARCHAR:    return 
String.class;  
  
     case Types.BIT:  
       return Boolean.class;  
  
    case Types.TINYINT:    
 case Types.SMALLINT:    
 case Types.INTEGER:  
       return Integer.class;  
case Types.BIGINT:  
return Long.class;  
 case Types.FLOAT:   case 
Types.DOUBLE:  
     return Double.class;  
  
     case Types.DATE:  
       return java.sql.Date.class;  
  
     default:  
       return Object.class;  
     }  
   }  
  
124  
  
 482.ЧДТУ. 2281-01 12 01  17   
   public boolean isCellEditable(int row, int column) {  
     return false;  
   }  
  
  public int getColumnCount() {    
 return columnNames.length;  
   }  
  
   // Data methods  
  
 public int getRowCount() {   return 
rows.size();  
   }  
public Object getValueAt(int aRow, int aColumn) {  
List row = (List) rows.get(aRow);  
 
   return row.get(aColumn);  
}  
public String dbRepresentation(int column, Object value) {  
     int type;  
  
  if (value == null) {    return "null";  
     }  
  
     try {  
       type = metaData.getColumnType(column + 1);  
125  
  
 482.ЧДТУ. 2281-01 12 01  18   
    } catch (SQLException e) {    
   return value.toString();  
     }  
  
  switch (type) {   case 
Types.INTEGER:   case 
Types.DOUBLE:   case 
Types.FLOAT:  
   return value.toString();   case Types.BIT:  
      return ((Boolean) value).booleanValue() ? "1" : "0";    
 case Types.DATE:       return value.toString(); // This will 
need some conversion.     default:  
     return "\"" + value.toString() + "\"";  
   }  
}  
 public  void  addSale(int  productId,  int  currentQuantity,  int  
quantityToSubstract, double d, Date currentDate)  
       throws SQLException {  
     double purchaseAmount = d * quantityToSubstract;  
     DateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd  
HH:mm:ss");  
     String date = dateFormat.format(currentDate).toString();  
  String query = "INSERT INTO sales (product_id, quantity, date, price, 
purchase_amount) VALUES ( " + productId  
         + ", " + quantityToSubstract + ", " + "'" + date + "'" + ", "  
+ d + ", " + purchaseAmount + ")";   
dbConnector.getStatement().executeUpdate(query);   int productFinalQuantity = 
126  
  
 482.ЧДТУ. 2281-01 12 01  19   
currentQuantity - quantityToSubstract;   query = "UPDATE product SET quantity = 
" + productFinalQuantity  
+ " WHERE  id =" + productId;    
 dbConnector.getStatement().executeUpdate(query);  
   }  
  
}   
127  
  
 
  
ДОДАТОК В  
  
  
  
  
  
  
  
Програмне забезпечення системи розрахунку оптимального розміру 
замовлення за моделлю Уілсона  
   
  
  
  
  
Інструкція користувачеві  
482. ЧДТУ 2281-01 34 01  
Листів 4  
  
  
  
  
 Розробник  ________________       Семенчук К.М.  
  
  
  
  
2023  
 
482. ЧДТУ 2281-01 34 01  
2  
  
Розглянута програмна система є Windows-програмою, і для свого 
нормального функціонування вимагає як мінімум такої конфігурації 
апаратних засобів, що забезпечує функціонування операційного середовища 
Windows – архітектура:  
При відкритті системи, адміністратор системи має можливість вносити 
дані по кількості товарів, які він придбав у постачальника та вводити дані по 
продажу товарів.  
4 
  
Рис. В.1 – Внесення даних по товару  
Якщо кількість товару, який знаходиться в компанії потрібно змінити, 
то потрібно натиснути кнопку «Змінити кількість товару» і відкриється 
діалогове вікно, в якому зі списку обирається тип товару та вводиться його 
кількість.  
  
Рис.В.2 – Зміна кількості товару  
Після вводу цих даних автоматично змінюються дані в полі по наявносто 
товару в компанії  
 
 
121  
  
482. ЧДТУ 2281-01 34 01  
3 
 
  
Рис. В.3 – Змінена кількість товару  
При продажу товару вводяться дані по продажі. Дані по покупцям не 
вводяться, тому що ця інформація не є необхідною для поставленої задачі в 
магістерській роботі.  
  
Рис. В.4 – Ввод даних по продажу товару  
122  
  
482. ЧДТУ 2281-01 34 01  
4  
Після вводу даних по продажу, данів полі товару в головному вікні 
адміністратора змінюються.  
  
Рис. В.5 – Змінені дані по продажу товару  
Наступним кроком є розрахунок параметрів по моделі Уілсона. Для 
розрахунків цих параметрів необхідно внести ще наступні додаткові дані: 
витрати за зберігання товару за місяць (вводиться користувачем), витрати на 
доставку товару, час доставки товару. Ці дані зберігаються в базі даних та 
відносяться до конкретного товару. Дані Продано за місяць розраховуються 
автоматично з бази даних.  
 
 
 
123  
  
482. ЧДТУ 2281-01 34 01  
5 
 
  
Рис. В.6 – Дані для розрахунку  
Якщо необхідно їх змінити, то потрібно натиснути кнопку змінити вхідні 
дані.  
  
Рис. В.7 – Зміна даних для розрахунку  
  
124  
  
 
  
  
ДОДАТОК Г  
  
  
  
  
  
  
  
Програмне забезпечення системи розрахунку оптимального розміру 
замовлення за моделлю Уілсона  
   
  
Графічні матеріали  
482.ЧДТУ. 2281-01 90 01  
Листів 10  
  
  
  
  
 Розробник  ________________       Семенчук К.М.  
  
  
 
  
  
  
2023  
 
482.ЧДТУ. 2281-01 90 01  
2  
  
   
  
Рис. Г.1 – Моделі управління запасами  
  
  
  
  
Рис. Г.2 – Вхідні параметри моделі Уілсона  
  
126  
  
482.ЧДТУ. 2281-01 90 01  
  3 
 
   
Рис. Г.3 – Вихідні параметри моделі Уілсона  
  
  
  
  
  
Рис. Г.4 – Розрахунок оптимального розміру замовлення  
  
127  
  
482.ЧДТУ. 2281-01 90 01  
4 
 
   
  
Рис.к Г.5 – Знаходження загальних витрат  
  
  
  
  
Рис. Г.6 – Визначення періоду доставки та точки замовлення  
  
   
128  
  
482.ЧДТУ. 2281-01 90 01  
5 
 
  
  
  
Рис. Г.7 – Засоби розробки  
     
  
  
  
Рис. Г.8 – Вікно внесення даних по товару  
  
129  
  
482.ЧДТУ. 2281-01 90 01  
6  
  
  
  
Рис. Г.9 – Вікно по продажу товару  
  
  
  
  
  
Рис. Г.10 – Вікно з розрахунком даних по моделі Уілсона  
130
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
