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

Размещено на http://www.allbest.ru/

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

Корнута Володимирівн Андрійович, кандидат технічних наук, доцент Івано-Франківського національного технічного університету нафти і газу, вул. Карпатська, 15, Івано-Франківськ,

Соботник Едуард Любомирович, здобувач вищої освіти другого магістерського рівня спеціальності «Інженерія програмного забезпечення», Івано-Франківський національний технічний університет нафти і газу, вул. Карпатська, 15, м. Івано-Франківськ,

Катамай Юлія Володимирівна, здобувачка вищої освіти другого магістерського рівня спеціальності «Інженерія програмного забезпечення», Івано-Франківський національний технічний університет нафти і газу, вул. Карпатська, 15, м. Івано-Франківськ,

Катамай Ігор-Михайло Богданович, здобувач вищої освіти другого магістерського рівня спеціальності «Інженерія програмного забезпечення», Івано-Франківський національний технічний університет нафти і газу, вул. Карпатська, 15, м. Івано-Франківськ,

Анотація

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

1) аутентифікація та авторизація; 2) наповнення особистого профілю рецептами препаратів від лікаря з урахуванням усіх особливостей щодо прийому того чи іншого препарату; 3) створення графіку прийому препаратів з обов'язковим вказанням необхідних фізіологічних особливостей користувача, періоду прийому препаратів. Збільшення кількості користувачів у даній системі є передбачуваною ситуацією у теперішній час у зв'язку з пандемією через COVID-19. При розробці архітектури сервера був обраний мікросервісний підхід. Важливою перевагою мікросервісної архітектури є саме гнучкість до змін. Для розробки серверної частини було використано платформу .NET. При реалізації клієнтської архітектури основним фреймворком для побудови графічного інтерфейсу користувача виступив Angular. В результаті розроблена ефективна система планування/ нагадування/ контролю виконання лікарських призначень.

Ключові слова: веб-додатки; мікросервісна архітектура; програмне забезпечення для нагадування про прийом таблеток.

Abstract

Kornuta Volodymyr Andriiovych, Ph.D, Associate Professor of Ivano- Frankivsk National Technical University of Oil and Gas, 76019, Ivano-Frankivsk, Str. Karpatska,

Sobotnyk Eduard Lubomirovich, 1st year Master's student, Department of Software Engineering, Ivano-Frankivsk National Technical University of Oil and Gas, 76019, Ivano-Frankivsk, Str. Karpatska,

Katamai Yuliia Volodumurivna, 1st year Master's student, Department of Software Engineering, Ivano-Frankivsk National Technical University of Oil and Gas, 76019, Ivano-Frankivsk, Str. Karpatska,

Katamai Ihor-Mykhailo Bogdanovich, 1st year Master's student, Department of Software Engineering, Ivano-Frankivsk National Technical University of Oil and Gas, 76019, Ivano-Frankivsk, Str. Karpatska

DEVELOPMENT OF A WEB APPLICATION TO ENSURE TIMELY MEDICINE TAKING

The article describes the creation of an application for patients with the ability to import medical prescriptions into a centralized information system with the subsequent generation of a schedule of reminders for the use of a drug. All existing solutions to this problem are complex and consist of a physical device and a program that controls it. However, such devices can be inconvenient and cumbersome, so there is the problem of creating a web-based medication reminder system that consists of a software solution only. To solve this problem, a web information system based on .NET Core and Angular technologies is proposed, using modern patterns for designing system architecture, and existing modern approaches to the development of scalable applications. The possibility of scaling the application in the future has been taken into account, which may be associated with increasing the number of users or expanding the functionality of the system. The business logic of a web-based application for the organization of medication taking can be divided into 3 stages: 1) authentication and authorization; 2) filling the personal profile with prescriptions of drugs from a doctor, taking into account all the peculiarities of taking a particular drug; 3) creation of the schedule of drugs taking with obligatory indication of necessary physiological features of the user, the period of drugs taking. The increase in the number of users in this system is a predictable situation at the moment due to the COVID-19 pandemic. The microservice approach has been chosen when developing the server architecture. An important advantage of microservice architecture is the flexibility to change. The .NET platform has been used to develop the server part. When implementing the client architecture, Angular has been the main framework for building a graphical user interface. As a result, an effective system of planning / reminding / monitoring the prescriptions taking has been developed.

