Сезонні моделі ARIMA включають звичайні авторегресійні члени і члени ковзаючого середнього, що відповідають за кореляції при низьких інтервалах, а також авторегресійні члени і члени ковзаючого середнього, що відповідають за кореляції при сезонних інтервалах. У разі нестаціонарних сезонних рядів для досягнення повноти опису часто необхідно додатково врахувати в моделі сезонні різниці.[7]

3.2.6 Переваги і недоліки моделей ARIMA

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

Проте, використання моделей ARIMA має і декілька недоліків.

1 Необхідна відносно велика кількість початкових даних. Слід розуміти, що якщо дані періодичні з, скажімо, сезонним періодом S=12, то спостереження за один повний рік складатимуть фактично одне сезонне значення даних (один погляд на сезонну структуру), а не дванадцять значень. Взагалі кажучи, при використанні моделі ARIMA для несезонних даних необхідно близько 40 або більш за спостереження. При побудові моделі ARIMA для сезонних даних потрібні спостереження приблизно за 6-10 років, залежно від величини періоду сезонності.

2 Не існує простого способу коригування параметрів моделей ARIMA, такого як в деяких згладжуючих методах, коли задіюються нові дані. Модель доводиться періодично повністю перебудовувати, а іноді потрібно вибрати абсолютно нову модель.

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

3.3 Розробка моделей прогнозування

Відповідно до методології Бокса-Дженкінса, модель прогнозування для кожного конкретного випадку обирається аналітично.

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

Відповідно до описаної методологій, для прогнозування можна використовувати: авторегресійні моделі, моделі із ковзаючим середнім та змішані моделі.

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

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

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

Будуть використані авторегресійні модель з однією і двома незалежними змінними. Більша кількість незалежних змінних робить модель більш точною в дуже незначній мірі, в той же час значно ускладнюючи її програмну реалізацію. [4]

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

Для стаціонарних часових рядів використовують звичайні авторегресійні моделі. Пропонується використати наступні звичайні авторегресійні моделі:

Y_t=b₀+b₁*Y_t-1, (3.4)

Y_t=b₀+b₁*Y_t-1+b₁*Y_t-2(3.5)

Для нестаціонарних часових рядів використовують інтегральні авторегресійні моделі. Пропонується використати наступні інтегральні авторегресійні моделі:

?Y_t=b₀+b₁*?Y_t-1, (3.6)

?Y_t=b₀+b₁*?Y_t-1+b₁*?Y_t-2 (3.7)

Часові ряди можуть бути сезонними або не сезонними. Сезонні дані володіють виразною структурою, яка періодично повторюється. Можна зробити припущення, що для обсягів продажів період сезонності може складати чотири або дванадцять місяців. Період сезонності в чотири місяці означає, що обсяги продажів залежать від пори року. Довжина одного періоду приймається рівною одному місяцю. Пропонується використати наступні моделі:

Y_t=b₀+b₁*Y_t-4, (3.8)

Y_t=b₀+b₁*Y_t-4+b₁*Y_t-8, (3.9)

?Y_t=b₀+b₁*?Y_t-4, (3.10)

?Y_t=b₀+b₁*?Y_t-4+b₁*?Y_t-8 (3.11)

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

Y_t=b₀+b₁*Y_t-12, (3.12)

Y_t=b₀+b₁*Y_t-12+b₁*Y_t-24, (3.13)

?Y_t=b₀+b₁*?Y_t-12, (3.14)

?Y_t=b₀+b₁*?Y_t-12+b₁*?Y_t-24 (3.15)

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

3.4 Апроксимація даних

Для прогнозування використовуються моделі двох видів: з однією і двома незалежними змінними.

В першому випадку модель представляє собою рівняння прямої, і має вигляд:

,(3.16)

де Y_i - залежна змінна, ;

X_i - незалежна змінна, ;

b₀ - константа, яку можна інтерпретувати як нахил лінії;

b₁ - константа, яку можна інтерпретувати як Y-перетин;

n - кількість значень у числовому ряді.

