Форма № Н-9.02

Вінницький національний технічний університет

(повне найменування вищого навчального закладу)

Факультет інформаційних технологій та комп’ютерної інженерії (повне найменування інституту, назва факультету (відділення))

Кафедра програмного забезпечення (повна назва кафедри (предметної, циклової комісії))

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

на тему: «Розробка сервіс-орієнтованої системи онлайн-замовлень на основі

технології Windows Communication Foundation»

Виконав: студент II курсу, групи 1ПЗ-14мі

спеціальності

8.05010301 – Програмне забезпечення систем (шифр і назва напряму підготовки, спеціальності)

Стрельбіцький М.Ю. (прізвище та ініціали)

Керівник: доц., к.т.н. Майданюк В.П. (прізвище та ініціали) Рецензент: проф., д.т.н. Роїк О.М.

(прізвище та ініціали)

м. Вінниця – 2015 року

2

Форма № Н-9.01

Вінницький національний технічний університет

Факультет інформаційних технологій та комп’ютерної інженерії

Кафедра програмного забезпечення

Освітньо-кваліфікаційний рівень – магістр

Спеціальність 8.05010301 «Програмне забезпечення систем»

ЗАТВЕРДЖУЮ Завідувач кафедри ПЗ, проф., д.т.н.

________________ А.М. Пєтух “____” ________________ 2015 року

З А В Д А Н Н Я

НА МАГІСТЕРСЬКУ КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ

Стрельбіцькому Максиму Юрійовичу

1. Тема роботи: «Розробка сервіс-орієнтованої системи онлайн-замовлень

на основі технології Windows Communication Foundation»,

керівник роботи: Майданюк Володимир Павлович, к.т.н., доцент затверджені

наказом вищого навчального закладу від “___”_____20__ року №___

2. Строк подання студентом роботи

3. Вихідні дані до роботи:

операційні системи – Windows Server 2008 і новіша (веб-сайт),

Windows 7 і новіша (клієнтський додаток),

платформа розробки – .NET Framework,

мова програмування – C#,

час синхронізації із сервером – не більше 1 хв.

4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно

розробити): вступ; обґрунтування доцільності розробки системи онлайн-

замовлень; розробка архітектури системи та вибір засобів її реалізації;

розробка веб-сайту та веб-сервісів; розробка клієнтського додатку

постачальника; тестування роботи сервіс-орієнтованої системи; економічна

частина; висновки; додатки

5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень):

Актуальність теми; Мета роботи, об’єкт та предмет дослідження; Наукова

новизна та практична цінність отриманих результатів; Розробка архітектури

системи; Вибір сервіс-орієнтованої платформи для розробки; Розробка веб-

сайту: шаблон Model-View-Controller; Розробка веб-сайту: моделі; Розробка

веб-сайту: представлення; Розробка веб-сайту: контролер; Приклад веб-сайту

реалізатора; Розробка сервісів сайту; Розробка WCF-сервісу сайту; Розробка

сервісів Web API; Розробка структури клієнтського додатку постачальника;

Розробка WCF-сервісу постачальника; Приклад клієнтського додатку;

Тестування роботи системи; Економічна частина; Висновки

3

6. Консультанти розділів проекту (роботи) Роз-

діл

Прізвище, ініціали та посада

консультанта

Підпис, дата

завдання видав завдання прийняв

1-5 Майданюк В.П., доцент кафедри ПЗ

6 Бальзан М.В., доцент кафедри ЕПВМ

7. Дата видачі завдання______________________________________________

КАЛЕНДАРНИЙ ПЛАН

№

з/п

Назва етапів дипломної роботи Строк виконання

етапів роботи

Примітка

1 Визначення суті технічної проблеми та

постановка задач розробки

11.09.15 Вик.

2 Розробка архітектури системи

16.09.15 Вик.

3 Розробка веб-сайту

30.09.15 Вик.

4 Розробка клієнтського додатку постачальника

9.10.15 Вик.

5 Тестування роботи компонентів системи

13.10.15 Вик.

6 Тестування роботи системи в цілому

16.10.15 Вик.

7 Розробка системних вимог та керівництва

користувача

23.10.15 Вик.

8 Розрахунок економічної частини

30.10.15 Вик.

9 Оформлення матеріалів до захисту МКР

10.11.15 Вик.

Студент _________ Стрельбіцький М.Ю.

( підпис ) (прізвище та ініціали)

Керівник роботи _________ Майданюк В.П.

( підпис ) (прізвище та ініціали)

4

АНОТАЦІЯ

У магістерській кваліфікаційній роботі розроблено сервіс-орієнтований

програмний комплекс для організації електронних замовлень товарів через

мережу Інтернет. Впровадження розробки дозволить автоматизувати процеси

оформлення та обробки замовлень, а також синхронізувати обмін даними між

ланками ланцюжка «постачальник-реалізатор-замовник».

В ході виконання роботи обґрунтовано доцільність розробки системи,

виконано розробку архітектури системи, розроблено веб-сайт із використанням

шаблону ASP.NET MVC та клієнтський додаток постачальника у формі Windows

Forms Application. Компонентне та комплексне тестування системи показало її

високу продуктивність та коректність роботи.

5

ABSTRACT

This paper addresses the service-oriented system developed for organizing of

online ordering process. Implementation of the products allows automating processes

of ordering and synchronizing data exchange between links of the chain ‘vendor-

provider-customer’.

In the course of the paper were performed substantiation of expediency of system

development, architecture design, development of website using ASP.NET MVC and

development of client application using Windows Forms. Unit and complex testing has

shown its high performance and correctness.

6

ЗМІСТ

ВСТУП ......................................................................................................................... 9

1 ОБҐРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ СИСТЕМИ ОНЛАЙН-

ЗАМОВЛЕНЬ ............................................................................................................. 12

1.1 Визначення суті технічної проблеми ...................................................... 12

1.2 Аналіз функціональних можливостей аналогів ..................................... 13

1.3 Порівняння технічних показників аналогів та нового технічного

рішення ....................................................................................................... 16

1.4 Постановка задач дослідження ................................................................ 18

1.5 Висновки .................................................................................................... 18

2 РОЗРОБКА АРХІТЕКТУРИ СИСТЕМИ ТА ВИБІР ЗАСОБІВ ЇЇ

РЕАЛІЗАЦІЇ ............................................................................................................... 20

2.1 Аналіз предметної галузі .......................................................................... 20

2.2 Розробка архітектури системи ................................................................. 21

2.3 Аналіз та обґрунтування вибору сервіс-орієнтованої платформи для

розробки ..................................................................................................... 26

2.4 Аналіз та обґрунтування вибору основної мови програмування та

середовища розробки ................................................................................ 28

2.5 Висновки .................................................................................................... 29

3 РОЗРОБКА ВЕБ-САЙТУ ТА ВЕБ-СЕРВІСІВ .................................................... 30

3.1 Аналіз та вибір методів реалізації веб-сайту у середовищі .NET ........ 30

3.2 Розробка сайту із використанням шаблону ASP.NET MVC ................ 32

3.2.1 Розробка моделей (Models) ........................................................... 34

3.2.2.1 Опис засобів реалізації веб-сторінки .................................... 37

3.2.2.2 Реалізація шаблону MVVM засобами Knockout .................. 38

7

3.2.3 Розробка контролерів (Controllers) ............................................... 40

3.3 Розробка сервісів сайту ............................................................................ 41

3.3.1 Розробка серверного WCF-сервісу ............................................... 41

3.3.2 Розробка сервісів Web API ............................................................ 43

3.4 Висновки .................................................................................................... 44

4 РОЗРОБКА КЛІЄНТСЬКОГО ДОДАТКУ ПОСТАЧАЛЬНИКА ..................... 45

4.1 Розробка структури клієнтського додатку постачальника ................... 45

4.2 Розробка моделей клієнтського додатку постачальника ...................... 46

4.3 Розробка модуля контролю за файловою системою ............................. 48

4.4 Розробка WCF-сервісу .............................................................................. 49

4.5 Аналіз та вибір засобів розробки графічних інтерфейсів у середовищі

.NET ............................................................................................................ 50

4.6 Розробка додатку у вигляді Windows Forms Application ...................... 51

4.7 Висновки .................................................................................................... 54

5 ТЕСТУВАННЯ РОБОТИ СЕРВІС-ОРІЄНТОВАНОЇ СИСТЕМИ ................... 55

5.1 Тестування роботи сайту .......................................................................... 56

5.2 Тестування роботи клієнтського додатку постачальника .................... 60

5.3 Тестування роботи системи в цілому ..................................................... 62

5.4 Розробка системних вимог ....................................................................... 67

5.5 Керівництво для користувачів сайту ...................................................... 68

5.5 Висновки .................................................................................................... 71

8

6 ЕКОНОМІЧНА ЧАСТИНА .................................................................................. 72

6.1 Оцінювання комерційного потенціалу розробки .................................. 72

6.2 Прогнозування витрат на виконання науково-дослідної роботи ......... 74

6.3 Прогнозування комерційних ефектів від реалізації результатів

розробки ..................................................................................................... 78

6.4 Розрахунок ефективності вкладених інвестицій та періоду їх

окупності .................................................................................................... 80

6.5 Висновки .................................................................................................... 84

ВИСНОВКИ ............................................................................................................... 85

ПЕРЕЛІК ПОСИЛАНЬ ............................................................................................. 86

ДОДАТОК А. Технічне завдання ............................................................................ 89

ДОДАТОК Б. Лістинг вихідного коду .................................................................... 92

ДОДАТОК В. Ілюстративний матеріал до захисту магістерської роботи ........ 130

9

ВСТУП

Актуальність теми. Із розвитком мережі Інтернет все більшої популярності

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

частину становлять ті, що пов’язані з електронною комерцією, зокрема сервіси

онлайн-замовлень.

Популяризація сервісів зумовлена тим, що вони полегшують зв’язок із

потенційними клієнтами, і це дає поштовх для розробки спеціалізованих веб-

ресурсів, мета яких – привабити користувачів та реалізувати їм товари певної

категорії від виробника. На таких веб-ресурсах зручно розміщувати інформацію

про товари не лише від одного конкретного виробника, але й від його

конкурентів: це додає зручності користувачам, яким не потрібно шукати веб-

сторінки кожного із виробників, дає можливість порівняти товари та обрати

бажаний в одному місці.

Однак, такий підхід створює проблему зв’язку між ланками ланцюжка

«постачальник-реалізатор-замовник»: необхідно реалізувати обмін даними

таким чином, щоб постачальник міг розміщувати інформацію одночасно на

декількох сайтах, а реалізатори, в свою чергу, могли отримувати інформацію від

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

споживачів, краще оцінюють їх потреби, і, як наслідок, ефективніше продають

товари від постачальників.

Керувати вручну декількома сайтами одночасно незручно, тому доцільно

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

повинен одночасно надавати дані про свої товари сайтам, на яких він

зареєстрований, і при виникненні змін в описі товару оперативно оновлювати ці

дані. Сайти, водночас, повинні обробляти запити клієнтів та надсилати їх усім

зареєстрованим постачальникам на виконання. Кожна зі сторін повинна надавати

свою службу, або сервіс, яка може бути використана віддалено.

Тому, враховуючи описані особливості, розробка сервіс-орієнтованої

системи онлайн замовлень є доцільною та актуальною.

10

Зв’язок роботи з науковими програмами, планами, темами. Робота

виконувалася на кафедрі програмного забезпечення ВНТУ у відповідності з

координаційного плану науково-дослідних робіт Міністерства освіти і науки

України (наказ № 37 від 13.02.1997 р.), напрямок – «Перспективні інформаційні

технології, приклади комплексної автоматизації, системи зв’язку».

Об’єктом досліджень є сервіс-орієнтовані системи та інформаційні

процеси, пов’язані із обміном даними між компонентами таких систем.

Предметом досліджень є сервіс-орієнтована архітектура програмних

продуктів та її реалізація у вигляді системи онлайн-замовлень.

Метою роботи є підвищення рівня автоматизації процесів електронної

торгівлі шляхом розробки програмної системи для автоматизованого

оформлення та обробки замовлень у режимі онлайн.

Для досягнення поставленої мети необхідно розв’язати такі задачі:

1. Аналіз предметної галузі та методів вирішення задачі.

2. Розробка архітектури системи.

3. Розробка веб-сторінки та веб-сервісів.

4. Розробка клієнтського додатку постачальника.

5. Тестування розробленої системи.

Методи дослідження. У ході розробки системи було використано такі

методи для дослідження та розробки:

1. Методи розробки архітектури розподілених систем, зокрема сервіс-

орієнтована архітектура.

2. Методи реалізації веб-сайтів у середовищі .NET Framework.

3. Методи дизайну сайту засобами скриптових мов програмування та css-

шаблонів.

4. Методи реалізації сервісів.

5. Методи розробки графічних інтерфейсів клієнтських додатків.

Наукова новизна роботи полягає в наступному:

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

системи онлайн-замовлень, який зменшує часові витрати на розробку і

11

впровадження, підвищує продуктивність роботи та прискорює інтеграцію

програмного комплексу;

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

сторінки, що спрощує навігацію та підвищує інтерактивність.

Практична цінність полягає в наступному:

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