Keywords: web applications; microservice architecture; pill taking reminder software.

Постановка проблеми

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

Аналіз останніх досліджень і публікацій

веб додаток прийом ліки

Дану проблему досліджувало багато науковців, зокрема Хоші К., Кавакамі Дж., Аокі С. та інші, які розробили систему моніторингу для лікарів, щоб у реальному часі з'ясовувати поведінку пацієнтів, які приймають наркотики вдома [1]. Ермісоглу Е., Байрак Ч., Менді Е. запропонували новий автоматизований трекер ліків під назвою «Мобільна система моніторингу лікування», щоб допомогти пацієнтам приймати ліки вчасно. Серед інших технологій, які допомагають пацієнтам стежити за прийомом ліків, таких як органайзери для прийому таблеток, нагадування про ліки та диспенсери для таблеток, використання системи віддаленого моніторингу лікування виглядає багатообіцяючою технологією, оскільки система створює прямий зв'язок між лікарем і пацієнтом [2].

Карагянніс Д., Микита К.С. запропонували веб-додаток, через який лікарі можуть в режимі реального часу коригувати розклад лікування пацієнтом, який згодом зберігається в базі даних на віддаленому сервері. [3]

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

Береіс Редлі дослідив комп'ютеризовані системи управління ліками покращують безпеку ліків та проблеми впровадження системи управління ліками в медичне середовище [5].

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

Оскільки розглянута проблема є актуальною сьогодні, зокрема під час пандемії COVID-19, її можна вирішити за допомогою веб-інформаційної системи, побудованої на платформах .NET Core [6] та Angular [7] з використанням сучасних шаблонів для проектування архітектури системи, бібліотеки та існуючих сучасних підходів до розробки масштабованих додатків.

Виклад основного матеріалу

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

Загалом бізнес-логіку веб-орієнтованого застосунку для організації прийому ліків можна поділити на 3 етапи: 1) аутентифікація та авторизація;

2) наповнення особистого профілю рецептами препаратів від лікаря з урахуванням усіх особливостей щодо прийому того чи іншого препарату;

3) створення графіку прийому препаратів з обов'язковим вказанням необхідних фізіологічних особливостей користувача, періоду прийому препаратів. Як тільки всі 3 пункти користувачем будуть виконані, то система згенерує сповіщення та розподілить їх за вказаними датами. Збільшення кількості користувачів у даній системі є передбачуваною ситуацією у теперішній час у зв'язку з пандемією через COVID-19, саме тому масштабована архітектура даного додатку є невід'ємним фактором для безперебійної його роботи. Далі розглянемо архітектуру сервера та клієнта окремо, оскільки вони є незалежними частинами за своєю суттю, за винятком обміну інформації між ними за допомогою протоколу HTTP (Hypertext Transfer Protocol). Наразі HTTP є найпопулярнішим протоколом обміну інформації у світі WEB.

