ChSTU repository

,-~ . , 
МІІ ІІСТЕР '1'130 ОСВІТИ І І ІЛУКИ УКРАЇІ ІИ 
ЧЕРКАСЬКИЙ ДЕР)КЛ\3 1 ІИЙ т1_:: х1 ІОЛОІЧІ ІИЙ УІ ІІ ВЕРСИТІ2Т 
Факультет інформаційних технологій і систем 
Кафел,ра програмного забезпечення автоматизованих систем 
Поясн1овальна запис1(а 
до кваліфікаційної роботи бакалавра 
з напряму пщготовки І 21 «Інженерія програмного забезпечення» 
(ос11і1111,0-кваліфікані іі1111іі рі вс111,) 
на тему : 
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ КОНТРОЛЮ РОБОЧОГО ЧАСУ 
СПІВРОБІТНИКІВ ПІДПРИЄМСТВА 
Виконав : студент 113-184 
Напряму підготовки 
І 2 І «Інженерія програмного забезпечення » 
(11111фр і 11ю11а 11а11р11 .,1 у 11 ілгото111ш) 
Студент _____Г~ \~-'-а;"р__т,,и,_ І І_І~О І_( -в-',-,._А_,,,._ --,- ---
( 11рі"J ВІІ І І ll' та i 11 iнia.l fl ) 
Керівник ___ _ _ І..<.,.~ат--=-а_є_-в_а__Є-.,-ю·7"7"'._,_ ____  
( 11рі·ш11ш.: 1а i11i11i,l 111 ) 
Реце11зент - -----,-----,-,-,------
11 1ri1111,111, ІіІ і11і11іа. ІІІ) 
Ч еркаси 2022 року 
Форма № У-9.01 
Черкаський державний технологічний університет 
Факультет інформаційних технологій і систем ----~---- --------
(повна назва) 
Кафедра програмного забезпечення автоматизованих систем ___________  
(повна назва) 
Напрям підготовки ІНЖЕНЕРІЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ----------­
(код, назва) 
Спеніальність 121 «ІНЖЕНЕРІЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ» 
(ко.1. назва) -----------
ЗАТВЕРДЖУЮ: 
Зав. кафедри ~ 
" () t " ({) 2 20 Ztp. 
ЗАІЗДАННЯ 
на юн1ліфіющііі11у роботу бакnлаnрn 
" Бака.;1а11р 
(1ш1м p1n11_1 ) 
студс11ту Мартинюк Владислав А11атол і1Іоn11ч 
(Н(Н JІІІНІІС, ,r-i·•. 11,1 (1зl\, i.on1) 
1. Темп 11рос 1пу (р0Gот11 ) 11 ю1 · х1м11с забсз11с•1с1111я ко11т 
піш 1р11смстш1 
ЗtІТВСJ))(ЖСІІП ІІ[І(ШЗОМ 1\0 у11 івсрс11тсту від "07"02 2022 р. М!45/04 
2. Термін :щп11 і стулс11том закі11чс1ю1·0 проекту (роботн) "06" 06 2022 р. 
З. В11хію 1 і J tнІІі JtO нроскту (робот11); Опсраці11 11а систе~tа - Microsoft Windo\.vs 7/1 О. 
))L'Шtізсщія RE Т РІ ;щя uзаємодії зовнішніх клієнтів з сервером. архітектvра на базі 
стн11JtЩ)Т\1 U '11_, , tо,щток с\ЛЯ обліку робочого часу 
(т1:~щI•шю111ьс>l 1-:і.1ь1-.·іс11і miu (та) я1-:ісиі 1101-:аз111IюI. нюш 11Q61111eII від1106ідат11 об 'с,-;т r,рое1>:тувт111я 
11<1_1·1-:ово.·о до<:1ід.жеиня) 
➔. з~1іст розраху11ково-1юяс11юш 1ьної зап11ск11 (перел ік питань, що їх на.1е;кнть розробити) 
1 Л11ш1із С\'Час1111х СІІСТ('М контролю в11конання робочого графіку 
- Архітс~--.·,·ра сервіс,, об.1іку робочого часу 
3 Рсш1ізація мобі. 11,11ого додатку контролю виконання графіка робочого часу 
5. llt'pt'. 1ii-; графічного матеріалу 
/lІ.-\ П'.-\~ 1.-\ КО:\І ГІОІІЕНТІВ СЕРВІСУ 
C':'\Et--1.-\ І tЕ І !ТРА. ІЬІ-ІОЇ Т.-\ ВТОРИННОЇ БАЗИ ДАНИХ 
:\Л\'ОРІ І 1·:-,. І ЛОДАВ . \.ННЯ НОВОГО ТЕР~ІІНАЛА 
_J0Ш.8~.0b2.l!20~2~2J2P.•. :__ __________  
6. Дата вид.ачі заuдання -
І(алеидар•~~~ план 
(прізвище, 11-11 LЩUІИ) 
№ Назва етапів кваліфікаційної роботи Строк виконання еташв 
При~ 
з/п бакалавра проекту (роботи) 
1 ПІДГОТОВЧА СТАДІЯ лютий Викон. 
1.1 ПОСТАНОВКА ЗАДАЧІ лютий Викон, 
1.2 ПІДГОТОВКА ЗАВДАННЯ ЛЮТИЙ Викон, 
1.3 ПОГОДЖЕННЯ ЗАВДАННЯ ЛЮТИЙ Викон, 
1.4 ЗАТВЕРДЖЕННЯ ЗАВДАННЯ ЛЮТИЙ Викон, 
2 ОСНОВНА СТАДІЯ БЕРЕЗЕНЬ Викон, 
2.1 ПІДБІР МАТЕРІАЛІВ БЕРЕЗЕНЬ Викоп 
АНАЛІЗ ШЛЯХІВ РІШЕННЯ ПОСТАВЛЕНОЇ 
2.2 ЗАДА Ч} БЕРЕЗЕНЬ ВИКОН; 
2.3 ОФОРМЛЕННЯ ПЕРВІСНОЇ РЕДА ІЩ/Ї РОБОТИ КВІТЕНЬ Викон1 
3 ЗАКЛЮЧНА СТАДІЯ КВІТЕНЬ ВИКОН;, 
ОФОРМЛЕННЯ 1/ОЯСНІОВАЛЬНОЇЗАПИСКИ 
з. 1 РОБОТИ 
КВІТЕНЬ 
3.2 ВИКОНА 
ЗАТВЕРДЖЕН!ІЯ РОБОТИ 
ТРАВЕНЬ 
з.з ВИКОНА 
РЕЦЕНЗУВАІІІJЯ РОБОТИ 
ТРАВЕНЬ ВИКОНА 
Студент 
М_артинюк В.А. -
(11р1з11ище та і11іціали) --
(пщпис) 
Ксріоник роботи 
К~таєва Є.ІО. 
(11р1:111ищс та ініціанїї)' 
1 l) l І ' У. 22 1 Х 1Х . (І07 І П 
с11исо1· СКОРОЧЕІІІ> тл УМОВІН1Х ГIO'HIЛl.ff:Hh 
:\ l О ЛсtіУL'л 1)ata 01),i ccts 
, Pl Лрр\і (аt і о11 Рго~пн11111і11g І 11tcгli1 ccs 
С/\ "' Е Comptttcг Лі,іс<.і Systc111 l~пgi11ee1·i11g 
1:к 1'01·сі~11 kcy ( зовнішн і й ключ) 
РК 1яі1ш1гу kcy (первин ни й ключ) 
PL - pгcscпt~t io11 logic (презентаційна ло,~іка) 
ОА - Sсг\1 і се Огісп tеd Агс\1іtесtше 
UML - Uпified Modeliпg Laпguage 
АРМ - автоматизоване робоче місце 
БД - база даних 
JC - і нформаційна система 
КБД - корпоративна база даних 
ПБД - персональна база даних 
П JН - персонал ьний і ,цс11тифікаційний номер 
СРЧ - системи реального часу 
СУБД - система управління базою даних 
3 
ЗМ ІСТ 
ПИСОК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ ....................... ............ ....... 3 
1
ВСТ\ П ············ ····················· ···· ······ ···· ······· ······ ···· ·· ······················· ·· ·······························4 
І АНАЛІЗ СУЧАСНИХ СИСТЕМ КОНТРОЛJО ВИКОНАННЯ РОБОЧОГО 
ГРА<l)ІКУ ............... ..... .......... ............................... .............. ....... ........... .... ...... .. .......... 6 
1.1 Анал із особливостей створення і нформаuі й11и х системи обл і ку 
. . . . 6 
ДІ ЯЛЬНОСТІ прац1вник1в ...... .. ...... ... ........ .. ..................................... .. ................... .. 
1.2 Аналіз 1 снуючих сучасних систеі\•І контролю робочого часу ......................... 9 
І .З Огляд технологій для реал ізаuії серві су .... .................. ...................... ....... .... . І J 
1.4 Вимоги до сервісу обл іку часу ..... ... .. ........................... ............................ ....... 14 
2 АРХ ІТЕКТУРА СЕРВ ІСУ ОБЛ І КУ РОБОЧОГО ЧАСУ .. ................................... 19 
2.1 Компоненти серв ісу .... .. .................. ......... ........ .. ....... .... ..................... .. ........... . 19 
2.2 Л роцеси роботи з серв 1 соі\1 ................................... .......... .......... .. ...... .. ............ 20 
?_ .. ") J) еал .1  зац1. я сервера ................ .. ... ................. .. ...... .. ..... ........... ...... ... ...... ............. _?.")  
2.4 Реал і зація REST АР І для серв ісу .. .......... .. ...................... ................................ 27 
З Р ЕАJ ІІ ЗАЦІЯ МОБ ІЛЬНОГО ДОДЛТКУ КОІ !ТРОЛЮ ВИКОНАННЯ 
ГРАФ ІКА РОБОЧОГО ЧАСУ .............. .... ........................ ................... .... .............. 34 
З . І Інструменти збері гання даних .. .. ................ ..... .......... ................................ .... .3 4 
3.2 І11струменти розробки ............. ... .... .............................. ..... .. ............................. 38 
3.3 Користувальниuький і1-перфе 11 с .......................... .... ................................ ...... .42 
3.-l -І'ес·гування сервісу ............................ .... ..... .. .... ...................... ............ ...... ........ 48 
131-1('110 13 І(И .................. .... .... .................... ................. ...................... .... .......... .. .......... 55 
CJJ ИСОК ІЗИКОРИСТА І ІИХ Д)КЕРЕJ І .................................................................. 57 
) l())~ 'A ~ 'J' l( J,A J  ••• •••• ••••••• ••••• ••••••••• • •• •• •• ••• •••••••••.••• • ••••••••••••••• ................................................ 57 
Ч) tTY .22 1818.007 ПЗ 
r:~ докум 
\І.1р1111щж В Л ~. ,,,._ ' С Літ Лист Лист,{) 
І,аІ,І(ІІ.tС. ІО. l,,{fff//4 /j 11 ро , p,l\l lll' ~:11.1с ·~ 1 l l' ' )(' ) І ШІ І І з в, 
1,0111 ро: 110 1юGо• ІL) І L1 'Іr1l') ЧДТУ. 
І Іі11,·111, О. І., . 1 е: ~ ,С,, співро1.1 і 111111, і н 11і .1 11 р11п1с I ва кафедра ПЗ.АС. 11 3-1 8..J 
ЧДТУ.221818.007 ПЗ 
ВСТУП 
Актуальність дослідження 
Облік робочого часу співробітників ведеться в будь-якій організації. На 
підставі даних про фактично відпрацьований час на підприємстві для кожного 
співробітника генерується табель обліку робочого часу по формі Т-12, Т-13 або 
Т-14, нараховується заробітна плата та інші виплати, що належать працівнику. 
Керівники організацій використовують дані про відпрацьований час для контролю 
співробітників, підвищення продуктивності праці. 
Згідно зі статистичними дослідженнями [16], в Україні зареєстровано кілька 
сотень тисяч малих підприємств, які не можуть використовувати існуючі сервіси 
обліку робочого часу через складнощі експлуатації та необхідності покупки 
дорогого обладнання . 
Актуальною є задача створення платформи для обліку робочого часу 
співробітників з використанням можливостей сучасних смартфонів. 
Аналіз існуючих і найбільш доступних методів реалізації сервісу обліку 
робочого часу показує, що найбільш надійною є технологія передачі даних NFC 
[7], а найбільш поширеним і доступним терміналом, що має NFС-зчитувач, є 
смартфон на базі операційної системи Android. 
Мета та задачі 
Основною метою даної роботи - розробка сервісу для обліку робочого часу 
і контролю над дисципліною співробітників. 
В якості терміналу для зчитування даних може виступати смартфон на базі 
операційної системи Android, що володіє технологією безконтактної передачі 
даних NFC, в якості ключів для ідентифікації співробітників - будь-яка NFС­
карта. 
Мобільний додаток буде встановлено на смартфон для емуляції роботи 
терміналу. Додаток буде зчитувати дані з ключів співробітників, і відправляти їх 
на сервер по Wi-Fi або GSM. 
4 
ЧДТУ.221818.007 ПЗ 
На сервері буде обчислено фактичний час присутності співробітника на 
робочому місці, згенеровано табель робочого часу для кожного із співробітників, 
зібрана статистика запізнень і переробок по відділах. 
Для досягнення поставленої мети необхідно вирішити наступні задачі: 
провести огляд існуючих рішень по даній темі, виявити їх переваги та 
недошки; 
виявити вимоги, що пред'являються до серв1су, спроектувати його 
архітектуру, керуючись стандартом UМL; 
реалізувати REST АРІ для взаємодії зовнішніх клієнтів з сервером та 
додаток, який задовольняє всім поставленим вимогам; 
провести комплексне тестування сервісу. 
5 
ЧДТУ.221818 .007 ПЗ 
РОЗДІЛ 1 
АНАЛІЗ СУЧАСНИХ СИСТЕМ КОНТРОЛІО ВИКОНАННЯ РОБОЧОГО 
ГРАФІКУ 
1.1 Аналіз особливостей створення інформаційних системи обліку 
діяльності працівників 
Облік робочого часу може носити формальний характер, що, як правило 
фіксується в табелі робочого часу і управлінський характер, що передбачає його 
використання для досягнення поставлених цілей та завдань, виконання різних 
видів діяльності [ 1]. 
Якщо ставимо метою закладання в програм~ метод1в та моделей 
стимулювання праці, то доцільно використати відомі моделі, серед яких можна 
виокремити такі , як безпреміальна, преміальна, що залежить від розміру доходу 
або прибутку . . 
організації; прем1альна за шдивщуальними результатами, 
преміальна, в межах визначеного проекту [2, З]. 
На рисунку 1.1 представлено удосконалену модель управл1нського обліку 
. . 
завантаження прац1вниюв. 
С) '}--упність Робочий ч:ас; Обробка даних для 
. . 
р1зноманtпmх Показники оц~нювання 
, 
взає:мопов язаних виконання: результаnв та їх 
. . 
відомостей про ~нднвщуальних впливу на загальний 
. . 
стан об · єкта 1\ плашвта \ результат д1ЯЛЬНОСТ1 
управління, його завдань; орrанізації, її 
завантажеШіЯ, V Результативні vр ейтингу, бренду, 
види та ~ндикатори рейтингу працівника. 
результати виконання: 
д1ЯЛЬНОСТ1 
Рисунок 1.1 - Загальна модель інформаційної системи управлінського обліку та 
моніторингу завантаження працівників 
Загальна модель програмного продукту управлінського обліку завантаження 
6 
ЧДТУ.22 1818.007 ПЗ 
працівників повинна базуnатись на моделі інформаційної системи обліку та 11 
основних принципа.,"< [8]. 
Крім того, доцільно також використовувати досвід оплати праці зарубіжних 
k--раїн, а саме такі принципи як: 
заробітна плата кожного працшника має бути встановлена 
. . 
ІНдивщуально; 
перегляд заробітної плати робітників проводиться один раз на рік; 
застосовуються системи матеріального заохочення для різних категорій 
. . 
працшниюв; 
рівень заробітної плати має відображати досягнення та мотивац1ю 
пращвника. 
заходи моніторингу та контролю, спрямовані на вдосконалення оплати 
праці, містять насамперед забезпечення залежності розмірів заробітної 
плати від особистого внеску працівників у результати праці [7]. 
Інформаційна система обліку (ІСО) - це сукупність інформації, апаратно­
проrрамних і технологічних засобів, засобів телекомунікації, баз і банків даних, 
метод1в 1 процедур, персоналу управшння, які реалізують функції збору, 
оброблення, нагромадження та оброблення інформації для шдготовки та 
прийнятrя ефективних управлінських рішень. 
Інформаційні системи обліку належать до класу складних систем, яю 
містять у собі велику кількість різноманітних елементів, що взаємодіють. Тому 
при створенні таких систем потрібно вирішити проблему декомпозиції, тобто їх 
поділу на простіші складові та подання меншим числом узагальнених елементів. 
При описуванні інформаційної системи використовується кілька видів 
структур, які різняться типами елементів і зв' язків між ними (документальні, 
технічні, програмні, організаційні, алгоритмічні, інформаційні та функціональні 
структури). 
Документальна структура - це структура, елементами якої є неподшью 
складові та документи інформаційної системи, а зв'язки між елементами -
взаємодії, вхідност1 1 супідрядності. 
7 
ЧДТУ.221818.007 ПЗ 
Технічна структура - це структура, елементами якої є обладнання комплексу 
технічних засобів інформаційної системи, а зв' язки між елементами відбивають 
інформаційний обмін. У програмній структурі елементами є програмні модулі, а 
зв'язки між елементами реалізуються у вигляді інформаційних масивів. Під 
організаційною розуміють структуру, елементами якої є колективи людей та 
окремі виконавці, зв' язки між елементами - інформаційні, супідрядності та 
взаємодії. Елементами алгоритмічної структури є алгоритми, зв'язки між 
алгоритмами реалізуються за допомогою інформаційних масивів. 
Інформаційна структура - це структура, елементами якої є форми існування 
1 подання інформації у системі, зв'язки між ними - операції перетворення 
інформації в системі. Елементами інформаційної структури можуть бути також 
інформаційні масиви, зв'язки - операції роботи з масивами: введення, 
коригування, перегляд, знищення тощо. 
Функціональна структура - це структура, елементами якої є компоненти 
(підсистеми), функції інформаційної системи або її частини, зв'язки м1ж 
елементами - це потоки інформації, що циркулює між ними під час 
функціонування ІС. 
При створенні комп'ютерних інформаційних систем обліку найчастіше 
використовується функціональна структура. При створенні програмного продукту 
буде застосований системно-ситуаційний підхід, який дозволить врахувати 
основю принципи системного шдходу, а саме: кінцевої мети - абсолютний 
пріоритет глобальної мети; єдності - розгляд системи як цілого; зв'язності -
врахування зв'язків та відносин; модульної побудови; ієрархії; функціональності; 
децентралізації; врахування станів невизначеності. 
Також необхідно виконати тишзац1ю задач та 1х стандартизац1ю, 
відповідність плановим завданням та функціям, що виконують працшники. 
Ситуаційний підхід передбачає врахування конкретних ситуацій при здійсненні 
визначених видів діяльності та виконання конкретних завдань [8]. 
Використовуючи системний підхід до формування програмного продукту 
обліку та моніторингу роботи працівників та оцінювання результатів їх діяльності, 
8 
ЧДТУ.221818.007 ПЗ 
необхідно відповісти на основні питання доцільності автоматизації та сформувати 
загальні моделі взаємозв'язків системи моніторингу та оцінювання [14]. 
Представлені результати діяльності можуть бути конкретизовані кожним 
адміністративним підрозділом для формування рейтингу працівників та реалізації 
функції мотивації їх діяльності. 
Таким чином, для створення програмного продукту обліку роботи 
працівників необхідно визначити мету та подальше використання облікової 
інформації, особливості організації та подальше проектування і технічні аспекти 
реалізації продукту. Така модель дозволить сформувати необхідні первинні 
облікові документи, підготувати дані для подальшої обробки, оцінювання 
результатш діялмюсті, визначення рейтингів, рrвня виконання плаюв, 
прогнозування подальшої діяльності підрозділів підприємства. 
1.2 Аналіз існую'-ІІfХ сучасних систем контролю робочого часу 
Сервіс обліку робочого часу Workly 
Хмарний сервіс Wot·kly [ 12] пропонує для обліку робочого часу 
використовувати мобільний термінал TimePad. Термінал TimePad [21] дозволяє 
фіксувати прихід та вихід співробітників на територію офісу за допомогою QR­
кодів або РІN-кодів (рисунок 1.2). 
·-• 
_ .. tlF""( . ... -
,ft \~ е 
10:85 
, ..:::::.:.~ ф 
' .,. .. "'"' І"\::о)~ 
QQQQ о Q,) Q 
.... , .... _ .... ~·--
1 2 з 
4 5 6 
7 8 9 
Рисунок 1.2 - Методи ідентифікації співробітників в мобільному терміналі 
TimePad 
9 
чдт .221 1 .007 113 
Дані п би ід нтифікації півр бітників мають ряд серйозних недоліків: 
викори тання РІN-кодів і QR-кодів небезпечно, оскільки вони можуть 
бути л гко тиражовані, дубльовані, забуті вдома через неуважюсть, 
п р дані в кори тування іншому співробітнику, загублені; 
використання QR-кодів накладає на систему певну складн1сть 
зчитування даних - необхідність направити камеру під певним кутом. 
Сервіс обліку робочого часу ТІМЕDОСК 
Сервіс ТІМЕDОСК [13] для обліку робочого часу, як карток співробітника, 
пропонує використовувати прості, роздруковані на принтері бейджики з QR­
баркодом, а в якості зчитувача карт - практично будь-який пристрій, що має 
відеокамеру і здатний розпізнавати QR-коди (рисунок 1.3). 
Рисунок 1.3 - Пристрій для читання карт в додатку ТІМЕDОСК 
Оскільки для ідентифікації співробітників в сервісі використовуються 
аналогічні QR-коди, сервіс ТІМЕDОСК також володіє всіма вищеописаними 
недоліками - небезпечність рішення і незручність зчитування даних з ключа 
співробітника. Під терміном «облік робочого часу» в сервісі ТІМЕDОСК [20] 
10 
ЧДТУ.221818.007 ПЗ 
мається на увазі контроль над часом, витраченим на виконання робочих завдань і 
процесів. Реєстрація початку виконання будь-якого завдання або діяльності 
виконується за допомогою карток з QR-кодами. Приклади таких карток 
предстаалені на рисунок 1.4. 
SCAN 
This project 
ergonotes.com 
Powef!d Ьу Tme:Oocx.com 
Рисунок 1.4 - Картки реєстрації виконання завдань в сервісі ТІМЕDОСК 
Після спроби попрацювати з серв1сом TIMEDOCK видшено ще один 
істотний недолік - відсутність можливості більш тонкого налаштування системи в 
залежносп вщ роботи з нним (наприклад, вибору часових поясів або мови 
інтерфейсу). 
1.3 Огляд технологій для реалізації сервісу 
Технологія NFC 
Near field communication, NFC («комунікація ближнього поля», «ближній 
безконтактний зв'язою>) - це технологія бездротового високочастотного зв'язку 
малого радіусу дії, яка дає можливість обміну даними м1ж пристроями, що 
знаходяться на відстані близько 10 сантиметрів [1]. 
Дана технологія - просте розширення стандарту безконтактних карт (ISO 
14443), яка об'єднує інтерфейс смарт-карти і зчитувача в єдиний пристрій. 
Пристрій NFC може підтримувати зв'язок з існуючими смарт-картами, а також зі 
11 
ЧДТУ.221818.007 ПЗ 
зчmувачами стандарту ISO 14443, та з іншими пристроями NFC, і, таким чином, 
сумісний з існуючою інфраструктурою безконтактних карт [7]. 
Технологія NFC [2] в даний час головним чином націлена на використання в 
мобільних телефонах і планшетах. Існують три основні області застосування NFC: 
емуляція карт - пристрій NFC поводиться як існуюча безконтактна 
картка; 
режим зчитування - пристрій NFC є активним і зчитує пасивну RFШ­
позначку, наприклад для інтерактивної реклами; 
режим Р2Р - два пристрої NFC разом зв'язуються обмінюються 
інформацією. 
Використання технології безконтактного обміну даними NFC для побудови 
сервісу обліку робочого часу дозволить запобігти ряд проблем, що виникають з 
безпекою сервісу. Як NFС-ключ можуть бути використані квитки метро, брелки­
ключі від домофону, банківські картки, закордонний паспорт, смартфони на базі 
операційної системи Android, здатні емулювати NFС-карту. 
Оскільки NFС-кточі є особистою власністю працівника і надають для нього 
певну цшюсть, вони з меншою ймовірністю можуть бути втрачені, забуті, 
передані в користування іншому співробітнику. NFС-карта, на відміну від РІN­
коду або QR-коду, є фізичним ключем, тому ідентифікатор NFС-ключа не може 
бути продубльований. 
ТехнологіяВеасоп 
Сервіс обліку робочого часу може бути спроектований принципово іншим 
способом так, щоб самостійно і без безпосередньої участі співробітника 
визначати, чи перебуває співробітник на робочому місці. Така поведінка сервісу 
може бути досягнуто з використанням маяків beacon [4 ]. 
Маяки Beacon - це невеликі датчики, оснащені технологією Bluetooth Low 
Energy (BLE), які передають сигнал мобільному пристрою при наближенні його 
на певну відстань (в радіусі не більше п'ятдесяти метрів), і мобільний додаток 
повідомляє користувача. 
12 
ЧДТУ.22 1818.007 ПЗ 
Технологія Bluetooth Low Eneгgy використовується для передачі сигналу на 
невеликі відстані і відрізняється від Bluetooth низькою витратою батареї, вартістю 
(на 60-80% дешевше) та застосуванням. Технологія BLE підходить для 
використання в простих додатках, що вимагають невеликих періодичних передач 
даних. 
iBeacon - це стандарт компанії Apple, вбудований в iOS 7 (6]. Це система, що 
дозволяє iPhone і iPad постійно сканувати наявність пристроїв Bluetooth поблизу 
та реагувати на їхні сигнали. 
Маяк beacon періодично, з штервалом від декількох секунд до деюлькох 
хвилин, передає пакети для з'єднання (без встановлення самого з'єднання), які 
містять, крім заголовка, наступну корисну інформацію: 
UUID - 128-бітний унікальний ідентифікатор групи маяків, визначає їх 
тип або приналежність одній організації; 
Major - І б-бітне беззнакове значення, за допомогою якого можна 
групувати маяки з однаковим UШD; 
Minor - І б-бітне беззнакове значення, за допомогою якого можна 
групувати маяки з однаковим UШD і Major; 
Measured Power - 8-бітне знакове ціле - значення індикації рівня сигналу 
(RSSI), відкалібровані на відстані 1 м вщ приймача, яке 
використовується для визначення близькості маяка до приймача 
(мобільного пристрою). 
EddyStone - альтернативний iBeacon протокол для маяків, також заснований 
на Bluetooth LE, розроблений компанією Google. На відміну від протоколу 
iBeacon, EddyStone є більш відкритим протоколом. 
Використання даних технологій позиціонування всередию прим1щення 
може знайти застосування і в розробці сервісі обліку робочого часу. На території 
офісу встановлюються один або декілька маяків beacon, координати розташування 
яких заздалегідь відомі. Ці маяки із заданою періодичністю створюють 
трансляцію розсилки, яка містить ідентифікуючу інформацію. 
На смартфони співробітників встановлюється мобільний додаток, який 
13 
ЧДТУ.221818.007 ПЗ 
орієнтований на виявлення офісних маяків. Додаток циклічно отримує ці дані, по 
базі даних визначає координати маяків, і на основі їх сигналу (що дозволяє 
визначити ступінь дальності від кожного з них) визначає своє місце розташування. 
На підставі обчислених даних про місцезнаходження співробітника можна 
визначити, чи знаходиться співробітник на робочому місці і при необхідності -
зафіксувати цю інформацію в сервісі обліку робочого часу. 
На підставі розглянутих конкурентних рішень аналопчних серв1сш, 
зіставленні їх переваги і недоліків, обрані інструменти для реалізації сервісу 
обліку робочого часу. 
Вирішено використовувати технологію безконтактної передачі даних NFC 
для реалізації сервісу облік часу, а сам сервіс розгорнути в хмарі, зробивши його 
максимально доступним для користувачів з будь-якої точки світу. 
1.4 Вимоги до сервісу обліку часу 
Сервіс обліку робочого часу призначений для контролю над виконанням 
робочого графіка співробітниками організації. Сервіс дозволяє оперативно 
відслідковувати дисциплінарні порушення і своєчасно сповіщати про це 
керівників організації за допомогою sms та інших повідомлень. 
Для ідентифікації співробітників призначею ключ~ з NFС-мітками. 
Прикладами таких ключів є карти метрополітену, банківські картки, смартфони з 
технологією NFC, брелки від вхідних дверей. Використовуючи свій NFС-ключ, 
співробітник відзначається на терміналі кожен раз, коли покидає або повертається 
на територію офісу. 
Терміналом є найпростіший смартфон, оснащений NFС-зчитувачем, з 
встановленим додатком. Термінал зчитує дані ключів, обробляє і відправляє дані 
на сервер. 
Переглянути інтерактивний графік з табелем відвідуваності співробітників 
можна у веб-інтерфейсі сервісу. На основі графіка відвідувань для кожного 
співробітника буде згенеровано табель обліку робочого часу, а також зібрана 
статистика по всіх порушеннях. 
Ключовими перевагами сервісу є швидке впровадження, доступність 
14 
ЧДТУ.221818.007 ПЗ 
обладнання та дешевизна експлуатації. Ці аспекти роблять можливим 
використання сервісу на будь-якому підприємстві, нашть з досить малою 
кількістю співробітником (близько 1О  осіб). 
На відміну від традиційних систем, серв1с може бути використаний для 
контролю співробітників не тільки на стаціонарних, але і на мобільних та 
просторових робочих місцях (будівництва). 
Функціональні вимоги 
Функціональні вимоги визначають функціональність програмного 
забезпечення, тобто описують, що необхідно реалізувати в продукті або системі, 
які можливості має надавати розроблена система. Функціональні вимоги 
вкmочають в себе бізнес вимоги та вимоги, які призначені для користувача. 
Виявлені нас'І)'ПНі функціональні вимоги для системи контролю часу: 
1 Система повинна надавати інтерфейс для створення облікового запису 
корисrувача І входу в систему. 
2 Система повинна надавати інтерфейс для створення нової організації. 
З Система повинна надавати інтерфейс для додавання в організацію 
співробітників. 
4 Система повинна надавати інтерфейс для призначення працшникам 
робочих графіків. 
5 Система повинна надавати інтерфейс для призначення пращвникам 
ключ1в, забезпечувати можливІсть управшння статусами ключІв 
співробітників. 
6 Система повинна надавати інтерфейс для додавання нових термшалІв, 
забезпечувати можливість управління статусами терміналів. 
7 Система повинна забезпечувати можлив1сть відзначитися 
співробітникам в сервісі. 
8 Система повинна забезпечувати можливість кешування даних про оцінки 
співробітників на терміналі. 
9 Система повинна забезпечувати можлив1сть гнучкого налаштування 
опцій роботи терміналу в залежності від потреб організації. 
15 
ЧДТУ.221818.007 ПЗ 
І О Система повинна генерувати табель обліку робочого часу для кожного 
співробітника. 
Нефую,7/іональні вимоги 
Нефункціональні вимоги описують властивосп обмеження, ЯКІ 
накладаються на систему. Нефункціональні вимоги визначають, як повинна 
працювати система або програмний продукт, і якими властивостями або 
хара.І-.'Теристиками вона повинна володіти. 
Для реалізації системи контролю часу сформульовані наступю 
нефункціональні вимоги: 
1 Система повинна бути реалізована відповідно до триланковоІ КЛІЄНТ­
серверної архітектурою: клієнт - сервер додатків - сервер БД. 
2 Система повинна забезпечувати поділ даних на центральну базу даних та 
локальні бази даних для кожної організації. 
З Сервер повинен бути розроблений на сучасній мові програмування. 
4 Сервер повинен надавати REST АРІ для маніпулювання даними. 
5 Мобільний клієнт повинен бути розроблений для платформи Android на 
високій мові програмування. 
Опис прецедентів 
На рисуноку 1.5 зображена діаграма варіантів використання сервісу. В ході 
. . . . . . 
проектування сервІсу видшею чотири головю актора, ЯКІ взаємодноть з 
розроблюваної системою: користувач, співробітник організації, менеджер 
організації і власник організації. 
Користувач може створити собі новий обліковий запис в серв1с1, 
авторизуватися в сервісі через веб-інтерфейс або мобільний додаток за допомогою 
вже наявної пари логін-пароль або створити нову організацію в сервісі, ставши її 
власником. Користувач є базовим актором, характеристики і властивості якого 
. . . 
успадковують вс1 ІНШІ актори. 
Співробітник організації може шдзначитися в сервІс1, використовуючи 
персональний NFС-ключ, переглянути журнали відвідувань і табелі обліку 
16 
ЧДТУ.221818.007 ПЗ 
робочого часу співробітників організації, а також переглянути інформацію про 
організацію, в складі якої він зна.ходиться. 
Сt'рвіс ZapTimt>І' 
Сrворнm 
mдпрш:мство 
11 ВІQадиm 
підприємство 
Користувач 
Пр1оначити Власшrк 
менед::RРа пішІрпємсrва 
д 
Додаm 
співробіпшц 
В~rип.а 
СпівробіТШІК 
піі.шрпємсп~а __,--- ~енеджер 
__.,.- пщпрпємства 
r 
Рисунок 1.5 - Діаграма прецедентів сервісу обліку робочого часу 
Менеджер підприємства має ряд повноважень для управління організацією, 
включаючи додавання нових співробітників, підрозділів і терміналів, призначення 
співробітникам робочих графіків і унікальних ключів для ідентифікації в сервісі. 
Менеджер підприємства може керувати стаrусами ключів співробітників і 
терміналів, вносити коригування в журнал і проставляти значення в табель обліку 
робочого часу. 
Власник шдприємства має необмежені привше1 на управлшня своєю 
оргаюзацrєю, включаючи можлив1сть управшння ролями співробітників 
організації і можливість видалення організації. 
17 
------ -- - - --
ЧДТУ.221818.007 ПЗ 
З кожним актором системи пов'язано один або кілька прецедентів. На даній 
діаграмі деякі низькорівневі прецеденти об'єднані в прецеденти вищого порядку. 
Створити обліковий запис - будь-який анонімний користувач може створити 
новий обліковий запис в сервісі. 
Авторизуватися в системі неавторизований користувач може пройти 
процедуру авторизації в сервісі через веб-інтерфейс або мобільний додаток. 
Відзначитися - кожен співробітник організації, з яким асоційований 
активний NFС-ключ, може відзначитися в сервісі шляхом піднесення ключа до 
терм1налу. 
Всі позначки співробітників заносяться в журнал вщвщувань. Будь-який 
користувач з роллю співробітника шдприємства може переглянути журнал 
відвідувань організації. 
Додати співробітника - власник або менеджер підприємства можуть додати 
в оргаюзащю нового співробітника призначити йому параметри 
працевлаштування. Після додавання співробітника йому можна призначати 
робочий графік, згідно з яким для співробітника фіксується час приходу і відходу 
на роботу і час початку та закінчення перерв. Робочий графік розраховується до 
кінця року або до закінчення трудового договору. 
Відхилення фактичного часу присутності співробітника на робочому місці 
від призначеного йому робочого графіка трактуються сервісом як дисциплінарні 
порушення. 
Кожному співробітнику необхідно призначити ключ для ідентифікації в 
сервісі. Використовуючи свій NFС-ключ, співробітник реєструє в серв1с1 
фактичний час початку робочого дня, кінця робочого дня, а також час усіх перерв. 
Для забезпечення можливості співробітникам відзначатися в сервісі, 
необхідно додати термінал. Процедура додавання нового терміналу являє собою 
двоступеневий алгоритм, що складається з генерації коду активації терміналу в 
веб-інтерфейсі та введення коду активації на мобільний пристрій. Після виконання 
вищеописаних кроків термінал готовий до роботи. 
Створити підприємство може авторизований в сервісі користувач. 
18 
ЧДТУ.221818.007 ПЗ 
Користувач, який створив організацію, стає її власником. 
Призначити менеджера для передачі йому ряду повноважень по управлінню 
сервісом може RЛасник організації. 
Видалити підприємство може пльки її власник. При цьому оргаюзащя 
позначається як видалена і не відображається в списку активних організацій 
користувача. Організація, якийсь час не видаляється фізично, щоб можна було її 
відновити. 
У процесі аналізу вимог складено технічне завдання, в якому сформульовані 
основні функціональні та нефункціональні вимоги, що пред'являються до 
розробmованої системі, визначею rоловю користувачі системи і варіанти 
використання системи користувачами. 
19 
ЧДТУ221818.007 ПЗ 
РОЗДІЛ 2 
АРХІТЕКТУРА СЕРВІСУ ОБЛІКУ РОБОЧОГО ЧАСУ 
Архітектура сервісу для обліку робочого часу є класична триланкова 
архітектура: клієнт - сервер додатків - сервер бази даних, де в якості клієнтів 
вис'І)'Пають мобільні додатки на платформах iOS, Android і веб-додаток. 
2.1 Компоненти сервісу 
Для проектування статичного уявлення архітектури сервісу обрана діаграма 
компонентів. Діаграма компонентів наочно зображує розбиття програмної системи 
на структурні компоненти та зв'язки (залежності) між компонентами. 
Діаграма компонентів сервісу обліку часу представлена на рис. 2.1 1 
складається з нас-rупних компоненпв: 
- сервер Zaptimer; 
- REST-cepвic; 
. . . 
ЗОВН1ІІШ1 КЛІЄНТИ. 
REST АРІ 
Зовнішні 
KJilЄHTTf ____..Со-- REST-cepвic 
Сервер ZapTi.Jnel" 
-, 
Рисунок 2.1 - Діаграма компонентів сервісу ZapTimer 
20 
ЧДТУ.221818.007 ПЗ 
Взаємодія 1іж клієнтами і сервером відбувається за допомогою REST АРІ, 
rаданих RЕSТ-сервісом. REST-cepвic забезпечує передачу інформації на базі 
тротоколу НТТР. REST-cepвic реалізує ряд функцій з управління обліковими 
;аписами організаціями, співробітниками, ключами співробітників, терміналами і 
;курналами відвідувань. 
Зовнішні клієнти (Аndrоіd-додаток, іОS-додаток, веб-інтерфейс) постійно 
ззаємодіють з сервером за допомогою REST-cepвicy для реєстрації нових подій в 
;истемі (виявлення і зчmування ключів співробітників) . Також зовнішні клієнти 
регулярно запиrують у сервера дані про рекв1зити організації, списки 
:::півробітників і асоційованих з ними активних ключів, списки терміналів і 
>f-.'УРНали організації. 
2.2 Процеси роботи з сервісом 
Для проектування динамічного подання архпектури системи обрана 
діаграма послідовності. Дана діаграма описує взаємодію груп об'єктів в різних 
умовах їх поведінки. Діаграма послідовності моделює взаємодію об'єктів в часі. 
Для початку роботи з сервісом необхідно створити організацію і додати або 
зареєструвати термінал. Процес додавання нового терміналу відбувається 
наступним чином (рисунок 2.2): 
менеджер або власник підприємства натискають у веб-інтерфейсі кнопку 
«додати термшал»; 
веб-інтерфейс відправляє запит серверу на додавання нового терміналу 
за допомогою REST АРІ; 
сервер отримує запит на додавання нового терміналу через REST-cepвic. 
Сервер створює в базі даних новий термінал зі статусом NEW і генерує 
унікальний код для активації терміналу; 
- сервер повертає об'єкт щойно створеного терміналу веб-інтерфейсу; 
веб-інтерфейс відображає користувачеві код активації терміналу в 
браузері; 
користувач вводить код активації терміналу в мобільний додаток; 
- мобільний клієнт відправляє серверу запит на активацію терміналу за 
21 
ЧДТУ.22 1818 .007 ПЗ 
допомогою REST АРІ. Усередині запиту мобільний клієнт передає дані 
для ЗJ-."тивації терміналу: код активації, модель пристрою і ІМЕІ; 
сервер отримує запит на активацію терміналу через REST-cepвic. Сервер 
перевіряє наявність переданого коду активації в базі даних, змінює 
статус терміналу на ACTIVE, створює токен для терміналу і відправляє 
дані терміналу в мобільний додаток. 
мобільний додаток зберігає в файлі налаштувань дані терміналу, включаючи 
токен для авторизації і підприємство, в якій активований термінал, процес 
завершується. 
о 
.....І__яте.р..,ф._е_й_с__,/ / Апdrоіd-додато.:: І І REST-cepвic / .І. .._ _с _ер...в,._ер_  ___, 
І 
І 
Менеджер І 
І І І 
creakTemtiШІIO І І І 
..-'- -------t:--L, РОSТ .Jte11t1 iшils/ І 
І 
, l" "::~::~'\J 
., __ te1111innl ___ l 
І 
І pincode ' І 
рінсоdе І ,<-----------------1------------------ І 
І І 
І 
<------------------·1 І 
І І І 
І І І І 
1 j І І 
POST ../1e1111i11alsl І co111fi1111Tcm1i11al І 
1 со11/і1 1 11/ ~ (рінсоdе, 1110,ІеІ . І 
І 
,-------➔., 
с:::•~:о, j~] 
·- --~е~11:і! 1~ І ____ u 
l 1okc11 І 
І.- -- -- ----- ---- -- ... і- І 
І 
, І 
І 
Рисунок 2.2 - Процес додавання нового термінала 
Після додавання терміналу в сервіс можуть бути додані співробітники, 
22 
ЧДТУ.22 1 8 18.007 ПЗ 
співробітникам можуть бути призначені ключі . Використовуючи ЦІ ключ~, 
співробітники можуть відзначатися в сервісі . Ключовий процес роботи сервісу 
зображений на рисун1'-. у 2.3 і полягає в наступному: 
менеджер заповнює у веб-інтерфейсі форму додавання співробітника і 
натискає кнопку «додати співробітника»; 
веб-інтерфейс передає запит на додавання нового співробітника в 
організацію на сервер за допомогою REST АРІ; 
сервер отримує запит на створення співробітника через REST-cepвic. 
Усередині запиrу міститися передані дані про нового співробітника. 
Сервер створює на основі цих даних співробітника в базі даних 
організації і повертає об'єкт співробітника у веб-інтерфейс; 
менеджер призначає ключ співробітнику через мобільний додаток; 
'J 
т -г 
1 
І Інтерфейс ! / Аndrоіd-додаток І REST-cepaic І Сервер 
.Мене;zжер СпівробітинJ. _ _ _ . 
~- ----.-- -~ І І 
І І І І 
І І І 
: createPersouO : 1 . І І 
с--.:..~: --------~>l l ----~~s~:·_1: :~~::~ і --~~~•с~------ . __ [/ ~;~:;;;:~~, 
І І І І І 
'------~--=p_e_rs_o_11_--11--- - - --7,). ..J..i POST . Jp.:1·soнsl І . І 
о І <J)erso11 id:-ke= ! 1 odd.Кey(шd. І 
І l' -
і : l - --__k~!---- ~- ➔ t І 
--_[ -~-•_d;:~;;:!..l ) 
І key І , І І 
□І ); І І І 1 
t І І І 
__:4 І POST ..ljoнr11"l 1,/ : n,ІdJotiлн,Іtkey. : 
1І  1 j------ •1 d11teti111e) І 
І • І ~ j 
І І r_!:otl.: 20 І /jонnш1 ·, 
І srnt11sOk/ч.ннsF.1 il 
І ( І 
------------1------------------- ~ І 
І І 
Рисунок 2.3 - Процес роботи співробітника з сервісом 
мобільний клієнт передає запит на призначення співробітнику ключа 
23 
ЧДТУ.22 1818.007 ПЗ 
сервера за допомогою REST-cepвicy; 
сервер отримує запит на призначення ключа співробітника через REST­
cepв1c. Усередині запиту м1ститися даю про співробітника та 
ідентифікатор ключа. У разі якщо ключ вільний, сервер додає в базу 
даних нову асоціацію співробітник-ключ і повертає об'єкт тільки що 
створеного ключа в мобільний додаток; 
менеджер може передати ключ співробітнику; 
співробітник, використовуючи свій ключ, може вщзначитися на 
терміналі, піднісши до нього ключ для зчитування даних; 
мобільний клієнт зчитує дані з ключа і відправляє запит на додавання 
нового запису в журнал на сервер через REST АРІ; 
сервер отримує запит на додавання нового запису в журнал через REST­
cepвic, зберігає дані про нову відмітку співробітника в журнал~ 1 
повертає статус відмітки мобільному клієнту; 
мобільний клієнт аналізує статус позначки 1 видає користувачеві 
відповідний звук, процес завершується. 
В результаті спроектована архітектура сервісу, що складається з трьох 
основних компонентів: сервера, зовнішніх клієнтів (ІОS-додаток, Аndrоіd-додаток, 
веб-інтерфейс) і REST-cepвic. Всі компоненти є слабозв'язані, і зміна одного з них 
не впливає на шш1. 
2.3 Реалізація сервера 
Схема бази даних 
Для реалізації сервісу спроектована 1 реал1зована архпектура, що 
представляє собою поділ бази даних на первинну ( центральну, загальну для всіх 
організацій) і вторинну (приватну, актуальну для конкретної організації). 
Зберігання даних однієї організації окремо від інших організацій обумовлено 
рядом причин: 
- легкість масштабування даних - при необхідності бази даних організацій 
швидко і просто можуть мігрувати на шш1 сервера, виконуючи 
балансування навантаження серверів і т.д.; 
24 
ЧДТУ.22 1818.007 ПЗ 
швид1'."Одію при виконанні запитів до бази даних; 
логічний поділ та ізольованість даних дозволяє проводити системю 
роботи на одній базі даних без шкоди для баз даних інших організацій; 
можливість надавати клієнтам право самостійно вибирати, де і як 
зберігати свої дані. 
У первинній базі даних м1стяться дані про облікові записи користувачів і 
організаціях. Кожна організація має власний універсальний унікальний 
ідентифікатор (uuid), що генерується сервером за допомогою модуля uuid.uuid4 
при створенні організації. Іменування вторинних баз даних здійснюється на 
основі додавання префіксу «organization_» до uuid організації. 
Схем.а центральноz· бази даних 
Первинна або центральна база даних сервісу - база даних, що містить в собі 
інформацію, загальну для всіх організацій. 
To.kea 
v lD r.-'Т РК 
nІ toan VARCHAR (2SS) .. 
Eio._•11':eriOcatlo~Ke~· 
9 user ІNТ FК 
9 ІD ІNТ РК 
TtПDiuJ 9 email ІNТ FK 
..,_ • lD f!\.1 РК (;srr ke}· \ )\RCHAR.(255) 
І У user ~'Т FtC 4 -
v lD fNT РК expire DATE 
model \i\.RCНAR(2S;() 
login \~'\RCHAR.(255) 
imei \i\RCHAR.(2~S) 
, .. pas~,vord \~RCHAR(255) 
locatiou \~CНAR(2S5) ema.il \¼RCHAR(2Щ ч-.. [malL\ddr~s.s 
deкription \МСНАR(2Щ 
first_name \'ARCНAR(2SS) 
І created DAIE 9 JD ІNТ РК 
la&t_ n aine \(.\RCНAR(2 SS ) 
~Wted DATE ..,_ 9 шеr ІNТ FK 
is_octi,·e BOOLEA";I 
frnished DАТЕ ,·e.ri/ied BOOLL\~ 
Stal\lS \і\RСІ-'.АІЧ~5S) priuшry BOOLEA.,. 
І l 
L ~ІtшЬtr,ЬІр Or11alz11Іo1 
TfflDID1IVtriJlca1lo1К.y 
,; 1D INT РК ? 1D NT РК 
', 1D ~,- РК 9 user INT FK І,І--іt 11an1e \'ARCHAR(:!55) 
,;, шmiual r.п FK ,; organizatiou 11'-Т FK рІюое VARCНAR(I S) 
pincocu V.,\RCНAR( lO) relation_l)-pe \'ARCHAR(2И) address \ 1ARCHAR(:!SS) 
~pire DATE enwil_allo,,·ed BOOLEAN 
Оf!!WІЇZ4ІЇ011_І)'рс \~,\RCНAR(255) 
СОUІІ!І)' \ 'ARCIIAR(2S5) 
TtnnillalActn-lІYLOІ poc_lisn_ш1111e \J\RCHЛR(255) 
І::>-+- poc_la.st_rІWІ)e \1ARCHAR(:!5S) 
~ 1D І~'Т РК 
рос_ешаіІ \1ARCHAR(155) 
~ 1enшual П-:Т FK 
created DATE 
ncti,·at.ed DATE 
or~a11iza1ion_s1aiш \ ~ RCIIAR(:!S.S) 
dtзcti,·ated DАТЕ 
Рисунок 2.4 - Схема центральної бази даних 
25 
ЧДТУ.221818.007 ПЗ 
В первинну базу даних винесені дані про облікові записи користувачів, дані 
про реквізити організації, дані про термінали, оскільки один термінал може 
перебувати на прохідній відразу декількох організацій. Схема центральної бази 
даних сервісу представлена на рисунку 2.4. 
Ниж.'Че наведено опис основних таблиць первинної бази даних. 
Таблиця User призначена для зберігання інформації про всіх користувачів 
системи. Таблиця містить два обов'язкових поля: ім'я користувача і пароль, і 
деюлька необов'язкових полів, включаючи e-mail, активність аккаунта, дату 
останнього входу в систему. логічне поле is_  active визначає, чи може користувач 
авторизуватися в сервісі. 
У таблиці Token зберігаються маркери користувачів, що представляють 
собою І б-річний рядок, який використовується для аутентифікації та ідентифікації 
в серв1с1 через клієнтські програми. Кожному користувачеві в даний момент 
належить пльки один токен. 
Таблиця Organization зберігає інформацію про організацію, включаючи тип 
організації, фінансову інформацію, інформацію про контактну особу, службові 
поля ( created, status) . Ключовим полем є поле uuid - шістнадцяткове значення 
рядка. На основі даного поля згодом будуть згенеровані імена вторинних баз 
даних. 
Таблиця Membership визначає тип вІДносини м1ж обліковим записом і 
організацією. Поле relation_type може приймати одне з наступних значень: 
OWNER МANAGER USER TERМINAL. Залежно ВІД типу вщносин 
визначається роль користувача в організації та дозволу на виконання певних дій. 
Таблиця Terminal містить дані про термінали, включаючи характеристики 
пристрою (imei, model), що використовується в якості терміналу, опис та 
розташування терміналу, технічну інформацію про час створення, включення, 
відключення терміналу. На основі даних ІМЕІ є можливість отримати історію 
зчитування ключів співробітників на конкретному пристрої. 
У таблиці Terminal VerificationKey в поле pincode зберігається код для 
активації терміналу, який запитується в мобільному клієнті Android. При активації 
26 
ЧДТУ.221818.007 ПЗ 
терміналу перевіряється актуальність переданого коду активації на основі даних 
поля exp1re. 
Періоди активності терміналу зберігаються в таблиці TerminalActivityLog. 
Кожен запит на зміну статусу термtналу оновлює даю в таблиці 
TeпninalActivityLog. При зміні статусу терміналу на ACTIVE додається новий 
запис в таблиці Tem1inalActivityLog з датою включення терміналу (поле activated) і 
відкритою датою виключення терміналу (поле deactivated). При зміні статусу 
терміналу з ACTIVE на INACTIVE останній запис в таблиці TerminalActivityLog з 
відкритою датою виключення терм~налу, пов'язаний з цим терміналом, 
оновлюється (виставляється параметр deactivated). Згодом дані з цієї таблиці 
анал1зуються для визначення статусу зчитування нового ключа. 
Схема вторинної' бази даних 
Вторинна база даних зберігає даю, які безпосередньо відносяться до 
конкретної організації - дані про співробітників, асоційованих з ними NFС-ключі, 
параметри працевлаштування, робочі графіки, журнали вщвщувань I т.д. 
Вторинна база даних створюється при додаванні нової організації і має наступну 
структуру даних, представлену на рисунку 2.5 . 
OraPtrsoa ...l 
9 1D 11\ї РК 
u~r INT 
first_llAlllt \ )\RCHAR(:!5~) 
Іа~_,шше VARCHAR(2SS) 
finltibttl Jо11111І 
pзtroD)'Ш \i\RCHAR(.155) 
9 1D JNT О 1D r.-ї РК 
РК ~ 
binhda~• DATE 
011~rsou J:--'Т FK ,-.. &,tttimt' DAТ Е 
<,: еnюіІ \~RCHAR(:Ш) 
О L:ty П\'Т FK 
datl.' DАТЕ р:~ssро11_ІІШІІ~r \'ARCHAR(25$) 
tem1io.1І ІNТ 
day_l)Jкodt \j\RCHAR(2S~) ЇІW \~'\RCH,\R(2И) 1-
\'ARCНAR(2SS) u~ !NТ 
oi~t_opcodt $11Ї Іs \:.\RCHAJ{(:!SS) 
dny_  "'Ь$ 1:-.'Т " ·ork_shtdule \:-\RCHЛR(255) 
оіЕ,Ьr_\ \'bS 1:--т Kt)' 
- ч+ -
І q 1D П\1 РК 
,.,._ uid \'ARCl·IAR{!Щ 
Dtpa11WtDI E111plo~·111tal sraned DАТЕ 
• 1D І\'Т РК ,; 1D 1:--'Т РК fiнisbtd DАТЕ 
" pзr.-ut 1:0-Т FK 9 ~rsoo !NT FK - У org~rsoo NГ FK 
-І-< 
.011_ord.-r 1:---т 9 dtVartweot 11\'Т FK 
11n111~ \ :.\RCHAR(2SS) - posirion \ :.\RCHAR{255) 
\\-ork_sbtdult \ARCHAR(lSS) swced DАТЕ 
f fioi~ DАТЕ 
Рисунок 2.5 - Схема вторинної бази даних 
27 
ЧДТУ.221818.007 ПЗ 
Розглянемо основні таблиці структури вторинної бази даних. 
Таблиця 01-gPe,·son містить персональні дані про співробітників організації, 
включаючи контактну інформацію (e-mail), паспортні дані (passpost_number, inn, 
snils ), особистий розклад співробітника (Wo1·k_ shedule) . 
Department (підрозділ) - група співробітників, об'єднаних за принципом 
застосовуваного розкладу роботи. До властивостей Department відносяться 
найменування підрозділу, опис, розклад роботи. Якщо для підрозділу не задано 
розклад роботи, то застосовується розклад роботи, заданий для всієї організації. 
Кожен співробітник (OrgPerson) може бути доданий тільки в один підрозділ. Сама 
організація уособлюється кореневим підрозділом, що має ідентифікатор id, що 
співпадає з ідентифікатором id організації в первинній БД, і порожнім значенням 
parent_id. 
Таблиця Employment включає дані про трудовий договір між співробітником 
організацією - дата прийому на роботу, дата звільнення, посаду, на яку був 
прийнятий співробітник. 
Тimesheet зберігає дані табеля співробітника. Кожен співробітник, має 
актуальну інформацію про працевлаштування (посада), повинен мати запис в 
табелі обліку робочого часу за це число. Основними полями табеля є код обліку 
робочого часу, кількість відпрацьованих годин. При роботі одночасно в денні та 
нічні години використовується дві пари осередків код / кількість годин. 
Таблиця Кеу м1стить даю про NFС-ключі, яю використовуються 
співробітниками організації для фіксації відвідувань в журналі . Кожен ключ має 
обов'язкові поля : унікальний ідентифікатор NFС-мітки, дата початку дії ключа 
(дата призначення ключа співробітнику), ідентифікатор співробітника, з яким 
асоційований даний ключ, і необов'язкове поле - дата закінчення дії ключа, яке 
заповнюється сервером при деактивації ключа. На підставі даних полів started, 
finished визначається, чи активний ключ. Ключі з відкритою датою закінчення дії 
ключа вважаються активними. 
У таблиці Journal зберігаються даю про оцшки співробітників. Кожний 
запис в журнаш представлений наступними обов'язковими полями 
28 
ЧДТУ.22 1818 .007 ПЗ 
ідентифікатор ключа співробітника і час зчитування ключа. Як правило, запис в 
:>!-,УРНЗЛ додається від облікового запису терміналу організації, але, У виняткових 
випадках (співробітник забув картку), додати запис в журнал може власник або 
менеджер організації. Тому в Протокол зберігає посилання на обліковий запис 
терміналу - поле tenninal, або аккаунта - поле user. 
2.4 Реалізація REST АРІ для сервісу 
Всі взаємодії між клієнтами (веб-інтерфейс, Аndrоіd-кліенти, іОS-клієнти) і 
сервером здійснює за допомогою REST АРІ на базі протоколу НТТР. АРІ - єдина 
точка входу для всіх клієнтів. 
В рамках проекту реалізовано повнофункціональний АРІ, який надає 
клієнтам всі необхідні методи для роботи з сервісом, включаючи методи 
створення організації, додавання співробітників, призначення співробітником 
посад і розкладу, управління NFС-ключами, терміналами і журналами організації. 
{ 
"id": 475, 
"email_list": [ 
{ 
"id": 71, 
"email": "[email protected]", 
"verified": true, 
"primary": true 
}, 
] , 
"organizations": [ 
{ 
"city'': "'', 
"address": "", 
"id": "b0b6cc4f-be6e-49a 1-a9d1-7b2e494324fd", 
"roles": [ "manager"], 
"name": "Redso/ution" 
} 
], 
"token": "32а656511 defa4 ?ЗЬЬ 1032с239ЬОО 15аа8Ье2992", 
"username": "ivan.ivanov", 
"first_name": "Іван", 
"last name": "Іванов" 
} 
Рисунок 2.6 - JSОN-представлення структури даних Account 
29 
ЧДТУ.22 1 8 1 8 .007 ПЗ 
Згідно з концепцією REST [5] вид1·лен1· колекції ресурсів accounts, 
organizations, depart:inents,  регsо ns, t · І · · 
е1mша s 1 Jouгnals, опис структур даних яких 
буде наведено нижче. 
{ 
"!d": "~0b6cc4f-be6e-49a 1-a9d1 -7b2e494324fd" 
"1d_lat1n11 11
: wЗ?k~ly", ' 
"name"·.  n n ' 
"phone": " ", 
"address"· 11 
. " ' 
"emai/"· " n 
• І 
1
, email_allowe d ,1: true 
rr • • ' 
organ,zatюn_type": з, 
r•country": 171, 
rrtz".•  n 11 , 
,'poc_first_name": "Петро", 
"poc_last_name": "Петров", 
"poc_phone": " ", 
"poc_email": "[email protected]", 
"org_form": " ", 
"full_org_name11 11 
: ", 
"kpp": "745301001", 
"inn": "74 53175139", 
"bank_name": " ", 
1
, bik": "047501981 ", 
"nostro_account": "30101810900000000981 ", 
"bank_account": 1140702810461070001436", 
"legaf_address11 11 
: ", 
"city": " ", 
"url": " 1
', 
"country_ name'1 11 
: " , 
"country_name_en": 11
" 
} 
Рисунок 2. 7 - JSОN-представлення структури даних Organization 
Роботу з інформацією про облікові записи користувачів забезпечує колекція 
ресурсів account. Account - розширення системного облікового запису User, що 
дозволяє зберігати кілька адрес e-mail користувача та використовувати їх для 
30 
ЧДТУ.22 1 8 1 8.007 ПЗ 
ідентифікації користувача . JSОN-предстаnлення структури даних Account 
представлено на рисунку 2.6. 
Робоrу з інформацією про оргаюзац1ю корисrувачш забезпечує колекц1я 
ресурсів organizations. JSОN-представлення струкrури даних Organization 
представлено на рисунку 2.7. 
Робоrу з інформацією про підрозділи забезпечує колекц~я ресурсш 
departments. Структура даних Depaгtment організована у вигляді ієрархії. 
Кореневий елемент ієрархії уособлює організацію, має ID організації, не має 
батьківського елемента і створюється при ініціалізації БД підприємства. JSОN­
представлення структури даних Department представлено на рисунку 2.8. 
{ 
"id": "Ь0Ь6сс4 f-be6e-49a 1-a9d 1-7b2e494324fd", 
"departments": ( 
{ 
"id": "61325b73-6aa4-497a-Ь475-a8899d4a0b4d", 
"effective_work_schedule": { 
"department": "b0b6cc4f-be6e-49a 1-a9d 1-7b2e494324fd", 
"work_schedule": "АВС1" 
}, 
"parent": "b0b6cc4f-be6e-49a 1-a9d 1-7b2e494324fd", 
"sort_order'': 1, 
"name": "subordinate1 ", 
"work_schedule": null 
}, 
], 
"effective_work_schedule": { 
"department": "b0b6cc4f-be6e-49a 1-a9d 1-7b2e494324fd", 
"work_schedu1e": "АВС1" 
}, 
"parent": null, 
"sort_order'': 1, 
"name": " ", 
"work_schedule": "АВС1" 
} 
Рисунок 2.8 - JSОN-представлення структури даних Department 
Роботу з інформацією про співробітників організації забезпечує колекція 
ресурсів terminals. JSОN-представлення структури даних Terminal представлено на 
рисунку 2.9. 
31 
ЧДТУ.221818.007 ПЗ 
{ 
"id": 74, 
"created": "", 
"started": " ", 
"finished": "", 
''token": null, 
"organization": { 
"id": "Ь0b6cc4f-be6e-49a1-a9d1-7b2e494324fd", 
"name":"" 
}, 
"status": "DISABLED", 
"pincode": null, 
"imei": null, 
"model": null, 
"location": null, 
"description": null 
} 
Рисунок 2.9 - JSОN-представлення структури даних Tenninal 
Роботу з інформацією про співробітників організації забезпечує колекція 
ресурсів joumals. Будь-яка позначка в журналі пов'язана з терміналом або 
обліковим записом менеджера/власника підприємства, від імені якого додано 
запис в журнал. Тому структура даних журналу містить вкладену структуру даних 
терміналу або облікового запису користувача. 
JSОN-представлення структури даних Journal представлено на рисунок 2.1 О. 
{ 
"id": 11836, 
"account": null, 
"terminal": { 
"id": 783, 
"imei": "8646940206547 32", 
"created": "", 
"started": " ", 
"finished": null, 
"model": "ТСТ 6037У", 
"location": null, 
"description": null, 
"status": "АСТІVЕ" 
"key_ id": 38, 
"key_uid": "34Е994С1648А66", 
"org_person_id": 29, 
"datetime": " " 
} 
Рисунок 2.1О  - JSОN-представлення структури даних Joшnal 
32 
ЧДТУ.221818.007 ПЗ 
Роботу з інформацією про співробітників організації забезпечує колекщя 
ресурсів persoпs. З кожним співробітником в сервісі асоційовано NFС-ключ для 
ідентифікації співробітника, посада та підрозділ, в якому значиться співробітник, 
а також робочий графік, згідно з яким фіксується обов'язковий час присутності 
співробітника на робочому місці. 
{ 
"'id": 41 , 
· roJes": []., 
'"user": null, 
"pos-itions": [ 
{ 
"'id ..:  25, 
•position": "Контент-менеджер", 
'"started": .. ··, 
"finished": null 
} 
J, 
"'ikeys": [ 
{ 
"id"': 107, 
·star1ed": • ", 
•uid": "34DDDFC137C166", 
"'finished": null 
} 
J, 
..e ffecfive_v,ork_schedule"': { 
•d epartment": "ЬО b6cc4f-be 6e-49a1-a9d1 -7b2e494324fd'•, 
'\vork_schedule": ·двС1" 
1 
f, 
"'first_name": " ", 
, ast_name": "", 
•palroлym": null, 
·snils": 1nurt, 
"'passport_number'': null, 
"inn"': nulf, 
'"emair": nufl , 
·ьirthday": пu:11, 
·departmeлt": { 
•jd": "b0b6cc4f-be6e-49a1-a9d1-7b2e494324fd", 
·ettective v,ort schedule": { 
•d ёpartment": "ЬО b6cc4f-be бе-49 а 1-a9d1-7Ь2е494324fd''. 
"'\•1ork_schedule": ·дБС1" 
}, 
·pareпt": nu/1, 
•sort_order'': 1, 
•name": "", 
· ,,,ork_schedule": ·дБС1" 
}, 
"'\•1or k_schedu/e ": nul/ 
} 
Рисунок 2.11 - JSОN-представлення структури даних OrgPeI"son 
33 
-
ЧДТУ.22 1 8 18 .007 ПЗ 
Відповідно структура даних співробітника м1стить вкладеш структури 
даних Кеу, Position, Depaгt111ent, WoгkSchedule. JSОN-представлення структури 
даних OгgPe1-son представлено на рисунок 2. 11 . Для реалізації REST АРІ була 
використана бібліотека djangorest-fra111ew01·k [ І 8]. 
Згідно з концепцією RЕSТful-додатків, REST АРІ не зберігає інформацію 
про стан клієнта [І І]. Відповідно з кожним RЕSТ-запитом необхідно відправляти 
певний вид параметра аутентифікації користувача - секретний токен доступу. 
Приклади RЕSТ-запитів до сервера для авторизації в сервісі, реєстрації 
нового шдприємства, додавання в організацію співробітників, асоціація зі 
співробітником NFС-ключа, створення нового терміналу і додавання нової 
позначки в журнал відвідувань представлені на рисунок 2.12 
POST t::p://:aot~~er-de ~o .~edsolut:.o n . ru/ap:./v~/acconts/login/ 
- d "username=username" -d "pass\-.1ord=pass•,..ord" 
PCST tttp: // : ap:~~e=-je~o . =edsol uti o n . ru/ap~/vl / o r ganizatio~s/ 
- d "name=new organiza~ion" -d "tz=Azia/Yeka t erinburg" -Н " Authori zation: 
Token 1234 567890" 
?OST ht:p : // :ap::.~er-de~c -=edso_u::cn . ru /ap:. /v: /oraaniza:io~s/: /persons/ 
- d "fi rst name=firs t name" -d "la st name=last name" -Н " Authorizat i o n: To ­
ken 1234 567890 " 
POST :-. : :;: : / /: ~р: .:.r-::er-:~e::,-: . red~c: u::. С!1 . rt1 / ~р:. / 11 ~ / organ і za.t:io:1s/ 1/persons/ 1 / 
1:-::·.":.!_ - d "key_uid=l2345" -Н "Authorization: To ke n 12345678 90" 
POST http://:aot :mer-demc . redso:u: :.en . ru/ap~/vl/orga~i:acioпs/ 1 /cer~inals/ 
-Н "Authori zatio n : To ke n 1234 567 890 " 
POST h::p : //:a;::.re ~-~e~c .redsc:~ -:. ~n .ru/~pi/v:/crgзniza: i o~5/l/ Journзls/ 
-d "key_ uid=123 45" -d "datetime= 12 : 20:01 " -Н "Authorizatio n : To-
ken 12 34567890 " 
Рисунок 2.12 - Приклади RЕSТ-запитів до сервера 
34 
ЧДТУ.22 1818.007 ПЗ 
Повний перелік всіх доступних методів АРІ, що надаються RЕSТ-сервісом, а 
також матриця доступу до методів, що відображає правила доступу суб'єктів до 
інформаційних ресурсів повністю підтримується системою. Для серв1су 
реалізована архітектура, що представляє собою поділ бази даних на первинну 
(загальну для всіх організацій) і вторинну (актуальну для конкретної організації). 
В результаті виконана реалізація сервера відповідно до функціональних і 
нефункціональних вимог, що пред'являються до системи. У тому числі 
реалізований REST-cepвic, що надає необхідний REST АРІ для роботи клієнтських 
додатюв. 
35 
члт 1818.007 113 
І)ОЗДІЛ 3 
РЕАЛІЗАЦІЯ l\'1.ОБІЛЬНОГО ДОДАТКУ КОНТРОЛІО ВИІ{ОНАННЯ 
ГРАФІКА РОБОЧОІ О ЧАСУ 
3.1 Інструменти зберігання даних 
Файл наrюшnl) вань програми 
В Аndrоіd-додап,"ЗХ для зберігання невеликих наборів даних, яю можуть 
бути представлені у вигляді «ключ-значення», використовуються файли 
налаштувань програми, реалізовані класом SharedPreferences. 
Об'єь.т класу SharedPreferences надає прості методи для читання 1 запису 
даних в файл, а також надає можливість вибрати тип файлу (загальний або 
приватний). 
Файл налаrmувань програми орієнтований на зберігання примітивних типів 
даних - Integer, Long, Float, Boolean, String і StringSet. Основне призначення 
даного файлу - зберігання деякого стану програми і призначених для користувача 
налаштувань [З]. 
При реалізації мобільного додатка був створений файл налаштувань для 
зберігання простих і найбільш часто використовуваних даних. До таких даних 
належать даю користувача, авторизованого в додатку, 1 даю термшалу, 
активованого для зчиrування даних з кточів співробітників. 
Після успішної авторизації користувача в додатку, сервер повертає дані про 
обліковий запис корисrувача - ідентифікатор корисrувача, нікнейм і ім'я 
корисrувача, email-aдpeca, токен для ідентифікації корисrувача та для виконання 
насrупних запитів до сервера. 
Ці дані зберігаються у файлі налашrувань програми і видаляються тшьки 
при виході корисrувача з програми. 
Після активації терміналу додаток зберігає у файлі налаштувань дані про 
ідентифікатор терміналу, статус і тип терміналу (мобільний І стаціонарний), токен 
для авторизації та ідентифікації терміналу. 
Локальна база даних програми 
36 
ЧДТУ.221818 .007 ПЗ 
Необхідність кешування даних в мобільному додатку обумовлена 
наступними причинами - отримання найбільш часто використовуваних даних з 
локальної бази даних проrрами збільшить швидкість завантаження даних і значно 
знизить навантаження на сервер, скоротивши кількість запитів до сервера і 
кількість звернень до бази даних. 
Використання локальної бази даних програми надає користувачам 
можливість працювати з сервісом і при відсутності Інтернет-з'єднання або втрати 
з1єднання з сервером. 
Особливо важливо забезпечити автономну роботу термшалу, що збирає 
.інформацію про співробітників, з подальшою синхронізацією накопичених 
додатком даних з даними на сервері. 
Для зберігання даних про підприємства, ключі, співробітників і журнали 
відміток співробітників використовується база даних, що складається з чотирьох 
таблиць: Organization, Person, Кеу, Joumal. 
Таблиця 3.1 
Таблиця Organization 
№ Атрибут Семантика Тип 
І UUID Унікальний ідентифікатор на сервері String 
2 Name Назва String 
з Role Роль користувача String 
4 City Місто String 
5 Address Фактична адреса String 
Опис таблиці Organization для зберігання списку організацій, в яких 
користувач є учасником, представлено в таблиці З. І . 
Опис таблиці Person, що містить список співробітників для кожної 
організації користувача з таблиці Organization, представлено в таблиці З .2. 
Дані про ключі та співробітників оновлюються в додатку кожну годину, 
оскільки операції додавання співробітника, призначення співробітнику ключа -
виконуються досить нечасто. 
37 
ЧДТУ.221818.007 ПЗ 
Дані про ключі співробітників, відповідна інформація про співробітників, 
відправлєються на сервер в момент зчитування нового 1<люча. У разі якщо 
своєчасно передати на сервер дані про ключі співробітника не вдається через 
проблеми з досrупністю сервера, в мобільному додатку в режимі background 
запус1'.11ється сервіс, який відповідає за відправку накопичених даних. 
Таблиця 3.2 
Таблиця Person 
№ Атрибут Семантика Тип 
1 m Унікальний ідентифікатор в локальній базі Int 
2 ServerlD Унікальний ідентифікатор на сервері Int 
з FirstName Ім'я співробітника String 
4 LastName Прізвище співробітника String 
Зовнішній ключ на ідентифікатор 
5 OrganizationUUШ ForeignК.ey 
організації в локальній базі 
Опис таблиці Кеу, в якій зберігаються списки всіх актуальних ключів для 
кожного із співробітників, представлено в таблиці З.З. 
Таблиця З.З 
Таблиця Кеу 
№ Атрибут Семантика Тип 
1 ID Унікальний ідентифікатор в локальній базі Int 
2 ServerID Унікальний ідентифікатор на сервері Int 
з Uid Унікальний ідентифікатор NFС-ключа String 
4 Started Дата початку дії ключа Date 
5 Finished Дата закінчення дії ключа Date 
Зовнішній ключ на ідентифікатор 
б PersonID F01·eignКey 
співробітника в локальній базі 
Опис таблиці Journal для зберігання даних про всі відмітках співробітниках 
на активованому терміналі представлено в таблиці 3.4. 
38 
ЧДТУ.221818 .007 ПЗ 
Таблиця 3.4 
Таблиця Jош·ш1І 
№ Атрибут Семантика Тип 
І ID Унікальний ідентифікатор в локальній базі Int 
2 KeyUid Унікальний ідентифікатор NFС-ключа String 
.")  Datetiшe Дата і час події Date 
4 Event Опис події String 
5 Status Статус події String 
6 WasSend Статус відправки запису Boolean 
Механізми синхронізації даних 
Синхронізація даних локальної бази даних програми і центральної бази 
даних на сервері досягається шляхом реалізації в додатку сервісів, що працюють у 
фоновому режимі та призначених для своєчасного завантаження/оновлення/ 
вІДПравки локальних даних. 
Цей фоновий сервіс намагається відправити дані про ключі співробітників 
на сервер з періодичністю 5 хвилин. Сервіс здійснює відправку даних за 
принципом черги (FIFO, «першим прийшов - першим пішов») - до тих пір, поки 
не будуть успішно відправлені дані, відповідні найпершому зчитуванню ключа, 
дані про інші ключі зчитані терміналом пізніше, відправлені не будуть. 
Додатковим сигналом про необхідність синхронізувати локальні даю з 
сервером є події, при яких очікуваний результат не збігається з реальним 
результатом. До таких подій належать операції призначення ключа співробітнику, 
операції деактивації ключа, операції зчитування ключа співробітника терміналом 
для реєстрації приходу/відходу співробітника. 
Дані операції спираються на роботу з локальною базою даних програми, 
після чого відправляють результат діяльності операції на сервер. Невідповідність 
очікуваної відповіді сервера реальній відповіді є приводом для припущення про 
те, що локальні дані додатка є застарілими, відповідно, необхідно завантажити з 
сервера нову версію даних, і повторити операцію. 
39 
ЧДТУ.221818.007 ПЗ 
Надалі в якості додаткового методу синхронізації даних планується 
використання механізм відправки повідомлень GCM (Google Cloud Message). 
3.2 Інструменти розробки 
ORМRealm 
В якості бекенда для локальної бази даних програми обрана мобільна база 
даних Realш, написана на мові С++. База даних Realm представляє ОRМ для 
маніпулювання об'єктами і відрізняється від бази даних SQLite швидкодією і 
зручністю розробки [8]. 
puЬlic c l ass Кеу extends RealmObject { 
@Pri maryKey 
private int id; 
@Required 
pri vat e String uid; 
pri vate OrgPerson orgPerson; 
pri vate Date started; 
privat e Date finished; 
public Кеу() {} 
puЬlic Key(int id, String uid, OrgPerson orgPerson) { 
t his.id = id; 
this.uid = uid; 
this.orgPerson = orgPerson; 
Рисунок З .1 - Опис моделі даних Кеу в базі даних Realm 
Приклад опису моделі даних Кеу, що використовується для роботи з базою 
даних Realm, представлений на рисуноку З .1. 
На рисунку З .2 зображено приклад роботи з базою даних Realm [9] при 
реалізації сервісу завантаження та оновлення ло1<альних даних про ключ~ 
співробітників. 
40 
ЧДТ)Z22 1818.007 ПЗ 
Real realn = Realm. getDefaultI11sta11ce () ; 
Rea • !h~esu ts<Key> key_list = realm.1~!1ere (Кеу . class) . f iпdAll (); 
real . begin~ransactioп() ; 
key 1ist . clear () ; 
f r ( і. ~ і = О ; і< actialKeyList .si ze (); і++ ) І 
KeyMin key = actialKeyList .get(i) ; 
inI key_id = key.getld (); 
Str~ng key_uid = key.getUid() ; 
і . .І org_person_ i d = key. getOrgyerson id () ; 
Siring org_person_first_name = key.getFirst name(); 
s~ring orgyerson_last_name = key.getLast_n~me(); 
Кеу keyRealm=  nеи Key(key- id, key- uid, 
realm.where(OrgPerson.class) 
. equalTo ("id", orgyerson _i d) . f indFirst () 
) і 
rеа~.ПІ . copyToRealm (k eyRealm) ; 
reaLm.comi~~tTransaction( ); 
real . . c_ose () ; 
Рисунок 3.2 - Приклад роботи з базою даних Realm 
Бібліотека Retrofit 
Для роботи взаємодії додатка з сервером за допомогою REST АРІ 
використана бібліотека Retrofit, що дозволяє динамічно будувати НТТР-запити і 
виконувати їх асинхронно, а також автоматично конвертувати JSОN-відповідь 
сервера в jаvа-об'єкти [1 О] . 
Опис запитів до сервера відбувається в інтерфейсі Se1·viceApi. Над кожним 
методом повинна стояти анотація, за допомогою якої Retюfit визначає тип запиту 
(POST, GET, РАТСН, PUT, DELETE). 
41 
ЧДТУ.22 1818.007 ПЗ 
Також за допомогою анотацій @Patl1, @Field, @Queгy можна вказувати 
параметри запиту. 
42 
ЧДТУ.221818.007 ПЗ 
р ·~ i1terface ZapTirnerServiceApi { 
@PcST (" ·~anizations/{organization id}/terrninals/") 
·~а <rnerrn паl> cгeaJ..eTei-rninal ( 
@Path("orgaпizaJ..ioп id") Striпg orgaпization id 
) ; 
@Forrn·i-lEпcoded 
@POST ("te.:minals/confirm/") 
Са _<merrn~ паl> c01{irmTerminal ( 
@F;eld("pincode") String pincode, 
@~1eld{"model") SJ..ring model , 
@?~eld("ime~ 11
) String imei 
) ; 
@GET (1'organizat~ons/ {o rganization id} /terminals/") 
Call<Term~nalL~st> getTerminalList( 
@Path("organization id") String organization id 
) ; 
@GET("organizations/{organization id}/terminals/{terminal id}/ 11
) 
ca_l<Term~nal> getTerrninal( 
@Path("organization id") String organization id, 
@Path("terminal id") String terrninal id 
) ; 
~FormUrlEncoded 
@РАТСН (" or-ganiz.ations/ {o rganization id}/ termiпals/ {t erminal id} /") 
Call<Terminal> updateTerrninal( 
@Path("organization id") String organization id, 
@Path( 11terminal id11
) String terminal id, 
@Field("status 11
) String status 
) ; 
} 
Рисунок З .З - Лістинг коду опису запитів до АРІ 
43 
ЧДТУ.221818.007 ПЗ 
Опис запитів до АРІ для роботи з терміналами організації представлено на 
рисую,')' 3.3. Для реалізації мобільного клієнта використані методи АРІ для 
додавання нового терміналу, підтвердження терміналу, отримання списку 
терміналів підприємства, отримання даних про конкретний терміналі за його 
ідентифікатором і зміни даних терміналу. 
Після опису всіх запитів до сервера в інтерфейсі ServiceApi необхідно 
передати цей інтерфейс спеціальному класу, який обробить інтерфейс і згенерує 
Jroд запитів (рисунок 3.4). 
public static final String АРІ BASE URL = 
- -
"http://zaptimer-demo.redsolution.ru/api/vl/"; 
private static Retrofit .Builder builder = 
new Retrofit.Builder() 
.baseUrl(API BASE URL) 
- -
.addConverterFactory(GsonConverterFactory.create()); 
public static <S> S createService(Class<S> serviceClass) { 
OkHttpClient.Builder httpClient = new OkHttpClient.Builder(); 
OkHttpClient client = httpClient 
.connectTimeout(l0, TimeUnit.SECONDS) 
.build(); 
Retrofit retrofit = builder.client(client) .build(); 
return retrofit .create(serviceClass); 
Рисунок 3.4 -Лістинг коду генерації httр-запитів до АРІ 
Система збирання npoe1<my Gradle 
44 
ЧДТУ.221818.007 ПЗ 
В якості 1нстум енту для збірки npoercry був використаний Gradle, 
і'trrегрований в середовище розробки Andгoid Studio. 
i,uil ciscript { 
repositories { 
rnaven {url 'https://maven . fabric .io/public'} 
ma\ren {url 'http: І ldl .bintr ay . corn/amulyakhare/maven'} 
ciependeпcies {classpath 'io.fabric.tools:gradle:l.+'} 
} 
apply plugin : ' corn.android .application ' 
aD- -oly -plugin: ' io.faЬric ' -
repositories { 
ma\тen { url 'https: / /maven. fabric. io/public 1 
} 
apply plugin : ' com .google.gms.google-services' 
android { 
compil eSdkVersion 23 
ЬuildToolsVersion '' 23. О. 2" 
ciefaultConfig { 
applicationid "ru.redsolution.nataliabarabanschikova . zaptimer" 
minSdkVersion 16 
targetSdkVersion 23 
versionCode 2D 
versionNarne "0 .1.25" 
multiDexEnabled ї:rue 
buildTypes { 
release { 
rninifyEnabled fal se 
proguardFiles getDefaultProguardFile('proguard-android.txt'), 
'proguard-rules .pro ' 
} 
} 
Рисунок З .5 - Вихідний код конфігураційного файлу build.gradle 
Збірка проекту здійснюється середовищем розробки Andr·oidStudio 
lВТоматично у фоновому режимі на основі набору конфігураційних файлів (grаdlе­
:криптів на мові groove) . 
45 
-
ЧДТУ.22 1818 .007 ПЗ 
Інструмент Gгadle [17] значно спрощує процес управління залежностями 
додатку і його налаштування зі сховищем JCenteг, що дозволяє створювати різні 
варіанти збірок додатків. 
Конфігураційний файл build.gгadle містить дані про версії додатки, вимоги 
до версії Android. Відповідний фрагмент вихідного коду файлу конфігурації 
системи представлений на рисунок. 3.5. 
Файл конфігурації програми також визначає список використовуваних в 
додатку сторонніх бібліотек. Фрагмент вихідного коду файлу build.gradle 
розробляється зі списком використовуваних сторонніх модулів представлений на 
рисунок 3 .6. 
dependencies { 
cornpile ' com.android.support:appcompat-v7:23.1.1' 
compile ' com.android.support:design: 23.1.1' 
cornpile ' com. android. support : recyclerviei;,т--117: 23 .1.1' 
compile ' com.jaredrummler:android-device-names:1.0.5' 
compile ' сот. amulyak.hare: сот. amulyakhare. textdraw.able: 1. О .1' 
cornpile ' com.google.code.gson:gson:2.6.1' 
cornpile ' com.squareup.retrofit2:retrofit: 2.0.0-beta4' 
compile ' com.squareup.retrofit2:converter-gson:2.0.0-beta4' 
cornpile ' com.squareup.okhttpЗ:okhttp:3.1.2' 
compile ' i o.realm:realm-android:0.85.1' 
cornpile 'de. hdodenhof: circleimageviei,т: 1. З. О' 
compile "сот. google. android. gms: play-seлrices: 8. З. О" 
compile ( ' com. crashlyt ics.sdk.android:crashlytics: 2.5.S@aar') { 
t ransi t ive = t rue; 
} 
} 
Рисунок 3.6 - Вихjдний код конфігураційного файлу build.gradle 
3.3 Корисrувальницький інтерфейс 
Розроблений мобjльний додаток надає користувачеві два режими роботи -
режим зчитування ключів співробітників (термінальний режим) і режим 
mравління. 
46 
ЧДТУ.221818.007 ПЗ 
В режимі зчиrування додаток емулює роботу терміналу - додаток постійно 
знаходиться на foi·egi·oш1d (передній план) і не дозволяє запус1шти на цьому 
пристрої ніякі інші додатки. 
Головна функція програми в термінальному режимі - зчитування ключш 
співробітників і додавання записів в журнал відвідувань. Для виходу з 
термінального режиму необхідно перевести додаток в режим управління 1 
деактивувати термінал на пристрої. 
У режимі управління представлена функціональність для управшння 
сервісом - робота з підприємствами, співробітниками, ключами і терміналами. 
Головні функції програми в режимі управління - призначення NFС-ключів 
співробітникам або вимкнення ключів (видалення асоціації між ключем і 
співробітником). 
Em(11I ШН11,мя ПIJЛbJIJOD Н!ПЯ 
Пароль 
Забь,ли пароль? 
Рисунок 3. 7 - Екрани для авторизації користувача і активації терміналу 
47 
ЧДТУ.221818.007 ПЗ 
При запуску програми користувач може авторизуватися в серв1с1, 
використовуючи дані свого облікового запису, або активувати додаток як 
стаціонарний термінал. Для активації терміналу користувачеві необхідно ввести в 
додаток унікальний код для підтвердження терміналу, згенерований сервером. 
На основі унікального коду сервером буде визначена організація, якій 
належить термінал. Скріншоти екранів авторизації в сервісі і активації терміналу 
представлені на рисунок 3.7. 
Після успішної авторизації в сервісі Аndrоіd-додаток переходить в режим 
управління (рисунок 3.8). Разом з даними про обліковий запис користувача на 
мобільний додаток завантажуються дані про список організацій і ролях 
корис'І)'Вача в організаціях, дані про співробітників і асоційованих з ними NFС­
ключ1 . 
N)) Активировать терминал 
-... Орrанизоцня 
-•·•  Сотрудники 
□ Терминаль, 
е Профипь nользоеателя 
ш вь,йrи 
Рисунок З .8 - Навігаційна панель мобільного додатку 
48 
ЧДТУ.221818.007 ПЗ 
У режимі управління корисrувач може вибрати організацію і переглянути 
дані про реквізити організац1••1•,  сп1·в  б. · · б · · ~ 
ро ІТНИКІВ, термшали, ви равши ВJДПОВІДНИИ 
пун1(Т меню на навігаційній панелі (рис. 3.9).  
• Бара-t5анщикова Наталья 
С-,·.аршим r1pr.:it·p амм и:с т 
Вишняков П а вел 
C:rieциa1il: itcт SEO 
Владимиров Сергей 
nроrр,с1мм.:~~с т 
~. 
J~.'k ·_ ~-~ rерасименко Олеся 
,, 
~1 C-H{!,O)t<1:tp ло rарое-ю .[ІМ; 
Горшков А11 ексей 
Д·QЛ ЖНСІ СТІ\:> 
Зубакин Юри й 
Слеци311ист :S.EO 
Рисунок 3.9-Екрани для перегляду списку співробітників 
Для управшння NFС-ключами співробітників необхідно вибрати 
~ідповідного співробітника зі списку всіх співробітників підприємства, перейти до 
Ірофілю співробітника, вибрати пункт меню «прив'язати ключ» на панелі AppBar і 
юкласти NFС-ключ до пристрою . 
49 
ЧДТУ.221818.007 ПЗ 
На основі даних про ключі та співробітників підприємства, збережених в 
локальній базі даних програми, буде зроблено висновок про те, чи належить цей 
JСЛ10Ч одному зі співробітників організації або ключ вільний, і запропоновано 
відповідну дію корисrувачеві. Діалоги прив'язки / відв'язування ключів наведені 
на рисунок 3.1 О. 
У режимі управління досrупна опц1я спрощеної активац11 терміналу, 
мт,mаючи процес створення унікального коду в веб-інтерфейсі та введення його в 
додаток. При активації терміналу з режиму управління корисrувач може вибрати 
один з дос'І)'ПНИХ режимів роботи терміналу - мобільний або стаціонарний 
(рисунок 3.11) . 
ключ уже используется 
НОВЬІЙ КЛЮЧ 
І\,tокероо Олег 
• 
Идент11фика1ор: З•1С28729314266 
К/ІЮ\І уже щ:ПОJJt,Зуется ;1 не МОЖ('Т 
Идентифик.~тор : З482Е47 І FD2166 бь-пь пр1t6113Я!-і к еt>16ра1111 ому 
соvр}1днику. 
Пр1~в112ан, а101 КJ1юч к ;•четно іі 
заr1ис1, со І;J}•дник.(' Отоязоть 1<люч? Mattepoв Oncr 
больше не- сможет нспол~зовать 
О rr •1 н... ПР~ШЯЗАТЬ КЛЮЧ его дл:.1 рнистр,щ11 11. 
1 ',1 · 1\ ОТВЯЗАТІ, КЛЮЧ 
Рисунок З .1 О - Діалоги для призначення ключа співробітнику і деактивації ключа 
50 
-
... 
ЧДТУ.221818 .007 ПЗ 
Залежно від режиму роботи терміналу деякі налаштування або background­
cepвicи, що запускаються додатком, можуть бути відключені. 
Мобільний термінал передбачає використання особистого Аndrоіd­
пристрою менеджера або власника підприємства і працює в режимі управління. 
JJpн зчитуванні NFС-ключа користувачеві буде показано діалогове вікно з 
інформацією про статус події. 
При виході з режиму управління мобільний терм1нал стає активований. 
використання мобільного терміналу може бути виправдане на рухомих 1 
просторових робочих місцях для контролю співробітників. 
а .... rJ ~ ~. (> ._,_. "о/' • :І 50·· _ ~ ,:.i.:iб 
,,,, '~ І ' 
. ~ Актива.ц.и:R те'ііминала 
, . · ... 
В l.ackWater І n с. 
О СТацион арн ь1 й .,, 
C'f [il ~.tl.)I 1;)ІJ•І nl ~ · 'f<('f}І,'1~ І•Іі)1q L1J)e;/4Гl(ІJ!,fLГf~ c,' 
n,:;c r.::-;::;нноо<J nvДЮ1ІОЧ~н11с к а .i рядному 
1 строй.-:тв-у. ра бо rает ,: вr.:ег; i.a 
r 1кІІІ<)чсІІИt,ІМ ,:~щ·1 ;:1н◊м, ifJ}l'I І)tЇ if.,JfJY)Щ},t ,Щ 
нas. ::iro 1<n10·-ш со-и:дника nр::,1,с к,,щит 
ае:щ-ман11 1е<:~.:и,➔ ВЬlХОД ПО1Н::?іОВиТе1151 \ІІЗ 
рс:,,:11м:;J )'Пr:Н~fl(:'Шlfl. 
ЛК І Иt:,ИІ •І;В/•. І І:, І !:. І 1МИ і і Л.І І 
Рисунок З .11 - Екран для активації терміналу через режим управління 
51 
ЧДТУ.221818.007 ПЗ 
Стаціонарний термінал п б · · ~ 
еред ачає, що Аndrо1d-пристрш працює автономно 
без людського втручання (наприклад, розташований на вході в офіс підприємства). 
У зв'язку з тим, що зчитування NFС-карт можливо тільки при включеному і 
незаблокованому екрані пристрою з міркувань безпеки, при активації 
стаціонарного терміналу в додатку запускається сервіс, який відповідає за 
своєчасне розблокування екрану. 
Мобільний додаток може працювати з NFС-картками співробітників і при 
відсутності доступу до мережі Інтернет. Дані журналу про зчитування ключів 
співробітників зберігаються перед відправкою на сервер в локальній базі даних 
програми. 
Якщо з якої-небудь причини (відсутність з'єднання з сервером, відсутність 
Інтернет-з'єднання і т.д.) дані про зчитування ключа не вдалося вщправити 
своєчасно, то буде зроблено і відображено попередній висновок про статус 
зчи'І)'вання ключа на основі локальних даних програми. 
Після чого додаток ініціює запуск сервісу, що працює у фоновому режимі, 
який буде регулярно, з періодичністю в п'ять хвилин намагатися синхронізувати 
локальну базу даних з накопиченою інформацією про ключі співробітників з 
центральною базою даних на сервері. Після успішного відправлення накопичених 
даних на сервер, фоновий сервіс завершує роботу. 
В результаті розроблено мобільний додаток на базі операційної системи 
Android. Розроблений додаток повюстю задовольняє функціональним 1 
нефункціональним вимогами, що пред'являються до системи. 
3.4 Тесrування сервісу 
Процес тестування, як окремий етап, має свій життєвий цикл. Життєвий 
цикл тестування є частиною життєвого циклу програмного забезпечення, і вони 
повинні синхронізуватися один з одним. Проектування та розробка тестування 
може бути настільки ж складним і трудомістким завданням, як і розробка самого 
програмного продукту. 
У випадку не виконання тестування разом з першими верс1ями програмного 
забезпечення багато неполадок будуть виявлятися на більш пізніх стадіях 
' 
52 
ЧДТУ.221818.007 ПЗ 
розробки. 
Часто внаслідок даних д~•.и., .., 
випуск продукту відкладається через довгии 
період виправлення помилок програми, що практично зводить нанівець переваги 
ітеративної розробки. 
Ітерація - завершений цикл розробки, що приводить до випуску кінцевого 
продукту або деякої скороченої версії, яка розширюється від ітерації до ітерації, 
щоб, врешті-решт, стати закінченою системою. 
Детальна схема життєвого циклу тестування. 
Стадія 1 ( планування тестування) - необхідна для того, щоб отримати 
відповіді на наступні питання: що не належить тестувати; як багато буде роботи; 
які є складності; чи все необхідне є для проведення роботи. Як правило, отримати 
відповіді на дані запитання неможливо без аналізу вимог, тому що саме вимоги є 
первинним джерелом відповідей. 
Стадія 2 (уточнення критеріїв) - дозволяє сформулювати або уточнити 
метрики та ознаки можливості або необхідності початку тестування, припинення 
та поновлення тесrування, завершення або припинення тестування 
Стадія З (уточнення стратегії тестування). На цій стадії розглядаються 1 
уточняються частини стратегії тестування, які актуальні для поточної ітерації. 
Стадія 4 (розробка тест-кейсів) - присвячена розробці, перегляду, 
уточненню, доопрацюванню, переробці та іншим діям з тест-кейсами, наборами 
тест-кейсів, тестовими сценаріями та артефактами, які будуть використовуватися 
при безпосередньому виконанні тестування. 
Стадія 5 (виконання тест-кейсів) та стадія 6 (фіксація знайдених дефектів) 
тісно пов'язані між собою і фактично виконуються паралельно. Дефекти 
фіксуються відразу по факту їх виявлення в процесі виконання тест- кейсів. 
Однак, найчастіше після виконання всіх тест-кейсів і написання всіх звітів про 
знайдені дефекти проводиться явно виділена стадія уточнення, на якій всі звіти 
про дефекти розглядаються повторно з метою формування єдиного розумшня 
проблеми та уточнення таких характеристик дефекту, як важлив1сть 
терміновість. 
53 
ЧДТУ.221818.007 ПЗ 
Стадія 7 (аналіз результатів тестування) та стадія 8 (звітність) також тісно 
пов'язані між собою та виконуються практично паралельно. Сформульовані на 
стадії аналізу результатів висновків безпосередньо залежать від плану тестування, 
критеріїв приймання та уточненої стратегії, отриманих на стадіях 1, 2 і З. 
Отримані результати оформляються на стадії 8 та є основою для стадій 1, 2 і З для 
наступної ітерації тестування. Таким чином, цикл замикається. 
Тестування RESTА РІ  
Тестування методів REST-cepвicy проводилося з використанням 
автоматизованих засобів тесrування. Для написання модульних тестш 
застосована бібліотека django-unit-tests [14] . 
Бібліотека для автоматизованого тестування включає в себе наступю 
елементи: 
TestCase - модуль тестування. Перевірка валідності вщповщ1 для 
певного набору даних; 
- TestSuite - містить в собі тести, які повинні бути запущені разом; 
TestFixture - містить в собі попередні налаштування для тестш 
(з'єднання з базою даних, створення тимчасових директорій); 
TestRunner/Loader - модуль, що запускає тести 1 виводить результати 
тестування в потрібному форматі. 
Для кожного методу АРІ REST-cepвicy написаю модулью тести, що 
покривають всі можливі варіанти використання кожного методу. Кожен метод АРІ 
протестований на розмежування прав доступу, на що повертається відповідь і http­
кoд сервера. Кожен метод АРІ при тестуваню виконаний вщ 1мею 
неавторизованого користувача, авторизованого користувача, що не входить в 
організацію, співробітника організації, власника, менеджера 1 термшалу 
підприємства. 
Дані, що передаються в метод АРІ, перевірені на валідність, на відповідність 
рекомендованій в документації та формату. 
На рисунку 3 .12 представлений приклад реалізації TestCase для тестування 
Методу АРІ додавання нового співробітника в сервіс. 
54 
ЧДТУ.22 1818 .007 ПЗ 
response = self . client .post (url , data=data ) 
self .assertEqual (response.st at us code, 401) 
self.aesl fs eortrE qua. l (Em. ployment.obJ'ect . ( 
5 s.us1ng 
• ganization .database_name) .al l() . count(), О) 
login = sel f. client . l ogi n(username=self.USER USERNA.МE, 
pass\vord=self . PASSWORD) 
self . assertтrue(login ) 
response = self .client .post (url, data=data) 
self .assertEqual (response.status code, 403) 
self .asser tEqu~l(Employment .object s.using( 
sel ~.or gan1zat ion.dat abase name) .all() .count(), О) 
self .cl i ent.logout () -
l ogin = sel f.client .login(username=self.ORG USER USERNAМE, 
paSS\vord=self. PASSWORD) 
self.assertтrue{login) 
response = self.client .post (url, data=data) 
sel f.asse r tEqual(response.status code, 403) 
sel f . assertEqual(Employment .object s.using( 
sel f.organization .dat abase name) .all() .count(}, О) 
self.cl ient.logout() -
login = sel f.client.login(username=self.ORG TER~INAL USERN.Al'1E, 
password=self.PASSWORD) 
self.assertтrue(login) 
response = self.client .post (url, data=data) 
sel f.assertEqual{response.status_code, 403) 
self.assertEqual(Employment .objects.using( 
sel f .organizat ion.database name) .all() .count(}, О) 
self .client. logout () 
l ogi n = self. client .login(username=self.ORG OWNER USERNAl\.1E , 
password=self. PASS\iORD) 
self.assertTrue (login) 
response = self . clien~ .pos~ (url , dat a=data) 
Рисунок 3.12 - Тестування методу АРІ для додавання нового співробітника 
Для моделювання НТТР-запитів до сервера був використаний тестовий 
І<Лієнт, представлений класом Client в бібліотеці django-unit-tests. Тестовий клієнт 
55 
► 
ЧДТУ.221818.007 ПЗ 
дозволяє емулювати POST, GET, РАТСН, DELETE запити на задану URL-aдpecy 
та обробляти відповідь сервера [15]. 
В результаті тестування методів АРІ вс1 написаю модулью тести для 
кожного RЕSТ-методу пройдені успішно. Також зібрана статистика, згідно з якою 
загальне покриття коду модульними тестами становить 78%, що говорить про 
досить хорошу надійності реалізованих методів. 
Тестування мобільного додатку 
Тестування програмного забезпечення охоплює цілий ряд видів діяльності. 
До них входять: постановка задачі для тесту, проектування, написання тестів, 
тестування тестів і, нарешті, виконання тестів і перегляд результатів тестування. 
Вирішальну роль відіграє проектування тесту. 
Тестування для користувача інтерфейсу розробленого мобільного додатка 
проводилося вручну. 
Для проведення тестування програми використано сервіс Crashlytics [19]. 
Даний сервіс дозволяє поширювати додаток серед користувачів, обраних автором 
програми шляхом зазначення їх email-aдpec для відправки запрошень вступити в 
ряди тестувальників. Сервіс моментально оповіщає про «зависання» додатків на 
пристроях користувачів, формує звіти і статистику (рисунку 3.13). 
✓ ) (r,s~l)1J(S .!: о ф 
ф t · :t,.11 с- wІIDrf' І] 
., (...,.•:.fi:.:. u 
V....,., 11 І 
(. 
♦ 
Ct• ...... Q 
__..,,,.....-, --4)'.l {:.,.t:,., І І 
- ··" .. .І- ,.,i... .. .. • ... .. ,....~ .... . ,.. 
i.,....-,tp,"-4м 1,.:s.! ...... 
- f J,.. f 1' ~,&.J -.:.1-11• ,,. . , . :.j, ......,  .... ,.,., 
.. 
Рисунок з .13 _ Статистика «зависань» додатка в сервісі Crashlytics 
56 
-
ЧДТУ.221818.007 ПЗ 
З використанням серв · С 
icy 1·asl1lytics знайдено безліч помилок, що 
виникають при експлуатації додатку, запущеного на реальному, призначеному для 
корисrувача, пристрої. 
Інтеграційне тестувают сервісу 
Кожна складна програми а система складається з окремих частин - модушв· , 
які виконують різні функції в складі системи. Для впевненості у коректній роботі 
системи в цілому,  потр~' б но спочатку протестувати окремо кожен модуль 
програмної системи. У випадку • 
виникнення дефектш це дозволить набагато 
простіше виявити модулі, які викликали проблему, та повністю усунути відповідні 
дефекти. 
Для проведення тестування спільної роботи мобільного клієнта і сервера 
проведено інтеграційне тестування сервісу. Основне завдання інтеграційного 
тестування - пошук дефектів, пов'язаних з помилками в реалізації та інтерпретації 
інтерфейсної взаємодії між модулями. 
В результаті проведення інтеграційного тестування виявлено, що розроблені 
окремо компоненти коректно взаємодіють один з одним, представляючи собою 
єдиний продукт. 
Приймальне тестування 
Розроблений сервіс був впроваджений у досшдну експлуатацію на 
підприємстві. Для тестування сервісу були залучені реальні співробітники, що 
працюють на даному підприємстві. Протягом 4 місяців співробітники щодня 
фіксували час початку/закінчення робочого дня, час початку/закінчення перерви. 
В ходІ проведення тестування виявлені кілька вузьких місць в роботі 
сервісу, одним з яких є можливІсть втрати Інтернет-з'єднання в мобільному 
додатку, що неминуче призводить до втрати даних про ключі співробітників. 
Інший виявлений істотний недолік в роботі сервісу обліку часу полягав в 
особливості роботи NFС-зчитувача на смартфоні - смартфон здатний зчитувати 
NFС-ключі співробітників тільки при включеному і незаблокованому екрані. 
Прийняті відповідні заходи щодо усунення всіх знайдених вузьких місць в роботі 
сервісу - розширені функціональні вимоги, змінені пріоритети завдань в 
57 
ЧДТУ.221818 .007 ПЗ 
реал ізації сервісу. 
Після усшшного 
проведення приймального тестування серв1с був 
11ереведений в промислову експлуатацію ва підприємстві. 
Проведено модульне тестування окремих компонентів сервісу, інтеграційне 
тестування для перевірки коректності спільної роботи компонентів сервісу та 
rтриймальне тестування сервісу на базі підприємства. 
Після успішного проходження всіх вищеописаних видів тестування сервіс 
був впроваджений в промислову експлуатацію. 
Для ідентифікації співробітників призначені ключ~ з NFС-мітками. 
Прикладами таких ключів є карти метрополітену, банківські картки, смартфони з 
технологією NFC, брелки від вхідних дверей. Використовуючи свій NFС-ключ, 
співробітник відзначається на терміналі кожен раз, коли покидає або повертається 
на територію офісу. 
Терміналом є найпростіший смартфон, оснащений NFС-зчитувачем, з 
встановленим додатком. Термінал зчитує дані ключів, обробляє і відправляє дані 
на сервер. 
Переглянути інтерактивний графік з табелем відвідуваності співробітників 
можна у веб-інтерфейсі сервісу. На основі графіка відвідувань для кожного 
співробітника буде згенеровано табель обліку робочого часу, а також зібрана 
статистика по всіх порушеннях. 
Ключовими перевагами сервісу є швидке впровадження, доступюсть 
обладнання та дешевизна експлуатації. Ці аспекти роблять можливим 
використання сервісу на будь-якому підприємстві, навіть з досить малою 
кількістю співробітником (близько 1О  осіб). 
58 
ЧДТУ.221818.007 ПЗ 
ВИСНОВІ(И 
У даній кваліфікаційній роботі запропоновано інноваційне рішення 3 
Розробки хмарного сервісу контролю робочого часу, засноване на використанні 
сучасної технології комунікації ближнього поля NFC. Вивчені інші технології 
бе3контактної передачі даних iBeacon і EddyStone. Виконано дослідження щодо 
прое1'.'1Ування систем управлінського обліку та моніторингу результатів діяльності 
працівників. 
Актуальність та доцільність створення визначених інформаційних систем 
доведено на основі аналізу наукових праць та практичних потреб організацій в 
функціонально-програмній реалізації функцій менеджменту на всіх рівнях 
управління діяльністю працівників. 
Проведено дослідження з пошуку аналогічних вже існуючих рішень для 
хонтролю і обліку робочого часу, розглянуті їх основні характеристики і 
призначення, а також виявлені принципові недоліки. 
У роботі також дано детальний опис створеного серв1су, сформульовані 
функціональні та нефункціональні вимоги до розроблюваної системі. Виявлені 
основні актори, які взаємодіють з системою, і дії, які можна здійснювати над 
системою. На основі цих даних побудована діаграма прецедентів, а також дано 
детальний опис кожного зазначеного на діаграмі актора і прецеденту. Розроблено 
UМL діаграми, та алгоритми роботи системи. 
В ході роботи виявлено сучасний стан інформаційних систем обліку, 
моніторингу та безпосередньо табельного обліку. Проведено порівняльний аналіз 
розроблюваної системи та аналогів з метою визначення її переваг, що доводять 
доцільність створення продукту. До основних переваг системи відносить 
спрямованість на конкретну організацію та комплексність використання. 
Спроектована архітектура системи, що складається з трьох основних 
компонентів: сервер гри, мобільний додаток і REST-cepвic. Всі компоненти є 
слабо зв'язані, і зміна одного з них не впливає на інші . 
В результаті виконана реалізація всіх компонентів серв1су відповідно до 
функціональних та нефункціональних вимог, які пред'являються до системи. У 
59 
ЧДТУ.221818.007 ПЗ 
rомУ числі реалізований REST-cepвic, що надає необхідний REST АРІ для роботи 
кл ієнтських додатків. Проведено модульне тестування компонентів сервісу, 
jJ{теградійне тесrування для перевірки спільної роботи компонентів і приймальне 
тес1)'вання. 
Практичне значення результатів дослідження полягає в дослідженні 
поведінкових та функціональних моделей ведення управлінського обліку, 
моніторингу та можливості їх запровадження на підприємстві. 
60 
ЧДТУ.221818.007 ПЗ 
СПИСОК ВИКОРИСТАНИХ Д)І(ЕРЕЛ 
Ан1у Вгоwв ашd Gi·eg Wilsoп Tl1e Aгcl1itectuгe of Open Source Applications -
202 1. - 121 р. 
АРІ Sei·veг [Електронний ресурс] Режим доступа: 
l1ttps ://www.c1·ossbase.de/DE/DE/loesungeп/datenbereitstellung/api-server. 
Gwyпne Richards Waгehous management: А Complete Guide to Improving 
Efficiency and Minimizing Costs in the Modem Warehouse-2017. - 250 р. 
Intemational Testing-Board Testautomatisierung Definition, Tutorial und Artikel 
Testautomatisierung [Електронний ресурс] / Code Project - Режим доступу до 
ресурсу: https://www.testing-board.com/testautomatisierung. 
Marc Unger 50 Dropship & Wholesale Vendors: Dropshipping List (Drop 
Shipping & Wholesalers Book 1) - 2020, 500 р. 
Realm Studio [Електронний ресурс] / Ве moreproductive with Realm Studio -
https :/ /realm. і o/products/realm-studio. 
SAP [Електронний ресурс] / Developer Overview - Режим доступу до 
ресурсу: https://www.sap.com/index.html. 
Брайан К. Практика программирования. / Б. Керниган, Р. Пайк. Пер. с англ. -
Вінниця: РВВ ВНАУ, 2019. -217 с. 
Войтко В.В. Комбінований метод пошуку оптимальних рішень з 
використанням засобів теорії графів / В.В. Войтко, С.В. Бевз, С.М. Бурбело, 
О.В. Гавенко // Оптико-електронні інформаційно-енергетичні технології. -
№ 2 (16). - 2008. - с. 67-70. 
О Гарсиа-Молина Г. Системь1 баз данньrх. Полнь1й курс І Г. Гарсиа-Молина, 
Дж. Ульман, Дж. Уидом. - Вінниця : РВВ ВНАУ, 2013. - 1088 с. 
1 Гильманов А.А. Карткові технології в автоматизації маркетингу. Вінниця : 
РВВ ВНАУ, 2020. -379 с. 
2 Коваленко Е.А. Методология проектирования информационнЬІх систем 
организации - концепция двух зеркал / Е.А. Коваленко // Вінниця: РВВ 
ВНАУ. - 2019. - № 4. - С. 38-41. 
61 
ЧДТУ.22 1818.007 ПЗ 
13 Коваленко О •О  . К онцепц1·я  створення мережевого 1· н ф ормащ•иvн ого 
середовища управління комnан1єю / О.О. Коваленко // Вісник 
Хмельницького національного університету. - 2016. - № 1, том 2. - С. 21-26. 
14 Коваленко О.О. Необхідність впровадження інформаційних технологій та 
програмного забезпечення на підприємстві / О.О. Коваленко // Соціально­
економічні, політичні та культурні оцінки і прогнози на рубіжі двох 
тисячоліть: - Тернопіль: ТНУ, 2019. - С. 416-418. 
15 Коваленко О.О. Створення інформаційного середовища підприємства для 
якісного прийняття управлінських рішень/ О. О. Коваленко// Регіональна 
перспектива. - 2019. -№2-3 (27-28). -С.121-128. 
16 Коваленко О.О. Сучасні тенденції управління інформаційними ресурсами 
підприємства/ О.О. Коваленко // Методологія та практика менеджменту у 
ХХІ столітті: загальнодержавні, галузеві та регіональні аспекти: матеріали 
VI Міжнародної науково-практичної конференції 26-27 квітня 2019 р. 
м. Полтава. -Полтава : ПУЕТ, 2019. -С. 368-370. 
17 Коваленко О.О. Теорія інформаційних взаємодій на підприємстві / 
О.О. Коваленко // Збірник наукових праць ВНАУ. - Вінниця : РВВ ВНАУ, 
2020. -Вип. 5. - Т. 3. - С. 156-159. 
18 Маклаков С.В. Моделирование бизнес процессов с BPwin 4.0 М.: Диалог 
МИФИ, 2020. - 124 с. 
19 Модульне тестування (Unit testing) [Електронний ресурс] / Qalight 2021 
Режим доступу до ресурсу: http://lviv.qalight.corn.ua/Ьaza-
znan/modulnetestuvannya. 
20 Островерха Р.Е. Організація обліку: навч. посіб. / Р.Е. Островерха. - К.: 
Центр учб. л-ри, 2019. - 568 с. 
21 Потриваєва Н.В. Стан та перспектива обліку праці: теоретичний аспект І 
Н.В. Потриваєва, І .В. Савченко// Економічний форум. - 2019. - №1. - С. 93-
98. 
22 Роб П. Системь1 баз даннь1х: проектирование, реализация и управление / 
П. Роб, К. Коронел. - Вінниця: РВВ ВНАУ, 2018. - 1040 с. 
62 
Ч)\Т . 21818.007 111 
23 Семко Л.Л. онсршснстнованнс тр J\a т, ТІJЮМJ)ТНІJІеJtrн,,х JІрс1трияпrях І 
Л.А. Семко // 1lі)1.прнсмстно, 1·0 'ІЮ)Щр ·тно і нрнrю . 201 7. № 4. '. 135-
136. 
24 Сок-олов В.10. 1нформt-щійні сн •т~ми тсхтtо1ю, ·ії: Т Jав1rалr,ний посібник -
Кнї-в Д~ 11{1~ - Ot 9. 34 t с. 
63 
ЗЛТВ І ~Р Д)КПІ 10 : 
Зао. кафс;\рою ПЗЛС, професор 
~Первунінський С.М. 
,,_2_ О"  __.....::....t..J.Jc і:;:__ _ ___  2022 р. 
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ КОНТРОJПО РОБОЧОГО ЧАСУ 
СШВРОБІТНИКІВ ШДПРИЄМСТВА 
Специфікація 
482. ЧДТУ 221818.007 
Листів 2 
1озробник Мартинюк В.А. 
Серівник Катаєва Є.Ю. 
2022 рік 
64 
482. ЧДТУ 22 18 18.007 
Позначення 
Наймснуnання Примітка 
482.ЧДТУ._2 1 18-О l 12 О 1 Текст програми 
48-.ЧДТ .221 818-01 34 01 Інструкція користувачеві 
482.ЧДТ .221818-019001 -
Графічні матеріали 
65 
ДОЛАТОl Б 
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ КОІ-ТТРОJПО РОБОЧОГО ЧАСУ 
СШВРОБІТНИКІВ ШДПРИЄМСТВА 
Текст програми 
482.ЧДТУ.221818-01 12 01 
Листів 8 
Розробник Мартинюк В.А. 
Черкаси,2022 
66 
482.ЧЛ.Т .22 1818-0 1 12 01 
2 
Ne\oJ_ tabel 
#include <vcl . 11 
#include ComObj . hpp> 
#include <utilcls .h> 
#pragma hdrstop 
#include " Ne\v_tabel uni t . h " 
#iпclude "Arhiv unit.h " 
#include " Calendar_ arhiv unit .h" 
#include " Zvit unit . h " -
#include " Image unit . h " 
#include " Poznach unit . h" 
-/-/--------------------------- ----------------------------------------------
#pragma package(smart init) 
#pragma resource " * . dfm" 
TNew- tabel *New- tabel·,  
Variant rnExcel , Арр, Sh ; 
oid _ fastcall TNew_tabel : : ButtonlClick(TObject *Sender) 
{ 
Tablel->First () ; 
Arhiv- >Tablel->First() ; 
for ( int і=О; i<Tablel->RecordCount ; і++) 
{ 
Arhiv->Tablel->Insert(); 
Arhiv->TablelNorner->Value = TablelNomer->Value; 
Arhiv- >TablelPIB->Value = TablelPIB->Value; 
Arhiv->TablelPosada->Value = TablelPosada->Value; 
Arhiv- >TablelStaty- >Value = TablelStaty->Value; 
Arhiv->TablelDl - >Value = TablelDl->Value ; 
Arhiv->Table1D2->Value = Table1D2->Value; !l13 
Arhiv->Table1D3->Value = TablelDЗ->Value; 
Arhiv->Table1D4->Value = Table1D4->Value ; 
Arhiv->TablelDS->Value = TablelDS- >Value; 
Arhiv->Table1D6- >Value = TablelDб->Value; 
Arhiv->Table1D7->Value = Table1D7- >Value ; 
Arhiv- >Table1D8->Value = Table1D8->Value; 
Arhiv->Table1D9->Value = Table1D9->Value ; 
Arhiv->Table1D10->Value = TablelDl0->Value ; 
Arhiv->TablelDll->Value = TablelDll->Value; 
Arhiv->Table1D12- >Value = Table1Dl2->Value ; 
Arhiv->Table1D13->Value = TablelD13->Value ; 
Arhiv->Table1D14->Value = TablelD14 - >Value ; 
Arhiv->Table1D15->Value = TablelD15->Value ; 
Arhiv - >Table1D16- >Value = TablelDlб->Value ; 
Arhiv->TablelD17->Value = TablelD17->Value ; 
Arhiv->Table1D18->Value = Tablel018->Value; 
Arhiv->Table1D19->Value = Table1D19- >Value ; 
Arhiv->Table1D20->Value = TablelD20->Value ; 
Arhiv->Table1D21->Value = TablelD21->Value ; 
Arhiv->Table1D22->Value = TablelD22->Value ; 
Arhiv->TablelD23->Value = Table1D23->Value ; 
67 
48- .ЧДТ .22 18 18-01 12 О І з 
Arhiv- >Table1D2 4- Value = Table1D2 4->Value; 
Arhi v->Table1 D25- Value ~ TablelD25->Value ; 
Ar h iv->TablelD26- Value = Table1D26->Value; 
Arhiv- >TablelD27 ->Value = Tablel027->Value; 
Ar hiv- >TablelD28->Value = Tablel028->Value ; 
Arhiv->Table1D29->Value = Table1D29->Value; 
Arhiv->TablelDЗO->Value = TablelDЗO->Value; 
Arhiv->TablelDЗl->Value = TablelDЗl->Value; 
Arhiv- >TablelKilkisty d->Value = TablelKilkisty d->Value ; 
Arhiv- >TablelUrochno d->Value = TablelUrochno d=>Value ; ! 114 
Arhiv- >TablelBD- >Value = TablelBD->Value ; -
Arhiv- >Tab lelH- >Value = TablelH->Value ; 
Arhiv- >Ta ble lBZ - >Value = TablelBZ->Value ; 
Arhiv ->Tab l e lB- >Value = TablelB->Value ; 
Arhiv- >Tabl e lTH - >Value = TablelTH- >Value ; 
Arhiv- >Table lDO- >Value = TablelDO- >Value ; 
Arhiv- >Table lBP- >Value = TablelBP- >Value ; 
Arhiv- >Tabl elDD- >Va lue = Tablel DD- >Value; 
Arhi v - >TablelPa zom- >Value = Tabl elPazom- >Value; 
Arhiv->TablelММRRRR->Value = TablelMMRRRR- >Value ; 
Arh i v - >Table lRik- >Value = Tab l elRik- >Val ue; 
Arhiv- >Tabl el->Post() ; 
Tabl e l - >Next () ; 
Arhiv- >Tablel - >Next() ; 
} 
Tablel - >First() ; 
Arhiv- >Table l - >First () ; 
ShоwМеssаgе( "Даніуспішнозбережені " ); 
) 
//--- ----------- ------- - - -------- -------------------- --------
void fas tcall TNew tabel : :StringGridlDrawCe ll{TObject *Sender , 
int 
ACol , 
int ARow, TRect &Rect , TGrid DrawState State ) 
{ 
Ans iStri n g Х ; 
X=StringGridl - >Cells[ACol] [ARow) ; 
і f ( х == ІІ - ff ) { 
StringGr idl- >Canvas - >Brush- >Color=clRed ; 
StringGridl - >Canvas - >FillRect(Rect) ; 
stringGridl->Canvas->Tex tOut(Rect. Left , Rect . Top , StringGridl­
>Cells [ACol] [ARow)) ; ! 115 
) 
i f (Х == " / " ) { 
St r ingGridl - >Canvas->Brush->Color=clBlack; 
StringGridl->Canvas->FillRect(Rect ) ; 
StringGridl - >Canvas->TextOut(Rect . Left , Rect . Top , StringGrid l­
>Ce ll s [ACol) [ARow)) ; 
} 
} 
// ---------- --------- ------------------ - -----
68 
482.ЧДТ .2218 18-0 t 12 О t 4 
void _fastcal l TNe w_ tab l :: Button7Click(TObject *Sender) 
{ 
AnsiString sFile = GetCurre11tDir()+ 11 \\tabel .x lsx 11
; 
//инициализи У мЕхсеl , открwваемзтотшаблон 
App=Variant:: CreateObject( " Excel .Applicatioп 11 ); 
Арр · OlePropertyGet ( "WorkBooks 11
) • OleProcedure ( 11 Open 11
, s ~ile . с _ s tr ( 
) , 
0,false,1 ) ; 
Sh=App. OlePropertyGet ( "trvorkSheets " , 1); 
//записзtаЬlе 
Tablel->First() ; 
Tablel - >Next () ; 
for ( int і=4; i <Tablel ->RecordCount+4 ; і++) { 
toExcel(App, і, 1, TablelNomer->Value) ; 
toExcel(App, і, 2, TablelPIB->Value) ; 
toExcel(App, і, 4, TablelPosada->Value) ; 
toExcel(App, і, 5, TablelStaty->Value) ; 
toExcel(App, і, б, TablelDl- >Value) ; 
toExcel(App , і , 7 , Table1D2->Value); 
toExcel(App, і, 8 , Table1D3- >Value) ; 
toExcel(App , і, 9 , Table1D4 - >Value); 
toExcel (App , і, 10, Table1D5- >Value); 
toExcel(App, і, 11, Table1D6- >Value); !116 
toExcel(App, і, 12, Table1D7 ->Value) ; 
toExcel(App , і, 13, Table1D8 ->Value); 
toExcel(App, і, 14, Table1D9->Value); 
toExcel(App , і, 15, Table1D10->Value); 
toExcel(App, і , 16, TablelDll ->Value); 
toExcel(App, і , 17 , Table1D12 - >Value); 
toExcel (App, і , 18 , Table1D13->Value); 
toExcel (App , і , 19, Table1D14->Value); 
toExcel (App, і , 20 , Table1D15->Value); 
toExcel (App , і , 22 , Table1D16->Value); 
toExcel(App , і , 23 , Table1D17 ->Value); 
toExcel (App , і , 24 , Table1D18 - >Value); 
toExcel(App , і , 25 , Table1D19- >Value); 
toExcel (App , і , 26 , Table1D20- >Value ); 
toExcel (App , і , 27 , Table1D21->Value); 
toExcel (App , і , 28 , Table1D22- >Value) ; 
toExcel (App , і , 29 , Table1D23->Value) ; 
toExcel (App , і , ЗО , Table1D24 - >Value) ; 
toExcel(App , і , 31 , Table1D25->Value) ; 
toExce l(App , і , 32, Table1D26->Value) ; 
toExce l(App , і , 33 , Table1D27->Value) ; 
toExce l(App , і, 34 , Table1D28->Value) ; 
toExcel(App , і , 35 , Table1D29->Value) ; 
toExcel(App, і , Зб , TablelDЗ0->Value) ; 
toExcel(App, і , 37 , Table1D31->Value) ; 
toExcel(App, і , 38 , TablelKilkisty_ d->Value) ; 
toExcel(App, і , 39 , TablelUrochno_d->Value) ; 
toExcel(App, і , 40 , TablelBD->Value); 
toExcel(App , і , 41, TablelH->Value) ; 
toExcel (App, і , 42, TablelBZ->Value) ; 
69 
482.Ч.ДТУ.22 1818-01 12 О І 5 
toExcel (App, і , 44, TablelB->Value) ; !11 7 
toExcel(App, і , 44, TablelTH->Value) ; 
toExcel(App, і , 45, TablelDO->Value); 
toExcel(App, і , 4 6 , TablelBP->Value); 
toExcel(App, і , 4 7 , TablelDD->Value); 
toExcel (App, і, 48, TablelPazom->Value); 
Tablel->Next () ; 
} 
App . OlePropertySet ( " Visible", тrue) ; 
} 
//--------------------------------------------------------------
Data vubir 
void _fastcall TData_vubir :: Buttonl Click(TObj ect *Sender) 
{ 
if (DBLookupCornboBoxl - >Text=="" ) 
Application->MessageBox("Bибepiть 
місяць!","Увага!",МВ_ІСОNWАRNІNG); 
else 
if (CornЬoBoxl ->Text=="" ) 
Application->MessageBox("Bибepiть 
piк!","Yвaгa!",MB_ICONWARNING); 
else 
{ 
//перевіркачивжестворенийтабельнаданудату 
bool flag = false ; 
int denya=l; 
Edit2 - >Text=""; 
Tablel->First(); 
Editl->Text= CornЬoBoxl->Text; 
Edit2->Text=(DBEditl ->Text+Editl->Text); 
Arhiv->Tablel->First(); 
for (int і=О ; і< Arhiv->Tablel->Rec ordCount ; і++) !11 8 
{ 
if (Edit2->Text == Arhiv->TablelMMRRRR->Value) 
{ 
ShоwМеssаgе( "Табельнаданиймісяцьірікіснує"); 
//flag = true; 
denya=2; 
break; 
} 
Arhiv->Tablel->Next () ; 
} 
//Перевіркачистворенийтрудвовийкалендар 
if (denya == 1) 
{ 
String а= Edi t2 - >Text; 
Calendar arhiv->Tablel->First() ; 
for (int-i=O; і< Calendar_arhiv->Table l->RecordCount ; і ++ ) 
{ 
if( a== Calendar arhiv->Ta blelMMRRRR->Value) 
{ 
ShоwМеssаgе("календаріснує " ) ; 
70 
482.ЧДТУ.22 1818-011 2 01 6 
denya = З ; 
/ / flag = true ; 
ьreak; 
} 
calendar_  a r l1iv ->Ta b le l ->Next () ; 
} 
} 
/////ІІ///////////////////Створенняновоготабеля 
if (denya == 3) 
{ 
//ВидаленняданихзБД!119 
New_tabel->BitBtnl->Click(); 
//Записмісяцятароку,записданихвтаблицю 
New_tabel->Tablel->Insert(); 
New_tabel->Tablel->Post(); 
New_tabel->BitBtn2->Click(); 
New_tabel->Tablel - >First() ; 
New_tabel->Tablel->Insert(); 
New_tabel->TablelPIB->Value = DBLookupComboBoxl ->Text+ "місяць" 
+ ComЬoBoxl->Text + "року ."; 
New_tabel->Tablel->Post(); 
//запискодамісяцяірокувполеММRRRR 
New_tabel->Tablel- >First() ; 
for ( int і=О ; i<New_tabel - >Tablel ->RecordCount; і++) 
{ 
New tabel->Tablel- >Edit(); 
New-tabel->TablelMMRRRR->Asinteger = StrToFloat(Edit2->Text); 
New=tabel->TablelRik- >Asintege r = StrToFloat(Editl->Text); 
New tabel->Tablel - >Post( ); 
New tabel->Tablel->Next(); 
} 
New tabel->Tablel - >Last() ; 
New tabel->Tablel - >Delete (); 
!І/////ІІІІІІІІІ//ІІІІІІ/!//І/ 
Tablel->Delete() ; 
New tabel->Tablel - >First() ; 
New tabel->Show(); 
flag = true; 
} 
if (denya==l) 
{ 
ShоwМеssаgе( "Створітькалендар " ); !120 
} 
New tabel->Button8->Click(); 
Data vubir->Close() ; 
} } 
Data vubir 
void fastcall TData vubir::ButtonlClic k(TObject *Sender ) 
{ 
if (DBLookupComboBoxl->Text== "" ) 
Application->MessageBox( "Bибepiть 
місяць! 11
, " Увага! " ,MB_ ICONWARNING) ; 
else 
71 
48-.ЧJЛ' .221818-01 12 0 1 7 
if ( Con,t В "ІХ 1 - ''l' ~xt -== 11 " ) 
,n.ppli ati 11 - 'Mcssag - Box ( " ВиСSсріт1., 
piк ! ","Yвaгa! " ,MB_ICONWAHNING) ; 
el~ 
{ 
//перевіркачивжестворенийтабельнаданудату 
ь 1 flag = false; 
i11t den ya=l ; 
Edit2 - Te x t=""; 
Tablel->First() ; 
Editl- >Text= ComboBoxl->Text ; 
Ed i t 2 - >Text=(DBEd itl->Text+Edit l ->Te xt ) ; 
Arhiv- >Tablel- > First() ; 
fo r ( int і=О ; і< Arhiv- >Table l->RecordCount; і++ ) 
{ 
if (Edit2->Tex t == Arhiv- >Tabl elMMRRRR->Value) 
{ 
ShоwМеssаgе ( "Табельнаданиймісяцьірікіснує " ); 
// flag = true ; 
denya=2; ! 1 2 1 
break; 
} 
Arhiv- >Tablel->Next () ; 
} 
//Перевіркачистворенийтрудвовийкалендар 
if (denya == 1 ) 
{ 
String а = Edi t 2 - >Text ; 
Calendar_arh i v ->Tablel->First(); 
for (int і=О ; і< Calendar arhiv->Tablel->RecordCount; і++) 
{ 
if (a== Ca l endar_arhiv- >TablelMMRRRR->Value) 
{ 
ShоwМеssаgе ( " календаріснує"); 
denya = З; 
//flag = true; 
break; 
} 
Calendar arh iv->Table l - >Next(); 
} 
} 
/////////////////////І////Створенняновоготабеля 
if (denya == З) 
{ 
//ВидаленняданихзБД 
New tabel->Bi t Btnl->Cl i c k() ; 
//Записмісяцятароку , записданихвтаблицю 
New tabel->Tablel->I n s ert() ; 
New-tabel->Ta b l el -> Post() ; 
New-tabel- >Bi t Btn2 - >Cl i c k () ; 
New-tabel->Tab l el->Fir st () ; !122 
New-tabel- >Tablel->Insert() ; 
New-tabel->TablelPIB->Value = DBLoo kupCombo Boxl->Te xt+ "мі сяць " 
72 
482.ЧДТУ.22 1 8 1 8-0 1 12 01 8 
+ comЬoBox l ->Tex t +"року . 11 ; 
1ew tabel - >Tablel->Pos t() ; 
//запискодамісяцяірокувполеММRRRR 
ew tabe l - >Tablel - >First() ; 
fo r -( int і=О ; i<Ne w_tabel - >Tablel->RecordCount ; і+ +) 
{ 
New tabel->Table l->Edi t () ; 
New=tabel- >Ta b l elMMRRRR->Asinteger = StrToFloat(Edit2- >Text) ; 
New tabel->Tabl elRik->Asinteger = StrToFloat(Editl->Text); 
New-tabel - >Tabl e l - > Po s t() ; 
New=tabel- >Tabl el->Next() ; 
} 
New tabel - >Ta blel->Last() ; 
New-tabel- >Tablel->Delete() ; 
/////ІІІ/ІІІ//// / ///////////// 
Tablel->Delete ( ) ; 
New tabel - >Tablel - >Fi rst() ; 
New=tabel - >Show( ) ; 
flag = true ; 
} 
if (denya==l ) 
{ 
ShоwМеssаgе( "Створітькалендар"); 
} 
New_tabel - >Button8- >Click() ; }} 
73 
додлтокв 
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ КОНТРОJПО РОБОЧОГО ЧАСУ 
СШВРОБІТНИКІВ ШДПРИЄМСТВА 
Інструкція користувача 
482.ЧДТУ. 221818-01 34 01 
Листів 7 
- ) 
Розробник: Мартинюк В.А. 
Черкаси,2022 
74 
482.ЧДТ .. 1_1" lR-0134 01 2 
Розроблснн,1 106і.11 ьннй додЗї"Оt( над. .,  користувачеві )\Шl режими роботи -
pe)I-IfM зчтrтування ключів співро6ітннків (термінальний режим) режим 
,,nрзв.піmrя. В режнмі зчитування додаток ем люс роботу терміналу - лодаток 
~ 
110стійно знаходнться на foreg1·oнпd (передній план) і не дозnоляє запускати на 
цьому пристрої ніякі інші додатки . 
Головна функція програми в термінальному режимі - зчитування ключtв 
співробітнпків додавання заm,~сів в журнал відвідувань. Для виходу з 
термінального режиму необхідно перевести додаток в режим управління 
Jfеактивувати термінал на пристрої. 
режимі управління представлена функціональність для управління 
сервісом - робота з підприємствами, співробітниками, ключами і терміналами. 
Головні функції програми в режимі управління - призначення NFС-ключів 
співробітникам або вимкнення ключів (видалення асоціації між ключем 1 
сп:івробітником) . 
ЕтJ1І 11111• и1м1 nользооJ rсл» 
П;~ро11ь 
Забu1ли пароль? 
Рисунок В. І _ Екрани для авторизації користувача і активації терміналу 
75 
1,..-.-=-~ 
F 
482.ЧДТУ. 221818-01 3401 з 
При запуску програми користуnач може аnторизуватися в сервісі, 
sнF:орп:стовуючи дані свого облікового запису, або активувати додаток як 
с-таuіонарний термінал. Для аь.--тивації терміналу користувачеві необхідно ввести в 
додаток унікальний код для підтвердження терміналу, згенерований сервером. 
На основі унікального коду сервером буде визначена організація, якій 
належить термінал. Скріншоти екранів авторизації в сервісі і активації терміналу 
представлені на рис. В. І. 
Після успішної авторизації в сервісі Аndrоіd-додаток переходить в режим 
управління. Разом з даними про обліковий запис користувача на мобільний 
додаток завантажуються дані про список організацій і ролях користувача в 
організаціях, дані про співробітників і асоційованих з ними NFС-ключі. 
N)) Активировать термин ал 
-!!.!. 0рГ,:Н◄ t1ЗаЦІІЯ 
-••·  Сотрудники 
о Терминаль1 
е Профиль nользователя 
@ ВЬІЙТИ 
Рисунок В.2 - Навігаційна панель мобільного додатку 
у режимі управління користувач може вибрати організацію і переглянути 
дан· • ан~·зації , співробітників, термінали, вибравши відповідний 
1 про рекв1зити орг 
пункт меню на навігаційній панелі. 
76 
482-ЧДтУ. 2218 18-01 3401 4 
Барабанщикова Наталья 
с, с:~рш.1 •1 r1por р.:1м.r.111с, 
Вм-wняков Павел 
Cnt>u11a.11•cт SEO 
Владимиров Сергей 
nро,р.а.мм ИС:1 
Габбасов Константин 
Про.r, амr,щс, 
Герасименко Олеся 
Мен едже-р no nро~юам 
Горwков Алексей 
Л.о-nж.но-с,ь 
Зубакин Юрий 
Сnіі'цИ.rJШСї SEO 
Рисунок В.З -Екрани для перегляду списку співробітників 
Для управл1ння NFС-ключами співробітників необхідно вибрати 
відповідного співробітника зі списку всіх співробітників підприємства, перейти до 
профіто співробітника, вибрати пункт меню «прив'язати ключ» на панелі AppBar і 
докласти NFС-ключ до пристрою. 
На основі даних про ключі та співробітників підприємства, збережених в 
локальній базі даних програми, буде зроблено висновок про те, чи належить цей 
ключ одному зі співробітників організації або ключ вільний, і запропоновано 
відповідну дію користувачеві. Діалоги прив'язки І відв'язування ключів наведені 
на рис. В.З. 
У режимі управління доступна опщя спрощено~ активації терм1налу, 
минаючи процес створення унікального коду в веб-інтерфейсі та введення його в 
додаток. При активації терміналу з режиму управління користувач може вибрати 
один з доступних режимів роботи терміналу - мобільний або стаціонарний. 
77 
482-чдтУ. 221818-01 34 01 5 
Ключ уже используется 
НОВЬІЙ КЛЮЧ 
• Макеров Олег 
Горшков Meкcert 
ИАен'f11фикаrор: З4С2872~142бб 
И,Qентификатор: 34В2Е471FD2166 К11юч уже ис ntнit:>~~тcя 11 не может 
(jr,1ть ПPІfBSIJiHI І{ еь,6р{НІІІОМУ 
npv.В~Tt, Зl'O f ЮlЮЧ К j'ЧеТН СЇt сотруднику. 
!Jlr!ИCI~ соtруД.НИ!<.сі? 
ОтІЗязnть ключ? Ма11еров Олег 
OH,~:J-!t. ПРИВЯЗАТЬ КЛЮЧ больше н~ смо:«<:r ¼tсnользовать 
ero ДІJ~ реrисrрац1~н. 
(П.\S::J~/. ОТВЯЗАТЬ КЛЮЧ 
Рисунок В.4 - Діалоги для призначення ключа співробітнику і деактивації ключа 
Залежно від режиму роботи терміналу деякі налаштування або background­
cepвicи, що запускаються додатком, можуть бути відключені. 
Мобільний термінал передбачає використання особистого Аndrоіd-пристрою 
менеджера або власника підприємства і працює в режимі управління. При 
зчитуванні NFС-ключа користувачев1 буде показано дшлогове в1кно з 
інформацією про статус події. 
При виході з режиму управління мобільний терм1нал стає активований. 
Використання мобільного терміналу може бути виправдане на рухомих і 
просторових робочих місцях для контролю співробітників. 
Стаціонарний термінал передбачає, що Аndrоіd-пристрій працює автономно 
без людського втручання (наприклад, розташований на вході в офіс підприємства). 
У зв'язку з тим, що зчитування NFС-карт можливо тільки при включеному і 
78 
482.ЧДТУ. 221818-013401 6 
блокованому екрані пристрою ... 
~еЗа . з міркувань безпеки, при активац11 
cf8irio»apнoro терм1налу в додатку запускається сервіс, який відповідає за 
qасне розблокування екрану. 
своє 
а ~ 11 
d t{ <:>. ·:_,:~ ~ • ~ 50·:~ ~ с1.~_з 
.·~·~/:.:·/??·--·•.··.···. -~-~-. 
~ Акт1-1аация'терминала . 
... 
Ш IВlackWater Іnс. 
Наз.Тйttие CIPf,НJ l,\$.Jil jl,111 
D Стационарнь1й "' 
ЛІ{ ТІЛВИРОВАТ Ь H:PMИH/\Jl 
Рисунок В.5 - Екран для активації терміналу через режим управління 
Мобільний додаток може працювати з NFС-картками співробітників і при 
відсутності доступу до мережі Інтернет. Дані журналу про зчитування ключів 
співробітників зберігаються перед відправкою на сервер в локальній базі даних 
програми. 
Якщо з якої-небудь причини (відсутність з'єднання з сервером, відсутність 
Інтернет-з'єднання і т.д.) дані про зчитування ключа не вдалося вщправити 
своєчасно, то буде зроблено і відображено попередній висновок про статус 
зчитування ключа на основі локальних даних програми. 
79 
482.ЧДТУ. 221818-013401 7 
Після чого додаток ініціює запуск сервісу, що працює у фоновому режим~, 
я-кнй буде регулярно, з періодичністю в п'ять хвилин намагатися синхронізувати 
локальну базу даних з накопиченою інформацією про ключі співробітників з 
nентРальною базою даних на сервері. Після успішного відправлення накопичених 
дaJfJIX на сервер, фоновий сервіс завершує роботу. 
в результаті розроблено мобільний додаток на базі операційної системи 
Android. Розроблений додаток повністю задовольняє функціональним 1 
нефункціональним вимогами, що пред'являються до системи. 
80 
ДОДАТОКГ 
ПРОГРАМНЕ ЗАБЕЗПЕЧЕІffіЯ КОНТРОЛЮ РОБОЧОГО ЧАСУ 
СІПВРОБІПІИКІВ ШДПРИЄМСТВА 
Графічні матеріали 
482.ЧДТУ. 221818-019001 
Листів 4 
Розробник: 
Черкаси,2022 
81 
,, 
4 2 .чдт . 22 1 1s-01 90-01 2 
()'J.')'1JІПС_ТЬ Р бочнйчас : Обробка даних для 
· 3110МАН1ТНИХ 
pt . • Показннюі оцінювання 
взаоrопов язаних виконання резу.з:ьтатів та їх 
~01,1octtй про mдивід Іё\ЛЬНИХ впливу на загальний 
стан об· єкrа П."Іаmв та результат ціяльност1 
~його зав~ань: організації, її 
заваJПUеяяя. Результативні рейтипrу, бренду, 
JJl;xRТ3 шдн:Каторя рейтингу прац1вннка. 
резУЗЬТа~ виконання 
діJзІЬЯОС'П 
Рисунок Г.1 - Загальна модель інформаційної системи управлінського обліку 
та моніторингу завантаження працівників 
SCAN TAG 
Т№ Р'о,есІ AnactJon 
~ 
ТІМЕООСК 
~ 
e,gonotes com 
......... ... 8.ІоЬООnе 
.,,~ 
TunePad 
р - . . уючих сучасних систем контролю робочого часу 
исунок Г.2 Анал1з 1сн 
82 
482-ЧДТ · 2218 t 8-01 90•01 j 
--~~An o 
М\ 
J{'v"r'""С 'f'•' 81\Ч --· llpnщ~q11щ DлnСІІІІІС 
M~llt:'.\:a-~pn niltnpш:мcтn.t 
Пpmнimrm P<>OO'Ddl І l 
QrіВробі1ШІА ~~~{r 
nідІJРtrЄМСТВЗ 
, Менеджер 
піщrр11ємства 
1 1 
І 
Рисунок Г.З -Діаграма прецедентів сервісу обліку робочого часу 
.___1_я_те _ р....,ф_е_йс_  _,І .І. .._ _А_ пd_r_оі-~,г--д_о_А_а_т_о_к__,І І. _ R_Е_ s_ т...-.,_с_е_рв_ •_· с_ / ._І _с_ е_рт~-е_Р_ __  
Меае.ц;:ер І І 
І І 
І І 
crea teТ e nniшil() І І 
POST ../ ten11iшils/ , 1І  
·~--------.1--------71-·ї І 
і .. crenteTer111iш1ІO,, ~.J  
1 Code 20 1/ 
І · tс1111і11~І 1 ,' 
ІІ  pincode , -------------- ,І·  
рін.соdе J . ,<--------------- -- ~-------------- --- - : 
І ___________________ -, : : 
І І І 
І , J POST .. / ten11i11:ilsl І .:onifi1111Te1щi1111l 1 
со11!іrш/ : (рівсоdе, шоdеІ. : 
Т -------;,,- і11н~і) І 
І І-------7і·-•· 
f 
І СосІе 200! 
І 1 ~1·111і 11 11І 
І 
І юkен _, 
І г---- ---------· 
І І 
І І І 
І І 
І 
Рисунок Г.4 - Процес додавання нового термінала 
83 
,. 
482 ч;,т 
. ' у · 22 181 Н-01 90-0 t 4 
\ 
Cni11poбinDІ'~ '- l t And rоІd-до,111ток l REST~cepвlc І r Сервер 
r 
І 
І 
І 
І 
Рисунок Г.5 - Процес роботи співробітника з сервісом 
Tctm~н.tfrч,nt&A.. ...Y І tlf"'~ ~ 2 
•~J ,.,, . ..'/ J..,.• .,.,f ;t.,...;:..,, .. :a. , • .Jr ,J 1~ z.1~,1{, .,r,-iнiн~,,~:1,1r,., 
ltt rfll\.Lf,j1,щcw:.,-.~; tl< ! , !) 
t:U 1 ...i,t,,_"! . 't.::.~· .6,AJ:,,,:д,.4,'l(' ~J.!~ ~ І J ,-.\,1\JJ•Jr~_.._.,r.,._ OH1.$t. 
Рисунок Г.6 - Статистика «зависань» додатка в сервісі Crashlytics 
84