Для того, щоб визначити константи b₀ і b₁ використовується лінійний метод найменших квадратів.[8] Згідно методу, константи визначаються за формулами:

(3.17)

(3.18)

У другому випадку модель має вигляд:

,(3.19)

де Y_i - залежна змінна, ;

X_1i, X_2i - незалежні змінні, ;

b₀, b₁ ,b₂ - константи

n - кількість значень у числовому ряді.

Константи b₀, b₁, b₂ знаходяться через розв'язання системи нерівностей:

(3.20)

4. Розробка алгоритмічного забезпечення задачі управління запасами

4.1 Алгоритмічне забезпечення роботи програми в цілому

Необхідно визначити: коли і який об'єм певного виду товару треба замовляти. Об'єм замовлень повинен бути таким, щоб сумарні витрати на оформлення поставок и на зберігання товару були мінімальні.

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

Є декілька видів товарів. Поставка кожного виду виконується окремо. Кожний вид розглядається окремо, отже необхідна однономенклатурна модель задачі управління запасами. Але попит на кожний вид товарів не є однаковим, отже не можна використовувати одну модель прогнозування для всіх видів товарі. Кожному виду товарів необхідно окремо підібрати найбільш адекватну модель для прогнозування попиту.

Таким чином, алгоритм роботи програми з кожним видом товарів буде складатися з трьох етапів: вибір найбільш адекватної моделі прогнозування, побудова прогнозу, вирішення задачі управління запасами. Алгоритм:

1 Ввести дані для кожного виду товарів: статистика, вартість зберігання одиниці, вартість оформлення поставки, кількість періодів на які робляться розрахунки. Перейти до кроку 2.

2 Прирівняти нулю номер виду товарів, для якого робляться розрахунки. Перейти до кроку 3.

3 Визначити найбільш адекватну модель прогнозування для виду товарів, для якого робляться розрахунки. Перейти до кроку 4.

4 Побудувати прогноз попиту на вид товарів, для якого робляться розрахунки. Перейти до кроку 5.

5 Вирішити задачу управління запасами для виду товарів, для якого робляться розрахунки. Перейти до кроку 6.

6 Перевірити: чи для всіх видів товарів зроблені розрахунки. Якщо ні, збільшити номер виду товарів, для якого робляться розрахунки, на один і перейти до кроку 3. Якщо так, перейти до кроку 7.

7 Вивести результати розрахунків і завершити виконання алгоритму.

Схема роботи програми в цілому представлена на рисунку 4.1.

Рисунок 4.1 - Схема роботи програми в цілому

4.2 Алгоритмічне забезпечення процесу прогнозування

Для кожного виду товарів при кожному прогнозуванні серед перерахованих моделей необхідно визначити найбільш адекватну. Cтупінь неадекватності моделі визначається як сума квадратів різниць між прогнозом і статистичними значеннями. Визначення найбільш адекватної моделі складається з наступних кроків:

1 Прирівняти мінімальну ступінь неадекватності до числа M, що є більшим за будь яке інше число, використане в ході роботи алгоритму. Перейти до кроку 2.

2 Прирівняти номер найбільш адекватної моделі значенню мінус один. Перейти до кроку 3.

3 Прирівняти номер моделі що перевіряється нулю. Починається цикл перевірки кожної моделі. Перейти до кроку 4.

4 Визначити прогноз за допомогою моделі що перевіряється на основі вкороченої статистики. Перейти до кроку 5.

5 Визначити ступінь неадекватності моделі що перевіряється, вирахувавши суму квадратів різниць між прогнозом і статистичними значеннями. Перейти до кроку 6.

6 Перевірка: чи є ступінь неадекватності моделі, що перевіряється, меншою ніж ступінь неадекватності найбільш адекватної моделі. Тобто, чи є модель що зараз перевіряється більш адекватною ніж попередня найбільш адекватна модель. Якщо так, перейти до кроку 7. Якщо ні, перейти до кроку 8

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

8 Перевірка: чи всі моделі перевірені. Якщо ні, перейти до кроку 9. Якщо так, перейти до кроку 10.