Під час аналізу підходів до розробки серверів сучасних застосунків був обраний мікросервісний підхід. Це підхід, коли єдиний додаток будується як сукупність невеликих, самодостатніх, незалежних, не тісно пов'язаних сервісів, що спілкуються між собою за допомогою різних протоколів обміну інформацією (HTTP, gRPC, AMQP). Дані сервіси будуються навколо заданих бізнес-потреб (кожен відповідальний за конкретний процес, наприклад аутентифікація та авторизація, обробка сповіщень, керування статичними ресурсами сервера тощо) та розгортаються незалежно з використанням повністю автоматизованого середовища. Підхід постулює необхідність мінімізації централізованого управління цими сервісами. Самі по собі сервіси можуть бути написані різними мовами і використовувати різні технології зберігання даних. Спільним між усіма сервісами є комплекс дій задля досягнення кінцевої мети, а саме задоволення бізнес-потреб. Одна з причин використання мікросервісів полягає в тому, що у них є можливість швидко щось змінювати, щоб швидше реагувати на зміни бізнес -вимог. Мікросервіси допомагають розробникам реалізовувати зміни швидше, безпечніше і з більш високою якістю, тобто зберігати швидкість розвитку продукту, навіть коли той набуває розмірів, які потребують роботи великих команд розробників. Адже не тісно зв'язані сервіси дають можливість проводити зміни з більшою частотою ітерацій, мінімізуючи вплив змін на решту частин системи, що у свою чергу і забезпечує масштабованість системи. Тим не менш, такий підхід додає додаткову складність проекту в цілому. Під час роботи з мікросервісами доводиться розгортати усі сервіси, що вимагає додаткові знання та досвід інженерів програмного забезпечення, ускладнюється система моніторингу, зростає кількість можливих збоїв. Важливою перевагою мікросервісної архітектури є саме гнучкість до змін. Якщо відбувається зміна коду в одному з них, то розгортання усіх залежних мікросервісів не є необхідністю, а розгорнути необхідно лише ті сервіси, що піддалися змінам. До невід'ємних переваг варто додати можливість балансування навантаженості та відмовостійкість. Помилка в одному мікросервісі не підірве роботу системи. Неполадки у мікросервісі не зламають весь додаток, вони призведуть до збоїв у роботі тільки однієї функціональної одиниці, яку в подальшому легко можна локалізувати та виправити. Мікросервіси краще організовані, оскільки кожен мікросервіс має дуже специфічну роботу і не займається роботою інших сервісів. Тож вони потенційно легші для розуміння, підтримки і тестування.

Як раніше було зазначено, спілкування мікросервісів відбувається за допомогою протоколів обміну даних, таких як HTTP, gRPC та AMQP. HTTP - Hypertext Transfer Protocol - для передачі гіпертекстових документів, таких як HTML, хоча в принципі HTTP може використовуватися і для інших цілей, зокрема і для спілкування мікросервісів між собою. gRPC (Remote Procedure Calls) - це незалежна від мови програмування високопродуктивна платформа віддаленого виклику процедур. У gRPC клієнтська програма може безпосередньо викликати метод у серверній програмі на іншій машині, ніби це локальний об'єкт, що полегшує створення розподілених програм та служб. Як і у багатьох системах RPC, gRPC базується на ідеї визначення служби, вказуючи методи, які можна викликати віддалено з їх параметрами та типами повернення. З боку сервера реалізується інтерфейс і запускається окремий сервер gRPC для обробки усіх вхідних звернень клієнта. AMQP (Advanced Message Queuing Protocol)

- відкритий стандарт протоколу прикладного рівня для проміжного програмного забезпечення, орієнтованого на обробку повідомлень. Семантика обміну повідомленнями налаштовується під потреби конкретного проекту. «Повідомлення» (message) відправляються в «точку обміну». Точка обміну розподіляє повідомлення в одну або кілька «черг». При цьому в точці обміну повідомлення не зберігаються, тільки у черзі допоки воно не буде оброблено клієнтом.

При аналізі засобів розробки пропонованого до розгляду застосунку було вирішено використовувати платформу .NET для розробки серверної частини. Вона має гнучкі інструменти для реалізації мікросервісів та їх подальшої підтримки та масштабування. Серверна частина засобами .NET містить наступні ключові одиниці: Client, Identity Provider, API Gateway, Management, Service Discovery, Microservices, Remote Service, Static Content, CDN. Client - це будь-яка точка входу у додаток, у нашому випадку це веб-орієнтований застосунок, побудований на базі фреймворку Angular. Identity Provider - керує інформацією про користувача та надає послуги авторизації та аутентифікації у розподіленій мережі. API Gateway - служить точкою входу клієнта, тобто це єдиний спосіб контакту клієнта з сервером, яка, у свою чергу, повертає відповіді від базових мікросервісів, а іноді й сукупну відповідь кількох мікросервісів. Management - maintains the nodes for the service. Service Discovery

