Репозиторій ЧДТУ
Репозиторій ЧДТУ зберігає і дозволяє легкий і відкритий доступ до всіх видів цифрового контенту, включаючи текст, зображення, анімовані зображення, MPEG і набори даних
Дізнатися більше
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/9186Повний запис метаданих
| Поле DC | Значення | Мова |
|---|---|---|
| dc.contributor.advisor | Катаєва, Євгенія Юріївна | - |
| dc.contributor.author | Малаховський, Ярослав Віталійович | - |
| dc.date.accessioned | 2026-03-28T16:34:21Z | - |
| dc.date.available | 2026-03-28T16:34:21Z | - |
| dc.date.issued | 2024-06-17 | - |
| dc.identifier.uri | https://er.chdtu.edu.ua/handle/ChSTU/9186 | - |
| dc.description.abstract | АНОТАЦІЯ Малаховський Я.В., тема кваліфікаційної роботи бакалавра «Розробка wеb-застосунку обліку медичних препаратів аптеки», за спеціальністю 121 Інженерія програмного забезпечення, ЧДТУ, м. Черкаси 2024 Автоматизація обліку медичних препаратів є потребою і необхідністю, так як вона набагато спрощує процес роботи і допомагає звести до мінімуму збитки і зайві витрати. В результаті автоматизації підвищується якість сервісу; забезпечується швидка обробка замовлень і обслуговування відвідувачів; ведеться облік руху мед. препаратів; скорочуються витрати на пошук і аналіз інформації. Метою бакалаврської роботи є розробка системи, яка буде мати наступний функціонал: користувач повинен мати можливість переглядати та вести облік медичних препаратів аптеки які занесені в систему, додавати і видаляти дані. Робота передбачає: 1 Аналіз методів та засобів розв'язання поставлених задач; 2 Конструювання програмного забезпечення програмного забезпечення інформаційної системи; З Проектування програмного забезпечення програмного забезпечення інформаційної системи; 4 Тестування усунення недоліків програмного забезпечення програмного забезпечення інформаційної системи. Для розробки wеb-застосунку обліку медичних препаратів аптеки структури системи, проектовані інформаційні системи які включають а наліз предметної області, розробки логічної структури системи, проектування інтерфейсу користувача, створення бази даних, проведення модульного, інтеграційного, системного та приймального тестування. Об'єктом розробки є процес проектування, конструювання, тестування програмного забезпечення. | uk_UA |
| dc.description.abstract | ANNOTATION Malakhovskyi, Y.V., topic of the bachelor's qualification work "Development of а web-application for accounting of pharmaceutical drugs in а pharmacy", specialty 121 Software engineering, CSTU, Cherkasy 2024 Automation of medicines accounting is а need and а necessity, as it greatly simplifies the work process and helps to minimize losses and unnecessary costs. As а result of automation, the quality of service and prestige of pharmacies increases; fast order processing and customer service are ensured; coordination and control over the work of staff are improved; the movement of medicines is recorded; and time spent on searching and analyzing information is reduced. The work involves: 1 Analysis of methods and means of solving the tasks; 2 Software design information system software; З Software design information system software; 4 Testing of software defects elimination information system software. То develop а web-application for accounting for medicines of а pharmacy, the system structure, designed information systems that include analysis of the subject area, development of the logical structure of the system, design of the user interface, creation of а database, conducting modular, integration, system and acceptance testing. The object of development is the process of software design, construction, and testing. Translated with DeepL.com (free version) The purpose of the bachelor's thesis is to develop а system that will have the following functionality: the user should Ье able to view and keep records of the pharmacy's medicines that are entered into the system, add and delete data. | uk_UA |
| dc.language.iso | uk | uk_UA |
| dc.subject | автоматизація | uk_UA |
| dc.subject | розробка програмного забезпечення | uk_UA |
| dc.subject | облік медичних препаратів | uk_UA |
| dc.subject | проектування | uk_UA |
| dc.subject | бази даних | uk_UA |
| dc.subject | automation | uk_UA |
| dc.subject | software development | uk_UA |
| dc.subject | accounting of medicines | uk_UA |
| dc.subject | design | uk_UA |
| dc.subject | databases | uk_UA |
| dc.title | Розробка web-застосунку обліку медичних препаратів аптеки | uk_UA |
| dc.type | Bachelor Thesis | uk_UA |
| Розташовується у зібраннях: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) | |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Малаховський Ярослав Віталійович.pdf Restricted Access | 33.2 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«бакалавра»
освітній рівень
на тему: Розробка wеЬ-застосунку обліку медичних препаратів аптеки
Виконав: студент 4 курсу, групи ПЗ-2004
Спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент МалаховськийЯ.В.
(прізвище та ініціали)
Керівник Катаєва Є.Ю.
(прізвище та ініціали)
Рецензент Золотоверхий Я.В.
(прізвище та ініціали)
Черкаси 2024
ситет
(повне наіімснуваюUІ вищоrо навчального закладу)
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕР
Зав. к , професор
С. Гол б
ЗАВДАННЯ
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Малаховський Ярослав Віталійович
( прізвище, ім'я, по батькові)
1. Тема проекту (роботи) Розробка wеЬ-застосунку обліку медичних препаратів аптеки
Керівник проекту (роботи) Катаєва Євгенія Юріївна д.т.н .• професор
(прізвище, ім'я, по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від « 26 » лютого
2024 року №60/04
2. Строк подання студентом проекту (роботи) _________________
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси управління;
календарне планування проекту; управління ризиками проекту; управління ресурсами
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) Вступ;
Розділ 1. Існуючі методи та засоби розв'язання поставлених завдань;
Розділ 2. Впровадження результатів дослідження у практику проектування програмного
забезпечення інформаційних систем;
Розділ 3. Розробка та тестування програмного забезпечення;
Список використаних джерел;
Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов'язкових робіт проекту);
Додатоки Г - Графічний матеріал;
6. Консультанти розділів роботи
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання пnийняв
1
2
7. Дата видачі завдання =2=6-'-'лю=т:..;::о=г=о-=2:..;::О-=2""'4. ..р." '"._ __________________
КАЛЕН АРНИЙ ПЛАН
№
05.12.2023
з/п
Постановка задачі JЗ.12.2023
Підготовка завдання 16.12.2023
2
з Погодження завдання 19.02.2024
4 Затве дження завдання
Виконано
Студент-дипломник Малаховський Я.В.
(прізвище та ініціали)
Керівник проекту Катаєва Є.Ю.
(прізв11що та ініціал )
и
Завідувач кафедри Голуб С.В.
(прізвищ• та ініціат,)
-
АНОТАЦІЯ
Малаховський Я.В., тема кваліфікаційної роботи бакалавра «Розробка wеЬ
застосунку обліку медичних препаратів аптеки», за спіцальністю 121 Інженерія
програмного забеспечення, ЧДТУ, м.Черкаси 2024
Автоматизація обліку медичних препаратів є потребою і необхідністю, так
як вона набагато спрощує процес роботи і допомагає звести до мінімуму збитки і
зайві витрати. В результат� автоматизації шдвищується яюсть серв1су;
забезпечується швидка обробка замовлень і обслуговування відвідувачів; ведеться
облік руху мед.препаратів; скорочуються витрати на пошук і аналіз інформації.
Метою бакалаврської роботи є розробка системи, яка буде мати наступний
функціонал: користувач повинен мати можливість переглядати та вести облік
.
медичних препаратm. аптеки яю. занесеш. в систему, додавати 1. видаляти даш.
Робота передбачає:
1 Аналіз методів та засобів розв'язання поставлених задач;
2 Конструювання програмного забезпечення програмного забезпечення
інформаційної системи;
З Проектування програмного забезпечення програмного забезпечення
інформаційної системи;
4 Тестування усунення недоліків програмного забезпечення програмного
забезпечення інформаційної системи.
Для розробки wеЬ-застосунку обліку медичних препаратів аптеки структури
системи, проектовані інформаційні системи які включають аналіз предметної
області, розробки логічної структурии системи, проектування інтерфейсу
користувача, створення бази даних, проведення модульного, інтеграційного,
системного та приймального тестування.
Об'єктом розробки є процес проектування, конструювання, тестування
програмного забезпечення.
Ключові слова: автоматизація, розробка програмного забезпечення, облік
медичних препаратів, проектування, бази даних.
ANNOTATION
Malakhovskyi, Y.V., topic of the bachelor's qualification work "Development of а
web-application for accounting of pharmaceutical drugs in а pharmacy", specialty 121
Software engineering, CSTU, Cherkasy 2024
Automation of medicines accounting is а need and а necessity, as it greatly
simplifies the work process and helps to minimize losses and unnecessary costs. As а
result of automation, the quality of service and prestige of pharmacies increases; fast
order processing and customer service are ensured; coordination and control over the
work of staff are improved; the movement of medicines is recorded; and time spent on
searching and analyzing inf ormation is reduced.
The work involves:
1 Analysis of methods and means of solving the tasks;
2 Software design information system software;
З Software design information system software;
4 Testing of software defects elimination information system software.
То develop а web-application for accounting for medicines of а pharmacy, the
system structure, designed information systems that include analysis of the subject area,
development of the logical structure of the system, design of the user interface, creation
of а database, conducting modular, integration, system and acceptance testing.
The object of development is the process of software design, construction, and
testing.
Translated with DeepL.com (free version)
The purpose of the bachelor's thesis is to develop а system that will have the
following functionality: the user should Ье able to view and keep records of the
pharmacy's medicines that are entered into the system, add and delete data.
Keywords: automation, software development, accounting of medicines, design,
databases.
31\оІІСТ
ПЕРЕJПК СКО~ОЧЕНЬ ТА ·у1,1овних ПОЗИ..~\ ЧЕНЬ .................................. .5
вcn'll:..... .. ... ............. ........... ... ......... .... .......... .. . .......... . .......... .... . ............ ............ .......6
1 ІСНУЮЧІ rvmтоди ТАЗJ~СОБИ РОЗВtЯЗ.~llіНЯ ПОСТАВЛЕНИХ
3,.1.~Д~.t\ІІЬ ......~ .............. ·········· ............... ·········-·. ········••·•. ........................... ······· ......... 1О
1J "A.mt.rriз, сучасник піlmодів до іf:Юзрооm програ.\!НОFО забе:зпеченни
фармащ:-1[\ІичнаШ F&.iI}rзi ...................... ....- -...... .. ............. .•......... .. ............................ 1О
1 , О ... .... - . 12
.J., .пи прwrетн~1 ,oь..rra-cr. ............. ................................................................ .
1. З 1,fe- 'оди: 'Еа зас,о'fіи~ .икі !В..їІі:е викорнсrовуютье.я д.u },rсуненнк пробл:ем
Т;а ВШ.."'С)н:аинх s~....... ... . . ...... .. ....... •... .... .... ....... .... .. . ..... ..... .... .. .. .. . .. .. ... . . . .............. .. .. ... 15
1.4 Посі"аНов:~а за;::r;ачі ......................................................... .............. ............ .... 19
Висновок да~ першого роз~1:у: ..................................................................................... 20
2 ВІІРОВАД»ffі:ННЯ РЕЗУЛЬ ТАТІВ ДОСШДЖЕНЬ У ПРJ \КlltlКY
ПРОЕКnr-в.;!\ННЯ ПРОГР.а\і\..ПІОГО 3/~..БЕЗІІЕЧЕННЯ
llіФОРt"1АЦІЙНИХ С:ИСТШ.Л ... ............................................................................ 21
"'1' · 1111 ... 6 ,- ~- . , ,1
1v1.одеmовання предмеmш. 01... .1. 1:ac:n ....................... ................................. ,і;,
2. 1. 1Предмеmа область моделюв-аюп. f1i;!oдe.r.JЬ предr,.:е-mої
обпа.сr ·. G1:овнш: пре~етноі об..1п11~ і. ........................................... ,, ...... 21
2.1.2 Еле..\Іенm моде.тпов.аню1 предl1етної' ,області ....................... ...... ....... 25
2.1.3 Роооча обласІЬ мод~"ІЮБаншІ ....................................................... 27
2.2 Фор~~ та ана.1Й3 ВИ).{ОГ .................... ................... ......... ....................... 29
2.2 .1 Формування вимог до nporpa11мoro :sабез:печенІОІ. ПерБИННі і
детапьяі вимоги. &шоrя заь.1оsнш:а і роsроо!ШКаі. Фушщі,онаш~1rі
та иефуюдіонал:ьні БШ,ЮFІ-і_ ............................... ............ . м• •·· ········ ··· ···· 29
2.2.2 Формува:шп вимог задmюм:оrшо діа.rірами преде.деиrів .... 33
2J Проектуваню1 ."Іоrічиої струк:rури :пpOFpm,moro комп..11ексу ... З 5
2.3.1 ~аь.ш 1-::JJ.ac:i:в .••.• -··-····························· .. •··•·••••••··••··••••••• .. · ··•• .. ·•·•• 35
ЧДJУ. 242303 "008 З
І І І ІІІІІ !і. ....,.r_11... ......,._1_11к_.-+_л1~,_;_., і1_, ....
,: І . !_іс ·' L c.1 1.JJ 1..1 111~:. · '
Фmс= кафедра rn"i\!C=
m-1004
"~І .- .~. l. щпа·;г. р&\П{ Ііі!J{ЄІ'·І Б· . . . . . ....... . .. .. .......... . . .. ... . .... .. .... . . . . . ... ... .. . .......... ..... ЗS· ,
....4 ./'Lpx ·т ех· :'РНе r1poef~::вaюu1. ........... .......... .............. ........... .............. ..... ФО
2. ' .1 Діагра.\іа КОШ10Нентів .... ............ ............ ................................. 40
2А .2 Роsгорrанн.1 npOFJ?МDiOЇ оистеми на апарю:иих засобах.
діаrраьs:а posrop~. .... ............ .......... .................. ............. .................. 42
:..... 5 l\1fоде..1ІЮвання поsедінки систе1~m ....... .... .......... .. ........... .................. 44
~, .). - . 1JL1) п.y.~c~u,... ,.,,.. , , . . 44
J:A'CІ.n,[a ДUІJШ{()С'Е .... . . , . ... ... . ... .. .. . ..... .... .. ..... . .. .. .. .... . ... . . •• • • • • • •• • • •• ·• • • .
, - .,. п~ . . . 4·7
~ .) .l~arpa}.{a .І[()С-ЛЩО&НОС'І .... ..... .... ........ . ............ .......... .. . . ............ ....... ,
1~ - 1Ді . ....
) · '"' 1 агра>&а :ко~юун1r.:8ІJJ,11 .. .......................... ....................... -•• • ········• • · ··· 49·
2.5 .4Ді~[а скінченного аJБ'ТШ, ату. ...... ........................................... :51
Висн-овtЗІ ,дР другоrо J:IO'Sд. лу ............................................................ ..................... 54
J РОЗРОБК.~\ ТА ТЕСТУВ.А.ННЯ ПРО :А1\1fНОГО ЗАБЕЗПЕЧЕННЯ ..... 55
З .1 Posp.;)бt:a nporp~пroro :Б.."'()мm.11а·су ...................................................... 55
3. .1 ОбrрувтуБЗНИІ вибор;· ~собm [Ре&"Іізаціі• ...................... ....... 55
" 1 2 0m
j. . • іС естрJ'і..·турн·ш .. 1\i "lifn_ т·в :мд.о яа.ГJЬнmТ")' ,ск.еми ........................... ,, .J J·
З. .3 Опис лоrіч:нm схеми а-з:с-rем1і ...................... ................................ 60
З. .4 Розро5:ка. бази ~ .............................................................. _.. ..... 62
З .1..5 Роsроб:ка. і1перфе~1су користувача ............................................. 64
3.1.6 Опис рооробЮі: програмних компонентів ."'. .............................. бS.
3.2 Тесту:в.~ cиcm.fli ............................................................ .. ................. 72
З .2. J ..А оду:льие теСІ'}'І.~ ............................ .................... ....................... 72
з 1 2 І
..J;;, • • шеграцп..,. яrе· те~: _~"-'Ваю-ш ............................... ................................. 7"
1 j
:"J .'?-.·-i:tc··. ис.те!.tmе тес-т. увашt'іІ .................................... .................................. ",'і.'J,І.
З .2.4 Приймальне тес.тувания ................................. ............. ................... 75
3.3 Прикп.ад;и !ЕПрОВаджеиоrо проrрамноrо r~mmлe.кcjt. ................. ......... 7,6
Висновки д~.о тре:-ьоrо роо.дту .................... ......................................................... 7S
висн·овю1 ..................... .. ............. ........... ............ ..........._ _ ............ .......... .... ..... 79
СШІСОК В ·ІКОРИСТР .JП1Х ~ЕЛ ................ ............ ............................... 8'О
ДОД..!\m f .............. .................................................... .......................... ................... &4
ЧДГУ . 2· 2J 3. S ПЗ;
11 !..J t/llC ,11 tl
ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ
ПЗ програмне забезпечення;
ІС інформаційна система;
10 інформаційний об'єкт;
СУБД система управління базами даних;
Шv1L уніфікована мова моделювання.
ЧДТУ. 242303 .008 ПЗ
ВСТУП
Актуальність теми: Актуальністю визначається потребою у розробці
програмного забезпечення інформаційної системи wеЬ-застосунку обліку
медИЧІШХ препаратів аптеки, робота представлена студентом спеціальності 121
- "Інженерія програмного забезпечення". цей програмний продукт створений
для обліку медичними препаратами аптеки.
Актуальність обраної теми дослідження можна пояснити глобальними
тенденціями в області інформаційних технологій, які активно впроваджуються в
медичну сферу, зокрема у фармацевтичну індустрію. Сучасний фармацевтичний
ринок вимагає постійного оновлення програмного забезпечення для аптек, з
метою оптимізації обліку медичних препаратів та забезпечення високої точності
управління аптечними запасами. В цьому контексті, важливість розробки веб
застосунюв для управлпшя запасами в аптеках стає очевидною, осюльки вони
можуть забезпечити не тільки крос-платформенність, але й значно підвищити
ефективність робочих процесів.
Розвиток цифрових технологій відкриває нові можливості для покращення
якості обслуговування пацієнтів. Веб-застосунки дозволяють автоматизувати
численні процеси, зокрема, управління запасами лікарських засобів, обробку
замовлень та взаємодію з постачальниками, що сприяє ефективності ланцюгів
постачання і скорочує час обслуговування клієнтів.
Однією з ключових переваг впровадження веб-технологій є можливість
інтеграції аптечних інформаційних систем з електронними медичними картками
(ЕМК). Така інтеграція веде до безперервної синхронізації медичних даних,
забезпечуючи доступ до актуальної інформації про здоров'я пацієнтів, їхню
історію лікування, алергії та рецепти. Це підвищує безпеку медикаційного
обслуговування, зменшуючи ризик медичних помилок та невідповідності
шкарських призначень.
З іншого боку, активна інтеграція інформаційних технологій в аптечну
практику ставить перед розробниками нові виклики, пов'язані з забезпеченням
конфіденційності персональних даних пацієнтів та відповідності програмного
б
ЧДТУ. 242303.008 ПЗ
забезпечення вимогам законодавства у сфері охорони здоров'я. Важливим
аспектом є також необхідність адаптації інтерфейсів веб-застосунків до потреб
користувачів - фармацевтів, які потребують швидкого доступу до необхідної
інформації для прийняття оперативних рішень у своїй діяльності.
В цьому контексті, дослідження та розробка нових веб-застосунків для аптек не
лише відповідають актуальним потребам ринку, але й сприяють зростанню
наукового потенціалу у галузі інформаційних технологій, оскільки вимагають
розробки нових підходів до обробки великих обсягів даних, забезпечення їхньої
безпеки, а також розробки інтуїтивно зрозумілих і ефективних користувацьких
інтерфейсів. Таким чином, тема дослідження є високоактуальною та обіцяє
значний внесок у подальший розвиток фармацевтичної індустрії та покращення
якості медичного обслуговування. З точки зору програміста
Мета і завдання розробки розробки
Метою роботи є створення програмного забезпечення інформаційної
системи обліку медичних препаратів аптеки. Це передбачає створення
реляційної бази даних та програмного додатку через який буде здійснюватись
взаємодія користувача з базою даних. Для досягнення поставленої мети в роботі
вирішувались наступні завдання:
огляд методів і засобів реалізації;
перегляд подібних програмних продуктів;
уточнення задач проекту і проектування програмного продукту;
оптимізація проектного рішення і реалізація програмного продукту;
тестування програмного продукту інформаційних технологій;
провадження та супроводження програмного забезпечення.
Об'єктом розробки є wеЬ-застосунок обліку медичних препаратів аптеки
Предмет розробки
Предметом розробки є програмне забезпечення для обліку медичних
препаратів аптеки програмного забезпечення wеЬ-застосунку.
7
ЧДТУ. 242303.008 ПЗ
У даній роботі методи проектування та конструювання включають в
себе використання CSS3, Java Script, фреймворк Flask, SQLite та середовище
розробки діаграм.
Опис отриманих результатів. В даній роботі було розроблено програмне
забезпечення для обліку медичних препаратів, яке містить усю поточну
інформацію про аптеки. Результати демонструють успішну інтеграцію всіх
необхідних модулів для управління запасами, замовленнями та взаємодіями між
співробітниками та клієнтами аптеки. Зокрема, реалізовано функціональність,
яка дозволяє користувачам переглядати всі замовлення на медичні препарати, що
занесені в систему, додавати та видаляти їх. Менеджери мають змогу додавати,
видаляти та змінювати всі наявні інформаційні процеси, що значно підвищує
ефективність адміністрування даних та взаємодії з клієнтами. Для реалізації
бекенду використовується фреймворк Flask, який дозволяє створювати
масштабовані веб-застосунки. Фронтенд системи створений з використанням
НТМL, CSS та JavaScript, що забезпечує гнучкий і зручний інтерфейс
користувача.
Практичне значення отриманих результатів. Проблема обліку
медичних препаратів в аптеці та організації вщношень між клієнтами та
співробітниками була і є очевидною.
В проекті застосовані можливі стратегії роботи з замовленнями. Для
подальшої діяльності можливе збільшення гнучкості замовлень не обмежуючись
наявною кількістю товару, а й враховувати дані замовлень.
Особистий внесок автора. Головною метою даної кваліфікаційної роботи
було розробити програмний продукт, який забезпечить можливість обліку
медичних препаратів аптеки. В результаті виконання роботи було реалізовано
інформаційну систему. Розроблена програма, в якій користувач повинен мати
можливість переглядати всі замовлення на медичні препарати які занесені в
систему, додавати і видаляти їх. В системі будуть менеджери які будуть додавати
8
ЧДТУ. 242303.008 ПЗ
видаляти і змінювати всі наявні інформаційні процеси, такі як: ведення каталогу
препаратів, управління запасами, обробка замовлень, звітність та аналітика,
клієнтське обслуговування.
9
ЧДТУ. 242303.008 ПЗ
1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ'ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ
1.1 Аналіз сучасних підходів до розробки програмного забезпечення
фармацептичної галузі
Сучасна фармацевтична галузь вимагає високоточних та ефективних
. . .
шструменпв для управшння медичними препаратами. Ринок програмного
забезпечення для аптек постійно розвивається, пристосовуючись до вимог галузі
та запитів клієнтів. У цьому контексті важливо розглянути різноманітні підходи
та технології, які формують цей ринок, та здійснити аналіз для вибору
оптимального шляху розробки wеЬ-застосунку обліку медичних препаратів у
аптец1.
Один 1з перших підходів, що набув широкого застосування, - це
використання електронних медичних систем управшння. Ці системи
забезпечують аптеки шструментами для автоматизації процесів замовлення,
обліку та ведення інвентарю. Вони можуть інтегруватися з постачальниками та
системами управління ланцюгами постачання, щоб оптимізувати ланцюг
постачання медичних препаратів. Цей підхід сприяє уникненню помилок,
пов'язаних із ручним введенням даних, і полегшує ведення точного обліку
залишків. Крім того, він може покращити обслуговування клієнтів, шляхом
швидкої ідентифікації наявності потрібного препарату та його швидкого видачі.
У світі цифрових технологій все більше аптек звертають увагу на розробку
віртуальних аптек та онлайн-платформ. Це дозволяє клієнтам зручно замовляти
медичні препарати онлайн, отримувати консультації фармацевта в режимі
онлайн, а також відстежувати своє замовлення та отримувати сповіщення про
нові товари та акції.
Розробка віртуальних аптек потребує інтеграції з безпековими системами
для захисту персональних даних клієнтів, а також механізмами для ефективного
ведення електронних рецептш. Це дозволяє розширити географію
обслуговування та полегшити доступ клієнтів до необхідних препаратів.
10
ЧДТУ. 242303 .008 ПЗ
Сучасний ринок програмного забезпечення для аптек пропонує
різноманітні підходи, які можуть бути успішно використані для розробки wеЬ
застосунку обліку медичних препаратів. Важливо враховувати специфіку галузі,
потреби клієнтів та актуальні технологічні тенденції при виборі оптимального
шляху розробки.
Один із стратегічних напрямків розвитку програмного забезпечення для
аптек полягає у взаємодії з електронними медичними картками (ЕМК). Цей
шдхщ визначається потребою впровадження інноваційних рішень для
оптимізації обслуговування пацієнтів та підвищення ефективності аптечних
процесів. У даному аналізі ми розглянемо ключові аспекти інтеграції з ЕМК та
вплив цього підходу на функціонування аптек та надання медичних послуг.
Інтеграція з ЕМК є необхідним етапом в розвитку програмного
забезпечення для аптек, оскільки це відкриває широкі можливості для
поліпшення якості обслуговування пацієнтів та оптимізації аптечних процесів.
Інтеграція з ЕМК дозволяє аптечним працівникам отримувати актуальну
та повну медичну інформацію про пацієнтів. Це включає в себе дані про виписані
рецепти, алергії, хронічні захворювання та інші важливі аспекти здоров'я.
Завдяки цьому аптеки можуть надавати персоналізовані консультації та
допомагати клієнтам у виборі належного медичного препарату, враховуючи
їхню індивідуальну медичну історію.
Інтеграція з ЕМК відкриває можливість автоматизації процесу введення
медичних даних пацієнтів в систему аптеки. Це зменшує ризик виникнення
помилок та дозволяє ефективно керувати рецептами, уникати невірного вибору
препаратів або дублювання лікування. Такий підхід сприяє загальній безпеці
пацієнтів та підвищує довіру до аптек та їхнього персоналу.
Інтеграція з ЕМК розширює можливості співпраці м1ж аптеками та
медичними закладами. Зокрема, це дозволяє аптечним працівникам отримувати
інформацію від лікарів про призначення та зміни у лікуванні пацієнтів. Такий
обмін даними сприяє більш ефективній роботі між медичним персоналом та
11
ЧДТУ. 242303.008 ПЗ
фармацевтами , що може впливати на якість обслуговування та результати
лікування .
Інтеграція з ЕМК також надає пацієнтам зручність у веденні електронних
рецептів, управлінні медичними призначеннями та отриманні іншої важливої
інформації через спеціалізовані додатки або платформи . Пацієнти можуть більш
ефективно взаємодіяти з аптечними послугами та отримувати необхідні медичні
продукти без зайвих зусиль.
Незважаючи на всі переваги інтеграції з ЕМК, існують певні технологічні
виклики та перешкоди. Однією з них є неоднакові стандарти обміну медичною
інформацією між різними системами. Розробники програмного забезпечення для
аптек повинні узгоджувати стандарти та протоколи для ефективної інтеграції.
Майбутні розвиток інтеграції з ЕМК може включати у себе застосування
розумних алгоритмів для аналізу медичних даних та прогнозування попиту на
конкретні препарати . Це дозволить аптекам не лише реагувати на потреби
пацієнтів , але і активно впливати на формування асортименту та ціноутворення.
Інтеграція з електронними медичними картками стає важливим кроком в
розвитку програмного з.абезпечення для аптек . Вона не лише забезпечує доступ
до актуальної медичної інформації та п ідвищує безпеку обслуговування, але й
сприяє більш ефективній вза модії між аптеками та медичними закладами.
Подальший розвиток цього п ідходу може перетворити аптечні послуги, роблячи
їх більш персоналізованими, зручними та ефективними для кожного пацієнта.
1.2. Опис предметної області
Аптека - це медичний заклад, який працює за погодженням і контролем
державних установ і основним завдаІШЯМ якого є забезпечення населення,
санаторіїв , лікувально-профілактичних, медико-санітарних закладів, санаторно
курортних, науково-медичних та інших закладів охорони здоров'я. «Я, компанії,
установи та організації, які мають лікарські засоби та медичні засоби
Відповідно до зазначеної аптека виконує наступні три основні функції:
1 Функція медичного закладу, а саме:
12
ЧДТУ. 242303 .008 ПЗ
надання екстреної медичної допомоги населенню;
розповсюдження гігієнічних знань серед населення та здійснення
санітарно-просвітницької роботи;
фармацевтичне постачання;
проведення інформаційної роботи серед медичних та фармацевтичних
фахівців.
Ця функція може включати ряд завдань, які виконують деякі аптеки, які ще
не широко використовуються, наприклад До них відносяться, наприклад,
вимірювання тиску та температури людського організму, проведення швидкого
анашзу цукру для хворих на діабет, тестування на вагітність та надання
лікувальної аптеки.
TtfЛВtli.HI
Рисунок 1.1- Основні функції аптеки
2 Виробнича функція, а саме:
виробництво фармацевтичних препаратів;
виконання лабораторних та пакувальних робіт;
ЧДТУ. 242303.008 ПЗ
закупівля лікарської рослинної сировини;
контроль якості вироблених лікарських засобів.
Фармацевтичні препарати випускаються в аптеках відповідно до медичних
регламентів ( основні рецептури), замовлень у профілактичних медичних
установах (офіційних рецептурах) лише відповідно до лікарських засобів,
дозволених до використання діючих речовин та допоміжних речовин з
урахуванням вимог Державної фармакопеї України та інші нормативно-правові
акти. Правила фармацевтичної технології, вимоги до лікарського засобу, його
упаковки, умови зберігання, а також методи контролю якості лікарських засобів.
3 Комерційна чи комерційна функція, а саме:
придбання та приймання медикаментів та медичних виробів;
ретельний контроль якості лікарських засобів;
розміщення та зберігання лікарських засобів та медичних виробів;
продаж наркотиків та медичних виробів населенню за готівку;
реалізація медичних та профілактичних засобів для фармацевтичних
та медичних виробів шляхом безготівкового розрахунку.
В аптеці продаються лікарські та фармацевтичні засоби, медичн1
препарати, косметика, харчові добавки, лікувальна мінеральна вода та оптика.
Аптечна класифікація
Аптеки можна класифікувати за типом власносп, ринковою особою
материнської компанії та приналежністю відділу.
Зважаючи на те, що законодавство в Україні затвердило чотири основні
форми власності (державну, муніципальну, колективну та приватну), аптеки
можуть виступати як такі або створені компанії такого типу:
1 Приватна аптека, що базується на власності людини.
2 Форма колективної власності у вигляді:
колективне товариство, засноване на власності колективної праці
підприємства;
14
ЧДТУ. 242303.008 ПЗ
комерційне товариство (переважно товариства з обмеженою
відповідальністю і в меншій мірі акціонерні товариства);
в компанія, яка належить громадському об'єднанню.
3 Муніципальна аптека, що базується на власності відповідної громади
області.
4 Державна фармація.
Незалежно від форми власносп, комерційні компанії здійснюють
роздрібний продаж лікарських засобів, які потребують ліцензії на даний вид
господарської діяльності, за умови дотримання кваліфікаційних, організаційних
та ІНШИХ правових вимог.
Аптеки будь-якого типу власності можуть за контрактом використовувати
відомий бренд, а потім їх називають ліцензіатами аптек. Аптеки в різних регіонах
країни діють під торговою маркою угорського хімічного заводу "Gideon Richter",
словацької компанії "Slovakopharma" та польського акціонерного товариства
"Polfa".
Після шдключення до материнської компанії до ринку є аптеки,
організовані компаюями, діяльність яких спрямована лише на роздрібний
продаж фармацевтичних препарапв, аптеки з оптових та промислових
фармацевтичних препаратів (фірмові аптеки). Такі виробничі компанії, як
«Борщагівський НFZ», «Фармаю>, «Київмедпрепарат», «Лубніфарм» тощо, а
також оптові компанії - «Аптека Біокон», «Гедеон Ріхтер-Укрфарм» та «СЕБ
Фармація» відкрили власні аптеки (усі - Київ) та інші.
1.3 Методи та засоби, які вже використовуються для усунення проблем
та виконання завдань
1.3.1 Система обліку препаратів" ПроЗа-Аптека "[35]
В сучасних умовах розвитку інформаційних технологій аптеки активно
впроваджують різноманітні системи обліку медичних препаратів для оптимізації
управлінських процесів та підвищення ефективності роботи. Аналіз існуючих
15
ЧДТУ. 242303.008 ПЗ
систем дозволяє зрозуміти поточний стан цієї галузі та визначити тенденції в
розробці та використанні програмних продуктів для аптек.
ПроЗа-Аптека - програмний комплекс, що забезпечує облік та контроль в
аптеках:
на робочому місці провізора
облік залишків медикаментів на складах та відділах;
замовлення медикаментів з прайсів постачальників;
контроль серій та термінів зберігання медикаментів;
контроль фальсифікату медичних препаратів;
швидкий ввід прихідних накладних по штрихкодах;
зручний режим формування ціни;
. . .
друк цшниюв, штрихкод1в, накладних;
облік розрахунків з дебіторами/ кредиторами;
облік витрат;
контроль руху кошnв;
фінансові та товарні звіти;
проведення актів переоцінки;
формування інвентаризаційних актів.
На робочому місці фармацевта
продаж товарів по штрихкодах;
продаж товарів по кредитних картках;
індивідуальний дисконт для кожного клієнта.
контроль залишків медикаментів у відділі;
Нижче приведений приклад роботи з інтерфейсом цієї програми:
16
ЧДТУ. 242303 .008 ПЗ
Ае, <i•t.rrн :, aцJ 111 p o6~.lflt, 1.r а .,. 11ну
f€ 3,-.o r,11н t'"("] D!rJl -. •) iTl\~f
1:..-or.,r,11;'i ..rІЬ'J•.Л
Рисунок 1.2 - Інтерфейс системи
Переваги проrрами "ПроЗа-Аптека":
1 Автоматизація управління запасами.
2 Підвищення ефективності робочого процесу.
З Точний контроль термінів зберігання.
4 Захист від фальсифікації.
5 Оптимізація фінансового обліку.
6 Персоналізований дисконт для клієнтів.
Недоліки програми "Проза-Аптека":
1 Складність інтерфейсу.
2 Залежність від технічної підтримки.
З Вартість впровадження та обслуговування.
4 Ризики пов'язані з даними.
1.3.2 Система обліку" Скарб "[36]
Група компаній, що займаються розробкою і супроводом ІТ -товарів для
фармацевтичного ринку в 11-ти країнах світу це компанія «Скарб». Це один з
лідерів програмного забезпечення для аптечних підприємств на ринку України.
Ця компанія розробила програмний комплекс по автоматизації роботи аптек ПК
17
ЧДТУ. 242303.008 ПЗ
"Skarb 365" і за 4 роки вивела його на передові позиції за кількістю інсталяцій.
Понад 1500 роздрібних аптечних точок в Україні.
Нижче приведений приклад роботи з інтерфейсом цієї програми :
СКАРБ РІО Скарб
Skarb Pro Skarb Cloud
Облікова система управл іння аптеками та Модуль взаємодії з компонентами eHealth в рамках
аптечними мережами. гнучко і швидко програм реІмбурсаці"/ та електронного рецепта
настроюється і легко адаптується в м інливих
вимогах ринку
• і нтегрується з будь-якими програмними продуктами; • модуль для робо-ти з електронними рецептами (відпуск
• інтегрується з будь-яким торговим обладнанням (всі лікарських засобів, управління аптеками,
види програмних і апаратних РРО , банківських співробітниками, договорами з НСЗУ) .
терміналів, сканерів та інше); • адміністративно - аналітичний модуль керування
• має повний пакет рішень для управління: відпуском лікарських засобів за електронними
- асортиментом рецептами.
- ціноутворення • забезпечення взаємодії з НСЗУ (підписання договорів .
- продажем реєс-трація в НСЗУ ап-тек і фа рмацевтів/ п ров ізорів, зві-ти
- закупівлею по погашених рецептах)
- персоналом .
Рисунок 1.3 - Продукти компанії «Скарб»
Переваги програм Skarb Pro і Skarb Cloud:
1 Інтеграція з бухгалтерськими програмами.
2 Підтримка різноманітного обладнання.
3 Повний пакет управління.
4 Електронні рецепти.
5 Зв'язок з національною системою здоров'я.
Недоліки програм Skarb Pro і Skarb Cloud:
1 Комплексність налаштувань.
2 Залежність від інтернету для Skarb Cloud.
3 Вартість.
4 Оновлення та підтримка.
18
ЧДТУ. 242303.008 ПЗ
1.4 Постановка задачі
Після аналізу існуючих програмних аналогів , було виявлено їх переваги та
недоліки і на основі отриманої при аналізі інформації, виникла наступна
постановка задачі.
Розробити wеЬ-орієнтовану систему, яка буде встановлена на локальному
сервері що дозволить:
забезпечити кросплатформність ( систему можна запустити із наявного
в кожній ОС браузера ввівши відповідну wеЬ-адресу для входу в
середовище системи);
позбавити користувачів залежності вщ додаткового встановлення
спеціалізованого ПЗ;
забезпечити централізоване збереження даних;
забезпечити кращий супровід, та розширюваність інформаційної
системи за рахунок використання новітніх технологій .
За збереження і обробку даних відповідає серверна частина, яка пропонує
зручне у використанні АРІ яке розширення може з легкістю використовувати
задля своїх потреб.
WеЬ-орієнтована система, яка має відображати інформацію про
замовлення користувача, список наявних в аптеці препаратів, статистику, звіти
про доходи.
Здійснивши детальний анал1з системи, сmд спроектувати БД з
урахуванням подальших змін.
19
чдт . 24 О .оо 11
81, ноnок до н \р11101 о роздtлу
р І Jlbll В Ш ці1 рннку 11ро11)ам11их рішень у
блнвнм акц н гом на ро· робці та н11ровадже1111і веб
ля пр \Rління ·ша амн в , nт ка . Завдяки всебічному аналізу
і н ·ючн . · ів та ін тр t нтів підкр л1 ть я важливість високоточних та
ф ктнвнп . · п 'те t правління для задоволення динамічних потреб
ф Р шц втнчн г ктор . До лідж нпя різних програмних систем, висвітлює
ї. · ні п р в гп та пробл мп, пропонуючи розуміння їхньої функціональності,
адаптпвн ті так ри тувацького інтерфейсу.
Інтеграція з л ктронними медичними картами (ЕМК) визначена як
ключовий прогр що сприя покращенню обслуговування пац1єнт1в,
опти:1'rізації роботи аптек та підвищенню безпеки ліків.
Зроблено висновок що хоча сучасні програмні рішення пропонують значні
переваги: в оптимізації роботи аптек, постійні інновації та адаптація мають
вирішальне значення. Майбутній розвиток веб-орієнтованих систем обіцяє
подальшу революцію в аптечному секторі, забезпечуючи крос-платформенну
сум1сюсть, централізоване зберігання даних, а також покращення
обслуговування та масштабованості системи завдяки новітнім технологіям. Ця
еволюція до більш досконалих, зручних та інтегрованих систем знаменує собою
значний крок вперед у задоволенні складних вимог сучасного аптечного
менеджменту та догляду за пацієнтами.
З цього витікає задача розробки веб-орієнтованої системи для обліку
медичних препаратів аптеки, яка буде встановлена на локальному сервері. Ця
система повинна забезпечувати кросплатформенність, незалежність
користувачів від додаткового програмного забезпечення, централізован
зберігання даних і покращення супроводу і розширюваності за рахунок
використання новітніх технологій. Основним завданням системи є забезпечення
ефективної взаємодії користувача з базою даних через веб-інтерфейс.
20
ЧДТУ. 242303.008 ПЗ
2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ у ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
2.1 Моделювання предметної області
В цьому підрозділі розглядатимуться такі питання: предметна область
моделювання, модель предметної області, словник предметної області, елементи
моделювання предметної області, робоча область моделювання
2. 1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області.
Предметна область моделювання
Для моделювання предметної області системи обліку медичних препаратів
аптеки, виходячи з класичної схеми, можна визначити наступні етапи розробки:
1 Функціональна модель «як є»:
Цей етап передбачає аналіз існуючих процесів управління запасами
медичних препаратів у аптеці. Це включає збір інформації про:
Вхідні та вихідні процеси: Як препарати отримуються, зберігаються, і
продаються.
Інтеракції з клієнтами: Як здійснюється консультація і продаж.
Облік і звітність: Методи ведення обліку препаратів та формування
ЗВІТІВ.
Взаємодії з постачальниками: Замовлення, прийом товару, і вирішення
спор1в.
2 Модель <<ЯК треба»:
На основі аналізу моделі «як є», розробляється модель «як треба», що
відображає бажані зміни та оптимізації:
- А · процесів·• Впровадження автоматизованого обліку
втоматизац1я
запасів та системи електронного документообігу.
21
ЧДТУ. 242303 .008 ПЗ
оптимІЗащя складських запас1· в·. в икористання алгоритм1в для
оптимального замовлення та зберігання препаратів ;
покращення взаємодії з клієнтами: Введення СRМ системи для
кращого управління відносинами з клієнтами·
'
цифровізація документації: Перехід на повністю цифрове ведення
документації;
З Концептуальна модель даних:
На цьому етапі розробляється концептуальна модель, що включає:
сутності : Аптека, Працівники, Препарати, Запаси, Транзакції, Клієнти;
відносини між сутностями: Наприклад, один працівник може
управляти багатьма транзакціями;
атрибути сутностей: Детальна інформація, яка повинна зберігатися для
кожної сутності, така як ідентифікатор, ім'я, дата придбання тощо;
Завершення цього процесу дозволить чітко уявити як поточні процеси
функціонують, які зміни необхідні для оптимізації та як має виглядати кінцева
система для обліку медичних препаратів у аптеці. Це також допоможе у
виявленні потенційних ризиків та викликів на ранніх стадіях проектування та
впровадження системи.
Модель предметної області
При розробці веб-застосунку для обліку медичних препарат1в аптеки,
моделювання предметної області вимагає визначення ключових елементів, що
відображають структуру і процеси в аптеці. Ці елементи включають сутності,
атрибути, відносини, обмеження та процеси, які разом формують основу для
системи. Ось детальний опис кожного з цих елеменпв:
Сутності
1 Препарат: Основна сутність, яка представляє лікарський засіб,
доступний для продажу або зберігання в аптеці.
2 Запас: Відображає кількість конкретного препарату, що є в наявності.
3 Транзакція (Продаж): Фіксує продажі препаратів клієнтам.
22
L
ЧДТУ. 242303.008 ПЗ
4 Клієнт: Інформація про осіб, які купують препарати.
5 Постачальник: Сутність, що представляє компанії або осіб, яю
постачають препарати в аптеку.
6 Категорія препарату: Класифікація препаратів за їх призначенням або
типом.
Атрибути
Кожна сутність має набір атрибутів, яю детально описують її
характеристики. Наприклад:
препарат: Назва, Виробник, Термін придатності, Ціна, Категорія;
запас: Препарат (зв'язок), Кількість, Дата надходження;
- транзакція: Дата, Препарат (зв'язок), Кількість, Сума, Клієнт (зв'язок);
клієнт: Ім'я, Прізвище, Контактна інформація;
постачальник: Назва, Контактна інформація, Адреса;
категорія препарату: Назва, Опис.
Відносини
Відносини описують як сутності пов'язані між собою. Наприклад:
препарати належать до певної категорії;
- запаси відносяться до конкретних препаратів;
. .
- транзакц11 асоціюються з кшєнтами 1 одним або деюлькома
препаратами.
Обмеження
Обмеження необхідні для забезпечення валідності даних у системі. До
них можуть належати:
термін придатності препаратів не повинен бути минулим на момент
продажу;
кількість препаратів при продажі не може перевищувати їх кількість на
склад~.
Процеси
п · б жають основні операції або дії, що виконуються в системі:
роцеси ВІдо ра
23
L
ЧДТУ. 242303.008 ПЗ
Управління запасами: Додавання нових препарапв, оновлення
інформації про запаси;
Продаж препаратів: Обробка транзакцій продажу, включаючи
зменшення запасів та фіксацію продажів;
Обробка поставок: Реєстрація надходжень нових препарапв вщ
постачальників.
Ці елементи формують основу для розробки веб-застосунку, дозволяючи
ефективно управляти даними, процесами та взаємодіями в аптеці.
Словник предметної області:
Препарат: Лікарський засіб, який використовується для лікування,
профілактики або діагностики хвороб.
Запас: Кількість одиниць конкретного препарату, що зберігається на
склад~ аптеки.
Продаж: Акт кушвш-продажу препарату, що фіксується в систеМІ
обліку.
Клієнт: Особа або організація, яка купує препарати в аптеці.
Термін придатності: Період часу, протягом якого препарат зберігає свої
. . .
шкувалью властивосп.
Категорія: Класифікаційна група, до якої належить препарат
(наприклад, антибіотики, антигістамінні препарати).
Форма випуску: Фізична форма, в якій випускається медичний
препарат (наприклад, рідина, таблетки, капсули).
Рецептурний статус: Індикатор, що визначає, чи потрібен рецепт для
купівлі препарату.
Постачальник: Організація або особа, що постачає медичні препарати
в аптеку.
Звітність: Процес створення документів, що підсумовують фінансові та
оперативні результати діяльності аптеки за певний період.
24
ЧДТУ. 242303 .008 ПЗ
2.1.2 Елементи моделювання предметної області
Моделювання відбувалось з використанням мови UML, що була створена
для візуального моделювання складних та простих програм: їх структуру та
функціонал. Для цього, UML має велику кількість елементів, що полегшують
процес моделювання. При побудов і моделей з використанням UML,
використовуються основні три компоненти - об' єкти чи сутності, їх взаємодії та
діаграми .
Структурні об ' єкти відображають реальні сутності та речі , які мають
статичну поведінку. Їх приклади зображено на рис . 2.1.
- Classname клас відображає набір ідентичних речей, які
окреслюють функціональні можливості та властивості
об1єкта.
Елемнет Use Case зображує набір дій, які виконує
система для досягнення мети.
Найчастіше використовується у діаграмах варіантів
використання. Це об'єкт, який взаємодіє з
системою, наприклад, користувач.
Actor
ComponetJ компонент зображає фізичну частину
системи
Рисунок 2. 1 _ Структурні об'єкти [37]
25
►
ЧДТУ. 242303 .008 ПЗ
Поведінкові об'єкти зображую .
. . . ть поведшку системи . Наприклад у діаграмі
дtЯльносп, поведшка системи опис
ується за допомогою об' єктів , що зображено
на рис. 2.2.
І Початковий стан
Кінцевий стан
Дія Назва діяльності
Умова для виконання
Рисунок 2.2 - Об'єкти діаграми діяльності [37]
За необхідності елементи моделі можна згрупувати за допомогою об'єкту
' пакет'(расkаgе). Існують також об'єкти для створення описів і коментарів на
діаграмах(nоtе ).
Важливою складовою моделі є взаємодії між сутностями. Вони описують
як сутності повинні взаємодіяти між собою для коректної роботи системи,
26
ЧДТУ. 242303.008 ПЗ
модель якої створюється. Типи взаємодій на щаграмах позначаються
відношеннями(Рис. 2.3 )[ 15]
відношення асо~іа~ії
відношення залежності
--◊ відношення ar~era~iї
відношення ~омпози~ії
Рисунок 2.3 - Приклади відношень між об'єктами [37]
2.1.3 Робоча область моделювання
На моделі зображена робоча модель системи, з послідовністю передачі всіх
даних до БД. Див. рис. 2.4.
27
ЧДТУ. 242303.008 ПЗ
Рисунок 2.4 - Модель робочої області системи wеЬ-застосунку обліку медичних
препарат1в аптеки
На рисунку зображено інформаційний процес у системі обліку даних,
починаючи з користувача, який ініціює процес введення або запиту даних.
Користувач отримує доступ до системи, яка може включати аутентифікацію та
ініціацію сеансу . В самій системі відбувається обробка і внесення даних, після
чого оброблені дані пересилаються до бази даних для зберігання. База даних
класифікує ці дані як інформацію про медичні препарати та пов' язані з ними
часові мітки, терміни придатності чи час доставки, забезпечуючи ефективність і
логічність процесу від початку і до кінця .
28
ь
ЧДТУ. 24 О .008 П
z.2. Форм) ва11ня то а1шліз онмоr
р ['(іл ' копт к -•ті ро· роб1<и npor ам1 .
• . р" 1 го забезпечення тщя роботи аптек .
1'1111,нчно вn лпвп:м ля · об~ n чення . . :· . . . .. .
. . . , . усп1шно1 реащзацн проекту. Цей роздjл
А~тn. ьно оnп є проц - . ору ) аналізу та . . .. .. .
· валщацн вимог до системи .
. І Ф рм) вання внмог д про~ а .
· Р много забезпечення . Первинні і детальні
в нм 0111. Вн юги замовн11ка і розробни Ф· .. . .
ка. ункцюналью та нефункцjональні
вн ,югп
Форму.вання в11мог до програмного забезпечення
Вимоги до програмного забезпечення включає:
- техніко-економічне обrрунтування;
- збір вимог
специфікація вимог до програмного забезпечення ·
'
- перев1рка вимог до програмного забезпечення.
Збір вимог.
У разі позитивного результату техніко-економічного обrрунтування
проекту, наступним етапом є збір вимог користувача. Для цього аналітики та
інженери взаємодіють з клієнтом та кінцевими користувачами, щоб з'ясувати їхні
бажання стосовно того, які функції має мати програмне забезпечення та які
функції вони хочуть включити до нього.
Специфікація вимоr до проrрамного забезпечення,
SRS, який створює системний аналітик після збору вимог, є документом,
що описує, як програмне забезпечення буде взаємодіяти з апаратним
забезпеченням, зовнішніми інтерфейсами, його швидкістю роботи, часом
відгуку, переносимістю, ремонтопридатністю, швидкістю відновлення після
збою, безпекою, якістю, обмеженнями та іншими характеристиками. Вимоги від
l<Лієнта записуються природною мовою, але системний аналітик перетворює їх
на техн· 6 б ли зрозумілі для розробників. В SRS мають бути
1чну мову, що вони У
вказані вимоги користувача та технічні вимоги, опис дизайну, формат форм та
др\п,- гр ф' • ф ~ ні та математичні позначення тощо. Після
J'" а 1чного штер еису, умов
29
. ----- --
г
ЧДТУ. 242303.008 ПЗ
розробки SRS вимоги перевіряються на практичність, відповідність
функціональності та області програми б • ·
ого за езпечення, яюсть та завершеюсть .
це забезпечує те, що програмне забе зпечення б уде розроблене в•щ пов•щ но до
вимог користувача та функціональних вимог.
Первинні і детальні вимоги
Розробка веб-застосунку для обліку медичних препаратів аптеки вимагає
встановлення чітких первинних і детальних вимог, які забезпечать злагоджену
. .
взаємод1ю м1ж р~зними складовими системи та відповідність очікуванням
користувачш .
Первинні вимоги формулюють основні функціональні та
нефункціональні атрибути системи. З функціонального боку, система має
забезпечувати ефективне управління запасами медичних препаратів, можливість
замовлення нових поставок, реєстрацію продажів та автоматичну генерацію
звітів. Нефункціональні вимоги охоплюють безпеку даних, надійність системи,
можливість її інтеграції з іншими системами та здатність масштабування для
обробки збільшення обсягу даних та користувачів.
Детальні вимоги включають специфікації, необхідні для реалізації кожної
складової системи. У сфері управління запасами це стосується підтримки
категоризації препаратів, відстеження термінів придатності, історії змін цін.
Функціональність замовлень має інтегруватися з системами постачальників для
автоматизації процесу замовлення, включаючи ведення запис1в про статус
замовлень. Щодо продажу, система має включати можливості швидкої видачі
рецептів , обробки платежів та ведення обліку продажів. Звітність повинна
дозволяти налаштування параметрів для різноманітних звітів та їх експорт в
зручні формати для аналізу.
Вимоги замовника і розробника
Для розробника : мінімальними вимогами для розробки програми і будуть
32-бітний процесор. Щонайменше 3 гігабайти оперативної пам'яті , звісно як і у
випадку жливо запустити базу навіть на 512 мегабайтах, але для
з процесором мо
розробки в сучасних IDE та для стабільної роботи та подальшого росту бази
30
>
ЧДТУ. 242303.008 ПЗ
необхідні як мінімум 2 Гб. Процесор з 2 ядрами. Також знадобиться жорсткий
диск, рекомендовано мати диск з об'ємом 128 Гб та більше. Дисплей для
виведення інформації та периферія для введення.
Для замовника: особливі вимоги відсутні, для використання функціоналу
додатку буде достатньо будь-якого сучасного комп'ютера.
Функціональні та нефункціональні вимоги
Формулювання вимог до програмного забезпечення є важливим кроком у
розробці веб-додатку для управління лікарськими засобами в аптеці. Ці вимоги
не лише визначають обсяг проекту, але й гарантують, що кінцевий продукт
відповідатиме потребам його користувачів - фармацевтів, аптечних техніків і,
можливо, самих клієнтів. Ось деякі з потенційних вимог до такого проекту:
Функціональні вимоги
Управління користувачами:
безпечна автентифікація та авторизація користувачів для різних ролей
( фармацевт, аптечний технік, адміністратор тощо);
управmння профілями користувачш, що дозволяє створювати,
редагувати та видаляти облікові записи користувачів.
Управління запасами лікарських засобів:
моЖJШвість додавати, оновлювати та видаляти деталі інвентаризації
ліків, такі як назва препарату, виробник, номер серії, термін
придатності, кількість та ціна;
сповіщення про низький рівень запас1в та препарати, термш
придатності яких закінчується.
Обробка рецептів:
моЖJШвість обробляти рецепти, включаючи записи про видачу ліків;
інтеграція з електронними рецептами, що дозволяє безпосередньо
отримувати та обробляти електронні рецепти від постачальників
медичних послуг.
31
ЧДТУ. 242303.008 ПЗ
Управління продажами та транзакціями:
. . .
rенерац~я звп~в про продажі та історії транзакцій для фінансового
моніторингу та аналізу.
Управління замовленнями:
інструмент для розміщення замовлень на нов1 запаси ВІД
постачальниюв;
відстеження статусу замовлення від моменту розміщення до доставки.
Звітність та аналітика:
генерація звітів про рівень запасів, продажі, прострочені препарати та
фінансові звіти;
анаштична панель для розуміння тенденцій продаж1в, популярних
препаратів та швидкості обороту запасів.
Перевірка інформації про лікарські засоби та їх взаємодію:
база даних лікарських засобів, включаючи протипоказання, побічні
ефекти та взаємодію препаратів;
інструмент для перевірки взаємодії препарат1в та попередження
фармацевтів під час відпуску ліків.
Нефункціональні вимоги
Продуктивність:
додаток повинен бути швидким і здатним працювати з деюлькома
користувачами одночасно без значного зниження продуктивност1.
Безпека:
·ин~ их заходів безпеки для захисту конфіденційних
впровадження над~
. ф ц~я· про користувача та медичн1 записи;
даних, таких як ІН орма
· · · м охорони здоров'я та законам про захист даних.
ВlДПОВlДНlСТЬ норма
Зручність використання:
. .. . ~ учний інтерфейс для ефективної навігації та
шту1тивно зрозумшии та зр
роботи персоналу аптеки.
32
, . __ ,..,..
- -------- ----------- .
ЧДТУ . 242303 .008 ПЗ
Масштабованість:
система повинна бути масштабованою, щоб відповідати зростаючим
запасам і розширенню діяльності аптеки.
Надійність і доступність:
висока надійність систе ми з м1· ю·м альним часом простою;
регулярне резервне копіювання та план аварійного відновлення для
забезпечення цілісності даних.
Підтримка та обслуговування:
забезпечення технічної підтримки та оновлення системи для вирішення
нових потреб і потенційних проблем;
чпко визначивши Ц1 вимоги з самого початку, розробники можуть
гарантувати, що веб-додаток ефективно відповідає операційним
потребам аптеки, підвищує ефективність управшння аптекою та
покращує догляд за пацієнтами завдяки точному та своєчасному
відпуску ліків.
2.2.2 Формування вимог за допомогою діаграми прецедентів
Один з найважливіших етапів проектування системи - ідентифікація
прецедентів та дійових осіб. Цей процес включає чітке визначення системи та її
оточення, визначення того, як дійові особи взаємодіють з системою, а також
визначення очікуваного функціоналу системи (варіанти використання). Для
детального опису функціоналу системи використовуються загальні поняття з
глосарії предметної області. Ці дії зазвичай виконуються у такій послідовності:
визначення дійових осіб, визначення прецедентів (варіантів використання),
складання опису кожного прецеденту та опис моделі прецедентів в цілому (у
тому числі створення словника предметної області) [9].
33
ЧДТУ. 242303.008 ПЗ
Рисунок 2.5. - Графічне представлення д~·агра · weь ми прецедент1в для -
застосунку обліку медичних препаратів аптеки
Діаграма прецедентів (Use Case Diagram) для теми "Розробка wеЬ
застосунку обліку медичних препаратів аптеки" може включати наступні основні
прецеденти:
1 Користувач (адміністратор) реєструється у системі:
- користувач вводить свої особисті дані;
- система перевіряє введені дані на валідність;
- користувач отримує підтвердження реєстрації.
2 Користувач (адміністратор) авторизується в системі:
користувач вводить свої облікові дані;
- система перевіряє дані для авторизації;
користувач отримує доступ до функціоналу системи.
З Користувач (адміністратор) додає новий медичний препарат:
користувач вводить дані про новий медичний препарат;
- система зберігає введені дані.
4 Користувач (адміністратор) редагує існуючий медичний препарат:
- користувач вибирає медичний препарат для редагування;
- користувач вносить зміни в дані про обраний медичний препарат;
- система зберігає зміни.
5 к ( • · ) видаляє медичний препарат:
ористувач адм1шстратор
34
ЧДТУ. 242303.008 ПЗ
- користувач вибирає медичний препарат для видалення;
система шдтверджує видалення·
'
медичний препарат видаляється з бази даних.
6 Користувач (фармацевт) переглядає наявність медичних
препаратів:
користувач переглядає список медичних препаратів;
система відображає інформацію про наявність препаратів на складі.
7 Користувач (фармацевт) здійснює пошук медичного препарату:
користувач вводить дані для пошуку медичного препарату;
система відображає результати пошуку.
8 Користувач (клієнт) реєструється для замовлення препаратів
онлайн:
користувач вводить свої особисті дані для реєстрації;
система зберігає введені дані.
9 Користувач (клієнт) замовляє медичні препарати онлайн:
користувач вибирає потрібні медичні препарати;
користувач вводить даю для доставки;
кистема підтверджує замовлення та оновлює інформацію про
наявність препаратів на складі.
Ці прецеденти відображають основний функціонал системи розробки wеЬ
застосунку обліку медичних препаратів аптеки.
2.3 Проектування логічної структури програмного комплексу
В цьому розділі буде розписано діаграму класів, діаграму пакетів
2.3.1 Діаграми класів
Діаграма класів _ це статичне зображення структури моделі, яке відображає
деІ<.Ларативні елементи, такі як класи, типи даних, їх вміст та відносини між
ІІИми. Хоча діаграма класів може включати позначення для пакетів та їх
ВІ<JІадених . ... нииv фокус на статичних елементах моделі. Імена
елеменпв, 11 основ
35
ЧДТУ. 242303.008 ПЗ
•в повинні відображати поняття пре .. .
J(Jiact дметно~ област1 та описувати тільки одну
суrність.
По темі було розроблену наступну діаграмму класів [9].
nn•rt.м• ІнфоршцІ• Достuu
,..... - .--.
КормстуаочІ
С.,,ад
~luпuullllpmapaт
½
За.,1оа.1tИІUІ
~
смст.м~
~
.. . ~ ... ~
Рисунок 2.6. - Діаграма класів для wеЬ-застосунку обліку медичних препаратів
аптеки
На цій діаграмі зображені різні класи, а саме:
Діаграма класів для системи обліку медичних препаратш аптеки веб-
застосунку може містити наступні класи:
1 Користувач.
2 МедичнийПрепарат.
з Замовлення.
4 Склад.
5 Доставка.
б Платіжна інформація.
7 Веб-застосунок.
ЦІ. м~ж· собою для забезпечення функціональності
класи взаємодіють
сист · птеки веб-застосунку.
еми обліку медичних препарапв а
36
р
ЧДТУ. 242303.008 ПЗ
Тепер додамо до класів атриб уrи · 1 отримаємо таку діаграму (рис.2.5.)
.. Платіжне Інформація Доставка
IUJ)<C8
Т1tП .------.
ДОС Т&аQІ
n.,ет~~·
ст•ч·с .:iocтu..:.11
С:)'НА
i.':J.C R"IHihi:t\OTO'D 3a..\f08."IC RJU
Корнстv••ч І
Ім 'я
ідентифнса1ор
nвроnь Ctrn•д
l\ l~•~11nt1Пp•nap :11т
CrutCOK
мо.1 аа -
½ ~te.:urrмпx n~nаратш
"''" J<iл1.~cr•
оmк:
ро,:м.ішсин.1
t.:і"І•t.:.ість
цін" Замоа.,tмк111
~ і.:1е.КТ1tф і 1.:атор
D..'ІОDЛСНИJІ
;,;ета
Система
~ інrсрфеRс
~ри:сту~в.ча,
~~-вкuіона.nвість
Рисунок 2.7. - Діаграма класів для wеЬ-застосунку обліку медичних препаратів
аптеки з атрибутами
Було додано наступні атрибути:
1 Користувач:
Атрибути: ім'я, ідентифікатор, пароль.
2 МедичнийПрепарат:
Атрибути: назва, код, опис, кількість, ціна.
3 Замовлення:
Атрибути: ідентифікатор замовлення, дата, статус.
4 Склад:
Атрибути: список медичних препаратів, кількість, розміщення.
5 Доставка:
Атрибути: адреса доставки, статус доставки, ідентифікатор замовлення .
6 Платіжна інформація:
Атрибути: тип платежу, сума, статус.
7 Веб-застосунок:
37
ЧДТУ. 242303.008 П
Атрибути : інтерфейс користувача , ф · ·
ункцюнальюсть .
2.3.2 Діаграми пакетів
діаграма пакетів· (Package d1"a gram ) . v
є єдиним шструментом, якии дозволяє
керувати складністю модел· 1· · Граф · v
1чнии символ пакету використовується для
графічного зображення пакетів на діаграмах.
По темі було розроблену наступну діаграмму пакетів [9].
і\Іо~·.1ь
t..'DрПtТ)"DачІв МОЗ}·а"
u•dвІпр1тор1
Mo~·,ii.
ІннрфtІІ"'·
Мо~·.1ь
оп.11атп
1\foJQ·,iь
.!І.ОСТ8В1-Ш
Рисунок 2.8 - Діаграма пакетів для wеЬ-застосунку обліку медичних препаратів
аптеки
Розроблювану систему можна розглядати як сукупність пакетів:
Діаграма пакетів для системи обліку медичних. препаратів аптеки веб
застосунку може бути організована наступним чином:
І Модуль користувачів:
Включає в себе класи та компоненти, пов'язані з авторизацією,
реєстрацією та управлінням користувачами;
2 Модуль адміністратора:
38
ЧДТУ. 242303.008 ПЗ
Містить функціональність, спрямовану на управління медичними
препаратами ' таку як додавання , ·
редагування та видалення препарапв;
3 Модуль клієнтів:
Включає в себе функції для клієнтів, такі як перегляд наявносп
препараnв, замовлення та оплата·
'
4 Модуль складу:
Містить компоненти, пов'язані з управлінням запасами медичних
препаратів на складі;
5 Модуль доставки:
Включає в себе функції, пов'язані з управлінням доставкою медичних
препарапв кл1єнтам;
б Модуль оплати:
Містить компоненти, які забезпечують обробку платежів за замовлені
препарати;
7 Модуль інтерфейсу:
. . .
Модуль, ЩО м1стить компоненти, ВlДПОВІДалью за інтерфейс
користувача, включаючи веб-сторінки, форми та інші елементи взаємодії з
користувачем;
8 Модуль даних:
Включає в себе компоненти, пов'язані з управшнням базою даних,
збереженням та витягом інформації про медичні препарати, замовлення,
користувачів та інше;
Така організація модулів у вигляді пакетів дозволяє логічно групувати
компоненти за їх функціональністю та роллю в систем~, що полегшує
розробку, тестування та підтримку системи.
39
ь
ЧДТУ. 242303.008 ПЗ
2.4 Архітектурне проектування
В цьому розділі буде розписано щаграму компонентів та діаграму
розгортання.
2.4.1 Діаграма ко~mонентів
Діаграма компонентів (Co111ponent diagia.111) показує зв'язки між фізичними
або логічними модулями, які складають систему, що моделюється. Додавання
зв'язків між компонентами на діаграмі може допомогrи краще зрозуміти
архітектуру системи. У мові UМL 1, компонент зображується як прямокутник з
двома меншими прямокутника.ми зліва. Внугрішній прямокутник містить ім'я
ко~mонента і, можливо, додаткову інформацію. У мові UМL 2, компонент
зображується як прямокутник з необов'язковим ключовим словом "component" у
вигляд~ стереотипу.
На відміну від попередніх діаграм, діаграма компонентів описує фізичне
представлення системи та дозволяє визначити архітектуру розроблюваної
системи, встановлюючи залежності між програмними компонентами. У багатьох
середовищах розробки, модуль або компонент може відповідати файлу.
Діаграми компонентів використовуються для візуалізації високорівневої
структури програмного забезпечення, що полегшує розумшня 1 шдтримку
системи. Вони також допомагають ідентифікувати основні компоненти,
залежності між ними 1 способи їх взаємодії, що є критично важливим для
Усnіm.ного проєктування та розробки програмних систем .
по . 6 б ну наступну діаг·р амму компонентів [9).
тем1 уло розро ле
40
ЧДТУ. 242303 .008 ПЗ
Моцу:п,
Мо~-ль звirnocti
аЕУ~НТ11фіаці'і
Модуль
об:ш.у запасі.Е
Mo.:t)m.
управ,1іння
Модуль
~па аJамв
06.lik)' З~ІОВ."І~НЬ
С~рВ~ІШЙ
засtосунок cs~,y~
Application):
Корвстуваш.Dnі
івт~ф~ііс (lЛ) :
АРІ д,'lЯ АРІ=
постача.,:ьяшсів зовнішніх CBC'tt:\t
Рисунок 2.9 - Діаграма компонентів для wеЬ-застосунку обліку медИЧІШХ
препарапв аптеки
Діаграма компоненпв для wеЬ-застосунку обліку медичних препаратів
аптеки могла б виглядати наступним чином:
Користувацький інтерфейс (UI):
Клієнтський модуль: Відображає інтерфейс користувача, через який
працівники аптеки можуть вводити, переглядати та керувати даними про
медичні препарати.
Серверний застосунок (Server Application):
модуль автентифікації: Відповідає за перев1рку правильності входу
користувачів у систему;
модуль управління препаратами: Забезпечує функціонал для
створення, оновлення, видалення та перегляду інформації про
препарати;
41
ЧДТУ. 242303.008 ПЗ
модуль о.б ліку запасів·· В іде тежує наявю·с ть та необх•щ юс• ть закуш· вш·
препаратш;
модуль звітності·· Генерує зв·п и про продаж~,· запаси та використання
препарат1в;
модуль обліку замовлень: Дозволяє керувати замовленнями на
постачання нових медичних препаратів;
База даних (Database):
Сховище даних: Централізоване сховище всієї інформації, пов'язаної з
медичними препаратами, замовленнями, запасами та звітністю.
Інтеграційний шар (lntegration Layer):
АРІ для постачальників: Інтерфейси для автоматичного обміну даними
з системами постачальників медичних препаратів;
АРІ для зовнішніх систем: Забезпечує можливість інтеграції з іншими
системами, такими як електронні медичні записи;
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Діаграма розгортання в UМL відображає обчислювальні вузли,
компоненти та об'єкти, що працюють на цих вузлах під час виконання програми.
На діаграмі відображаються лише компоненти, які мають робочі екземпляри,
тоді як компоненти без екземплярів можна відобразити на діаграмах компонент.
Діаграма розгортання зосереджена на відображенні робочих екземплярів
компонентів, тоді як діаграма компонент зосереджена на зв'язках між різними
типами компонентів.
Діаграма розгортання (Deployment Diagram) в UМL є діаграмою, що
відображає апаратні компоненти, на яких виконується система, та їх зв'язки [9].
Для теми "Розробка wеЬ-застосунку обліку медичних препаратів аптеки",
діаграма розгортання може виглядати так:
42
ЧДТУ. 242303.008 ПЗ
/ ,,
.ае~сер_вер_:
,,
/ ,, ?
/ /
~МР- ~В~JШ №реж~sа
з.ШОL.)Жів: .:rопочіющх rep,11itш інфршр_}ЦІ:ра:
/
,,, -, / /
~ К,1іє1ш:ь~;і
~ ~ ПРЯ!:ІР.Q··:
/
Рисунок 2.1 О - Діаграма розгортання для wеЬ-застосунку обліку медичних
препарапв аптеки
Діаграма розгортання для wеЬ-застосунку обліку медичних препаратів
аптеки може вкшочати наступні елементи:
Веб-сервер:
Відповідає за розміщення веб-застосунку та обробку запитів користувачів.
Може містити:
Статичний контент: НТМL, CSS, JavaScript файли.
Динамічний контент: Скрипти серверної сторони, яю генерують веб-
сторінки на основі запитів користувачів.
Сервер застосунків:
Виконує бізнес-логіку застосунку та управляє взаємодією з базою даних.
Може містити різні модулі, як-от: модуль управління препаратами, модуль
об л~· ку запасів, модуль замовлень тощо.
43
>
ЧДТУ. 242303.008 ПЗ
База даних:
Сервер бази даних, який збер1·гає . .
вс1 даю застосунку, включаючи
інформацію про препарати, замовлення, користувачів та транзакції.
Сервери допоміжних сервісів:
Можуть включати системи обробки платежів, системи доставки,
зовнішні аналітичні сервіси тощо.
Клієнтські пристрої:
Комп'ютери, смартфони, планшети, які використовуються персоналом
аптеки або клієнтами для доступу до веб-застосунку.
Мережева інфраструктура:
Містить компоненти мережі, такі як маршрутизатори, комутатори,
брандмауери та балансувальники навантаження, які забезпечують безпечне та
ефективне з'єднання між серверами та клієнтськими пристроями.
На діаграмі розгортання кожен із цих елементів буде представлений як
окремий вузол, з'єднаний з іншими вузлами лініями, які вказують на взаємодію
та комунікацію між ними. Наприклад, веб-сервер може бути з'єднаний з
сервером застосунків через внутрішню мережу, а сервер бази даних може бути
підключений до сервера застосунків через захищене з'єднання. Клієнтські
пристрої з'єднуються з веб-сервером через Інтернет або локальну мережу.
2. 5 Моделювання поведінки системи
В цьому розділі буде розписано діаграму діяльності, діаграму послідовності,
Діаграму комунікації та діаграму скінченного автомату.
2.5.1 Діаграма діяльності
Для опису логіки процедур, бізнес-процесів 1 потоюв використовують
діаграми діяльності. Ці діаграми схожі на блок-схеми, але вони дозволяють
показати паралельні процеси. За допомогою діаграми діяльності будь-хто, хто
здійснює процес, може визначати порядок дій. Тобто, діаграма встановлює
Правила обов'язкової послідовності дій, які повинні бути виконані . Діаграми
44
►
ЧДТУ. 242303 .008 ПЗ
діяльносп також корисні при розробці паралельних алгоритмів, де незалежн1
потоки можуть виконувати роботу паралельно [9].
Нижче представлена наступна діаграма діяльності
•
Користувач
(фар:,.,~ац~вт або
а.DІ.ін істратор) вхо.]пrь
& СИСГ~:,J)-
Сист~ма
запитує лоrін і паро.,ь
Корист,о.1ч
отрюrує .]ОСТУП .:io _____ ,, е r.poИLUoc.._ _ ___J
основно~ +--r~-,-
інr~рф~йсу
- ~ Оно-в.,-~~нн я
П~р~r1Ц.] ~ До;~ав.анш;:
інфорщ.ції про
запасів препаратів новоrо пр=:;
пр~парат
Фор:!J)-вання
~-- ( Перш,ц
за.'-! ов.,еНВJІ на звітів
постачанн.я
Рисунок 2.11 - Діаграма діяльності для wеЬ-застосунку обліку медичних
препараnв аптеки
Діаграма діяльності може бути корисною для моделювання wеЬ
застосунку обліку медичних препаратів аптеки.
Діаграма діяльності для веб-застосунку обліку медичних препаратів
аптеки відображає основні процеси та їх взаємозв'язок в системі:
45
ЧДТУ. 242303 .008 ПЗ
1 Початок: Користувач ( фармаце б . .
вт а O адмп-нстратор) входить в
систему;
2 Авте.н тифікація: Система запиту · ·
є лопн 1 пароль;
З У сшшна автентифікація·· к ористувач отримує доступ до основного
інтерфейсу;
4 Невдала а.в тентифікація·• Си стема виводить пов•щ омлення про
помилку 1 пропонує повторити спробу;
5 Вибір дії:
Перегляд запасів препаратів: Користувач запитує інформацію про
наявю препарати.
Додавання нового препарату: Користувач заповнює форму додавання
нового препарату.
Оновлення інформації про препарат: Користувач обирає існуючий
препарат та оновлює його дані.
6 Формування замовлення на постачання: Користувач формує
замовлення на нові поставки препаратів.
7 Перегляд звітів: Користувач запитує звіти за певний період.
8 Обробка дії:
Для перегляду запасів система отримує дані з бази даних і відображає
їх користувачу.
При додаванні нового препарату інформація зберігається в базі даних.
При оновленні інформації про препарат старі дані оновлюються в базі
даних.
При формуванні замовлення інформація про нове замовлення
зберігається в системі та відправляється постачальнику.
Для перегляду звітів система генерує звіти на основі даних з бази даних.
9 Завершення дії: Користувач отримує результат обраної дії
(інформацію, підтвердження додавання чи оновлення, звіт).
1О Вихід з системи: Користувач завершує роботу та виходить з системи.
На кожному кроці, де користувач має вибір дії, діаграма містить
розгалуження, яке веде до відповідних дій. Цикли відсутні, але є
46
ЧДТУ. 242303.008 ПЗ
можJШвість повернення до вибору дії після завершення кожної операції,
що дозволяє користувачу виконати декілька дій за одну сесію.
2.5.2 Діаграма послідовності
Діаграма послідовності використовується для зображення об'єктів, яю
беруть участь У взаємодії та послідовності повідомлень, які вони обмінюють між
собою. Ці діаграми є одним із найпопулярніших способів представлення
детальних вимог на етапі аналізу. Головна мета перетворення полягає у
збільшенні рівня точності, формалізації вимог та їх представленні у вигляді,
необхідному для подальшого проектування [9].
Нижче наведено можливу діаграму послідовності для wеЬ-застосунку
обліку медичних препаратів аптеки.
Діаграма послідовності зазвичай використовується для відображення
взаємодій між об'єктами в певному порядку часових подій. Ось приклад
послідовності дій, які можуть відбуватися при розробці веб-застосунку для
обліку медичних препаратів аптеки:
користувач (User): Ініціює процес входу в систему;
веб-Інтерфейс (Web Interface): Приймає запит на вхід;
система Автентифікації (Authentication System): Перевіряє даю
користувача;
база Даних Користувачів (User Database): Повертає інформацію про
статус користувача (успішний вхід чи ні);
Користувач: Отримує доступ до основного інтерфейсу.
в б -І ~ в· 6 є доступні функції (наприклад, перегляд запасів,
е нтерфеис: що ража
ЦодаваННя нових препаратів).
47
....
ЧДТУ. 242303 .008 ПЗ
Кор11сt)-ваЧ Веб-Інтерфейс Сnщщ Ynpa1iioц
Пpcщ,>tum
t---- в.u:i в __ __..,
СИШ.\!)" перевірка даних
': г--- в.~ в lР' nеревірка
: , сксtе.\!)' стаІ}-су
' '
__ • ______ • _. ___ • __ • __ • ___ • : : liOJЖCl)"E3'Ll
· · .. · · · .. · · ·- · · ·:- · -- -~·спішна• .. -----........ .. ... __- ~ .. ............ .. ___ . _. .. _. __ .. ___ .. ___ _
' ''
ОІрІ!ШІ!І!S ДDct)"~
· • • • • •• • • • • •• • • • •уtІШШ!О ·• • • • • • • • • • ••••••
Ві,1обра;швя дОСі}~ фувщій
Обробка заmпу
заmпш
~ ~Ck)° препараrів
'
Пере,.ача сшю.у претраrів
Відобршння спиа.у ~
ВОuПЬ ' ~
.. .............. ····=: __ . ... i+.-. -..-.. - ..- .. ~~J~
про уСП!ІІІІіt ОВОВ.1~Ч : ,
: :
Рисунок 2.12 - Діаграма послідовності для wеЬ-застосунку обліку медичних
препаратів аптеки
Користувач: Надсилає запит на перегляд списку препаратів.
Система Управління Препаратами (Medication Management System):
Обробляє запит.
База Даних Препаратів (Medication Database): Надає дані про препарати.
48
ЧДТУ. 242303.008 ПЗ
Веб-Інтерфейс: Відображає інформацію про препарати .
Користувач: Вносить зміни або оновлює інформацію про препарати .
Система Управління Препаратами: Оновлює дані в базі даних препаратів .
База Даних Препаратів: Зберігає оновлення.
Користувач: Отримує підтвердження про успішне оновлення.
На діаграмі послідовності кожна з цих взаємодій буде представлена як
горизонтальна стршка, що вказує від відправника до отримувача, з часом, що
просувається вертикально вниз. Об'єкти (User, Web Interface, Authentication
System тощо) зазвичай розміщуються зліва направо у верхній частині діаграми в
порядку їх активації.
2.5.3 Діаграма комунікації
Діаграма комунікації (Communication Diagram) - це один із типів діаграм
UМL, який використовується для візуалізації взаємодії між об'єктами або
. .
компонентами системи, яю передають повщомлення один одному.
На діаграмі комунікації об'єкти чи компоненти представляються як
прямокутників чи гуртків, а зв'язок між ними - як стрілок, які вказують напрям
передачі повідомлень. Кожен зв'язок може бути підписаний повідомленням, яке
надсилається від одного об'єкта або компонента до іншого.
Діаграма комунікації може бути використана для розуміння, які об'єкти
взаємодіють між собою в системі та які повідомлення передаються між ними у
рамках певних сценаріїв. Вона може допомопи розробникам краще зрозуміти
логіку роботи системи та виявити потеІЩійні проблеми чи покращення у процесі
взаємодії між об'єктами.
Діаграма комунікації для розробки веб-застосунку обліку медичних
nреnаратів аптеки відображає взаємодії між різними учасниками (об'єктами)
nроцесу та повідомленнями, які вони обмінюють.
49
ЧДТУ. 242303.008 ПЗ
10.стотус
,о..,rо~,еННІ
І . ОtрІІШННІ ".У : , Спстема ~
___,О11 _с.....': ~~'_-oc..:..тym_un.....:np,=no~p=a·•n= __.. ...J правл~ння Препарата мп г----6_. ,._.._ о.._ 1rк_НІ______ ,
~-.4,.c:;;;nn;;;;co;;:-,.,; ;o;; :;cч;:;;·nю=n=--=np=e=n•-p•~тi_n _\
5. ,омо&.1еКН1 ,__ __7 .тер,шш._ ___
ДОСІUПІ
Фармацевт Посп1чальн11к
2. Отрш10КН1
,.. : ~::::НІ с •с•т ~осч•пlн, " npenopon•
З.сm1сок
. tОСТ)'ПКІL~ їреnороrів
9.ycnimиe
оновл:е
База
Даних
Рисунок 2.13 - Діаграма комунікації для wеЬ-застосунку обліку медичних
препаратів аптеки
Ось як може виглядати така діаграма:
Учасники:
Фармацевт (Pharmacist): Працівник аптеки, який керує запасами
препаратів.
Система Управління Препаратами (Medication Management System): Софт,
ЯІ<Ий дозволяє керувати інформацією про медичні препарати.
База Даних (Database): Зберігає дані про медичні препарати, їх наявність та
ІСТ .
ор~ю замовлень .
Постачальник (Supplier): Компанія, яка постачає медичні препарати.
Комунікація:
Фармацевт відправляє запит на Систему Управління Препаратами для
0rрим ання списку доступних препарат1в· .
Система Управління Препаратами запитує інформацію з Бази Даних.
50
ЧДТУ. 242303.008 ПЗ
База Даних повертає список препара · С .
т1в истем1 Управління Препаратами.
система У правління Препаратами
передає список препаратів Фармацевту.
Фармацевт вибирає препарати щ
, 0 потре 6 ують дозамовлення, і відправляє
заМовлеННЯ через Систему Управління Препаратами.
Система У правління Пре парат ами вщ· правляє запит на дозамовлення
постачальнику.
Постачальник підтверджує отримання замовлення і відправляє інформацію
про терміни доставки до Системи Управління Препаратами.
Система Управління Препаратами оновлює Базу Даних з інформацією про
нове замовлення.
База Даних повщомляє Систему Управління Препаратами про усшшне
оновлення.
Система Управління Препаратами інформує Фармацевта про статус
замовлення та очн<увану дату доставки.
На діаграмі комунікації кожен з цих кроюв представлений у вигляд~
повідомлення між об'єктами, зі стрілками, що вказують напрямок комунікації.
Об'єкти розташовуються на діаграмі так, щоб відображати логіку взаємодії та
послідовність обміну повідомлеІПІЯМИ.
2.5 .4 Діаграма скінченного автомату
Діаграма кінцевого автомата (Finite State Machine diagram) - це один із
типів діаграм UМL, який використовується для моделювання поведінки системи
У вигляді кінцевого автомата, тобто математичної моделі, яка є кінцевою
кількістю станів і
переходів між ними.
На діаграмі кінцевого автомата кожне стан системи представлено як
еліпса , а п • и - як стрілок , які вказують на умови переходу між ереходи м~ж станам
станами . К . бути підписаний умовою, яка має бути виконана,
ожен перехщ може
Щоб перейти до наступного стану•
51
ЧДТУ. 242303.008 П
Діаграма юнцевого автомата може бути використана для розумшня, як
система пере'х одить вщ одного с тану до ~· ншого залежно від певних умов, та як і
дії виконуються шд час переходу між станами. Вона може допомогп1
розробникам краще зрозуміти логіку роботи системи та виявити потенційні
проблеми чи покращення У процесі переходу між станами.
По темі роботи була створена наступна діаграма скінченого автомату.
Стани:
вхід у систему (Logi11): Початковий стан, де користувач вводить свої
облікові дані;
перегляд запас1в (View Inventory): Стан, в якому користувач може
переглядати наявю запаси медичних препаратів;
додавання/оновлення препаратів (Add/Update Medication): Стан, де
користувач може додавати нові препарати або оновлювати інформацію
. .
про 1снуюч1;
замовлення препаратш (Order Medication): Стан, в якому користувач
формує замовлення на нові поставки препаратів;
перегляд звітів (View Reports ): Стан, в якому можна переглядати
різноманітні звіти (наприклад, про продажі, запаси);
вихід з системи (Logout): Кінцевий стан, коли користувач завершує роботу
з системою;
Переходи:
вхід успішний: з "Вхід у систему" до "Перегляд запасів";
перегляд запасів: можливий перехід до "Додавання/оновлення препаратів" ,
"Замовлення препаратів", "Перегляд звітів" ;
додати або оновити препарат: з "Додавання/оновлення препаратів" назад
до "Перегляд запасів";
формування замовлення: з "Замовлення препаратів" назад до "Перегляд
запасів"·
'
п ереrляд зв·п ш· : мо жливии~ повернення до "Перегляд запасів";
вих·щ з системи : з будь-я.к ого ста ну до "Вихід з системи"·
52
....._
ЧДТУ. 242303 .008 ПЗ
•
Замовлення
Пере'=
Переrляд
запасів
Oкor,:1eRІU
Переrляд
Додавання/
звітів в,"';;.~
оновлення
препаратів
Рисунок 2.14 - Діаграма скінченого автомату wеЬ-застосунку обліку медичних
препарапв аптеки
Ця діаграма відображає можлив1 стани системи обліку медичних
препаратів у аптеці та переходи між цими станами, засновані на діях
користувачів . Вона допомагає розробникам і аналітикам зрозуміти логіку
взаємодії користувачів з системою та спроектувати інтерфейс і функціонал
застосунку відповідно до потреб користувачів. [9].
53
ЧДТУ. 242303.008 ПЗ
Висновки до другого розділу
Для опису вс~х процесів, які відбувалися під час розробки додатку,
використовувалась уніфікована мова моделювання (UМL ). у сі діаграми можна
умовно роздшити на поведінкові та структурні. Поведінкові діаграми
відображають процеси в модельованому середовищі, а структурні діаграми -
елементи, що складають систему. Однак, одні і ті ж типи діаграм можуть
використовуватись як для моделювання бізнес-процесів, так і для проектування
архітектури. Одне з завдань UМL полягає в тому, щоб служити засобом
спілкування всередині команди та спілкування з замовником. Діаграми UМL
можуть бути використані для змоделювання архітектури великих проектів, де
можна зібрати як великі, так і дрібні деталі та намалювати каркас (діаграму)
програми. Для створення моделі UМL з існуючого програмного коду можна
використовувати зворотне проектування. У проекті бакалаврської роботи були
створені діаграми розгортаШІЯ, комунікації, діяльності, компонентів, пакетів,
класів , послідовностей та прецедентів.
54
ЧДТУ. 242303 .008 ПЗ
3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
3.1 Розробка програмного комплексу
В розділі буде розглядатись процес розробки програмного забезпечення
обліку медичних препаратів аптеки ..
З .1.1 Обrрунтування вибору засобів реалізації
Розробка wеЬ-застосунку для обліку медичних препаратів у аптеці вимагає
обертання та використання відповідних технологій та інструментів для
забезпечення ефективності, безпеки та зручності використання для користувачів.
у цьому розділі розглянемо основні технології та інструменти, які можуть бути
використані для розробки wеЬ-застосунку в контексті обліку медичних
препаратів у аптечному бізнесі.
НТМL5 (HyperText Markup Language ): НТМL5 є стандартом для розмітки
та представлення контенту в інтернеті. Використання НТМL5 дозволяє
створювати структуровані та семантично правильні сторінки, що полегшує їхнє
розуміння браузерами та пошуковими системами.
CSSЗ (Cascading Style Sheets): CSS використовується для стилізації та
оформлення НТМL-елементів. З CSSЗ можна використовувати анімації, тіні,
градієнти та інші ефекти для поліпшення користувацького інтерфейсу.
JavaScript та фреймворки (наприклад, React, Angular, Vue): JavaScript
використовується для динамічної інтеракції та асинхронного взаємодії з
сервером. Фреймворки, такі як React, Angular чи Vue, допомагають в управлінні
станом додатку та забезпечують швидке та ефективне створення інтерфейсу.
Node.js: Node.js дозволяє використовувати JavaScript на стороні сервера.
Bin забезпечує високу продуктивність за рахунок неблокуючого
введення/виведення та широкого спектру модулів.
Django (Python): Django - це фреймворк для розробки веб-додатків на мові
55
ЧДТУ. 242303.008 ПЗ
o:porpa~яvпаННЯ Python. Він пропонує го · ·
1Y•1 - тов1 р1шення для багатьох завдань, таких
_яІ( автентифікація, робота з базою даних та створення АРІ.
Express.js (JavaScript/Node.js): Express.js - легкий фреймворк для розробки
серверних додатків на базі Node.js. Він дозволяє швидко налаштовувати сервер
та обробляти НТТР-запити.
MongoDB: MongoDB - нереляційна база даних, яка використовує
документ-орієнтований підхід. Вона підходить для зберігання структурованих
даних, таких як інформація про медичні препарати.
MySQL та PostgreSQL: Це реляційні бази даних, які можуть бути
використані для зберігання структурованих даних та забезпечення їх
консистентності та надійності.
Git та GitHub: Git використовується для контролю версій коду, а GitHub -
для спільної роботи та зберігання кодових репозиторіїв.
VSCode (Visual Studio Code): Це легкий та потужний редактор коду, який
підтримує багато мов програмування та надає багато корисних функцій для
розробки.
ЛRА та Trello: Інструменти для управшння проектом, як1 дозволяють
створювати завдання , відстежувати їх виконання та забезпечують комунікацію в
команді.
SSL (Secure Sockets Layer) та HTTPS: Для захисту передачі даних між
сервером та клієнтом.
JWT (JSON Web Tokens): Для безпечної аутентифікації та авторизації
користувачів.
OWASP (Open Web Application Security Project): Набір стандартів безпеки
д.!Ія захисту веб-додатків від різноманітних атак.
. .
Застосування вищезгаданих технологій та шструментш дозволить
створити надійний, швидкий та ефективний wеЬ-застосунок для обліку
мeдlft{utrv . ц1· враховуючи сучасні вимоги ДО розробки
•щл препарапв у апте ,
ІІроrрамноrо забезпечення.
56
....
ЧДТУ. 242303.008 ПЗ
З .1.2 Опис структурної ( функціональноі) схеми
Функціональна схема для системи обл~·
ку медичних препаратів аптеки
може включати наступні основні компоненти та процеси:
1 Інтерфейс користувача
2 У правління запасами:
- моніториш запасів: відслідковування кількості кожного препарату на
склад~;
- замовлення препаратів: автоматизація процесу замовлення для
поповнення запасів;
- отримання товарів: внесення інформації про прибуття нових препаратів
на склад;
З Замовлення
створення замовлень: Реєстрація нових замовлень від клієнтів;
- відстеження замовлень: Моніторинг статусу обробки замовлень;
- звітність замовлень: Аналіз замовлень для планування та оптимізації
продажш;
4 Звітність
- фінансові звіти: Генерація звітів про продажі, прибуток, і витрати;
звіти про запаси: Аналіз стану запасів, ідентифікація потреб у
замовленнях;
- аналітика продажів: ВивчеІПІЯ паттернів продажів для маркетингового
планування;
5 Базаданих
- зберігання даних: Централізоване зберігання всієї інформації системи;
- безпека даних: ЗабезпечеІПІЯ захисту даних від несанкціонованого
доступу;
- резервне копіювання: А втом атичне створення резервних копій для
відновлеІПІЯ інформації У разі аварії;
57
ЧДТУ. 242303.008 ПЗ
Звітність
Замовnення. Інтерфейс
База Бe3ner.e
користувача
даних ДВНИ)(
Уnрааnін ня
запасами
Моніторинг
Отримання
запвсіа
Замовnення товарів
препаратів
Рисунок 3. 1 -Функціональна схема програми wеЬ-застосунку обліку медичних
препаратів аптеки
Структурна схема веб-застосунку для обліку медичних препаратів в аптеці
включає декшька кmочових компонентів, які забезпечують його
функціональність. Цей застосунок взаємодіє з користувачами (наприклад,
фармацевтами, менеджерами запасів), обробляє дані і зберігає інформацію в базі
даних. Ось загальний опис структурної схеми такого застосунку:
1 Клієнтська частина (Frontend)
- інтерфейс користувача (UI): Включає сторінки та форми для введення
та перегляду інформації, такі як каталог препаратів, деталі замовлень,
інвентаризація, тощо. Розробляється з використанням технологій
HTML, CSS і JavaScript;
клієнтські скрипти: Забезпечують динам1чну взаємод1ю на стороні
клієнта включаючи валідацію форм, інтерактивні елементи UI та
'
асинхронні запити до сервера через AJAX.
2 Серверна частина (Backend)
- б від клієнтської частини, забезпечує логіку
ве -сервер: Обробляє запити
. · ми користувачів. Зазвичай реалізовано з
додатку та управшння сес1я
58
ЧДТУ. 242303 .008 ПЗ
використанням фреймворків як Express (Node.js) , Django (Python),
Laravel (РНР) ;
_ АРІ (Application Prograпuning Interface ): Містить набір кінцевих точок
для взаємодії з фронтендом, які дозволяють створювати, читати,
оновmовати та видаляти дані (CRUD операції);
з. База даних
_ система управшння базами даних (DBMS): Забезпечує зберігання,
пошук та відновлення даних. Часто використовуються реляційні СУБД,
такі як MySQL, PostgreSQL або нереляційні СУБД як MongoDB;
_ таблиці/колекції даних: Зберігають інформацію про продукти,
користувачів, транзакції, інвентаризацію тощо;
Система управління
КЛ ієнтські скрипти Веб-сервер
базами даних (DBMS)
,,
Серверна частина Запит____.
КЛієнтська частина База даних
(Frontend) ,.,і Результат
(Backend) Результат
.і І
І'
1'
'
АРІ (Application
Інтерфейс користувача Табnицикоnекції даних
Programming lnterface)
(UI)
р Ь-застосунку обліку медичних препаратів
исун0к 3 .2 _ Структурна схема we
аптеки
59
►
ЧДТУ. 242303.008 ПЗ
З.1.3 Опис логічної схеми системи
логічна схема для ПЗ обліку ме и .
д чних препарат1в аптеки може включати
JІac'fYI1Hi основю компоненти:
1 база даних:
це центральний елемент системи · · • •
· , ЩО МІСТИТЬ шформацІю про ВСІ
доступні медичні препарати , ·1·х вл · · · ·
астивостІ, кшьюсть у наявност~, дату
придбання, постачальників тощо;
2 інтерфейс користувача:
включає в себе веб-або десктопні додатки, які дозволяють фармацевтам і
адміністраторам взаємодіяти з системою. Це може бути веб-сторінка
аптеки або спеціалізована програма для роботи зі складом і продажем
медичних препаратm;
З модуль обробки замовлень:
даний модуль відповідає за прийом, обробку та зберігання замовлень від
клієнтів. Він також може включати можливість формування рахунків і
облік оплати;
4 модуль ведення обліку:
відповідає за оновлення бази даних щодо наявності медичних препаратів,
додавання нових препаратів, видалення застарілих тощо. Також може
містити функції автоматичного поповнення запас1в;
5 система аналітики і звітності:
дозволяє здійснювати аналіз продажів, прогнозування попиту на певні
ф и звіти про стан запасів, оборотність товару препарати, ормуват
тощо;
6 модуль безпеки:
· ого доступу до бази даних та
забезпечує захист від несанкцюнован
• •v •• ·нформації про клієнтів та операції з
збереження конфщенщиноt 1
препаратами;
60
ЧДТУ. 242303.008 ПЗ
г=-=-=-=-=-==-=-=-=-==-===========-======-==-==-==-:::~
База даних Інтерфейс
-,,
користувача
Модуль
Система ведення
аналітики і . облікv
звітності
1 Модуль
Модуль обробки
безпеки замовлень
Рисунок З .2 - Логічна схема для wеЬ-застосунку обліку медичних
препаратів аптеки
Архітектура веб-застосунку для обліку медичних препаратів в аптец~
складається з кількох взаємопов'язаних модулів, кожен з яких виконує
специфічні функції, необхідні для ефективної роботи системи. Головною є база
даних, яка служить як центральне сховище для всієї інформації, включаючи
деталі медичних препаратів, записи замовлень, дані про продажі та інформацію
про користувачів. Ця база даних інтегрована з різними модулями, забезпечуючи
надійне зберігання і доступ до даних.
Інтерфейс користувача дозволяє аптекарям та шшим користувачам
взаємодіяти з системою через зручний графічний інтерфейс, що забезпечує
МОЖJІивості для введення, оновлення і перегляду даних в режимі реального часу.
ОкреМИЙ модуль ведення обліку забезпечує функціональність для управління
запасами . чи моніторинг кількості та термінів придатності,
препарапв, включаю
а 'Га1<ож обробку даних про нові поставки.
м · щ· ає за автоматизац~ю процесів
одуль обробки замовлень вщпов
замов . . . ення статусів замовлень і оновлення бази
лення вщ постачальниюв, вщстеж
даuІіХ . ок Така інтеграція сприяє плавній
вщnовідно до отриманих постав ·
lloricnr •
ЦІ та управлінню запасами.
61
чдтУ. 242зоз oos
з.1 .4 Розробка бази даних · ПЗ
База складається з 8 таблиць:
places, menus
de,·s order_ product, barcodes.
or , customers, tables, products,
схема в базі даних
має зв' язки типу «о дин
багатьох» виглядає так: до багатьох», «Багато до
Табпиця "uaera"
І'\оІМ)
)'"-r.in,..,;, l!Jr•ч1 ,. 'tм~р
\tll{t\or
t1("~ D,І С'І -.t•~
Таблиця "orders"
ІЬnе
0!11111:
І,• ••
Таблиця "medicines"
П<>Ц
NI ~
~ ditht .. ~ . ~~9tf Y,ti...u~ш.t,
І р \ІШJ.4\Ш111у
lunlt
'°"' tt,,м м ~'fR.lNї;~1f)'
q\NI 't.~ і • 9tf Іn~ 11 rн.tt ~1~:щ.
e)~rt.11.~. . d..tte ~-,14.~ /&\1,і -it.n-f'I0111ct U'f\V"1r t f!'°'ЛІТН1ЮІ
Табnмця "sales"
По.'Іt' 1:'1111
t:Іlt. ~··
.,,.s.,- "' .,
~ .. --~·
Quan:•r.y • З!r
СІ :1 cюrni
•сІ~.,., ~-о.,м-р 14.1!11
РисуН ок. З .3 - Схема бази даних для wеЬ-застосунку о б ш·к у медичних
препаратів аптеки
62
ЧДТУ. 242303.008 ПЗ
І-Ій зображенн і представлена діаграма бази .
. . · даних, яка м1стить п'ять таблиць,
, аних м1ж собою р1зними відношення
1101J яз . ми. Ця база даних може бути
стана для управшння фармацевтич . .
111 1J<орИ ною д~яль1нстю, такою як ведення
ень продажів та запасів ліків Ось , v
замовл ' · коро rкии опис кожної таблиці та їх
11оля:
users
_ id (integer): унікальний ідентифікатор користувача;
_ username (varchar): ім'я користувача;
_ role (varchar): роль користувача (наприклад, клієнт, фармацевт);
_ created_at (timestamp): час створення запису про користувача;
2 orders
- order_ id (integer): унікальний ідентифікатор замовлення;
- client_id (integer): ідентифікатор користувача, який зробив замовлення
(посилання на таблицю users );
- pharmacist_id (integer): ідентифікатор фармацевта, який обробив
замовлення (посилання на таблицю users);
- created_at (timestamp): час створення замовлення;
З medicines
- medicine_id (integer): унікальний ідентифікатор медичного препарату;
- name (varchar): назва медичного препарату;
- quantity (integer): кількість наявних одиниць препарату;
- exp.1 ration_date (tu· nestamp)·. дата закінчення термшу придатносп
препарату;
4 sales
- sale_id (integer): • .v • нтифікатор продажу;
уюкальнии ~де
. . замовлення, до якого відноситься
order_ id (integer): щентиф1катор
б цю orders );
ІІродаж (посилання на та ли
63
◄
ЧДТУ. 242303.008 ПЗ
medicine_ id (integer):
ІДентифікатор препарату,
що продається
(посилання на таблицю medicines);
_ quantity (integer): кількість проданих одиниць;
_ price (decimal): ціна за одиницю товару;
_ sold_at (timestamp): час продажу;
Відношення між таблицями:
- таблиця orders має зв'язок з таблицею users через поля client_id та
pbarmacist_id, що дозволяє ідентифікувати клієнта і фармацевта, які
беруть участь у замовленні;
- таблиця sales зв'язана з таблицями orders та medicines, що дозволяє
відстежувати, які ліки були продані в рамках конкретного замовлення;
Ця структура дозволяє ефективно вести облік запасів, замовлень та
продажів у фармацевтичній сфері.
3.1.5 Розробка інтерфейсу користувача
Ця програма є веб-базованою системою для управтння запасами
медичних препаратів у аптеці. Її основна мета полягає в автоматизації обліку
медичних препаратів, спрощенні процесів управління запасами та підвищенні
ефективності робочих процесів. Програма складається із 5 вікон.
Перегляд списку препаратів:
Головна сторінка відображає список всіх наявних у системі медичних
11Реnараті·в • Ко жен препарат має унl· Кальний ID , назву та кількість, яка показує
Іlот0 ·
ч~н запаси.
д JІя кожного препарату передбачею· кно пки для редагування та видалення,
ІЦо
дозволяє користувачам швидко оновлювати інформацію або видаляти
llpenapa .
ти: з1 списку. Див.рис. 3.4.
64
ЧДТУ. 242303.008 ПЗ
Медичні препарати
1D Н11а1 nptnapaтy
ди
Анапьrін 100 -- -
210
Додати новий медичний препарат
н,не~ npenapa1
Рисунок. З .4 - Перегляд списку препаратів
2 Додавання нових препаратів:
Нижче списку препаратів знаходиться форма для додавання нових
медичних препаратів. Користувачі вводять назву та кількість нового препарату,
а потім натискають кнопку "Додати", щоб реєструвати його у системі. Див.рис.
3.5 .
• • ..- -,. а •
•cQc , - ... о• ~
Медичні препарати
Діі
1D На••• n~napaтy
100
д,..м1ь1 ,н
2'0
1eмnanr111
,о
Додати ноаий медичний препарат
1
- их препарапв р .з. 5 Додавання нов
исунок
65
ЧДТУ. 242303.008 ПЗ
аrування інформації про препарати ·
3 ~д . .
flpl,f натисканю на кнопку "Реда "
rувати користувач переходить на
rорі1л<У, де можна оновити назву або кількість препарату. Це важливо для
с ... . .
~оре!<Uії інформацн у раз1 зм1н у запасах або під час оновлення даних про
nродуІ('l'И .
... . .. ---
• ~ ~ • ') !..
Редагувати медичний препарат
Рисунок. З .6 - Редагування інформації про препарати
4 Видалення препаратів:
Кнопка "Видалити" дозволяє користувачам швидко видалити препарат з
бази даних, що є корисним у випадках, коли препарат більше не виробляється
або не використовується.
Медичні препарати
1D
Ан.111.. ., .., 100
10
доА•тм ноенй м•АИ"ннй npen•pe•
Рисунок. 3.7 - Видален ня препарат1в
66
ЧДТУ. 242303.008 ПЗ
JIIre рфейс користувача: 5
J1p0 грама має інтуїтивно зрозумілий, користувацький інтерфейс, який
легко навігувати і використовувати всі її функції. Веб-базована
дозво.JІЯЄ .
а забезпечує доступюсть системи з будь-якого пристрою з веб
сfРукrУР
м що підключений до Інтернету.
браузеро '
• \\ L.\::r"lf",~' ' .
·. о ! .
t ~ d :
Медичні препарати
10 Коu nРfІІ.ІрЩ Кішіm Дії
100
ВІІДЗІ!,ІПІ
Рwrува1и
111 , rін
Видамш
Додати новий медичний препарат
Назва nреЛАр"}' І
J
р 8 - Видалення препаратів
исунок .3.
67
ЧДТУ. 242303 .008 ПЗ
W' J1creмa не тільки спрощує управл · с шня запасами, але й забезпечує
сіб для ефективного контролю за на . .
~3if за явюстю медичних препарат~ в ,
onre . •
. чн ризики нестач1 та перевантаження за .
. · ~• 1 зуJО пас1в.
,н»'
з.J .б опис розробки програмних компонентів
головна логіка веб-застосунку полягає в тому щоб у користувача був
додаток який має доступ до інтернету та дозволяє йому перемикатись м~ж
rоловними функціями застосунку. За це відповідає файл routes.py.
файл арр.ру визначає маршрути та контролери для веб-застосунку обліку
медиqних препаратів аптеки. Цей файл є ключовим елементом, оскільки
визначає , як відбувається взаємодія між користувачем та самим застосунком.
Визначення маршрутів:
- @app.route('/') - Головна сторінка:
- функція indexO визначає обробник для маршруту '/', тобто головної
сторінки. При переході на цей маршрут, викликається функція, яка
отримує усі медичні препарати з бази даних та передає їх до НТМL
шаблону для відображення. Крім того, передається пустий екземпляр
форми AddMedicineFormO для можливості додавання нових
препаратів ;
- @app.route("/create_drug", methods=['POST', 'GET'])- Додавання
нового медичного препарату:
- функція create_drugO відповідає за обробку маршруту'/ create_drug,
який може обробляти як GET, так і POST запити. При GЕТ-запиті вона
Просто відображає сторінку зі списком препаратів та формою для
додавання нового. При РОSТ-запиті, коли дані форми були відправлені,
ф,тu · . . . • є новий медичний препарат до
J о.КЦІя перев1ряє іх вашдюсть, дода
бази • млення про успішне додавання та
даних, виводить повщо
Перенаправляє на головну сторінку;
2 811користання Flask та SQLAlcbemy:
68
r
ЧДТУ. 242303.008 ПЗ
render_template: Функція render_template ви
•дображення НТМL-шаблонів у користовується для
81 , · цьому ви
падку, шаблони;
i·equest: Об єкт request дозволяє
. отримувати доступ до даних що
надходять вщ користувача через НТТР-за . '
. пити, таю як дані форми·
redirect: Функц~я redirect використ '
- . . овується для перенаправлення
користувача на 1ншу стор~нку після
виконання певних дій, таких як
додавання, редагування або видалення пр
епарату;
Узагальнюючи, арр.ру відображає ефективне викорис ф ~
тання реимворку
f\ask та бібліотеки SQLAlchemy для обробки НТТР-запитів, взаємодії з базою
~аннх та відображення відповідей для користувача на сторінках веб-застосунку.
Цей файл становить основну частину бекенду застосунку, реалізуючи різні
функдіональносп для додавання, редагування та видалення медичних
препарапв .
Після розгляду цього файлу, пропоную розглянути головний html-фaйл, а
са.~е index.html. Використовуючи принципи написання html-розмітки були
створені і інші сторінки, а саму: add_ medicine.html та edit_m edicine.html.
НТМL-файл index.html є ключовим компонентом веб-застосунку для
обліку медичних препаратів аптеки. Давайте подробно розглянемо його
СІ]Jуктуру та функціонал, використовуючи теоретичні аспекти веб-розробки.
l DOCTYPE та Мета-теги:
<!DOCTYPE html>: Цей тег вказує на версію HTML, яку
у даному випадку, це НТМL5 , який є
використовує документ.
останньою версією НТМL;
НТМL-документу та вказує
<html lang=" en ">: Визначає початок
мову документу ( англійська) ;
2 Заголовок та Мета-теги:
. ф мацію про документ, таку як
-<head>· Цей блок містить мета-ІН ор .
· ля адаптивного вигляду,
. аштування д
І<ОдуВання симвоmв та нал вання символів документа
<:: 8">" визначає коду
rneta charset="UTF- · лів будь-якої мови;
истанНЯ симво
.s{l( UTF-8, що підтримує викор
69
ЧДТУ. 242303 .008 ПЗ
<111eta name=' 'viewport'' content=="W І' d th=dev1. ce-width · ·t· І
scale== 1. о ">·. Зада , , 1ш 1а -
є парамет·р и відоб раженняд
. . . · 1І Я адаптивного вигляду
»а р1зних пристроях;
заголовок сторінки:
3
<tіtІе>Медичні препарати</tіtІе>:
Визначає заголовок веб-
сторінки, який відображається у вк .
ладщ браузера чи на панелі
завдань;
Підключення СSS-стилів:
4
<link rel="stylesheet" href=" {{ url _ for('statr'c' , fi1l ename= ,s tyl es.css ')
}} " >: Підключає зовнішній файл стилів styl es.css. Ц е дозволяє
визначити вигляд та макет елементів на сторінці;
5 Тіло сторінки:
<body>: Визначає тіло НТМL-документу, де розміщено весь вміст,
який буде відображений на веб-сторінці;
6 Заголовок розділу:
<Ьl>Медичні препарати</hl>: Виводить заголовок першого рівня,
який вказує на тему сторінки - "Медичні препарати";
7 Вивід повідомлень:
{% with messages = get_flashed_messagesO 0/о}: Використовується
для отримання списку флеш-повідомлень (с повіщень, що виводяться
короткий час). Ці повідомлення можуть виникати під час виконання
певних дій, таких як додавання, редагування чи видалення
препарату;
{% if messages %} ... {о/0 endif %}: Перевіряє, чи є повідомлення для
виведення·
'
<ul class="flash-messages"> ... </ul>: Список для відображення флеш-
8 nовідомлень у вигляді списку;
ФоРІ\fа для додавання новоrо препарату:
<h2> Додати новий медичний препарат</Ь2>: Виводить заголовок
дР\,т,ого . ... давання нового препарату;
J" р1вня для секцв до
70
ЧДТУ. 242303.008 ПЗ
method="post" · "
<form action= {{ url_for('add_medicine')
}}"> </form>: Визначає форму
··· для введення нового препарату та
відправлення даних методом POST;
{{ form.csrf_token }}: Вставляє токен CSRF б ф
для езпеки орми;
<label for="name"> ... </label> та <input type--"t t"
ех name= " name "
сІ а Ss="form-control" placehold er= "В вед~· ть назву препарату"
required>: Визначає поле для введення назви препарату;
<ІаЬеІ for="quantity"> ... </label> та <input type="number"
oame=" quantity" class=" form-control" рlасеhоІdеr="Введіть
кількість" required>: Визначає поле для введення кількості
препарату;
<input type="submit" class="btn btn-primary" vаluе="Додати">:
Визначає кнопку для відправлення форми;
Узагальнюючи, base.html визначає структуру та вигляд веб-сторінки для
відображення інформації про медичні препарати, а також для взаємодії з
користувачем шляхом додавання, редагування та видалення препаратів. Файл
використовує шаблонізацію Jinja2 для вставки даних з серверного коду Python у
НТМL.
А без посередньо запуск веб-застосунку відбувається через файл run.py.
Розглянемо його більш детально. Файл run.py у нашому випадку є точкою входу
дЛя запуску Flаsk-додатку. Давайте розглянемо його структуру та пояснимо
кожен Рядок, використовуючи теоретичні аспекти Flask.
Файл арр.ру:
1 Перевірка, чи файл запускається напряму:
if _narne =' main ':
- це типова конструкція Python, яка перевіряє, чи файл запускається
напряму , • ся як модуль Це важливо для того, щоб
а не 1мпортуєть ·
\Лrw.І(п,.,.., пуску коду при імпорті, що дозволяє
JCU'l.--·J "и автоматичного за
71
ЧДТУ. 242303 .008 ПЗ
використовувати файл як модуль у інш
их частинах програми без
його автоматичного виконання;
заnуск додатку з режимом відладки:
2
run(debug=True)
арР·
ця команда запускає Flаsk-додаток у режимі вщладки. Режим
вl·дла.д ки дозволяє автоматично перез •
апускати додаток при змшах у
вихідному коді. Параметр debug=True включає цей режим;
Узагальнюючи, файл run.py відповідає за запуск Flаsk-додатку. Він
імпортує об'єкт арр з вашого модуля арр та запускає додаток у режимі відладки,
якщо файл запускається напряму. Цей підхід забезпечує портативність та
можливість використання вашого додатку в різних середовищах.
3.2 Тестування системи
В цьому розділі буде розписано модульне тестування, інтеrраційне
тестування, системне тестування, приймальне тестування.
3.2.1 Модульне тестування
Модульне тестування _ це методолопя тестування проrрамного
забезnечеННя, в якій окремі компоненти (модулі) проrрами перевіряються і
т~ .
ться незалежно від інших частин системи. Модуль в контекст~ тестування
МО)І(е • •
означати ф ункщ•ю , клас, о б' єк т або навіть цшу систему залежно вщ
І.!асІІІт б
а У Проекту.
Моду .
льн1 тести v юються розробниками проrрамного
зазвичаи створ
Забезn . в
••еченвя . • боти окремих модушв коду. они
для перев1рки правильносп ро
72
ЧДТУ. 24 2302.012 ПЗ
Таблиця 3.3
Результати системного тестування
і компоненти Опис Результат
vCJfCfe;rJJI +D B Ініціалізація бота та взаємодія з
Виконання
re\egra базою даних.
усшшне
~ot + User + Реєстрація нового користувача в Виконання
базу даних
DB усшшне
--- Створення нового шаблону через Виконання
TelegramBot +
бота.
Create_T emplate + DB усшшне
Додавання нового шаблону в базу
даних.
TelegramBot + Редагування та оновлення в базу Виконання
editing_T emplate + DB даних створеного шаблона. успшmе
Ці тестові сценарії допомагають забезпечити, що система є надійною,
відпові дає вимогам користувачів, і здатна правильно функцю· нувати У реальному
оnератив
ному середовищі.
3.2· 4 П u
риимальне тестування
llp ииu мальне тестування (Acceptance Testing) є фінальним етапом
!ес,,.-
-·1~анІіJІ • Ц
перед впровадженням системи в експлуатащю. е тестування
ЗоееРед)!(е
~ llo на перевірці, чи відповідає система зазначеним вимогам та
0
%аНІіJІ
м користувачів, і чи готова вона до реального використання.
73
ЧДТУ. 242303.008 ПЗ
ням даних, аномальні стани то Інт . v
61:rr' 1J-Іовлен • що. еrрац~ине тестування системи
~,едичних препарапв аптеІ<И поляг . .
о бJJil<Y 1" . . ає У перев1рщ взаємодії р1зних
нентів системи та перев1рщ коректності їх спіль " б
~О!',{110 НОІ ро ОТИ.
Було проведено наступне інтеграційне тестування:
Таблиця 3.2
Етапи інтеграційного тестування
компоненти Тип
Виконання
~.route("/show_ drug") - Написаний тест, що симулює Виконано
процес додавання препарату
певним користувачем на певний
час 1д ату.
- Перевірено, чи правильно
обробляється запит на додавання
препарату 1 чи зберігаються
відповідні дані у базі даних.
app.route("/about") - Створено тестову базу даних з1 Виконано
препаратами.
- Написано тест, що перев1ряє, чи
правильно система виявляє
доступні та зайняті препарати для
певного часу і дати.
_ Перевірено, чи повертає система
очікуваю результати щодо
доступності препаратів.
3 ·2.З Системне тестування
Си стемне тестування веб-базованої системи управшння запасами
'-tец11~· перевірку всіх компонентів системи
Препаратів у аптеці включає
74
r
" ЧДТУ. 242303 .008 ПЗ
м , щоб забезпечити ІХ коректн разо У взаємодію
ц v та вщ. пові ·
)-{моrам . еи вид тестування викону дюсть функціональним
в ється в інте
ui}{J1TИ систему у сценаріях, які ім· грованому середовищі, щоб
о . ~тують реальне вик0 .
nриJ()lаДІВ тестових сценаріїв, які мо ть ристания . Ось деюлька
жу бути використані
тестування цієї системи: для системного
Таблиця З.З
Етапи системного тестував
ня
-к--омпоненти Тип
Виконання
~pp.run( debug True) - Залогінитися як адміністратор . Виконано
- Перейти до форми додавання нових
препаратів.
- Ввести назву та кількість препарату.
- Натиснути кнопку "Додати".
def create _d rug() - Залогінитися як адміністратор. Виконано
- Перейти ДО форми додавання нових
препаратів.
- Ввести назву та кількість препарату.
- Натиснути кнопку "Додати".
3·2.4 Приймальне тестування
Приймальне тестування (Acceptance Testing) є фінальним етапом
Тес'Т•' J\ тоь ання перед впровадженням системи в експлуатацію. Це тестування
зосер едЖено на перевірці, чи відповідає система зазначеним вимогам та
о .
'іlІ<ува ІІНям користувачів, і чи готова вона до реального використання . Для веб-
6а зоваlіо·1· системи управління запасами медичних препарап.в прииV мальне
1ecl'\,
·JBallliЯ Може включати наступи~. аспекти..
75
.J
ЧДТУ. 242303.008 ПЗ
Таблиця 3.4
Етапи приймаJJьноrо тестуван11я
»енти Тип
io~f 110 Виконання
~ plate("cl'eate d1· - Перейти
rєнdе1_ до форми додавання ВИJ<онано
нg.І1tт І") препарату.
- Ввести дані нового препарату.
- Натиснути "Додати".
~uery.all() - Зайти в систему як новий користувач. Виконано
- Спробувати знайти функцію
додавання, редагування та видалення
препаратів.
db.session.commit() - Симулювати одночасний ввід даних Виконано
1О О користувачами.
- Оцінити час вщгуку системи та
стабільність.
З.З ПрикJJади впровадженого програмного комплексу
Система була розроблена з метою автоматизації процесів обліку медичних
ІІреnаратів, що включає відслідковування запасів, управління замовленнями та
0ІІ'Гнмізацію складських залишків у аптеках. Це дозволяє аптекам ефективно
kеру-ва'У'н . . V •
н1 наявюстю медичних препарат~в та забезпечувати високии р1вень
обсJІуг
овування клієнтів.
Ос»овн· компоненти та ф 1 ункцн...
i n ..
ерегляд списку препарат1в.
Система відображає актуальний список вс1х медичних препаратів,
достутуних . . енням їх кількості. Користувачі можугь
в аптещ, 1з зазнач
Il.r811rn, аляти препарати.
•-що переглядати, редагувати, та вид
2
Додавання нових препаратів:
76
ЧДТУ. 242303 .008 ПЗ
}(ористувач1 можуть легко додавати нов1·
медичні препарати до
системи, вказуючи назву та кількість.
3 Редагування інформації про препарати:
Система надає можливість редагу .
вання даних про 1снуючі препарати,
такі як зміна кількості на складі або назви.
4 Видалення препаратів:
Користувачі можуть видаляти препарати з системи, якщо вони більше
не потрібні або застарілі.
Система використовує сучасні веб-технології для забезпечення
доступності та інтерактивності. Вона базується на фреймворку Flask для бекенду
та використовує НТМL, CSS та Ja vaScript для фронтенду. Це забезпечує зручний
та гнучкий інтерфейс, який можна легко адаптувати під потреби конкрепюї
аптеки.
Впровадження цієї системи дозволить аптекам значно шдвищити
ефективність управління запасами. Аптеки зможуть знизити випадки нестачі
препаратів, підвищити точність інвентаризації та забезпечити кращий облік
фінансових та матеріальних ресурсів. Кінцеві користувачі, включаючи
фармацевтів і менеджерів, відзначать покращення в роботі системи, що
спростить їх повсякденні задачі і збільшить загальну продуктивність роботи.
77
-
ЧДТУ. 242303.008 ПЗ
Висновки до з роздt,1у
І1ід час цього етапу проекту було успішно розроблено програмний додаток
3 сіма »еобхідними функціями. При проектуванні були ретельно враховані всі
асу11 еJ('І'И модуm.ності та інтерфейсу додатку з використанням відповідної
вавчаль ної літератури для правильного виконання запланованих етапів. База
аІ:{}{Х була успішно спроектована та реалізована під час розробки. Результати
дп рое,1,.н..;,,-.3ння системи були втілені в кінцевому додатку, який пройшов
81,д пов1• дне тестування. Висновком з тестування є безперебійна та належна робота
додат.к у у своїй предметній області.
78
ЧДТУ. 242303.008 ПЗ
висновки
висновок досшдження підкреслює •
. усшшну розробку та впровадження
аuійної веб-ор1єнтованої системи .
j1111ов для управшння запасами в аптеці на
альному сервері. Ця система демоне • . .
пок трує значю переваги ун1версальносn та
доет уnності ' оскшьки її можна вико ристовувати з будь-якого пристрою з
підключенням до Інтернету. Така кросплатформеність робить систему особливо
привабливою для медичних установ, які прагнуть забезпечити швидкий доступ
до інформації про медичні препарати.
Автоматизація процесів обліку та управління запасами за допомогою веб
додатку значно знижує ризик помилок, пов'язаних з людським фактором, і
підвищує точність обліку. Централізоване зберігання даних забезпечує їх
актуальюсть 1 доступність для всіх зацікавлених стор1н, включаючи
фармацевтів, менеджерів та адміністративний персонал.
Система також пропонує інтеграцію з іншими медичними та аптечними
інформаційними системами, що сприяє створенню єдиної інтегрованої
інформаційної середовища. Інтеграція з електронними медичними картками
пацієнтів може покращити координацію лікування та забезпечити більшу
персоналізацію медичних послуг.
Адаптивність і масштабованість системи дозволяють ефективно реагувати
на змінні потреби аптечних мереж, зокрема на збільшення обсягів інформації,
зміни у законодавстві та розвиток нових технологій. Система підходить для
аптек різного розміру та типу, від невеликих до великих мереж.
Таким лише відповідає поточним потребам аптечного
чином, проект не
бізнесу , ал v для иv ого інноваційного розвитку, ілюструючи
е и закладає основу
ва)[(J}ивість інформаційних технологій у сфері охорони здоров'я для покращення
siI<ocтi та ефективності медичного обслуговування.
79
L
ЧДТУ. 242303.008 ПЗ
список ВИКОРИстлн··и х дж КРЕЛ
rлv tJ 1Y Brown amd Greg Wilson Th е Architecture of Open Source
J\pplications - 2021. - 121 р.
2 АРІ Server [Електронний ресурс ] .Р ежим доступа:
https·· //www.crossbase.de/DE/DE/loesungen/datenb ere1· 1s t е1. 1 un g/a p.1· -server.
3 Qwynne Richards Warehous management: А Complete Guide to Improving
Efficiency and Minimizing Costs in the Modem Warehouse _ 2017. _ 250 р.
4 Intemational Testing-Board Testautomatisierung Definition, Tutorial und
Artikel Testautomatisierung [Електронний ресурс]/ Code Project - Режим
доступу до ресурсу: https://www.testing-board.com/testautomatisierung.
5 Marc Unger 50 Dropship & Wholesale Vendors: Dropshipping List (Drop
Shipping & Wholesalers Book 1) - 2020, 500 р.
6 Realm Studio [Електронний ресурс] / Ве moreproductive with Realm
Studio - https://realm.io/products/realm-studio.
7 SAP [Електршrnий ресурс] / Developer Overview - Режим доступу до
ресурсу: https://www.sap.com/index.html.
8 Войтко В .В. Комбінований метод пошуку оптимальних рішень з
використанням засобів теорії графів / В.В. Войтко, С.В. Бевз, С.М.
Бурбело, О.В. Гавенко // Оптико-електронні інформаційно-енергетичні
технології. -№ 2 (16). -2008. - С. 67-70.
9 Гильманов А.А. Карткові технології в автоматизації маркетингу.
Томськ: Видавництво НТЛ, 2020. - 379 с.
10 Коваленко О.О. КоІЩепція створення мережевого інформаційного
серед · компанією / О О. Коваленко // Вісник
овища управшння ·
Хм · ун~·верситету - 2016. - № 1, том 2. - С.
ельницького нацюнальног 0 ·
21-26.
І 1 Ков б . . провадження інформаційних технологій
аленко О.О. Нео хщюсть в
та програмного забезпечення на підприємстві / О.О . Коваленко //
Со · . . . . · та культурні оцінки і прогнози на
ЦІально- економ1чю, пол~тичн~
РУбіжі двох тисячоліть: - Тернопіль: ТНУ, 2019. - С. 416-418.
80
ЧДТУ. 242303.008 ПЗ
2 Коваленко О. О. Створення інфо . v
1 · рмащиноrо середовища підприємства
для якісного прийняття управлінських рішень / О. О. Коваленко //
Регіональна перспектива. -2019. -№2-3 (27- ). -с.1 21 _ 128 _
28
13 Коваленко О· О· Сучасні тенденції управління інформаційними
ресурсами підприємства І О.О. Коваленко// Методологія та практика
менеджменту У ХХІ столітті: загальнодержавні, галузеві та регіональні
аспекти: матеріали VI Міжнародної науково-практичної конференції
26-27 квітня 2019 р. м. Полтава. -Полтава: ПУЕТ, 2019. -С. 368-370.
14 Коваленко О. О. Теорія інформаційних взаємодій на підприємстві / О. О.
Коваленко// Збірник наукових праць ВНАУ. - Вінниця: РВВ ВНАУ,
2020. - Вип. 5. - Т. З. - С. 156-159.
15 Модульні тестування (Unit testing) [Електронний ресурс]/ Qalight 2021
- Режим доступу до ресурсу: http://lviv.qalight.corn.ua/Ьaza
znan/modulnetestuvannya.
16 Соколов В.Ю. Інформаційні системи і технології: Навчальний посібник
-Київ ДУІКТ, 2019. - 341 с.
17 Android Framework [ електронний ресурс]• - 2017 · - Режим доступу:
https://www.quora.com/What-is-meant-by-Android-ftamework З. Мартин
Фаулер // GШ Architectures. - 2006
18 Kotlin [ електронний ресурс]· 2018. - Режим доступу:
https :// kotlinlang.org/
19 Android Studio [ електроннииV ресурс ] · _ 2019 - Режим доступу:
https://uk.wikipedia.org/w1' k'1/ Android- Studio
] 2019 Режим доступу:
20 REST [е лектронний ресурс ·
http !І k 'Ісі d' g/wiki/REST
s: u .w1 ре ia.or V ] - Режим доступу до
21 ТЬе МІТ License (МІТ) [Електр оннии ресурс
g/licenses/МIT
ресурсу: https://opensource.or [Електронний ресурс]. -
22 ~ я h.1 t ectures. Часть 1
ivJ.artin Fowler - GUI Arc /articles/18358/.
2009. -Режим доступу.. http.· //WWW•rusdoc.ru
81
ЧДТУ. 242303.008 ПЗ
23 :М:artin Fowler - GUI Architectures. Часть 2 [Е V
лектроннии ресурс]. -
2009. - Режим доступу: https://habrahabr.ru/post/53536/.
Б ес Л. Архітектура программн 24 а ого за 6е спечення на практиці , 2-ге
видання. : пер. 3 англ/ Лен Баес, Пол Клементс, Рик Кацман -, 2006. -
575 с.
25 литвак Б.Г. Експертні технології управління.2оо4г.
26 Гамма Е. Прийоми об'єктно-орієнтованного проектування. Патгерни
проектування : пер. с англ. І З. Гамма, Р. Хелм, Р. Джонсон, Дж.
влиссидес. 2007. - 366 с.
27 Тестування. Фундаментальна теорія. Частина 2 - Методоллогїї
розробки Програмного забеспечення [Електронний ресурс) : [Веб-
сайт]. - Електронні дані. - DOU.ua , 2005-2016. - Режим доступу:
https://dou.ua/forums/topic/14015 (дата звернення 15.04.2023 -
Спільнота програмістів DOU.
28 Jinja2. Офіційна документащя. Режим доступу:
https ://j inj а. palletsproj ects .сот/ en/3 .1.х/
29 Python. Офіційна документац~я. Режим доступу:
https :// docs. python.org/3 /
ЗО SQLite. Офіційна документац~я. Режим доступу:
https://www.sqlite.org/docs.html
31 Flask. Офіційна документац~я. Режим доступу:
https://flask.palletsprojects.com/en/3.0.x/
32 Web мvс framework. Режим доступу:
https://docs.sprin.g .ю/sp. пng-framework /docs/3.2.x/spring-framework-
reference/html/mvc.html
доступу:
ЗЗ Режим
CSS Documentation.
S/docs/Web/CSS/Reference
https://developer.mozilla.org/en-U
34 · _ Режим доступу:
в ументащя .
ootstrap. Офіційна док . d t' n/
etting-started/шtro uc ю
https://getbootstrap.com/docs/5.3/g
8_
ЧДТУ. 242303.008 ПЗ
програмне забезпечсннн- Режим доступу:
oZA
35 Р~ oft.comfua/products/
·//prozas
ttttP· 365. Комплексне рішення для аптек - Режим достуну :
5carb
36 · //skarь.ua/
ttrtP5·
с.В., Заспа Г.О . , Півень О.Б., Катаєва Є.Ю. Салапатов В.І .,
6
37 roJJY
в в Олексюк в .в ., доцент м. етодичю. рекомендац11... до
eтenan ..,
М ки кваліфікаційної роботи бакалавра для здобувачів вищої
nідготов . .
. • спеціальності 121 «Інженер1я програмного забезпечення» ус1х
осв1ти з1
форм uавчання
83
)(О)(Л'І ОК Л
1с1н. кафе;, .,,, 11 фсоор
_ ro ,у� ·.в.
,,_ -------- 2024 р.
Розробка web- астосунку обліку медичних препаратів аптеки
Специфікацjя
482. ЧДТУ 242303.008
Лисrів 2
Розробник Малаховський Я.В.
Керівник Катаєва Є.Ю.
Завідувач кафедри Голуб С.В.
2024
ЧДТУ 242303.008
2
nоз11ачення
Найменування
п римп. ка
документація
чдтУ. 242з93-о1 12 01
482
482 ·ЧДТУ. Текст програми
242303-01 34 О 1
ЧДТУ.242303-01 Інструкція користувачеві
482·. 90 01
Роздатковий матеріал
-
85
ДОДАТОК Б
Розробка wеЬ-застосунку обліку медичних препаратів аптеки
Текст програми
482.ЧДТУ. 242303-01 12 01
Листів 12
)Зробник Малаховський Я.В.
2024
4~2 . Ч lTY. 24 23 03-ОІ
12 01
, 11 І :~ . 1-.. 1i:11Ltc1· 1e111plate. 1-ccitic~t re(t ·
jf1 rl І . ІГСС \
і, , 2
., · N 1 1.11 i:111, i111port . QLЛ ІсІ1е111)
(l l .
• ·' І J '
Е R І '] = ' 1·
sq lle:///pharn1 .db'
~-. ~,-,н db.t', I del) :
.
, = db .Coltнiнi( db.1111eger. рп 111ary _ key=T п1 е)
' -db Colimнi(db.S 1 ri11g. 11t1llable=Trt1e)
';І - ·
= db . Col t1П1ІІ ( db.Stri11g. 1шІІаЬІе=Тп1е)
(і \
; ~ .rout", ,'" ")
Уі dex() :
rum render_template(" main.html")
~ 'i'PJOUle( n /about")
c~f aЬout() :
,rurn render _template("about .html" )
~ p.route("/create _d rug", methods=['POSТ', 'GЕТ'])
Crf стеаtе _d rug():
if request.method = 'РОSТ':
liile = request.form('title']
tex-t = request.form['text']
роя= Post(title=t itle , tex t=text)
ll}:
db.session .add( post)
db.session.commit()
prinl('Data add succses ful y')
return redirect('/' )
excepi:
return ,,0 ,,,. "
шиока при добваленин записи
tl~:
rtturn re d
п er _template("create_ drug.html")
87
482.ЧДТУ. 242303
-01 12 01
- pos1 . q11eгy . аІ І() 3
tS-
ро . dei· tei11pl:1te( "sl10"1_dн1 ~s. l11111I ". posts
і111 е ІІ - 1,osts)
re lll
•·er = Se11ti11el()
11inr, -
dе Г _clieck _ge11eric( cls, parameteгs , е\е11= _ma,·ker"):
'"'"Clieck corтect сонпt fог paгarпete1·s of а gепе 1· і с cls (іпtетаІ helper) .
Тliis gi,,es а 11ісе епоr message іп case of сон пt mismatcl,.
111111
іГ 1101 еІе11 :
raiseTypeE1тo1·(f'{cls} is поt а gепе,·іс class")
іГ еІе11 is _markeг:
if11ot l1asattr(cls, "_parameters_ ") 01· поt cls._ pa1·amete1·s_ :
raise ТуреЕrюг( f' { cls} is поt а generic class")
еІеп = le11(cls._paгarпeters_)
аІеп = le11(pararпeters)
if alen != е І еп :
ifhasattr(cls, "_pa,·ameteгs _ "):
paramete1·s = [р fог ріп cls._pa1·amete1·s_ ifпot _i s_uпpack(p)]
num_tv_tнples = sшл(isinstance(p , TypeVarTнple) for Ріп paramete,·s)
if(,ium_tv_tuples > О) and (а Іе11 >= еІеп - пum_tv_tuples):
retum
raise TypeEri·or(f'Тoo {'mапу' if аІеп > е І еп else 'few'} pararпete,·s foi· {c ls} ;"
f' actual {a len}, expected {е І еп } ")
if sys ve .
. r s юn_i11fo >= (3 , І О) :
def shou \d
- _co llect_from_parameters( t):
retur · •
,1 r s 111 staпce(
t, (ty · . . ty es UпіопТуре )
prпg ._ Geпe,·i cAlias , _types . GeneпcAl1as , - Р ·
eli f s
Ys. vers. .
def ro11_111fo >= (З , 9) ··
_shou\d с
- ol І ect_from_pa1·amete1·s(t) :
88
482 .ЧДТУ . 242303-0 J 12 01
. . ce(t, (typi 11g._ Ge11 c1·icAl ias, typcs G . .
~~ 115111s1 311 - · e11 cr1 cЛt 1 ,
' 15
)) 4
.с: d co ll ect_1i ·o 111_pмa111 ete 1· s( t) :
J ~IJ(JIII - • , .· .
1
1\ • taiice(t. 1yp1 11 g. Ge11 e 11 сА l1as) a ct .
i·cl'''11 is111s - 11 11011 ._specia \
1 ,µе ,,ars(types, ty pev,н_ty pes=No11 e): ,r co\\ect_) - . . .
~ 1 аІІ type vапаЬ І е co11tai11ed 111 types іп о ~·сІ ег о Г
"""[о \\ес
агапсе (Іехісоgгар\1і с 01·de1-). 1~01· еха 111 р \ е::
(lrst арре
collect_type_, ,a1·s((T, List[S, Т])) == (Т , S)
1111 1!
r ,,ai· types is Nопе :
і І)' Р e -
rype,,ai·_types = typi11g.TypeVai·
1,,ars = []
for І іп types:
if (
i s iпstaпce(t., typevaг_ types) and
t поt in tvars and
поt _is_uпpack(t)
):
tvars.appeпd(t)
if _should _c ollect_fl'Om__para111eteгs(t):
t11ars.exte11d([t for t in t._parameteгs_ ift 1101 іп tvaгs])
retum tup\e(tvars)
' OReturn = typiпg.NoRetui-n
' Soine ui1c onstra1·1 1ed type ·
vaгiables. These а1·е used Ьу t\1e co11ta111et· types.
' !'Гhese а re поt for ехрогt . )
Та ty •
, Ping.ТypeYar('Т') # Апу type.
кт" t .
YP.i ng.ТypeYar('KT') # К t
І'Т" еу уре .
Т ~• ping.ТypeYa1·(' VТ') # \І а\uе ty pe.
T_co" typing .TypeYaг('Т со' соvагіа11t=Тн1е) # Апу type co,,a1·ia11t co11tai11e1·s.
~ - , .
- ntra = typ·i ng. Т V ai·(T _ co11tt·a', . 1 ) # о1· н о co1111·avarra11t .
уре co11t1·ava1·1ant=Tп e
89
482 . ЧДТУ. 242303-0 \ 12 01
5
\ІІУ ІсЩІу ре) :
,1~,s f •
. stшicecl1 eck (self, оЬ 1 ) :
def' - 111 ' - •
ifselfis Л оу:
aise TypeEпo 1·(" ty pi11g_exte 11 s i o 11 s.A 11 y caпnot Ь d . . .
r . е use W1th 1s1nstance()")
rettІГІl sнper()._111 sta11cecl1 eck_( obj)
def _ 1·ep1·_ (self):
ifselfis А 11 у:
i·etLІl1l "typi11g_ ex te11sio11 s.A11y"
,·etlІl11 st1pe1·( ) ._І'ер1·_()
class д пy(metac lass= _АпуМеtа):
"" "Special type i11dicati11g а11 uпcoпstrained type .
. дпу is compatible witl1 evel'y type .
. дпу ass u111 ed to l1ave аІІ 111ethods .
. А ІІ values assu111ed to Ье iпstances of Any.
Note tl1at аІІ the above state111ents аге t1·ue fго111 the point ofview of
static type cl1eckers. At runti111e, Any shoнld not Ье used with instance
checks.
def _11e,v_ (cls, *args, **kwal'gs) :
if cls is А11у :
raise TypeErrol'("Any cannot Ье instantiated")
return supeг()._ new _ ( cls, *args, **kwargs)
ClassVar = typing .C l assVaг
class Є І . . -Т · )·
- х ensюnsSpecialFoпn(typiпg._ Spec1alFor111, _root- ІLІе ·
def _ repr _ (se lf):
return 'ty p1·1 1g_ex1e11s io11 s.' + se lf._na111 e
11 Гrи
~ 1"1 na1 е · . , · 11
Х І 15 111 3.8+, Ьнt we backpo1·t it foi· а ІІ vc:rsJO
90
r
482.ЧДТУ. 242303 01
- 12 01
re 3· 1110 keep sopport fol' tl1e _ fi11nl - аІІІ'іЬLІtе · 6
r
р І1е 10 . ЬLІ s.pytl1011 .ol'g/isst1e46342
І1ІІР5 .// g
,1 5ее
ffi11a l(f): . .
de . d -са11 Ье t1 sed 10 111d1ca1e to type cliecke
.,,,.,fІІІ S ес 0111101 rs І 1,а \
ecor·a1 ed metlюd can110t Ье oveпidde11 ' a11d decor·at d
е с ass
1І1е d 1
Ье sobclassed. FOI' еха111рІе :
cn1111ot
class ваsе:
@fi11al
defdoпe(selt) -> Іо11е:
class St1b(Base):
def do11e(selt) -> 1 011е: # Епо1· І'eported Ьу type cliecker
@fi11al
class Leaf:
class Otl1e1·(Leat): # Erro1· reported Ьу type cl1eckel'
There is 110 ru11tin1e checki11g of these properties. The decoratol'
setstl1e " fіпаІ_" attribote to " True" ол the deco1·ated object
to аІІоІ\1 rш1ti111e іпtюsресtіоп .
111111
tту :
f._ final_: Тi-ue
except (AttributeEпo1· , TypeError):
# Skip the attribute sileпtly if it is поt ,,;ritable.
# AttributeErr01· І1appens ifthe object has _slots_ or а
~
~ read-only prope1·ty, TypeErroг if it's а builtiп class.
Pass
return f
dtriщv
ar(narne ):
re1u rn "·1'P 1. ng
·1 YpeVar(пa111e)
:А
. l itera1 Ь
ir 1 ugw
\'s.verS.10 11 . as fixed іл 3.11.0, З . І О. І and 3.9.8
li1 era1 - _rnro >:: (З , І О , І) .·
- ty .
P111g.Literal
91
4R2· Ч ,'ч' ТУ .242]0]-0 11 2 01
rl.c: - l'пil p t11 ·n 111 s( prн· r1111 c t1:1,,): 7
, . nnflCII_ 1 І 1 - . .
1I
ti · нt еп~аІ І~ е Ірс , · ·101· І_, ,І ст І СІ'еа Iі о 11 : nанс,1 І , іt с,· аІ ,
••"" 11 ' s ,1111011g parametcrs"'"'
~1•ni11~ - І 1
11·
. ,arn111e1e1·s:
І "t1І' р 111 1
. . 1 п 11 се( ІJ Li teгalG eнe ,· icA lias):
jf1s111 " ' -
pm·a!l1S.ex te11d(p ._ ::н·gs _ )
else:
paгa111s.appe11d(p)
retнri 1 tt1ple( рага 111 s)
def valнe_at1d_type_ ite1·(pai ·a111s) :
for р і11 pal'a111s:
yield р, type(p)
class _L ite,·alGeпericA І ias(typing._ GeneгicA І ias, _root=True ):
def _ eq_ (self, otl1e1'):
ifпot isi11sta11ce( оtІ1ег, _ LiteгalGeпeгicAlias):
retum Notl111ple111ented
tl1ese_args_deduped = set(_ value_aпd_type_iter(self._args_))
other _a rgs _ deduped = set(_ value_ and _ type _іtег( othe1·._ aгgs _ ))
retum tl1ese_args_deduped == otheг_aгgs_deduped
def _ hash _(self):
returп l1asl1( f'i-ozenset(_ va І ue _ апd _ type _ itel'(sel f._ aгgs _)))
class _Li1eralFoпn(_ExtensionsSpecialFom1 , _1·ооt=Тп1 е) :
def _iлit_(self, doc : str):
self._name = 'Lite1·al'
self._doc = self._ doc_ = doc
def ·
___getite111_ (self, para111eteгs):
if n01 1· 1· s nstance( para111ete1·s, tuple):
Pararneters = (рага111е tегs,)
Pararnet ers = ·s)
_flatte11_Іiteral_para111s(para111ete i
V аІ - Іу р e_pa.ir s = li st( ,, аІuе апd type_1. ter(pai.a m ete1·s))
Іrу: - - -
dedup d
е _pairs = set(val type pai1·s )
ехсер1 Т - -
YpeE,·ror:
482.ЧДТУ . 242303-0J 12 01
аЬІе ра1,.1111 еtє гs 8
# u11І1as 1i ,
paSS
else: . d d .
. .1 ~· І ооіс to typ111g._ е t1pl1cate 011 Р),tІю
# s11111 а <> 11 3 +
. 9
(d edt1ped_pa iгs) < Іе11(,1 аІ type_paiгs)·
if І е п - ·
пe,vyara111eteгs = О
for pair іп val_ type _pai1·s:
ifpaii· і11 dedt1ped_pai1·s:
11e,;v _pa1·a111eters.appe11d(pai1·[0])
ded11ped_pai1·s . 1·e111ove(paiг)
assert not dedt1ped _pai1·s, dedt1ped _pairs
para111ete1·s = tt1ple( пе,;v _parameters)
retur11 _L ite1·a1GenericAlias(self, parameters)
Literal = _LiteralFor111( doc='""' \
А type that сап Ье t1sed to indicate to type cl1eckers
that tl1e coпespondiпg valt1e has а valt1e literally eqt1ivalent
to tl1e provided para111eter. For еха111рІе:
var: Literal[4] =4
ТІ1е type cl1ecker understands that 'var' is literally equal to
the value 4 and по other value.
Literal[ ... ] canпot Ье subclassed. There is по ruпtime
checking verifying that tl1e parameter is actually а value
instead ofa type.""")
_o1•erload d
- urnmy == typiпg._overload_du111my
if has
atlr(typing "
overІ ' get_ overloads"): # З .11 +
oad "'ty .
kt1 p1ng.overload
,overІoads - .
t І еаг - 1Y PІПg.get_ overloads
t , overІoad - .
1 Іе: 5
- typing.clear _ overloads
" l111od uІe·
' о Verload · {quа Іпа 11 1 . {fi .
е. 1rst l111eno: fш1с}}}
~ _regist1-y -
\J~c10 - collections.defau ltdict(
о 1s .partial( І . .
со lect10ns.defaultd ict, d1ct)
93
482 .ЧДТУ . 242303
-0 1 12 01
9
Іасе 1wo 01· 11101·е stub defi11itio11s for the s
s11111 (ІІе , р . ame
111 п . a1.0 ,•.,,. еасІ1 decoгated \oV1tl1 @ove1·Іoad
j11 · For е .
хшnр1е :
[1111ctJO 11
a1overJoad
- f 1f8(''al11e: о11е) -> No11e: ...
dC ІІ
іі1О''е 1· І оаd
" е · bytes) -> bytes : ...
def11tf8( ,,a1 L І .
@overload .
"( ,alue: st1') -> bytes ....
def 11tlo '
-stнb ftle (і.е. а геguІаг .ру file), do the sa111e but
111 а 11011
fо ІІоІІ' it witli а11 i111ple111e11tatio11. ТІ1е i111ple111e11tatio11 should *not*
be decoi·ated witl1 @ove1·Іoad. Fo1· еха111рІе:
@о,,егІоаd
defutf8(value: Nопе) -> Nопе: ...
@overload
defutf8(value: bytes) -> bytes: ...
@overload
defutf8(,1alue: stг) -> bytes: ...
def utf8(value ):
# imple111entation ooes hеге
о
The overloads fo1· а fuпction сап Ье 1·etгieved at п111tіте usiпg tlie
get_o verloads() fu11ctio11 .
111111
#c lassmeth 0 d
алd static111etlюd
r-- getattr( ~un с , "І _ fш 1с_" , fuпc)
І)':
_overload _i·eg1· stry[f._ n10dule _J[f._ qt1al11a111e _Jf
f. cod
]- - e_ .co_firstli11e110
- func
ехс
ер , А 111·1·ь LlteEпor·
II Not .
Pass а nоп11аІ fi unctio11 ; ig1101·e.
re1ur11
_overload d
_ ummy
94
r
482.ЧДТУ . 242303 -01 12 01
10
\oads(fi.mc) :
І o,,er
defge _ . 11 defi 11ed ove1·\oads 101· • rш1с • as а seqtieІІc """
,,,,, izetLІІ 11 а е.
' od at1d static111et\10d
c\assmet 11
# (fuнc " fu11c_ ", fш1с)
f "' getattr ' - . .
dule not 111 _oveгload_1·eg1stгy:
jff._ _ 1110 -
returi1 О
. 1 :с 0verload 1·egistry[f. 1110dL1le
111od_d ic - - -
a\t1anie 11ot і11111od_dict :
iff._ qu -
retuПl О
ist(ll10d dict[f._ qualname _J.values())
reІUГll l -
def clear _o verloads( ):
"" "Clear аІІ overloads in the registry."""
0,,erload _registry .clear()
=This is not а геаІ ge11eric class. Don't use outside ai,notations.
Туре= typing.Тype
=\ 'arious ABCs mi111icking those in collections.abc.
=А few are simply re-exponed for completeness.
A1vaitable = typi11g.A waitable
Coroutine = typi11g.Coroutine
Asynclterab\e = typiпg.Asyncl tегаЬІе
AS) nclterator = typiпg. Asynclterator
Deque" typing.Deque
ContextMa nager = typ1. 11g.ContextManager
AsvncC
· ontextManager = typing.AsyncContextManager
Defau\1D· - .
ict - typing.DefaultDict
Ordered Di - .
С ct - typ1ng.OrderedDict
0unieг = •
typing.Counter
Chain~1a _ .
,\ р - typing.ChainMap
S)·ncGene
1 rator = typi11g.Asy11cGenerator
ех1::: .
IYp1ng.T ext
'ГУрє
_снєск.1 1G '= typing.ТYPE_CHECKING
Р~от
. o_ALcowLІsт = {
С()\ \ес1 ·
IOns.abc'· [
·с .
<11\аЬ\е' , І '
' A\vaitable', 'lterable', '\terator', 'Asynclterab е'
95
r
482.ЧДТУ. 242303-О l 12 О І
ь Іе' 'Sized', ' Со11tаі11ег' , ' Со ІІесtі он' . 'Re,,e,·sibl ,, ' В r. 11
· н аsІ1а . ~, ll ,~,-·.
]. ~ · ь• · ['Abst1·actC011text
'cor11ext , . Іанаgе г' . 'Abst1·actA sy 11cC011textM::111ager'].
. о exte11sio11s': ['Bll ffer ·'].
't)'Pill::,_
·cL DED - А TTRS = {
Е ;-;
- "_abstтact111etl10ds_" , "_ a1111otatio11s_ ", "_ ,-,,eak1·ef_ ", "_is_pr·otocol",
"_ i s_1·Lrnt·1 111e_pгo t ос о\" · "- d'1c t- "· "_ s І O t s_ " , " _pa1·aп1ete1·s_" ,
"_orig_bases_ ", "_ m odule _ "• "_ М lt t а ЬІ е М app1·1 1g_111aгke1· " , "_ doc_ ",
" subclasshook_ ", "_oгig_class_" , "_іпіt_" , "_неw_" ,
"_protocol_a ttr·s_ ", "_ саІ ІаЬІе _ргоtо _111е111Ьегs _ 011Іу _ ",
" match _a rgs _ ",
ifsys .11ersio11_i11fo >= (3 , 9):
EXCLUDED_AT TRS.add("_ class_getite111_ ")
ifsys.11ersio11_i11fo >= (3 , 12):
_EXCLUDED _А TTRS.add("_ type_params_" )
_EXCLU DED _А TTRS = fгozeпset(_EXCLUDED _А TTRS)
def _get_protocol_ at11·s( cls) :
attrs == set()
forbase іп cls._mro_ [:-1] : # witlюut object
ifbase._11ame_ іп {'P1·otocol', 'Geпeric'}:
continue
arinotations = getat1r(base, '_ a1111otatio11s_ ', {})
fог attr in (*base. dict , *a11110t.atio11s) :
1·r ( поt attr.stans-witl1(' аЬс ') апd at1r 1юt 1.1 1 - EXCLUDED - А ПRS):
at1rs.add( attr)
return attrs
der
_ca lІ e r( depth ==?) .
try : - .
return ' ' 111аі11_')
е~ sys.__getfran1e(deptl, ). f global s . get( '_пam e_ ' - ~- е()
сер1 ( . - 'tliotrl get 11 а111
AttributeError, ValueError): # For platfom1s w1 -
96
r
482.ЧДТУ. 242303-01 12 01
12
. atll'ibLІte was 1·e111oved fro111 p1·otocol
tel1 args_ 111 е
1118 111 Ьегs · 111 3. 13 ,
i ·, ,- - ьackport tl11·s с І 1a11ge t о о ld ег Р yt h0 11 versioris.
' •с ,va11t 10
, ,, · і11fо >= (З , І З) :
,ers101 1_
1 S \
~· І " typiнg . Protoco 1
•
protoco
1І1 е·
d· f eckless class cl1ecks( deptl1=3 ):
аІІ01v_r - -
е - 11 1 1· 1151311се a11d class c11ecks for· special stdlib rnodules
1,""А Q\.\ •
ТІ~е а ь с а l,d fur1ctoo1s rпodules i11discri111i11ately саІІ isinstance() and
1. ssu Ь с Ia s s() 011 the whole MRO of а user class, whicl1111ау contain protocols.
1111 11
rеtuГІІ _C alJe1·(depth) in {'аЬс' , 'functools', Nопе}
97
додлтокв
Розробка wеЬ-застосунку обліку медичних препаратів аптеки
Інструкція користувачеві
482. ЧДТУ 242303-013401
Листів5
Розробник Малаховський Я.В .
2024
482-чдтv. 242303-013401
2
програма є веб-базованою сист .
Uя емою для управшння запасами медичних
еnаратів У аптеці. Її основна мета полягає в автоматизації обліку медичних
ттр . .
nреnаратів, спрощеню процес~в управління запасами та підвищенні ефективності
б чих процесів. Програма складається із 5 вікон.
ро о
1. Перегляд списку препаратів:
Головна сторінка відображає список всіх наявних у системі медичних
nрепаратів. Кожен препарат має унікальний ID, назву та кількість, яка показує
поточні запаси.
для кожного препарату передбачені кнопки для редагування та видалення,
що дозволяє користувачам швидко оновлювати інформацію або видаляти
препарати зі списку .
. ,... ..,_,.__ ~ .
'°" СІ {,; О " о ~ с
Медичні препарати
Додати новий мtдичний nptnapaт
р - Перегляд списку препарапв
исунок . в . 1
2-Додавання нових препаратів:
фо ма для додавання нових медични Нижче списку препаратів знаходиться Р .
npen . кість нового препарату, а попм
аратів. Користувачі вводять назву та юль .
Ііа111с ати його у систем1.
І<а10ть кнопку "Додати", щоб реєструв
99
482.ЧДТУ. 242303-01 3401
з
'"
Додати ноеиіІ 114•дични~ npenape,
І І&trin1'Фn111111 1
Рисунок. В.2 - Додавання нових препаратів
3. Редагування інформації про препарати:
При натисканні на кнопку "Редагувати" користувач переходить на сторінку,
де можна оновити назву або кількість препарату. Це важливо для корекції
інформації у разі змін у запасах або під час оновлення даних про продукти .
.., .._. _____ . .
І • ОQО •с • •c Q.,!. c
Редагувати медичний препарат
1,. ...... ..
Рисунок В.З - Редагування інформації про препарати
4. Видалення препаратів:
І( увачам швидко видалити препарат з бази І-Іоnка "Видалити" дозволяє корнет
~alllix парат більше не виробляється або не
' ІЦо є корисним у випадках, коли пре
~lii<op»
сrовується.
100
-
482.ЧДту_ 242303-01 34 01
4
Медичні nрсnарати
10
100 -
JO
Дод11тм но■ий МІ!АМЧНИЙ ПрІ!Пар~,т
н~. .. ~)\'~)'
Рисунок В .4 - Видалення препаратів
5. Інтерфейс користувача:
Програма має інтуїтивно зрозумілий, користувацький інтерфейс, який
юзволяє легко навігувати і використовувати всі її функції. Веб-базована структура
абезпечує доступність системи з будь-якого пристрою з веб-браузером, що
ПlКЛЮчений до Інтернету.
··-- .. ) .
• - " с •
Медичні препарати
ДІ
10 н.. ... ~
,,.
ДоА~1'·и но•иЙ медичний препарат
в 5 - Інтерфейс користувача
Рисунок •
але й забезпечує аптекам
~ . . авлінНЯ запасами, . . .
~n: система не nльки спрощує упр чних препаратів , м1юм1зуючи
"'- tб дitsi аявністю меди
іІі.>ь.. ефективного контролю за н .
~~ ne~ • заnас1в.
"'!.а.ч1 та перевантаження 101
{О ~ЛТОІ{ Г
РОЗРОБКА WЕВ-ЗАСТОСУНКУ ОБЛІКУ МЕДИЧНИХ П РЕП АР тrв
АПЕТКИ
Графічні матеріали
482 . ЧДТУ.242054 90-01
Листів 8
Розробник Мала 'овськнй Я.В.
482.ЧДТУ. 242054 90-0 І 2
Черкаси 2024
Бакалаврська робота
ІІ а І СІ\ І у:
Ро'3робка \\' еЬ-зас1осунку обл іку ме1tи •11111 х 11pc11 apa 1i)j , 1111 ~ю1
/
J;1uбува'І : Малаховськ 11й Я.В . к~рів11 ше І<. І . Н . ,Jj(Щ. К,п а Є Ва (" .ІО .
Рисунок Г.1 - Слайд 1
Вступ
:\l~Іі1 і 1:113. l tllll!H pu1pufi1;11 Об'єктом ро1робки є \VеЬ-застосунок об.1і.ку
Мета розробк11: Є створення проrра~1ного про.:rукту мед11'!НІІХ препаратів аnтек11
'об.'Ііку ме.:~rrчнш111 препарата~т аптек11 . Ue передбачас У ,:ншііІ роботі ~,етодн проектування та
І
/ створе1шя ре.1яuіііної ба111 .:~аннх та програмного 1tо11струюоа1111я вк.1ючаютL в себе ш1корнстання
;.ю.:~атку через яю1fі бу.Jе з,:rіііснювашсь взанюдія CSS3 , Java Scripl. фреіІмворк FJask. SQLite та
користувача з базою ;:iaюrx . сере..:1овнше розробк11 .!! і аrр,щ.
для .:~осягнення постав:rеної ~1еп1 в роботі внріш ува.111сь наступні 1ав.1авня
ро1робкп :
Ог.1я.J ~1етодів і засобів реалізщії.
Пepernя.:i поді бн 11х проrра~1н11 х про,.:.~упів .
Уточнення задач проекту і проектування проrращrого про~1у~-ту.
Оптнмізапія проепного рішення і реа.1 ізаu ія nporpaмJioro проду1пу.
Тестування програмного продукту.
2
Рисунок Г .2 - Слайд 2
103
482 .ЧДТУ. 242054 90-01
з
Первинні та детальні вимоги
11,· р11111111і Rl\'10111 ( ,а""DІІІІІ<а):
.]r , ,. _ , ь 11 І 11 11 "" ' 11 (1,r11puo1111 h·a):
з ф\·нкцюнольного боку, сI1стема моє
Мінімальними вимогам ~ 1д ля розробк I 1
за езпечува111 ефе 'ТІ 1вне управління зопасам11
програми буде 32-бі;н11й процесор. .
м д1 1чн,1х rрепараті в . можлI1віст1, замовлення
Щонайменше З гігабайти операт11вної пом я т ,,
н в1 1х поставок, реєстрацію продажів та
зв існо я t< і у випадку з процесором можл~1 во
а тол,,а11·ччу генерацію звітів . Нефункціональн і
за пуст ити базу навіть на 512 мегаба1нах, але
І ,,,СГІ' ОХО:lЛ'ОЮТЬ безпеку дан I 1х , надійність
можливість її інтеграції з іншими для розробки в сучас них IDE та мя стабільної
11.
, ні здатність масштабування для роботи та подальшого росту бази необх1дн1 FK
,ьшення обсягу даних та мінімум 2 Гб. Процесор з 2 ядрами . Також
знадобиться жорсткий диск, рекомендовано
мати диск з об'ємом 128 Гб то більше.
Дисплей для виведення інформації то
перI1фер і я для введення.
3
Рисунок Г.3 - Слайд З
Діаграма прецедентів
/\
І~ І )
t •• 11, 11 1
Рисунок Г.4 - Слайд 4
104
.....
4Н . Ч ) (Т . ...05 · 90-0 І 4
11 І)ОСКТува1н111 11 · , ..
Юа • ра 111 1,. ,:н· і,; · ОІ І 11101 структ. ри
) {і а 1 р 11 щ1 11 11 · с• 1 і 11
.
\ ІJ, .......
І ,. - ...
Рисунок Г.5 - Слайд 5
Архіте:ктуJ}Не проектування
Діаграма РО 'JГО)П~НІІ-ІЯ
іа грама КОІ\JПОJІеІІТіВ
f .•--._1. t~1ІПІ
ri11 ~-."''
t··І
~;l(m
~ .. ~,~-('
6
Рисунок Г.6 - Слайд 6
105
482-ЧДТУ. 242054 90-0 І
5
. . . Мод.е .rJюван..-•я ·
nовед1нки системи
Дн,грама IOШlblltH: i-i .
J1.ia1 ·pa 1а 11щ· .11 ілтн111ст і
•
·•
7
Рисунок Г. 7 - Слайд 7
Моделювання поведінки системи
іаrрама комуні1"ації Діаграма скінченного автомату
інтерфейсу
•
' ; !(>.
\ t>., І І І• JІ 1•.; І ,j\:. " ' ,- --"--'-- .;-
І В.u... ~
L ,,··~"•·,
!І, . ., u:...: , :;.
І 1 .,
1J ,;,•a:tІ;i;U
r:!,r:~-," t·..S
" '
І 11,,w', ·" І
}.\Г_І,.В
:i ·t'-.':-l i.....
І · • . ,: ,, ,, ,. , " . .
•,•JІ, ІЬІ <' І !Н.\
І,• I Іl j'-' IU І\.\ [r.11
8
Рисунок Г.8 - Слайд 8
106
482.ЧДТУ . 242054 90-01
б
Структурна схема
Функціональна схема
,. ~•І ..
' ._ ◄" t::"E
9
Рисунок Г.9 - Слайд 9
Логічна схема
Ін;ерфейс І
- --• ,ор11е1увача
Система
г~aniнj v.>1 1
/ ЗВІТНОСТІ
Модуль І
обробки
заL1011Лень
І
_J
10
10 - Слайд 10
Рисунок г .
107
482.ЧДТУ. 242054 90-01
7
Структура бази даних
ll
Рисунок Г .11 - Слайд 11
Інтерфейс користувача
12
Рисунок Г.12 - Слайд 12
108
8
Тес11 вання
Етапн інтеrрацІйноrо тестува_ння .
І
:r=~-~=-~ f~ ~ - ,r=-..:::.::::-.: '-'
~= ~ ,... ..: :- ~~__.:,,!_ .... -::.s..· ..... :: -::i,,.~
&:ч,.,х...;;;:-,. ~..::~-:.... ,.. ~-~. _ .., ..._.::::-.;:-~
.
~~ .J... : -~::~~(: .. . !~ _,,,,=-:es п:~,ж., ~---=- = ~
Nt"-~ -="-' . - ..: , _~,,:~а..;, ..:-: · :-- ~ • -...:-- <7 ... ..:, -- ~ о:-= - . - -.:з.- .. ~:.,. - •<: ~--:
r~~s:~ · ~::-.:.с.:. ~~ .•z - ~,·-1'-'Jt r;:)o, --=---.-.. ,.,х ... -......:.-~ =-=--'!....-, ·;:.:: --~-~"
---- -- . - - --- -..;:- _- ... - ~-
грамвого np0.!1)'1'."'I)' .:~овепо адекватність програ~1ної реапізаuії
розр б.1еннм :~..горнтма~.
13
Рисунок Г.13 - Слайд 13
109