9 Збільшити на одиницю номер моделі що перевіряється. Перейти до кроку 4.

10 Перевірка: чи є найбільш адекватна модель достань адекватною. Якщо так, завершити роботу алгоритму. Якщо ні, прирівняти номер найбільш адекватної моделі значенню мінус один, щоб інформувати, що достатньо адекватна модель не знайдена і завершити роботу алгоритму.

Схема визначення найбільш адекватної моделі прогнозування представлена на рисунку 4.2.

Рисунок 4.2 - Схема визначення найбільш адекватної моделі прогнозування

4.3 Алгоритмічне забезпечення процесу вирішення задачі управління запасами

Розглянемо алгоритм, що дозволяє визначити: який об'єм товарів необхідно замовити, щоб сумарні витрати на зберігання товару і оформлення замовлень були мінімальні.

Попередньо до виконання алгоритму необхідно побудувати послідовність об'єктів-періодів. Кожний об'єкт зберігає наступну інформацію:

- k - номер періоду;

- X - попит в цей період;

- S - запас, який необхідно створити в цей період;

- L - витрати в цей період на оформлення поставки та зберігання надлишкового запасу;

- NP - посилання на наступний період.

Алгоритм складається з наступних кроків:

1 Перевірка: це останній період чи ні. Якщо це останній період, то перейти до другого кроку. Якщо це не останній період, то перейти до третього кроку.

2 Це останній період. Прирівняти оптимальній об'єм запасів до попиту в цей період. Завершити виконання алгоритму.

3 Це не останній період. Перевірити: чи є в таблиці рішень, для даного періоду, для даного об'єму залишку, оптимальне рішення. Якщо так, отримати рішення із таблиці рішень і завершити виконання алгоритму. Якщо ні, перейти до кроку 4.

4 Прирівняти оптимальні сумарні витрати в цей період до числа M, що є більшим за будь-яке інше число, використане в ході роботи алгоритму. Перейти до кроку 5.

5 Прирівняти підібраний об'єм запасів до попиту в цей період. Перейти до кроку 6.

6 Визначити мінімальні витрати на зберігання товару і оформлення замовлень для наступних періодів. Це можна зробити виконавши цей же алгоритм але для наступного періоду. Необхідно зазначити що на початок наступного періоду буде існувати запас. Перейти до кроку 7.

7 Визначити підібрані сумарні витрати, які дорівнюють сумі витрат в цей період і сумарним витратам в попередні періоди. Перейти до кроку 8.

8 Перевірити: чи є сумарні витрати в цей період меншими за підібрані сумарні витрати. Якщо так, прирівняти оптимальний об'єм запасів до підібраного об'єму запасів. Прирівняти оптимальні сумарні витрати до підібраних сумарних витрат. Перейти до кроку 9. Якщо ні, просто перейти до кроку 9.

9 Перевірити: чи досяг підібраний об'єм запасів свого максимального значення - сумарного попиту за всі наступні періоди. Якщо ні, збільшити підібраний об'єм запасів і перейти до кроку 6. Якщо так, перейти до кроку 10.

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

Схема алгоритму вирішення задачі управління запасами представлена на рисунку 4.3.

Рисунок 4.3 - Схема алгоритму вирішення задачі управління запасами

За допомогою динамічного програмування можна мінімізувати витрати L, проте спосіб розрахунку витрат L залежить від того, наскільки достовірно відомий майбутній попит.

Для того щоб визначити ймовірності того, що попит в певний період дорівнюватиме значенню x, необхідно:

1 Визначити середньоквадратичне відхилення. Перейти до кроку 2.

2 Визначити математичне очікування. Перейти до кроку 3.

3 Визначити значення функції Лапласа для першого елементу, що представлений у формулі 4.4. Перейти до кроку 4.

4 Визначити значення функції Лапласа для другого елементу, що представлений у формулі 1.4. Перейти до кроку 5.

5 Визначити ймовірності того, що величина x попаде на інтервал від (x-1) до (x+1). Завершити виконання алгоритму.

