Репозиторій ЧДТУ
Репозиторій ЧДТУ зберігає і дозволяє легкий і відкритий доступ до всіх видів цифрового контенту, включаючи текст, зображення, анімовані зображення, MPEG і набори даних
Дізнатися більше
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/9083| Назва: | Програмне забезпечення логістичної системи розрахунку оптимальних витрат методом рішення транспортної задачі |
| Автори: | Первvнінський, Станіслав Михайлович Завіновський, Владислав Валерійович |
| Ключові слова: | логістика;транспортна задача;опорний план;оптимальні витрати;програмне забезпечення |
| Дата публікації: | 2023 |
| Короткий огляд (реферат): | Завіновський Владислав Валерійович, кваліфікаційна робота магістра на тему «Програмне забезпечення логістичної системи розрахунку оптимальних витрат методами рішення транспортних задач». Напрям підготовки 121 «Інженерія програмного забезпечення», ЧДТУ, Черкаси 2023. В даній кваліфікаційній роботі магістра проводяться дослідження логістичних процесів та їх застосування для побудови різних систем. В кваліфікаційній роботі магістра описано предметну область, структуру процесу управління логістикою, постановка транспортної задачі, методи пошуку опорного плану. Результатом роботи є побудована система рішення опорного плану з використанням методів мінімального елементу, північно-західного кута та метода Фогелю. Використані програмні засоби: JDBC, Java, MySQL, Spring Framework, Spring Security. |
| URI (Уніфікований ідентифікатор ресурсу): | https://er.chdtu.edu.ua/handle/ChSTU/9083 |
| Розташовується у зібраннях: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| Завіновський Владислав. Маг. 2022.pdf Restricted Access | 2.9 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«магістра»
освітній рівень
на тему: Програмне забезпечення логістичної системи розрахунку
оптимальних витрат методом рішення транспортної задачі
Виконав:студент 2 курсу, групи МПЗ-2104
Спеціальність:
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Завіновський В.В.
(прізвище та ініціали)
Керівник Д.т.н., проф., Первунінський С.М.
(прізвище та ініціали)
Рецензент
(прізвище та ініціали)
Черкаси 2023
Черкаський державний технологічний університет
Факультет інформаційних технологій і систем __________________________________
Кафедра програмного забезпечення автоматизованих систем ______________________
Освітній рівень магістр ______________________________________________________
Спеціальність 121 «Інженерія програмного забезпечення» ________________________
Освітня програма 121 «Інженерія програмного забезпечення» _____________________
ЗАТВЕРДЖУЮ:
Зав. кафедри _ ______Голуб С.В.
“_____” _______________20 __ р.
ЗАВДАННЯ
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
студенту Завіновському Владиславу Валерійовичу___________________________
(прізвище, ім’я, по батькові)
1. Тема проекту (роботи) Програмне забезпечення логістичної системи розрахунку
оптимальних витрат методом рішення транспортної задачі _______________________
Керівник проекту (роботи) Первунінський Станіслав Михайлович д.т.н._____________
професор (прізвище, ім’я , по батькові, науковий ступінь, вчене звання
затверджена наказом Черкаського державного технологічного університету від «14» жовтня
2022р. №275/04
2. Строк подання студентом (роботи) “02” грудня__2022_р.
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення, моделювання
процесів на етапі формування вимог, визначення транспортних задач, методи знаходження
оптимальних рішень транспортних задач._________________________________________
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити)
Існуючі методи та засоби розв’язання поставлених завдан______________________________
Теоретичні та експериментальні дослідження ________________________________________
Впровадження результатів досліджень у практику проектування програмного забезпечення
інформаційних систем ____________________________________________________________
Розробка та тестування програмного забезпечення_____________________________________
Висновки_______________________________________________________________________
_
Додатки ____________________________________________________________
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів) Задачі
дослідження.
Класифікація рішень.
Існуючі алгоритми вирішення завдання.
Структура системи
6.Дата видачі завдання _____02.09.2022р.________________________________
Календарний план
(прізвище, ініціали)
№ Назва етапів випускної магістерської Строк виконання етапів
Примітка
з/п роботи проекту (роботи)
1 Підготовча стадія вересень Виконано
1.1 Постановка задачі вересень Виконано
1.2 Підготовка завдання вересень Виконано
1.3 Погодження завдання вересень Виконано
1.4 Затвердження завдання вересень Виконано
2 Основна стадія жовтень Виконано
2.1 Підбір матеріалів вересень Виконано
2.2 Аналіз шляхів рішення поставленої задачі вересень Виконано
2.3 Оформлення первісної редакції роботи вересень Виконано
3 Заключна стадія листопад Виконано
Оформлення пояснювальної записки
3.1 роботи листопад Виконано
в кінцевій редакції листопад
3.2 Затвердження роботи грудень Виконано
3.3 Рецензування роботи грудень Виконано
Студент _______________ Завіновський В.В.
(підпис) (прізвище та ініціали)
Керівник _______________ Первунінський С.М
(підпис) (прізвище та ініціали)
АНОТАЦІЯ
Завіновський Владислав Валерійович, кваліфікаційна робота магістра на
тему «Програмне забезпечення логістичної системи розрахунку оптимальних
витрат методами рішення транспортних задач». Напрям підготовки 121
«Інженерія програмного забезпечення», ЧДТУ, Черкаси 2023.
В даній кваліфікаційній роботі магістра проводяться дослідження
логістичних процесів та їх застосування для побудови різних систем. В
кваліфікаційній роботі магістра описано предметну область, структуру
процесу управління логістикою, постановка транспортної задачі, методи
пошуку опорного плану.
Результатом роботи є побудована система рішення опорного плану з
використанням методів мінімального елементу, північно-західного кута та
метода Фогелю.
Використані програмні засоби: JDBC, Java, MySQL, Spring Framework,
Spring Security.
Ключові слова: логістика, транспортна задача, опорний план,
оптимальні витрати, програмне забезпечення.
ANNOTATION
Zavinovskyi Vladyslav Valeriyovych, master's qualification thesis on the
topic "Software support of the logistics system for calculating optimal costs by
methods of solving transport problems." Field of training 121 "Software
engineering", ChSTU, Cherkasy 2023.
In this master's qualification, research is carried out on logistics processes and
their application for the construction of various systems. The master's qualification
work describes the subject area, the structure of the logistics management process,
the formulation of the transport problem, methods of finding a reference plan.
The result of the work is a built system of the solution of the reference plan
using the methods of the minimum element, the northwest corner and the Vogel
method.
Used software tools: JDBC, Java, MySQL, Spring Framework, Spring
Security.
Keywords: logistics, transport problem, reference plan, optimal costs,
software.
ЗМІСТ
СПИСОК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ………………………4.
ВСТУП…………………………………………………………………………………….5
1.ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ………………………………………………………………………………....9
1.1 Базові підходи до організації логістичних завдань………………………………...9
1.2 Основні функції логістичних процесів……………………………………21
Висновки до першого розділу………………………………………………………….27
2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ ……………………28
2.1 Теоретичні дослідження…………………………………………………...……….28
2.1.1 Узагальнення поняття логістики ………………………………..………………28
2.1.2 Представлення транспортної задачі ……………………………….…………….32
2.2 Експериментальні дослідження…………………………………………………….34
2.2.1 Метод північно-західного кута…………………………………………………...34
2.2.2 Метод мінімального елемента………………………………....…………………38
2.2.3 Метод Фогеля ………………………………………………….………................41
Висновки до другого розділу…………………………………………………………. 46
3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ…………………………………………………………………………………48
3.1 Моделювання предметної області………………………………………………… 48
3.1.1 Предметна область моделювання. ………………………………………………48
3.1.2. Модель предметної області. Словник предметної області…………………….53
3.1.3 Елементи моделювання предметної області…………………………………….54
3.1.4. Робоча область моделювання……………………………………………………55
3.2 Формування та аналіз вимог до програмного забезпечення………………...........56
3.2.1 Первинні і детальні вимоги………………………………………………………56
3.2.2 Вимоги замовника і розробника………………………………………………….58
3.2.3 Функціональні і нефункціональні вимоги. ……………………………………..58
3.2.4. Формування вимог за допомогою діаграми прецедентів………………………59
3.2.5. Проектування логічної структури програмного комплексу …………………63
3.2.5.1 Діаграма класів…………………………………………………………………..63
3.2.5.2 Діаграма пакетів…………………………………………………………………66
3.3 Архітектурне проектування………………………………………………………..68
3.3.1 Діаграма компонентів…………………………………………………………….68
3.3.2 Діаграма розгортання…………………………………………………………….69
3.3.3 Моделювання поведінки системи……………………………………….............70
3.3.3.1 Діаграма діяльності……………………………………………………..………70
3.3.3.2 Діаграма послідовності…………………………………………………………72
3.3.3.3 Діаграма комунікації…………………………………………………………....73
ЧДТУ. 2278.003 ПЗ
Зм. Лист № докумемента Підпис Дата
Розроб. Завіновський В.В. Літ. Лист Листів
Програмне забезпечення логістичної
Керівник Первунінський С. М. 6 1
системи розрахунку оптимальних
витрат методом рішення транспортної ФІТІС, кафедра ПЗАС,
Н.контр. Півень О. задачі
Затв. Голуб С.В. (Пояснювальна записка ) гр. МПЗ-2104
3.3.3.4 Діаграма скінченого автомату………………………………………………....74
Висновки до третього розділу…………………..…………………………….... ……77
4. КОНСТРУЮВАННЯ ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
…..………………………………………………………………………………………..78
4.1 Обґрунтування вибору засобів реалізації …………..…………………..…………78
4.2. Опис структурної (функціональної) схеми……………………………………….80
4.3. Опис логічної схеми системи………………………………………………………82
4.4 Розробка бази даних………………………………………………………………...83
4.5. Опис інтерфейсу користувача…………..…………………………………………83
4.5. Опис розробки програмних компонентів…………………………………………86
4.6 Тестування системи…………………………………………………………………89
4.6.1 Модульне тестування …………………..……………………………….……..…89
4.6.2 Інтеграційне тестування…………………………………………………………..91
4.6.3 Системне тестування……………………………………………………………...93
4.6.4 Приймальне тестування…………………………………………………………..94
Висновки четвертого розділу………………………………………………….………..96
ЗАГАЛЬНІ ВИСНОВКИ……………………………………………………….….........97
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ……………………………………..……….98
ДОДАТКИ………………………………………………………………………….......101
Лист
ЧДТУ. 2278.003 ПЗ
Зм. Лист № документа Підпис Дата
ЧДТУ. 2278.003 ПЗ
СПИСОК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ
SQL – Structured query language – мова структурованих
запитів
БД – база даних
Гб – гігабайт, кратна одиниця виміру кількості
інформації, що дорівнює 1024 мегабайтам
JSP – технологія, що дозволяє веб-розробникам
динамічно генерувати HTML, XML та інші
вебсторінки
ПЗ – програмне забезпечення
ПП програмний продукт
СУБД – система управління базами даних
ТЗ – технічне завдання
Spring універсальний фреймворк з відкритим вихідним
кодом для Java-платформи
4
ЧДТУ. 2278.003 ПЗ
ВСТУП
Актуальніcть теми. Розвиток товарного ринку в будь-якій країні визначає
збільшення обсягів виробництва та споживання товарів, прискорення процесів
руху товару та товарообміну. Прагнення виробників товарів отримати економію
на зниженні часу зберігання, доставки товарів до споживачів при збереженні їх
у найбільш привабливому для продажу вигляді реалізується за допомогою єдиної
транспортної системи, що обслуговує рух товарних мас, що виробляються, у
вигляді матеріальних вантажопотоків. Вимоги клієнтури в сучасних умовах
найефективніше задовольняються на базі створення логістичних систем, де дії
всіх учасників операції з транспортування, а також всі супутні операції
виконуються як єдине ціле на основі принципів системного підходу.
Узгодженість дій та інтересів усіх учасників логістичних систем забезпечує
розробку оптимальних маршрутів, графіків, способів доставки, ефективне
використання транспортних засобів, економію часу, грошей та інших ресурсів за
максимально високого рівня обслуговування клієнтів. У сучасних економічних
умовах транспорт перестає бути відокремленою галуззю економіки та постає як
виробник широкого спектру логістичних послуг – і одноопераційних
(транспортування), і комплексних (транспортно-експедиційне обслуговування).
З розвитком логістики збільшується роль великих логістичних операторів
змішаного перевезення вантажів як координаторів діяльності всіх учасників
переміщення матеріальних потоків, узгодження їх інтересів, але вже ширших
масштабах. Коли доставка товару до споживача здійснюється комбінуванням
перевезень з перевалкою на різні види транспорту, це вимагає ретельної
підготовки товару на завершальному етапі його виробництва, при упаковці,
маркування, укладання, етикетуванні, формуванні партій, розробці графіків
поставки, розкладів подачі та рухи транспортних засобів; при цьому необхідна
чітка організація перелічених та багатьох інших процесів та операцій. Наявність
та розвиток логістичних функцій у традиційній транспортно-експедиційній
діяльності є показником освіти, розвитку логістичних систем та фактором
5
ЧДТУ. 2278.003 ПЗ
забезпечення їх стійкості та надійності, оскільки рівень та якість обслуговування
в них у багато разів вищий, ніж при наданні лише транспортних чи лише
експедиторських послуг. Розвиток логістики характерний для стійких, стабільно
функціонуючих транспортних ринків, він заснований на здатності
використовувати сучасні технології, досягнення науково-технічного прогресу,
вмінні концентрувати потужності та ресурси.
Більш жорстка координація та контроль взаємодії елементів у логістичній
системі забезпечують можливість отримання економії на доставці, зниженні
величини транспортної складової у загальній ціні товару, що зрештою
позначається на зниженні ціни споживання товарів та збільшенні обсягів
реалізації продукції та послуг. Виконання комплексного транспортно-
логістичного обслуговування потребує сучасної розвиненої інфраструктури,
найважливішими елементами якої є:
- комплексні складські системи та термінали;
- частково або повністю автоматизовані системи розміщення товарів;
- механізовані та автоматизовані установки для завантаження та
розвантаження транспортних засобів;
- системи стеження за вантажами в дорозі;
Розрізняють такі форми взаємодії учасників перевізного процесу:
- технологічна форма забезпечує безперервність процесу доставки,
узгоджене та раціональне використання рухомого складу, прогресивність
технологій, що використовуються на суміжних видах транспорту;
- технічна форма визначає уніфікацію та стандартизацію узгодженості
дій, ефективність використання рухомого складу;
- економічна форма взаємодії є базою для пошуку резервів зниження
витрат на функціонування логістичної системи, визначення необхідного
ресурсного потенціалу, формування можливостей майбутнього розвитку,
вивчення потреб клієнтури та управління ними. Оскільки в основу організації
узгодженої роботи видів транспорту, що беруть участь у змішаному перевезенні,
6
ЧДТУ. 2278.003 ПЗ
покладено принцип доставки «від дверей до дверей», то дотримання цього
принципу передбачає поряд із забезпеченням координації видів транспорту
координацію діяльності вантажовласників у виконанні допоміжних робіт,
супутніх перевізному процесу.
Для цього можуть використовуватись такі методи:
- організаційно-управлінські (створення рад та організацій з координації
діяльності, єдиної інформаційної системи документообігу та обробки
замовлення тощо);
- економічні (визначення наскрізної тарифної ставки та формування
єдиної системи ціноутворення, уніфікація товарної та супровідної документації,
запровадження єдиної уніфікованої номенклатури вантажів);
правові (запровадження єдиного правового регулювання комерційних
взаємин клієнтури та виробників, визначення та розмежування відповідальності
за виконання доставки в обумовлених умовах).[18]
Мета роботи: підвищення ефективності методик розробки програмного
забезпечення інформаційної системи розрахунку оптимальних витрат методом
рішення транспортної задачі.
Завдання дослідження:
1 Дослідження предметної області.
2 Математичне моделювання процесів побудови оптимального шляху
переміщення транспорту у заданих умовах. Висунення гіпотез.
3 Експериментальна перевірка висунутих гіпотез.
4 Дослідження процесів об’єктно-орієнтованого проектування
програмного забезпечення інформаційної системи для підтримки лоністики
транспортного підприємства
5 Розробка методики проектування програмного забезпечення
інформаційної системи логістичного забезпечення транспортного підприємства.
Об’єкт дослідження: процес об’єктно-орієнтованого проектування
програмних систем.
7
ЧДТУ. 2278.003 ПЗ
Предмет дослідження: теоретичні, формальні методи та відповідні засоби
побудови методики проектування програмного забезпечення інформаційної
системи логістичного забезпечення транспортного підприємства.
Методи досліджень:
- метод мінімального елементу;
- метод північно-західного кута;
- метод Фогеля.
Наукова новизна отриманих результатів удосконалено метод об’єктно-
орієнтованого проектування програмних систем за рахунок використання
удосконаленого методу вирішення транспортної задачі на етапі моделювання
предметної області та нової процедури формування вимог до програмного
забезпечення інформаційної системи логістичного забезпечення транспортного
підприємства. Це дозволяє підвищити ефективність рішень із прокладання
маршрутів руху транспорту в заданих умовах.
Практична значимість одержаних результатів
Отримані результати дозволяють розробляти методики об’єктно-
орієнтованого проектування та конструювання програмного забезпечення
інформаційної системи логістичного забезпечення транспортного підприємства
для різних умов роботи.
Особистий внесок автора
Розроблено програмне забезпечення вирішення транспортної задачі з
використанням математичних методів.
Апробація результатів кваліфікаційної роботи магістра
Первунінський С.М., Завіновський В.В. Тези доповіді на II Міжнародній
студентській науковій конференції «Тренди та перспективи розвитку
мультидисциплінарних досліджень» (25.11.2022, м. Хмельницький, Україна) на
тему «Актуальність розробки логістичної системи розрахунку оптимальних
витрат»
8
ЧДТУ. 2278.003 ПЗ
РОЗДІЛ 1
ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ
1.1 Базові підходи до організації логістичних завдань
Тенденції розвитку внутрішньо і торгівлі є одним із наочних індикаторів
економічного розвитку держави. Внутрішня торгівля займає особливе місце в
економічній системі України та в її соціальній сфері.
Метою роботи є дослідження сучасних тенденцiй розвитку внутрішньої
торгівлі в Україні. Вивченням цього питання також займалася значна кількість
фахівців, серед яких праці Л.О. Омелянович, Н.І. Яркової, І.В. Сороки, А. Кріє,
Ж. Жаллє та інших. Сьогодні ця проблема є досить актуальною.[1]
Внутрішня торгівля характеризується наявністю домінуючої частки
приватного капіталу, сталою позитивною динамікою обсягу роздрібного
товарообороту, збільшенням чисельності приватних підприємців.
У 2008 році обсяг реального валового внутрішнього продукту становив
949,8 млрд. гривень, а оборот роздрібної торгівлі – 449,3 млрд. гривень. Проте на
сьогодні темпи збільшення обороту роздрібної торгівлі у порівнянних цінах
уповільнилися на 14,3 відсотка через зменшення обсягу споживчого попиту,
зумовлене уповільненням зростання реальних доходів населення та
підвищенням вартості імпортної продукції внаслідок істотної девальвації
національної валюти.
За темпами підвищення валової до даної вартості у 2008 році торгівля
посідала третє місце серед галузей економіки. Площа торговельних об'єктів
збільшилася за останні п'ять років на 35,3 відсотка, зокрема у містах - на 52
відсотки, за рахунок відкриття нових великих магазинів. Протягом останніх п'яти
років населення надавало перевагу стаціонарним торговельним об'єктам.
Кількість роздрібних ринків за зазначений період зменшилася на 3 відсотки.
Питома вага реалізації товарів на ринках скоротилась у 2008 році до 26,3 відсотка
обсягу продажу споживчих товарів.
9
ЧДТУ. 2278.003 ПЗ
У 2008 році оптовий товарооборот одного такого підприємства становив у
середньому 14,5 млн. гривень. При цьому на 14,1 відсотка оптових торговельних
підприємств припадає основна частка оптового товарообороту (92 відсотки).
Зазначені підприємства не мають достатньої кількості сучасно обладнаних
складів, на яких упроваджено новітні технології складської обробки товарів.
Станом на 1 січня 2009 р. лише 8,5 відсотка підприємств мали власні склади.
На нашу думку, спостерігається збільшення товарообороту між оптовими
торговельними підприємствами, що призводить до зростання роздрібних цін.
Зберігається стійка тенденція до зменшення кількості юридичних осіб, що
провадять діяльність у сфері роздрібної торгівлі та ресторанного господарства, у
зв'язку з переходом до оподаткування за спрощеною системою та одночасним
збільшенням кількості фізичних осіб – підприємців.
Стратегічними цілями розвитку внутрішньої торгівлі України є:
- задоволення потреби населення, зокрема малозабезпечених верств, у
високоякісних товарах та послугах, запобігання необґрунтованому зростанню
цін на споживчому ринку, в тому числі на соціально значущі продовольчі товари;
- запровадження сучасних стандартів торговельного і побутового
обслуговування;
- розвиток конкуренції у сфері оптової та роздрібної торгівлі;
- оптимізація і структурна перебудова торговельної мережі;
- урегулювання відносин, пов'язаних з організацією та функціонуванням
роздрібних ринків, створення умов для продажу
сільськогосподарської продукції безпосередньо її виробниками;
- удосконалення системи показників статистичного спостереження за
діяльністю підприємств торгівлі;
- поліпшення іміджу робітничих професій у сфері торгівлі та послуг,
удосконалення системи підготовки спеціалістів вищими та
професійнотехнічними навчальними закладами; - налагодження соціального
діалогу між громадськими, профспілковими об'єднаннями, організаціями
10
ЧДТУ. 2278.003 ПЗ
роботодавців у сфері торгівлі, центральними та місцевими органами виконавчої
влади [2].
Розглянемо розвиток сучасної логістики.
Серед основних причин і тенденцій розвитку сучасної логістики можна
виділити наступні вісім.
1 Значно виросла вартість транспортних послуг. Транспорт перестав
вважатися стабільним фактором бізнесу, у проблемах логістики, зв'язаних із
транспортом, потрібно було здійснювати менеджмент більш високого рівня,
причому одночасно як на рівні поточних операцій, так і на рівні політики,
2 Ефективність виробництва досягла максимуму. Стало важко домагатися
додаткової економії коштів, оскільки весь прибуток формувався у виробництві.
Але фізичний розподіл і логістика були фактично недослідженими областями з
погляду прибутковості й ефективності,
3 Відбулися фундаментальні зміни у філософії товарно-матеріальних
запасів.
4 Асортимент товарів істотно розширився. Кількість одиниць обліку
запасів росл з експонентним законом, що значно ускладнювало ефективне
управління запасами.
5 Відбулися революційні зміни у сфері виробництва комп'ютерів і
комунікаційних технологій, що сприяло здійсненню логістичного підходу,
побудованого на безлічі облікових елементів і оперуючого великими обсягами
даних.
6. Використання комп'ютерів у світі бізнесу постійно розширюється.
У багатьох фірм з'явилася можливість систематично вивчати якість
сервісу, що їм надають постачальники Проводячи такого роду аналіз, багато
фірм одержали можливість модернізації своїх систем розподілу.
7 Громадськість звернула увагу на проблеми забруднення навколишнього
середовища і повторного використання відходів (рециклінг). Ці проблеми
11
ЧДТУ. 2278.003 ПЗ
зв'язані з логістикою, оскільки мова йде про пакувальні матеріали і про
створення каналів повернення відходів для переробки.
8 З'явилися нові, великі мережі роздрібного продажу і торговельні фірми
масового продажу з дуже складними логістичними системами. Крім центрів
масової торгівлі, з'явилися також мережі великих спеціалізованих магазинів, що
процвітають багато в чому завдяки добре відпрацьованим логістичним системам.
Сучасний етап розвитку логістики характеризується створенням великої
кількості професійних організацій. Це зв'язано з тим, що мистецтво логістики
розвивається настільки стрімко й швидко, що професіоналам приходиться
постійно займатися самоосвітою. [3]
Глобальна господарська діяльність — це поки ще освоювана «територія»,
для якої характерна зростаюча потреба в логістичному менеджменті. Компанії
виходять на світовий ринок, спонукувані прагненням до ринкового росту,
бажанням скористатися дешевими або високоякісними робочою силою,
сировинними ресурсами, виробничими потужностями. З розширенням
міжнародної торгівлі відповідно збільшуються і потреби логістики в міру
подовження логістичного ланцюжка, росту невизначеності, збільшення обсягу
необхідної документації. Але а той час, як ці руйнівні сили спонукують компанії
до подолання національних меж, логістичні менеджери як і раніше
зіштовхуються з ринковими і фінансовими бар'єрами, перешкодами,
обумовленими каналами розподілу. Усю сукупність подібних бар'єрів описує
формула чотирьох «Д» — дальність перевезень, диктат І споживчого попиту,
розподіл культур, документація. Задача логістики — створити такі умови, що
дозволили б компаніям витягати максимальні вигоди з глобального виробництва
і маркетингу, підтримуючи ефективний рівень витрат і сервісу.
Підходи фірм до міжнародної діяльності варіюють від вузьконаціональної
спрямованості до так називаної компанізації (орієнтації на створення
«підприємства без громадянства»).
12
ЧДТУ. 2278.003 ПЗ
Фірми, що коштують на національних позиціях, розглядають будь-яку
міжнародну діяльність тільки як експортно-імпортні операції, у яких беруть
участь незалежні організації, навіть якщо останні знаходяться у власності одного
власника. При такому підході компанії стурбовані тим, щоб прийняті ними
виробничі і логістичні рішення були оптимальні для операцій у конкретній
країні, але не для глобальної діяльності. Логістичні менеджери національне
орієнтованих компаній обмежені у виборі джерел постачань, перевізників,
партнерів для створення союзів.
Підхід до міжнародної діяльності з позицій «підприємства без
громадянства», навпроти, означає, що компанія націлена на надання споживачам
унікальних, ефективних за витратами послуг з доданою вартістю на усіх світових
ринках. «Підприємства без громадянства» готові користуватися будь-якими
світовими джерелами сировини і послуг, де б вони не знаходилися. Вибір таких
джерел визначається в даному випадку найбільш вигідної споживацькою
вартістю. Підхід з позицій «підприємства без громадянства» збільшує нестаток
у логістичному менеджменті, тому що вимагає аналізу більш широкого кола
варіантів і менш централізованого прийняття рішень. Під впливом глобалізації
економіки усе більше фірм переходить на позиції «підприємства без
громадянства». Це ставить ще більш відповідальні задачі перед логістичним
менеджментом.
У процесі глобалізації господарської діяльності компаній можна виділити
п'ять етапів або рівнів: 1-ий та 2-ий (збереження дистанції І самостійний експорт)
- у проведенні закордонних операцій компанії покладаються на сторонніх
посередників. Ризик і потенційні вигоди міжнародної діяльності фірми на цих
етапах мінімальні.
3-ій та 4-ий (самостійні закордонні операцій і укорінення бізнесу за
рубежем) - компанії починають розвивати місцеві підприємства на зовнішніх
ринках.
13
ЧДТУ. 2278.003 ПЗ
5-ий (денаціоналізації) - фірми створюють регіональні штаб-квартири, що
відповідають за операції на окремих національних ринках і в той же час - за такий
вибір джерел ресурсів і прийняття таких логістичних рішень, що приносили б
оптимальні результати компанії в цілому.
Еволюція світової економіки привела до виникнення трьох регіональних
торговельних об'єднань - ЄС, НАФТА й АФТА, призначених для розвитку
регіональної торгівлі і підвищення конкурентноздатності відповідного регіону
на світовому ринку. Програма ЄС 92 дозволила європейським країнам далі всіх
просунутися на шляху інтеграції (аж до валютного союзу). Представникам
Азіатського і Північноамериканського регіонів — хоча в них і не було такої
Історичної передумови Інтеграції, як загальний ринок, — удалося швидко
досягти угод про створення зон вільної торгівлі. Менш розвинуті країни Східної
Європи І Латинської Америки швидше за все згодом приєднаються до ЄС і
НАФТА відповідно.
Глобальна логістика підкоряється тим же законам, що і внутрінаціональна,
але світовий ринок висуває перед логістикою особливі задачі.
По-перше, функціональний цикл глобальної логістики більш тривалий
через більш далекі відстані, які потрібно перетинати, більшого числа
посередників і необхідності використовувати для багатьох вантажоперевезень
повільний океанський транспорт.
По-друге, самі логістичні операції на світовому ринку складніші внаслідок
більшої розмаїтості одиниць збереження і запасів у цілому, з якими приходиться
мати справу, більш великої документації, більшого числа необхідних складських
потужностей і щодо менш розвинутої системи логістичних послуг {зокрема,
транспортних і складських).
По-третє, на глобальному рівні підвищуються вимоги до інформаційних
систем, оскільки зростає потреба в протяжних каналах зв'язку, використанні
різних мов і підтримці гнучкості логістичних процесів.
14
ЧДТУ. 2278.003 ПЗ
І по-четверте, на світовому ринку не обійтися без глобальних виробничих,
логістичних і маркетингових союзів, створення і розвиток яких теж складає
непросту задачу.
Такі союзи відкривають компаніям доступ до знань про місцеві ринки і
забезпечують економію операційних витрат, однак установлення глобальних
партнерських відносин і управління ними самі по собі вимагають значних
зусиль. Створенню подібних союзів повинне сприяти розвиток інтегрованих
розподільних і транспортних мереж. Перераховані задачі збільшують потреби в
логістичному менеджменті, оскільки для їхнього рішення потрібні велика
чутливість до запитів ринку й облік більш різноманітних альтернатив.
Глобальні маркетингові і логістичні операції дозволяють компаніям
домогтися ринкового росту, значної економії за рахунок масштабів діяльності і
підвищення прибутковості. На світовому ринку підсилюється роль логістики і
зростає значення логістичного менеджменту. Логістика, у свою чергу, повинна
відповідати на це зусиллями, спрямованими на виявлення всіх наявних ринкових
можливостей і удосконалювання системи прийняття рішень [13].
Сьогодні інформаційні технології є головним джерелом росту
продуктивності і конкурентноздатності. На відміну від більшості інших
технологій, потужність і швидкість обробки інформації, збільшуючись,
дешевшають. При всьому різноманітті новинок у сфері інформації п'ять з них
особливо важливі для логістики [14]:
1 Електронний обмін даними.
2 Персональні комп'ютери.
3 Системи штучного інтелекту.
4 Супутникові системи зв'язку.
5 Технологія штрихового кодування і сканування.
Електронні системи обміну даними забезпечують оборот
стандартизованих документів між комп'ютерами різних компаній і заміняють
такі традиційні форми зв'язку, як пошта, пересилання з нарочним і навіть факси.
15
ЧДТУ. 2278.003 ПЗ
Прямі вигоди електронного обміну даними полягають у; 1
Підвищенні продуктивності праці.
1 Зміцненні господарських зв'язків з постачальниками і споживачами.
2 Підвищенні міжнародної конкурентоздатності.
3 Зниженні операційних витрат.
Продуктивність росте в силу того, що передача інформації прискорюється
й у її одержанні і поширенні бере участь менше число людей. До речі, ті ж
фактори сприяють підвищенню точності інформації.
Електронні засоби зв'язку забезпечують зниження витрат завдяки тому,
що:
1 Скорочуються трудові і матеріальні витрати на підготовку,
розмноження, розсилання всіляких документів.
2 Скорочується обсяг повідомлень, переданих по каналах телефонного,
факсового і телексного зв'язку.
3 Скорочуються канцелярські витрати в цілому.
У сьогоднішній логістиці персональний комп'ютер (ПК) поширився майже
повсюдно. Завдяки мініатюризації і підвищенню потужності обчислювальної
техніки сучасні інформаційні технології стали доступні не тільки менеджерам.
Можна виділити три аспекти впливу ПК на логістичний менеджмент:
По-перше, дешеві і легко переміщувані ПК дають можливість одержувати
оперативну інформацію не тільки в офісі, але і на складі й у дорозі. У минулому
рішення приходилося приймати на основі інформації, що застаріла на години І
навіть на дні. Тепер і стратегічні, і тактичні рішення можна приймати,
спираючись на свіжу інформацію. Безліч прикладів свідчить про те, що
своєчасна інформація істотно підвищує ефективність роботи складів і
перевізників.
По-друге, ПК збільшують швидкість і точність реакції виконавців. що
сприяє росту якості й ефективності сервісу Доступні колись масивні стаціонарні
комп'ютери створювали розрив між тими, хто приймає рішення, і безпосередніми
16
ЧДТУ. 2278.003 ПЗ
виконавцями. Щоб не ризикувати через ненадійність передачі даних, менеджери
воліли працювати по старинці, вручну. Поява комп'ютерних мереж (локальної і
глобальних) і мережної конфігурації клієнт/ сервер відкриває шлях до інтеграції
інформаційних потоків, що дає можливість використовувати вигоди
децентралізації, гнучкості і достатку інформаційних ресурсів. У локальних
комп'ютерних мережах каналами зв'язку для обміну інформацією між
комп'ютерами і спільним користуванням принтерами і пам'яттю служать
телефонні лінії або кабелі. Локальні мережі звичайно охоплюють межі офісу або
складу, а для більш широких географічних зон потрібні інші мережні рішення.
Мережка конфігурація клієнт/сервер зберігає автономність і гнучкість, властиву
локальним мережам. Сервер - це могутній комп'ютер, призначений для спільного
користування й обміну даними між багатьма учасниками. «Клієнт» — це мережа
ПК, яка має доступ до даних і можливість автономної роботи з ними, що додає
додаткову гнучкість.
По-третє, ПК здатні працювати з графічними програмами в
інтерактивному режимі, полегшують освоєння систем підтримки прийняття
рішень із приводу розміщення логістичних потужностей, аналізу запасів,
маршрутизації і складання графіків перевезень. З появою ПК число і
функціональні можливості програмних додатків до таких систем різко
розширилися. Використання інтерактивної графіки і стандартизованих форматів
аналізу уможливили ефективну оцінку варіантів логістичних рішень. Щорічно
публікуються огляди доступного програмного забезпечення
Штучний інтелект (ШІ) і експертні системи (ЕС) — ще один різновид
інформаційних технологій, що знайшли застосування в логістиці.
Узагальнюючим терміном штучний інтелект позначають групу технологій,
націлених на відтворення в комп'ютерах особливостей людського мислення.
Характерна риса ШІ — операції із символами, а не з числами, До складу ШІ
входять експертні системи; програми-перекладачі з однієї мови на іншу;
17
ЧДТУ. 2278.003 ПЗ
програми, що Імітують роботу нейронних мереж; робототехніка; технології
розпізнавання мовних сигналів і тривимірного відтворення зорових образів.
Поки в логістиці знайшли застосування тільки експертні системи.
Експертні системи являють собою економічний і спосіб виявлення,
уточнення і поширення передового досвіду управлінських рішень. Ці системи
забезпечують єдину схему оформлення питань і відповідей, використовуваних
експертами для рішення аналітичних і оперативних проблем. Експертні системи
дозволяють зробити знання одного фахівця надбанням багатьох працівників, що
збільшує погодженість, точність і продуктивність операцій за всією мережею. Ці
системи створюють можливості для більш ефективного управління
найважливішим для будь-якої організації ресурсом – знанням[15].
Програмне забезпечення експертних систем у логістиці створює і
накопичує логістичну «базу знань» у формі евристичних правил, загальних
принципів прийняття рішень, контрольних параметрів і логічних схем зовсім так
само, як звичайні комп'ютерні програми накопичують числову інформацію в
базах даних. При цьому програмне забезпечення експертних систем набагато
легше піддається відновленню, модифікації і розширенню, ніж звичайні
комп'ютерні програми.
У логістиці ЄС знаходять застосування в тих випадках, коли накопичені
досвід і знання здатні підвищити рентабельність активів. У число задач,
розв'язуваних за допомогою ЕС, входять вибір перевізників, міжнародний
маркетинг і глобальна логістика, управління запасами і проектування
інформаційних систем.
Удосконалювання засобів зв'язку значно підвищує ефективність
інформаційних технологій у логістиці. У минулому комунікаційні можливості в
логістиці були досить обмежені в силу децентралізації операцій постачання і
збуту і нездатності підтримувати постійний зв'язок із транспортними засобами е
шляху (так що в процесі транспортування і вантажопереробки працівникам
доводилось покладатися тільки на попередні інструкції, з менеджерам —
18
ЧДТУ. 2278.003 ПЗ
сподіватися на те, що ніякі непередбачені події не порушать намічений порядок
дій). Іншими словами, через недосконалість техніки між джерелами інформації,
виробленням розпоряджень і реальних операцій існував просторово-часовий
розрив. Ситуацію змінила поява низькочастотних радіотелефонів,
супутникового зв'язку і технології обробки графічної інформації.
Система Logist.ua включає функції планування, GPS-моніторингу та
керування транспортом підприємства. Вона має модульну структуру – залежно
від того, які процеси треба оптимізувати і в яких масштабах, для впровадження
вибирається один або кілька модулів. Модуль «Планування» дозволяє
проаналізувати усі ввідні дані для розрахунку маршрутів доставки і на цій основі
спланувати оптимальні рейси, що враховують усі особливості автомобілів і
доріг, графіки роботи клієнтів, пріоритети та інше. Модуль «Моніторинг» за
допомогою системи GPS-навігації дозволяє відстежувати рух транспорту в
реальному часі, зіставляти по карті фактичний маршрут кожної машини із
запланованим. А також фіксувати всі події, що відбуваються з автомобілем:
відхилення від маршруту, затримки в часі, відвідування точок призначення і
запізнення. За необхідності диспетчер може вчасно скоригувати дії водіїв.
Мобільні додатки Logist.ua дають можливість здійснювати планування і
моніторинг рейсів за допомогою мобільних пристроїв.
Користувачі: «Ясен», корпорація «Алмі», банк «Новий», Kuehne + Nagel
Ltd., «Автозвук», «АРДА-Трейдинг», «Агромарс» (ТМ «Гаврилівські
курчата»), Acme Color.
19
ЧДТУ. 2278.003 ПЗ
Рис. 1.1 – Вікно розподілення маршрутів системи Програмний аналог
«Rational Logistics».
Українська компанія Rational Logistics розробили власне ПЗ для
автоматизації бізнес-процесів у логістиці. Система оптимізує не кілометраж або
час, а собівартість доставки. Окрім цього, вона може бути легко інтегрована з
будь-якою обліковою системою, що дозволяє переносити дані з однієї програми
в іншу. В якості GPS-трекерів можна використати планшети або смартфони на
ОС Android. Мобільний додаток дозволяє вести облік зібраної готівки на
маршруті, а також ввести зрозумілі KPI для водіїв: своєчасність доставок,
кількість доставок, час роботи на маршрутах. За словами розробників, в системі
використовується найактуальніша карта, що забезпечує надійність побудованих
маршрутів. Карта максимально актуальна, оскільки її постійно коригує велика
кількість користувачів. За допомогою цієї програми користувачі можуть
скоротити витрати на транспортну логістику шляхом оптимізації маршрутів і
зменшення часу обслуговування точок на маршрутах.
Рис. 1.2 – Вікно розподілення маршрутів системи
1.2 Основні функції логістичних процесів
Концепція логістики допомагає змінити ситуацію на підприємстві,
впроваджуючи нові технології зниження витрат за багатьма показниками.
Більше того, вона дозволяє підвищити рівень обслуговування клієнтів та
вдосконалити відносини між підрозділами у компанії. На жаль, на вітчизняних
20
ЧДТУ. 2278.003 ПЗ
підприємствах логістика найчастіше сприймається лише як організація
транспортування та складування.
Отже, відбувається підміна понять. Склад або відділ постачання можуть
просто перейменувати на відділ логістики, але для компанії це нічого не змінює,
тому що використовується лише інструмент логістики, а не логістична концепція
в цілому. Тому методологія управління матеріальними, інформаційними та
фінансовими потоками спрощується або зовсім сходить нанівець.
Для скорочення логістичних витрат підприємства відділ логістики повинен
аналізувати весь ланцюжок поставок. При ефективної організації роботи відділу
логістики вирішується як проблема зайвих витрат, а й скорочується кількість
міжфункціональних конфліктів між відділами підприємства, зменшуються
страхові запаси, прискорюється оборотність капіталу, знижується собівартість
продукції і на логістичних витрат у дистрибуції, з'являється можливість
забезпечити відповідність можливостей компанії вимогам споживачів товарів та
рівню послуг [7].
Основними завданнями логістики є:
• Збір, акумулювання, аналіз та передача інформації про рух матеріальних
потоків;
• Планування формування та утримання матеріальних запасів на
підприємстві;
• Вибір та обґрунтування найкращого розташування таких логістичних
об'єктів як проміжний склад, розподільчий центр, оптова база та інші на
логістичному полігоні;
• Управління складською діяльністю у необхідному клієнтом форматі;
• Упаковка продукції з урахуванням вимог щодо постачання та
збереження її якості;
• Вибір типу та виду транспортних засобів для постачання продукції
споживачеві;
• Вибір оптимальних маршрутів доставки продукції споживачам [17, 23].
21
ЧДТУ. 2278.003 ПЗ
Основний керований логістичною системою компонент – матеріальний
потік, утворюється під час роботи безлічі різних підприємств, які виробляють чи
споживають продукцію. Розглянемо підприємства, які грають ключову роль
управлінні матеріальними потоками:
• Експедиційні фірми, транспортні компанії загального користування;
• Посередницькі компанії, що надають послуги з організації оптового
продажу;
• Підприємства оптової торгівлі, які здійснюють комплекс логістичних
операцій із продукцією;
• Виробники, що виконують різноманітні логістичні операції з ходу
виробництва, транспортування та складування.
Саме ці підприємства створюють та контролюють матеріальні та супутні
потоки. Здійснення логістичних функцій розподіляється між учасниками
логістичного процесу, що розглядаються. Логістична функція – це укрупнена
група логістичних операцій, вкладених у реалізацію цілей і завдань логістичної
системи [9, 43].
До основних функцій логістики можна віднести:
• Управління господарськими зв'язками із постачальниками товарів;
• Визначення обсягу матеріального потоку;
• Прогнозування потреб перевезень;
• Ефективна організація складування;
• Управління обігом продукції;
• Впровадження системи якості для підприємства.
Логістична діяльність на підприємстві починається у момент виникнення
потреби у товарі та закінчується у момент задоволення цієї потреби. Тому
логістичне управління підприємством можна охарактеризувати як максимально
ефективне інтегроване управління бізнес-процесами з виробництва та продажу
продукції та супутніх йому потоків від моменту створення до повідомлення його
кінцевого споживача [6].
22
ЧДТУ. 2278.003 ПЗ
Стратегія логістики полягає в ефективному управлінні матеріальними та
супутніми потоками. Так само логістична система підприємства має бути
клієнтоорієнтованою. Виходячи з цих двох пунктів, можна сформулювати
головну мету логістики: доставка продукції відповідної кількості та якості точно
в строк та за мінімальних витрат на постачання, виробництво, збут та
транспортування, а також на отримання, обробку та передачу інформації [14].
Для досягнення основної мети логістики необхідно реалізувати такі
підцілі:
• Налагодження системи обліку витрат та обсягу виконання логістичних
операцій за допомогою встановлення ефективного порядку контролю на
підприємстві;
• Реорганізація організаційної структури підприємства;
• Організація логістичного менеджменту для підприємства.
Стратегія логістики має керуватися такими принципами:
• Ефективність – у виробництві має брати участь лише те, що несе
додаткову цінність кінцевого споживача, решта має бути виключено з усіх
аспектів ланцюжка поставок;
• Чуйність – весь ланцюжок поставок компанії безпосередньо залежить
від інтересів споживачів;
• Швидкість реакції – весь ланцюжок повинен бути здатним швидко
адаптуватися до будь-яких змін;
• Безпека – гарантія того, що товар безпечний
Безліч всіх доріг міста (району) становить дорожню мережу, але поняття
транспортної мережі дещо вже інакше. У ній враховуються лише ті вулиці
(дороги), які придатні для руху по ширині проїжджої частини та якості покриття.
Модель такої мережі може бути подана у вигляді графа (рис. 2.2). Граф - це фігура,
що складається з точок (вершин) та відрізків (ребер), що їх з'єднують. Ребра
характеризуються числами, які можуть мати різний фізичний зміст. Як видно із
рис. 1.3, частина ребер орієнтована за напрямом. Такі ребра називаються дугами.
23
ЧДТУ. 2278.003 ПЗ
Фактично всяке неорієнтоване ребро включає дві рівноцінні, але протилежно
спрямовані дуги. Залежно від цього, всі або частина ребер мають напрямок, граф є
орієнтованим чи змішаним.
Рис.1.3 – Модель транспортної мережі
Граф, кожна вершина якого може бути з'єднана деякою послідовністю
ребер з будь-якою іншою його вершиною, називається зв'язковим графом. З
цього визначення випливає, що кожна вершина зв'язкового графа повинна мати
як мінімум одну вхідну і одну дугу, що виходить. Граф, що моделює транспортну
мережу, обов'язково має бути зв'язковим, щоб завжди був шлях із будь-якої
вершини до будь-якої іншої. Числа, що характеризують ребра такого графа,
виражають протяжність колії, час чи вартість проїзду. Граф найчастіше є
змішаним, оскільки у міських умовах деяких вулицях встановлено
односторонній рух. Для моделювання транспортної мережі насамперед
потрібний картографічний матеріал. Він має бути досить докладним,
відображати сучасний стан міста (району) та, по можливості, перспективи його
розвитку. Цим вимогам відповідають карти великого масштабу, де нанесено всі
існуючі вулиці (дороги) та проїзди. Такі карти дозволяють з великою точністю
робити вимірювання відстаней між суміжними вершинами.
Картографічний матеріал необхідно доповнити відомостями з
комунальних та дорожніх організацій у вигляді переліку вулиць (населених
пунктів) з характеристикою їхньої проїзної частини. Для моделювання, крім
картографічного матеріалу, необхідно мати всі відомості щодо організації
24
ЧДТУ. 2278.003 ПЗ
вуличного руху у місті. Сюди входять схеми організації руху на перехрестях,
площах та транспортних розв'язках, а також різні обмеження, що діють на
вулицях, проїздах та дорожньо-мостових спорудах відповідно до встановлених
там дорожніх знаків. До цих обмежень входять:
- запровадження одностороннього руху;
- заборона проїзду вантажних автомобілів;
- заборона деяких напрямків руху;
- обмеження загальної ваги, навантаження на вісь або габаритних
розмірів транспортних засобів.
Крім цього, необхідно мати відомості про розміщення основних
вантажоутворюючих і вантажопоглинаючих об'єктів, що обслуговуються
автомобільним транспортом. Маючи ці дані, моделювання транспортної мережі
починають із розміщення вершин.
Вершини присвоюють точкам міста, що відповідають:
- основним вантажоутворюючим та вантажопоглинаючим пунктам
(промисловим підприємствам, портам, залізничним станціям тощо);
- центрам великих житлових кварталів (як існуючих, так і тих, що
будуються);
- центрам невеликих відокремлених населених пунктів, що входять до
меж міста, перетинам вулиць.
Після розміщення вершин деякі їх пов'язують ребрами (дугами). При
цьому враховують лише вулиці та проїзди, які мають вдосконалене покриття.
Якщо дві точки міста пов'язані кількома паралельними проїздами, то моделі
мережі їх замінюють одним рубом. Не слід вводити в модель дублюючі зв'язки,
що не дають скорочення відстані, порівняно з іншими зв'язками. Окремо слід
розглянути моделювання транспортної мережі для сучасних міських умов із
щільними транспортними потоками (рис. 1.4).
25
ЧДТУ. 2278.003 ПЗ
Рис.1.4 – Схема моделювання часу на транспортній мережі
Ділянку вулично-дорожньої мережі, що існує, ми можемо розбити на дві
частини за умовами руху: lд – ділянка вільного руху транспортного засобу; lз –
черга перед перехрестям. Довжина затора визначається виходячи з існуючої
годинної інтенсивності руху (Nчас), у нашому прикладі, часу циклу світлофора
(Tц). У випадку існуюче перехрестя незалежно від його виду ми можемо у
вигляді системи масового обслуговування (СМО) і цим визначити довжину
затора.
Важливо відзначити, що ситуація в місті змінюється з кожною годиною, і
інтенсивність вхідного потоку по кожній дузі також буде різною. Це зумовлює
необхідність проводити моделювання для кожної конкретної години. Кінцевим
результатом подібного моделювання є карти транспортної доступності, на яких
зазначено час і можливість дістатися зазначеної точки від вихідної (рис. 1.5).
Рис.1.5 – Варіант карти транспортної доступності
Висновки до першого розділу
Експертні системи являють собою економічний і спосіб виявлення,
уточнення і поширення передового досвіду управлінських рішень. Ці системи
забезпечують єдину схему оформлення питань і відповідей, використовуваних
експертами для рішення аналітичних і оперативних проблем. Експертні системи
26
ЧДТУ. 2278.003 ПЗ
дозволяють зробити знання одного фахівця надбанням багатьох працівників, що
збільшує погодженість, точність і продуктивність операцій за всією мережею.
Удосконалювання засобів зв'язку значно підвищує ефективність
інформаційних технологій у логістиці.
Канали супутникового зв'язку відкривають можливість швидко передавати
значні обсяги інформації в будь-якій точці Землі.
Збір даних і обмін інформацією критично важливі для логістичного
менеджменту [16].
Стратегія логістики має керуватися такими принципами:
• Ефективність – у виробництві має брати участь лише те, що несе
додаткову цінність кінцевого споживача, решта має бути виключено з усіх
аспектів ланцюжка поставок;
• Чуйність – весь ланцюжок поставок компанії безпосередньо залежить
від інтересів споживачів;
• Швидкість реакції – весь ланцюжок повинен бути здатним швидко
адаптуватися до будь-яких змін;
• Безпека – гарантія того, що товар безпечний
У другому розділі представлена модель транспортної задачі.
27
ЧДТУ. 2278.003 ПЗ
РОЗДІЛ 2
ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ
2.1 Теоретичні дослідження
2.1.1 Узагальнення поняття логістики
Всередині логістичної системи використовується методологічний апарат
логістики. Методи вирішення логістичних завдань можна розбити на два класи:
- традиційні методи управління матеріальними потоками, що
домагаються ефекту за рахунок раціоналізації схем руху товару і координації
учасників логістичної системи;
- наукові методи ефективного управління, що дозволяють оптимізувати
витрати в логістичній системі шляхом використання наукового апарату
спеціальних дисциплін, таких як:
- системний аналіз;
- теорія дослідження операцій;
- теорія оптимального управління;
- прогнозний аналіз;
- теорія конфліктів; - моделювання.
Розглянемо поняття системного аналізу. Системний аналіз забезпечує
розгляд об'єктів як комплексів взаємопов'язаних підсистем, об'єднаних спільною
метою, внутрішніми і зовнішніми зв'язками, наявністю інтеграційних
властивостей.
Якщо розглянути формування логістичної системи, то можна виділити
основні принципи системного підходу, такі як:
- послідовне просування по етапах створення системи від макро- до
мікрорівня;
- узгодження інформаційних, характеристик надійності та
інших характеристик проектованих підсистем;
- відсутність конфліктів між цілями окремих підсистем і цілями всієї
системи.
28
ЧДТУ. 2278.003 ПЗ
Якщо розглядати системний підхід, то він передбачає поетапне рух від
загального до конкретного. Розглянемо ці етапи:
1 Формулювання цілей системи;
2 Визначення обмеження та вимоги до системи;
3 Формування підсистеми, функціонально орієнтовані на спільне
досягнення мети;
4 З підсистем, кожна з яких розглядається як система нижчого рівня
для реалізують її елементів, синтезування системи.
Основний принцип системного підходу – це визначення головної мети.
Дерево цілей формується шляхом розбиття головної мети (корінь цілі) на підцілі
- підлеглі вершини. Наприклад, метою є розвиток логістичної системи - перший
рівень дерева цілей. Рівень розвитку логістичної системи в свою чергу
визначається формуванням адекватної системи
Якщо розглянути другий рівень дерева цілей, це - логістика управління,
розвиненістю інфраструктури, формуванням відповідної кадрової систем. Кожен
наступний рівень розбиває мета вищого рівня на підцілі, завдання або конкретні
заходи.
Рис.2.1 - Приклад дерева цілей
Класичний і системний підходи до організації доставки товарів можна
показати на прикладі постачання магазинів зі складів оптової торгівлі.
Класичний підхід представляє собою так зване само вивіз товару. При
цьому магазини самостійно в міру необхідності закуповують зі складу товари,
29
ЧДТУ. 2278.003 ПЗ
використовуючи свій чи найманий транспорт для їх доставки. На складі можуть
виникати великі черги в разі одночасного приїзду багатьох покупців. Транспорт
простоює і використовується неефективно по завантаженню. Кожен магазин
використовує свої технології вантажопереробки. Спільної мети між магазинами
немає.
Системний підхід передбачає організацію доставки централізовано. У
цьому випадку створюється єдина система забезпечення магазинів з
мінімальними витратами, для чого визначаються оптимальні маршрути, графіки
та партії поставок, створюється парк спеціалізованих автомобілів, уніфікуються
процеси приймання вантажу і тара.
Якщо просумувати витрати, то вони в обох випадках нижче. Однак для
його реалізації необхідно створити систему розподілу продукції, в якій кожен
магазин розглядається як підсистема або її елемент.
Теорія дослідження операцій дозволяє знаходити оптимальні рішення.
Наприклад, вибір оптимального маршруту руху транспортного засобу, що
доставляє продукцію декільком споживачам, в умовах обмеження його
вантажопідйомності, швидкості руху, часу перебування в дорозі, сумісності
різних товарів і т.д., може здійснюватися чисельними методами лінійного
програмування з використанням теорії графів.
Якщо розглядати теорію оптимального управління то можна визначити,
що це дозволяє вирішувати завдання управління системами на основі
кібернетичного підходу з використанням принципів адаптації за рахунок
введення в систему зворотних зв'язків. В управлінні зворотний зв'язок дозволяє
враховувати миттєвий результат від керуючого впливу. Ступінь впливу при
цьому може змінюватися в залежності від величини неузгодженості між
результатом управління і метою управління а оптимальне управління дозволяє
досягати результату найбільш швидким способом при оптимальному
використанні ресурсів.
30
ЧДТУ. 2278.003 ПЗ
Прогнозований аналіз дозволяє прогнозувати зміни її параметрів у
майбутньому на основі вивчення поведінки системи у минулому та сучасному.
Це дає можливість запобігати несприятливим змінам за рахунок перерозподілу
ресурсів, що впливають на параметри прогнозу, керувати системою з
урахуванням даних прогнозу в режимі випередження реального часу.
Теорія конфліктів дозволяє пов'язати різні самостійні елементи на єдину
систему, підпорядкувати їх досягненню єдиної мети. Кожен учасник
логістичного процесу має чітко визначені межі відповідальності та свою
локальну мету. Матеріальний потік, що рухається від одного учасника до іншого,
підпорядкований цілям роботи кожного учасника. Мінімізація логістичних
витрат для одного учасника може призвести до їх різкого збільшення для іншого
учасника. Побудова логістичної системи вимагає узгодження інтересів всіх
учасників та функціональних ланок руху товарів, пошуку компромісів для
досягнення оптимальних параметрів усієї системи.
Матеріальні моделі є макети з планувальними і технологічними схемами,
що відображають геометричні або фізичні параметри системи. Прикладом
матеріальної моделі може бути план складу, виконаний з дотриманням розмірних
масштабів, який використовується для знаходження оптимального
компонування складського обладнання, зон прийому, збирання та відвантаження
товарів, місць стоянки та маневрування транспорту.
Аналітичні моделі є математичним описом об'єктів і зв'язків між ними у
вигляді рівнянь, які вирішуються щодо керуючих параметрів. Для перевірки
моделі результати порівнюються із практикою. Аналітичні моделі можуть бути
побудовані для відносно простих об'єктів та невеликої кількості
взаємопов'язаних параметрів та дозволяють проводити якісну оцінку
управлінських заходів. Отримати аналітичну модель усієї логістичної системи
неможливо через формалізації реальних подій випадкового характеру та
величезної кількості взаємних зв'язків між її елементами. Тому будь-яка
аналітична модель має приватний характер і вирішує обмежене коло завдань.
31
ЧДТУ. 2278.003 ПЗ
Імітаційні моделі відтворюють процес функціонування системи у часі
без урахування реальних зв'язків усередині неї та реалізуються як функція
вихідних параметрів від вхідних параметрів. Такий підхід називається
принципом «чорної скриньки» і дозволяє вибирати комбінацію вхідних
параметрів відповідно до бажаних вихідних значень.
2.1.2 Представлення транспортної задачі
Транспортна задача — це специфічна задача лінійного програмування,
застосовувана для визначення найекономічнішого плану перевезення однорідної
продукції від постачальників до споживачів.
Загальна постановка транспортної задачі полягає у визначенні
оптимального плану перевезень деякого однорідного товару із M — пунктів
відправлення ( ) в N — пунктів призначення ( ). При цьому в
якості критерію оптимальності беруть мінімальну вартість на перевезення всього
товару обо мінімальний час його доставки.
Розглянемо транспортну задачу в якості критерію оптимальності якої
взято мінімальну вартість перевезення. Позначимо через — тарифи на
перевезення одиниці товару з i-го пункту відправлення в j-й пункт призначення.
Через — запаси товару в i-му пункиі відправлення; — потреби в товарі у j-
му пункті призначення. Через — кількістьі товару, який потрібно перевезти
з i-го пункту відправлення в j-й пункт призначення. Тоді математична
постановка задачі полягає у визначенні мінімального значення функції:
(1)
при умовах:
32
ЧДТУ. 2278.003 ПЗ
(2)
(3)
Оскільки змінні — задовільняють систему лінійних рівнянь (2) і (3) і
умову (4), то ми можемо забезпечити доставку необхідної кількості товару в
кожний із пунктів призначення.
Означення 1: будь-який невід'ємний розв'язок системи лінійних рівнянь
(2) і (3), який записується у вигляді матриці —
називається планом транспортної задачі.
Означення 2: план , при якому функція (1) приймає
своє мінімальне значення називається оптимальним планом транспортної
задачі.
Початкові дані транспортної задачі записуються у вигляді таблиці Рис.2.2:
Рис.2.2 – Матриця транспортноъ задачі
Очевидно, що загальна кількість товару поставщиків дорівнює ;
Загальні потреби в товарі у пункті призначення рівні .
33
ЧДТУ. 2278.003 ПЗ
Якщо загальна потреба в товарі у пунктах призначення рівна запасам
товару у пунктах відправлення, тобто ,то модель такої
транспортної задачі називається закритою. Якщо ж вказана умова не
виконується, то задача називається відкритою.
Теорема 1: Для того, щоб транспортна задача мала розв'язок, необхідно
і достатньо, щоб запаси товару в пунктах відправлення дорівнювали потребам в
товарі у пунктах призначення, тобто щоб виконувалась умова (5).
У випадку коли запаси більші від потреб, тобто , вводиться
фіктивний (n+1)-й пункт призначення з потребами . І .
Аналогічно, при вводиться фіктивний (m+1)-й пуект
відправлення з запасами товару і тарифи рівні нулю ( ).
Число змінних в транспортній задачі з M пунктами відправлення
і N пунктами призначення дорівнюєM*N, а число рівнянь M+N.
Опорний план транспорної задачі може мати не більше (n+m-1) відмінних
від нуля невідомих. Якщо в опорному плані число відмінних від нуля компонент
рівна точно (n+m-1), то план називається невиродженим, а якщо менше, то
виродженим. Для визначення опорного плану існує декілька методів, серед
яких виділяють метод північно-західного кута, метод мінімального елемента,
метод Фогеля.
2.2 Експерементальні дослідження
2.2.1 Метод північно-західного кута
Ідея методу північно-західного кута полягає в тому, що
заповнення таблиці перевезень транспортної задачі починається з лівого
верхнього (північно-західного) кута, не враховуючи вартостей перевезень. У
34
ЧДТУ. 2278.003 ПЗ
клітину записують менше з двох чисел та . Далі переходять до наступної
клітинки в цьому ж рядку або у стовпчику і заповнюють її і так далі. Закінчують
заповнення даної таблиці у правій нижній клітинці. У такий спосіб значення
поставок будуть розташовані по діагоналі таблиці.
Для того, щоб закріпити даний алгоритм більш детально розглянемо
наступний приклад: на три бази поступив товар в кількості 140; 180;
160. Цей груз треба перевезти в п'ять пунктив призначення в
кількостях 60; 70; 120; 130; 100. Тарифи перевезення записані в наступній
таблиці Рис.2.3:
Рис.2.3 – Початкові дані тарифів перевезень
Для того, щоб знайти план перевезення даної транспортної задачі
методом північно-західного кута, спочатку, не враховуючи вартостей
перевезення, задовільняємо потреби першого пункту призначення ,
використовуючи запаси першого пункту відправлення . У нашому прикладі
потреби в товарі пункту становлять , а запаси відправника — .
Тобто із запасів першого пункту відправлення ми можемо повністю
задовільнити потреби першого пункту призначення. Тому у
клітинку записуємо менше із значень , , тобто 60. Після цього наша
таблиця набуде такого вигляду Рис.2.4.:
35
ЧДТУ. 2278.003 ПЗ
Рис.2.4- Другий крок вирішення ТЗ
Тепер переходимо до задоволення потреб другого пункту
призначення — , потреби якого становлять . Після задоволення потреб
пункту , залишок запасів першго пункту відправлення становить 140 — 60 =
80 (цього достатно, щоб задовільнити потреби і другого пункту призначення).
Тому записуємо в клітинку значення 70 і переходимо до задоволення
потреб пункту .
Рис.2.5 - Третій крок вирішення ТЗ
Залишок запасів у першого пункту призначення, після задоволення
потреб пунктів призначення і , становить 140 — 60 — 70 = 10. Тому
третьому споживачеві від першого відправника можемо перевезти лише 10
одиниць продукції. Отже, в клітинку помістимо число 10.
Рис.2.6 - Четвертий крок вирішення ТЗ
36
ЧДТУ. 2278.003 ПЗ
Після цього, оскільки запаси першого відправника повністю вичерпані,
переходимо до використання запасів наступного постачальника . Його запаси
рівні . А незадоволені потреби третього пункту призначення 120 — 10
= 110. Тому в клітинку записуємо число 110, і третій споживач, у такий
сопсіб, також отримав необхідну кількість продукції.
Рис.2.7 - П’ятий крок вирішення ТЗ
Переходимо до задоволення потреб наступного споживача, а саме . У
результаті часткового використання запасів другого пункту відправлення його
залишок продукції становить 180 — 110 = 70. Отже від другого пункту
відправлення до четвертого пункту призначення можна перевезти лише 70
одиниць продукції. Тому клітинка міститиме число 70, і цим запаси
постачальника будуть також повністу вичерпані.
Рис.2.8 - Шостий крок вирішення ТЗ
Переходимо до використання запасів останнього пункту відправлення
. Залишок потреб четвертого пункту становить 130 — 70 = 60. Для їх задоволення
скористаємось запасами відправника . У клітинку запишемо число 60 і
потреби четвертого пункту також повністю задоволені.
37
ЧДТУ. 2278.003 ПЗ
Рис.2.9 - Сьомий крок вирішення ТЗ
Переходимо до останнього споживача з потребами , які
повністю задовольняються за рахунок залишку третього відправника 160 — 60
=100, тобто у клітинку запишемо число 100. Таким чином ми отримали
кінцеву таблицю, у заповнених клітинках якої містяться числа, які означають
можливий план перевезення продукції з загальною вартістю F = 60 * 2 + 70 * 3
+ 10 * 4 + 110 * 1 + 70 * 4 + 60 * 7 + 100 * 2 = 1380 умовних одиниць [5].
Рис.2.10 - Фінальний вигляд матриці ТЗ
2.2.2 Метод мінімального елемента
Ідея методу мінімального елемента полягає в тому, що на кожному кроці
заповнюють клітинку таблиці, яка має найменшу вартість перевезення одиниці
продукції. Такі дії повторюють до тих пір, поки не буде розподілено всю
продукцію між пунктами відправлення і пунктами призначення.
Складемо розв'язок наступної задачі з допомогою цього
методу. Приклад: На три бази поступив товар в кількості 160; 140 і 170
одиниць відповідно. Цей груз потрібно перевезти в чотири пункти призначення
38
ЧДТУ. 2278.003 ПЗ
, потреби яких становлять 120; 50; 190; 110. Тарифи перевезення
записані в таблиці:
Рис.2.11. - Введення початкових матриці ТЗ
Найменшу вартість має перевезення, яке здійснюються з в , ціна
перевезення одиниці продукції якого становить 1-ну умовну одиницю.
Заповнимо дану клітинку. Оскільки відправник має в запасі 160 одиниць
продукції, а пункт призначення потребує — 190, то від першого відправника
третьому споживачеві можна перевезти лише 160 одиниць продукції. І таким
чином запаси першого пункту відправлення повністю вичерпані (перший рядок
викреслюємо з розгляду).
Рис.2.12 - Перший крок розрахунку матриці ТЗ
З клітинок, що залишилися вибираємо ту, в якій знаходиться маршрут з
мінімальною вартістю перевезення. Таких клітинок у нас дві: і .
Виходячи з того, що клітинка знаходиться в першому рядку, а його ми на
попередньому кроці викреслили з розгляду, то будемо заповнювати
клітинку . Обсяг запасів пункту відправлення рівні , а
потреби , тому, за рахунок запасів третього відправника, потреби другого
39
ЧДТУ. 2278.003 ПЗ
споживача задовільняються в повному обсязі (стовбець під номером два
викреслюється з розгяду) і в клітинку записуємо число 50. В результаті
отримуємо наступну таблицю:
Рис.2.13 - Другой крок розрахунку матриці ТЗ
Знову вибираємо клітинку (серед тих що залишилися незаповненими) з
найменшою вартістю перевезень. Такою клітинкою буде . Виходячи з того,
що запаси третього пункту відправлення становлять , а потреби
третього пункту призначення рівні , то ставимо в
клітинку значення 30. І таким чином потреби 3-го пункту призначення
задоволені, а стовбець в якому знаходиться даний пункт викреслюємо з розгляду.
Рис.2.14 - Третій крок розрахунку матриці ТЗ
Продовжуючи даний процес до тих пір, поки усі запаси не будуть
вичерпані, а потреби — задоволеними, ми отримаємо таблицю, у заповнених
клітинках якої містяться числа, які означають можливий план перевезення
продукції із загальною вартістю F = 120 * 4 + 50 * 2 + 160 * 1 + 3 * 30 + 20 * 8 +
90 * 6 = 1530
40
ЧДТУ. 2278.003 ПЗ
Рис.2.15 - Фінальний розрахунок матриці ТЗ
2.2.3 Метод Фогеля
Серед розглядуваних на даному сайті методів побудови опорного плану
в транспортній задачі, найчастіше застосовуються на практиці метод Фогеля.
Послідовність дій при його використанні зовсім інша, ніж при
заповненні транспортної таблиці методом північно-західного кута чи методом
мінімального елемента. На перший погляд метод Фогеля видається набагато
складнішим, проте це лише помилкове враження. Метод простий і дозволяє
отримати опорний план більш наближений до оптимального рішення, ніж у
випадку застосування інших методів (за винятком хіба що методу подвійної
переваги). Отже, розглянемо алгоритм даного методу більш детально:
1 На довільному кроці методу, для кожного рядка та стовпця
обчислюється різниця ("штраф") між значеннями найменшої вартості та
вартості, наступної за величиною. Якщо ж виявиться, що в рядку чи стовпці
містятся дві комірки з однаковими мінімальними значеннями тарифів, то
беремо саме їх. В такому випадку різниця буде дорівнює нулю.
2 Обчислені штрафи записуються у додаткові рядки та
стовпі транспортоної таблиці.
3 Виокремлюємо рядок чи стовпець з найбільшим "штрафом" (якщо
їх є декілька, то обираємо довільний з них).
4 У виокремленому на попередньому кроці рядку чи стовпці, обираємо
комірку з найменшою вартістю.
41
ЧДТУ. 2278.003 ПЗ
5 Для обраної комірки встановлюємо величину перевезунь,
аналогічно методу мінімального елемента, після чого, повторюємо всі
вищеописані дії знову, тільки вже не враховуючи заповнені клітини.
Відмітимо, що такі дії необхідно повторювати до тих пір, поки не
залишиться незаповненим лише один рядок або стовпець. В такому випадку,
обчислення різниць припиняють, а таблицю продовжують заповнювати
згідно методу мінімального елемента.
Побудова опорного плану транспортної задачі методом Фогеля —
приклад:
На три бази поступив товар в кількості 160, 140 і 170 одиниць
відповідно. Цей груз потрібно перевезти в чотири пункти призначення ,
потреби яких становлять 120, 50, 190, 110. Тарифи на перевезення одиниці
продукції записані в наступній таблиці.
Рис.2.16 - Таблиця тарифів на перевезення
Для побудови опорного плану транспортної задачі методом Фогеля, на
першому кроці доповнимотранспортну таблицю додатковим рядком і
стовпцем. Далі, згідно алгоритму, заповнимо їх комірки обчисленими для
кожного рядка та стовпця "штрафами".
42
ЧДТУ. 2278.003 ПЗ
Рис.2.17 - Побудова опорного плану транспортоної задачі Крок 1
Максимальне значення такої різниці на першому кроці відповідає
четвертому стовпцю і означає, що у разі, коли не буде задоволена потреба
четвертого пункту призначення перевезенням продукції від першого пункту
відправлення за ціною 2 у. о. за одиницю товару, то на наступних кроках вартість
перевезення може бути на 4у. о. більшою. Тобто інакше може статися, що
потребу четвертого пункту необхідно буде задовольняти перевезенням продукції
від третього відправника, що призведе до збільшення вартості цього перевезення
в3 рази. Водночас для всіх інших пунктів призначення та пунктів відправлення
такі різниці є меншими. Отже, найдоцільніше на першому кроці заповнити
комірку . Після цього потреби пункту повністю задоволені, і всі комірки
четвертого стовпчика виключаємо з подальших розрахунків різниць по рядках і
стовпцях, після чого переходимо до наступного кроку.
Рис.2.18 - Побудова опорного плану транспортоної задачі Крок 2
На другому кроці максимальна різниця дорівнює 6 і відповідає першому
рядку таблиці. Тому заповнюємо її комірку з мінімальною вартістю, а саме
комірку . Після цього з розгляду виключаються одразу всі комірки першого
рядка, оскільки його запаси повністю вичерпані. Переходимо до кроку під
номером три.
43
ЧДТУ. 2278.003 ПЗ
Рис.2.19 - Побудова опорного плану транспортоної задачі Крок 3
Третій крок розрахунку різниць (найбільше значення 6 відповідає
третьому стовпцю) говорить про те, що доцільно, скориставшись запасами
третого пункту відправлення, повністю задовільнити потреби третього пункту
призначення, тобто заповнємо комірку таблиці і викреслюємо третій
стовпець з розгляду. Далі, переходимо до четвертого кроку.
Рис.2.20-Побудова опорного плану транспортоної задачі Крок 4
На четвертому кроці, скориставшись запасами, що залишились, третого
пункту відправлення, частково задовільнимо потреби другого пункту
призначення і таким чином викреслимо третій рядок таблиці з розгляду.
Відмітимо, що на цьому процес обчислення різниць ("штрафів") завершується,
і решта клітин заповнюємо згідно алгоритму методу мінімального елемента. В
результаті виконання даного кроку, ми отримали таблицю, у заповнених
комірках якої містяться числа, які означають можливий план перевезення
продукції із загальною вартістю .
44
ЧДТУ. 2278.003 ПЗ
Рис. 2.21 - Побудова опорного плану транспортоної задачі Крок 5
45
ЧДТУ. 2278.003 ПЗ
Висновки до другого розділу
Розглянувши поставлені питання можна сказати щоглобальні маркетингові
і логістичні операції дозволяють компаніям домогтися ринкового росту, значної
економії за рахунок масштабів діяльності і підвищення прибутковості. На
світовому ринку підсилюється роль логістики і зростає значення логістичного
менеджменту.
Інформаційна система — це певним чином організоване сукупність
взаємозалежних засобів обчислювальної техніки, різних довідників і необхідних
засобів програмування, що забезпечує рішення тих або інших функціональних
задач
У сьогоднішній логістиці персональний комп'ютер (ПК) поширився майже
повсюдно. Завдяки мініатюризації і підвищенню потужності обчислювальної
техніки сучасні інформаційні технології стали доступні не тільки менеджерам.
Експертні системи являють собою економічний і спосіб виявлення,
уточнення і поширення передового досвіду управлінських рішень. Ці системи
забезпечують єдину схему оформлення питань і відповідей, використовуваних
експертами для рішення аналітичних і оперативних проблем. Експертні системи
дозволяють зробити знання одного фахівця надбанням багатьох працівників, що
збільшує погодженість, точність і продуктивність операцій за всією мережею.
Удосконалювання засобів зв'язку значно підвищує ефективність
інформаційних технологій у логістиці.
Збір даних і обмін інформацією критично важливі для логістичного
менеджменту [16].
Також, у другому розділі проаналізовано методи вирішення логістичних
завдань, які умовно розбиваються на два класи: традиційні методи управління
матеріальними потоками, що домагаються ефекту за рахунок раціоналізації схем
руху товару і координації учасників логістичної системи; наукові методи
ефективного управління, що дозволяють оптимізувати витрати в логістичній
системі шляхом використання наукового апарату спеціальних дисциплін, таких
46
ЧДТУ. 2278.003 ПЗ
як: системний аналіз, теорія дослідження операцій, теорія оптимального
управління, прогнозний аналіз, теорія конфліктів, моделювання.
Представлена матриця транспортної задачі та методи вирішення опорного
плану транспортної задачі: метод мінімального елемента, метод північнозахідного
кута і метод Фогеля. Як видно з прикладів, метод Фогеля дає оптимальний варіант
рішення опорного плану на відміну від інших методів.
47
ЧДТУ. 2278.003 ПЗ
РОЗДІЛ 3
ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
3.1 Моделювання предметної області
3.1.1 Предметна область моделювання
Сучасне життя вже неможливе без використання нових технологій і
нерозривно пов’язаного з ними інформаційного забезпечення, тому що задачі
діяльності в сучасних умовах все частіше вирішуються з використанням власних,
національних і міжнародних інформаційних ресурсів.
В даний час все більшого і більшого поширення, як у виробництві, так і в
документообігу підприємств знаходить комп'ютерна техніка, все ширше і ширше
стає перелік охоплених нею завдань. Постійно зростає обсяг і складність
оброблюваної інформації, потрібні все нові й нові види її подання. Як показує
практика, більшість користувачів вже не уявляє собі, як би вони виконували свою
роботу, з якою чудово справлялися ще п'ять – десять років тому, без допомоги
комп'ютера. Ось тільки деякі з переваг використання обчислювальної техніки при
роботі, з якими даними, документами:
- відразу після введення, дані можуть брати участь у різних операціях;
- можливість одночасного доступу до інформації декількох користувачів
;
- можливість швидкого отримання необхідних звітів;
- необхідна інформація, пошук якої у звичайній папці з документами
утруднений, може бути швидко знайдена;
- істотна економія часу і людських ресурсів при виконанні операцій,
пов'язаних з обробкою інформації;
- дозволяє швидко і в найкращому конкретної людини вигляді
переглянути дані, що підвищує їх сприйняття.
48
ЧДТУ. 2278.003 ПЗ
Все, вище викладені переваги, на сьогоднішній день оцінені не тільки
рядовими користувачами, а й керівниками підприємств і організацій, особливо це
стосується можливості контролю і пошуку інформації.
Зберігання даних у цифровому вигляді більш доцільно, ніж зберігання у
вигляді паперів. Комп'ютер надає можливість швидкого пошуку за кількома
параметрами.
Логістика – це сфера діяльності, об'єктом якої є організація та регулювання
процесів надходження продукції, що виготовляється від виробника до споживача.
Тобто це управління матеріальними ресурсами під час їх закупівлі або
виробництва, перевезення, зберігання.
Для здійснення логістичної діяльності використовуються логістичні центри
- це складські приміщення, площею більше 10 тис. кв. метрів, в яких
використовується спеціальне обладнання для виконання вантажно-
розвантажувальних робіт і зберігання вироблюваної продукції, а також
інформаційна система, за допомогою якої виявляються логістичні послуги [1].
Сучасний етап розвитку логістики характеризується створенням великої
кількості професійних організацій. Це зв'язано з тим, що мистецтво логістики
розвивається настільки стрімко й швидко, що професіоналам приходиться
постійно займатися самоосвітою.
Стратегічний напрямок логістики в Україні зумовлений декількома
причинами:
1 Швидким зростанням витрат на будь-які перевезення (викликаним
зростанням цін на нафту та енергетичною кризою);
2 Переорієнтацією від ринку надання послуг до ринку споживача і як
наслідок досягнення межі ефективності системи обслуговування і виробництва.
Для подальшого просування послуг на ринку стало необхідним зокрема
поліпшення роботи в сфері розподілу, що дозволяє знижувати ціну послуг і
постачати його точно в термін і потрібної якості;
49
ЧДТУ. 2278.003 ПЗ
3 Розвитком комп'ютерних технологій, що дозволяє здійснювати обробку
величезних масивів інформації і обмінюватися даними в реальному часі з
мінімальними витратами [2].
Щоб прискорити розвиток логістики в Україні, важливо з’ясувати причини,
які стримують її практичне застосування.
По-перше, це відсутність належного державного підходу до проблем
логістики, що виявляється як у відсутності відповідної бази, так і у відсутності
спеціалістів та центрів їх підготовки.
По-друге, загальна економічна криза, незавершеність вирішення питання
власності, скорочення обсягів виробництва, інфляція гальмують будь-які новації.
По-третє, відсутній комплексний облік витрат, при якому їх зростання у
транспортно-складському господарстві перекривається ефективністю,
досягнутою за межами цієї галузі господарства. Разом з тим існуюча система
бухгалтерського обліку, методики внутрішньовиробничого госпрозрахунку, що
використовуються на практиці, поки не дають змоги повністю оцінювати витрати
й результати діяльності підрозділів та служб підприємства.
По-четверте, логістичний підхід передбачає досить кардинальні зміни в
структурі підприємства, перехід до більш гнучких організаційних структур,
створення спеціалізованих цехів і служб транспортно-складського господарства.
По-п'яте, розвиток ідей логістики гальмується недоліками професійної
підготовки кадрів. Існує багато й інших причин, ліквідація яких прискорила б
впровадження логістики у практику.
У результаті такої мотивації можна говорити про розвиток і поступове
впровадження логістики в господарську практику. Звідси на відміну від
традиційного управління матеріальними потоками, здійснюваного людьми з
давніх часів, при використанні логістичного підходу виділяється категорія
«наскрізний матеріальний потік», який стає об'єктом управління з якісними
показниками, що контролюються.
50
ЧДТУ. 2278.003 ПЗ
Логістика як наукова дисципліна може стати надійним помічником в
удосконаленні діяльності підприємств. Тому в Україні необхідно створити
розгалужену мережу логістичних утворень, яка в нинішніх кризових умовах
допоможе підприємствам швидше встановити нові господарські зв'язки. Такі
утворення, як ніякі інші, спроможні швидко відновити виробничий ритм, зняти
бар'єри у господарських стосунках [1].
3.1.2 Модель предметної області. Словник предметної області
Уніфікована мова моделювання (UML) є стандартним інструментом для
створення "креслень" програмного забезпечення. За допомогою UML можна
візуалізувати, специфікувати, конструювати й документувати артефакти
програмних систем.
UML придатний для моделювання будь-яких систем: від інформаційних
систем масштабу підприємства до розподілених програм орієнтованих під Web і
навіть вбудованих систем реального часу. Це дуже виразна мова, що дозволяє
розглянути систему із всіх точок зору, що мають відношення до її розробки й
наступного розгортання. Незважаючи на достаток можливостей вираження, ця
мова проста для розуміння й використання.
Хоча UML не залежить від модельованої реальності, найкраще
застосовувати його, коли процес моделювання заснований на розгляді
прецедентів використання, є ітеративним й покроковим, а сама система має чітко
виражену архітектуру [25].
UML - це мова для візуалізації, специфікації, конструювання й
документування артефактів програмних систем.
Мова складається зі словника й правил, що дозволяють комбінувати слова
що входять в нього й одержувати осмислені конструкції. У мові моделювання
словник і правила орієнтовані на концептуальне й фізичне подання системи.
Мова моделювання, подібна UML, є стандартним засобом для складання
"креслень" програмного забезпечення.
51
ЧДТУ. 2278.003 ПЗ
Моделювання необхідно для розуміння системи. При цьому єдиної моделі
ніколи не буває досить. Навпроти, для розуміння будь-якої нетривіальної
системи доводиться розробляти велику кількість взаємозалежних моделей. У
застосуванні до програмних систем це означає, що необхідна мова, за допомогою
якої можна з різних точок зору описувати уявлення про архітектуру системи
протягом циклу їх розробки.
Словник і правила такої мови, як UML, пояснюють, як створювати й читати
добре визначені моделі, але нічого не повідомляють про те, які моделі й у яких
випадках потрібно створювати. Це завдання всього процесу розробки
програмного забезпечення. Добре організований процес повинен підказати, які
потрібні артефакти, які ресурси необхідні для їхнього створення, як можна
використати ці артефакти, щоб оцінити виконану роботу й управляти проектом
у цілому.
З погляду більшості програмістів, міркування із приводу реалізації проекту
майже еквівалентні написанню для нього коду. І насправді, деякі речі найкраще
виражаються безпосередньо в коді на якій-небудь мові програмування, оскільки
текст програми - це найпростіший і короткий шлях для запису алгоритмів і
виразів.
Але навіть у таких випадках програміст займається моделюванням, хоча й
неформально. Він може, наприклад, "накинути" ідеї на дошці або на серветці.
Однак такий підхід може викликати неприємності. По-перше, обмін думками із
приводу концептуальної моделі можливий тільки тоді, коли всі учасники
дискусії говорять на одній мові. Як правило, при розробці проектів групам
розробників доводиться винаходити власні мови, і новачкові непросто зрозуміти,
про що йде мова. По-друге, не можна одержати уявлення про певні аспекти
програмних систем без моделі, що виходить за межі текстової мови
програмування. Так, призначення ієрархії класів можна, звичайно, зрозуміти,
якщо уважно вивчити код кожного класу, але сприйняти всю структуру відразу
й цілком не вийде. Аналогічне вивчення коду системи не дозволить скласти
52
ЧДТУ. 2278.003 ПЗ
цілісне уявлення про фізичний розподіл і можливі міграції об'єктів в програмі
орієнтованій на Web. По-третє, якщо автор коду ніколи не втілював у явній формі
задумані їм моделі, ця інформація буде назавжди втрачена, якщо він, наприклад,
змінить місце роботи. У найкращому разі її можна буде лише частково
відтворити виходячи з реалізації.
Використання UML дозволяє вирішити третю проблему: явна модель
полегшує спілкування.
Деякі особливості системи найкраще моделювати у вигляді тексту, інші -
графічно. Насправді у всіх визначних системах існують структури, які
неможливо представити за допомогою однієї лише мови програмування. UML -
графічна мова, що дозволяє вирішити другу з позначених проблем.
UML - це не просто набір графічних символів. За кожним з них знаходиться
добре визначена семантика. Це значить, що модель, написана одним
розробником, може бути однозначно інтерпретована іншим - або в MDA,
інструментальною програмою. Так вирішується перша з перерахованих вище
проблем.
У даному контексті специфікація означає побудову точних, недвозначних
і повних моделей. UML дозволяє специфікувати всі істотні рішення, що
стосуються аналізу, проектування й реалізації, які повинні прийматися в процесі
розробки й розгортання системи програмного забезпечення.
UML не є мовою візуального програмування, але моделі, створені з її
допомогою, можуть бути безпосередньо трансформовані в конкретну реалізацію
під вибрану платформу.
Розробники програмного забезпечення, крім коду програми, створюють й
інші артефакти, у тому числі такі:
1 вимоги до системи;
2 архітектуру;
3 проект;
4 вихідний код;
53
ЧДТУ. 2278.003 ПЗ
5 проектні плани;
6 тести;
7 прототипи;
Залежно від прийнятої методики розробки виконання одних робіт
виробляється більш формально, ніж інших. Згадані артефакти - це не просто
складові частини, що поставляються з проекту; вони необхідні для керування,
для оцінки результату, а також як засіб спілкування між членами колективу під
час розробки системи й після її розгортання.
UML дозволяє вирішити проблему документування системної архітектури
й всіх її деталей, пропонує мову для формулювання вимог до системи й
визначення тестів і, нарешті, надає можливості для моделювання робіт на етапі
планування проекту й керування версіями.
3.1.3 Елементи моделювання предметної області
Розглянемо елементи моделювання предметної області.
Агрегація (aggregation) - спеціальна форма асоціації, що визначає
відношення «частина-ціле» між агрегатом (цілим) та частинами
Актор (actor) - пов'язаний набір ролей, який виконують користувачі при
взаємодії з елементами Use Case
Діяльність (activity) - стан, у якому проявляється деяка поведінка Діаграма
(diagram) - графічне представлення набору елементів, зазвичай
у вигляді зв'язкового графа, у вершинах якого знаходяться предмети, а
дуги є їхні відносини
Діаграма Use Case (use case diagram) - діаграма показує набір елементів Use
Case, акторів та його відносин. Діаграма Use Case відноситься до статичного
уявлення Use Case, що створюється для системи
Діаграма взаємодії (interaction diagram) - діаграма, що показує взаємодію,
що включає набір об'єктів та їх відносин, а також повідомлення, що
пересилаються між об'єктами. Діаграми взаємодії відносяться до динамічного
уявлення системи. Це загальний термін, що застосовується до різних видів
54
ЧДТУ. 2278.003 ПЗ
діаграм, на яких зображено взаємодію об'єктів, включаючи діаграми
співробітництва та діаграми послідовності
Діаграма діяльності (activity diagram) - діаграма, що показує переходи від
одного виду діяльності до іншого. Діаграми діяльності відносяться до
динамічного уявлення системи. Діаграма діяльності є спеціальним різновидом
діаграми схем станів, в якій всі або більшість станів є станами дій, а всі або
більшість переходів спрацьовують при завершенні дій у вихідних станах
Діаграма класів (class diagram) - діаграма, що показує набір класів,
інтерфейсів, кооперацій, і навіть їх відносини. Діаграма класів відноситься до
статичного проектного представлення системи. Ця діаграма показує набір
декларативних (статичних) елементів
Діаграма об'єктів (object diagram) - діаграма, що показує набір об'єктів та
його відносин у певний час. Діаграма об'єктів відноситься до статичного
проектного уявлення або статичного уявлення процесів системи
Діаграма послідовності (sequence diagram) - діаграма взаємодії, що виділяє
тимчасову послідовність передачі повідомлень
Діаграма розміщення (deployment diagram) - діаграма, що показує набір
вузлів та його відносини. Діаграма розміщення відноситься до статичного
уявлення розміщення системи
Діаграма співпраці (collaboration diagram) - діаграма взаємодії, що виділяє
структурну організацію об'єктів, що посилають та приймають повідомлення;
діаграма, яка демонструє організацію взаємодії між екземплярами та їх зв'язок
один з одним
Діаграма схем станів (statechart diagram) - діаграма, що показує кінцевий
автомат. Діаграми схем станів відносяться до динамічного представлення
системи.
3.1.4 Робоча область моделювання
55
ЧДТУ. 2278.003 ПЗ
Моделювання було проведено в додатку App.diagrams.net. App.diagrams.net
— це безкоштовний додаток для побудови діаграм, що дозволяє користувачам
створювати схеми, моделі та діаграми та обмінюватися ними у веб-браузері.
Інтернет-сервіс та відкрите ПЗ від розробника призначено для побудови
робочих схем та діаграм у різних нотаціях. Онлайн-інструмент працює з Google
та Dropbox. Користувачі можуть працювати над діаграмами в автономному
режимі та зберігати їх локально за допомогою настільної програми для macOS,
Windows та Linux.
Інструмент app.diagrams.net забезпечує інтуїтивно зрозумілий інтерфейс з
функцією перетягування, шаблонами діаграм, що налаштовуються, і великою
бібліотекою графічних елементів. Користувачі можуть створювати та редагувати
різні діаграми, включаючи блок-схеми, організаційні діаграми, діаграми
процесів (BPMN), діаграми сутність-зв'язок (ER), схеми уніфікованою мовою
моделювання (UML), мережеві діаграми та багато іншого. draw.io Багата
функціональність дозволяє користувачам відстежувати та відновлювати зміни,
імпортувати та експортувати різні формати, а також автоматично публікувати
роботи та ділитися ними.[29]
3.2 Формування та аналіз вимог до програмного забезпечення
3.2.1 Первинні і детальні вимоги.
Вимоги інженерного процесу це чотириетапний процес, який включає:
- Техніко-економічне обґрунтування
- Збір вимог
- Специфікація вимог до програмного забезпечення
- Перевірка вимог до програмного забезпечення
Техніко-економічне обґрунтування.
Коли клієнт звертається до організації за розробкою потрібного продукту,
він приходить до чіткого уявлення про те, які функції має виконувати програмне
забезпечення та які функції очікуються від програмного забезпечення.
56
ЧДТУ. 2278.003 ПЗ
Посилаючись на інформацію, аналітики докладно вивчають, чи можлива
розробка бажаної системи та її функціональних можливостей.
Це техніко-економічне обгрунтування спрямоване на цілі організації. У
цьому дослідженні аналізується, чи програмний продукт може бути практично
матеріалізований з точки зору реалізації, вкладу проекту в організацію, обмежень
витрат і відповідно до цінностей і цілей організації. У ньому розглядаються
технічні аспекти проекту та продукту, такі як зручність використання,
ремонтопридатність, продуктивність та можливість інтеграції.
Результатом цього етапу має стати звіт про техніко-економічне
обґрунтування, який має містити адекватні коментарі та рекомендації для
керівництва щодо того, чи слід здійснювати проект.
Збір вимог.
Якщо техніко-економічне обґрунтування позитивно ставиться до виконання
проекту, наступний етап починається зі збору вимог користувача. Аналітики та
інженери спілкуються з клієнтом та кінцевими користувачами, щоб дізнатися їхні
ідеї про те, що програмне забезпечення має надавати та які функції вони хочуть
включити до програмного забезпечення.
Специфікація вимог до програмного забезпечення
SRS – це документ, створений системним аналітиком після збору вимог
різних зацікавлених сторін.
SRS визначає, як передбачуване програмне забезпечення взаємодіятиме з
апаратним забезпеченням, зовнішніми інтерфейсами, швидкістю роботи, часом
відгуку системи, переносимість програмного забезпечення різні платформи,
ремонтопридатність, швидкість відновлення після збою, безпеку, якість,
обмеження тощо.
Вимоги, отримані від клієнта, написані природною мовою. Системний
аналітик зобов'язаний документувати вимоги технічною мовою, щоб вони могли
бути зрозумілі та корисні для команди розробників програмного забезпечення.
SRS повинен містити такі функції:
57
ЧДТУ. 2278.003 ПЗ
- Вимоги користувача висловлені природною мовою.
- Технічні вимоги висловлені структурованою мовою, яка
використовується всередині організації.
- Опис дизайну має бути написано у псевдокоді.
- Формат форм та друк графічного інтерфейсу.
- Умовні та математичні позначення для DFD тощо.
- Перевірка вимог до програмного забезпечення
Після того, як специфікації вимоги розроблені, вимоги, згадані в цьому
документі, підтверджуються. Користувач може попросити про незаконне,
непрактичне рішення, або експерти можуть неправильно інтерпретувати вимоги.
Вимоги можуть бути перевірені на відповідність до таких умов –
- Якщо вони можуть бути практично реалізовані.
- Якщо вони дійсні і відповідно до функціональності та області
програмного забезпечення.
- Якщо є якісь неясності.
- Якщо вони завершені.
- Якщо вони можуть бути продемонстровані.
3.2.2Вимоги замовника і розробника.
Для розробника : мінімальними вимогами для розробки програми і будуть
32-бітний процесор. Щонайменше 3 гігабайти оперативної пам`яті, звісно як і у
випадку з процесором можливо запустити базу навіть на 512 мегабайтах, але для
розробки в сучасних IDE та для стабільної роботи та подальшого росту бази
необхідні як мінімум 2 гб. Процесор з 2 ядрами. Також знадобиться жорсткий
диск, рекомендовано мати диск з об`ємом 128 гб та більше. Дисплей для
виведення інформації та периферія для введення.
Для замовника: особливі вимоги відстуні, для використання функціоналу
додатку буде достатньо будь-якого сучасного комп`ютера.
3.2.3 Функціональні та не функціональні вимоги
Функціональні вимоги.
58
ЧДТУ. 2278.003 ПЗ
Розроблена система повинна виконувати наступні функції:
1 Внесення даних по пунктам відправлення.
2 Внесення даних по пунктам отримання товару.
3 Внесення даних по вартості перевезення з кожного пункту відправлення
до кожного пункту отримання.
4 Внесення даних потребам до кожного пункту отримання товару.
5 Внесення даних запасів до кожного пункту відправлення товару.
6 Розрахунок опорного плану по методу мінімального елемента.
7 Розрахунок опорного плану по методу північно-західного кута.
8 Розрахунок опорного плану по методу Фогеля.
Повинно бути візуалізовано:
1 Матриця тарифів.
2 Транспортна таблиця з опорним планом північно-західного кута.
3 Транспортна таблиця з опорним планом мінімального елемента.
4 Транспортна таблиця з опорним планом Фогеля.
Розглянемо не функціональні вимоги.
Зручність використання
Інтерфейс користувача повинен бути Windows-сумісним.
Інтерфейс користувача повинен бути простим і не вимагати додаткового
навчання для користувачів.
Надійність
Система повинна бути в працездатному стані 24 год в день 7 днів на
тиждень, час простою - не більше 10%. Середній час безвідмовної роботи має
перевищувати 300 ч.
Продуктивність
Система повинна бути здатна завершувати 80% всіх транзакцій не більш
через 1 хв.
3.2.4 Формування вимог за допомогою діаграми прецедентів
59
ЧДТУ. 2278.003 ПЗ
Ідентифікувати прецеденти і дійові особи це один з найважливіших
моментів проектування системи. При ідентифікації виконуються наступні кроки
[17]:
- чітко розмежується система і її оточення;
- визначається, які дійові особи і як саме вони взаємодіють з системою,
який функціонал (варіанти використання) очікується від системи;
- визначається і описується в словнику предметної області (глосарії)
загальні поняття, які необхідні для детального опису функціоналу системи
(прецедентів).
Подібний вид діяльності зазвичай виконується в такій послідовності:
1. Визначення дійових осіб.
2. Визначення прецедентів (варіантів використання).
3. Складання опису кожного прецеденту.
4. Опис моделі прецедентів в цілому (цей етап включає в себе створення
словника предметної області).
Спочатку вимоги оформляються у вигляді звичайного текстового
документа, який створюється або самим користувачем, або користувачем і
розробником разом. Далі вимоги оформляють у вигляді таблиці. У ліву колонку
поміщають прецеденти, а в праву - дійових осіб, що беруть участь в прецеденті.
Для розробленої системи магістерської роботи було створено наступні
дійові особи або актори:
- Користувач.
- Система.
Далі виділено наступні прецеденти для системи:
- Обробка даних по пунктам відправлення.
- Обробка даних по пунктам отримання товару.
- Обробка даних по вартості перевезення з кожного пункту відправлення
до кожного пункту отримання.
- Обробка даних потреби до кожного пункту отримання товару.
60
ЧДТУ. 2278.003 ПЗ
- Обробка даних запасів до кожного пункту відправлення товару.
- Розрахунок опорного плану по методу мінімального елемента.
- Розрахунок опорного плану по методу північно-західного кута.
- Розрахунок опорного плану по методу Фогеля.
Виділено наступні прецеденти для користувача:
- Запуск системи
- Внесення даних по пунктам призначення
- Внесення даних по пунктам відправлення
- Внесення даних по вартості перевезення з пункту призначення до пункту
відправлення
- Внесення даних по потребам пунктам призначення
- Внесення даних по запасам по пунктам відправлення
- Контроль працездатності системи
- Контроль результатів діяльності системи
Виходячи з цих даних, розроблено таблицю прецедентів і акторів.
(Табл.3.1)
Діаграма прецедентів є графом, що складається з множини акторів,
прецедентів (варіантів використання) обмежених границею системи
(прямокутник), асоціацій між акторами та прецедентами, відношень серед
прецедентів, та відношень узагальнення між акторами[18]. Діаграми прецедентів
відображають елементи моделі варіантів використання.
Суть даної діаграми полягає в наступному: проектована система
представляється у вигляді безлічі сутностей чи акторів, що взаємодіють із
системою за допомогою так званих варіантів використання. Варіант
використання (англ. use case) використовують для описання послуг, які система
надає актору. Іншими словами, кожен варіант використання визначає деякий
набір дій, який виконує система при діалозі з актором. При цьому нічого не
говориться про те, яким чином буде реалізована взаємодія акторів із системою.
Таблиця 3.1
61
ЧДТУ. 2278.003 ПЗ
Таблиця прецедентів і акторів системи
Прецедент Актор
Обробка даних по пунктам відправлення. система
Обробка даних по пунктам отримання товару. система
Обробка даних по вартості перевезення з кожного пункту система
відправлення до кожного пункту отримання.
Обробка даних потреби до кожного пункту отримання товару. система
Обробка даних запасів до кожного пункту відправлення система
товару.
Розрахунок опорного плану по методу мінімального елемента. система
Розрахунок опорного плану по методу північно-західного кута. с истема
Розрахунок опорного плану по методу Фогеля. система
Внесення даних по пунктам призначення користувач
Внесення даних по пунктам відправлення користувач
Внесення даних по вартості перевезення з пункту призначення користувач
до пункту відправлення
Внесення даних по потребам пунктам призначення користувач
Внесення даних по запасам по пунктам відправлення користувач
Контроль працездатності системи користувач
контроль результатів діяльності системи користувач
У мові UML є кілька стандартних видів відношень між акторами і
варіантами використання:
- асоціації (англ. association relationship)
- включення (англ. include relationship)
- розширення (англ. extend relationship)
62
ЧДТУ. 2278.003 ПЗ
- узагальнення (англ. generalization relationship)
При цьому загальні властивості варіантів використання можуть бути
представлені трьома різними способами, а саме — за допомогою відношень
включення, розширення і узагальнення.
Включення (англ. include) у мові UML — це різновид відношення
залежності між базовим варіантом використання і його спеціальним випадком.
При цьому відношенням залежності (англ. dependency) є таке відношення між
двома елементами моделі, при якому зміна одного елемента (незалежного)
приводить до зміни іншого елемента (залежного).
Відношення розширення (англ. extend) визначає взаємозв'язок базового
варіанта використання з іншим варіантом використання, функціональна
поведінка якого задіюється базовим не завжди, а тільки при виконанні
додаткових умов [18].
Згідно таблиці опису прецедентів створено список прецедентів.
Рис. 3.1. – Графічне представлення діаграми прецедентів
3.2.5 Проектування логічної структури програмного комплексу
3.2.5.1 Діаграма класів
Діагра́ма кла́сів — статичне представлення структури моделі. Відображає
статичні (декларативні) елементи, такі як: класи, типи даних, їх зміст та
відношення. Діаграма класів може містити позначення для пакетів та може
63
ЧДТУ. 2278.003 ПЗ
містити позначення для вкладених пакетів. Також, діаграма класів може містити
позначення деяких елементів поведінки, однак їх динаміка розкривається в
інших типах діаграм. Діаграма класів служить для представлення статичної
структури моделі системи в термінології класів об'єктноорієнтованого
програмування. На цій діаграмі показують класи, інтерфейси, об'єкти й
кооперації, а також їхні відносини В UML існують такі типи зв'язків:
Асоціації
Асоціація показує, що об'єкти однієї сутності (класу) пов'язані з об'єктами
іншої сутності.
Якщо між двома класами визначена асоціація, то можна переміщатися від
об'єктів одного класу до об'єктів іншого. Цілком припустимі випадки, коли
обидва кінці асоціації відносяться до одного і того ж класу. Це означає, що з
об'єктом деякого класу дозволено зв'язати інші об'єкти з того ж класу. Асоціація,
що зв'язує два класи, називається бінарною. Можна, хоча це рідко буває
необхідним, створювати асоціації, що зв'язують відразу кілька класів; вони
називаються n-арними. Графічно асоціація зображується у вигляді лінії, що
з'єднує клас сам з собою або з іншими класами.
Асоціації може бути присвоєно ім'я, яке описує природу відносин.
Зазвичай ім'я асоціації не вказується, якщо тільки ви не хочете явно задати для
неї рольові імена або у вашій моделі настільки багато асоціацій, що виникає
необхідність посилатися на них і відрізняти один від одного. Ім'я буде особливо
корисним, якщо між одними і тими ж класами існує кілька різних асоціацій.
Клас, що бере участь в асоціації, грає в ній деяку роль. По суті, це
«обличчя», яким клас, що знаходиться на одній стороні асоціації, звернений до
класу з іншого її боку. Ви можете явно позначити роль, яку клас грає в асоціації.
Часто при моделюванні буває важливо вказати, скільки об'єктів може бути
пов'язано допомогою одного примірника асоціації. Це число називається
кратністю (Multiplicity) ролі асоціації та записується або як вираз, значенням
якого є діапазон значень, або в явному вигляді. Вказуючи кратність на одному
64
ЧДТУ. 2278.003 ПЗ
кінці асоціації, ви тим самим говорите, що на цьому кінці саме стільки об'єктів
повинно відповідати кожному об'єкту на протилежному кінці. Кратність можна
задати рівною одиниці (1), можна вказати діапазон: «нуль або одиниця» (0..1),
«багато» (0 .. *), «одиниця або більше» (1 .. *). Дозволяється також вказувати
певне число (наприклад, 3). За допомогою списку можна задати і більш складні
кратності, наприклад 0. . 1, 3..4, 6 .. *, що означає «будь-яке число об'єктів, крім
2 і 5».
Агрегація
Агрегація — проста асоціація між двома класами, яка відображає
структурне відношення між рівноправними сутностями, коли обидва класи
знаходяться на одному концептуальному рівні, і жоден з них не важливіший за
решту. Але іноді доводиться моделювати відношення типу «частина/ціле», в
якому один з класів має вищий ранг (ціле) і складається з декількох менших за
рангом (частин). Ставлення такого типу називають агрегацією; воно зараховане
до відносин типу «має» (з урахуванням того, що об'єкт-ціле має кілька
об'єктівчастин). Агрегація є окремим випадком асоціації і її зображують як
просту асоціацію з незафарбованим ромбом з боку «цілого».
Графічно агрегація представлена порожнім ромбом на блоці класу, і
лінією, яка проведена від цього ромба до класу, що міститься в ньому.
Композиція
Композиція — більш строгий варіант агрегації. Відома також як агрегація
за значенням.[28]
Композиція має жорстку залежність часу існування екземплярів класу
контейнера та екземплярів класів що містяться в ньому. Якщо контейнер буде
знищений, то весь його вміст буде також знищено.
65
ЧДТУ. 2278.003 ПЗ
Рис. 3.2. - Діаграма класів «Розрахунок рішення ТЗ»
3.2.5.2 Діаграма пакетів
Діаграма пакетів (Package diagram) — єдиний засіб, що дозволяє управляти
складністю самої моделі.
Для подання груп класів в мові UML передбачено поняття пакета. Пакети
є блоки сильносвязанних класів, які самі утворюють якесь єдине ціле, але слабо
пов'язані з іншими подібними кластерами.
Пакети можуть бути вкладеними. Це дозволяє здійснювати декомпозицію
великих систем на підсистеми, модулі і т.д. Зовнішній пакет отримує доступ до
будь-якого класу, який безпосередньо міститься в його вкладених пакетах.
Класом може володіти тільки один пакет. Це не перешкоджає появі класу
в інших пакетах або взаємодії з класами в інших пакетах. Використовуючи
оголошення класу всередині пакету як закритого, захищеного або відкритого,
можна контролювати взаємодію і залежності між класами в різних пакетах.
Пакет зображується у вигляді піктограми папки. Вкладені пакети
зображуються всередині зовнішнього пакета. Для кожного пакету повинна бути
побудована власна діаграма класів, яка визначає всі класи, що належать пакету.
Пакети можуть бути пов'язані між собою двома типами відносин:
узагальненням і залежністю.
66
ЧДТУ. 2278.003 ПЗ
Пакети створюються в діаграмі класів або діаграмі прецедентів. У першому
випадку діаграма пакетів представляє модель системи з точки зору її станів. У
другому випадку - з точки зору поведінки системи.
Діаграма пакетів для станів описує архітектурну основу системи.
Поведінкова діаграма пакетів служить тільки в якості опису високорівневою
функціональної структури. Діаграма пакетів для станів допомагає в управлінні
масштабами і складністю системи. Вона також грає важливу роль в якості
механізму доступу і конфігураційного управління, що сприяє співпраці
розробників.
Діаграма пакетів є діаграму, яка містить пакети класів і залежності між
ними.
У мові UML визначені три стереотипу класів:
1) Прикордонні - описують об'єкти, які представляють інтерфейси між
суб'єктом і системою.
2) Керуючі - описують об'єкти, які перехоплюють свої вхідні події,
ініційовані користувачем і контролює виконання бізнес-процесу.
3) Класи-сутності - описують об'єкти, які представляють семантику
сутностей, що належать предметної області. Вони співвідносяться зі
структурами даних системної БД.
Керуючі об'єкти маніпулюють взаємодіями між подіями, ініційованими
користувачами, і впливають на об'єкти-сутності і прикордонні об'єкти. Зокрема,
кожному прикордонному об'єкту, який допускає взаємодію, повинен бути
поставлений у відповідність пов'язаний з ним керуючий об'єкт. Тому деякі типи
архітектури ПО об'єднують дві функції в одному класі.
67
ЧДТУ. 2278.003 ПЗ
Рис. 3.3 - Діаграма пакетів (Package diagram).
3.3.Архітектурне проектування
3.3.1 Діаграма компонентів
Діаграма компонентів (Component diagram) — показує взаємозв'язки між
модулями (логічними або фізичними), з яких складається система, що
моделюється.
Рис. 3.4 — Діаграма компонентів (Component diagram).
Основний тип сутностей на діаграмі компонентів — це самі компоненти, а
також інтерфейси, за допомогою яких вказується взаємозв'язок між
компонентами.
68
ЧДТУ. 2278.003 ПЗ
3.3.2 Діаграма розгортання
Діаграма розгортання — діаграма в UML, на якій відображаються
обчислювальні вузли під час роботи програми, компоненти, та об'єкти, що
виконуються на цих вузлах. Компоненти відповідають представленню робочих
екземплярів одиниць коду. Компоненти, що не мають представлення під час
роботи програми на таких діаграмах не відображаються; натомість, їх можна
відобразити на діаграмах компонент. Діаграма розгортання відображає робочі
екземпляри компонент, а діаграма компонент, натомість, відображає зв'язки між
типами компонент.
Фізичне представлення програмної системи не може бути повним, якщо
відсутня інформація про те, на якій платформі і на яких обчислювальних засобах
вона реалізована. Діаграма розгортання призначена для візуалізації елементів і
компонентів програми, які існують лише на етапі її виконання (runtime). При
цьому подаються тільки компоненти-екземпляри програми, які є здійснимими
файлами або динамічними бібліотеками. Ті компоненти, які не
використовуються на етапі виконання, на діаграмі розгортання не
відображаються. Так, компоненти з вихідними текстами програм можуть бути
присутніми тільки на діаграмі компонентів. На діаграмі розгортання вони не
вказуються.
Рис 3.5 Діаграма розгортання
69
ЧДТУ. 2278.003 ПЗ
Діаграма розгортання містить графічні зображення процесорів, пристроїв,
процесів і зв'язків між ними. На відміну від діаграм логічного представлення,
діаграма розгортання є єдиною для системи в цілому, оскільки повинна повністю
відображати особливості її реалізації. Ця діаграма, по суті, завершує процес
ООАП для конкретної програмної системи і її розробка, як правило, є останнім
етапом специфікації моделі.
3.3.3 Моделювання поведінки системи
3.3.3.1 Діаграма діяльності
Діаграма діяльності потрібна для того щоб описати логіку процедур,
бізнес-процеси і потоки. У багатьох випадках вони нагадують блок схеми, але
принципова різниця між діаграмами діяльності і нотацією блок-схем полягає в
тому, що перші підтримують паралельне процеси.
Основний набір символів діаграми діяльності, необхідний для того, щоб
зуміти прочитати діаграму:
Початковий вузол - старт діаграми.
Розгалуження - має один вхідний потік і кілька вихідних паралельних
потоків.
Потік / ребро - в UML 2 паралельно вживаються терміни потік і ребро для
позначення зв'язку між двома операціями. Самий простий вид ребра - це
звичайна стрілка між двома операціями.
Рішення - кожен раз при досягненні рішення вибирається тільки один з
вихідних потоків, тому вони повинні бути взаємно виключаючими.
Злиття - завершення умовної поведінки, яка була розпочата рішенням.
Об'єднання - при наявності паралелізму необхідна синхронізація. Ми не
закриваємо замовлення, поки віно не оплачено і не доставлено.
Кінець діяльності - закінчення діаграми.
Тимчасової сигнал - приходить з часом. Такі сигнали можуть означати
кінець місяця в звітному періоді або приходити кожну секунду в контролері
реального часу.
70
ЧДТУ. 2278.003 ПЗ
Найбільша перевага діаграм діяльності полягає в тому, що вони
підтримують і стимулюють застосування паралельних процесів. Саме завдяки
цьому вони являють собою могутній засіб моделювання потоків робіт.
На даний момент діаграми діяльності не відносяться до найбільш
поширених технологій мови UML, і всі їхні попередники в області моделювання
потоків також не користувалися успіхом. Технологія діаграм ще не досягла
необхідного рівня для опису поведінки таким способом.
Діаграма діяльності піддавалася найбільшим змінам при зміні версій мови
UML, тому не дивно, що вона були знову змінена і істотно розширена в UML 2.
В UML 1 діаграма діяльності розглядалася як особливий випадок діаграм станів.
Це викликало чимало труднощів у фахівців, що моделюють потоки робіт, для
яких добре підходять діаграми діяльності. В UML 2 це обмеження було
ліквідовано.
Діаграма діяльності дозволяє будь-кому, хто виконує цей процес, вибирати
порядок дій. Іншими словами, діаграма тільки встановлює правила обов'язкової
послідовності дій, яким я повинен слідувати. Це важливо для моделювання
бізнес-процесів, оскільки ці процеси часто виконуються паралельно. Такі
діаграми також корисні при розробці паралельних алгоритмів, в яких незалежні
потоки можуть виконувати роботу паралельно.
Рис. 3.6 - Діаграма діяльності
71
ЧДТУ. 2278.003 ПЗ
3.3.3.2 Діаграма послідовності
Діаграма послідовності використовується для того щоб зобразити об'єкти,
які беруть участь у взаємодії і послідовності повідомлень, якими вони
обмінюються.
Основний набір символів діаграми послідовності, необхідний для того,
щоб зуміти прочитати діаграму:
Знайдене повідомлення - у першого повідомлення немає учасника, який
послав його, оскільки воно приходить з невідомого джерела. Воно називається
знайденим повідомленням.
Повідомлення - команда, що відправляється іншому учаснику. Може
містити тільки дані, що передаються.
Лінія життя - кожна лінія життя має смугу активності, яка показує інтервал
активності учасника при взаємодії. Вона відповідає часу знаходження в стеці
одного з методів учасника.
Учасник - у більшості випадків можна вважати учасників діаграми
взаємодії об'єктами, як це і було в дійсності в UML 1. Але в UML 2 їх роль значно
складніше. Тому тут вживається термін учасники, який формально не входить в
специфікацію UML.
Самовизов - учасник відправляє повідомлення самому собі.
Повернення - передача управління назад учаснику, який до цього ініціював
повідомлення.
Активація - на зображенні це - білий вертикальний прямокутник. Момент,
коли учасник починає діяти у відповідь на отримане повідомлення.
Створення - у разі створення учасника треба намалювати стрілку
повідомлення, у напрямку до прямокутника учасника. Якщо застосовується
конструктор, то ім'я повідомлення не обов'язково, але можна маркувати його
словом «new» в будь-якому випадку. Якщо учасник виконує що-небудь
безпосередньо після створення, наприклад команду запиту, то треба
72
ЧДТУ. 2278.003 ПЗ
Рис. 3.7 - Діаграма послідовності
Самовидалення - видалення учасника позначається великим хрестом (X).
X в кінці лінії життя показує, що учасник видаляє сам себе.
Видалення з іншого об'єкта - видалення учасника позначається великим
хрестом (X). Стрілка повідомлення, що йде в X, означає, що один учасник явно
удаляє іншого.
Діаграми послідовності слід застосовувати тоді, коли потрібно подивитися
на поведінку декількох об'єктів в рамках одного прецеденту. Діаграми
послідовності гарні для подання взаємодії об'єктів, але не дуже підходять для
точного визначення поведінки.
3.3.3.3 Діаграма комунікації
Діаграма комунікації точно так само, як і діаграма послідовності UML, є
транзитивною, тобто виражає в собі взаємодію, але при цьому демонструє його
різними способами, і при необхідності з потрібним ступенем точності можна
перетворити одну в іншу. Діаграма комунікації відображає в собі взаємодії, які
відбуваються між різними елементами композитної структури, а також ролями
кооперації. Головною відмінністю її від діаграми послідовності є те, що на ній
досить явно вказуються зв'язки між елементами, а час не використовується в
якості окремого вимірювання. Даний тип відрізняється абсолютно вільним
форматом впорядкування декількох об'єктів і зв'язків точно так само, як це
здійснюється в діаграмі об'єктів. Якщо є необхідність у тому, щоб підтримувати
73
ЧДТУ. 2278.003 ПЗ
порядок повідомлень при цьому вільному форматі, здійснюється їх хронологічна
нумерація. Читання даної діаграми починається з початкового повідомлення 1.0
і згодом продовжується з того напрямку, за яким здійснюється передача
повідомлень від одного об'єкта до іншого. В більшості своїй такі діаграми
демонструють точно таку ж інформацію, яку надає нам діаграма послідовності,
проте із-за того, що тут використовується інший спосіб представлення
інформації, визначені речі на одній діаграмі стає набагато легше визначити, ніж
на іншій. [25]
Рис. 3.8 - Діаграма комунікації
3.3.3.4 Діаграма скінченого автомату
Діаграми скінчених автоматів (англ. state machine) використовуються для
опису поведінки, що реалізується в рамках варіанта використання, або поведінки
екземпляра сутності (класу, об'єкта, компонента, вузла або системи в цілому) [30].
Поведінка моделюється через опис можливих станів екземпляра сутності та
переходів між ними протягом його життєвого циклу, починаючи від створення та
закінчуючи знищенням. Діаграма автоматів є зв'язний орієнтований граф,
вершинами якого є стани, а дуги служать позначення переходів зі стану на стан.
Під станом (англ. state) розуміється ситуація в ході життя екземпляра
сутності, коли ця ситуація задовольняє певній умові, екземпляр виконує деякі
операції або чекає настання деякої події. Наприклад, для об'єкта його стан може
74
ЧДТУ. 2278.003 ПЗ
бути заданий у вигляді набору конкретних значень атрибутів, при цьому зміна цих
значень призведе до зміни стану об'єкта, що моделюється.
У UML розрізняють два види операцій: дію та діяльність. Дія (англ. action)
- це атомарна операція, виконання якої не може бути перервано, що призводить
до зміни стану або повертає значення. Прикладами дій є операції створення або
знищення об'єкта, розрахунок факторіалу і т. д. Діяльність (англ. activity) – це
складова (неатомарна) операція, що реалізується екземпляром у конкретному
стані, виконання якої може бути перервано. Зокрема, під діяльністю можна
розуміти процедури розрахунку допустимих швидкостей або шифрування даних.
Подія (англ. event) - це специфікація суттєвого факту, який може відбутися
у конкретний момент часу. Події можуть бути внутрішніми чи зовнішніми.
Зовнішні події передаються між системою та акторами (наприклад, натискання
кнопки або надсилання сигналу від датчика пересування). Внутрішні події
передаються між об'єктами усередині системи. У UML можна моделювати такі
види подій.
Виклик – специфікація факту посилки синхронного повідомлення між
об'єктами, що наказує виконання операції (дії чи діяльності) об'єктом, якому
надсилається повідомлення. Синхронність означає, що після здійснення виклику
об'єкт-відправник передає управління об'єкту-отримувачу і після виконання
останнім операції отримує управління назад. Наприклад, зафарбувати фігуру
червоним тлом fill(red) чи розрахувати допустимі швидкості calculateVdop().
Сигнал – специфікація факту надсилання асинхронного повідомлення між
об'єктами. Винятки, що підтримуються у більшості сучасних мов програмування,
є найпоширенішим видом внутрішніх сигналів.
Подія часу – специфікація факту, що означає настання конкретного часу
(англ. absolute time) чи закінчення певного проміжку часу (англ. relative time). У
UML цей факт позначається за допомогою ключових слів «at» (наприклад, at
9:00:00) та «after» (наприклад, after 2 seconds).
75
ЧДТУ. 2278.003 ПЗ
Зміна стану – специфікація логічної умови, що відповідає зміні стану
екземпляра сутності. У UML воно позначається за допомогою ключового слова
"when" (наприклад, when A < B) або сторожової умови (наприклад, [A < B]).
По темі магістерської роботи була створена наступна діаграма скінченого
автомату, яка описує стани системи під час внесення даних і виводу даних на
екран.
Рис. 3.9 - Діаграма скінченого автомату
76
ЧДТУ. 2278.003 ПЗ
Висновки до третього розділу
Для моделювання і опису усіх процесів, що протікали під час розробки
додатку, застосовувалась уніфікована мова моделювання (UML). Усі діаграми
можна умовно розділити на поведінкові і структурні. Поведінкові діаграми
відображають процеси, що протікають у модельованому середовищі. Структурні
діаграми відображають елементи, з яких складається система. При цьому одні й
ті ж типи діаграм можуть використовуватися як для моделювання бізнес-
процесів, так і для безпосереднього проектування архітектури.
Одне із завдань UML — служити засобом спілкування всередині команди
та спілкування із замовником. Розгляньмо можливі варіанти використання
діаграм.
Дизайн. Діаграми UML допоможуть вам змоделювати архітектуру великих
проектів, де ви зможете зібрати як великі, так і дрібні деталі та намалювати
каркас (діаграму) програми. Код буде збудований на ньому пізніше.
Зворотне проектування — створення моделі UML з існуючого програмного
коду, зворотна побудова. Його можна використовувати, наприклад, у проектах
підтримки, де є написаний код, але документація неповна або відсутня.
По темі магістерської роботи було створено наступні діаграми: діаграма
розгортання, діаграма комунікації, діаграма діяльності, діаграма компонентів,
діаграма пакетів, діаграма класів, діаграма послідовностей та діаграма
прецедентів.
.
77
ЧДТУ. 2278.003 ПЗ
РОЗДІЛ 4
КОНСТРУЮВАННЯ ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
Засобами програмної розробки проекту кваліфікаційної роботи магістра
вибрано JDBC, Java, MySQL, Spring Framework, Spring Security.
4.1 Обґрунтування вибору засобів реалізації
JDBC (англ. Java DataBase Connectivity - з'єднання з базами даних на Java)
- платформенно - незалежний промисловий стандарт взаємодії Java -додатків з
різними СУБД, реалізований у вигляді пакета java.sql, що входить до складу Java
SE [20].
JDBC заснований на концепції так званих драйверів, що дозволяють
отримувати з'єднання з базою даних за спеціально описаного URL. Драйвери
можуть завантажуватися динамічно ( під час роботи програми). Завантажившись,
драйвер сам реєструє себе і викликається автоматично, коли програма вимагає
URL, що містить протокол, за який драйвер відповідає.
JDBC API містить два основних типи інтерфейсів: перший - для
розробників додатків і другий ( більш низького рівня ) - для розробників
драйверів.
З'єднання з базою даних описується класом, що реалізує інтерфейс
java.sql.Connection.
Маючи з'єднання з базою даних, можна створювати об'єкти типу Statement,
службовці для виконання запитів до бази даних на мові SQL.
Існують наступні види типів Statement, що розрізняються за призначенням
:
- java.sql.Statement - Statement загального призначення;
- java.sql.PreparedStatement - Statement, службовець для виконання
запитів, що містять підставляються параметри (позначаються символом '?' в
тілі запиту ) ;
78
ЧДТУ. 2278.003 ПЗ
- java.sql.CallableStatement - Statement, призначений для виклику
збережених процедур.
Інтерфейс java.sql.ResultSet дозволяє легко обробляти результати запиту.
Перевагами JDBC вважають:
- легкість розробки: розробник може не знати специфіки бази даних, з
якою працює;
- код не змінюється, якщо компанія переходить на іншу базу даних; -
не потрібно встановлювати громіздку клієнтську програму;
- до будь-якої базі можна під'єднатися через легко описуваний URL.
JavaScript (JS) — динамічна, об'єктно-орієнтована прототипна мова
програмування. Реалізація стандарту ECMAScript. Найчастіше
використовується для створення сценаріїв веб-сторінок, що надає можливість на
стороні клієнта (пристрої кінцевого користувача) взаємодіяти з користувачем,
керувати браузером, асинхронно обмінюватися даними з сервером, змінювати
структуру та зовнішній вигляд веб-сторінки.
JavaScript класифікують як прототипну (підмножина
об'єктноорієнтованої), скриптову мову програмування з динамічною типізацією.
Окрім прототипної, JavaScript також частково підтримує інші парадигми
програмування (імперативну та частково функціональну) і деякі відповідні
архітектурні властивості, зокрема: динамічна та слабка типізація, автоматичне
керування пам'яттю, прототипне наслідування, функції як об'єкти першого класу.
Мова JavaScript використовується для:
• написання сценаріїв веб-сторінок для надання їм інтерактивності;
• створення односторінкових веб-
застосунків (React, AngularJS, Vue.js);
• програмування на стороні сервера (Node.js);
• стаціонарних застосунків (Electron, NW.js);
• мобільних застосунків (React Native, Cordova);
79
ЧДТУ. 2278.003 ПЗ
• сценаріїв в прикладному ПЗ (наприклад, в
програмах зі
складу Adobe Creative Suite чи Apache JMeter);
• всередині PDF-документів тощо.
Незважаючи на схожість назв, мови Java та JavaScript є двома різними
мовами, що мають відмінну семантику, хоча й мають схожі риси в стандартних
бібліотеках та правилах іменування. Синтаксис обох мов отриманий «у спадок» від
мови С, але семантика та дизайн JavaScript є результатом впливу мов Self та
Scheme.
JavaScript має низку властивостей об'єктно-орієнтованої мови, але завдяки
концепції прототипів підтримка об'єктів в ній відрізняється від традиційних мов
ООП. Крім того, JavaScript має ряд властивостей, притаманних
функціональним мовам, — функції як об'єкти першого класу, об'єкти як списки,
каррінг, анонімні функції, замикання (closures) — що додає мові додаткову
гнучкість.
JavaScript має C-подібний синтаксис, але в порівнянні з мовою C має такі
корінні відмінності:
• об'єкти, з можливістю інтроспекції і динамічної зміни типу через
механізм прототипів
• функції як об'єкти першого класу
• обробка винятків
• автоматичне приведення типів
• автоматичне збирання сміття
• анонімні функції
Семантика мови схожа з семантикою мови Self.
4.2. Опис структурної і функціональної схеми
Процес проектування складного програмного забезпечення починається з
уточнення його структури, тобто визначення структурних компонентів та зв'язків
80
ЧДТУ. 2278.003 ПЗ
між ними. Результат уточнення структури може бути представлений у вигляді
структурної та/або функціональної схем та опису (специфікацій) компонентів.
Структурною називають схему, що відображає склад і взаємодію з
управління частин програмного забезпечення, що розробляється.
Структурні схеми пакетів програм не інформативні, оскільки організація
програм пакети передбачає передачі управління з-поміж них. Тому структурні
схеми розробляють кожної програми пакета, а список програм пакета визначають,
аналізуючи функції, зазначені у технічному завданні.
Найпростіший вид програмного забезпечення - програма, яка як структурні
компоненти може включати лише підпрограми та бібліотеки ресурсів. Розробку
структурної схеми програми зазвичай виконують методом покрокової деталізації.
Рис.4.1 – Структурна схема ПЗ
Структурними компонентами програмної системи чи програмного
комплексу можуть бути програми, підсистеми, бази даних, бібліотеки ресурсів
тощо.
Структурна схема, зазвичай, показує наявність підсистем чи інших
структурних компонентів. На відміну від програмного комплексу, окремі частини
(підсистеми) програмної системи інтенсивно обмінюються даними між собою і,
81
ЧДТУ. 2278.003 ПЗ
можливо, з основною програмою. Структурна схема програмної системи цього
зазвичай не показує.
4.3. Опис логічної схеми системи
Логічною схемою називається сукупність логічних електронних елементів,
з'єднаних між собою таким чином, щоб виконувався заданий закон
функціонування схеми, інакше кажучи, виконувалася задана логічна функція.
За залежністю вихідного сигналу від вхідного все електронні логічні схеми
можна умовно розбити на: схеми першого роду, тобто. комбінаційні схеми,
вихідний сигнал яких залежить від стану вхідних сигналів у кожний момент часу;
схеми другого роду або накопичуючі схеми (схеми послідовні), що містять
накопичувальні схеми (елементи з пам'яттю), вихідний сигнал яких залежить як
від вхідних сигналів, так і стану схеми в попередні моменти часу. За кількістю
входів та виходів схеми бувають: з одним входом та одним виходом, з кількома
входами та одним виходом, з одним входом та кількома виходами, з кількома
входами та виходами.
За способом здійснення синхронізації схеми бувають із зовнішньою
синхронізацією, із внутрішньою синхронізацією. Практично будь-який комп'ютер
складається з комбінації схем першого та другого роду різної складності.
Таким чином, основою будь-якого цифрового автомата, що обробляє
цифрову інформацію, є електронні елементи двох типів: логічні або комбінаційні
та запам'ятовуючі.
Логічні елементи виконують найпростіші логічні операції над цифровою
інформацією, а запам'ятовуючі служать її зберігання. Як відомо, логічна операція
полягає у перетворенні за певними правилами вхідної цифрової інформації у
вихідну.
Можна вважати, елементарні логічні функції є логічними операторами
згаданих електронних елементів, тобто. схем. Кожна така схема позначається
певним графічним символом.
82
ЧДТУ. 2278.003 ПЗ
Рис.4.2 – Структурна схема ПЗ
4.4 Розробка бази даних
По темі магістерської кваліфікаційної роботи база даних не була
розроблена. Поставлене завдання було виконано вирішивши задачу програмної
реалізації математичних методів без зберігання даних, що було і затверджено
керівником магістерської кваліфікаційної роботи.
4.4 Розробка інтерфейсу користувача
При запуску системи відкривається діалогове вікно для внесення даних по
кількості пунктів відправлення і кількості пунктів призначення.
Рис.4.3 – Внесення даних по кількості місць
83
ЧДТУ. 2278.003 ПЗ
Після внесення необхідних даних натискаємо кнопку «Примінити» і
отримуємо наступне вікно. Рис.4.4
Рис.4.4 – Відкриття таблиці опорного плану
В новому вікні з`явилась таблиця опорного плану транспортної задачі.
Наступним кроком є введення тарифів перевезення з пунктів відправлення до
пунктів призначення. Ці дані мжна вносити як з клавіатури, так і натискаюи
кнопки біля кожного поля.
Також вносимо дані по потребам кожного пункту призначення, та по
запасам кожного пункту відправлення.Рис.4.5.
Рис.4.5 – Внесення даних
Після внесення даних натискаємо кнопку «Найти опорній план» і
отримуємо рішення транспортної задачі, тобто пошуку оптимального шляху,
трьома методами описаними в четвертому розділі.
84
ЧДТУ. 2278.003 ПЗ
Рис.4.6 – Рішення методом північно-західного кута
Як бачимо з результатів, вартість перевозки по такому маршруту буде
складати 652 грошові одиниці.
Рис.4.7 – Рішення методом мінімального елемента
Як бачимо з результатів, вартість перевозки по такому маршруту буде
складати 603 грошові одиниці.
Рис.4.8 – Рішення методом Фогеля
Як бачимо з результатів, вартість перевозки по такому маршруту буде
складати 591 грошова одиниця.
85
ЧДТУ. 2278.003 ПЗ
Після кожної таблиці ми отримуємо результати розрахунку перевезень
товару. Як бачимо рішення транспортної задачі методом Фогеля дає найменші
витрати на перевезення.
4.5. Опис розробки програмних компонентів
Сторінки - це лише кутові компоненти. Таким чином, і сторінки, і
компоненти перевіряються, використовуючи вказівки щодо перевірки
компонентів.
Оскільки сторінки та компоненти містять і код TypeScript, і розмітку
шаблону HTML, можна виконати як тестування класу компонентів, так і
тестування DOM компонента. Коли створюється сторінка, сформований тест
шаблону виглядає приблизно так:
import{CUSTOM_ELEMENTS_SCHEMA}from'@angular/core';
import{async, ComponentFixture, TestBed }from'@angular/core/testing';
import{ TabsPage }from'./tabs.page';
describe('TabsPage',()=>{
let component: TabsPage;
let fixture: ComponentFixture<TabsPage>;
beforeEach(async()=>{
TestBed.configureTestingModule({
declarations:[TabsPage],
schemas:[CUSTOM_ELEMENTS_SCHEMA],
}).compileComponents();
});
beforeEach(()=>{
fixture= TestBed.createComponent(TabsPage);
component= fixture.componentInstance;
fixture.detectChanges();
86
ЧДТУ. 2278.003 ПЗ
});
it('should create',()=>{
expect(component).toBeTruthy();
});
});
Ось приклад, який реалізує кілька основних методів, які потрібно
підтримувати всім об'єктам сторінки.
import{ browser, by, element, ExpectedConditions }from'protractor';
exportclassPageObjectBase{
private path:string;
protected tag:string;
constructor(tag: string, path: string){
this.tag = tag;
this.path = path;
}
load(){
return browser.get(this.path);
}
rootElement(){
returnelement(by.css(this.tag));
}
waitUntilInvisible(){
browser.wait(ExpectedConditions.invisibilityOf(this.rootElement()),3000);
}
waitUntilPresent(){
browser.wait(ExpectedConditions.presenceOf(this.rootElement()),3000);
}
87
ЧДТУ. 2278.003 ПЗ
waitUntilNotPresent(){
browser.wait(
ExpectedConditions.not(ExpectedConditions.presenceOf(this.rootElement())),
3000
);
}
waitUntilVisible(){
browser.wait(ExpectedConditions.visibilityOf(this.rootElement()),3000);
}
getTitle(){
return element(by.css(`${this.tag} ion-title`)).getText();
}
protectedenterInputText(sel: string, text: string){
const el =element(by.css(`${this.tag}${sel}`));
const inp = el.element(by.css('input'));
inp.sendKeys(text);
}
protectedenterTextareaText(sel: string, text: string){
const el =element(by.css(`${this.tag}${sel}`));
const inp = el.element(by.css('textarea'));
inp.sendKeys(text);
}
protectedclickButton(sel: string){
const el =element(by.css(`${this.tag}${sel}`));
browser.wait(ExpectedConditions.elementToBeClickable(el));
el.click();
}
}
88
ЧДТУ. 2278.003 ПЗ
4.6 Тестування системи
4.6.1 Модульне тестування
Кожна складна програмна система складається з окремих частин - модулів,
що виконують ту чи іншу функцію в складі системи. Для того, щоб упевнитися в
коректній роботі системи в цілому, необхідно спочатку протестувати кожен
модуль системи окремо. У разі виникнення проблем це дозволить простіше
виявити модулі, що викликали проблему, і усунути відповідні дефекти в них.
Таке тестування модулів окремо отримало називання модульного тестування (
unit testing). Для кожного модуля, що піддається тестуванню, розробляється
тестове оточення, що включає в себе драйвер і заглушки, готуються тест-вимоги
і тестплани, описують конкретні тестові приклади.
Основна мета модульного тестування - впевнитись у відповідності вимогам
кожного окремого модуля системи перед тим, як буде проведена його інтеграція
до складу системи. При цьому в ході модульного тестування вирішуються чотири
основні завдання.
1 Пошук і документування невідповідностей вимогам - це класична
завдання тестування, що включає в себе не тільки розробку тестового оточення і
тестових прикладів, а й виконання тестів, протоколювання результатів
виконання, складання звітів про проблеми.
2 Підтримка розробки та рефакторинга низькорівневої архітектури
системи і міжмодульного взаємодії - це завдання більше властива "легким"
методологіям типу XP, де застосовується принцип тестування перед розробкою
(Test-driven development), при якому основним джерелом вимог для програмного
модуля є тест, написаний до самого модуля . Однак, навіть при класичній схемі
тестування модульні тести можуть виявити проблеми в дизайні системи та
нелогічні або заплутані механізми роботи з модулем.
3 Підтримка рефакторинга модулів - це завдання пов'язане з підтримкою
процесу зміни системи. Досить часто в ході розробки потрібно проводити
рефакторінг модулів або їх груп - оптимізацію або повну переробку програмного
89
ЧДТУ. 2278.003 ПЗ
коду з метою підвищення його супроводженості, швидкості роботи або
надійності. Модульні тести при цьому є потужним інструментом для перевірки
того, що новий варіант програмного коду працює в точності так само, як і старий.
4 Підтримка усунення дефектів і налагодження - це завдання пов'язане зі
зворотним зв'язком, яку отримують розробники від тестувальників у вигляді
звітів про проблеми. Детальні звіти про проблеми, складені на етапі модульного
тестування, дозволяють локалізувати і усунути багато дефекти в програмній
системі на ранніх стадіях її розробки або розробки її нової функціональності.
В силу того, що модулі, що піддаються тестуванню, звичайно невеликі за
розміром, модульне тестування вважається найбільш простим (хоча і досить
трудомістким) етапом тестування системи. Однак, незважаючи на зовнішню
простоту, з модульним тестуванням пов'язано дві проблеми.
1 Не існує єдиних принципів визначення того, що в точності є окремим
модулем.
2 Відмінності в трактуванні самого поняття модульного тестування - чи
розуміється під ним відокремлений тестування модуля, робота якого
підтримується тільки тестовим оточенням, чи мова йде про перевірку
коректності роботи модуля в складі вже розробленої системи.
У ході модульного тестування програмного забезпечення була перевірка
взаємодії методів усередині класу і правильність доступу методів до внутрішніх
даних класу.
Не було виявлено дефектів об'єктно-орієнтованого програмного
забезпечення:
- дефектів інкапсуляції, в результаті яких, наприклад, приховані дані класу
виявляється недоступними за допомогою відповідних публічних методів;
- дефектів спадкування, за наявності яких схема успадкування блокує
важливі дані або методи від класів-нащадків;
- дефектів поліморфізму, при яких поліморфну поведінку класу
виявляється поширеним не на всі можливі класи;
90
ЧДТУ. 2278.003 ПЗ
- дефектів інстанцірованія, при яких в новостворюваних об'єктах класу не
встановлюються коректні значення за замовчуванням параметрів і внутрішніх
даних класу.
По темі магістерської роботи було проведено наступне функціональне
модульне тестування.
Таблиця 4.2 Функціональне модульне тестування
N Функціональні вимоги Проходження
1. Додати валідні значення відправки Passed
2. Додати валідні значення отримання Passed
3. Додати валідні значення вартості перевозки Passed
4. Додати валідні значення кількості пунктів прийому Passed
5. Додати валідні значення кількості пунктів розвозки Passed
4.6.2 Інтеграційне тестування
Інтеграційне тестування (англ. integration testing) — це фаза тестування
програмного забезпечення, під час якої окремі модулі програми комбінуються та
тестуються разом, у взаємодії. Інтеграційне тестування виконується після
модульного тестування та перед верифікацією та валідацією ПЗ. Якщо
розглядати цей процес як систему, то на вхід їй подаються модулі, які вже
пройшли модульне тестування; потім модулі групуються в більші частини,
виконуються тести передбачені планом, а на виході системи — інтегрована
система, що готова до системного тестування.
Метою інтеграційного тестування є верифікувати вимоги з
функціональності, продуктивності, надійності до основних компонентів
програми. Ці компоненти, тобто групи модулів, тестуються методом чорної
скриньки (англ. «black-box testing»), успішні та неуспішні тесткейси
симулюються відповідними вхідними параметрами.
91
ЧДТУ. 2278.003 ПЗ
В процесі інтеграційного тестування тестуються симульоване
використання спільних даних та комунікація між процесами. Тест-кейси
перевіряють чи коректно взаємодіють всі компоненти, наприклад: через виклик
процедури або активізацію процесу.
Серед різновидів інтеграційного тестування є: «big bang» тестування,
тестування зверху-донизу та знизу-вгору.
В цьому підході всі або більша частина розроблених модулів збираються
разом, формуючи завершену програмну систему або її значну частину та
використовуються для інтеграційного тестування. Цей метод дуже ефективний
для збереження часу тестування програмної системи. Тим не менше, якщо
тесткейси та їх результати не занотовані належним чином, весь процес стане
дуже складним та втратить сенс.
Тестування знизу-вгору — це такий підхід до тестування, коли першими
тестуються компоненти нижнього рівня, щоб полегшити тестування
високорівневих компонентів. Після інтеграційного тестування групи
компонентів певного рівня з них формується наступний рівень, який теж повинен
бути протестований. Цей підхід ефективний тільки коли всі модулі одного рівня
вже розроблені. Також цей підхід допомагає визначити які рівні системи вже
розроблені та виразити процес тестування в відсотках.
Тестування зверху-донизу — це такий підхід до тестування, коли
тестуються компоненти вищого рівня та гілки кожного з модулів тестуються
крок за кроком, поки модуль не буде протестований повністю.
При інтеграційному тестуванні програмного забезпечення була перевірка
інтерфейсів між компонентами, взаємодія з різними частинами системи, такими
як операційна система, файлова система та апаратне забезпечення, інтерфейси
між системами.
По темі магістерської роботи було проведено наступне функціональне
інтреграційне тестування.
92
ЧДТУ. 2278.003 ПЗ
Таблиця 4.3 Функціональне інтеграційне тестування
N Функціональні вимоги Проходження
Внесення валідних даних і відкриття
1. демонстраційного плану Passed
Внесення валідних даних і отримання опорних планів
2. Passed
Внесення валідних даних і отримання пустих
3. демонстраційних планів Passed
4.6.3 Системне тестування
Системне тестування програмного забезпечення - це тестування
програмного забезпечення (ПО), що виконується на повної, інтегрованій системі,
з метою перевірки відповідності системи вихідним вимогам. Системне
тестування відноситься до методів тестування чорного ящика, і, тим самим, не
вимагає знань про внутрішній устрій системи.
Основним завданням системного тестування є перевірка як
функціональних, так і не функціональних вимог до системи в цілому.
При цьому виявляються дефекти, такі як неправильне використання
ресурсів системи, непередбачені комбінації даних користувача рівня,
несумісність з оточенням, непередбачені сценарії використання, відсутня або
неправильна функціональність, незручність використання і т.д. Для мінімізації
ризиків, пов'язаних з особливостями поведінки системи в тому чи іншому
середовищі, під час тестування рекомендується використовувати оточення
максимально наближене до того, на яке буде встановлено продукт після видачі.
Можна виділити два підходи до системного тестування: -на
базі вимог (requirements based)
93
ЧДТУ. 2278.003 ПЗ
-на базі випадків використання (use case based) За часом проведення
тестування.[26]
Для магістерської роботи було проведено системне тестування на базі
вимог до розробки програмного забезпечення.
Таблиця 4.4
Функціональне системне тестування
N Функціональні вимоги Проходження
1. Робота системи в стретових умовах Passed
2. Робота системи під нагрузкою Passed
3. Запуск системи в різних браузерах Passed
4.6.4 Приймальне тестування
Приймальне тестування проводиться з метою: визначення чи задовольняє
система приймальні критерії там винесення рішення замовником або іншою
уповноваженою особою приймається програма чи ні.
Приймальне тестування виконується відповідно до Плану приймальних Робіт.
Рішення про проведення приймального тестування приймається, коли:
продукт досяг необхідного рівня якості та замовник ознайомлений з Планом
приймальних Робіт (Product Acceptance Plan) або іншим документом, де
описаний набір дій, пов’язаних з проведенням приймального тестування, дата
проведення, відповідальні і т.д.
Методи приймального тестування:
• Тестування замовником самостійно. Це ризиковано в тому плані що у
замовника може не бути творчих ресурсів, а завантаження по поточним
завданням може розтягти процес приймання.
• Тестування (Аудит) третьою стороною. Наймається спеціалізована
компанія на тестуванні або підписується договір з конкурентом постачальника
на надання послуг аудиту. Оптимально.
94
ЧДТУ. 2278.003 ПЗ
• Спільне тестування за сценаріями із замовником. Постачальник
допомагає готувати пакет матеріалів для приймального тестування, готує
команду замовника до методичного приймального тестування, контролює хід
приймального тестування і терміни його виконання. Присутність інженера з
тестування з боку виконавця допоможе краще зафіксувати розбіжності,
зауваження та виявлені дефекти.
Фаза приймального тестування триває до тих пір, поки замовник не
виносить рішення про відправлення програми на доопрацювання або реліз
програми.[27]
Так як розробка програмного забезпечення на завдання на магістерську
роботу, тому приймальне тестування було проведено мною.
95
ЧДТУ. 2278.003 ПЗ
Висновки до четвертого розділу
Засобами програмної розробки проекту магістерської роботи вибрано
JDBC, Java, MySQL, Spring Framework, Spring Security.
JDBC (англ. Java DataBase Connectivity - з'єднання з базами даних на Java)
- платформенно - незалежний промисловий стандарт взаємодії Java -додатків з
різними СУБД, реалізований у вигляді пакета java.sql, що входить до складу Java
SE.
JDBC заснований на концепції так званих драйверів, що дозволяють
отримувати з'єднання з базою даних за спеціально описаного URL. Драйвери
можуть завантажуватися динамічно ( під час роботи програми). Завантажившись,
драйвер сам реєструє себе і викликається автоматично, коли програма вимагає
URL, що містить протокол, за який драйвер
Також в главі представлено інтерфейс основних вікон програми та проведено
функціональне тестування системи.
96
ЧДТУ. 2278.003 ПЗ
ЗАГАЛЬНІ ВИСНОВКИ
Розглянувши поставлені питання можна сказати що глобальні
маркетингові і логістичні операції дозволяють компаніям домогтися ринкового
росту, значної економії за рахунок масштабів діяльності і підвищення
прибутковості. На світовому ринку підсилюється роль логістики і зростає
значення логістичного менеджменту.
В першому розділі проаналізовано методи вирішення логістичних завдань,
які умовно розбиваються на два класи: традиційні методи управління
матеріальними потоками, що домагаються ефекту за рахунок раціоналізації схем
руху товару і координації учасників логістичної системи; наукові методи
ефективного управління, що дозволяють оптимізувати витрати в логістичній
системі шляхом використання наукового апарату спеціальних дисциплін, таких
як: системний аналіз, теорія дослідження операцій, теорія оптимального
управління, прогнозний аналіз, теорія конфліктів, моделювання.
Представлена матриця транспортної задачі та методи вирішення опорного
плану транспортної задачі: метод мінімального елемента, метод
північнозахідного кута і метод Фогеля.
В другому розділі описано актуальність вивчення предметної області та
вивчено питання використання інформаційних технологій в логістиці.
В третьому розділі описано процес моделювання та створено наступні
діаграми: діаграма розгортання, діаграма комунікації, діаграма діяльності,
діаграма компонентів, діаграма пакетів, діаграма класів, діаграма послідовностей
та діаграма прецедентів.
В четвертому розділі представлено інтерфейс основних вікон програми та
описан процес проведенн функціонального тестування системи.
97
ЧДТУ. 2278.003 ПЗ
Список використаних джерел:
1 Сучасні тенденції розвитку внутрішньої торгівлі України.
[Електронний ресурс]. Режим доступу –
http://www.ukr.vipreshebnik.ru/torgovlya/4468suchasni-tendentsiji-rozvitku-
vnutrishnoji-torgivli-ukrajini.html
2 Электронная библиотека Князева Основи логістики. Кальченко А. Г.
[Електронний ресурс]. Режим доступу –
http://ebk.net.ua/Book/OsnlogKalchenko/6.4.htm
3 Розвиток логістики в Україні. [Електронний ресурс]. режим доступу -
http://www.rusnauka.com/31_PRNT_2010/Economics/73425.doc.htm
4 Сучасні тенденції розвитку внутрішньої торгівлі України.
[Електронний ресурс]. режим доступу -
http://ukr.vipreshebnik.ru/torgovlya/4468suchasni-tendentsiji-rozvitku-vnutrishnoji-
torgivli-ukrajini.html
5 Група компаній Quantum [Електронний ресурс] — Режим доступа:-
https://quantum-int.com/uk/ -
6 Мурашина логістика [Електронний ресурс] — Режим доступа:-
https://ant-logistics.com/uk/main.html
7 Метод північно-західного кута [Електронний ресурс] — Режим
доступа:http://www.mathros.net.ua/metod-pivnichno-zahidnogo-kuta.html
8 Актуальність впровадження логістичних систем у
виробничогосподарську діяльність підприємств [Електронний ресурс] —
Режим доступа: http://www.economy.nayka.com.ua/?op=1&z=2841
9 Денисенко М.П. Організація та проектування логістичних систем.
Підручник / за ред. проф. М. П. Денисенка, проф. П. Р. Лековця, проф. Л. І.
Михайлової. — К.: Центр учбової літератури, 2010. — 336 с.
10 Зборовська О.М. Аналіз факторів впливу на обсяги логістичних витрат/
Зборовська О.М. // Економіка та держава, 2011. — №7 — С. 26— 27.
98
ЧДТУ. 2278.003 ПЗ
11 Постановка транспортної задачі [Електронний ресурс] — Режим
доступа:https://studfiles.net/preview/5392511/
12 Сутність транспортних задач та методи їх вирішення [Електронний
ресурс]—Режим доступа:
https://pidruchniki.com/12560607/ekonomika/sutnist_transportnih_zadach_me todi
13 Сучасні тенденції розвитку логістики вирішення [Електронний ресурс]
— Режим доступа: https://studopedia.com.ua/1_369854_vzaiemozvyazoklogistiki-z-
marketingom.html
14 Cучасні тенденції розвитку логістики та логістичні системи
[Електронний ресурс] — Режим доступа:
https://www.bestreferat.ru/referat115008.html
15 Cучасні тенденції розвитку логістики та логістичні системи
[Електронний ресурс] —Режим доступа: https://www.docsity.com/ru/suchasni-
tendenciji-rozvitku-logistiki-talogistichni-sistemi/1449360/
16 Інформаційні технології в логістиці: проблеми та перспективи
[Електронний ресурс] — Режим доступа:
https://osvita.ua/vnz/reports/logika/25322/
17 Основи проектування інформаційних систем. [Електронний ресурс] —
Режим доступа: https://studfile.net/preview/3751299/
18 Діаграма прецедентів [Електронний ресурс] — Режим доступа:
https://uk.wikipedia.org/wiki/Діаграма_прецедентів
19 Діаграма послідовності [Електронний ресурс] — Режим доступа:
https://studfile.net/preview/381095/page:37/
20 Об'єктно-орієнтоване програмування [Електронний ресурс] Режим
доступа: http://www.kievoit.ippo.kubg.edu.ua/kievoit/2016/58_java/index.html
21 JAVA програмування [Електронний ресурс] Режим доступа:
https://uk.wikipedia.org/wiki/Java
22 Тестування програмного забезпечення [Електронний ресурс] Режим
доступа https://uk.wikipedia.org/wiki/Тестування_програмного_забезпечення
99
ЧДТУ. 2278.003 ПЗ
23 Первунінський С.М., Завіновський В.В. Тези доповіді на II
Міжнародній студентській науковій конференції «Тренди та перспективи
розвитку мультидисциплінарних досліджень» (25.11.2022, м. Хмельницький,
Україна) на тему «Актуальність розробки логістичної системи розрахунку
оптимальних витрат»
24 Bézivin, J. the Unification Power of Models ATLAS Group, (INRIA &
LINA) University of Nantes, 2, rue de la Houssinière, BP 92208, 44322 Nantes Cedex
3, France
25 UML діаграма. Види діаграм [Електронний ресурс] — Режим
доступа:.http://poradu.pp.ua/nauka/25991-uml-dagrama-vidi-dagram-uml.html
26 Системне тестування програмного забезпечення [Електронний ресурс]
— Режим доступа: https://jak.koshachek.com/articles/sistemnetestuvannja-
programnogo-zabezpechennja.html
27 Рівні тестування забезпечення [Електронний ресурс] — Режим
доступа:https://qalearning.com.ua/theory/lectures/material/testing-levels/
28 Діаграма класів забезпечення [Електронний ресурс] — Режим
доступа:https://www.wiki.uk-
ua.nina.az/%D0%94%D1%96%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0
%B0_%D0%BA%D0%BB%D0%B0%D1%81%D1%96%D0%B2.html
29 Створення UML діаграмм [Електронний ресурс]. – Режим доступу:
https://app.diagrams.net/
30 Діаграма автоматів [Електронний ресурс]. – Режим
доступу:https://sites.google.com/site/anisimovkhv/learning/pris/
100
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС, професор
_____________ Голуб С.В.
„____” _________________ 2023 р.
Програмне забезпечення логістичної системи розрахунку оптимальних витрат
методом рішення транспортної задачі
Специфікація
482. ЧДТУ 2278.003
Листів 2
Розробник ________________ Завіновський В.В.
Керівник ________________ Первунінський С.М.
2023
101
Позначення Найменування Примітка
Документація
482.ЧДТУ. 2278-01 12 01 Текст програми
482.ЧДТУ. 2278-01 34 01 Інструкція користувачеві
482.ЧДТУ. 2278-01 90 01 Графічні матеріали
ДОДАТОК Б
Програмне забезпечення логістичної системи розрахунку оптимальних витрат
методом рішення транспортної задачі
Текст програми
482.ЧДТУ. 2278-01 12 01
Листів 14
Розробник ________________ Завіновський В.В.
2023
103
2
ЧДТУ. 2278-01 12 01 2
angular.module('t_task_app',[]).controller('north_west_corner',function($scope,$http)
{
$scope.suppliers = 3;
$scope.consumers = 4;
$scope.suppliers_range=[];
$scope.consumers_range=[];
$scope.prices = [];
$scope.prices2 = [];
$scope.stocks = [];
$scope.stocks1 = [];
$scope.stocks2 = [];
$scope.need = [];
$scope.need1 = [];
$scope.need2 = [];
$scope.reference = [];
$scope.reference1 = [];
$scope.reference2 = [];
$scope.showMatrix=false;
$scope.showResult=false;
$scope.showResult2=false;
$scope.resulsumm1=0;
$scope.resulsumm2=0;
$scope.resulsumm3=0;
$scope.showPriceMatrixDemo = function()
{
$scope.suppliers = 3;
$scope.consumers = 4;
$scope.suppliers_range=[0,1,2];
$scope.consumers_range=[0,1,2,3];
$scope.prices = [
[5,8,1,2],
[2,5,4,9],
104
ЧДТУ. 2278-01 12 01
3
[9,2,3,1]
];
$scope.stocks = [210,170,65];
$scope.need = [125,90,130,100];
$scope.reference = [
[0,0,0,0],
[0,0,0,0],
[0,0,0,0]
];
$scope.showMatrix=true;
}
$scope.showPriceMatrix = function()
{
$scope.prices = [];
$scope.stocks = [];
$scope.need = [];
$scope.reference = [];
$scope.suppliers_range=[];
$scope.consumers_range=[]; for
(i=0;i<$scope.suppliers;i++) {
$scope.suppliers_range.push(i);
$scope.stocks.push(0);
}
for (i=0;i<$scope.consumers;i++) {
$scope.consumers_range.push(i);
$scope.need.push(0);
}
for (i=0;i<$scope.suppliers;i++) {
$scope.prices.push([]);
$scope.reference.push([]); for
(j=0;j<$scope.consumers;j++) {
105
ЧДТУ. 2278-01 12 01
4
$scope.prices[i].push(0);
$scope.reference[i].push(0);
}
}
$scope.showMatrix=true;
}
$scope.getResult = function(rarr,parr)
{
var ressumm=0; rarr.forEach(function(ritem,rindex){
ritem.forEach(function(rritem,rrindex){ ressumm = ressumm +
(rarr[rindex][rrindex]*parr[rindex][rrindex]);
})
})
return ressumm;
}
$scope.calculate = function()
{
$scope.stocks1 = $scope.copyArray($scope.stocks);
$scope.need1 = $scope.copyArray($scope.need);
$scope.reference1 = $scope.copyArray($scope.reference);
$scope.suppliers_range.forEach(function(supplier_index){
if ($scope.stocks1[supplier_index]>0) {
$scope.consumers_range.forEach(function (consumer_index) {
if ($scope.need1[consumer_index]>0) {
if ($scope.stocks1[supplier_index]>$scope.need1[consumer_index]) {
$scope.reference1[supplier_index][consumer_index]=$scope.need1[consumer_index];
$scope.stocks1[supplier_index] = $scope.stocks1[supplier_index]-
$scope.need1[consumer_index];
$scope.need1[consumer_index]=0;
} else {
$scope.reference1[supplier_index][consumer_index]=$scope.stocks1[supplier_index];
106
ЧДТУ. 2278-01 12 01
5
$scope.need1[consumer_index] = $scope.need1[consumer_index]-
$scope.stocks1[supplier_index];
$scope.stocks1[supplier_index]=0;
}
}
})
}
})
console.log('summ=',$scope.getResult($scope.reference1,$scope.prices));
$scope.resulsumm1=$scope.getResult($scope.reference1,$scope.prices);
$scope.showResult=true;
$scope.calculate2();
}
$scope.calculate2 = function()
{
$scope.stocks2 = $scope.copyArray($scope.stocks);
$scope.need2 = $scope.copyArray($scope.need);
$scope.reference2 = $scope.copyArray($scope.reference);
$scope.prices2 = $scope.copyArray($scope.prices); while
($scope.getMinPrice()!=null) { var minPrice =
$scope.getMinPrice(); if (minPrice!=null) {
if ($scope.stocks2[minPrice.si]>$scope.need2[minPrice.ci]) {
$scope.reference2[minPrice.si][minPrice.ci]=$scope.need2[minPrice.ci];
$scope.stocks2[minPrice.si] = $scope.stocks2[minPrice.si]-$scope.need2[minPrice.ci];
$scope.need2[minPrice.ci]=0;
} else {
$scope.reference2[minPrice.si][minPrice.ci]=$scope.stocks2[minPrice.si];
$scope.need2[minPrice.ci] = $scope.need2[minPrice.ci]- $scope.stocks2[minPrice.si];
$scope.stocks2[minPrice.si]=0;
}
107
ЧДТУ. 2278-01 12 01
6
}
}
console.log('summ=',$scope.getResult($scope.reference2,$scope.prices2));
$scope.resulsumm2=$scope.getResult($scope.reference2,$scope.prices2);
$scope.showResult2=true;
$scope.calculate3();
}
$scope.calculate3 = function()
{
$scope.stocks3 = $scope.copyArray($scope.stocks);
$scope.need3 = $scope.copyArray($scope.need);
$scope.reference3 = $scope.copyArray($scope.reference);
$scope.prices3 = $scope.copyArray($scope.prices);
$scope.startRecursion();
console.log('summ=',$scope.getResult($scope.reference3,$scope.prices3));
$scope.resulsumm3=$scope.getResult($scope.reference3,$scope.prices3);
$scope.showResult3=true;
}
$scope.startRecursion = function()
{
$scope.penalty_consumer = [];
$scope.penalty_supplier = [];
$scope.checkPenaltyConsumers();
$scope.checkPenaltySuppliers();
console.log('penalty_consumer',$scope.penalty_consumer);
console.log('penalty_supplier',$scope.penalty_supplier); max_penalty
= $scope.checkMaxPenalty();
console.log('max_penalty',max_penalty);
108
ЧДТУ. 2278-01 12 01
7
if ((max_penalty.supplier!=null)&&(max_penalty.consumer!=null)) {
if (max_penalty.consumer.max >= max_penalty.supplier.max) {
console.log('------FILL COL-----', max_penalty.consumer.index);
$scope.fillCol(max_penalty.consumer.index);
} else {
console.log('------FILL ROW-----', max_penalty.supplier.index);
$scope.fillRow(max_penalty.supplier.index);
}
$scope.startRecursion();
} else if ((max_penalty.supplier!=null)) { console.log('------
FILL ROW-----', max_penalty.supplier.index);
$scope.fillRow(max_penalty.supplier.index);
$scope.startRecursion();
} else if ((max_penalty.consumer!=null)) { console.log('----
--FILL COL-----', max_penalty.consumer.index);
$scope.fillCol(max_penalty.consumer.index);
$scope.startRecursion();
}
//$scope.startRecursion();
}
$scope.fillRow = function(index)
{ min_price = null; for
(i=0;i<$scope.consumers;i++)
{
if ($scope.need3[i]>0) {
if (min_price == null) {
min_price = { index:
i,
price: $scope.prices3[index][i]
}
109
ЧДТУ. 2278-01 12 01
8
}else { if (min_price.price >
$scope.prices3[index][i]) { min_price = {
index: i, price: $scope.prices3[index][i]
}
} else if (min_price.price == $scope.prices3[index][i]) {
if ($scope.penalty_consumer[min_price.index] < $scope.penalty_consumer[i]) {
min_price = { index: i, price: $scope.prices3[index][i]
}
}
}
}
}
}
console.log('min_price',min_price);
if (min_price!=null)
{
if ($scope.stocks3[index]>$scope.need3[min_price.index])
{
$scope.reference3[index][min_price.index] +=$scope.need3[min_price.index];
$scope.stocks3[index] = $scope.stocks3[index]-$scope.need3[min_price.index];
$scope.need3[min_price.index] = 0;
} else {
$scope.reference3[index][min_price.index] += $scope.stocks3[index];
$scope.need3[min_price.index] = $scope.need3[min_price.index]-$scope.stocks3[index];
$scope.stocks3[index] = 0;
}
}
}
$scope.fillCol = function(index)
{ min_price =
null; 9
for (i=0;i<$scope.suppliers;i++)
110
ЧДТУ. 2278-01 12 01
{
if ($scope.stocks3[i]>0) {
if (min_price == null) {
min_price = {
index: i, price:
$scope.prices3[i][index]
}
} else { if (min_price.price >
$scope.prices3[i][index]) { min_price = {
index: i, price: $scope.prices3[i][index]
}
} else if (min_price.price == $scope.prices3[i][index]) { if
($scope.penalty_supplier[min_price.index] < $scope.penalty_supplier[i]) {
min_price = { index: i, price: $scope.prices3[i][index]
}
}
}
}
}
}
if (min_price!=null)
{
if ($scope.need3[index]>$scope.stocks3[min_price.index])
{
$scope.reference3[min_price.index][index] += $scope.stocks3[min_price.index];
$scope.need3[index] = $scope.need3[index]-$scope.stocks3[min_price.index];
$scope.stocks3[min_price.index]=0;
} else {
10
$scope.reference3[min_price.index][index] += $scope.need3[index];
$scope.stocks3[min_price.index]=$scope.stocks3[min_price.index]-$scope.need3[index];
$scope.need3[index]=0;
111
ЧДТУ. 2278-01 12 01
}
}
console.log("min_price",min_price);
}
$scope.checkMaxPenalty = function()
{
max_penalty = {
supplier:null,
consumer:null
};
for (i=0;i<$scope.penalty_supplier.length;i++)
{
if ($scope.penalty_supplier[i]!=null)
{
if (max_penalty.supplier==null) {
max_penalty.supplier= { max:
$scope.penalty_supplier[i], index:
i
}
} else {
if ($scope.penalty_supplier[i]>max_penalty.supplier.max)
{
max_penalty.supplier= {
max: $scope.penalty_supplier[i],
index: i
}
}
}
} 11
}
for (i=0;i<$scope.penalty_consumer.length;i++)
112
ЧДТУ. 2278-01 12 01
{
if ($scope.penalty_consumer[i]!=null)
{
if (max_penalty.consumer==null) {
max_penalty.consumer={
max: $scope.penalty_consumer[i],
index: i
}
} else {
if ($scope.penalty_consumer[i]>max_penalty.consumer.max)
{
max_penalty.consumer= {
max: $scope.penalty_consumer[i],
index: i
}
}
}
}
}
console.log(max_penalty);
return max_penalty;
}
$scope.checkPenaltySuppliers = function()
{
for (i=0;i<$scope.suppliers;i++) {
min1 = null; min2 = null;
if ($scope.stocks3[i]>0) {
for (j = 0; j < $scope.consumers; j++) {
if ($scope.need3[j]>0) { if 12
(min1==null) { min1 =
$scope.prices3[i][j];
} else {
113
ЧДТУ. 2278-01 12 01
if ($scope.prices3[i][j]<min1)
{ min2 =
min1; min1 =
$scope.prices3[i][j];
} else {
if (min2==null)
{ min2
= $scope.prices3[i][j];
} else { if
($scope.prices3[i][j] < min2) {
min2 = $scope.prices3[i][j];
}
}
}
}
}
}
}
console.log("col:", i, "min1:", min1, "min2:", min2);
if ((min1!=null)&&(min2!=null)) {
$scope.penalty_supplier.push(Math.abs(min2 - min1));
} else { if
((min1!=null)||(min2!=null)) {
$scope.penalty_supplier.push(0);
} else {
$scope.penalty_supplier.push(null);
}
13
}
}
// console.log($scope.penalty_supplier);
114
ЧДТУ. 2278-01 12 01
}
$scope.checkPenaltyConsumers = function()
{
//console.log($scope.prices3);
for (i=0;i<$scope.consumers;i++)
{
min1 = null; min2 = null;
if ($scope.need3[i]>0) { for (j = 0; j
< $scope.suppliers; j++) { if
($scope.stocks3[j]>0) { if (min1
== null) { min1 =
$scope.prices3[j][i];
} else { if
($scope.prices3[j][i] < min1) {
min2 = min1; min1 =
$scope.prices3[j][i];
} else { if
(min2 == null) { min2 =
$scope.prices3[j][i];
} else { if
($scope.prices3[j][i] < min2) {
min2 = $scope.prices3[j][i];
}
}
}
}
}
}
console.log("row:", i, "min1:", min1, "min2:", min2); 14
}
if ((min1!=null)&&(min2!=null)) {
$scope.penalty_consumer.push(Math.abs(min2 - min1));
115
ЧДТУ. 2278-01 12 01
} else {
if ((min1!=null)||(min2!=null)) {
$scope.penalty_consumer.push(0);
} else {
$scope.penalty_consumer.push(null);
}
}
}
// console.log("penalty_consumer",$scope.penalty_consumer);
}
$scope.copyArray = function(carray)
{
return JSON.parse(JSON.stringify(carray));
}
$scope.getMinPrice = function()
{
var minElem = null;
$scope.suppliers_range.forEach(function(supplier_index){
if ($scope.stocks2[supplier_index]>0) {
$scope.consumers_range.forEach(function (consumer_index) {
if ($scope.need2[consumer_index]>0) { if (minElem!=null)
{
if
($scope.prices2[supplier_index][consumer_index]<$scope.prices2[minElem.si][minElem.ci]) {
minElem.si = supplier_index; minElem.ci = consumer_index;
}
} else {
15
minElem= {
si:supplier_index,
ci:consumer_index
}
}
116
ЧДТУ. 2278-01 12 01
}
});
}
});
return minElem;
117
ДОДАТОК В
Програмне забезпечення логістичної системи розрахунку оптимальних витрат
методом рішення транспортної задачі
Інструкція користувачеві
482. ЧДТУ 2278-01 34 01
Листів 4
Розробник ________________ Завіновський В.В.
2023
ЧДТУ 2278-01 34 01
2
ЗМІСТ
1 ПРИЗНАЧЕННЯ ПРОГРАМИ ...................................................................... 3
2 УМОВИ ВИКОНАННЯ ПРОГРАМИ ........................................................... 3
3 РОБОТА З ПРОГРАМОЮ ............................................................................. 3
119
ЧДТУ 2278-01 34 01
3
1 ПРИЗНАЧЕННЯ ПРОГРАМИ
Програма призначена для ведення бази даних проектів, етапів проектів,
експертів та тривалості задач. Програма виконує визначення оптимальної
тривалості задачі по середньому значенню оцінок експертів та проводить
розрахунок оцінки узгодженості експертів в своєму рішенні.
2 УМОВИ ВИКОНАННЯ ПРОГРАМИ
Розглянута програмна система є Windows-програмою, і для свого
нормального функціонування вимагає як мінімум такої конфігурації апаратних
засобів, що забезпечує функціонування операційного середовища Windows –
архітектура:
- сервер бази даних: комп'ютер Pentium III 900 і вище, 256Мб або
більше оперативної пам'яті, не менше за 1 Гб місця на жорсткому диску;
- комп’ютери на яких буде встановлене клієнтське програмне
забезпечення: комп'ютер Pentium III 600 і вище, 128Мб або більше оперативної
пам'яті, не менше за 400 Кб місця на жорсткому диску.
3 РОБОТА З ПРОГРАМОЮ
При запуску системи відкривається діалогове вікно для внесення даних по
кількості пунктів відправлення і кількості пунктів призначення.
Рис.В.1 – Внесення даних по кількості місць
Після внесення необхідних даних натискаємо кнопку «Примінити» і
отримуємо наступне вікно. Рис.В.2
120
ЧДТУ 2278-01 34 01 4
Рис.В.2 – Відкриття таблиці опорного плану
В новому вікні з`явилась таблиця опорного плану транспортної задачі.
Наступним кроком є введення тарифів перевезення з пунктів відправлення до
пунктів призначення. Ці дані мжна вносити як з клавіатури, так і натискаюи
кнопки біля кожного поля.
Також вносимо дані по потребам кожного пункту призначення, та по
запасам кожного пункту відправлення.Рис.В.3.
Рис.В.3 – Внесення даних
Після внесення даних натискаємо кнопку «Найти опорній план» і
отримуємо рішення транспортної задачі, тобто пошуку оптимального шляху,
трьома методами описаними в четвертому розділі.
Рис.5.4 – Рішення методом північно-західного кута
121
ЧДТУ 2278-01 34 01 5
Як бачимо з результатів, вартість перевозки по такому маршруту буде
складати 652 грошові одиниці.
Рис.В.4 – Рішення методом мінімального елемента
Як бачимо з результатів, вартість перевозки по такому маршруту буде
складати 603 грошові одиниці.
Рис.В.4 – Рішення методом Фогеля
Після кожної таблиці ми отримуємо результати розрахунку перевезень
товару. Як бачимо рішення транспортної задаі методом Фогеля дає найменші
витрати на перевезення.
122
ДОДАТОК Г
Програмне забезпечення логістичної системи розрахунку оптимальних витрат
методом рішення транспортної задачі
Графічні матеріали
482.ЧДТУ. 2278-01 90 01
Листів 7
Розробник ________________ Завіновський В.В.
2023
ЧДТУ. 2278-01 90 01
1
Рисунок Г.1 – Матриця транспортної задачі
Рисунок Г.2 – Діаграма прецедентів
124
ЧДТУ. 2278-01 90 01
2
Рисунок Г.3 – Діаграма класів
Рисунок Г.4 – Діаграма діяльності
125
ЧДТУ. 2278-01 90 01 3
Рисунок Г.5 – Внесення даних
Рисунок Г.6 – Рішення методом Фогеля
126