- встановлює послуги та кінцеві точки для отримання доступу до заданого функціоналу мікросервісів. Remote Service - будь-який зовнішній сервіс, що не залежить від реалізації мікросервісів даного додатку, але використовується ними задля досягнення кінцевої бізнес-логіки додатку. Він не є обов'язковий, але у нашому випадку зумовлений бізнес-логікою, а саме можливістю інтеграції даних додатку з Google Calendar API. Static Content - the static resources like pages and web content. CDN - a content delivery network to serve static resources.

У реалізації мікросервісів та монолітів (єдиний проект) засобами платформи .NET Core з використанням ASP.NET Core різниці великої немає. Єдине, що у мікросервісній архітектурі кожен мікросервіс - це окремий solution у загальному проекті додатку. Оскільки ці solutions є незалежними, то необхідно налаштувати обмін інформацією між ними певним чином. Як уже раніше зазначалося, у мікросервісній архітектурі спілкування між мікросервісами відбувається за допомогою спеціальних протоколів обміну даних. У даній реалізації єдиним протоколом обміну інформації між мікросервісами виступить gRPC. До випуску .NET Core 3.0 gRPC був доступний у програмах на C# за допомогою бібліотеки Grpc.Core. Це обгортка C# навколо бібліотеки “Core gRPC”, написана на C. Такий підхід працював нестабільно, особливо з такими бібліотеками як HttpClient, що призводило до частих збоїв у системі, незручного розгортання подальшого застосунку, а також до збільшення часу на розгортання протоколу gRPC у самому проекті для подальшого його використання. Починаючи з .NET Core 3.0, є можливість використовувати бібліотеку grpc-dotnet, повністю написану в керованому коді та добре інтегровану з платформою .NET. Ця бібліотека також надає базовий шаблон проекту, який допоможе досить швидко налаштувати додаток для роботи з даним протоколом обміну інформації. Першим кроком у створенні мікросервісу є визначення інтерфейсу, який описує вхідні параметри, що доступні для даного мікросервісу. В рамках gRPC цей інтерфейс визначається за допомогою Protobuf (формат серіалізації даних, запропонований корпорацією Google, як альтернатива XML), що забезпечує універсальність та незалежність від мов програмування. Зокрема, визначення усіх наборів правил щодо використання інструкцій Protobuf розміщено у .proto файлі. Перші два рядки .proto файлу декларують версію синтаксису Protobuf, що буде використовуватися, та простір імен C#, де буде реалізовано інтерфейс. Потім визначається необхідний пакет. Специфікатор пакета запобігає зіткненню імен між типами повідомлень протоколу. Наступні елементи у .proto файлі визначають інтерфейс служби RPC та необхідну кількість типів повідомлень. Інтерфейс служби RPC повинен мати назву та містити елемент, позначений ключовим словом “rpc”. Для спрощення розуміння даного синтаксису, про це можна думати як про клас з його методами. Якщо мікросервіс має кілька функціональних можливостей, то необхідно оголосити декілька rpc визначень. Кожне rpc визначення складається з імені, списку типів аргументів та типу виводу. Окрім примітивних типів даних RPC дозволяє оголошувати моделі даних, наче класи у звичному об'єктно-орієнтованому програмуванні. Така структура називається message. Message декларація визначає структуру повідомлення, що складається зі списку полів з відповідним типом. Як тип кожного поля можна використовувати скалярні типи, перелічення або інші типи повідомлень. Крім того, кожному полю призначається унікальний номер. Номери використовуються для ідентифікації полів у повідомленнях після їх перетворення у двійковий формат. Після того як інтерфейс описано, його необхідно підключити у системному файлі проекту типу .csproj. Ця інформація дозволяє системі збірки генерувати код C#, необхідний для підтримки базової інфраструктури для зв'язку gRPC. Зокрема, він буде генерувати код, необхідний для сервера.

