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

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

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

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

на тему: «Розробка web-додатку для онлайн реєстрації пацієнтів на прийом

до лікаря»

Виконала: студентка ІІ курсу,

групи 1ПЗ-14м

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

Програмне забезпечення систем

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

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

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

Вінниця - 2015 року

Білоконна К. В.

Войтко В. В.

Роїк О.М.

1

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

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

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

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

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

ЗАТВЕРДЖУЮ Завідувач кафедри ПЗ

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

З А В Д А Н Н Я

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

Білоконній Катерині Валеріївні

1. Тема роботи: Розробка web-додатку для онлайн реєстрації пацієнтів на

прийом до лікаря.

керівник роботи: Войтко Вікторія Володимирівна, к.т.н., доцент кафедри ПЗ,

затверджені наказом вищого навчального закладу від “__”_____20__року

№___

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

3. Вихідні дані до роботи: операційна система – Windows XP/7/8; середовище

програмування Visual Studio 2013; мова програмування – C#, SQL, JavaScript;

технологія –.NET

4. Зміст розрахунково-пояснювальної записки: обґрунтування доцільності

розробки автоматизованої системи; варіантний аналіз та обґрунтування

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

структури автоматизованої системи; розробка програмного забезпечення

автоматизованої системи; тестування роботи автоматизованої системи;

економічна частина.

5. Перелік графічного матеріалу: мета роботи, об’єкт та предмет

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

значення; high-level архітектура web-додатку; модулі автоматизованої

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

апробації.

2

6. Консультанти розділів роботи

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

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

Підпис, дата

завдання

видав

завдання

прийняв

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

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

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

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

№

з/п

Назва етапів магістерської кваліфікаційної

роботи

Строк

виконання

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

Примітка

1 Технічне обґрунтування доцільності

розробки web-додатку онлайн реєстрації 20.09–25.09

2 Варіантний аналіз та обґрунтування

вибору засобів реалізації web-додатку 26.09–30.09

3 Розробка моделей системи 01.10–10.10

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

системи 11.10–27.10

5 Тестування програмного забезпечення

системи 28.10–04.11

6 Економічна частина 05.11–10.11

Студент ____________ Білоконна К. В.

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

Керівник магістерської кваліфікаційної роботи _____________ Войтко В.В.__

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

3

АНОТАЦІЯ

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

для онлайн реєстрації в лікарні. Для реалізації сайту було розроблено базу

даних, web-сервіс, модель сайту та базові елементи сайту. Подано

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

програмного засобу, елементів інтерфейсу та програмного забезпечення.

Розроблений web–додаток сприятиме ефективному веденню

документації поліклінік та заощаджуватиме час пацієнтів.

Для реалізації web–ресурсу було обрано мову програмування С# та

САПР ПЗ – Microsoft Visual Studio 2013.

Тестування підтвердило ефективність і правильність функціонування

розробленого web–додатку для онлайн реєстрації.

4

АННОТАЦИЯ

В магистерской квалификационной работе было разработано web-

приложение для онлайн регистрации в поликлинике. Для реализации

приложения было разработано базу данных, web-сервис, модель сайта и

базовые элементы сайта. Представлена модель и описание информационного

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

элементов интерфейса и программного обеспечения.

Данное web-приложение будет способствовать эффективному ведению

документации поликлиники и будет экономить время пациентов.

Для реализации web-приложения был избран язык программирования

С# и САПР ПО - Microsoft Visual Studio 2013.

Тестирование подтвердило эффективность и правильность

функционирования разработанного web-приложения для онлайн

регистрации.

5

ABSTRACT

There was developed web-application for online registration to clinics in the

master's qualification work. To realize the site was developed a database, web-

service, site model and basic elements of the site. Posted architecture and

description of information security, describes the development of a framework of

software, interface elements and software.

This web-application will improve clinic workflow and safe patient's time.

To implement web-resource has been chosen programming language C# and

software - Microsoft Visual Studio 2013.

Testing confirmed the effectiveness and correct function developed of web-

application for online registration.

6

ЗМІСТ

ВСТУП .............................................................................................................................. 8

1ТЕХНІЧНЕ ОБГРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ WEB-ДОДАТКУ

ОНЛАЙН РЕЄСТРАЦІЇ………………………………………………………………12

1.1 Аналіз стану питання .......................................................................................12

1.2 Аналіз понять предметної області ..................................................................12

1.3 Порівняльний аналіз існуючих аналогів........................................................14

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

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

2 ВАРІАНТНИЙ АНАЛІЗ ТА ОБГРУНТУВАННЯ ВИБОРУ ЗАСОБІВ

РЕАЛІЗАЦІЇ WEB-ДОДАТКУ .....................................................................................17

2.1 Аналіз принципу роботи web-додатків ..........................................................17

2.2 Аналіз особливостей розробки web-сервісу.................................................18

2.3Аналіз принципу розробки web-сервісів за допомогою фреймворку

Web API ..........................................................................................................21

2.4 Аналіз особливостей розробки бази даних ...................................................25

2.5 Аналіз особливостей розробки web-сайтів ....................................................28

2.6 Аналіз можливостей клієнтської мови програмування JavaScript ..............30

2.7 Аналіз принципу розробки web-сайтів за допомогою фреймворку

AngularJS .........................................................................................................32

2.8 Обшрунтування вибору середовища розробки web-додатку ......................35

2.9 Висновок .........................................................................................................37

3 РОЗРОБКА МОДЕЛЕЙ СИСТЕМИ .........................................................................38

3.1 Розробка high-level моделі системи ...............................................................38

3.2 Розробка моделі бази даних ............................................................................39

3.3 Розробка моделі сайту .....................................................................................42

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

4 РОЗРОБКА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ СИСТЕМИ ...............................49

4.1 Розробка web-сервісу .......................................................................................49

4.1.1 Розробка шаблону маршрутизації .......................................................49

7

4.1.2 Розробка RESTful протоколу з адресами доступу до функцій

web-сервісу .....................................................................................................50

4.2 Розробка бази даних.........................................................................................52

4.3 Розробка модуля Data Access Layer ...............................................................54

4.4 Розробка сайту ..................................................................................................55

4.5 Висновок ...........................................................................................................59

5 ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ СИСТЕМИ .........................60

5.1 Тестування web-сервісу ...................................................................................60

5.2 Тестування бази даних.....................................................................................62

5.3 Тестування web-сайту ......................................................................................64

5.4 Висновок ...........................................................................................................67

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

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

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

6.2.1 Розрахунок витрат, які безпосередньо стотуються виконавців

даного розділу роботи ...................................................................................71

6.2.2 Розрахунок загальних витрат на виконання даної роботи ...............74

6.2.3 Прогнозування загальних витрат на виконання та

впровадження результатів виконаної наукової роботи..............................74

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

розробки ..........................................................................................................74

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

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

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

ВИСНОВКИ ....................................................................................................................81

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

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

ДОДАТОК Б Лістинг програмної реалізації ...............................................................88

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

кваліфікаціної роботи ....................................................................................................96

8

ВСТУП

Актуальність теми. В теперішніх умовах життя вже досить складно

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

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

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

та мобільних гаджетів стають єдиними засобами, що надають широкі

можливості керування інформацією.

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

необхідно або прийти до реєстратури, або подзвонити туди. Але на це

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

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

реєстрації, необхідно буде витратити час на чергу і є ризик взагалі не

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

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

«Зареєструватися». При онлайн реєстрації відбувається значна економія часу

та сил.

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

автоматизованих систем, інформаційних сайтів та web-служб [1-2]. Проте,

менше уваги приділено розроблі моделей систем для онлайн реєстрації. Тому

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

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

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

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

зручний для себе день та час.

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

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

Міністерства освіти і науки України за напрямком – “Програмне

забезпечення систем”.

9

Мета та задачі дослідження. Метою роботи є автоматизація процесу

реєстрації у лікарні шляхом створення інформаційної системи та web-

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

доступу.

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

сучасних Інтернет технологій.

Предмет дослідження – методи та засоби створення автоматизованих

систем, що забезпечують онлайн реєстрацію.

Методи дослідження:

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

автоматизованої системи;

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

створення загальної структури збереження та обробки

інформаційних ресурсів;

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

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

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

створення web-сервісів, web-сайтів та баз даних.

Задачі дослідження:

1. Аналіз і систематизація сучасних принципів створення web-

додатків.

2. Розробка моделей модулів системи для онлайн реєстрації.

3. Розробка програмного забезпечення системи.

4. Тестування компонентів розробленої системи.

Наукова новизна одержаних результатів. Отримали подальший

розвиток системи ведення документообігу в медицині, які відрізняються від

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

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

підвищення швидкодії та ефективності реєстрацій у лікарні.

10

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

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

пацієнтами.

Апробація результатів роботи. Результати роботи доповідалися на

науково-технічних конференціях:

­ XL Науково-технічна конференція професорсько-викладацького

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

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

підприємств м. Вінниці та області, 9-11 березня 2011 року, м. Вінниця.

­ XLІІ Науково-технічна конференція професорсько-викладацького

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

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

підприємств м. Вінниці та області, 13-15 березня 2013 року, м.

Вінниця, в секціях гуманітарних та фундаментальних наук.

­ XLІІ Науково-технічна конференція професорсько-викладацького

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

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

підприємств м. Вінниці та області, 20-22 березня 2013 року, м.

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

­ Міжвузівський студентський вебінар «Інноваційні та інформаційні

технології в бізнесі та освіті», 21 жовтня 2015 року, м. Вінниця.

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

ідей, який був організований Фондом Віктора Пінчука. Робота здобула ІІ

місце та отримала підтримку Фонду в реалізації та впровадженні проекту.

Публікації. Результати роботи опубліковані в 9 наукових працях, з них

1 входить до переліку ВАК України [3], 1 стаття у результатах міжнародної

наукової конференції [4] та 2 свідоцтва на авторське право [5, 6].

Особистий внесок здобувача. У літературі [3] автором розроблено

моделі реалізації навчальних програм; у літературі [4] автором досліджено

11

ринок відеокарт; у літературі [5] розроблено алгоритми динамічної

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

у літературі [6] автором розроблено програмний модуль розпізнавання тексту

за зображенням; у літературі [7] автором проведено аналіз сучасних

технологій розробки web-додатків; у літературі [8] автором проаналізовано

ринок мобільних гаджетів; у літературі [9] автором розроблено моделі

спеціалізованих програм; у літературі [10, 11] автором проведено аналіз

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

Робота складається з 6 розділів. У першому розділі наведено технічне

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

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

другому розділі проведено варіантний аналіз та обґрунтування вибору

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

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

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

реєстрації в лікарнях. У п’ятому розділі наведено результати тестування

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

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

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

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

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

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

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

12

1 ТЕХНІЧНЕ ОБГРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ

WEB-ДОДАТКУ ОНЛАЙН РЕЄСТРАЦІЇ

1.1 Аналіз стану питання

Сучасна реєстратура вирішує величезну кількість завдань, починаючи з

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

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

медичних відділеннях. Однак далеко не кожному керівникові медичної

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

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

складності в складанні графіків і розкладів та вирішити інші організаційні

питання.

Через велику кількість рутинної роботи, величезного потоку

оброблюваної інформації, застарілої форми зберігання і обробки

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

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

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

початку лікування.

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

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

інстанції.

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

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

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

пацієнтами.

1.2 Аналіз понять предметної області

Автоматизована система (АС) – сукупність керованого об'єкта й

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

функцій керування виконує людина. АС являє собою організаційно-технічну

13

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

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

проектування, виробництво тощо) або їх поєднаннях.

Web-додаток – клієнт-серверна програма, в якій клієнтом виступає

мобільний додаток, десктопна програма або web-браузер, а сервером – web-

сервер.

Сервер – у комп'ютерній термінології термін може стосуватися

окремого комп'ютера чи програми. Головною ознакою в обох випадках є

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

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

встановленого програмного забезпечення.

Сервер як комп'ютер – це комп'ютер у локальній чи глобальній мережі,

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

доступ до встановлених сервісів; найчастіше працює цілодобово, чи у час

роботи групи його користувачів.

Сервер як програма – програма, що надає деякі послуги іншим

програмам (клієнтам).

Web-служба, web-сервіс – програмна система, що ідентифікується URI,

та публічні інтерфейси та прив'язки якої визначені та описані мовою XML.

Опис цієї програмної системи може бути знайдено іншими програмними

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

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

допомогою інтернет-протоколів.

Сайт або веб-сайт – сукупність веб-сторінок, доступних у мережі

Інтернет, які об'єднані як за змістом, так і за навігацією. Фізично сайт може

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

Application Programming Interface, API – набір визначень взаємодії

різнотипного програмного забезпечення. Метод абстракції між

низькорівневим та високорівневим програмним забезпеченням.

14

Модель-вигляд-контролер (MVC) – архітектурний шаблон, який

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

забезпечення. Цей шаблон поділяє систему на три частини: модель даних,

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

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

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

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