Схема визначення ймовірності того, що попит в певний період дорівнюватиме значенню x, представлена на рисунку 4.4.

Рисунок 4.4 - Схема визначення ймовірності того, що попит в певний період дорівнюватиме значенню x

5. Розробка програмного забезпечення

5.1 Основи процесу розробки програмного забезпечення

Програмне забезпечення розроблене на платформі Microsoft .NET Framework 3.5, мовою програмування С# в середовищі Microsoft Visual Studio 2008. Для доступу до баз даних використана технологія ADO.NET. У якості сервера баз даних слугує сервер MS SQL 2008.

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

Рисунок 5.1 - схема процесу розробки

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

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

- що насправді необхідно створити;

- як це можна реалізувати.

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

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

2 Технологічні ризики. З якими технологічними ризиками доведеться зіткнутися? Чи дійсно дозволяє вибрана вами технологія реалізувати проект? Яким чином слід інтегрувати різні частини проекту?

3 Ризики, пов'язані з кваліфікацією персоналу. Чи є змога підібрати штат співробітників з необхідним досвідом і кваліфікацією?

4 Політичні ризики. Чи існують політичні сили, які можуть опинитися на вашому шляху і серйозно вплинути на виконання проекту?

Взагалі ризиків може бути і більше. Але ті ризики, які потрапляють в ці чотири категорії, присутні майже завжди.

Фаза дослідження повинна займати біля однієї п'ятої часу від загальної тривалості проекту. Основними ознаками завершення фази дослідження є наступні дві події:

- розробники можуть з упевненістю оцінити, що слід робити в найближчий день і скільки часу при цьому буде потрібно на реалізацію кожного варіанту використання;

- ідентифіковані всі найбільш серйозні ризики, а найважливіші з них зрозуміли настільки, що вам відомо, як з ними впоратися.

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

Існує безліч способів планування ітеративного проекту. Важливо розуміти, що план розробляється з метою забезпечити обізнаність всієї команди про хід виконання проекту.

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

В ході планування краще розглядати дві групи осіб: клієнти і розробники.

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

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

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

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

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

Наступний крок полягає в розподілі варіантів використання по ітераціях.

Варіанти використання, які володіють високим пріоритетом і/або ризиком розробки, слід реалізовувати насамперед. Не можна відкладати розгляд ризику в останню чергу! При цьому може виникнути необхідність розділити дуже великі варіанти використання і, можливо, переглянути попередні оцінки деяких варіантів використання відповідно до порядку їх реалізації.

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

Ітерації на стадії побудови є як інкрементними (нарощуваними), так і такими, що повторюються.

Ітерації є інкрементними в сенсі деякої функції. Кожна ітерація реалізує чергові варіанти використання і додає їх до вже реалізованим в ході попередніх ітерацій.

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

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

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

5.2 Діаграма варіантів використання

Що таке варіант використання? Прямої відповіді на це питання не існує. Але спробувати на нього відповісти можна, описавши спочатку сценарій.

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

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

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

У такому разі варіантом використання є безліч сценаріїв, об'єднаних разом деякою загальною метою користувача.

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

Роботу програмного забезпечення можна умовно розділити на два основних етапи: побудова прогнозу і вирішення задачі управління запасами.

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

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

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

Оскілки видів товарів може бути дуже багато, необхідно щоб була можливість обрати лише деякі з них для подальших розрахунків. Відповідно до зазначених вимог розроблена діаграма варіантів використання. Що представлена на рисунку 5.2



Рисунок 5.2 - Діаграма варіантів використання

5.3 Діаграма класів

Діаграма класів по праву займає центральне місце в об'єктно-орієнтованому підході. Фактично будь-яка методологія включає деякий різновид діаграм класів.

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

Діаграма класів описує типи об'єктів системи і різного роду статичні відносини, які існують між ними. Є два основні види статичних відносин:

- асоціації (наприклад, клієнт може узяти напрокат ряд відеокасет);

- підтипи (медсестра є різновидом особи).

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