та обробки онлайн-замовлень;

- принципи, покладені в основу розробки, можна використовувати при

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

Структура та обсяг роботи. Робота складається із шести розділів. У

першому розділі проведено аналіз функціональних можливостей аналогів та

обґрунтовано доцільність розробки сервіс-орієнтованої системи онлайн-

замовлень. У другому розділі розроблено архітектуру програмної системи та

обґрунтовано вибір засобів її реалізації. У третьому розділі розроблено веб-сайт

із використанням шаблону ASP.NET MVC. У четвертому розділі розроблено

клієнтський додаток постачальника у вигляді Windows Forms Application. У

п’ятому розділі виконано компонентне та комплексне тестування системи, а

також розроблено системні вимоги та керівництво користувача. У шостому

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

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

ілюстративний матеріал до захисту магістерської кваліфікаційної роботи.

12

1 ОБҐРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ СИСТЕМИ ОНЛАЙН-

ЗАМОВЛЕНЬ

1.1 Визначення суті технічної проблеми

Сучасні темпи зростання обсягів інформації та комп’ютеризації

досягаються завдяки стрімкому розвитку мережі Інтернет, покращенню

апаратних та програмних засобів та наповненню мережі контентом.

Використання локальних та глобальних мереж дозволяє ширше та повніше

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

даними незалежно від їх апаратної реалізації.

Розширення мережі дозволяє використовувати її для цілого спектру як

повсякденних, так і корпоративних задач. Проте, деякі із них потребують

використання нестандартних підходів і, як наслідок, створення нових способів їх

розв’язання. Так, одним із варіантів вирішення проблеми комунікації між

пристроями при розробці програмного забезпечення є використання сервіс-

орієнтованого підходу.

Використання такого підходу надає ряд переваг. Зокрема, до стратегічних

переваг можна віднести такі:

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

- підвищення продуктивності;

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

корпоративна інтеграція [1].

Відомо, що реалізація традиційних рішень для інтеграції прикладних

програм – непросте завдання, що вимагає істотних капіталовкладень. Крім того,

часто при впровадженні необхідно написання програмного коду. Сервіс-

орієнтована архітектура передбачає розміщення сервісів в мережі в режимі

виконання, тобто дозволяє автоматизувати ці ресурсномісткі процеси, завдяки

чому істотно скорочуються всі витрати на інтеграцію.

13

Тактичними перевагами використання такого підходу є:

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

- використання поточних інвестицій;

- зменшення ризиків, пов’язаних із впровадженням проектів у галузі

автоматизації послуг та процесів;

- можливість неперервного покращення якості послуг;

- скорочення кількості звернень за технічною підтримкою;

- підвищення показника повернення інвестицій;

- декомпозиція процесів розробки та слабка зв’язність компонентів

системи [2].

Таким чином, використання сервіс-орієнтованого підходу є доцільним при

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

саме для створення системи онлайн-замовлень.

1.2 Аналіз функціональних можливостей аналогів

На сьогодні розроблено достатньо велику кількість сайтів та сервісів, які

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

спеціалізацію та принципи реалізації. Оскільки розроблювана в магістерській

роботі система реалізує можливість замовлення автомобілів в режимі онлайн,

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

Сайт Toyota-центр Київ [3] (рис. 1.1) дозволяє користувачам замовити

автомобілі марки Toyota онлайн. Сервіс пропонує вибір серед моделей Toyota,

дозволяє вибрати колір та комплектацію автомобіля. При виборі автомобіля

виводиться інформація про приблизну ціну автомобіля, додатково запитуються

дані користувача, який виконує замовлення.

До переваг сайту можна віднести простоту у користуванні, відсутність

необхідності у створенні облікового запису. Негативні сторони – відсутність

української локалізації, обмеженість одним виробником та однією обраною

моделлю авто, а також відсутність текстового опису.

14

Рисунок 1.1 – Сайт Toyota-центр Київ

Сайт компанії Chery в Україні [4] (рис. 1.2) надає можливість замовляти

автомобілі Chery онлайн. Від користувача необхідно ввести персональні дані та

обрати модель авто із випадаючого списку. Така реалізація сайту є досить

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

із модулем замовлення, що робить сайт малоінформативним.

15

Рисунок 1.2 – Сайт компанії Chery в Україні

Сайт CarsDirect [5] (рис. 1.3) надає можливість замовлення нових та б/у

автомобілів у Сполучених Штатах. Сайт має обширний функціонал, який

дозволяє порівнювати характеристики автомобілів, переглядати описову

інформацію, зв’язуватись напряму із продавцями та інше.

До недоліків слід віднести виключно англомовну реалізацію,

ускладненість інтерфейсу користувача, необхідність реєстрації на сайті.

16

Рисунок 1.3 – Сервіс CarsDirect

Отже, в ході аналізу наявних реалізацій систем онлайн-замовлень

автомобілів було виявлено ряд переваг та недоліків, які враховуватимуться при

розробці сервіс-орієнтованої системи онлайн-замовлень.

1.3 Порівняння технічних показників аналогів та нового технічного

рішення

Для того, щоб порівняти можливості нового продукту із існуючими

аналогами, необхідно виділити набір критеріїв, за якими можна їх оцінити.

17

Оскільки достатньої інформації щодо архітектури перелічених сервісів немає,

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

відвідувачі сайту:

- швидкодія;

- українська локалізація;

- простота та зручність інтерфейсу;

- односторінкова реалізація сайту;

- необхідність реєстрації на сайті;

- миттєва реакція на зміни у постачальника;

- можливість вибору серед різних постачальників;

- можливість замовлення декількох моделей одночасно;

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

Виконаємо порівняння за вказаними параметрами і зведемо їх

до таблиці 1.1.

Таблиця 1.1 – Порівняння технічних показників аналогів та системи, що

проектується

Показник Варіанти

Toyota-

центр

Chery CarsDirect Нова

розробка Швидкодія висока висока середня висока Українська локалізація - - - - Простота та зручність

інтерфейсу простий,

зручний

простий,

незручний

складний,

незручний

простий,

зручний Односторінкова реалізація - - - + Необхідність реєстрації - - + - Миттєва реакція на зміни у

постачальника - - - +

Можливість вибору серед

різних постачальників - - + +

Можливість замовлення

декількох моделей

одночасно

- - - +

Залежність від апаратного

чи програмного

забезпечення

- - - -

18

Враховуючи перелічені особливості, можна зробити висновок, що система,

яка проектується, є конкурентоздатною та має деякі переваги в порівнянні з

аналогами. Відсутність української локалізації компенсується простотою та

інтуїтивністю інтерфейсу користувача, крім того, декілька сайтів можуть

працювати синхронно з одними і тими ж постачальниками, що дає змогу

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

1.4 Постановка задач дослідження

Для розробки сервіс-орієнтованої системи онлайн-замовлень необхідно

окреслити ряд задач, які мають бути виконані, а саме:

1. Проаналізувати предметну галузь.

2. Розробити архітектуру сервіс-орієнтованої системи.

3. Обрати платформу та набір технологій і мов програмування для

реалізації системи.

4. Розробити дизайн сайту, на якому можна виконувати замовлення.

5. Реалізувати сервіси, які працюватимуть на стороні сайту.

6. Розробити клієнтський додаток для постачальників.

7. Виконати тестування сайту, додатку та системи в цілому.

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

клієнтського додатку постачальника.

9. Розробити керівництво користувача.

1.5 Висновки

У ході аналізу доцільності розробки сервіс-орієнтованої системи онлайн-

замовлень було визначено суть технічної проблеми та окреслено переваги

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

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

системи онлайн-замовлень.

19

Система створюється на прикладі мережі для замовлення автомобілів від

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

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

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

матиме односторінкову реалізацію, буде динамічним та швидко реагуватиме на

зміни зі сторони постачальників. Гнучкість системи дозволить створити декілька

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

дасть можливість ефективніше враховувати потреби потенційних клієнтів на

регіональному рівні.

Також було сформульовано ряд задач, необхідних до виконання для

реалізації сервіс-орієнтованої системи.

20

2 РОЗРОБКА АРХІТЕКТУРИ СИСТЕМИ ТА ВИБІР ЗАСОБІВ ЇЇ

РЕАЛІЗАЦІЇ

2.1 Аналіз предметної галузі

На початковому етапі розробки програмних систем передбачається

написання технічного завдання (див. Додаток А), формулювання вимог до

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

Програмна система, яка розробляється у магістерській роботі, може бути

використана як комерційне рішення для зв’язку між постачальниками продукції,

її реалізаторами та клієнтами. За допомогою системи постачальник може

створювати набір продуктів, набір характеристик якого описується конкретним

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

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

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

онлайн. Реалізатори отримують набір замовлень та надсилають їх до відповідних

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

відповідним реалізаторам.

Передбачається, що система надаватиме такі можливості:

- робота у локальній або глобальній мережі;

- автоматична реєстрація постачальника на сайті;

- надання постачальником актуальної інформації про продукцію та

оперативне відображення на сторінці;

- відображення змін в списку та/або описі продукції;

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

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

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

додаткових параметрів;

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

продукції реалізатору.

21

2.2 Розробка архітектури системи

Архітектура програмного забезпечення – це структура програми або

обчислювальної системи, яка містить програмні компоненти, видимі ззовні

властивості цих компонентів, а також відносини між ними [6].

Область комп’ютерних наук з моменту свого утворення зіткнулася з

проблемами, пов’язаними зі складністю програмних систем. Раніше проблеми

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

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

зрозуміти і пояснити програмну архітектуру системи були повні неточностей і

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

з’єднаних лініями. В 1990-ті роки спостерігається спроба визначити і

систематизувати основні аспекти даної дисципліни. Початковий набір шаблонів

проектування, стилів дизайну, передового досвіду, мови опису та формальна

логіка були розроблені протягом цього часу. Основною ідеєю дисципліни

програмної архітектури є ідея зниження складності системи шляхом абстракції і

розмежування повноважень. Досі немає згоди щодо чіткого визначення терміну

«архітектура програмного забезпечення» [7].

Будучи дисципліною без чітких правил про «правильний» шлях створення

системи, проектування архітектури ПЗ є поєднанням науки і мистецтва. Аспект

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

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

сценаріїв як нефункціональні вимоги до системи, також відомі як атрибути

якості, які визначають, як буде вести себе система. Атрибути якості системи

включають в себе відмовостійкість, збереження зворотної сумісності,

розширюваність, надійність, придатність до сервісного обслуговування,

доступність, безпека, зручність використання, а також інші якості. З точки зору

користувача програмної архітектури, вона дає напрям руху і вирішення завдань,

пов’язаних зі спеціальністю кожного такого користувача, наприклад,

зацікавленої особи, розробника ПЗ, групи підтримки, спеціаліста із супроводу,

22

спеціаліста із розгортання ПЗ, тестувальника, а також кінцевих користувачів. У

цьому сенсі архітектура програмного забезпечення насправді об'єднує різні

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

об’єднані в архітектурі програмного забезпечення, є аргументом на захист

необхідності і доцільності створення архітектури ще до етапу розробки ПЗ [8].

Таким чином, розробка архітектури є важливим та невід’ємним етапом

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

дозволяє підвищити ефективність розробки та суттєво зменшити кількість

проблем при подальшій розробці та відлагодженні продукту.

Існує велика кількість архітектурних шаблонів, які підходять для реалізації

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

розробки системи онлайн-замовлень, метою якої є автоматизація процесів між

постачальниками, реалізаторами та потенційними клієнтами, доцільним є

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

Сервіс-орієнтована архітектура (англ. Service-oriented architecture, SOA) –

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

програмного забезпечення, заснований на використанні розподілених, слабко

пов'язаних замінних компонентів, оснащених стандартизованими інтерфейсами

для взаємодії за стандартизованими протоколам [9].

До появи концепції SOA при розробці систем в якості відправного моменту

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

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

чого впроваджувалися. Сьогодні ситуація змінилася докорінно: сучасні

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

розробки та тестування. Так, за допомогою методів моделювання можна

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

потім автоматично отримувати описи цих діаграм на XML-мовах управління

бізнес-процесами.

23

Така технологія управління бізнес-процесами є великим кроком вперед з

точки зору підвищення ефективності розробки систем; за значимістю її можна

порівняти із створенням в кінці 50-х років компіляторів мов високого рівня.

Дійсно, даний підхід дозволяє спростити виклик Web-сервісів з будь-якого місця

розташування і їх виконання на основі бізнес-правил. Крім того, при зміні цих

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

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

повільного ручного кодування, використовуваного при створенні систем, до

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

правил, якщо це необхідно, набагато швидше [10].

Сервіс-орієнтована архітектура – це парадигма, призначена для

проектування, розробки та управління дискретних одиниць логіки (сервісів) в

обчислювальному середовищі. Застосування цього підходу вимагає від

розробників проектування застосунків як набору сервісів, навіть якщо переваги

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

застосунків і подумати, як скористатися вже наявними сервісами, або вивчити,

як їх сервіси можуть бути використані їх колегами.

SOA підштовхує до використання альтернативних технологій і підходів

(таких як обмін повідомленнями) для побудови застосунків за допомогою

зв'язування сервісів, а не за допомогою написання нового програмного коду. У