REST (Representational State Transfer, «передача репрезентативного

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

доступ до інформаційних ресурсів.

HTTP – протокол передачі даних, що використовується в комп'ютерних

мережах. Назва скорочена від Hyper Text Transfer Protocol, протокол передачі

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

HTML (HyperText Markup Language – Мова розмітки гіпертекстових

документів) – стандартна мова розмітки веб-сторінок в Інтернеті.

База даних – це інформаційна модель, що дозволяє упорядоченно

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

властивостей.

1.3 Порівняльний аналіз існуючих аналогів

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

записатися на будь-які події. Для порівняльної експертизи інтернет ресурсів,

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

існуючі портали: портал «Дніпромед», інформаційна система «Поліклініка»,

а також портал «Doc.ua».

Інтернет портал «Дніпромед» [12] – портал для пошуку спеціалістів

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

і амбулаторія з переліком фахівців. Портал dnipromed.com - спільний проект

компанії CDM і КП «Дніпропетровський міський Центр здоров'я»

Департаменту охорони здоров'я Дніпропетровської міської ради. Це

15

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

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

Інформаційна система «Поліклініка» [13] – проект Житомирської

поліклініки №2, запущений у 2013 році. За цим проектом для пацієнта

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

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

подальшому щеплення та профілактичні огляди. Пацієнту не треба

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

чергу в реєстратурі. Лікар отримує інформацію про пацієнтів, які записалися

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

більш якісно використовувати робочий час лікаря та здійснювати

статистичний аналіз.

Doc.ua [14] – безкоштовний онлайн-сервіс пошуку лікаря або лікарні за

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

критеріїв пошуку та видає результати в межах міста Київ.

У таблиці 1.1 наведено зведений аналіз аналогів.

Таблиця 1.1 - Порівняльна характеристика аналогів

Назва

порталу

Можливість

пошуку

спеціаліста

Можливість

запису на

прийом

Можливість

обрання часу

прийому

Поширеність

Поліклініка – + + область

Дніпромед + – – область

Doc.ua + – – область

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

спеціалістів. Тільки портал Поліклініка дає можливість реєстрації. Також усі

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

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

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

Також, відповідно до реформ в медицині, розроблений web-додаток дає

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

16

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

– Провести порівняльний аналіз існуючих аналогів.

– Провести варіантний аналіз засобів реалізації.

– Розробити high-level модель системи.

– Розробити модель бази даних.

– Розробити модель сайту.

– Розробити модуль для маніпулювання даними в базі даних.

– Розробити базу даних web-додатку.

– Розробити web-сервіс.

– Розробити сайт.

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

– Оцінити комерційний потенціал розробки.

– Зробити прогнозування витрат на виконання роботи та

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

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

окупності.

1.5 Висновок

У даному розділі було здійснено детальний аналіз предметної області

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

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

постановку задач дослідження.

17

2 ВАРІАНТНИЙ АНАЛІЗ ТА ОБҐРУНТУВАННЯ ВИБОРУ

ЗАСОБІВ РЕАЛІЗАЦІЇ WEB-ДОДАТКУ

2.1 Аналіз принципу роботи web-додатків

Web-додаток – клієнт-серверний додаток, в якому клієнтом виступає

браузер, а сервером – web-сервер. Логіка web-додатку розподілена між

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

Клієнт найчастіше відповідає лише за відображення інформації, завантаженої

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

інформацією відбувається по мережі Інтернет.

Однією з переваг такого підходу є той факт, що клієнти не залежать від

конкретної операційної системи користувача, тому web-додатки є

кросплатформними сервісами.

Алгоритм роботи web-додатку такий. Клієнт, яким зазвичай є web-

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

URL-адресами. Ресурси – це HTML-сторінки, зображення, файли, медіа-

потоки або інші дані, які необхідні клієнту. У відповідь веб-сервер передає

клієнтові запитані дані. Цей обмін відбувається по протоколу HTTP [15].

Web-сервіс (англ. web service) - програмна система, що ідентифікується

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

Web-сервіс – програма, яка запущена на web-сервері.

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

наприклад, бази даних або іншого web-додатку, розташованого на іншому

сервері.

Переваги web-сервісів:

• Забезпечують взаємодію програмних систем незалежно від

платформи. Наприклад, Windows-C#-клієнт може комунікувати з

Java-сервером, що працює під Linux.

18

• Засновані на базі відкритих стандартів і протоколів. Завдяки

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

web-сервісів.

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

програмних систем через міжмережевий екран. Це значна перевага,

порівняно з такими технологіями, як CORBA, DCOM або Java RMI.

З іншого боку, веб-служби не прив'язані до HTTP – можуть

використовуватися й інші протоколи.

Недоліки web-сервісів:

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

порівнянні з технологіями RMI, CORBA, DCOM за рахунок

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

серверах можливе налаштування стиснення мережевого трафіку.

• Аспекти безпеки. Відповідальні web-служби повинні

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

Сьогодні набирає популярність новий підхід до розробки web-додатків,

а саме у проектуванні web-сторінок – так званий Ajax. При використанні Ajax

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

необхідні дані з сервера, що робить їх більш інтерактивними і

продуктивними.

AJAX, (Asynchronous Javascript and XML – Асинхронний JavaScript і

XML) – підхід до побудови інтерактивних користувацьких інтерфейсів веб-

додатків, що полягає в «фоновому обміні» даними браузера з веб-сервером. У

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

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

2.2 Варіантний аналіз особливостей розробки web-сервісу

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

інтерфейсами, яка ідентифікується за web-адресою.

19

Web-служби можуть взаємодіяти одна з одною і зі сторонніми

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

(SOAP, XML-RPC, REST). Web-служба є одиницею модульності при

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

Термін "web-сервіс" організацією W3C застосовується до багатьох

різних систем, але в основному термін стосується клієнтів та серверів, що

взаємодіють за допомогою повідомлень протоколу SOAP. В обох випадках

припускається, що існує також опис доступних операцій у форматі WSDL.

Хоча наявність цього опису не є вимогою SOAP, а радше передумовою для

автоматичного генерування коду на платформах Java та .NET на стороні

клієнта.

Стандарти, що використовуються веб-службами [1]:

– XML: Розширювана мова розмітки, призначена для зберігання і

передачі структурованих даних;

– SOAP: Протокол обміну повідомленнями на базі XML;

– REST: Протокол обміну повідомленнями на базі JSON, XML;

– WSDL: Мова опису зовнішніх інтерфейсів веб-служби на базі

XML;

– UDDI: Універсальний інтерфейс розпізнавання опису та інтеграції.

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

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

На рисунку 2.1 зображено модель web-сервісу.

Рисунок 2.1 – Модель web-сервісу

20

Розширювана мова розмітки (англ. Extensible Markup Language,

скорочено XML) - запропонований консорціумом World Wide Web (W3C)

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

між різними застосунками, зокрема, через Інтернет. Є спрощеною

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

знаків, і придатний до читання людиною.

Стандарт XML [16] (англ. Recommendation, перше видання від 10

лютого 1998, останнє, четверте видання 29 вересня 2006) визначає набір

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

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

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

Іншими словами, запропонований стандарт визначає метамову, на основі

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

визначаються специфічні, предметно-орієнтовані мови розмітки даних. Ці

обмеження описуються мовами схем (англ. Schema), такими як XML Schema

(XSD), DTD або RELAX NG. Прикладами мов, основаних на XML

є: XSLT, XAML, XUL, RSS, MathML, GraphML, XHTML, SVG, і також XML

Schema.

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

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

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

виклику процедур (RPC), а назва була абревіатурою: Simple Object Access

Protocol - простий протокол доступу до об'єктів. Зараз протокол

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

для виклику процедур. SOAP є розширенням мови XML-RPC.

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

рівня: SMTP, FTP, HTTP та інш. Проте, його взаємодія з кожним із цих

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

Найчастіше SOAP використовується разом з HTTP.

21

REST (скор. від англ. Representational State Transfer - «передача

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

додатку в мережі Інтернет, при якому виклик віддаленої процедури

представляє собою звичайний HTTP-запит (зазвичай GET чи POST; такий

запит називають REST-запит), а необхідні дані передаються в якості

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

методам, таким як SOAP, CORBA и RPC.

У широком розумінні REST підтримує концепцію побудови

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

взаємодії клієнтів і серверів у мережі Інтернет.

WSDL (англ. Web Services Description Language) - мова опису

зовнішніх інтерфейсів веб-служби.

UDDI (англ. Universal Description Discovery & Integration) -

платформово-незалежний інструмент для розміщення описів веб-

сервісів (WSDL) для забезпечення можливості їх пошуку іншими

організаціями і інтеграції в свої системи.

2.3 Аналіз принципу розробки web-сервісів за допомогою

фреймворку Web API

Web API - нове виконавче середовище web-додатків, побудоване на

уроках і паттернах, схвалених в ASP.NET MVC. Використовуючи просту

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

Web API web-служби з невеликим за обсягом кодом і конфігурацією.

Однією з переваг стека технологій на платформі .NET є можливість

створення сервісів. Так, в ASP.NET можна було створювати ASMX-веб-

служби. Крім того, можна використовувати більш функціональну в цьому

плані технологію WCF для створення web-служб.

Але з останнім релізом MVC 4 і взагалі всієї платформи .NET 4.5 в

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

22

служб - Web API. Концепція Web API – новий підхід до реалізації веб-

додатків.

Щоб створити Web API додаток, необхідно при створенні простого

додатку ASP.NET MVC 4, вказати в якості шаблону проекту Web API

(рис.2.2):

Рисунок 2.2 –Приклад створення додатку Web API

Середовище розробки створить звичайний mvc-проект зі стандартною

структурою. За замовчуванням буде створено два контролера. Один з них

стандартний контролер HomeController. Другий контролер - ValuesController,

який і реалізує функціонал Web API. Нижче наведено приклад коду:

public class ValuesController : ApiController

{

// GET api/values

public IEnumerable<string> Get()

{

return new string[] { "value1", "value2" };

}

// GET api/values/5

public string Get(int id)

{

23

return "value";

}

// POST api/values

public void Post([FromBody]string value)

{

}

// PUT api/values/5

public void Put(int id, [FromBody]string value)

{

}

// DELETE api/values/5

public void Delete(int id)

{

}

}

Як видно, синтаксис контролера Web API відрізняється від синтаксу

звичайного контролера. По-перше, він утворений від класу ApiController,

який не пов'язаний з базовим класом звичайних контролерів – Controller. По-

друге, контролери Web API використовують стиль REST. Взагалі підтримка

архітектури REST є одним з основних вузлових пунктів технології Web API.

Для взаємодії з сервером в REST-архітектурі використовуються методи

HTTP:

- GET

- POST

- PUT

- DELETE

У таких контролерах немає звичайних методів дій, як в традиційних

контролерах, які повертають ActionResult. А в контролері ValuesContoller

відповідні методи зіставляються з однойменними методами HTTP.

Оскільки в Web API методи контролера не є прямими ресурсами і

зіставляються з методами HTTP, то і весь механізм маршрутизації діє не так,

як при визначенні звичайних маршрутів. Всі визначення маршрутів для Web

24

API знаходяться у файлі WebApiConfig.cs у папці App_Start. Нижче наведено

приклад налаштування маршрутизації:

public static class WebApiConfig

{

public static void Register(HttpConfiguration config)

{

config.Routes.MapHttpRoute(

name: "DefaultApi",

routeTemplate: "api/{controller}/{id}",

defaults: new { id = RouteParameter.Optional }

);

}

}

У даному випадку визначений один маршрут, де в якості другого

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

певний ідентифікатор.

У результаті звернення api/values відповідатиме зверненню до

контролера ValuesCotroller, причому майже до всіх дій відразу. Але залежно

від використаного методу HTTP фреймворк буде розрізняти, до якої саме дії

відноситься поточний запит.

Так, наприклад, запит GET api/values буде зіставлений з методом

IEnumerable <string> Get() і поверне у відповідь браузеру колекцію елементів

string.

Якщо ж сервер отримає запит PUT з адресою api/values, то такий запит

буде зіставлений з методом Put.

А запиту GET api/values/7 відповідатиме метод string Get(int id), так як

цей метод приймає параметр.

При створенні методів контролера Web API існують деякі умовності.

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

призначеного для них методу HTTP.

25

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

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

як показано в прикладі:

[HttpPost]

public void CreateItem([FromBody]string value) { }

2.4 Аналіз особливостей розробки бази даних

Сучасні інформаційні технології побудовані на принципах взаємодії з

базами даних. Бази даних грають велику роль у житті більшості людей. Вони

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

власні бази товарів, працівників, партнерів, постачальників і закінчуючи

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

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

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

отримати ефективний пошук та взаємодію. Тому вони займають провідне

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

У розроблювальному web-додатку необхідно ефективно зберігати

інформації про пацієнтів, лікарні, лікарів та актуальні години прийому. Для

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

концепцію баз даних.

База даних (БД) - сукупність даних, що зберігаються у відповідності зі

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

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

моделювання даних.

Відмінні ознаки:

1. БД зберігається і обробляється в обчислювальній системі. Таким

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

базами даних не є.

26

2. Дані в БД логічно структуровані (систематизовані) з метою

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

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

складових частин (елементів), зв'язків між ними, а також типізацію елементів

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

семантика і допустимі операції.

3. БД включає схему, або метадані, що описують логічну структуру БД

у формальному вигляді.

Реляційна база – це колекція пов'язаних таблиць. Різниця між базою

даних і реляційною базою даних знаходиться в будові таблиць. У реляційній

базі даних таблиці побудовані так, що є логічний зв'язок між ними. На

підставі інформації, яка є в одній таблиці, можна отримати відповідну

інформацію з іншої таблиці.

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

Етап концептуального проектування полягає в описі і синтезі

інформаційних вимог користувачів у початковий проект БД. Вихідними

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

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

етапу є високорівневе подання (у вигляді системи таблиць БД)

інформаційних вимог користувачів на основі різних підходів.

Спочатку вибирається модель БД. Потім створюється структура БД,

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

режимі перегляду таблиць БД. Тут же забезпечується захист і цілісність (у

тому числі посилальна) даних за допомогою СУБД або шляхом побудови

тригерів.

У процесі логічного проектування використовується високорівневе

подання даних у структуру СУБД, що використовується. Основною метою

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

нормалізації. Ціль нормалізації - мінімізувати повторення даних і можливі

27

структурні зміни БД при процедури оновлення. Це досягається розділенням

(декомпозицією) однієї таблиці в дві або декілька з подальшим

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

пошук знижує швидкодію БД, тобто збільшує час відгуку на запит. Отримана

логічна структура БД може бути оцінена кількісно за допомогою різних

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

додатку, загальний обсяг даних). На основі цих оцінок логічна структура

може бути вдосконалена з метою досягнення більшої ефективності.

Спеціального обговорення заслуговує процедура управління БД. Вона

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

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

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

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

явища використовують систему транзакцій і режим блокування таблиць або

окремих записів.

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

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

блокування далі будуть розглянуті окремо.

На етапі фізичного проектування вирішуються питання, пов'язані з

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

методи доступу.

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

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

використовуватися незалежно в разі відсутності словникової

системи. Сама словникова система може розглядатися як елемент

автоматизації проектування.

Засоби проектування і оціночні критерії використовуються на всіх

стадіях розробки. В даний час невизначеність при виборі критеріїв є

28

найбільш слабким місцем у проектуванні БД. Це пов'язано з труднощами

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

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

відносяться час відповіді на запит, вартість модифікації, вартість пам'яті, час

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

протиріччя критеріїв одне одному.

У той же час існує багато критеріїв оптимальності, які є невимірними

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

цільової функції.

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

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

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

відновлення, можливість розподілу і розширення.

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

кілька місяців.

2.5 Аналіз особливостей розробки web-сайтів

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

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

структуру.

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

потреби користувача. Це зумовлюється тим, що сайти з невірно

спроектованою логічною структурою викликають у відвідувачів небажання

їх відвідувати та розчарування.

Для зручності роботи користувача з інформаційним веб-сайтом

використовується меню навігації. Розробка системи навігації сайту – це одна

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

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

29

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

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

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

Термін «інтерфейс» широко використовується в областях, де людині

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

англійської мови Interface означає зовнішнє обличчя. У комп'ютерному світі

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

інтерфейс, інтерфейс вводу-виводу, зовнішній чи внутрішній інтерфейс,

інтелектуальний інтерфейс, людино-машинний інтерфейс, програмний

інтерфейс та інші.

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

пристроїв, програм і людини.

Особливо важливий інтерфейс, що забезпечує взаємодію користувача з

персональним комп'ютером, так званий інтерфейс користувача. Від зручності

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

в конкурентній боротьбі на ринку програмних засобів. Інтерфейс

користувача може бути символьним і графічним.

Символьний інтерфейс використовується зазвичай при роботі

відеосистеми в текстовому режимі. Інформація виводиться на екран монітора

посимвольно.

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

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

інформацію поточечно.

Графічний інтерфейс в порівнянні з символьним, сприймається як

більш зрозумілий і інтуїтивно ясний.

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

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

Мета створення ергономічного інтерфейсу сайту полягає в тому, щоб

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

30

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

чином, щоб привернути увагу до найбільш важливих одиниць інформації.

Основна ж мета полягає в тому, щоб мінімізувати загальну інформацію на

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

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

1. Природність (інтуїтивність). Робота з сайтом не повинна викликати у

користувача труднощів у пошуку необхідної інформації (елементів

інтерфейсу).

2. Несуперечність. Прийоми роботи зі схожими елементами інтерфейсу

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

3. Відсутність надмірності інформації. Це означає, що користувач

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

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

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

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

щоб мінімізувати процес введення інформації.

4. Гнучкість. Для недосвідчених користувачів інтерфейс може бути

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

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

2.6 Аналіз можливостей клієнтської мови програмування

JavaScript

JavaScript – це мова сценаріїв, що дозволяють зробити html-сторінку

інтерактивною, тобто такою, яка вміє спілкуватися з користувачем. JavaScript

є найбільш популярною мовою сценаріїв в інтернеті, і працює в більшості

браузерів, таких як Intenet Explorer, Firefox, Chrome, Opera, і Safari. У

javascript є свій стандарт: ECMAScript.

JavaScript зазвичай використовується як вбудовується мова для

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

31

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

сторінок.

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

автоматичне керування пам'яттю, прототипне програмування, функції як

об'єкти першого класу.

Javascript не потрібно компілювати, він підключається до HTML-

сторінки і працює одразу.

JavaScript є об'єктно-орієнтованою мовою, але використовуване у мові

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

традиційними клас-орієнтованими мовами. Крім того, JavaScript має ряд

властивостей, властивих функціональним мовам, а саме – функції як об'єкти

першого класу, об'єкти як списки, каррінг, анонімні функції, замикання, що

додає мові додаткову гнучкість.

Нижче наведено основні можливості JavaScript-ів.

JavaScript дає HTML дизайнерам інструмент програмування. Тобто, хоч

автори HTML звичайно не є програмістами, але майже кожен зможе вставити

невеликі частини коду в їх HTML сторінки, адже JavaScript – це мова

сценаріїв з дуже простим синтаксисом.

JavaScript реагує на події. JavaScript може бути налаштований на

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

коли щось трапиться (клік миші, закінчення завантаження сторінки) і

реагувати на це виконанням функції.

JavaScript може читати і писати, а також змінювати вміст HTML

елементів.

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

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

серверу зайвої обробки.

32

JavaScript може використовуватися для визначення браузера

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

цього браузера.

JavaScript може використовуватися для створення cookies – для

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

Для додавання JavaScript-коду на сторінку, можна використовувати

теги <script> </ script>, які рекомендується, але не обов'язково, поміщати

всередині контейнера <head>. Контейнерів <script> в одному документі може

бути скільки завгодно. Атрибут «type = 'text / javascript'» вказувати

необов'язково, так як за замовчуванням стоїть javascript.

2.7 Аналіз принципу розробки web-сайтів за допомогою

фреймворку AngularJS

AngularJS – це JavaScript-фреймворк з відкритим програмним кодом,

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

одної HTML сторінки з CSS і JavaScript. Його мета — розширення

браузерних застосунків на основі шаблону Модель-вид-контролер (MVC), а

також спрощення їх тестування та розробки.

AngularJS спроектований з переконанням, що декларативне

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

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

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

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

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

результаті AngularJS зменшує роль DOM-маніпуляцій з метою підвищення

продуктивності і спрощення тестування.

Фреймворк працює зі сторінкою HTML, що містить додаткові атрибути

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

звичайні змінні JavaScript. Значення цих змінних задаються вручну або

отримуються зі статичних або динамічних JSON-даних.

33

Наразі існує проблема, що HTML відмінно підходить для опису

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

динамічні види у веб-додатках. AngularJS дозволяє розширити синтаксис

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

Використання фреймворку AngularJS є вигіднішим через те, що інші

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

/ або JavaScript, або нав'язуючи обов'язкові інструменти для маніпулювання

DOM. Жоден з цих способів не усуває суть проблеми, а саме те, що HTML не

призначений для динамічних додатків, на відміну від фреймворку AngularJS.

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

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

взаємодіє з іншими бібліотеками. Будь-яка особливість може бути змінена

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

У таблиці 2.1 наведено опис переваг фреймворку AngularJS.

Таблиця 2.1 – Переваги фреймворку AngularJS

Етап Перевага Опис

Керування

Зв'язування

даних

Зв'язування даних - це спосіб автоматичного

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

оновлення моделі при зміні виду. Дивно, але це

виключає DOM-маніпуляції зі списку речей, про які

потрібно турбуватися.

Контролер

Контролери додають поведінку DOM-елементам.

AngularJS дозволяє описати поведінку в простій

формі без шаблонного поновлення DOM, реєстрації

колбеков або сканування змін моделі.

Зрозумілий

JavaScript

На відміну від інших фреймворків, немає

необхідності успадковуватися від власних типів;

обертати модель методами доступу. Використання

JavaScript дозволяє легко тестувати код,

обслуговувати, повторно використовувати і знову ж

звільнити від шаблонів.

Зв’язок із

сервером

Зовнішнє

зв'язування

Зовнішній зв'язок показує, в якому місці додатка

знаходиться користувач. Це корисно, тому що

користувачі зможуть створювати закладки і

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

електронній пошті. AngularJS поєднує в собі

переваги зовнішнього зв'язування з поведінкою

десктопного додатка.

34

Продовження таблиці 2.1 – Переваги фреймворку AngularJS

Валідація форм

Перевірка форм на стороні клієнта важлива, тому

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

AngularJS дозволяє задавати правила перевірки

форми без необхідності писати JavaScript код.

Пишеш менше коду - п'єш більше пива.

Обмін даними

AngularJS містить сервіси високорівневого XHR, що

істотно спрощує код. XHR було обернуто, щоб

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

код при обробці асинхронно-отриманих даних. Це

дозволяє призначати властивості синхронно, тоді як

отримання насправді асинхронне.

Створення

компонентів

Директиви

Директиви - це унікальна і потужна особливість,

доступна тільки в Angular. Директиви дозволяють

винаходити новий HTML синтаксис, спеціально під

конкретне застосування.

Повторне

використання

Директиви використовуються для створення

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

Компонент дозволяє приховати складну DOM-

структуру, CSS і поведінку. Що дозволяє

сфокусувати увагу на те, що додаток робить чи як

воно виглядає.

Локалізація

Одна з найважливіших особливостей серйозного

додатку - локалізація. Angular містить фільтри і

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

доступним для різних мов і культур.

Вбудовування

та

впровадження

Вбудовування

AngularJS превосходно працює з іншими

технологіями. Ви самі вибираєте що

використовувати з AngularJS у додатку. Більшість

фреймворків вимагають повного контролю над

всією сторінкою (додатком). Ця ж сторінка

складається з декількох AngularJS додатків

вбудованих в неї. Так як AngularJS не вимагає

контролю над всією сторінкою, то кілька додатків

можуть бути запущені на одній сторінці без

необхідності використовувати iframe.

Рекомендуємо відкрити вихідний код цієї сторінки

(view-source) і подивитися як він виглядає.

Впроваджування

Впровадження залежності в AngularJS дозволяє

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

програми. Це означає що програма не потребує

методі main (), який, як правило, створює безлад.

Впровадження залежностей є однією з ключових

особливостей AngularJS. Це означає що будь-який

компонент, який не відповідає вашим потребам,

може бути легко замінений.

35

Продовження таблиці 2.1 – Переваги фреймворку AngularJS

Тестування

AngularJS був спроектований так, щоб максимально

полегшити тестування. Він відокремлює подання

від поведінки, вже має в комплекті mock'і, і по

повній використовує впровадження залежності. Так

само в AngularJS вбудований движок для

комплексних (end-to-end) тестів, який рятує від

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

AngularJS зсередини.

2.8 Обґрунтування вибору середовища розробки web-додатку

Для розробки web-додатку було обрано програмний пакет Microsoft

Visual Studio 2013.

Microsoft Visual Studio [17] - серія продуктів фірми Microsoft, які

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

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

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

підтримкою технології Windows Forms, а також веб-сайти, веб-додатки, веб-

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

підтримуються Microsoft Windows, Windows Mobile, Windows CE, .NET

Framework, .NET Compact Framework та Microsoft Silverlight.

Visual Studio включає один або декілька з наступних компонентів:

2 Visual Basic .NET, а до його появи — Visual Basic

3 Visual C++

4 Visual C#

5 Visual J#

6 Visual F# (входить до складу Visual Studio 2010)

7 Visual Studio Debugge

8 Microsoft SQL Server

9 MSDE Visual Source Safe - файл-серверна система управління версіями

Це дасть можливість реалізувати усі компоненти web-додатку за

допомогою одного програмного пакету.

36

Для web-додатку онлайн реєстрації на прийом до лікаря в дільничну

лікарню було обрано реалізувати RESTful Web API сервіс мовою

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

Для побудови web-сайту було обрано AngularJS Framework та мову

JavaScript.

C# - об'єктно-орієнтована мова програмування з безпечною системою

типізації для платформи .NET. Розроблена Андерсом Гейлсбергом, Скотом

Вілтамутом та Пітером Гольде під егідою Microsoft Research (при фірмі

Microsoft).

Синтаксис C# близький до С++ і Java. Мова має строгу статичну

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

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

форматі XML. Перейнявши багато що від своїх попередників — мов С++,

Delphi, Модула і Smalltalk — С#, спираючись на практику їхнього

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

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

спадкування класів (на відміну від C++).

REST (Representational state transfer) - це стиль архітектури

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

Web, який, як правило, використовується для побудови web-служб. Термін

REST був введений в 2000 Роєм Філдінгом, одним з авторів HTTP-протоколу.

Системи, що підтримують REST, називаються RESTful-системами [2].

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

інформацією без використання додаткових внутрішніх прошарків. Кожна

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

таким як URL. Кожна URL, в свою чергу, має строго заданий формат.

Управління інформацією повністю ґрунтується на протоколі передачі

даних. Найбільш поширений протокол HTTP. При цьому дія над даними

задається за допомогою методів: GET (отримати), PUT (додати, замінити),

37

POST (додати, змінити, видалити), DELETE (видалити). Таким чином, дії

CRUD (Create-Read-Updtae-Delete) можуть виконуватися як з усіма 4-ма

методами, так і лише за допомогою GET і POST.

Дані передаються у форматі JSON. JSON (англ. JavaScript Object

Notation) - текстовий формат обміну даними, заснований на JavaScript і

зазвичай використовуваний саме з цією мовою. Як і багато інших текстових

форматів, JSON може бути легко прочитаний людьми. Формат JSON був

розроблений Дугласом Крокфорд.

За рахунок своєї лаконічності в порівнянні з XML, формат JSON може

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

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

самими серверами (програмні HTTP-інтерфейси).

На рисунку 2.3 зображено модель web-сервісу.

Рисунок 2.3 –Модель RESTful web-сервісу

2.9 Висновок

В даному розділі було проаналізовано принципи роботи web-додатків,

особливості розробки web-сервісів, розглянуто фреймворк Web API. Також

було проведено аналіз особливостей розробки баз даних. Були зазначені

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

JavaScripts та фреймворку AngularJS. За проведеним аналізом було

обгрунтовано вибів середовища розробки web-додатку.

38

3 РОЗРОБКА МОДЕЛЕЙ СИСТЕМИ

3.1 Розробка high-level моделі системи

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

1 база даних;

2 web-сервіс, що реалізований за принципом RESTful Web API;

3 web-сайт.

На рисунку 3.1 наведено high-level модель програмного засобу.

Рисунок 3.1 – High-level модель програмного засобу

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

через мобільні додатки з операційними системами Android, iOS або Windows.

Для роботи web-додатку необхідна база даних (DB) для зберігання

інформації про лікарню, пацієнтів, лікарів та години прийому. Також для

роботи з базою даних необхідний спеціальний модуль (Data Access Layer), за

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

Необхіно розробити web-сайт, за допомогою якого буде

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

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

39

Також необхідний модуль (WEB-Service), який буде приймати запити

від користувача та викликати певні методи DAL модуля для маніпулювання

даними в базі даних.

3.2 Розробка моделі бази даних

Однією з обов’язкових умов при розробці баз даних є її нормалізація.

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

відношення (на практиці: таблиці) відповідно до алгоритму нормалізації на

декілька відношень на базі функціональних залежностей.

Нормальна форма — властивість відношення в реляційної моделі

даних, що характеризує його з точки зору надмірності, яка потенційно може

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

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

відношення.

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

третю і так далі нормальні форми. Якщо відношення відповідає критеріям

нормальної форми n, та всім попереднім нормальним формам, тоді

вважається, що це відношення знаходиться у нормальній формі рівня n.

У роботі базу даних приведемо до третьої нормальної форми, тобто,

тоді вона відповідатиме вимогам першої та другої нормальних форм, а саме:

1 Перша нормальна форма:

1) кожна таблиця повинна мати основний ключ: мінімальний набір