Можна виділити три різні точки зору на побудову діаграми класів.

1 Концептуальна точка зору. Якщо розглядати діаграми класів з концептуальної точки зору, то вони служать для представлення понять наочної області, що вивчається. Ці поняття, природно, відповідатимуть класам, що реалізовують їх, проте така пряма відповідність часто відсутня. Насправді, концептуальна модель може мати вельми слабке відношення або взагалі не мати ніякого відношення до того, що буде реалізовано в програмному забезпеченні, тому її можна розглядати незалежно від мови програмування.

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

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

Мову UML можна використовувати з будь-якою з цих точок зору.

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

Розроблене програмне забезпечення включає наступні класи:

VariantOfDecision - зберігає інформацію про варіант поведінки в певний період, включає наступні атрибути:

- Z - об'єм товару що залишився від попереднього періоду;

- X - попит в даний період;

- S - запас, що необхідно створити в даний період;

- L - витрати в даний період.

У склад класу входить функція ToString, що у вигляді строки повертає значення всіх атрибутів. Функція призначена лише для поліпшення процесу тестування.

PeriodOfTime - містить набір функцій, що дозволяють визначити оптимальний об'єм запасу для одного періоду. Включає наступні атрибути:

- k - номер данного періоду;

- X - попит на один вид товарів в даний період;

- nextPeriod - посилання на наступний період.

У цьому класі представлені наступні методи:

- GetOptVariant - повертає оптимальний варіант поведінки в даний період, використовує функції FindOptVariantInCache і CalculateOptVariant;

- FindOptVariantInCache - повертає оптимальний варіант поведінки, якщо він вже був розрахований та збережений в кеш;

- CalculateOptVariant - розраховує оптимальній варіант поведінки в даний період;

- ToString - повертає у вигляді строки значення всіх атрибутів.

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

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

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

Клас реалізує заступні функції:

- GetModels - повертає список об'єктів, що позначені атрибутом CanCreateForecastAttribute, і є похідними від ModelCreationForecast.

- LinearLeastSquaresMethod - визначає дві константи для вказаної моделі прогнозування лінійним методом найменших квадратів;

- LeastSquaresMethod - визначає три константи для вказаної моделі прогнозування методом найменших квадратів;

- GetTruncatedStatistic - повертає вкорочену статистику, на основі якої буде робитися перевірка адекватності моделей прогнозування;

- GetAntiTruncatedStatistic - повертає частину статистики, яка не увійшла до truncatedStatistic;

- SimpleValuesToDeltaValues - перетворює звичайний ряд даних у різницевий;

- DeltaValuesToSimpleValues - перетворює різницевий ряд даних у звичайний.

AutoRegressiveModel_p1_S1 - клас позначений атрибутом CanCreateForecastAttribute і є клас-спадкоємець для класу ModelCreationForecast. Метод CreateForecast реалізує авторегресійну модель прогнозування з однією незалежною змінною і коефіцієнтом сезонності S рівним одному періоду.

AutoRegressiveModel_p1_S4 - клас позначений атрибутом CanCreateForecastAttribute і є клас-спадкоємець для класу ModelCreationForecast. Метод CreateForecast реалізує авторегресійну модель прогнозування з однією незалежною змінною і коефіцієнтом сезонності S рівним чотирьом періодам.

AutoRegressiveModel_p1_S12 - клас позначений атрибутом CanCreateForecastAttribute і є клас-спадкоємець для класу ModelCreationForecast. Метод CreateForecast реалізує авторегресійну модель прогнозування з однією незалежною змінною і коефіцієнтом сезонності S рівним дванадцятьом періодам.

AutoRegressiveModel_p2_S1 - клас позначений атрибутом CanCreateForecastAttribute і є клас-спадкоємець для класу ModelCreationForecast. Метод CreateForecast реалізує авторегресійну модель прогнозування з двома незалежними змінними і коефіцієнтом сезонності S рівним одному періоду.