цьому випадку, при належному проектуванні, застосування повідомлень

дозволяє компаніям своєчасно реагувати на зміну ринкових умов — настроювати

процес обміну повідомленнями, а не розробляти нові програми [11].

Ще до недавніх пір термін «сервіс-орієнтована архітектура» був синонімом

терміну «Web-сервіс». SOA – виклик Web-сервісів за допомогою засобів і мов

управління бізнес-процесами. SOA – це термін, який з’явився для опису

виконуваних компонентів, таких як Web-сервіси, які можуть викликатися

іншими програмами, які виступають у якості клієнтів або споживачів цих

сервісів. Ці сервіси можуть бути повністю сучасними, або навіть застарілими

прикладними програмами, які можна активізувати як чорний ящик. Від

24

розробника не потрібно знати, як працює програма, необхідно лише розуміти, які

вхідні та вихідні дані потрібні, і як викликати ці програми для виконання. У

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

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

учасників виглядає досить просто: постачальник сервісу реєструє свої сервіси в

реєстрі, а споживач звертається до реєстру із запитом [10].

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

для звернення до сервісу – інтерфейс повинен не залежати від платформи. SOA

реалізує масштабованість сервісів – можливість додавання сервісів, а також їх

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

непов’язаними – вони спілкуються за допомогою повідомлень. Оскільки

інтерфейс повинен не залежати від платформи, то і технологія, використовувана

для визначення повідомлень, також повинна не залежати від платформи. Тому,

як правило, повідомлення є XML-документами, які відповідають XML-схемі.

Дійсно, відкриті стандарти, що описують XML і Web-сервіси, дозволяють

застосовувати SOA до всіх технологій і застосунків, встановлених в компанії. Як

відомо, Web-сервіси базуються на широко поширених і відкритих протоколах:

HTTP, XML, UDDI, WSDL і SOAP. Саме ці стандарти реалізують основні вимоги

SOA: по-перше, сервіс повинен піддаватися динамічному виявленню і викликом

(UDDI, WSDL і SOAP), по-друге, повинен використовуватися незалежний від

платформи інтерфейс (XML). Нарешті, HTTP забезпечує функціональну

сумісність [11].

Першим етапом розробки архітектури є розробка контрактів між сервісами

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

сервіси.

Так, Реалізатор надає Клієнтам можливість отримати список

постачальників, отримати список товарів конкретного постачальника, отримати

опис конкретного товару, надіслати замовлення та переглянути список

виконаних замовлень. Постачальник може зареєструватись або скасувати

25

реєстрацію, додати або видалити товари, а також повідомити про відправлення

товару на склад.

В свою чергу, Постачальник надає Реалізатору можливість передати собі

замовлення на обробку.

Враховуючи перелічені особливості, виконаємо розробку сервіс-

орієнтованої архітектури для сервісу онлайн-замовлень. Схематично вона

відображена на рис. 2.1.

GetVendorsListGetItemsList

GetItemDescriptionSendOrder

GetOrdersList

RegisterVendorUnregisterVendor

AddItemsRemoveItemsAcceptOrder

База даних товарів

База даних замовленьР

еал

ізат

ор

(ве

б-с

айт)

По

стач

альн

ики

Клі

єнти

Клієнт 1 Клієнт 2 Клієнт 3

ProcessOrder

Кеш товарів

ProcessOrder

Кеш товарів

Рисунок 2.1 – Схематичне відображення архітектури сервіс-орієнтованої

системи онлайн-замовлень

26

2.3 Аналіз та обґрунтування вибору сервіс-орієнтованої платформи

для розробки

Для реалізації сервіс-орієнтованої системи зручно обрати готову

платформу, яка дозволяє це зробити. Серед найпопулярніших із них можна

виділити .NET Framework та Java Platform, Enterprise Edition (Java EE).

.NET Framework [12] – програмна платформа, розроблена Microsoft в

основному для запуску в ОС Windows. Включає в себе велику бібліотеку класів,

відому як Framework Class Library (FCL) та надає сумісність мов програмування:

кожна мова може використовувати код, написаний іншою .NET-сумісною

мовою. Програми, написані на .NET Framework, працюють у програмному

середовищі Common Language Runtime (CLR), програмній віртуальній машині,

яка керує пам’яттю, обробляє виключні ситуації та відповідає за безпеку. Разом

FCL та CLR складають .NET Framework.

FCL надає засоби для розробки інтерфейсів користувача та веб-додатків,

роботи із базами даних, криптографічні засоби, тощо. Програміст створює

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

Framework використовується у більшості сучасних додатків, створених для

платформи Windows. Компанія Microsoft також розробила власне середовище

розробки (IDE) для .NET Framework – Visual Studio.

Java Platform, Enterprise Edition [13] (Java EE) – широко використовувана

платформа для розробки корпоративного програмного забезпечення. Платформа

надає прикладний програмний інтерфейс (API) та середовище для розробки та

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

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

Java EE розширює можливості платформи Java, надаючи API для об’єктно-

реляційного відображення (ORM), розподіленої архітектури та веб-сервісів.

Платформа реалізує ідею розробки, яка базується на модульних компонентах, які

запускаються на сервері додатків. Програмне забезпечення для Java EE

розробляється мовою Java.

27

Розглянемо особливості обох платформ, щоб оцінити їх можливості та

обрати одну із них для розробки.

Платформа .NET:

1. Єдиний стек технологій – можна вважати як перевагою, так і недоліком. З

однієї сторони, це значно спрощує та прискорює процеси розробки, але з

іншої, розроблювана система дуже чутлива до змін у самій платформі.

2. Оскільки платформа більшою мірою Windows-орієнтована, можуть

виникати проблеми з компонентами рівня операційної системи

(наприклад, DLL).

3. Архітектура “Think Small”: хоча існує велика кількість великих систем,

розроблених на платформі .NET, ментально вона залишається

орієнтованою на дрібніші проекти, наприклад, онлайн-магазини.

4. Філософія Microsoft, яка полягає у зосередженості на розробнику. В той

час, як API Java EE розроблялись різними постачальниками, такими як

IBM, HP, Sun Systems, тощо, у Microsoft була можливість зробити усе

самостійно. Завдяки цьому розробка на платформі .NET більш уніфікована

та проста [14].

Платформа Java EE:

1. Розробка API велась в основному інженерами Sun, а не користувачами

бібліотек – розробниками, тому вона не дуже зручна для використання.

2. Гнучкість та розширюваність API Java EE дає можливість для розробки

великої кількості відкритих та інноваційних продуктів.

3. Java EE – хороший варіант для розробки великих та складних комерційних

додатків. Фреймворки Spring та Hibernate дозволяють розробляти

високопродуктивні інтеграційні рішення, які підходять для підприємств

будь-якого направлення.

4. Java EE повноцінно мультиплатформена, що теж є плюсом для

використання у великих проектах.

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

яких становить ліцензія [14].

28

Обидві платформи об’єктно-орієнтовані, що має велике значення при

проектуванні архітектури.

Платформа .NET поступається Java EE в плані підтримки ORM-систем для

роботи із базами даних, Entity Framework поки не дає результатів, на які здатна

Java EE. Проте, розробка невеликих корпоративних рішень на платформі .NET є

доцільнішою та продуктивнішою. Що стосується Web-сервісів, явним

переможцем тут є саме .NET Framework. Інструменти для їх розробки добре

інтегровані та дуже зручні [15].

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

.NET Framework.

2.4 Аналіз та обґрунтування вибору основної мови програмування та

середовища розробки

.NET Framework – платформа, яка підтримує велику кількість мов

програмування. Для реалізації сервіс-орієнтованої системи розглянемо і

виберемо одну з популярних мов платформи .NET: C#, C++/CLI або

Visual Basic .NET.

C# – мова програмування, яка підтримує різні парадигми розробки, строгої

типізації, імперативна, декларативна, функціональна, узагальнена, об’єктно- та

компонентно-орієнтована. Розроблена компанією Microsoft, стандартизована у

Ecma (ECMA-334 [16]) та ISO (ISO/IEC 23270:2006). C# – одна із мов

інфраструктури Common Language Infrastructure (CLI). Розроблена як проста,

сучасна об’єктно-орієнтована мова широкого використання. Найбільш

використовувана мова платформи .NET Framework.

C++/CLI – розширення мови C++ у інфраструктурі CLI. Модулі, написані

цією мовою, можуть бути скомпільовані у Common Intermediate Language (CIL),

утворюючи збірки, які можуть повноцінно використовуватись у .NET. C++/CLI

розроблена Microsoft та стандартизована у Ecma (ECMA-372 [17]). Згідно зі

29

стандартом, мова, порівняно із C++, надає додаткові ключові слова, класи,

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

Visual Basic .NET (VB.NET) – мова програмування високого рівня, яка

підтримує різні парадигми розробки. Разом із C# є головними мовами платформи

.NET. Основна відмінність між мовами – синтаксична. Обидві мови

розроблялись спеціально для платформи .NET однією командою розробників з

Microsoft. Обидві мови компілюються у CIL. Практично усі команди у Visual

Basic мають еквівалент у C#, і навпаки.

Синтаксис C# є більш привабливим для використання, ніж синтаксис

Visual Basic, а C++/CLI не надає усіх можливостей, які існують у мові C#. Тому

для розробки сервіс-орієнтованої системи основною мовою програмування

доцільно обрати саме C#.

Для розробки у середовищі .NET існують різноманітні середовища

розробки, наприклад SharpDevelop, Microsoft Visual Studio, тощо. Visual Studio

має ряд переваг порівняно із іншими інструментами для розробки, тому

обираємо його в якості основного середовища розробки (IDE).

2.5 Висновки

У другому розділі було проаналізовано предметну галузь та визначено

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

При розробці архітектури було вирішено обрати сервіс-орієнтований

підхід для реалізації системи. Кожен сервіс надає можливість віддаленого

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

Для реалізації було виконано співставлення платформ .NET Framework та

Java Enterprise Edition, в результаті якого визначено доцільність використання

першої із них. В якості основної мови програмування обрано C#. Розробка буде

виконуватись у середовищі Microsoft Visual Studio.

30

3 РОЗРОБКА ВЕБ-САЙТУ ТА ВЕБ-СЕРВІСІВ

3.1 Аналіз та вибір методів реалізації веб-сайту у середовищі .NET

Для розробки веб-сайту у середовищі .NET існує окрема платформа

ASP.NET. Це інструмент для розробки серверних веб-додатків та динамічних

веб-сторінок. На даному етапі розвитку ASP.NET знаходиться в процесі

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

такими як Entity Framework. Оновлена платформа використовуватиме новий

відкритий компілятор Roslyn та буде крос-платформною. Веб-проекти усіх типів

об’єднаються в уніфікований MVC 6. Процес ре-імплементації має назву

ASP.NET vNext [18].

Розглянемо основні типи проектів, які можна використати для розробки

веб-сайтів: ASP.NET Web Forms та ASP.NET MVC.

ASP.NET Web Forms прийшов на заміну ASP, вирішивши проблеми,

пов’язані зі створенням абстракцій високого рівня для веб-розробників. Web

Forms реалізує концепції зворотної передачі та ViewState (збереження даних з

форми на сторінці). Найцікавіше полягає в тому, що для цього не потрібно

писати жодної стрічки коду. ASP.NET Web Forms – спроба Microsoft втілити

модель Visual Basic у веб-розробку.

Переваги використання ASP.NET Web Forms:

1. Наявність великої кількості готових елементів керування. ASP.NET

генерує відповідний HTML та JavaScript-код для кожного браузера.

2. Підтримка ViewState. Можливість збереження проміжних даних – станів

елементів керування в формі невидимого поля ViewState.

3. Подійно-орієнтоване програмування. Розробнику не потрібно

замислюватись над тим, як працюють http-запити (POST, GET, тощо) на

низькому рівні.

4. Швидкі темпи розробки [19].

31

Втім, є і ряд недоліків:

1. Архітектура проекту. Для проектів Web Forms немає чіткої архітектури

проекту, що може бути проблемою, коли проект стає більшим. Логіка

відображення тісно пов’язана із графічним інтерфейсом, що також має

негативні наслідки при розробці.

2. Складність тестування. Велика кількість обробників подій робить

автоматичне модульне тестування практично неможливим.

3. Низька швидкодія. Застосування ViewState гальмує роботу браузера та

значно збільшує обсяг сторінки.

4. Слабка підтримка паралельної розробки. Компоненти Web Forms тісно

пов’язані одне з одним, тому розробляти графічний дизайн окремо від

логіки сайту неможливо [19].

ASP.NET MVC – ще одна веб-платформа від Microsoft, філософією якої є

розділення відповідальності та хороша тестованість. Вона повністю базується на

шаблоні розробки Model-View-Controller [20] (див. пункт 3.2). ASP.NET MVC не

підтримує концепцію ViewState.

Серед переваг ASP.NET MVC можна виділити такі:

1. Архітектура проекту. Важливою перевагою є розподіл відповідальності.

Це значно знижує ризики ускладнити архітектуру.

2. Зручне тестування та повторне використання коду.

3. Швидкодія. Відсутність ViewState не нагромаджує сторінку, відтак

підвищується швидкодія.

4. Повний контроль над HTML. ASP.NET MVC не використовує серверні