колонок, які ідентифікують запис;

2) уникнення повторень груп (категорії даних, що можуть

зустрічатись різну кількість разів у різних записах), правильно

визначаючи не-ключові атрибути;

3) атомарність: кожен атрибут повинен мати лише одне значення, а

не множину значень.

2 Друга нормальна форма:

40

1) схема бази даних повинна відповідати вимогам першої

нормальної форми;

2) дані, що повторно з'являються в декількох рядках, виносяться в

окремі таблиці.

3 Третя нормальна форма:

1) схема бази даних повинна відповідати всім вимогам другої

нормальної форми;

2) будь-яке поле, що залежить від основного ключа та від будь-

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

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

як організувати ці таблиці і зв'язати їх одна з одною. Здебільшого, це

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

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

• зовнішній ключ - первинний ключ однієї таблиці знаходиться в

іншій таблиці.

На рисунку 3.2 зображено модель бази даних web-додатку.

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

модуль DAL.

DAL (Data Access Layer) - це логіка обробки даних. У ASP.NET вона

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

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

entities. У будь-якому випадку, додаток буде містити в собі логіку доступу до

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

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

Будь-який код, який здійснює обробку даних, їх вибірку, зміну,

команди SELECT, INSERT, UPDATE, і DELETE та інші, повинен

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

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