AutoRegressiveModel_p2_S4 - клас позначений атрибутом CanCreateForecastAttribute і є клас-спадкоємець для класу ModelCreationForecast. Метод CreateForecast реалізує авторегресійну модель прогнозування з двома незалежними змінними і коефіцієнтом сезонності S рівним чотирьом періодам.

AutoRegressiveModel_p2_S12 - клас позначений атрибутом CanCreateForecastAttribute і є клас-спадкоємець для класу ModelCreationForecast. Метод CreateForecast реалізує авторегресійну модель прогнозування з двома незалежними змінними і коефіцієнтом сезонності S рівним дванадцятоьм періодам.

AutoRegressiveIntegratedModel_p1_d1_S1 - клас позначений атрибутом CanCreateForecastAttribute і є клас-спадкоємець для класу ModelCreationForecast. Метод CreateForecast реалізує різницеву авторегресійну модель прогнозування з однією незалежною змінною і коефіцієнтом сезонності S рівним одному періоду.

AutoRegressiveIntegratedModel_p1_d1_S4 - клас позначений атрибутом CanCreateForecastAttribute і є клас-спадкоємець для класу ModelCreationForecast. Метод CreateForecast реалізує різницеву авторегресійну модель прогнозування з однією незалежною змінною і коефіцієнтом сезонності S рівним чотирьом періодам.

AutoRegressiveIntegratedModel_p1_d1_S21S4 - клас позначений атрибутом CanCreateForecastAttribute і є клас-спадкоємець для класу ModelCreationForecast. Метод CreateForecast реалізує різницеву авторегресійну модель прогнозування з однією незалежною змінною і коефіцієнтом сезонності S рівним дванадцятьом періодам.

AutoRegressiveIntegratedModel_p2_d1_S1 - клас позначений атрибутом CanCreateForecastAttribute і є клас-спадкоємець для класу ModelCreationForecast. Метод CreateForecast реалізує різницеву авторегресійну модель прогнозування з двома незалежними змінними і коефіцієнтом сезонності S рівним одному періоду.

AutoRegressiveIntegratedModel_p3_d1_S4 - клас позначений атрибутом CanCreateForecastAttribute і є клас-спадкоємець для класу ModelCreationForecast. Метод CreateForecast реалізує різницеву авторегресійну модель прогнозування з двома незалежними змінними і коефіцієнтом сезонності S рівним чотирьом періодам.

AutoRegressiveIntegratedModel_p3_d1_S21 - клас позначений атрибутом CanCreateForecastAttribute і є клас-спадкоємець для класу ModelCreationForecast. Метод CreateForecast реалізує різницеву авторегресійну модель прогнозування з двома незалежними змінними і коефіцієнтом сезонності S рівним дванадцятьом періодам.

UnitingClass - клас що поєднує функціональні можливості класів PeriodOfTime і ModelCreationForecast, та зберігає глобальні дані, такі як статистика та результат розрахунків. Має наступні атрибути:

- statistic - список елементів типу double, що являють побою статистику попиту на даний вид товарів;

- forecast - список елементів типу double, що являють побою прогноз попиту на даний вид товарів;

- periods - список елементів типу PeriodOfTime, що зберігають інформацію про прогнозовану статистику попиту у вигляді, зручному для вирішення задачі управління запасами;

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

Клас реалізує наступні функції:

- CreatePeriodsFromDemand - перетворює дані прогнозу із послідовності змінних типу double у послідовність змінних типу PeriodOfTime;

- GetMostAdequacyModel - визначає найбільш адекватну модель прогнозування серед реалізованих, або генерує виключення NotAnAdequacyModelException, якщо достатньо адекватної моделі не вдалося знайти;

- GetListOfOptVariant - на сонові списку елементів типу PeriodOfTime, вирішує задачу управління запасами і зберігає результат у список елементів типу VariantOfDecision.

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

Рисунок 5.3 - Діаграма класів

5.4 Проектування систем баз даних

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

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

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

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

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

Оптимальна модель даних повинна відповідати наступним критеріям:

- структурна достовірність - відповідність способу визначення і організації інформації на даному підприємстві;