З накопиченням бізнес-логіки кількість класів-сервісів, що використовуються для реалізації прийому та відправлення повідомлень з використанням протоколу передачі інформації gRPC, зростатиме. Це супроводжуватиметься погіршенням підтримки проектів у майбутньому, якщо не буде організована внутрішня архітектура побудови класів. Один з популярних підходів імперативного програмування CQRS (Command-Query Responsibility Segregation) дозволяє вирішити цю проблему та структурувати бізнес-логіку. Принцип стверджує, що метод повинен бути або командою, яка виконує якусь дію, або запитом, що повертає дані, але не одночасно і тим, і іншим. Саме тому CQRS дозволяє відокремити навантаження від читання та запису, що дозволяє масштабувати кожну функціональну одиницю окремо. Активно цей шаблон використовується з шаблоном Mediator. Суть шаблону посередника полягає в тому, щоб “визначити об'єкт, який інкапсулює взаємодію набору об'єктів”. Об'єкти більше не спілкуються між собою безпосередньо, а натомість спілкуються через посередника. Це зменшує залежності між об'єктами, що супроводжується кращою підтримкою та масштабованістю у майбутньому за рахунок легкої можливості внесення змін у реалізацію бізнес-логіки. У .NET Core є уже готові рішення, що дозволяють гнучко реалізувати використання цих патернів з використанням мікросервісної архітектури. Зокрема для інкапсуляції залежностей, а також гнучкого використання зареєстрованих служб (будь-які зареєстровані класи, типи, які будуть використовуватися у виконанні бізнес-логіки), ASP.NET Core містить простий вбудований контейнер IoC (представлений інтерфейсом IServiceProvider), що підтримує впровадження через конструктор за замовчуванням. Налаштувати служби вбудованого контейнера можна в методі ConfigureServices в класі Startup. Саме цей контейнер і використовуватиметься подальшими сутностями патернів CQRS та Mediator, а саме Command та Query. Query - це запит до системи на отримання певної інформації, зазвичай це читання даних з бази даних, без зміни стану системи. Один і той самий запит може виконуватися кілька разів, причому важливо, щоб для одного і того самого стану системи результат запиту незалежно від кількості цих запитів був тим самим. Command - це запит до системи на виконання дії, яка змінює стан системи. Команди є імперативними і повинні оброблятися тільки один раз. Команда реалізується за допомогою класу, який містить поля даних або колекції з усіма відомостями, необхідними для виконання цієї команди. Команда - це об'єкт передачі даних (DTO) особливого типу, призначений спеціально для запиту змін або транзакцій. Сама по собі команда заснована тільки на тих відомостях, які необхідні для її обробки, і ні на що більше. Відповідно у класах-контролерах фреймворку ASP.NET небхідно викликати запити чи команди залежно до бажаного результату.

У порівнянні з архітектурою сервера клієнтська архітектура є значно простіша у її реалізації та розумінні загалом. Основним фреймворком для побудови графічного інтерфейсу користувача виступив Angular. Як і нативний JavaScript, Angular також використовує DOM для представлення вмісту HTML користувачам, але йде зовсім іншим шляхом до побудови додатків, більше зосереджуючись на даних у програмі та асоціюючи їх з елементами HTML через динамічні прив'язки даних. Angular має основний файл, так звану точку входу index.html, який викликає ініціалізацію усіх подальших компонентів, сервісів і додаткових утиліт для коректної роботи описаної бізнес-логіки системи. Обробляючи HTML-документ, HTTP-сервер заповнює тіло застосунку елементами сценарію, які вказують браузеру на необхідність їхнього завантаження та виконання під час процесу збірки. Браузери виконують файли JavaScript у тому порядку, в якому відображаються їх елементи сценарію, починаючи з файлу runtimejs, який містить код фреймворку Angular. Основою Angular-додатків є модулі. Це так звані «будівельні блоки», які у комплексі формують кінцевий застосунок. Кількість модулів необмежена, проте завжди має бути принаймні один, який створюється за замовчуванням при ініціалізації проекту. Можна зауважити, що файл будь-якого модуля складається з декоратора NgModule, який описує цей модуль. Під описом мається на увазі, які саме залежності необхідні цьому модулю для його подальшої коректної роботи. Наступною логічною частиною Angular додатків є його компоненти. Компонент складається в основному з 2 файлів: component.ts та component.html, проте додатково можна створити component.css, щоб описати унікальні ізольовані стилі даного компонента. Оскільки більшість веб-клієнтів виконують різні http-запити на сервери типу GET, POST, PUT, PATCH, DELETE, то в Angular передбачено уже готовий HttpModule модуль, який дозволяє обробляти такі запити і приймати необхідну відповідь сервера. Все, що необхідно зробити, - це створити клас-сервіс, який буде надсилати запити, підключити його до необхідного модуля у масив providers і додати до класу-сервісу декоратор Injectable без жодних вхідних параметрів. Окрім підключення створеного класу-сервісу у заданий модуль, необхідно ще підключити HttpModule у масив imports, щоб клас-сервіс мав змогу використовувати його можливості. Саме використання усіх цих сутностей фреймворку Angular у комплексі формує загальний додаток з потрібними функціональними можливостями.