41

Ри

сун

ок 3

.2 –

мод

ель

баз

и д

ани

х w

eb-д

од

атку

42

3.3 Розробка моделі сайту

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

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

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

бути простою і зрозумілою як відвідувачу, так і пошуковій системі.

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

розташування, а також і подачі інформації, який, завдяки використанню

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

проміжок часу максимально точно передати інформацію, що подається на

сайті.

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

користувачеві. Таким чином найкращим варіантом структури є поділ її на

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

будуть взаємно пов’язані.

У процесі складання моделі визначається [18]:

– які розділи є найбільш важливими, а які другорядними;

– які розділи варто включати в навігаційне меню;

– авторитетність яких сторінок потрібно підвищувати внутрішніми

посиланнями;

– під які запити з семантичного ядра не вистачає сторінок на сайті і

необхідність їх створювання.

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

ланцюг – елемент навігації по веб-сайту, що представляє собою шлях по

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

користувач. Всі елементи, крім останнього, зазвичай є внутрішніми

гіперпосиланнями.

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

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

самому документі, на інший об'єкт (файл, каталог, додаток), розташований на

43

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

При натисканні на гіперпосилання вказаний у ній об'єкт відображається у

браузері.

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

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

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

інформаційний простір сайту.

Модель поділяється на логічну та фізичну. Логічною моделлю

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

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

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

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

забезпечення. На основі логічної структури виконується розробка фізичної

структури.

На рисунку 3.3 зображена логічна модель сторінок сайту.

Рисунок 3.3 – Логічна модель сайту

44

index.html – головна та єдина сторінка сайту для онлайн реєстрації

пацієнтів на прийом. На даній сторінці міститься вся необхідна інформація,

яка розділена на такі секції, як «Головна», «Зареєструватися» та «Відмінити

реєстрацію».

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

лікаря у дільничну лікарню. На рисуну 3.4 зображено блок-схему алгоритму.

Рисунок 3.4 – Блок-схема алгоритму запису на прийом

45

Продовження рисунку 3.4 – Блок-схема алгоритму запису на прийом

46

Продовження рисунку 3.4 – Блок-схема алгоритму запису на прийом

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

сторінок запису та відміни запису на прийом. На рисунках 3.5-3.7 зображено

схеми сторінок.

47

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

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

Складові структури сайту, які не були описані в логічній структурі наступні:

1) Каталог css:

– файл style.css містить таблицю каскадних стилів, яка

підключається до головного html-файлу, вона задає стиль

одночасно для всього сайту;

– bootstrap.min.css– файл з набором інструменів bootstrap.

2) Каталог img – містить необхідні зображення для сайту.

3) Каталог js:

– bootstrap.min.js – файл із описаними сценаріями JavaScript для

інструменів bootstrap.

– файл scripts.js містять java-скріпти для підтимання динаміки

сайту.

Рисунок 3.5 – Схема головної сторінки

48

Рисунок 3.6 – Схема сторінки запису на прийом

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

3.4 Висновок

У даному розділі було розроблено high-level модель системи, модель

бази даних, модель сайту, описано алгоритм роботи розробленої програми,

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

операції програми. Розроблено модель програмного продукту.

49

4 РОЗРОБКА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ СИСТЕМИ

4.1 Розробка web-сервісу

4.1.1 Розробка шаблону маршрутизації

Відповідно до наведених вище етапів розробки RESTful Web API

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

На рисунку 4.1 наведено розроблений шаблон маршрутизації:

Рисунок 4.1 – Шаблон маршрутизації для сервісу

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

Нижче наведено приклад коду функції GetDoctorsReceptionDates з

контролеру Clinic.

[HttpGet] public List<DateTime> GetDoctorsReceptionDates(int specializationId, int doctorId, int clinicId) { List<DateTime> dates = dal.SelectDoctorsReceptionDates(specializationId, doctorId, clinicId); List<DateTime> nextDates = new List<DateTime>(); foreach(DateTime date in dates)

50

{ if(date >= DateTime.Now) { nextDates.Add(date); } } nextDates.Sort(); return nextDates;}

Рисунок 4.2 – Наявні контролери на сервісі

4.1.2 Розробка RESTful протоколу з адресами доступу до функцій

web-сервісу

Для того, щоб надати можливість користуватися розробленим web-

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

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

вихідних параметрів та з описом їх призначення [19].

На рисунку 4.3 зображено приклад розробленого протоколу.

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

дізнатися, звернувшись безпосередньо до сторінки сервісу Help [20]. Ця

можливість реалізована за допомогою XML Documentation Comments, які

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

/// <summary>Request for reception dates of selected specialization and doctor in clinic.</summary> /// <param name="specializationId">specializationId</param> /// <param name="doctorId">doctorId</param> /// <param name="clinicId">clinicId</param> /// <returns>Returns a list of doctor's reception dates.</returns>

На рисунку 4.4 наведено приклад вигляду сторінки Help.

51

Ри

сун

ок 4

.3 –

Пр

ото

ко

л R

ES

Tfu

l w

eb-с

ервіс

у

52

Рисунок 4.4 – Вигляд сторінки Help

4.2 Розробка бази даних

На основі розробленої структури бази даних було написано скрипт

створення бази даних. Щоб часто при виконанні складних операцій не

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

для бази даних web-ресурсу. Процедури дозволяють об'єднати послідовність

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

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

виконання збереженої процедури. Тригери застосовуються для забезпечення

53

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

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

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

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

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

відбутися відкат цієї транзакції. Частина коду скриптів наведено нижче:

-- Creating table 'Clinics' CREATE TABLE [dbo].[Clinics] ( [ClinicId] int IDENTITY(1,1) NOT NULL, [Address] nvarchar(max) NOT NULL, [Name] nvarchar(max) NOT NULL, [Phone] nvarchar(max) NOT NULL ); GO -- Creating table 'Streets' CREATE TABLE [dbo].[Streets] ( [StreetId] int IDENTITY(1,1) NOT NULL, [Name] nvarchar(max) NOT NULL, [CitiesCityId] int NOT NULL ); GO -- Creating table 'Homes' CREATE TABLE [dbo].[Homes] ( [HomeId] int IDENTITY(1,1) NOT NULL, [HomeNumber] nvarchar(max) NOT NULL, [StreetsStreetId] int NOT NULL, [AreasAreaId] int NOT NULL ); GO -- Creating table 'Specializations' CREATE TABLE [dbo].[Specializations] ( [SpecializationId] int IDENTITY(1,1) NOT NULL, [Name] nvarchar(max) NOT NULL, [IsDistrict] bit NOT NULL ); GO CREATE PROCEDURE ADDUser (@Login varchar(32), @Password varchar(32), @Mail varchar(32), @UserName nvarchar(32) ) AS DECLARE @CountRows int SELECT @CountRows =COUNT(*) FROM Users WHERE [Login] = @Login AND Email = @Mail IF @CountRows = 0 INSERT INTO Users ([Login], [Password], Email, UserName) VALUES (@Login, @Password, @Mail, @UserName);

54

4.3 Розробка модуля Data Access Layer

Для роботи з базою даних було розроблено спеціальний Data Access

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

даними в базі даних.

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

Entity Framework.

Entity Framework (EF) - це об'єктно-реляційний модуль зіставлення, що

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

об'єктів, спеціалізованих для доменів. Це усуває необхідність у написання

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

розробникам.

EF надає можливість взаємодії з об'єктами як за допомогою LINQ у

вигляді LINQ to Entities, так і з використанням Entity SQL.

Нижче наведено один з методів для маніпулювання даними в базі

даних.

public bool BookingReception(int specializationId, int doctorId, int clinicId, DateTime date, TimeSpan time, bool isSelected) { int clinicSpecializationDoctorId = context.ClinicSpecializationDoctors.Where(csd => csd.SpecializationsSpecializationId == specializationId && csd.DoctorsDoctorId == doctorId && csd.ClinicsClinicId == clinicId).Select(csd => csd.ClinicSpecializationDoctorId).FirstOrDefault(); Reception reception = (from r in context.Receptions where r.ClinicSpecializationDoctorsClinicSpecializationDoctorId == clinicSpecializationDoctorId && r.Date == date && r.Time == time select r).Single<Reception>(); bool isSuccess; if (reception.IsSelected != isSelected) { reception.IsSelected = isSelected; context.SaveChanges(); isSuccess = true; } else {

55

isSuccess = false; } return isSuccess; }

4.4 Розробка сайту

Платформа ASP.NET MVC базується на взаємодії трьох компонентів:

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

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

користувачеві результат обробки запиту.

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

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

відображення інформації.

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

використовується движок представлення. До версії MVC 5

використовувалися два движка:

Web Forms і Razor. Починаючи з MVC 5 єдиним двигуном, вбудованим

за замовчуванням, є Razor. Движок WebForms використовує файли .aspx, а

Razor - файли .cshtml і .vbhtml для зберігання коду представлення. Основою

синтаксису Razor є знак @, після якого здійснюється перехід до коду на

мовах C # / VB.NET. Також можливо і використання сторонніх движків.

Файли представлення не є стандартними статичними сторінками з кодом

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

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

При обробці запитів фреймворк ASP.NET MVC спирається на систему

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

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

запит. Вбудований маршрут за умовчанням передбачає триланкову

структуру: контролер / дія / параметр.

56

Сайт web-додатку онлайн реєстрації на прийом було розроблено з

використанням фреймворку AngularJS. Нижче наведено приклад коду

створення web-сайту з використанням фрейморку AngularJS.