- простота - зручність вивчення моделі як професіоналами в області розробки інформаційних систем, так і звичайними користувачами;

- виразність - здатність представляти відмінності даними, зв'язки між даними і обмеження;

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

- здатність до сумісного використання - відсутність приналежності до якогось особливого застосування або технології і. отже, можливість використання моделі в багатьох застосуваннях і технологіях;

- розширюваність - здатність розвиватися і включати нові вимоги з мінімальною дією на роботу вже існуючих застосувань;

- цілісність - узгодженість із способом використання і управління інформацією усередині підприємства;

- схематичне уявлення - можливість представлення моделі за допомогою наочних схематичних позначень.

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

Другий етап проектування бази даних називається логічним проектуванням бази даних. Його мета полягає в створенні логічної моделі даних для досліджуваної частини підприємства. Концептуальна модель даних, створена на попередньому етапі, уточнюється і перетвориться в логічну модель даних. Логічна модель даних враховує особливості вибраної моделі організації даних в цільовій СУБД (наприклад, реляційна модель).

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

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

Фізичне проектування є третім і останнім етапом створення проекту бази даних, при виконанні якого проектувальник приймає рішення про способи реалізації бази даних, що розробляється. Під час попереднього етапу проектування була визначена логічна структура бази даних (яка описує відносини і обмеження в даній прикладній області). Хоча ця структура не залежить від конкретної цільової СУБД, вона створюється з урахуванням вибраної моделі зберігання даних, наприклад реляційною, мережевою або ієрархічною. Проте, приступаючи до фізичного проектування бази даних, перш за все необхідно вибрати конкретну цільову СУБД. Тому фізичне проектування нерозривно пов'язане з конкретною СУБД. Між логічним і фізичним проектуванням існує постійний зворотний зв'язок, оскільки рішення, що приймаються на етапі фізичного проектування з метою підвищення продуктивності системи, здатні вплинути на структуру логічної моделі даних.

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

- створення набору реляційних таблиць і обмежень для них на основі інформації, представленої в глобальній логічній моделі даних;

- визначення конкретних структур зберігання даних і методів доступу до них, що забезпечують оптимальну продуктивність СУБД;

- розробка засобів зашиті створюваної системи.

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

При розробці реляційної моделі бази даних враховувались наступні бізнес правила:

- всі товари одного виду мають однакову вартість зберігання;

- одному виду товарів відповідає один постачальник;

- якщо у постачальника змінюється ціна на товар, то цей товар необхідно вважати новим товаром;

- якщо для виду товару змінюється вартість зберігання, вартість оформлення поставки, втрати від дефіциту або постачальник то цей вид товарів треба вважати новим видом товарів;

- замовлення обов'язково буде виконане;

- довжина періоду є постійною.

Розроблена база даних включає наступні сутності:

1 GlobalTypeOfArticles - перелік унікальних видів товарів. До атрибутів входять ідентифікаційний номер та назва виду товарів.

2 TypeOfArticles - перелік всіх видів товарів. Відповідно до бізнес-правил, якщо у виду товарів змінюється вартість зберігання, вартість оформлення поставки, чи інше, то це вже буде вважатися інший вид товарів. Тобто він буде відноситись до того ж глобального виду товарів, але буде мати свої власні параметри. До атрибутів входять: ідентифікаційний номер глобального виду товарів id_globalTypeOfArticle, вартість зберігання одиниці товару costOfStorage, вартість оформлення поставки costOfDelivery, втрати від дефіциту одиниці товару lossesAtDeficit та порядковий номер постачальника id_supplier.

3 Periods - зберігає перелік періодів, в який входять як минулі, так и майбутні періоди.

4 GlobalArticles - перелік унікальних товарів. Для кожного товару зберігається назва name, ідентифікаційний номер глобального виду товару id_globalTypeOfArticle та додаткова інформація description.

5 Articles - перелік усіх товарів. Відповідно до бізнес-правил, якщо у товару змінюється вартість, то цей товар вже буде вважатися іншим товарів. Тобто він буде відноситись до того ж глобального товару, але буде мати свої власні параметри. До атрибутів входять ідентифікаційний номер товару, порядковий номер глобального товару id_GlobalArticles та ціна price.