елементи керування, єдина можливість – використання елементів HTML.

Це гарантує отримання чистого HTML на виході та значно полегшує

інтеграцію із сучасними засобами для веб-розробки – наприклад, jQuery.

5. Підтримка паралельної розробки. У ASP.NET MVC компоненти слабко

пов’язані одне одним: можна розробляти моделі (Models), контролери

(Controllers) та представлення (Views) паралельно.

32

6. Маршрутизація посилань. Кожна URL-адреса трактується як ресурс, який

підтримує RESTful-інтерфейси.

7. Розширюваність. Існує велика кількість засобів відображення

представлень (aspx, Razor), і, якщо це необхідно можна створити або

додати власний [19].

Єдиним значним недоліком перед ASP.NET Web Forms є складність у

вивченні, оскільки ASP.NET MVC вимагає у розробника знань у сучасній

веб-розробці.

Враховуючи тенденції розвитку ASP.NET та перелічені особливості

проектів, для розробки доцільно обрати варіант сайту із використанням шаблону

ASP.NET MVC.

3.2 Розробка сайту із використанням шаблону ASP.NET MVC

В основі обраного шаблону ASP.NET MVC лежить архітектурний шаблон

Model-View-Controller (MVC). Цей шаблон поділяє систему на три частини:

модель даних, вигляд даних та керування. Застосовується для відокремлення

даних (модель) від інтерфейсу користувача (вигляду) так, щоб зміни інтерфейсу

користувача мінімально впливали на роботу з даними, а зміни в моделі даних

могли здійснюватися без змін інтерфейсу користувача [21].

Мета шаблону – гнучкий дизайн програмного забезпечення, який повинен

полегшувати подальші зміни чи розширення програм, а також надавати

можливість повторного використання окремих компонентів програми. Крім того

використання цього шаблону у великих системах призводить до певної

впорядкованості їх структури і робить їх зрозумілішими завдяки зменшенню

складності.

Як показано на рис. 3.1, архітектурний шаблон MVC поділяє програму на

три частини. У тріаді до обов'язків компоненту Модель (Model) входить

зберігання даних і забезпечення інтерфейсу до них. Представлення (View)

відповідальне за представлення цих даних користувачеві. Контролер (Controller)

33

керує компонентами, отримує сигнали у вигляді реакції на дії користувача, і

повідомляє про зміни компоненту Модель. Така внутрішня структура в цілому

поділяє систему на самостійні частини і розподіляє відповідальність між різними

компонентами.

Рисунок 3.1 – Взаємодія між компонентами шаблону MVC

MVC поділяє цю частину системи на три самостійні частини: введення

даних, компонент обробки даних і виведення інформації. Модель інкапсулює

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

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

може мати декілька взаємопов'язаних областей, наприклад, різні таблиці і поля

форм, в яких відображається інформація. У функції Контролера входить

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

положення курсора миші, натиснення кнопки або введення даних в текстове

поле).

Зареєстровані події транслюються в різні запити, що спрямовуються

компонентам Моделі або об’єктам, відповідальним за відображення даних.

Відокремлення моделі від представлення дозволяє незалежно використовувати

різні компоненти для відображення інформації. Таким чином, якщо користувач

через Контролер внесе зміни до Моделі даних, то інформація, подана одним або

декількома візуальними компонентами, буде автоматично відкоригована

відповідно до змін, що відбулися [21].

34

3.2.1 Розробка моделей (Models)

У якості моделей на сайті виступають об’єкти доступу до даних, які

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

запити. Вони мають назву Data Access Layers (DAL), або шар доступу до даних.

Оскільки дані на сайті мають нескладну структуру і не потребують

розробки складної структури, як, наприклад, для реляційної бази даних, їх зручно

зберігати у файлі формату XML. C# підтримує технологію LINQ to XML, за

допомогою якої можна працювати із XML-файлами напряму засобами мови

програмування. Підтримується робота із XML-деревами, що дозволяє швидко

знаходити, отримувати, додавати, змінювати або видаляти дані та зберігати

їх у файл.

База даних з моделями товарів представляє файл CarsDatabase.xml,

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

постачальників (назва, адреса сервісу, ідентифікатор) та їх товари (назва, опис,

ціна, доступні кольори).

Рисунок 3.2 – Структура бази даних моделей товарів

Шар доступу до бази даних з моделями товарів (Models DAL) надає

такі функції:

- отримати список постачальників (GetVendorsList);

- отримати адресу сервісу постачальника (GetVendorAddress);

- отримати перелік товарів (GetCarModelsList);

- отримати інформацію про товар (GetCarInfo);

35

- додати постачальника (AddVendor);

- видалити постачальника (RemoveVendor);

- додати товари (AddCars);

- видалити товари (RemoveCars).

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

щодо яких надійшла від постачальників і які доступні для замовлення.

База даних замовлених товарів містить перелік усіх товарів, замовлених

користувачами. Структуру файлу OrdersDatabase.xml наведено на рис. 3.3.

Рисунок 3.3 – Структура бази даних замовлених товарів

Шар доступу до бази даних замовлених товарів (Orders DAL) містить

такі функції:

- отримати список замовлень (GetOrdersList);

- додати замовлення в чергу (AddPendingOrder);

- помітити замовлення як виконані (MarkOrdersAsReady).

Використовуючи ці методи, можна повноцінно працювати із моделлю та

переглядати і редагувати дані у відповідних файлах.

3.2.2 Розробка представлення (View)

Представлення – це компонент шаблону MVC, відповідальний за

відображення даних користувачеві. У випадку ASP.NET MVC представлення –