<script src="Scripts/angular.js"></script> <body ng-controller="MainCtrl"> <div> <nav class="navbar-fixed-top" style="background-color:rgba(69, 69, 69, 0.47); height:60px; box-shadow: 0 0 10px rgba(0,0,0,0.5);"> <div class="container" > <a id="Logo" style="text-decoration:none; cursor:pointer;"><p style="color:#fff; font-size:35px; font-family:Andalus;">AntiQueue</p></a> </div> </nav> <!-- Header --> <div id="header" style="min-height: 100vh; height: auto !important; height: 100%; margin: 0 0 0px; background-image:url(images/medicine2.jpg); background-size:cover; background-position:top;

">

<div ng-show="showRegistrationInfo"> <div class="panel-heading" style="font-size:20px; font-family:Arial; min-width:500px; width:100%; height:60px; color:black; text-align:center;">Ви успішно зареєстувались <br /> Ваші реєстраційний квиток</div> <div class="panel-body" style="min-width:500px; width:60%; margin-left:20%;min-height: 50vh;min-width:500px; "> <div class="form-group"> <p>Реєстраційний номер: {{ReceptionRegistrationId}}</p> <p>Ім'я: {{PatientName}}</p> <p>Прізвище: {{PatientSurname}}</p> <p>Дата прийому: {{ReceptiomDate}}</p> <p>Час прийому: {{ReceptiomTime}}</p>

</div>

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

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

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

сіток, навігації тощо, а також додаткові розширення JavaScript.

57

Bootstrap використовує найсучасніші напрацювання в галузі CSS [21] і

HTML.

Основні переваги Twitter Bootstrap 3:

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

шаблони дизайну і класи Bootstrap і сконцентрованість на інших

розробках;

– висока швидкість – з використанням Bootstrap легко створювати

динамічні макети. Макети Bootstrap легко масштабуються на

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

– гармонійний дизайн – всі компоненти платформи Bootstrap

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

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

сторінок узгоджуються один з одним;

– простота у використанні – платформа дуже проста у

використанні. Тому будь-який користувач з базовими знаннями

HTML і CSS може почати розробку з Twitter Bootstrap;

– сумісність з браузерами – Twitter Bootstrap сумісний з усіма

сучасними браузерами, такими як Mozilla Firefox, Google Chrome,

Safari, Internet Explorer і Opera;

– відкрите програмне забезпечення – найкраща особливість Twitter

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

відкритості вихідних кодів і безкоштовного завантаження.

Основні інструменти Bootstrap:

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

використовувати, наприклад ширина колонки 140px відноситься

до класу .span2, який можна використовувати в CSS описі

документа.

– шаблони – фіксований або гумовий шаблон документа.

58

– типографіка – описи шрифтів, визначення деяких класів для

шрифтів, таких як код, цитати і т. ін.

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

– таблиці – засоби оформлення таблиць, навіть додавання

функціональності сортування.

– форми – класи для оформлення не тільки форм, а й деяких подій,

що відбуваються з ними.

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

меню і панелі інструментів.

Сайт розроблений за шаблоном onepage, тобто створений у вигляді

однієї сторінки. Сторінка розділена на секції, навігація до яких здійснюється

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

[22].

Секції сайту зображено на рисунках 4.5 – 4.7.

Рисунок 4.5 – Головна сторінка

59

Рисунок 4.6 – Сторінка запису на прийом

Рисунок 4.7 – Сторінка відміни запису на прийом

4.5 Висновок

У даному розділі було розроблено web-сервіс, базу даних, DAL модуль,

та виконано розробку сайту.

60

5 ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ СИСТЕМИ

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

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

впровадженням у використання. Тестування програмного продукту є одним

із основних методів забезпечення надійності web-додатку.

Тестування програмного коду [23] – процес виконання програмного

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

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

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

відповідає вимогам. Несподівана поведінка системи може призводити до

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

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

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

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

Мета застосування процедури тестування програмного коду –

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

Тестування само по собі не може гарантувати повну відсутність дефектів у

програмному коді системи. Однак, в поєднанні з процесами верифікації та

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

документації, грамотно організоване тестування дає гарантію того, що

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

передбачених ситуаціях.

5.1 Тестування web-сервісу

Для тестування web-сервісу [24] можна використати будь-який браузер.

Для початку за допомогою браузера протестуємо HTTP GET запит. Для цього

потрібно до основної адреси сервісу додати URI контролеру та методу з

параметрами. На рисунку 5.1 зображенно тест web-сервісу на GET запит.

61

Рисунок 5.1 – Тестування GET методів web-сервісу

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

додаток Fidller4. На рисунках 5.2, 5.3 зображено тест web-сервісу на POST

запит за допомогою програмного додатку Fidller4.

Рисунок 5.2 – Формування POST запиту

Рисунок 5.3 – Результат виконання POST запиту

62

5.2 Тестування бази даних

Тестування БД поділяється на наступні види:

• Тестування логічної моделі:

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

інформації, що повторюється;

- пошук можливостей для спрощення логічної моделі.

• Тестування логічної схеми бази даних:

- тестування на відповідність нормальним формам;

- тестування на узгодженість бази;

- тестування для виявлення даних, що перебувають в надлишку.

• Тестування фізичної структури бази даних:

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

- аналіз системи зберігання даних (табличні області (Oracle, DB2),

масивів даних і груп файлів (MS SQL));

- аналіз політики безпеки та розробка пропозицій щодо її

поліпшення;

- аналіз та реалізація розподілу бази даних;

- аналіз та реалізація стратегії реплікації;

- аналіз та реалізація стратегії резервного копіювання.

• Тестування бази даних на можливість програмування:

- аналіз ефективності процедур і тригерів;

- оптимізація запитів;

- аналіз ефективності клієнтського додатку.

Для того, щоб ефективно проводити тестування БД, розробляється план

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

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

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

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

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

63

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

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

пришвидшити сам процес генерації даних для тестування.

Для тестування БД напишемо тестові запити мовою MS SQL і

виконаємо їх в середовищі VisualStudio2013. Приклади тесту зображено на

рисунках 5.4 – 5.6.

Рисунок 5.4 – Тестування БД

Рисунок 5.5 – Формування запитів через DAL

64

Рисунок 5.6 – Результат виконання запитів через DAL

5.3 Тестування web-сайту

Тестування, як завершальний етап розробки web-сайту, відіграє дуже

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

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

Залежно від специфіки проекту, на тестування може виділятися до 50%

часових ресурсів.

Зазвичай, тестування сайту проходить за такими пунктами:

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

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

подальшого тестування;

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

суть процесу якого полягає у перевірці всього описаного функціоналу:

перевірці роботи всіх обов'язкових функцій сайту, тестуванні

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

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

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

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

очікуваному вихідному контенту;

тестування верстки – при перевірці верстки в першу чергу перевіряється

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

65

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

перевірка валідності коду;

тестування usability – проводиться для оцінки зручності продукту у

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

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

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

доступу до службових або закритих сторінок;

тестування продуктивності сайту – проводиться з метою визначення

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

Під час роботи над сайтом розробник має вважати на багато чинників,

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

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

моніторі, його роздільна здатність, доступність JavaScript тощо [25].

Після закінчення верстання слід провести ряд перевірок і у разі

виявлення явних помилок, внести в код відповідні зміни. Зрозуміло, це

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

Відлагодження - це процес знаходження помилок в коді і виправлення

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

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

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

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

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

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

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

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

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

як чужа.

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

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

66

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

провести над ним експерименти.

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

відвідувачів. Адже перша думка про сайт складається при перегляді

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

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

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

покинути сайт. Пізніше, вони будуть просто ігнорувати цей сайт.

Тестування розробленого сайту для онлайн реєстрації пацієнтів на

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

При функціональному тестуванні було перевірено всі функції сайту, а

саме: перехід до секції через головне меню та через функцію скролу вниз;

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

перехід за гіперпосиланнями.

При проведеному функціональному тестуванні та при тестуванні сайту

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

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

Отже, тестування сайту показало, що сайт відповідає всім вимогам,

працює без помилок.

Кросбраузерність - це властивість певного сайту практично однаково

відображатися і працювати в браузерах. Сайт має відображати матеріал з

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

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

найпопулярніших браузерах Opera, Google Chrome і Internet Explorer. На

рисунках 5.7-5.8 зображено роботу сайту у браузерах Google Chrome та

Internet Explorer.

67

Рисунок 5.7 – Тестування web-сайту у Google Chrome

Рисунок 5.8 – Тестування web-сайту у Internet Explorer

5.4 Висновок

У п’ятому розділі було здійснено тестування розробленого web-

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

тестування web-сервісу та сайту. Тестування підтвердило ефективність та

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

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

інтерфейс. Програма дозволяє заощаджувати час користувача за рахунок

мінімального введення даних.

68

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

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

Перш за все, для оцінювання комерційного потенціалу розробки web-

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

фахівців. Для цього залучаємо 3-х незалежних експертів (Е1, Е2 та Е3), яким

пропонується оцінити комерційну розробку за 12-ма критеріями за 5-ти

бальною шкалою. Критерії оцінювання та їх можлива бальна оцінка наведені

у табл. 6.1 [26].

Таблиця 6.1 — Рекомендовані критерії оцінювання комерційного потенціалу

розробки та їх можлива бальна оцінка

Критерії оцінювання та бали (за 5-ти бальною шкалою)

Кри-

терій 0 1 2 3 4

Технічна здійсненність концепції:

1

Достовірність

концепції не

підтверджена

Концепція

підтверджена

експертними

висновками

Концепція

підтверджена

розрахунками

Концепція

перевірена на

практиці

Перевірено

роботоздатність

продукту в

реальних умовах

Ринкові переваги (недоліки):

2

Багато

аналогів на

малому ринку

Мало

аналогів на

малому ринку

Кілька

аналогів на

великому

ринку

Один аналог

на великому

ринку

Продукт не має

аналогів на

великому ринку

3

Ціна продукту

значно вища

за ціни

аналогів

Ціна

продукту

дещо вища за

ціни аналогів

Ціна продукту

приблизно

дорівнює

цінам

аналогів

Ціна

продукту

дещо нижче

за ціни

аналогів

Ціна продукту

значно нижче за

ціни

аналогів

4

Технічні та

споживчі

властивості

продукту

значно гірші,

ніж в аналогів

Технічні та

споживчі

властивості

продукту

трохи гірші,

ніж в аналогів

Технічні та

споживчі

властивості

продукту на

рівні аналогів

Технічні та

споживчі

властивості

продукту

трохи кращі,

ніж в аналогів

Технічні та

споживчі

властивості

продукту значно

кращі, ніж в

аналогів

5

Експлуатацій

ні витрати

значно вищі,

ніж в аналогів

Експлуатацій

ні витрати

дещо вищі,

ніж в аналогів

Експлуатацій

ні витрати на

рівні

експлуатаційн

их витрат

аналогів

Експлуатацій

ні витрати

трохи нижчі,

ніж в аналогів

Експлуатаційні

витрати значно

нижчі, ніж в

аналогів

69

Продовження таблиці 6.1 — Рекомендовані критерії оцінювання

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

Ринкові перспективи

6 Ринок малий і

не має

позитивної

динаміки

Ринок малий,

але має

позитивну

динаміку

Середній

ринок з

позитивною

динамікою

Великий

стабільний

ринок

Великий ринок з

позитивною

динамікою

7 Активна

конкуренція

компаній

Активна

конкуренція

Помірна

конкуренція

Незначна

конкуренція

Конкурентів

немає

Практична здійсненність

8 Відсутні

фахівці як з

технічної, так

і з

комерційної

реалізації ідеї

Необхідно

наймати

фахівців або

витрачати

значні кошти

та час на

навчання

наявних

фахівців

Необхідне

незначне

навчання

фахівців та

збільшення їх

штату

Необхідне

незначне

навчання

фахівців

Є фахівці з питань

як з технічної, так

і з

комерційної

реалізації ідеї

9 Потрібні

значні

фінансові

ресурси, які

відсутні.

Джерела

фінансування

ідеї відсутні

Потрібні

незначні

фінансові

ресурси.

Джерела

фінансування

відсутні

Потрібні

значні

фінансові

ресурси.

Джерела

фінансування

є

Потрібні

незначні

фінансові

ресурси.

Джерела

фінансування

є

Не потребує

додаткового

фінансування

10 Необхідна

розробка

нових

матеріалів

Потрібні

матеріали, що

використовую

ться у

військово-

промисловом

у

комплексі

Потрібні

дорогі

матеріали

Потрібні

досяжні та

дешеві

матеріали

Всі матеріали для

реалізації ідеї

відомі

та давно

використовуються

у виробництві

11 Термін

реалізації ідеї

більший

за 10 років

Термін

реалізації ідеї

більший

за 5 років.

Термін

окупності

інвестицій

більше

10-ти років

Термін

реалізації ідеї

від 3-х до 5-ти

років.

Термін

окупності

інвестицій

більше

5-ти років

Термін

реалізації ідеї

менше

3-х років.

Термін

окупності

інвестицій від

3-х до

5-ти років

Термін реалізації

ідеї

менше

3-х років.

Термін окупності

інвестицій менше

3-х років

70

Продовження таблиці 6.1 — Рекомендовані критерії оцінювання

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

12 Необхідна

розробка

регламентних

документів та

отримання

великої

кількості

дозвільних

документів на

виробництво

та реалізацію

продукту

Необхідно

отримання

великої

кількості

дозвільних

документів на

виробництво

та реалізацію

продукту, що

вимагає

значних

коштів та

часу

Процедура

отримання

дозвільних

документів

для

виробництва

та реалізації

продукту

вимагає

незначних

коштів та

часу

Необхідно

тільки пові-

домлення

відповідним

органам про

виробництво

та реалізацію

продукту

Відсутні будь-які

регламентні

обмеження на

виробництво та

реалізацію