6 DemandOnATypeOfArticles - реалізує відношення «багато до багатьох» між сутностями Articles та Periods. Зберігає значення попиту value на вказаний вид товарі у вказаний період.

7 DemandOnAArticles - реалізує відношення «багато до багатьох» між сутностями TypeOfArticles та Periods. Зберігає значення попиту value на вказаний товар у вказаний період.

8 Orders - перелік замовлень, де кожному замовленню вказані об'єм value, дата оформлення date, ідентифікаційний номер товару id_articles та періоду id_periods до початку якого замовлення має бути виконане.

9 Suppliers - зберігає перелік постачальників. Для кожного постачальника зберігається його ідентифікаційний номер id_suppliers, назва name та додаткова інформація description.

Реляційна модель бази даних представлена на рисунку 5.4.



Рисунок 5.4 - Реляційна модель бази даних

5.5 Опис інтерфейсу користувача

Після запуску програми з'являється вікно, яке містить інформацію про програму. Інформаційне вікно представлено на рисунку 5.5.

Інформаційне вікно зникне якщо кліпнути на нього. Також інформаційне вікно автоматично зникне через хвилину, після появи.

Рисунок 5.5 - Інформаційне вікно

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



Рисунок 5.6 - Вікно вибору видів товарів

Після того як потрібні види товарів обрано, необхідно натиснути кнопку «Далі». Після натискання кнопки «Далі» з'являється вікно налаштування процесу прогнозування (рисунок 5.7). В цьому вікні, для кожного виду товарів, показані: вартість зберігання одиниці товару, вартість оформлення замовлення, витрати через дефіцит та число, якому повинний бути кратний об'єм замовлення. Поле «Модель прогнозування» дозволяє обрати модель, за допомогою якої буде будуватися прогноз. Поле «Кількість періодів» дозволяє вказати, на скільки періодів треба робити прогноз. Кнопка «Обрати види товарів» дозволяє повернутися до попереднього вікна. Кнопка «Побудувати прогноз» дозволяє перейти до наступного етапу.

Якщо двічі кліпнути на назву виду товарів, то з'явиться вікно (рисунок 5.8), в якому можна переглянути наявну статистику по обраному виду товарів.

Рисунок 5.7 - Вікно налаштування процесу прогнозування



Рисунок 5.8 - Вікно з детальною інформацією по обраному виду товарів

Після того як налаштування процесу прогнозування зроблені, необхідно натиснути кнопку «Побудувати прогноз». З'являється вікно, «Прогноз споживацького попиту» (рисунок 5.9). В цьому вікні показано, яка модель прогнозування використовувалася для кожного із видів товарів.

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

Якщо двічі кліпнути на назву виду товарів, то з'явиться вікно (рисунок 5.10), в якому можна переглянути прогнозований споживацький попит для обраного виду товарів.

Рисунок 5.9 - Вікно що відображає модель прогнозування для кожного із видів товарів



Рисунок 5.10 - Вікно що відображає прогнозований споживацький попит для обраного виду товарів

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

Кнопка «Повернутися до прогнозів» дозволяє повернутися до попереднього етапу. Кнопка «Зберегти рішення» дозволяє зберегти звіт, у форматі HTML, про отримане рішення.



Рисунок 5.11 - Вікно з витратами фірми при різних стратегіях управління запасами

Якщо двічі кліпнути на назву виду товарів, то з'явиться вікно (рисунок 5.12), в якому можна переглянути детальну інформацію про рішення, а саме:

- номер періоду;

- прогнозований попит в даний період;

- залишок товарів на початок періоду;

- об'єм товарів, до якого необхідно довести запас ;

- об'єм товарів який необхідно замовити;

- вартість організації постачання;

- вартість зберігання надлишку;

- загальні витрати в кожний із періодів, та загальні витрати за всі періоди.



Рисунок 5.12 - Вікно з детальними даними про об'єм поставок

...