це шаблони HTML-сторінок (якщо необхідно, зі вставками коду мовами Visual

36

Basic або C#), які компілюються у готові html-сторінки та скрипти мовою

JavaScript.

Значна частина сучасних веб-сайтів розробляється як односторінкові

сайти. Це надає ряд переваг: підвищується інформативність та швидкість роботи

сайту, зменшується кількість відволікаючого контенту, немає посилань на інші

сторінки, тощо.

Цей факт стосується і розробки представлень у ASP.NET MVC: кожній

окремій сторінці відповідає одне представлення. Розробляючи односторінковий

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

представлень. Систему онлайн-замовлень також доцільно реалізувати як

односторінковий сайт.

Структура сторінки передбачається мінімалістичною. На ній буде

відображена вся необхідна користувачеві інформація у зручному вигляді

(рис. 3.4).

Заголовок сайтуМоє

замовленняІсторія

замовлень

Світлина із зображенням моделі

Назва моделі

Опис

Замовлення

Замовити

Постачальники Моделі

Рисунок 3.4 – Структура сторінки

37

3.2.2.1 Опис засобів реалізації веб-сторінки

Веб-сайт, який складається з однієї сторінки, неможливо реалізувати лише

засобами HTML та CSS. Для того, щоб сторінка була динамічною, гнучкою та

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

Найпопулярнішим засобом для створення динамічного контенту є

використання скриптів на веб-сторінках. Найпопулярнішою скриптовою мовою

програмування є JavaScript – динамічна об’єктно-орієнтована мова

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

можливість коду на стороні клієнта взаємодіяти з користувачем, керувати

браузером, асинхронно обмінюватися даними з сервером, змінювати структуру

та зовнішній вигляд веб-сторінки.

Мовою JavaScript написана велика кількість готових інструментів, які

полегшують дизайн та розробку веб-сторінок. Для дизайну веб-сторінки буде

використано одну із найпопулярніших платформ – Twitter Bootstrap [22]. Це

безкоштовна колекція засобів для розробки веб-додатків та веб-сторінок із

відкритим кодом. Вона включає в себе HTML- та CSS-шаблони для типографії,

форм, кнопок, навігації та інших компонентів інтерфейсу, а також додаткові

розширення JavaScript. Bootstrap – платформа для front-end розробки, яка працює

на стороні клієнта, не навантажуючи сервер. Плюсами використання Bootstrap є

велика кількість готових шаблонів сайтів, гнучкість та адаптивність інтерфейсу.

Для зручності розробки на Bootstrap створено спеціальний додаток Pingendo, за

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

представленням у шаблоні ASP.NET MVC. Він дозволяє створити сайт

візуально, щоб не створювати HTML-код вручну.

Для реалізації динамічного контенту зручно використовувати jQuery у

зв’язці із AJAX. jQuery – популярна JavaScript-бібліотека з відкритим кодом.

Синтаксис jQuery розроблений, щоб зробити орієнтування у навігації зручнішим

завдяки вибору елементів DOM, створенню анімації, обробки подій і розробки

AJAX-застосунків. Це сприяє створенню потужних і динамічних веб-сторінок.

38

Щоб сайт міг відображати інформацію про товари в реальному часі, зручно

застосувати компонент ASP.NET SignalR [23]. Вона надає можливість змінювати

контент на пристроях підключених клієнтів одразу ж після того, як ці зміни

виникають на сервері. При цьому користувачу не потрібно перезавантажувати

сторінку. SignalR використовує веб-сокети, які реалізують двосторонню

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

цьому код залишається незмінним. Він буде використаний при реєстрації або

відміні реєстрації постачальника та WCF-сервісом (див. пункт 3.3.1).

Оскільки представлення – це лише шаблон HTML сторінки, її частина

генеруватиметься автоматично під час виконання залежно від інформації,

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

змінюватиметься. Для того, щоб зробити це можливим, можна використати

бібліотеку Knockout [24]. Вона буде використовуватись разом із сервісами Web

API (див. пункт 3.3.2).

3.2.2.2 Реалізація шаблону MVVM засобами Knockout

Knockout – це бібліотека JavaScript, яка дозволяє створювати складні

інтерфейси користувача при змінній моделі даних. Knockout полегшує

реалізацію динамічного оновлення графічного інтерфейсу на сайті. Головні

особливості бібліотеки:

- відстеження залежностей – автоматичне оновлення частин інтерфейсу

при зміні моделі;

- декларативні прив’язки – простий спосіб поєднати дані у моделі із

відображенням;

- розширюваність – можливість використання прив’язок для повторного

використання у коді.

Особливістю цієї бібліотеки є використання шаблону проектування

Model-View-ViewModel (MVVM) [21]. MVVM полегшує відокремлення

розробки графічного інтерфейсу від розробки бізнес логіки.

39

Шаблон MVVM поділяється на три частини:

- Модель (Model) – фундаментальні дані, що необхідні для роботи

додатку;

- Представлення (View) – це графічний інтерфейс, тобто вікно, кнопки

тощо;

- Модель представлення (ViewModel) з одного боку є абстракцією

Вигляду, а з іншого надає обгортку даних з Моделі, які мають

зв'язуватись. Фактично ViewModel призначена для того, щоб

здійснювати зв'язок між моделлю та вікном, відслідковувати зміни в

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

View.

Функціональні зв'язки між користувацьким інтерфейсом та ViewModel

реалізуються через прив’язки (Bindings), які, можуть бути написані в коді або

визначені декларативним шляхом.

Оскільки Knockout – бібліотека JavaScript, дані у моделі отримуються за

допомогою JavaScript-методів, які викликають методи Web API (див. пункт 3.3.2)

для отримання даних зі сторони сервера. Вони зберігаються у вигляді

спеціального типу даних – спостережувані дані (Observables). Отримані дані

записуються у спеціальні поля об’єктів моделі представлення, які прив’язані до

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

Так, при розробці моделей були розроблені такі функції:

- отримати список постачальників (getVendorsList);

- отримати перелік товарів (getCarsList);

- отримати інформацію про товар (getCarInfo);

- надіслати замовлення (sendOrder);

- отримати список замовлень (getOrdersList).

Для кожного компоненту представлення, який має динамічне

відображення, створюється окрема модель представлення:

- список постачальників (VendorsListViewModel): додавання, видалення

постачальника зі списку;

40

- список товарів (CarsListViewModel): додавання, видалення та вибір

товару зі списку;

- опис товару (CarViewModel) – містить набір параметрів товару для

зв’язки та відображення у представленні;

- поточне замовлення (CurrentOrderViewModel): вибір кольору та

кількості товару;

- кошик товарів (CartViewModel): додавання, видалення замовлень;

- історія замовлень (OrdersHistoryViewModel) – містить набір даних про

виконані замовлення для зв’язки та відображення у представленні.

Відзначимо також, що кошик товарів працює локально, не навантажуючи

сервер, і використовує кеш браузера (об’єкт localStorage) для збереження даних.

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

представленні – тобто, на HTML-сторінці. Це досягається за рахунок

використання прив’язок до даних, які містяться у моделях представлення.

3.2.3 Розробка контролерів (Controllers)

Контролер – компонент, який відповідає за зв’язок між моделлю та

представленням. Зазвичай кожному представленню відповідає один контролер.

У нашому випадку необхідно створити контролер для початкової сторінки

HomeController та передати йому у якості аргументу URL-адресу сайту. Це

необхідно для того, щоб зробити можливим виклик API-методів (див. пункт

3.3.2) за допомогою скриптів. Дані передаються через спеціальну відкриту

властивість ViewBag, яка є динамічним об’єктом, схожим на об’єкти JavaScript,

проте керована із C#-коду.

Простота структури контролера пояснюється односторінковою будовою

сайту, а також тим, що динаміка реалізується за допомогою JavaScript, а не

іншого способу для побудови сторінок в ASP.NET MVC – часткового

представлення (Partial View), який дозволяє керувати частиною веб-сторінки.

41

Крім того, ASP.NET MVC передбачає наявність контролерів іншого типу:

це набір методів для роботи із моделлю під назвою Web API. Розробку цих

контролерів буде детально розглянуто у пункті 3.3.2.

3.3 Розробка сервісів сайту

Як було вказано в розділі 2, система онлайн-замовлень розробляється із

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

Веб-сервіс – програмна система зі стандартизованим інтерфейсом, яка

ідентифікується уніфікованим ідентифікатором ресурсів (URI). Веб-сервіси

можуть взаємодіяти один з одним та зі сторонніми додатками за допомогою

повідомлень, які базуються на визначеному протоколі (SOAP, REST, тощо). Веб-

сервіс є одиницею модульності при використанні сервіс-орієнтованої

архітектури додатку.

3.3.1 Розробка серверного WCF-сервісу

Windows Communication Foundation (WCF) – набір API платформи .NET

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

WCF – інструмент, який часто використовується для реалізації сервіс-

орієнтованої архітектури. Він розроблений з урахуванням її принципів, які

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

користувачі. Клієнти можуть користуватись багатьма сервісами, сервіси можуть

бути використані багатьма користувачами. Сервіси слабко зв’язані одне із

одним. Це досягається наявністю інтерфейсу мовою WSDL (Web Services

Description Language), яким може користуватись будь-який клієнт для доступу

до сервісу, незалежно від платформи, з якої він працює [25].

Клієнт підключається до сервісу через кінцеву точку (Endpoint). Кожен

сервіс надає свій контракт через одну або декілька кінцевих точок. Вона включає

42

в себе URL-адресу сервісу та властивості прив’язки, які описують спосіб

передачі даних.

Набір параметрів, які складають кінцеву точку, складають абревіатуру

“ABC” (Address / Binding / Contract, або адреса-прив’язка-контракт). Прив’язка

вказує протокол передачі даних, який використовується для доступу до сервісу,

набір механізмів захисту, якщо вони застосовуються, тощо. WCF включає

більшість стандартних типів прив’язок для популярних протоколів: SOAP

(Simple Object Access Protocol) через HTTP, SOAP через TCP, тощо. Обмін

даними між кінцевою точкою та клієнтом здійснюється через SOAP-

повідомлення у форматі XML, що робить їх платформо-незалежними. Коли

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

(інтерфейс), але і застосовувати прив’язку, яка вказана у кінцевій точці. Клієнт

та сервер повинні мати сумісні кінцеві точки.

WCF підтримує сумісність із додатками WCF, запущених на локальному

або віддаленому пристрої під керуванням Windows, а також зі стандартними веб-

сервісами, розробленими на інших платформах, наприклад на Java.

Для того, щоб постачальники могли автоматично додавати і видаляти

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

сайту. Опишемо кінцеву точку, яка буде доступна його користувачам:

- Адреса. У якості адреси виступає URL сервісу, наприклад http://car-

shop.com/CarShopService.svc.

- Прив’язка. Використовується стандартна прив’язка SOAP через HTML

(wsHttpBinding).

- Контракт. У якості контракту можуть виступати контракти даних (Data

Contract) та контракти сервісу (Service Contract). Оскільки методи

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

відповідає цьому типу товару – у нашому випадку, автомобілю. Він має

відкриті властивості Name (назва моделі), Description (текстовий опис),

ImageLink (посилання на адресу із зображенням), Price (ціна), Colors

(доступні для замовлення кольори). Контрактом сервісу є інтерфейс із

43

набором методів, доступних для віддаленого виклику: AddCars (додати

автомобілі) та RemoveCars (видалити автомобілі).

3.3.2 Розробка сервісів Web API

Web API – ще один тип веб-сервісів, де основний акцент зроблено на

простішому типі комунікації – Representational State Transfer (REST). Web API не

потребує протоколів веб-сервісів, що базуються на XML (SOAP, WSDL) для

підтримки їх інтерфейсів [26].

Як було вказано у пункті 3.2.3, шаблон ASP.NET MVC підтримує ще один

тип контролерів, які не асоціюються із відповідними представленнями, а саме

API-контролери. Методи, які розробляються у API-контролерах, можна

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

лише знати повну URL-адресу відповідного метода та ввести коректний набір

параметрів. Якщо параметр є об’єктом, він передається як стрічка – у вигляді

серіалізованого об’єкта JSON (JavaScript Object Notation).

JSON – це текстовий формат обміну даними між комп`ютерами. JSON

базується на тексті, і може бути з легкістю прочитаним людиною. Формат

дозволяє описувати об'єкти та інші структури даних. Цей формат головним

чином використовується для передачі структурованої інформації через мережу

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

JSON знайшов своє головне призначення у написанні веб-програм, а саме

при використанні технології AJAX. JSON виступає як заміна XML під час

асинхронної передачі структурованої інформації між клієнтом та сервером. При

цьому перевагою JSON перед XML є те, що він дозволяє складні структури в

атрибутах, займає менше місця і прямо інтерпретується за допомогою JavaScript

в об'єкти.

Для роботи системи необхідно реалізувати три контролери:

44

- InformationController. Відповідає за отримання списків постачальників

(GetVendorsList) та моделей (GetCarModelsList), а також отримання опису

конкретного товару (GetCarDescription);

- RegisterController. Дозволяє реєструвати (RegisterVendor) або скасовувати

реєстрацію постачальника (UnRegisterVendor) на сайті. При реєстрації

отримує в якості вхідного параметра адресу сервісу постачальника, а

повертає йому адресу сервісу сайту та ідентифікатор, присвоєний

постачальнику;

- OrderController. Дозволяє надсилати замовлення постачальнику

(SendOrder), отримувати список усіх замовлень на сайті (GetOrdersList) та

приймати виконані замовлення (AcceptDelivery).

3.4 Висновки

У третьому розділі описано процес розробки веб-сайту для системи

онлайн-замовлень. При аналізі варіантів розробки сайту у середовищі .NET було

вирішено обрати шаблон ASP.NET MVC, який є одним із сучасних стандартів

розробки веб-сайтів.

Шаблон MVC поділяється на три компоненти: модель (Model),

представлення (View) та контролер (Controller). У якості моделі виступають бази

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

представлення, в якості якого виступає веб-сторінка, окрім HTML, CSS та

JavaScript використано інструменти та бібліотеки Twitter Bootstrap, jQuery,

AJAX, ASP.NET SignalR та Knockout. За допомогою останнього також

реалізовано шаблон MVVM. До контролерів, окрім основного, входять також

API-контролери, які реалізують методи Web API.

Для віддаленого користування програмним функціоналом сайту

розроблено ряд сервісів WCF та Web API.

45

4 РОЗРОБКА КЛІЄНТСЬКОГО ДОДАТКУ ПОСТАЧАЛЬНИКА

4.1 Розробка структури клієнтського додатку постачальника

Клієнтський додаток встановлюється постачальником для роботи із

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

- реєстрація на сайті та отримання адреси його сервісу;

- керування списком та описом товарів та відображення змін на сайті в

реальному часі;

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

- автоматичний збір замовлень із сайту;

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

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

частини та розробимо його структуру. Виділимо такі основні компоненти:

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

із сайту та очікують на виконання;

- кеш товарів, відображених на сайті. Зберігає список товарів, інформація

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

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

товари, а не оновлює інформацію повністю;

- модуль контролю за файловою системою. Контролює папку у файловій

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

відслідковує зміни у ній;

- сервіс для збереження замовлень. Сервіс, який надає функцію для

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

зі сторони реалізаторів.

Схематично структуру додатку показано на рис. 4.1.

46

По

ста

чал

ьн

ик Сервіс обробки

замовлень

Кеш товарів

База даних поточних замовлень

Модуль контролю за файловою

системою

File1.dllFile2.dllFile3.dll...

Веб-сайт

Рисунок 4.1 – Структура клієнтського додатку постачальника

4.2 Розробка моделей клієнтського додатку постачальника

Як і дані на сайті, дані клієнтського додатку мають нескладну структуру та

не потребують розробки реляційної бази даних, їх також зручно зберігати у

форматі XML. Для клієнтського додатку необхідно зберігати поточні

замовлення, які надійшли від сайту, а також перелік моделей, інформація про які

вже завантажена на сайт.

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

PendingOrdersDatabase.xml, структура даних якого наведена на рис. 4.2. Для

кожного замовлення зберігається його унікальний ідентифікатор (GUID), а

також назва моделі, кількість та колір.

47

Рисунок 4.2 – Структура бази даних поточних замовлень

Шар доступу до бази даних поточних замовлень містить такі функції:

- додати замовлення (AddOrder);

- отримати список поточних замовлень (GetPendingOrders);

- очистити список (ClearPending).

Кеш моделей автомобілів містить інформацію про ті моделі, інформація

про які уже завантажена на сайт. Структура файлу CarsCache.xml наведена на

рис. 4.3. Оскільки кожна модель представлена окремим файлом (див. пункт 4.3),

для кожної із них, крім імені, зберігається ім’я файлу та дата останньої

його зміни.

Рисунок 4.3 – Структура бази даних кешу товарів

Шар доступу до бази даних кешу товарів містить такі функції:

- отримати список поточних моделей в кеші (GetCarsList);

- зберегти в кеші поточний список моделей (CacheCarsInfo);

- очистити кеш товарів (RemoveCache).

Використання цих файлів дає можливість зберігати інформацію на стороні

постачальника та виконувати запити реалізаторів.

48

4.3 Розробка модуля контролю за файловою системою

Для того, щоб дані про товари зберігались у цілісному вигляді та не могли

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

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

допомогою механізму рефлексії.

Рефлексією називається процес виявлення типів під час виконання. Із

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

зручної об’єктної моделі. Наприклад, рефлексія дозволяє отримати список всіх

типів, які містяться всередині певної збірки * .DLL або * .EXE, у тому числі

методів, полів, властивостей і подій, визначених у кожному з них. Можна також

динамічно виявляти набір інтерфейсів, що підтримуються даним типом,

параметрів, які приймає даний метод, та інших деталей подібного роду (таких як

імена базових класів, інформація про простір імен, дані маніфесту і т. д.) [27].

Структура DLL-файлу, який представляє модель товару, є типовою для

всіх моделей, тому додаток обробляє лише ті бібліотеки, які їй відповідають.

Кожна збірка містить інтерфейс ICarModel, в якому перелічено набір

властивостей (Name, Description, ImageLink, Price, Colors), а також клас Car, який

реалізує цей інтерфейс. Дані про модель товару є нічим іншим, як значенням

атрибутів класу Car.

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

файлової системи. Щоб відстежувати зміни у файловій системі (додавання,

редагування або видалення файлу), створюємо об’єкт класу FileSystemWatcher.

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

відповідає конкретній зміні (OnCreated, OnChanged, OnDeleted). Створимо

приватний метод UpdateInformation, який виконує такі дії:

1. Зчитує усю поточну інформацію про товари із бібліотек.

2. Зчитує список закешованих товарів, інформація про які міститься на

сайті.

49

3. Порівнює списки автомобілів та обирає моделі, які необхідно видалити,

а які – додати.

4. Викликає методи RemoveCars та AddCars WCF-сервісу на сайті (див.

пункт 3.3.1).

Таким чином, на сайті завжди відображається актуальна інформація про

товари, а постачальнику не потрібно редагувати її вручну: усі необхідні дані

синхронізуються автоматично.

4.4 Розробка WCF-сервісу

Середовище .NET дозволяє розміщувати WCF-сервіси такими способами:

1. Саморозміщення у будь-якому керованому додатку .NET.

2. Розміщення у якості служби Windows.

3. Розміщення на сервері Internet Information Services (IIS).

Оскільки на стороні постачальника реалізується керований додаток .NET,

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

застосовується розміщення на IIS-сервері. Він створюватиметься програмно при

запуску додатку.

Постачальнику необхідно надати можливість підключеному сайту

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

точку із такими параметрами:

- Адреса. URL-адреса сервісу, на якому він розміщений. Зазвичай вона

складається із виділеної IP-адреси та імені сервісу, наприклад:

http://147.27.4.1:50293/VendorService.

- Прив’язка. Як і на сервері, використовується стандартний тип прив’язки

SOAP через HTTP (wsHttpBinding).

- Контракт. Контрактом даних виступає клас Order, який містить необхідну

інформацію про замовлення (GUID (унікальний ідентифікатор),

ModelName (назва моделі), ModelColor (колір моделі), Quantity

(кількість)). Контрактом сервісу є метод ProcessOrder,

50

який приймає у якості аргумента об’єкт класу Order, обробляє його та

записує до бази даних поточних замовлень.

4.5 Аналіз та вибір засобів розробки графічних інтерфейсів у

середовищі .NET

Для розробки графічних інтерфейсів у середовищі .NET можна

використати один із трьох типів проектів:

- консольний додаток (Console Application);

- додаток Windows Forms (Windows Forms Application);

- додаток Windows Presentation Foundation (WPF Application).

Консольні додатки використовують клас System.Console для зчитування та

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

Помилкові дані виводяться окремим потоком. Є найпростішим типом

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

можливості для відображення графічної інформації дуже обмежені.

Windows Forms дозволяє розробляти якісні графічні додатки, які легко

розгортати та оновлювати, які можуть працювати як в онлайн, так і в офлайн-

режимі та використовувати ресурси комп’ютера у більш захищений спосіб, ніж

стандартні додатки Windows. Windows Forms – технологія середовища .NET, яка

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

і запис до файлової системи. Використовуючи середовище Visual Studio, можна

розробляти додатки, які відображають інформацію, запитують дані у

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

Форма – це візуальна поверхня, на якій відображається інформація для

користувача. Зазвичай вона складається із елементів керування та обробників

подій при натисненні на ці елементи.

Windows Presentation Foundation (WPF) – платформа для розробки додатків

зі складними графічними інтерфейсами. Платформа WPF включає велику

кількість можливостей та інструментів для розробки графічних додатків: модель

51

додатку, ресурси, елементи керування, прив’язки даних, документи, тощо. Це

розширення платформи .NET, яке використовує мову Extensible Application

Markup Language (XAML), яка є XML-подібною, для декларативної розробки

графічних інтерфейсів. Порівняно із Windows Forms, має більший функціонал,

але розробка WPF-додатків є складнішою [28].

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

шаблон проекту Windows Forms Application.

4.6 Розробка додатку у вигляді Windows Forms Application

Для того, щоб не ускладнювати графічний інтерфейс додатку, доречно

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

інформація. Функціонал додатку можна умовно поділити на три частини: робота

із сайтами, робота із товарами, обробка замовлень. Такий поділ зручно

реалізовувати за допомогою компонента TabControl – це панель з декількома

вкладками (рис. 4.4).

Рисунок 4.4 – Елемент керування TabControl

Кожній вкладці відповідає своя частина роботи із програмою: так, вкладка

Sites передбачає роботу із сайтами, до яких підключено постачальника (рис. 4.5).

Можна додати або видалити сайт зі списку, а також зареєструватись на

відповідних сайтах або скасувати реєстрацію.

Вкладка Items відповідає за керування списком товарів. При виборі пункту

Add new можна додати новий товар (рис. 4.6). Потрібно ввести значення усіх

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

52

Рисунок 4.5 – Вкладка для керування сайтами

Рисунок 4.6 – Додавання нового товару

53

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

даними, які зчитуються із DLL-бібліотек (рис. 4.7). Можна їх редагувати або

видалити файл.

Якщо створюється або редагується інформація про товар, створюється

новий DLL-файл: спочатку на основі введених даних отримується вхідний код,

потім збірка компілюється і зберігається у папці, вказаній у файлі конфігурації.

Рисунок 4.7 – Перегляд інформації про існуючий товар

На третій вкладці відбувається обробка замовлень: у вигляді списку

відображаються всі замовлення, виконані на сайтах (рис. 4.8). При натисненні на

кнопку Process відбувається обробка замовлень та повідомлення сайтам про їх

успішне виконання.

54

Рисунок 4.8 – Перелік поточних замовлень

4.7 Висновки

У четвертому розділі описано процес розробки клієнтського додатку

постачальника у системі онлайн-замовлень. Розроблено структуру додатку та

виконано його декомпозицію на складові частини.

Дані про поточні замовлення та кеш товарів на сайтах зберігаються у

відповідних базах даних у вигляді XML-файлів. Інформація про кожну модель

товару зберігається в окремому файлі у вигляді DLL-бібліотеки, що гарантує

цілісність та незмінність даних. Для обробки замовлень із зареєстрованих сайтів

створено WCF-сервіс, який дає можливість сайтам автоматично додавати

замовлення від їх клієнтів. Клієнтський додаток постачальника реалізовано як

проект Windows Forms Application.

55

5 ТЕСТУВАННЯ РОБОТИ СЕРВІС-ОРІЄНТОВАНОЇ СИСТЕМИ

Тестування програмного забезпечення – це процес технічного

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

відносно контексту, в якому він має використовуватись.

Тестування визначається як процес перевірки правильності програми в

динаміці її виконання за тестовими даними. При тестуванні виявляються

недоліки: відмови і дефекти як причини порушення роботи програми, збої як

небажані ситуації, помилки як наслідки збоїв та ін. Тестування вважається

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

Зазвичай для проведення тестування застосовуються методи структурного

(«білий ящик») та функціонального («чорний ящик») тестування [29].

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

в перевірці відповідності поведінки програми її зовнішній специфікації.

Критерієм повноти тестування вважається перебір всіх можливих значень

вхідних даних, що здійснити на практиці надзвичайно важко.

При структурному тестуванні текст програми відкритий для аналізу. Суть

даного методу полягає в перевірці внутрішньої логіки програмного

забезпечення. Повним тестуванням у цьому випадку буде таке, що приведе до

перебору всіх можливих шляхів на графі передач керування програми. Число

таких шляхів може досягати десятків тисяч. Крім того, виникає питання про

створення тестів, що забезпечують дане покриття. Здійснити повне

всеохоплююче тестування навіть простої програми вкрай важко, а часом і

неможливо в силу обмеженості часу й ресурсів. Отже, необхідно мати певні

критерії, за якими мають обиратися контрольні приклади та критерії зупинки

процесу тестування.

Оскільки метод «білого ящика» є досить громіздким, а система досить

функціональна, доречно буде скористатися методом «чорного ящика», не

втручаючись у вихідний текст програми.

56

5.1 Тестування роботи сайту

Для тестування працездатності сайту перевіримо, як він працює із

тестовими даними: додамо двох постачальників – Ford та Honda. На головній

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

замовлення та історії замовлень, а також перелік зареєстрованих постачальників

(рис. 5.1).

Рисунок 5.1 – Головна сторінка сайту

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

(рис. 5.2). Вони відображаються в правій частині відносно списку

постачальників.

Рисунок 5.2 – Перелік моделей після вибору постачальника

При натисненні на відповідну модель відображається повна інформація,

яка надійшла від постачальника: зображення, опис, доступні кольори, ціна

(рис. 5.3).

57

Рисунок 5.3 – Відображення інформації про конкретну модель

При натисненні на один із доступних кольорів з’являється панель

замовлення (рис. 5.4). На ній можна обрати кількість автомобілів обраної марки

і кольору (не більше 10) та додати до замовлення (рис. 5.5).

Рисунок 5.4 – Панель замовлення товару

58

Рисунок 5.5 – Додавання товару в список замовлених

Додамо ще декілька автомобілів до списку (рис. 5.6) та видалимо частину

із них натисканням на іконку у вигляді хрестика. Зазначимо, що у графі Total

price відображається сумарна вартість замовлення.

Рисунок 5.6 – Додавання декількох товарів до загального списку

59

Сайти із використанням Twitter Bootstrap мають адаптивну розмітку та

підлаштовують її під розміри екрана пристрою або ширину вікна браузера

(рис. 5.7). Як можна побачити, розмітка змінюється, але при цьому вся

інформація на сайті залишається доступною.

Рисунок 5.7 – Зміна розмітки сайту для вузького вікна браузера

Із проведених тестів можна дійти висновку, що сайт відображає

інформацію коректно і так, як це передбачалось.

60

5.2 Тестування роботи клієнтського додатку постачальника

Автономне тестування клієнтського додатку постачальника передбачає

перевірку коректності роботи інтерфейсу, а також генерації бібліотек товарів.

На вкладці Sites за допомогою кнопок Add/Remove можна додавати або

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

(рис. 5.8-5.10).

Рисунок 5.8 – Додавання сайту до списку

Рисунок 5.9 – Вибір сайту в списку

61

Рисунок 5.10 – Сайт видалено зі списку

Виконаємо перевірку працездатності вкладки Items. При виборі пункту Add

new з’являється можливість створити нову модель товару, при цьому стає

доступною кнопка Add (див. рис. 4.6). При натисненні на кнопку створюється

бібліотека із іменем формату {Vendor_Name}_{Model_Name}.dll, де

Vendor_Name – ім’я постачальника, Model_Name – назва моделі. Файл

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

папці (рис. 5.11).

Рисунок 5.11 – Збереження бібліотеки у файловій системі

При виборі існуючої моделі на вкладці Items відображається вся наявна

інформація про модель (див. рис. 4.7). Дані (окрім назви моделі) можна

редагувати, та при натисненні кнопки Save спочатку видаляється стара

62

бібліотека, а потім генерується нова (рис. 5.12). Дата її останнього редагування

змінюється відносно інших, згенерованих раніше.

Рисунок 5.12 – Генерація нової бібліотеки при редагуванні даних

При натисненні кнопки Remove бібліотека видаляється із файлової

системи. Як можна побачити із результатів, в автономному режимі клієнтський

додаток постачальника працює коректно.

5.3 Тестування роботи системи в цілому

Для того, щоб перевірити, чи система працює коректно, необхідно

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

який не містить інформації про постачальників, оскільки жоден із них ще не

зареєстрований (рис. 5.13).

Рисунок 5.13 – Запуск сайту без постачальників

Наступним кроком є реєстрація постачальників на сайті. Зареєструємо для

прикладу постачальників BMW, Honda та Jeep. Для цього запустимо клієнтські

63

додатки окремо для кожного постачальника, додамо сайт до списку та

зареєструємо (приклад для постачальника BMW на рис. 5.14). Якщо сайт

недоступний, з’явиться повідомлення про помилку (рис. 5.15).

Рисунок 5.14 – Успішна реєстрація на сайті

Рисунок 5.15 – Повідомлення у випадку, якщо сайт недоступний

Після реєстрації на сайті з’являється список постачальників та їх моделей

(рис. 5.16). Спробуємо видалити бібліотеку Jeep_Wrangler.dll. При видаленні

моделі, сторінка якої переглядається на даний момент, з’явиться повідомлення

64

про те, що вона більше недоступна (рис. 5.17). Оскільки ця модель – єдина, яку

надає виробник, на сайті з’явиться повідомлення про те, що на даний момент

немає доступних моделей від виробника (рис. 5.18).

Рисунок 5.16 – Сайт із зареєстрованими постачальниками

Рисунок 5.17 – Повідомлення про недоступність обраної моделі

Рисунок 5.18 – Повідомлення про відсутність інформації про моделі від

постачальника

65

Аналогічно, при відміні реєстрації постачальника у момент перегляду його

товарів також з’явиться відповідне повідомлення (рис. 5.19).

Рисунок 5.19 – Повідомлення від постачальника про те, що він йде з ринку

Тепер спробуємо виконати замовлення у декількох постачальників

(рис. 5.20), при цьому один із них, BMW, буде недоступним. При цьому з'явиться

повідомлення про недоступність постачальника, а автомобіль залишиться в

списку. Коли постачальник знову буде на зв'язку, клієнт може повторно

замовити автомобіль.

Рисунок 5.20 – Замовлення для декількох постачальників

66

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

загальній історії (рис. 5.21). Значок з пісочним годинником вказує на те, що

замовлення ще не оброблене постачальником і знаходиться в черзі.

Рисунок 5.20 – Замовлення в черзі на обробку

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

поточний перелік замовлень та виконати їх (рис. 5.21). Після успішної обробки

замовлень вони будуть відмічені в історії як виконані (рис. 5.22).

Рисунок 5.21 – Перелік поточних замовлень

67

Рисунок 5.22 – Виконані замовлення в загальному списку

Таким чином, у ході тестування системи було виявлено її повну

працездатність. Серед недоліків при тестуванні можна відзначити, що воно

проводилось тільки в локальній мережі, але з використанням протоколу HTTP.

Передбачається коректна робота при роботі із віддаленим сервером.

Але загалом система працює коректно та опрацьовує виключні ситуації,

якщо вони виникають у ході роботи.

5.4 Розробка системних вимог

Для розгортання системи необхідно виконати вимоги стосовно апаратного

та програмного забезпечення. Коли всі вимоги виконані, можна повноцінно

розгорнути систему на серверах реалізаторів та постачальників.

Вимоги до сервера веб-сайту:

- програмне забезпечення:

o операційна система: Windows Server 2008 або новіша серверна ОС

Windows;

68

o сервер Internet Information Services 7.0 або новіше;

o .NET Framework версії 4.5 або новіше;

- виділене доменне ім’я;

- апаратне забезпечення:

o багатоядерний процесор частотою не менше 2 ГГц;

o оперативна пам’ять: не менше 1024 Мб;

o дисковий простір: не менше 1 Гб.

Вимоги до сервера клієнтського додатку постачальника:

- програмне забезпечення:

o операційна система: Windows 7 або новіша;

o .NET Framework версії 4.5 або новіше;

- апаратне забезпечення:

o процесор частотою не менше 2 ГГц;

o оперативна пам’ять: не менше 1024 Мб;

o дисковий простір: не менше 1 Гб.

Вимоги до користувачів сайту:

- програмне забезпечення:

o встановлений веб-браузер Google Chrome, Firefox, Opera або Internet

Explorer останньої версії.

- апаратне забезпечення:

o кольоровий дисплей із розширенням не менше, ніж 400 пікселів у

ширину.

5.5 Керівництво для користувачів сайту

Для початку роботи із сайтом необхідно перейти на його URL-адресу,

використовуючи будь-який популярний браузер (Google Chrome, Mozilla Firefox,

Opera, тощо).

69

На сторінці можна переглянути перелік виробників товару (панель зліва),

перелік доступних для замовлення моделей (панель по центру) та інформацію

про обрану модель (рис. 5.23).

Рисунок 5.23 – Головна сторінка сайту

Для того, щоб замовити обрану Вами модель, необхідно натиснути на

кнопку бажаного кольору, і під описом товару з’явиться панель замовлення

(рис. 5.24). На панелі замовлення можна обрати бажану кількість товару та

додати його до кошика (кнопка Add to cart).

Рисунок 5.24 – Панель замовлення

70

Обрані Вами товари можна переглянути, натиснувши на кнопку Current

Order (рис. 5.25). Якщо Ви бажаєте видалити товар із кошика, потрібно

натиснути на кнопку у вигляді червоного хрестика зліва від опису позиції у

замовленні.

Рисунок 5.25 – Приклад замовлення

Коли замовлення сформовано, потрібно у кошику натиснути на кнопку

Order now. Виробники будуть сповіщені про замовлення, а у разі успіху ви

отримаєте відповідне повідомлення (рис. 5.26).

Переглянути статус своїх замовлень можна, натиснувши на кнопку Orders

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

у списку зеленою галочкою.

71

Рисунок 5.26 – Повідомлення про успішне замовлення

5.5 Висновки

У п’ятому розділі розглянуто процес тестування розробленого

програмного комплексу. Виконано автономне тестування роботи сайту та

клієнтського додатку постачальника, а також тестування системи в цілому.

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

до неї вимог.

Також розроблено набір вимог до апаратного і програмного забезпечення

та керівництво для користувачів сайту.

72

6 ЕКОНОМІЧНА ЧАСТИНА

6.1 Оцінювання комерційного потенціалу розробки

Метою проведення технологічного аудиту є оцінювання комерційного

потенціалу розробки. Для цього необхідно провести експертне опитування

фахівців. Залучаємо трьох незалежних експертів (Е1, Е2, Е3), яким пропонується

оцінити комерційний потенціал розробки за 12 критеріями за п’ятибальною

шкалою [30].

Критерії оцінювання наведено в табл. 6.1.

Таблиця 6.1 – Рекомендовані критерії оцінювання комерційного

потенціалу розробки та їх можлива бальна оцінка

Критерії оцінювання та бали (за 5-ти бальною шкалою)

Кри-

терій 0 1 2 3 4

Технічна здійсненність концепції:

1

Достовірність

концепції не

підтверджена

Концепція

підтверджена

експертними

висновками

Концепція

підтверджена

розрахунками

Концепція

перевірена на

практиці

Перевірено

роботоздатність

продукту в

реальних умовах

Ринкові переваги (недоліки):

2

Багато

аналогів на

малому ринку

Мало

аналогів на

малому ринку

Кілька аналогів

на великому

ринку

Один аналог на

великому ринку

Продукт не має

аналогів на

великому ринку

3

Ціна продукту

значно вища за

ціни аналогів

Ціна продукту

дещо вища за

ціни аналогів

Ціна продукту

приблизно

дорівнює цінам

аналогів

Ціна продукту

дещо нижче за

ціни аналогів

Ціна продукту

значно нижче за

ціни

аналогів

4

Технічні та

споживчі

властивості

продукту значно

гірші, ніж в

аналогів

Технічні та

споживчі

властивості

продукту трохи

гірші, ніж в

аналогів

Технічні та

споживчі

властивості

продукту на рівні

аналогів

Технічні та

споживчі

властивості

продукту трохи

кращі, ніж в

аналогів

Технічні та

споживчі

властивості

продукту значно

кращі, ніж в

аналогів

5

Експлуатаційні

витрати значно

вищі, ніж в

аналогів

Експлуатаційні

витрати дещо

вищі, ніж в

аналогів

Експлуатаційні

витрати на рівні

експлуатаційних

витрат

аналогів

Експлуатаційні

витрати трохи

нижчі, ніж в

аналогів

Експлуатаційні

витрати значно

нижчі, ніж в

аналогів

Ринкові перспективи

6 Ринок малий і не

має позитивної

динаміки

Ринок малий, але

має позитивну

динаміку

Середній ринок з

позитивною

динамікою

Великий

стабільний ринок

Великий ринок з

позитивною

динамікою

73

Продовження таблиці 6.1

Критерії оцінювання та бали (за 5-ти бальною шкалою)

Кри-

терій 0 1 2 3 4

7 Активна

конкуренція

компаній

Активна

конкуренція

Помірна

конкуренція

Незначна

конкуренція

Конкурентів

немає

Практична здійсненність

8 Відсутні фахівці

як з технічної, так

і з комерційної

реалізації ідеї

Необхідно

наймати фахівців

або витрачати

значні кошти та

час на навчання

наявних фахівців

Необхідне

незначне

навчання фахівців

та збільшення їх

штату

Необхідне

незначне

навчання

фахівців

Є фахівці з питань

як з технічної, так

і з

комерційної

реалізації ідеї

9 Потрібні значні

фінансові

ресурси, які

відсутні.

Джерела

фінансування ідеї

відсутні

Потрібні

незначні

фінансові

ресурси. Джерела

фінансування

відсутні

Потрібні значні

фінансові

ресурси.

Джерела

фінансування є

Потрібні

незначні

фінансові

ресурси.

Джерела

фінансування є

Не потребує

додаткового

фінансування

10 Необхідна

розробка

нових матеріалів

Потрібні

матеріали, що

використовуються

у військово-

промисловому

комплексі

Потрібні

дорогі

матеріали

Потрібні

досяжні та дешеві

матеріали

Всі матеріали для

реалізації ідеї

відомі

та давно

використовуються

у виробництві

11 Термін

реалізації ідеї

більший

за 10 років

Термін

реалізації ідеї

більший

за 5 років.

Термін окупності

інвестицій більше

10-ти років

Термін

реалізації ідеї

від 3-х до 5-ти

років.

Термін окупності

інвестицій більше

5-ти років

Термін

реалізації ідеї

менше

3-х років.

Термін окупності

інвестицій від 3-х

до

5-ти років

Термін реалізації

ідеї

менше

3-х років.

Термін окупності

інвестицій менше

3-х років

12 Необхідна

розробка

регламентних

документів та

отримання

великої кількості

дозвільних

документів на

виробництво та

реалізацію

продукту

Необхідно

отримання

великої кількості

дозвільних

документів на

виробництво та

реалізацію

продукту, що

вимагає значних

коштів та часу

Процедура

отримання

дозвільних

документів для

виробництва та

реалізації

продукту вимагає

незначних коштів

та часу

Необхідно тільки

пові-домлення

відповідним

органам про

виробництво та

реалізацію

продукту

Відсутні будь-які

регламентні

обмеження на

виробництво та

реалізацію

продукту

Результати оцінювання комерційного потенціалу розробки зводимо до

табл. 6.2.

74

Таблиця 6.2 – Результати оцінювання комерційного потенціалу розробки

Критерії Експерти

Експерт 1 Експерт 2 Експерт 3

Бали, виставлені експертами:

1 3 2 3

2 3 2 2

3 2 2 2

4 1 3 3

5 4 3 3

6 3 2 3

7 2 2 1

8 4 3 4

9 1 3 3

10 4 4 4

11 4 4 4

12 4 4 4

Сума балів 35 34 36

Середньоарифметична сума

балів СБ

35

Згідно з отриманими результатами, рівень комерційного потенціалу

розробки можна вважати вищим за середній, оскільки середньоарифметична

сума балів знаходиться в межах 31-40.

6.2 Прогнозування витрат на виконання науково-дослідної роботи

Розрахуємо основну заробітну плату кожного із розробників Зо, які

працюють в наукових установах бюджетної сфери за формулою:

Зо =М

Тр∙ 𝑡 (грн.), (6.1)

де М – місячний посадовий оклад розробника, грн.;

Тр – число робочих днів в місяці, Тр = 22;

t – число днів роботи розробника.

75

В розробці програмного продукту бере участь один програміст. Програма

розроблялась 45 робочих днів. Оклад програміста складає 4400 грн., а

керівника – 6600 грн. Отже, основна заробітна плата програміста та керівника

роботи за весь період роботи відповідно дорівнює:

Зоп =4400

22∙ 45 = 9000 (грн. )

Зок =6600

22∙ 33 = 9900 (грн. )

Виконані розрахунки зведемо до табл. 6.3.

Таблиця 6.3 – Витрати на оплату праці

Найменування

посади виконавця

Місячний

посадовий

оклад, грн.

Оплата за

робочий

день, грн.

Число днів

роботи

Витрати на

оплату

праці, грн.

1. Інженер-

програміст

4400 200 45 9000

2. Керівник 6600 300 33 9900

Всього 18900

Додаткова заробітна плата Зд розраховується як 10% від суми основної

заробітної плати всіх розробників:

Зд = (0,1 … 0,12) ∙ Зо. (6.2)

Зд = 0,1 ∙ 18900 = 1890 (грн)

Нарахування на заробітну плату Нзп розробників, які брали участь у

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

Нзп = (Зо + Зд) ∙𝛽

100, (6.3)

76

де Зо – основна заробітна плата розробників, грн.;

Зд – додаткова заробітна плата всіх розробників та робітників, грн.;

𝛽 – ставка єдиного внеску на загальнообов’язкове державне соціальне

страхування, рівна 36,3 %.

Нзп = (18900 + 1890) ∙36,3

100= 7547 (грн)

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

обладнання можна розрахувати за такою формулою:

А =Ц∙На

100∙

Т

12, грн (6.4)

де Ц – балансова вартість обладнання, приміщень, грн;

На – річна норма амортизаційних відрахувань, %;

Т – термін використання обладнання, приміщень, міс.

Зведемо розрахунки до табл. 6.4.

Таблиця 6.4 – Амортизаційні відрахування

Найменування

обладнання, приміщень

тощо

Балансова

вартість,

грн.

Норма

амортизації,

%

Термін

використання,

міс.

Величина

амортизаційних

відрахувань, грн.

1. Персональний

комп’ютер на базі

процесора Intel i5

15000 15 3 563

2. Приміщення 10000 10 3 250

Всього 813

Відзначимо, що при створенні програмного продукту були також і витрати

на комплектуючі (К). До таких витрат можна віднести витрати на носії

інформації (флеш-пам’ять), блокнот, ручки, заправка картриджів принтеру тощо.

В табл. 6.5 наведено інформацію про використані матеріали.

77

Таблиця 6.5 – Перелік використаних комплектуючих

№ Найменування Ціна,

грн.

Скільки

витрачено,

шт.

Вартість

витрачених

комплектуючих,

грн.

1 Флеш-пам’ять 150 1 150

2 Блокнот 20 1 20

3 Ручка 5 2 10

4 Папір А4 70 1 70

5 Заправка картриджу 75 1 75

325

З урахуванням транспортних витрат:

К = 325·1,1 = 358 грн.

Витрати на силову електроенергію розраховується за формулою:

Ве = В · П · Ф · Кп, (6.5)

де В − вартість 1кВт-години електроенергії, В=1,825 грн/кВт-год;

П − установлена потужність обладнання, кВт, 0,7 кВт;

Ф − фактична кількість годин роботи обладнання, 360 годин;

Кп − коефіцієнт використання потужності, 0,5.

Ве = 1,825 · 0,7 · 360 · 0,5 = 230 грн.

Інші витрати приймаємо рівними основній заробітній платі робітників,

тобто 18900 грн.

Сума всіх попередніх статей витрат дає витрати на виконання даної

частини роботи:

В = Зо + Зд + Нзп + А + К + Ве + Ів, грн (6.6)

78

В = 18900 + 1890 + 7547 + 813 + 358 + 230 + 18900 = 48638 (грн)

Оскільки робота повністю завершена і не продовжуватиметься в

майбутньому, то загальні витрати на її виконання будуть рівними Взаг = В =

48638 грн.

Для розрахунку прогнозу загальних витрат скористаємось формулою:

ЗВ =Взаг

𝛽, (6.7)

де 𝛽 – коефіцієнт, який характеризує етап (стадію) виконання даної роботи.

Оскільки робота знаходиться на стадії впровадження, то 𝛽 = 0,9.

ЗВ =48638

0,9= 54043 (грн)

6.3 Прогнозування комерційних ефектів від реалізації результатів

розробки

Спрогнозуємо кількісно, яку вигоду, зиск можна отримати у майбутньому

від впровадження результатів виконаної наукової роботи.

Виконання нашої наукової роботи та впровадження її результатів буде

здійснюватися протягом одного року. Основні позитивні результати від

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

Одним із основних позитивних результатів є зростання величини прибутку.

При реалізації результатів наукової розробки покращується якість

програмного продукту, що дозволяє підвищити ціну його реалізації на 200 грн.

Кількість одиниць реалізації програмного засобу також збільшиться: протягом

першого року — на 40 шт., протягом другого року — ще на 20 шт. Реалізація

продукції до впровадження результатів наукової розробки складала 100 шт., а

ціна — 500 грн.

79

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

впровадження результатів наукової розробки у кожному році відносно базового

за такою формулою:

іП )100

1()(1

іоо

n

NЦNЦ , (6.8)

де По – покращення основного оціночного показника від впровадження

результатів розробки у даному році. Зазвичай таким показником може бути ціна

одиниці нової розробки;

N – основний кількісний показник, який визначає діяльність підприємства

у даному році до впровадження результатів наукової розробки;

N – покращення основного кількісного показника діяльності

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

Цо – основний оціночний показник, який визначає діяльність підприємства

у даному році після впровадження результатів наукової розробки;

n – кількість років, протягом яких очікується отримання позитивних

результатів від впровадження розробки;

– коефіцієнт, який враховує сплату податку на додану вартість. Ставка

податку на додану вартість дорівнює 20%, а коефіцієнт 8333,0 .

– коефіцієнт, який враховує рентабельність продукту; = 0,25;

– ставка податку на прибуток. У 2015 році = 18%.

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

складе:

∆П1 = [200 · 100 + (500 + 200) · 40] · 0,8333 · 0,25 · (1 −18

100)

= 119584 грн

80

Збільшення чистого прибутку підприємства протягом другого року

(відносно базового року, тобто року до впровадження результатів наукової

розробки) складе:

∆П2 = [200 · 100 + (500 + 200) · (40 + 20)] · 0,8333 · 0,25 · (1 −18

100)

= 157167 грн

Отже, протягом двох років підприємство може розраховувати на

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

6.4 Розрахунок ефективності вкладених інвестицій та періоду їх

окупності

Теперішня вартість інвестицій приймається рівною загальним витратам на

виконання та впровадження результатів роботи, тобто

PV = ЗВ = 54043 грн.

Очікуване зростання прибутку складе, відповідно, у першому році

∆П1 = 119584 грн та у другому році ∆П2 = 157167грн.

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

користуються формулою:

Еабс = (ПП – PV), (6.9)

де ПП – приведена вартість всіх чистих прибутків, що їх отримає

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

PV – теперішня вартість інвестицій, грн.

81

Рух платежів (інвестицій та додаткових прибутків) показано на рис. 5.1.

Початок отримання

прибутків

Базовий рік 1 2 3

54

043

11

958

4

15

716

7

Життєвий цикл розробки

Період отримання прибутків

Рисунок 5.1 – Вісь часу з фіксацією платежів, що мають місце під час

впровадження та розробки результатів НДДКР

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

розраховується за формулою:

т

t

іПЗВПП

10 )1()1(

, (6.10)

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

виявляються результати виконаної та впровадженої НДДКР, грн;

т – період часу, протягом якого виявляються результати впровадженої

НДДКР, роки;

82

– ставка дисконтування, за яку можна взяти щорічний прогнозований

рівень інфляції в країні; для України цей показник знаходиться на рівні 0,1;

t – період часу (в роках) від моменту отримання чистого прибутку до

точки „0”.

Якщо Еабс < 0, то результат від проведення наукових досліджень та їх

впровадження буде збитковим і вкладати кошти в проведення цих досліджень

ніхто не буде.

Якщо Еабс > 0, то результат від проведення наукових досліджень та їх

впровадження принесе прибуток, але це також ще не свідчить про те, що інвестор

буде зацікавлений у фінансуванні даного проекту (роботи).

Користуючись формулою (6.10), розрахуємо приведену вартість усіх

чистих прибутків:

ПП =54043

(1 + 0,1)0+

119584

(1 + 0,1)2+

157167

(1 + 0,1)3= 270954 грн.

Тепер, користуючись формулою (6.9), розрахуємо абсолютну ефективність

вкладених інвестицій:

Еабс = 270954 − 54043 = 216911 грн.

Оскільки Еабс > 0, то вкладання коштів на виконання та впровадження

результатів НДДКР є доцільним.

Розрахуємо відносну (щорічну) ефективність вкладених в наукову

розробку інвестицій Ев. Для цього скористаємося формулою:

1PV

Е1Е жТ абс

в , (6.11)

де Еабс – абсолютна ефективність вкладених інвестицій, грн;

PV –теперішня вартість інвестицій PV = ЗВ, грн;

83

Тж – життєвий цикл наукової розробки, роки.

Ев = √1 +216911,64

54043

3

− 1 = 0,71 або 71%

Розраховану величину Ев порівняємо з мінімальною (бар'єрною) ставкою

дисконтування мін, яка визначає ту мінімальну дохідність, нижче за яку

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

ставка дисконтування мін визначається за формулою:

d + f, (6.12)

де d – середньозважена ставка за депозитними операціями в комерційних

банках; d = 0,2;

f – показник, що характеризує ризикованість вкладень; f = 0,05.

Якщо величина Ев > мін, то інвестор може бути зацікавлений у

фінансуванні даної наукової розробки. В іншому випадку фінансування наукової

розробки здійснюватися не буде.

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

𝜏 = 0,2 + 0,05 = 0,25

Оскільки Ев = 71% > мін = 0,25 = 25%, то у інвестора буде зацікавленість

вкладати гроші в нашу наукову розробку, оскільки значно більші прибутки він

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

банк [30].

Термін окупності вкладених у реалізацію наукового проекту інвестицій Ток

можна розрахувати за формулою:

84

в

окЕ

1Т . (6.13)

Якщо Ток < 3 років, то фінансування даної наукової розробки в принципі є

доцільним.

Ток =1

0,71= 1,4 роки.

Отже, фінансування нашої наукової розробки є доцільним, оскільки

Ток < 3 років.

6.5 Висновки

Результати проведених розрахунків дають можливість зробити висновок

про доцільність розробки та впровадження нашої наукової роботи. Це

підтверджують такі показники як:

- абсолютна ефективність вкладених інвестицій, яка рівна 62664 грн., що є

більшим 0 і вказує на те, що інвестор може бути зацікавленим у нашій

розробці;

- відносна ефективність наукової розробки становить 71%, що є вищим за

мінімальну ставку дисконтування, тому вкласти кошти у нашу розробку

вигідніше, ніж покласти кошти на депозит;

- термін окупності вкладених у реалізацію наукового проекту інвестицій

складе 1,4 роки, що вказує на швидку окупність вкладених інвестицій.

Крім того, розраховано, що наукова розробка приноситиме підприємству

додатковий прибуток протягом двох років за рахунок покращення її якості

порівняно з існуючими аналогами.

85

ВИСНОВКИ

У магістерській кваліфікаційній роботі розроблено сервіс-орієнтований

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

замовлень. Основні результати роботи такі:

1. Проведено аналіз функціональних можливостей та порівняння технічних

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

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

2. Виконано розробку архітектури програмного комплексу. За основу обрано

сервіс-орієнтований підхід для реалізації розподіленої програмної

архітектури.

3. У якості базової обрано платформу розробки .NET Framemork. Основною

мовою розробки обрано C#, а сама розробка виконувалась у середовищі

Microsoft Visual Studio.

4. Виконано розробку веб-сайту з використанням шаблону ASP.NET MVC.

Для дизайну сайту використано ряд інструментів та технологій: HTML,

CSS, JavaScript, Twitter Bootstrap, jQuery, AJAX, ASP.NET SignalR,

Knockout. Розроблено ряд WCF-сервісів та Web API сервісів для

віддаленого використання функціоналу сайту.

5. Розроблено клієнтський додаток постачальника у вигляді Windows Forms

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

зареєстрованими сайтами.

6. Виконано компонентне та комплексне тестування системи, яке показало її

повну працездатність.

7. Розрахунок економічних показників повністю підтвердив доцільність

розробки. Термін окупності розробки склав 1,4 роки, що вказує на швидку

окупність вкладених інвестицій.

86

ПЕРЕЛІК ПОСИЛАНЬ

1. Hao H. What Is Service-Oriented Architecture [Електронний ресурс] /

H. Hao. – 2003. – Режим доступу до ресурсу:

http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html.

2. Сервис-ориентированная архитектура [Електронний ресурс] // InterSoft

Lab. – 2005. – Режим доступу до ресурсу:

http://citforum.ck.ua/internet/webservice/soa/.

3. Тойота центр Киев "Автосамит" [Електронний ресурс] – Режим доступу

до ресурсу: http://www.toyota.com.ua/order.

4. Официальный сайт автомобилей Chery в Украине [Електронний ресурс] –

Режим доступу до ресурсу: http://chery.ua/order_avto_online.html.

5. CarsDirect - Cars for Sale [Електронний ресурс] – Режим доступу до

ресурсу: http://www.carsdirect.com/.

6. Documenting Software Architectures: Views and Beyond / [P. Clements, F.

Bachmann, L. Bass та ін.]., 2010. – (Second Edition). – ISBN 0-321-55268-7.

7. Чернецки К. Порождающее программирование. Методы, инструменты,

применение / К. Чернецки, У. Айзенекер. – СПб: Издательский дом

«Питер», 2005. – 730 с.

8. Кратчен Ф. Ретроспектива программных архитектур / Ф. Кратчен, Х.

Оббинк, Д. Стаффорд. // Открытые системы. – 2006. – №3.

9. Moinuddin M. An Overview of Service-Oriented Architecture in Retail

[Електронний ресурс] / Moin Moinuddin. – 2007. – Режим доступу до

ресурсу: https://msdn.microsoft.com/en-us/library/bb264584.aspx.

10. Channabasavaiah K. Migrating to a service-oriented architecture / K.

Channabasavaiah, K. Holley, E. Tuggle. // IBM DeveloperWorks. – 2003.

11. Bell M. SOA Modeling Patterns for Service-Oriented Discovery and Analysis /

Michael Bell., 2010. – 390 с. – ISBN 978-0-470-48197-4.

12. Microsoft .NET Home [Електронний ресурс] – Режим доступу до ресурсу:

http://www.microsoft.com/net.

87

13. Java EE at a Glance [Електронний ресурс] // Oracle – Режим доступу до

ресурсу:

http://www.oracle.com/technetwork/java/javaee/overview/index.html.

14. Begoli E. .NET vs. J2EE (Java EE) - Architectural Philosophy [Електронний

ресурс] / Edmon Begoli. – 2006. – Режим доступу до ресурсу:

http://it.toolbox.com/blogs/lim/net-vs-j2ee-java-ee-architectural-philosophy-

11290.

15. Davu S. .NET vs Java: How to Make Your Pick [Електронний ресурс] / Srinath

Davu. – 2013. – Режим доступу до ресурсу:

http://www.seguetech.com/blog/2013/06/03/dotnet-vs-java-how-to-pick.

16. Standard ECMA-334. C# Language Specification [Електронний ресурс]. –

2006. – Режим доступу до ресурсу:

http://www.ecma-international.org/publications/standards/Ecma-334.htm.

17. Standard ECMA-372. C++/CLI Language Specification [Електронний

ресурс]. – 2005. – Режим доступу до ресурсу:

http://www.ecma-international.org/publications/standards/Ecma-372.htm.

18. Roth D. Introduction to ASP.NET 5 [Електронний ресурс] / Daniel Roth –

Режим доступу до ресурсу: http://docs.asp.net/en/latest/conceptual-

overview/aspnet.html#unify.

19. Sukesh M. WebForms vs. MVC [Електронний ресурс] / Marla Sukesh. – 2014.

– Режим доступу до ресурсу:

http://www.codeproject.com/Articles/528117/WebForms-vs-MVC.

20. Фримен А. ASP.NET MVC 5 с примерами на C# 5.0 для профессионалов /

Адам Фримен. – Вильямс, 2015. – 736 с.

21. Приемы объектно-ориентированного проектирования. Паттерны

проектирования / Э.Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес. – Питер,

2014. – 366 с. – ISBN 978-5-496-00389-6.

22. Bootstrap. The world's most popular mobile-first and responsive front-end

framework [Електронний ресурс] – Режим доступу до ресурсу:

http://getbootstrap.com/.

88

23. ASP.NET SignalR [Електронний ресурс] – Режим доступу до ресурсу:

http://signalr.net/.

24. Knockoutjs: Introduction [Електронний ресурс] – Режим доступу до

ресурсу: http://knockoutjs.com/documentation/introduction.html.

25. WCF 4: Windows Communication Foundation и .NET 4 для профессионалов

/ П.Сирбаро, К. Клайс, Ф. Коссолино, Й. Грабнер. – Вильямс, 2011. –

464 с.

26. ASP.NET Web API [Електронний ресурс] – Режим доступу до ресурсу:

http://www.asp.net/web-api.

27. Ерохин А. Сборки .NET. Рефлексия [Електронний ресурс] / Александр

Ерохин – Режим доступу до ресурсу:

http://professorweb.ru/my/csharp/assembly/level2/2_3.php.

28. Ерохин А. WPF - Windows Presentation Foundation [Електронний ресурс] /

Александр Ерохин – Режим доступу до ресурсу:

http://professorweb.ru/my/WPF/base_WPF/level1/info_WPF.php.

29. Калбертсон Роберт. Быстрое тестирование. / Р. Калбертсон, К. Браун, Г.

Кобб. – Вильямс, 2002. – 374 с. – ISBN 5-8459-0336-X.

30. Методичні вказівки до виконання студентами-магістрантами наукового

напряму економічної частини магістерських кваліфікацйіних робіт /

Уклад. В. О. Козловський – Вінниця: ВНТУ, 2012. – 22 с.