продукту

Результати оцінювання комерційного потенціалу розробки web-додатку

зводимо у таблицю 6.2.

Таблиця 6.2 — Результати оцінювання комерційного потенціалу розробки

Критерії Експерти

Войтко В.В. Майданюк В.П. Катєльников Д.І.

Бали, виставлені експертами:

1 2 1 3

2 2 2 3

3 3 4 3

4 3 2 4

5 2 3 3

6 3 2 2

7 2 3 3

8 3 3 4

9 2 1 2

10 4 4 3

11 4 2 3

12 2 2 3

Сума балів 32 29 36

Середньоарифметична

сума балів СБ 32,5

Як показують результати аналізу таблиці 6.2, рівень комерційного

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

сума балів (СБ) знаходиться в межах від 31 до 40.

71

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

6.2.1 Розрахунок витрат, які безпосередньо стосуються виконавців

даного розділу роботи.

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

працюють в сфері ІТ розробки за формулою 6.1 [27].

Зо =М

Тр х 𝑡 (грн.), (6.1)

де М - місячний посадовий оклад розробника, гри.;

Тр - число робочих днів в місяці,Тр= 21;

t - число днів роботи розробника.

В розробці програмного продукту бере участь один програміст.

Програма розроблялась 42 робочий день. Оклад програміста складає 5000

грн., а керівника — 8000 грн. Отже, основна заробітна плата програміста та

керівника роботи за весь період роботи відповідно дорівнює:

Зо =5000

21∗ 42 = 10000 (грн. )

Зо =8000

21 х 21 = 8000 (грн. )

Зроблені розрахунки зведемо до таблиці 6.3.

Таблиця 6.3 — Основна заробітна плата програміста та керівника за весь

період роботи.

Найменування

посади

Місячний

посадовий

оклад, грн.

Оплата за

робочий день,

грн.

Число

днів

роботи

Витрати на

заробітну

плату, грн.

Інженер-програміст 5000 238 42 10000

Керівник 8000 380 21 8000

Всього 18000

Додаткова заробітна плата Зд всіх розробників складає 10%...12% від

основної (формула 6.2):

72

Зд = (0,1 … 0,12) × Зо (6.2)

Зд = 0,12 × 18000 = 2160 (грн)

Нарахування на заробітну плату Нзп розробників, які брали участь у

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

Нзп = (Зо + Зд) ×𝛽

100 (6.3)

де Зо – основна заробітна плата розробників, грн.;

Зд — додаткова заробітна плата всіх розробників та робітників, грн.;

𝛽 — ставка єдиного внеску на загальнообов’язкове державне соціальне

страхування, %. Cтавка єдиного внеску на загальнообов’язкове державне

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

Нзп = (18000 + 2160) ×36,3

100= 7318 (грн)

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

виконання даного етапу роботи.

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

обладнання можна розрахувати за формулою 6.4.

А =Ц×На

100×

Т

12, грн (6.4)

де Ц – балансова вартість обладнання, приміщень, грн;

На – річна норма амортизаційних відрахувань, %;

Т – термін використання обладнання, приміщень, міс.

Всі розрахунки зведемо до таблиці 6.4:

Таблиця 6.4 – Амортизаційні відрахування

Найменув.

обладнання

Балансова

вартість,

грн.

Норма

амортиза

ції %

Термін

використання

обладнання, міс.

Величина

амортизаційних

відрахувань, грн.

Компютер на

базі athlon-64 4000 25 2 167

Приміщення 7000 14 2 163

Всього 330

73

Розрахуємо витрати на матеріали [28]. Відзначимо, що при створенні

програмного продукту були також і витрати на матеріали (М). До таких витрат

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

заправка картриджів принтеру тощо. В таблиці 6.5 наведено інформацію про

використані матеріали.

Таблиця 6.5 — Витрати на використані комплектуючі

№ Найменування Ціна, Скільки Вартість витрачених

комплектуючого грн. витрачено, шт. комплектуючих,

грн.

1 Компакт диск 5 7 35

2 Заправка

картриджа 50 2

100

3 Ручка 4 1 4

4 Папір 65 1 65

Всього 204

З урахуванням транспортних витрат:

М = 204 × 1,1 = 224 грн.

Витрати на силову електроенергію розраховується за формулою 6.5

Ве = В × П × Ф × Кп (6.5)

де В − вартість 1кВт-години електроенергії, В=1,35 грн/кВт-год;

П − установлена потужність обладнання, кВт, 0,5 кВт;

Ф − фактична кількість годин роботи обладнання, 504 години;

Кп − коефіцієнт використання потужності, 0,7.

Ве = 1,35 × 0,5 × 504 × 0,7 = 238,14 (грн)

Інші витрати доцільно приймати як 200%...300% від суми основної

заробітної плати розробників, що виготовили новий пристрій:

Ів = 18000 × 2 = 36000 (грн).

Сума всіх попередніх статей витрат дає витрати на виконання даної

частини роботи (формула 6.6).

В = Зо + Зд + Нзп + А + М + Ве + Ів, грн (6.6)

74

В = 18000 + 2160 + 7318 + 330 + 224 + 238,14 + 36000 = 64270,14 (грн)

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

роботи складе 64270,14 грн.

6.2.2 Розрахунок загальних витрат на виконання даної роботи Взаг.

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

буде продовжена, то Взаг = В = 64270,14 грн.

6.2.3 Прогнозування загальних витрат на виконання та

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

Прогнозування загальних витрат на виконання та впровадження

результатів виконаної наукової роботи здійснюється за формулою 6.7 [29].

ЗВ =Взаг

𝛽, (6.7)

де 𝛽 – коефіцієнт, який характеризує етап (стадію) виконання даної

роботи. Оскільки наша робота знаходиться на стадії впровадження, то 𝛽 =

0,9.

ЗВ =64270,14

0,9= 71411,3 (грн)

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

розробки

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

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

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

протягом 3-х років після її впровадження. Одним із основних позитивних

результатів є зростання величини прибутку.

При реалізації результатів наукової розробки покращується якість

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

200 грн. Кількість користувачів програмного засобу також збільшиться:

75

протягом першого року — на 1000 чол., протягом другого року — ще на 500

чол., протягом третього року — ще на 300 чол.

Реалізація продукції до впровадження результатів наукової розробки

складала 0 шт., а ціна — 504 грн.

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

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

базового за формулою 6.8.

іП )100