Контейнеризація дозволяє розгортати сервіси з власними налаштуваннями на будь-яких машинах незалежно від типу операційної системи досить швидко без необхідності налаштовувати їх щоразу з самого нуля. Враховуючи дану перевагу, було вирішено контейнеризувати, тобто ізолювати, додаток Medicine Planner у Docker-контейнери, зокрема усі мікросервіси серверної частини, а також клієнтський додаток як окремі контейнери. Docker - це програмна платформа для створення додатків на основі контейнерів - невеликих та простих середовищ виконання, які спільно використовують ядро операційної системи, але працюють ізольовано одне від одного. Для контейнеризації .NET додатків необхідно створити Docker-file, адже він використовується внутрішнім механізмом програми docker при виконання білду. Оскільки Docker-файл - файл налаштувань, то він містить у собі певну чітко визначену структуру, зокрема ключі слова. Ключове слово FROM вимагає повного імені шаблону контейнера Docker. Реєстр контейнерів Microsoft (MCR, mcr.microsoft.com) - це колекція Docker Hub, в якій розміщені загальнодоступні контейнери. Сегмент dotnet - це репозиторій контейнерів, а сегмент asp.net - це ім'я конкретного шаблону контейнера. Версія образу позначається цифрою 5.0 для управління версіями. Таким чином, mcr.microsoft.com/dotnet/aspnet:5.0 - це середовище виконання .NET Core 5.0. Docker обробить всі рядки файлу Dockerfile. Символ “.” в команді docker build використовується, щоб виконати за допомогою Docker пошук файлу Dockerfile в цій папці. Ця команда створює образ і локальний репозиторій з вказаним іменем, який в подальшому вказуватиме на цей образ. Після завершення роботи цієї команди виконайте команду docker images, щоб переглянути список встановлених образів задля упевнення, що команда виконалася успішно. Зазначимо, що два образи мають однакове значення IMAGE ID . Це пов'язано з тим, що єдина команда в файлі Dockerfile створює новий образ на основі існуючого, наче дописує до публічного образу власні налаштування, кастомізуючи його. Команда COPY вказує куди Docker повинен скопіювати вказану папку на вашому комп'ютері в папку в контейнері. Команда WORKDIR змінює поточний каталог в контейнері на заданий. Команда ENTRYPOINT використовується, щоб налаштувати за допомогою Docker контейнер для запуску в якості виконуваного файлу. При запуску контейнера виконується команда ENTRYPOINT. Після виконання команди контейнер автоматично зупиниться. Як тільки образ, що містить додаток, створено, необхідно створити контейнери для кожного мікросервісу та клієнта веб - орієнтованого додатку. Команда docker create створює контейнер на основі образу. У вихідних даних цієї команди присутній CONTAINER ID створеного контейнера. Щоб переглянути список всіх контейнерів, необхідно виконати команду docker ps -a. Таким чином після конфурації Dockerfile і створення образу з контейнерами Docker дозволить зручно налаштовувати та розгортати додаток на етапі деплою.

Процес деплою - це процес публікування програмного забезпечення у мережу Інтернет для загального доступу до нього. Для .NET додатків існує ціла інфраструктура для його деплою, що підтримується компанією Microsoft - Azure. Щоб опублікувати додаток MedicinePlanner необхідно виконатися налаштування Dockerfile, створити необхідні контейнери та загальний образ, а далі почати роботу з ACR - реєстром контейнерів Azure (Azure Container Registry), а саме створити групу ресурсів за допомогою команди az group create. Далі потрібно створити екземпляр реєстру контейнерів Azure за допомогою команди az acr create і надати йому власне унікальне ім'я реєстру. Після чого необхідно прив'язати docker-контейнери до ACR вказавши відповідні унікальні ідентифікатори. Звісно на практиці налаштування деплою є складним процесом, проте з базовою структурою деплою та публікації програмного забезпечення може впоратися будь-який досвідчений інженер програмного забезпечення. Для створення гнучкого середовища розгортання додатків з автоматичним відстеженням змін за допомогою систем контролю версій, автобалансуванням навантаження та розподіленням трафіку варто звертатися до спеціалістів у сфері DevOps. Саме на великих високонавантажених проектах такі спеціалісти слідкують за роботою сервера в режимі онлайн і виправляють будь-які несправності, що з'являються під час роботи додатку.

Висновки

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

Література:

1. Hoshi K, Kawakami J, Aoki S, Hamada K, Sato K. Real-time wireless compliance monitoring system using calendar-type pill organizer. Technol Health Care. 2013; 21(5). 455-467. https://doi.org/10.3233/THC-130747

2. Ermisoglu E, Bayrak C, Mendi E. Simulation of mobile treatment monitoring

system. In: Proceedings of the 2013 IEEE/ACM International Conference on Advances in Social Networks Analysis and Mining - ASONAM '13. ACM Press; 2013. https://doi.org/10.1145/2492517.2500318

3. Karagiannis D., Nikita K.S. Design and development of a 3D Printed IoT portable Pillbox for continuous medication adherence. In: 2020 IEEE International Conference on Smart Internet of Things (SmartIoT). IEEE; 2020. https://doi.org/10.1109/SmartIoT49966.2020.00066.

4. Varshney U. Smart medication management system and multiple interventions for medication adherence. DecisSupportSyst. 2013;55(2):538-551. https://doi.org/10.1016/j.dss.2012.10.011

5. Redley B., Botti M. Pharmacist-led admission medication reconciliation before and after the implementation of an electronic medication management system. Journal of Clinical Nursing (JCN), vol. 22, issue 3-4, pp. 579-589, 2012. https://doi.org/10.1111/j.1365- 2702.2012.04326.x

6. NET. Microsoft. Retrived from https://dotnet.microsoft.com/

7. Angular. Angular.io. Retrived from https://angular.io/about

References:

1. Hoshi, K, Kawakami, J, Aoki, S, Hamada, K, & Sato, K. (2013). Real-time wireless compliance monitoring system using calendar-type pill organizer. Technol Health Care. 21(5). 455-467. https://doi.org/10.3233/THC-130747

2. Ermisoglu, E., Bayrak, C., & Mendi, E. (2013). Simulation of mobile treatment monitoring system. In: Proceedings of the 2013 IEEE/ACM International Conference on Advances in Social Networks Analysis and Mining - ASONAM '13. ACM Press. https://doi.org/10.1145/2492517.2500318

3. Karagiannis, D., & Nikita, K.S. (2020) Design and development of a 3D Printed IoT portable Pillbox for continuous medication adherence. In: 2020 IEEE International Conference on Smart Internet of Things (SmartIoT). IEEE. https://doi.org/10.1109/SmartIoT49966.2020.00066

4. Varshney, U. (2013). Smart medication management system and multiple interventions for medication adherence. Decis Support Syst. 55(2):538-551. https://doi.org/10.1016/_j.dss.2012.10.011

5. Redley, B., & Botti, M. (2012) Pharmacist-led admission medication reconciliation before and after the implementation of an electronic medication management system. Journal of Clinical Nursing (JCN), 22(3-4). 579-589. https://doi.org/10.1111/j.1365-2702.2012.04326.x

6. NET. Microsoft. Retrived from https://dotnet.microsoft.com/

7. Angular. Angular.io. Retrived from https://angular.io/about

Размещено на Allbest.ru