1()NЦNЦ( іоо

n

1

, (6.8)

де Цо – покращення основного оціночного показника від

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

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

N – основний кількісний показник, який визначає діяльність

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

N – покращення основного кількісного показника діяльності

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

Цо – основний оціночний показник, який визначає діяльність

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

розробки;

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

результатів від впровадження розробки;

– коефіцієнт, який враховує сплату податку на додану вартість.

Ставка податку на додану вартість дорівнює 20%, а коефіцієнт 8333,0 .

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

Рекомендується приймати = 0,2...0,3;

– ставка податку на прибуток, = 18%,

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

року складе:

∆П1 = [200 × 0 + (504 + 200) × 1000] × 0,8333 × 0,2 × (1 −18

100) = 96209,5 грн

76

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

(відносно базового року, тобто року до впровадження результатів наукової

розробки) складе:

∆П2 = [200 × 0 + (504 + 200) × (1000 + 500)] × 0,8333 × 0,2 × (1 −18

100)

= 144314,2 грн

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

(відносно базового року, тобто року до впровадження результатів наукової

розробки) складе:

∆П2 = [200 × 0 + (504 + 200) × (100 + 500 + 300)] × 0,8333 × 0,2

× (1 −18

100) = 173177 грн

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

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

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

окупності

Загальні витрати ЗВ на виконання та впровадження результатів

наукової роботи (або теперішня вартість інвестицій PV) [30] дорівнює

71411,3 грн.

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

виявлятися через два роки.

Ці результати виявляться у тому, що у першому році підприємство

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

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

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

(відносно базового року). На рисунку 6.1 зображено вісь часу з фіксацією

платежів.

77

Рисунок 6.1 – Вісь часу з фіксацією платежів

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

користуються формулою 6.9 [31].

Еабс = (ПП – PV), (6.9)

де ПП – приведена вартість всіх чистих прибутків, що їх отримає

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

PV – теперішня вартість інвестицій PV = ЗВ, грн.

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

розраховується за формулою 6.10.

т

1t

і

)1(

ППП , (6.10)

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

яких виявляються результати виконаної та впровадженої НДДКР, грн;

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

НДДКР, роки;

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

рівень інфляції в країні; для України цей показник знаходиться на рівні 0,1;

t – період часу (в роках) від моменту отримання чистого прибутку до

точки „0”.

78

Якщо Еабс < 0, то результат від проведення наукових досліджень та їх

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

досліджень ніхто не буде.

Якщо Еабс > 0, то результат від проведення наукових досліджень та їх

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

інвестор буде зацікавлений у фінансуванні даного проекту (роботи).

Користуючись формулою 6.10, розрахуємо приведену вартість усіх

чистих прибутків:

ПП =71411,3

(1 + 0,1)0+

96209,5

(1 + 0,1)2+

144314,2

(1 + 0,1)3+

173177

(1 + 0,1)4= 377630,8 грн

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

вкладених інвестицій:

Еабс = 377630,8 − 71411,3 = 306219,5 грн

Оскільки Еабс > 0, то вкладання коштів на виконання та впровадження

результатів НДДКР є доцільним.

Розрахуємо відносну (щорічну) ефективність вкладених в наукову

розробку інвестицій Ев. Для цього скористаємося формулою 6.11.

1PV

Е1Е жТ абс

в , (6.11)

де Еабс – абсолютна ефективність вкладених інвестицій, грн;

PV –теперішня вартість інвестицій PV = ЗВ, грн;

Тж – життєвий цикл наукової розробки, роки.

Ев = √1 +306219,5

71411,3

3

− 1 = 0,7422 або 74,22%

Розраховану величину Ев порівняємо з мінімальною (бар'єрною)

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

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

(бар'єрна) ставка дисконтування мін визначається за формулою 6.12.

d + f, (6.12)

79

де d – середньозважена ставка за депозитними операціями в

комерційних банках; d = (0,14...0,2);

f – показник, що характеризує ризикованість вкладень; зазвичай,

величина f = (0,05...0,1).

Якщо величина Ев > мін, то інвестор може бути зацікавлений у

фінансуванні даної наукової розробки. В іншому випадку фінансування

наукової розробки здійснюватися не буде.

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

𝜏 = 0,15 + 0,1 = 0,25

Оскільки Ев = 74,22 % > мін = 0,25 = 25 %, то у інвестора буде

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

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

депозит у комерційний банк.

Термін окупності вкладених у реалізацію наукового проекту інвестицій

Ток можна розрахувати за формулою 6.13.

в

окЕ

1Т . (6.13)

Якщо Ток < 3…5-ти років, то фінансування даної наукової розробки в

принципі є доцільним.

Ток =1

0,7422= 1,35 роки

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

Ток < 5 років.

6.5 Висновок

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

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

підтверджують такі показники як:

80

абсолютна ефективність вкладених інвестицій, яка рівна 306219,5

грн., що є більшим 0 і вказує на те, що інвестор може бути зацікавленим у

розробці;

відносна ефективність наукової розробки становить 74,22%, що є

вищим за мінімальну ставку дисконтування (25%), тому вкласти кошти у

розробку web-додатку є вигідніше, ніж покласти кошти на депозит;

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

інвестицій складе 1,35 років, що є менше 5-ти і вказує на швидку окупність

вкладених інвестицій.

Крім того, розраховано, що наукова розробка приноситиме

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

покращення її якості порівняно з існуючими аналогами.

81

ВИСНОВКИ

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

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

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

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

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

існуючих аналогів. Проведено варіантний аналіз і систематизацію сучасних

принципів створення та засобів реалізації web-додатків. Розроблено моделі

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

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

Для реалізації web–додатку було обрано мови програмування С#, SQL,

JavaScript, було використано фреймворки Web API, AngularJS та середовище

програмування – Microsoft Visual Studio 2013. Було створено high-level

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

модуль для маніпулювання даними в базі даних, розроблено web-сервіс,

модель сайту та сам web-сайт. Проведене тестування підтвердило

ефективність і правильність функціонування розробленого web–додатку.

Зроблено прогнозування витрат на виконання роботи та прогнозування

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

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

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

ІТ-ринку.

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

опубліковані в 9 наукових працях, з них 1 входить до переліку ВАК України

[3], 1 стаття у результатах міжнародної наукової конференції [4] та 2

свідоцтва на авторське право [5, 6].

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

ідей, який був організований Фондом Віктора Пінчука. Робота здобула ІІ

місце та отримала підтримку Фонду в реалізації та впровадженні проекту.

82

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

1. Веб-служба. [Електронний ресурс]. – Режим доступу:

https://ru.wikipedia.org/wiki/Веб-служба.

2. An Introduction To RESTful Services With WCF. [Електронний ресурс]. –

Режим доступу: https://msdn.microsoft.com/en-us/magazine/dd315413.aspx

3. Білоконна К. В. Принципи реалізації навчальних ігрових програм // К. В.

Білоконна, С. М. Бурбело, С. А. Яремко. – Вісник Хмельницького

національного університету. Технічні науки. – Хмельницький 2013. – № 6. –

С. 218-223.

4. Bilokonna K.V. Market of video cards // K.V. Bilokonna, S.A. Romanyuk, O.A.

Sivets. – Materiały IX międzynarodowej naukowi-praktycznej konferencji

«Dynamika naukowych badań – 2013» 07-15 lipca 2013 roku Volume 12. –

Przemyśl Nauka i studia 2013. – С. 53-56.

5. Білоконна К.В., Войтко В.В., Бевз С.В. Комп'ютерна програма "Комп’ютерна

програма динамічної ідентифікації елементів керування шляхом моніторингу

процесів візуалізації результатів роботи" // Свідоцтво про реєстрацію

авторського права на твір № 54949, від 23.05.2014.- 2014.- Свідоцтва про

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

6. Білоконна К.В., Зінчук В.С., Войтко В.В. Компютерна програма

“Програмний модуль розпізнавання тексту із зображення” // Свідоцтво про

реєстрацію авторського права на твір №5998, від 05.01.2015.-2015.-

Свідоцтво про державну реєстрацію авторського права на твір.

7. Білоконна К.В. Новітні технології розробки web-додатків // В. В. Войтко, К.

В. Білоконна. – Збірник матеріалів Міжнародної науково-практичної

Інтернет-конференції «Інноваційні та інформаційні технології в бізнесі та

освіті» – Вінниця 2015;

8. Белоконная К.В. Рынок мобильных гаджетов // К. В. Белоконная, А.Н.

Романюк, О.А. Сивец. – Збірник матеріалів Всеукраїнської науково-

практичної Інтернет-конференції 2013 року «Електронні інформаційні

83

ресурси в освіті і науці: створення, використання, доступ» – Вінниця 2013. –

С. 14-16.

9. Білоконна К.В. Принципи реалізації ігрових програм // К. В. Білоконна –

Електронне наукове видання матеріалів конференції «XLII Регіональна

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

співробітників та студентів університету з участю працівників науково-

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

Вінниці та області» – conf.vntu.edu.ua/alvntu/2013/initki/txt/bilokonna.pdf.

10. Білоконна К.В. Активізація навчального процесу з використанням концепції

GBL // C.В. Бевз, В.В. Войтко, С.М. Бурбело, К.В. Білоконна - Міжнародний

науково-технічний журнал «Вимірювальна та обчислювальна техніка в

технологічних процесах» – Хмельницький 2014. – № 4. – С. 236-240.

11. Білоконна К.В. Технологія навчального процесу з використанням концепції

GBL // Бевз С.В., Войтко В.В., Бурбело С.М., Білоконна К.В. - Збірник

матеріалів Міжнародної науково-практичної Інтернет-конференції

«Електронні інформаційні ресурси: створення, використання, доступ» –

Вінниця 2014. – С. 54-62.

12. Портал «Дніпромед». [Електронний ресурс]. – Режим доступу:

http://dnipromed.com/

13. Портал «Поліклініка» [Електронний ресурс]. – Режим доступу:

https://clinica2.munis.com.ua/

14. Портал «Doc.ua». [Електронний ресурс]. – Режим доступу: https://doc.ua/

15. Аналіз та обґрунтування вибору засобів реалізації інформаційних веб-сайтів .

[ електронний ресурс] / М. С. Федорова. – Режим доступу до статті:

http://conf.vstu.vinnica.ua/allvntu/2012/initki/pz.php.

16. XML. [Електронний ресурс]. – Режим доступу: https://ru.wikipedia.org/wiki/XML

17. Microsoft Visual Studio.[Електронний ресурс]. – Режим доступу:

https://ru.wikipedia.org/wiki/Microsoft_Visual_Studio

18. Рухляда В. С., Карпенко М. Ю. Розробка персонального WEB-сайту. / В. С.

Рухляда, М. Ю. Карпенко // Харків: ХНАМГ. – 2008.

84

19. ASP.NET MVC. [Електронний ресурс]. – Режим доступу:

http://www.asp.net/mvc

20. Kurtz Jamie, Wortman Brian. ASP.NET Web API 2: Building a REST Service

from Start to Finish. / Jamie Kurtz, Brian Wortman // ISBN13: 978-1-484201-10-7

21. CSS-практикум, часть 1: назначение и возможности CSS. [Електронний

ресурс]. – Режим доступу: http://site.nic.ru/content/view/114/37.

22. Романюк О. Н. Веб-дизайн i комп'ютерна графіка: навчальний посібник / О .

Н. Романюк, Д. І. Катєльнков, О. П. Косовець. – В: ВНТУ, 2007. – 147 с.

23. Тестування програмного забезпечення. [Електронний ресурс] / Wikipedia. –

Режим доступу: http://en.wikipedia.org/wiki/ Software_testing.

24. Локалізація програмного забезпечення [Електронний ресурс] / Wikipedia. –

Режим доступу статті: http://en.wikipedia.org/wiki/ Localization.

25. Тестування веб-сайтів. [Електронний ресурс]. – Режим доступу: http://arhiv-

statey.pp.ua/index.php?newsid=26947.

26. Грабовецький Б. Є. Економіка підприємства. / Б. Є. Грабовецький, Т.М.

Пілявоз – Вінниця: ВНТУ, 2009 – 248 с.

27. Методичні рекомендації з комерціалізації розробок, створених в результаті

науково-технічної діяльності – К.: Наказ Державного комітету України з

питань науки, інновації та інформатики (Лист № 1/06-4-97 від 13.09.2010 р.).

28. Козловський В.О., Лесько О. Й. Бізнес-планування: Навчальний посібник /

В. О. Козловський, О. Й. Лесько [2-е вид., доп. Та переробл.] – Вінниця:

УНІВЕРСУМ-Вінниця, ВНТУ, 2008. – 241 с.

29. Козловський В.О. Техніко-економічні обгрунтування та економічні

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

Козловський – Вінниця: ВНТУ, 2003. – 75 с.

30. Козловський В.О. Економіка, організація виробництва та менеджмент в

дипломних роботах. Навчальний посібник / В.О. Козловський – Вінниця:

ВНТУ, 2004. – 94 с.

31. Козловський В. О. Бізнес-планування. / В. О. Козловський, О.Й. Лесько –

Вінниця: ВНТУ, 2005 – 188 с.

85

ДОДАТОК А

Технічне завдання

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

Міністерство освіти і науки України

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

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

ЗАТВЕРДЖУЮ

д.т.н., проф. А. М. Пєтух

"____ "________2015 р.

Технічне завдання

на магістерську кваліфікаційну роботу за спеціальністю

8.05010301 – Програмне забезпечення систем

Керівник магістерської кваліфікаційної роботи:

к.т.н., доц. В.В.Войтко

"____"_________________2015 р.

Виконaв:

студентка гр.1ПЗ-14м К.В. Білоконна

"____"_________________2015 р.

Вінниця ВНТУ 2015

86

1.1 Найменування та галузь застосування

Робота має назву «Розробка web-додатку для онлайн реєстрації

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

кваліфікаційної роботи.

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

використовуватись офіційною організацією.

1.2 Підстава для розробки

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

рішення засідання кафедри програмного забезпечення (протокол №___ від

«___»_____________ 20__ року).

1.3 Мета та призначення розробки

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

створення інформаційної системи та web-ресурсу, що дає можливість запису

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

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

провести порівняльний аналіз існуючих аналогів;

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

розробити моделі системи;

розробити модулі web-додатку;

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

1.4 Технічні вимоги

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

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

обчислювальна машина (ПЕОМ).

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

87

Для нормальної роботи програми, необхідний персональний комп’ютер

з наступною мінімальною конфігурацією:

1. Процесор Intel Core I7 з частотою не менше 3.5 Гц;

2. Оперативна пам’ять ємністю не менше 8194Мb;

3. Запам’ятовуючий пристрій ємністю 500 Gb.

4. Операційна система Windows 7/8/8.1.

Вимоги до програмного забезпечення.

Програмний продукт розробляється на мові програмування C# з

використанням платформи.NET та системи керування базами даних MS SQL

Server.

1.5. Перелік технічної документації, що пред’являється по закінченню робіт

– технічне завдання;

– технічне обґрунтування доцільності розробки;

– лістинги програми.

1.6 Стадії і етапи розробки

Завдання на проектування видане _________ 2015 року. Проектування

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

Технічне обґрунтування доцільності розробки web-

додатку онлайн реєстрації 20.09–25.09

Варіантний аналіз та обґрунтування вибору засобів

реалізації web-додатку 26.09–30.09

Розробка моделей системи 01.10–10.10

Розробка програмного забезпечення системи 11.10–27.10

Тестування програмного забезпечення системи 28.10–04.11

Економічна частина 05.11–10.11

1.7 Порядок контролю і приймання

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

документами ВНТУ і державними стандартами.

88

ДОДАТОК Б

Лістинг програмної реалізації

ClinicController.cs

using ComplexObjects;

using DataAccessLayer;

using Microsoft.AspNet.SignalR;

using System;

using System.Collections.Generic;

using System.Linq;

using System.Timers;

using System.Web.Http;

using System.Web.Http.Cors;

namespace AntiQServiceWebApp.Controllers

{

/// <summary>Contains requests related to clinic.</summary>

[EnableCors(origins:"*", headers:"*", methods:"*")]

public class ClinicController : ApiController

{

DAL dal = new DAL();

IHubContext hub = GlobalHost.ConnectionManager.GetHubContext<AntiQueueSeviceHub>();

/// <summary>Request for information about the clinic.</summary>

/// <param name="id">areaId</param>

/// <returns>Returns information about the clinic.</returns>

[HttpGet]

public ComplexObjects.Clinic GetClinicData(int id) //areaId

{

int clinicId = dal.SelectClinicByArea(id);

Dictionary<string, string> clinicData = dal.SelectClinicData(clinicId);

ComplexObjects.Clinic clinic = new ComplexObjects.Clinic();

clinic.ClinicId = clinicId;

foreach(KeyValuePair<string, string> data in clinicData)

{

switch(data.Key)

{

case "Address":

clinic.Address = data.Value;

break;

case "Name":

clinic.Name = data.Value;

break;

case "Phone":

clinic.Phone = data.Value;

break;

}

}

return clinic;

}

/// <summary>Request for specializations in clinic.</summary>

/// <param name="id">ClinicId</param>

/// <returns>Returns a dictionary of specializations id and name.</returns>

[HttpGet]

public Dictionary<int, string> GetClinicSpecializations(int id) //clinicId

{

return dal.SelectSpecializationsInClinic(id);

}

89

/// <summary>Request for doctors of selected specialization.</summary>

/// <param name="specializationId">specializationId</param>

/// <param name="areaId">areaId</param>

/// <param name="clinicId">clinicId</param>

/// <returns>Returns a list of Doctor objects, which contains information about doctors of concrete

specialization.</returns>

[HttpGet]

public List<ComplexObjects.Doctor> GetDoctors(int specializationId, int areaId, int clinicId)

{

bool isDistrict = dal.SelectSpecializationIsDistrict(specializationId);

List<int> doctorsId = new List<int>();

if (isDistrict != true)

{

doctorsId = dal.SelectDoctorBySpecializationAndClinic(specializationId, clinicId);

}

else

{

doctorsId = dal.SelectDoctorBySpecializationAndArea(specializationId, areaId);

}

List<ComplexObjects.Doctor> doctors = new List<ComplexObjects.Doctor>();

foreach(int id in doctorsId)

{

Dictionary<string, string> doctorData = dal.SelectDoctorData(id);

ComplexObjects.Doctor doctor = new ComplexObjects.Doctor();

doctor.DoctorId = id;

foreach (KeyValuePair<string, string> data in doctorData)

{

switch (data.Key)

{

case "Name":

doctor.Name = data.Value;

break;

case "Patronymic":

doctor.Patronymic = data.Value;

break;

case "Surname":

doctor.Surname = data.Value;

break;

case "Phone":

doctor.Phone = data.Value;

break;

case "Mail":

doctor.Mail = data.Value;

break;

}

}

doctors.Add(doctor);

}

return doctors;

}

/// <summary>Request for reception dates of selected specialization and doctor in clinic.</summary>

/// <param name="specializationId">specializationId</param>

/// <param name="doctorId">doctorId</param>

/// <param name="clinicId">clinicId</param>

/// <returns>Returns a list of doctor's reception dates.</returns>

[HttpGet]

public List<DateTime> GetDoctorsReceptionDates(int specializationId, int doctorId, int clinicId)

{

90

List<DateTime> dates = dal.SelectDoctorsReceptionDates(specializationId, doctorId, clinicId);

List<DateTime> nextDates = new List<DateTime>();

foreach(DateTime date in dates)

{

if(date >= DateTime.Now)

{

nextDates.Add(date);

}

}

nextDates.Sort();

return nextDates;

}

/// <summary>Request for the doctor's reception times in the selected date.</summary>

/// <param name="specializationId">specializationId</param>

/// <param name="doctorId">doctorId</param>

/// <param name="clinicId">clinicId</param>

/// <param name="date">date</param>

/// <returns>Returns a dictionary of reception times and information about availability of that time:

/// true - time is alreade booked,

/// false - time is free.</returns>

[HttpGet]

public Dictionary<TimeSpan, bool> GetReceptionTime(int specializationId, int doctorId, int clinicId,

DateTime date) //DateTime format: 2015-07-30

{

Dictionary<TimeSpan, bool> receptionTimes = new Dictionary<TimeSpan, bool>();

receptionTimes = dal.SelectReceptionTimes(date, specializationId, doctorId, clinicId);

Dictionary<TimeSpan, bool> receptionTimesOrdered = new Dictionary<TimeSpan, bool>();

receptionTimesOrdered = receptionTimes.OrderBy(i => i.Key).ToDictionary(t => t.Key, t => t.Value);

return receptionTimesOrdered;

}

/// <summary>Request for reservation / release of the reception time.</summary>

/// <param name="reception">Pay attention to the required fields in the object Reception.</param>

/// <returns>Returns a boolean value as response:

/// true - time booked successfully;

/// false - time wasn't booked (but also it may be bad request, check required properties).</returns>

[HttpPost]

public bool BookingReception([FromBody] ComplexObjects.Reception reception)

{

bool response = false;

if (ModelState.IsValid)

{

bool result;

result = dal.BookingReception(reception.SpecializationId, reception.DoctorId, reception.ClinicId,

reception.Date, reception.Time, reception.IsSelected);

if(reception.IsSelected == true)

{

int receptionId = dal.SelectReceptionId(reception.ClinicId, reception.SpecializationId,

reception.DoctorId, reception.Date, reception.Time);

dal.AddBookingToBookedReception(receptionId);

}

if (result == true && reception.IsSelected == true)

{

response = true; ;

}

else if (result == false && reception.IsSelected == true)

{

response = false;

91

}

else if (result == true && reception.IsSelected == false)

{

response = true;

}

else if (result == false && reception.IsSelected == false)

{

response = true;

}

//notify

hub.Clients.All.notifyStateChanged(reception.SpecializationId, reception.DoctorId, reception.ClinicId,

reception.Date, reception.Time, reception.IsSelected);

}

return response;

}

/// <summary>Request for record the patient's on reception.</summary>

/// <param name="data">Pay attention to the required fields in the object

RegistrationToReceptionData.</param>

/// <returns>Returns a registrationListId. If registrationListId=0 - the request is invalid. Check required

properties.</returns>

[HttpPost]

public int RegisterToReception([FromBody] RegistrationToReceptionData data)

{

int registrationListId = 0;

if (ModelState.IsValid)

{

dal.BookingReception(data.Reception.SpecializationId, data.Reception.DoctorId, data.Reception.ClinicId,

data.Reception.Date, data.Reception.Time, data.Reception.IsSelected);

int receptionId = dal.SelectReceptionId(data.Reception.ClinicId, data.Reception.SpecializationId,

data.Reception.DoctorId, data.Reception.Date, data.Reception.Time);

dal.AddDataToRegistrationList(receptionId, data.PatientId);

registrationListId = dal.SelectRegistrationListId(receptionId, data.PatientId);

List<int> bookedReceptionIds = dal.GetBookedReceptionId(receptionId);

foreach (int id in bookedReceptionIds)

{

dal.DeleteBookedReception(id);

}

}

return registrationListId;

}

/// <summary>Request for cancel record on reception.</summary>

/// <param name="data">Pay attention to the required fields in the object

UnregistrationFromReceptionData.</param>

/// <returns>Returns a boolean value as response:

/// true - time unbooked successfully;

/// false - time wasn't unbooked (but also it may be bad request, check required properties).</returns>

[HttpPost]

public bool UnregisterFromReception([FromBody] UnregistrationFromReceptionData data)

{

bool result = false;

if (ModelState.IsValid)

{

//get ids from Patient by mail

List<int> patientIds = dal.SelectPatientIds(data.Mail);

int RegistrationLis_PationID = dal.SelectPationIdFromRegistrationList(data.RegistrationListId);

//compare ids with regList->PatID

bool equal = false;

foreach (int id in patientIds)

92

{

if (id == RegistrationLis_PationID)

{

equal = true;

}

}

if (equal == true)

{

//unbook time

int receptionId = dal.SelectReceptionId(data.RegistrationListId);

dal.UnregisterReception(receptionId);

//notify views

DataAccessLayer.Reception reception =

dal.GetReceptionByRegistrationListId(data.RegistrationListId);

DataAccessLayer.ClinicSpecializationDoctor clinicSpecializationDoctor =

dal.GetClinicSpecializationDoctor(reception.ClinicSpecializationDoctorsClinicSpecializationDoctorId);

hub.Clients.All.notifyStateChanged(clinicSpecializationDoctor.SpecializationsSpecializationId,

clinicSpecializationDoctor.DoctorsDoctorId, clinicSpecializationDoctor.ClinicsClinicId, reception.Date,

reception.Time, reception.IsSelected);

//delete regList

dal.DeleteRegistrationToReception(data.RegistrationListId);

result = true;

}

}

return result;

}

}

}

PatientController.cs

using ComplexObjects;

using System;

using System.Collections.Generic;

using System.Linq;

using System.Net;

using System.Net.Http;

using System.Web.Http;

using DataAccessLayer;

//using DataAccessLayer;

using System.Web.Http.Cors;

namespace AntiQServiceWebApp.Controllers

{

/// <summary>Contains requests related to patient.</summary>

[EnableCors(origins: "*", headers: "*", methods: "*")]

public class PatientController : ApiController

{

DAL dal = new DAL();

/// <summary>Adding a new patient to the database.</summary>

/// <param name="patient">Pay attention to the mandatory fields in the object Patient.</param>

/// <returns>Returns patientId. If patientId=0 - the request is invalid. Check required properties.</returns>

[HttpPost]

public int AddNewPatient([FromBody] ComplexObjects.Patient patient)

{

int patientId = 0;

if (ModelState.IsValid)

{

93

patientId = dal.AddDataToPatient(patient.Name, patient.Patronymic, patient.Surname, patient.Birthday,

patient.Mail, patient.Phone, patient.PersonalData, patient.ApartmentId);

}

return patientId;

}

}

}

DAL.cs

using System;

using System.Collections.Generic;

using System.Linq;

namespace DataAccessLayer

{

public class DAL

{

RecordOnReceptionSystemContainer context = new RecordOnReceptionSystemContainer();

#region Select

//regions

public Dictionary<int, string> SelectRegions()

{

Dictionary<int, string> regions = context.Regions.Select(r => new { r.RegionId, r.Name }).ToDictionary(r

=> r.RegionId, r => r.Name);

return regions;

}

//cities

public Dictionary<int, string> SelectCitiesInRegion(int regionId)

{

Dictionary<int, string> cities = context.Cities.Where(c => c.RegionsRegionId == regionId).Select(c => new

{ c.CityId, c.Name }).ToDictionary(c => c.CityId, c => c.Name);

return cities;

}

//streets

public Dictionary<int, string> SelectStreetsInCity(int cityId)

{

Dictionary<int, string> streets = context.Streets.Where(s => s.CitiesCityId == cityId).Select(s => new {

s.StreetId, s.Name }).ToDictionary(s => s.StreetId, s => s.Name);

return streets;

}

//homes

public Dictionary<int, string> SelectHomesInStreet(int streetId)

{

Dictionary<int, string> houses = context.Homes.Where(h => h.StreetsStreetId == streetId).Select(h => new

{ h.HomeId, h.HomeNumber }).ToDictionary(h => h.HomeId, h => h.HomeNumber);

return houses;

}

public int SelectApartmentId(int homeId, string apartmentNumber)

{

int apartmentId = 0;

apartmentId = context.Apartments.Where(a => a.HomesHomeId == homeId && a.ApartmentNumber ==

apartmentNumber).Select(a => a.ApartmentId).FirstOrDefault();

if(apartmentId == 0)

{

if (apartmentNumber == "null" || apartmentNumber == "")

94

{

AddDataToApartment(null, homeId);

apartmentId = context.Apartments.Where(a => a.HomesHomeId == homeId && a.ApartmentNumber

== null).Select(a => a.ApartmentId).FirstOrDefault();

}

else

{

AddDataToApartment(apartmentNumber, homeId);

apartmentId = context.Apartments.Where(a => a.HomesHomeId == homeId && a.ApartmentNumber

== apartmentNumber).Select(a => a.ApartmentId).FirstOrDefault();

}

}

return apartmentId;

}

//area

public int SelectAreaByHome(int homeId)

{

return context.Homes.Where(h => h.HomeId == homeId).Select(h => h.AreasAreaId).FirstOrDefault();

}

public int SelectAreaByPatient(int patientId)

{

int apartmentId = context.Patients.Where(p => p.PatientId == patientId).Select(p =>

p.ApartmentsApartmentId).FirstOrDefault();

int homeId = context.Apartments.Where(a => a.ApartmentId == apartmentId).Select(a =>

a.HomesHomeId).FirstOrDefault();

int areaId = SelectAreaByHome(homeId);

return areaId;

}

//clinic

public int SelectClinicByArea(int areaID)

{

return context.Areas.Where(a => a.AreaId == areaID).Select(a => a.ClinicsClinicId).FirstOrDefault();

}

public Dictionary<string, string> SelectClinicData(int clinicID)

{

Dictionary<string, string> clinicData = new Dictionary<string,string>();

clinicData.Add("Address", context.Clinics.Where(c => c.ClinicId == clinicID).Select(c =>

c.Address).FirstOrDefault().ToString());

clinicData.Add("Name", context.Clinics.Where(c => c.ClinicId == clinicID).Select(c =>

c.Name).FirstOrDefault().ToString());

clinicData.Add("Phone", context.Clinics.Where(c => c.ClinicId == clinicID).Select(c =>

c.Phone).FirstOrDefault().ToString());

return clinicData;

}

//specializations

public Dictionary<int, string> SelectSpecializationsInClinic(int clinicID)

{

Dictionary<int, string> specializations = context.ClinicSpecializationDoctors.Where(c => c.ClinicsClinicId

== clinicID).Select(c => new { c.SpecializationsSpecializationId,

c.Specialization.Name}).Distinct().ToDictionary(c => c.SpecializationsSpecializationId, c => c.Name);

return specializations;

}

public bool SelectSpecializationIsDistrict(int specializationId)

{

95

return context.Specializations.Where(s => s.SpecializationId == specializationId).Select(s =>

s.IsDistrict).FirstOrDefault();

}

//doctors

public List<int> SelectDoctorBySpecializationAndArea(int specializationID, int areaID) //for family doctor

{

int[] clinicSpecializationdDoctorIDs = context.ClinicSpecializationAreas.Where(csa => csa.AreasAreaId ==

areaID).Select(csa => csa.ClinicSpecializationDoctorsClinicSpecializationDoctorId).ToArray();

List<int> doctors = new List<int>();

foreach (int id in clinicSpecializationdDoctorIDs)

{

doctors.Add(context.ClinicSpecializationDoctors.Where(cs => cs.ClinicSpecializationDoctorId == id &&

cs.SpecializationsSpecializationId == specializationID).Select(cs => cs.DoctorsDoctorId).FirstOrDefault());

}

return doctors;

}

public List<int> SelectDoctorBySpecializationAndClinic(int specializationID, int clinicID) //for women's

consultation

{

return context.ClinicSpecializationDoctors.Where(cs => cs.ClinicsClinicId == clinicID &&

cs.SpecializationsSpecializationId == specializationID).Select(cs => cs.DoctorsDoctorId).ToList();

}

public Dictionary<string, string> SelectDoctorData(int doctorID)

{

Dictionary<string, string> doctorData = new Dictionary<string, string>();

doctorData.Add("Name", context.Doctors.Where(d => d.DoctorId == doctorID).Select(d =>

d.Name).FirstOrDefault().ToString());

doctorData.Add("Patronymic", context.Doctors.Where(d => d.DoctorId == doctorID).Select(d =>

d.Patronymic).FirstOrDefault().ToString());

doctorData.Add("Surname", context.Doctors.Where(d => d.DoctorId == doctorID).Select(d =>

d.Surname).FirstOrDefault().ToString());

doctorData.Add("Mail", context.Doctors.Where(d => d.DoctorId == doctorID).Select(d =>

d.Mail).FirstOrDefault().ToString());

doctorData.Add("Phone", context.Doctors.Where(d => d.DoctorId == doctorID).Select(d =>

d.Phone).FirstOrDefault().ToString());

return doctorData;

}

//clinicSpecializationDoctor

public ClinicSpecializationDoctor GetClinicSpecializationDoctor(int clinicSpecializationDoctorId)

{

ClinicSpecializationDoctor clinicSpecializationDoctor = (from csd in context.ClinicSpecializationDoctors

where csd.ClinicSpecializationDoctorId == clinicSpecializationDoctorId

select csd).Single<ClinicSpecializationDoctor>();

return clinicSpecializationDoctor;

}

//reception

public List<DateTime> SelectDoctorsReceptionDates(int specializationId, int doctorId, int clinicId)

{

int clinicSpecializationDoctorId = context.ClinicSpecializationDoctors.Where(csd =>

csd.SpecializationsSpecializationId == specializationId && csd.DoctorsDoctorId == doctorId &&

csd.ClinicsClinicId == clinicId).Select(csd => csd.ClinicSpecializationDoctorId).FirstOrDefault();

List<DateTime> dates = context.Receptions.Where(r =>

r.ClinicSpecializationDoctorsClinicSpecializationDoctorId == clinicSpecializationDoctorId).Select(r =>

r.Date).ToList();

return dates.Distinct().ToList(); } } }

96

ДОДАТОК В

ІЛЮСТРАТИВНИЙ МАТЕРІАЛ ДО ЗАХИСТУ МАГІСТЕРСЬКОЇ

КВАЛІФІКАЦІНОЇ РОБОТИ

Завідувач кафедри ПЗ, д. т. н., професор ___________________ А. М. Пєтух

Науковий керівник, к. т. н., доцент кафедри ПЗ______________ В. В. Войтко

Рецензент, зав. каф. МБІС, д.т.н., професор________________О. М. Роїк

Нормоконтроль, к. т. н., доцент кафедри ПЗ ________________ В. В. Войтко

Виконавець, студентка групи 1ПЗ-14м____________________К. В. Білоконна

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113