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

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ "ЛЬВІВСЬКА ПОЛІТЕХНІКА"
Інститут КНІТ
Кафедра ПЗ
ЗВІТ
До лабораторної роботи № 7
З дисципліни: “Моделювання та аналіз програмного забезпечення”
На тему: “Дослідження предметної області та проектування системи за
допомогою UML діаграм”
Лектор:
доц. каф. ПЗ
Сердюк П.В.
Виконав:
ст. гр. ПЗ-25
Гнатущенко А.О.
Прийняла:
асист. каф. ПЗ
Цимбалюк Т.М.
« ____ » ________ 2023 р.
∑= _____
Львів – 2023

2
Тема роботи: Дослідження предметної області та проектування системи за допомогою UML діаграм.
Мета роботи: Дослідити предметну область та спроектувати систему за допомогою UML діаграм згідно з індивідуальним варіантом.
TЕОРЕТИЧНІ ВІДОМОСТІ
UML — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування. Є невід'ємною частиною уніфікованого процесу розробки програмного забезпечення. UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проектування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання
UML-моделей як інтерпретованого коду можлива кодогенерація.
UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес- систем і розробки прикладних програм. Різні види діаграм які підтримуються UML,
і найбагатший набір можливостей представлення певних аспектів системи робить
UML універсальним засобом опису як програмних, так і ділових систем.
Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код. Основною причиною використання мови UML є спілкування розробників між собою. Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.
Діаграма класів — статичне представлення структури моделі. Відображає статичні (декларативні) елементи, такі як: класи, типи даних, їх зміст та відношення. Діаграма класів може містити позначення для пакетів та може містити позначення для вкладених пакетів. Також, діаграма класів може містити позначення деяких елементів поведінки, однак їх динаміка розкривається в інших типах діаграм.
ЗАВДАННЯ
Відповідно до завдання, яке ви виконуєте у рамках команди (3-4 студенти в команді) розробити:
 діаграму діяльності;
 діаграму класів (+- 10 класів для кожного студента).

3
Врахувати у проектах інтерактивну взаємодію користувачів. Всі діаграми повинні бути складними, оскільки кінцевої реалізації проекту не потрібно, як і всіх задекларованих можливостей у діаграмах.
Побудувати діаграму класів із використанням основних парадигм ООП. Для
інкапсуляції логіки, створити щонайменше 2 модулі: модуль з класами, що відповідальні за внутрішню логіку програми (бізнес-логіку) та модуль інтерфейсу користувача. Модифікатори доступу класів і полів повинні надавати доступ лише до необхідних елементів, усі решта повинні бути невидимі розробнику інтерфейсу користувача.
Роль у команді:
➔ TL
1) Розробити діаграми компонент і розгортання. Спроектувати збірки: моделі, Unit тести, клієнта з графічним інтерфейсом (web, mobile, desktop). Якщо є необхідність то реалізувати інші збірки: сервера,
іншого клієнт (наприклад може бути 2 клієнта – під веб та під мобільний пристрій).
Команда: 3. Медицина.
Варіант: 9. Розбір запитів.
Термінові ситуації і їх вирішення. Гарячі потреби, операції – списки людей, які вирішують термінову медичну допомогу і перенаправляють у лікарні (з лікарською освітою і т.д.)
Складні ситуації і їх підтримка для вирішення:
 онкохворі
 вагітні
 діти з особливими потреби
 люди з хронічними захворюваннями
 літні люди
 тощо.
Додаткове завдання від PO. Модератор повинен вести журнал, у якому він записує історію розмови з мігрантом, побажання мігранта щодо перенаправлення в лікарню, додаткову інформацію, яка стосується термінової ситуації мігранта, та яка може впливати на подальше лікування. Додати можливість відеоконсультації між модератором та переселенцем, під час якого є можливість вказати мову спілкування.
ХІД ВИКОНАННЯ
1. Розробив діаграму класів згідно з індивідуальним варіантом.

4
Рис. 1. Діаграма класів
Діаграма класів показує структуру взаємодії мігранта з модератором при виникненні термінової ситуації.
Клас IPerson представляє інтерфейс людини, яка має ім’я, прізвище, вік та може комунікувати з іншими.
Клас Moderator представляє модератора, обо’вязком якого є приймання запитів на операцію від мігрантів, приймання рішень про вирішення їхніх термінових ситуацій та перенаправлення у відповідні поліклініки. У модератора є освіта. Модератор може назначати час та дату для операції над пацієнтом. Також модератор може записувати та зчитувати дані з журналу про перебіг перенаправлення мігранта у поліклініку.
Класу Migrant притаманий певний тип термінової ситуації, медична історія, список алергій. Мігрант може описати свою термінову операцію та надати запит на медичну операцію.
Клас UrgentSituation є абстрактним класом для усіх інших типів термінових операцій та містить опис термінової ситуації, рівень загрози для мігранта, та можливість розпочати лікування термінової ситуації.
Клас ChronicDiseases є типом термінової ситуації, який описує хронічне захворювання, та містить поля, які відповідають даті діагностування хронічного

5 захворювання та список препаратів, які призначення для цього хронічного захворювання.
Клас ElderlyPerson є типом термінової ситуації, який описує людину похилого віку, містить булівське значення, яке вказує чи є людина старшою за 80 років, та чи може вона отримати підтримку від сім’ї. Також присутній метод для виклику людини, які обходить мігранта з похилим віком.
Клас SpecianNeeds описує термінову ситуацію у людини з особливими потребами. У класі присутнє поле, яке вказує, чи може людина з особливимо потребами обійтися без сторонньої підтримки, та метод для виклику на допомогу.
Клас Pregnancy описує термінову ситуацію – вагітність. Клас описує дату вагітності, записи про проходження вагітності, та метод для додавання записів про перебіг вагітності.
Клас Oncology описує онкологічне захворювання, та містить поля які відповідають типу онкології, статус лікування, та чи потрібне хірургічне втручення.
GunshotWould описує вогневе поранення та описує кількість поранень, їхню серйозність та можливість оцінити серйозність поранень.
Клас UrgentSituationView описує вікно, у якому мігрант та модератор можуть вести переписку та вести відеоконференсію.
Інтерфейс IView описує інтерфейс для віна, у якому мігрант та модератор можуть вести переписку та вести відеоконференсію.
HealOperationRequest описує клас, який відображає структуру запиту на операцю від мігранта. Містить посилання на відповідного мігранта, терміновість операції, її опис, тип операції, дату та час, та складність операції.
OperationType містить усі можливі види операції, які можуть бути присутні у
HealOperationRequest.
Hospital описує поліклініку, у яку модератор може перенаправити мігранта з його терміновою ситуацією та у якій можна провести відповідну операцію.
MedicalJourney описує журнал, у якому модератор може вести історію переписки з мігрантом, записувати важливі побажання мігранта, та особливості його термінової ситуації.
UrgentSituationTreatment описує клас, відповідальний за лікування певної термінової ситуаці. Клас використовується модератором, та містить план лікування, список медикаментів, результат лікування та методи для початку та закінчення лікувального процесу.
Клас Education описує освіту модератора та містить ступінь освіти, заклад у якому отримана та рік отримання.

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

9
Отже, спочатку при вході в систему робиться перевірка, чи авторизований модератор у системі, якщо у нього ще немає аккаунта, тоді на сервер надсилається запит на форму для реєстрації, і після чого модератор повинен заповнити
інформацію про себе та надіслати її. Після того форма відправляється на сервер, дані про модератора зберігаються у базі даних та сервер генерує токен для входу в систему.
Якщо ж модератор уже зареєстрований у системі, йому достатньо ввести свій логін та пароль, веб клієнт надсилає дані на сервер та натомість отримує токен для входу, що дозволяє відобразити відповідну сторінку для модератора.
Модератору поступають запити тільки від тих мігрантів, мову яких модератор знає, розуміє та може нею спілкуватися.
Після чого модератор приймає запит на спілкування від мігранта залежно від того чи це переписка чи відео консультація. Після того, як модератор отримує дані від маранта про термінову ситуацію мігранта, він аналізує дані про термінову ситуацію, робить відповідний запис у журналі та використовує веб клієнт щоб надіслати дані на сервер Якщо мігрант зробив запит на операцію тоді модератор обробляє цей запит, визначає поліклініку у якій є можливість провести відповідну операцію. Тоді веб клієнт надсилає інформацію про місце проведення операції на сервер. Сервер у свою чергу зберігає інформацію про місце проведення операції у
Базі даних. Також модератор робить запис про заплановану операцію у журналі.
Далі модератор обробляє запит самої термінової ситуації, підбирає відповідне рішення та надсилає рішення на сервер використовуючи веб клієнт. Далі він запитує мігранта чи це рішення йому підходить і якщо ні, тоді підбирає нове рішення. Якщо рішення підійшло, то модератор записує дані у журнал та підбирає клініку для вирішення термінової ситуації, але тільки у тому випадку, якщо запиту на операцію не було. Тому що якщо запит на операцію був то поліклініка вже була підібрана. У випадку якщо мігранту підібрана поліклініка не підходить модератор повинен провести ще раз аналіз даних та вибрати кращий варіант поліклініки. Після того як мігрант узгодив поліклінік, модератор записує дані про поліклініку у журнал та завершує консультацію з мігрантом
4. Розробив діаграму розгортання.

10
Рис. 4. Діаграма розгортання
На моїй діаграмі розгортання зображено повну систему, яка складається з наступних блоків:
 Database: блок, у якому передбачено дві бази даних, одна з яких буде використовуватися для зберігання та опрацювання даних, а друга лише для резервного зберігання даних.
 Websever: веб-сервер – це головне ядро системи, у якому обробляються та виконуються усі обчислення та дії у системі. Інтерфейс бази даних та моделі, які у ній використовуються виконують функцію спілкування сервера із базою даних. o
Logger: виконує дію зберігання усіх текстових записів, помилок та важливих дій під час роботи програми в окремий файл для логування. o
WebInterface: інтерфейс, який є основою для роботи сервера і клієнта. Виконує основні обчислення. o
UnitTests: тести, за допомогою яких можна протестувати Веб-
інтерфейс. У разі помилок під час виконанні тестів чи під час неуспішного проходження усіх тестів логувальник записує усі необхідні подробиці в окремий файл. o
DesktopAPI / MobileAPI: проміжний шар для спілкування між клієнтом і сервером.
 DesktopClient: містить основну логіку комп'ютерного застосунку, юніт- тести. Взаємодіє із сервером за допомогою контрактів DesktopAPI.

12 який серіалізує дані перед відправкою на клієнт та десеріалізує отримані дані.
 Serializer: серіалізатор, який десеріалізує отримані дані та серіалізує дані перед відправкою.
 Unit-Tests: компонент, який містить тести для усіх сервісів та інтерфейсу бази даних, для запобігнення пошкодження моделей під час запису.
 MessageQueue:сервіс який займається тим, що додає усі запити у чергу та зберігає їх для послідовго запису у базу для уникнення помилок під час одночасного заватаження у базу.
 StorageModel: представляє модель складу для ліків для спілкування веб- серверу так бази даних.
 VideoConferenceModel: представляє модель відеоконференсії для спілкування веб-серверу так бази даних.
 MedicalJournalModel: представляє модель медичного журналу для спілкування веб-серверу так бази даних.
 PhychologistModel: представляє модель психолога для спілкування веб- серверу так бази даних.
 UrgentSituationModel: представляє модель термінової ситуації для спілкування веб-серверу так бази даних.
 MigrantModel: представляє модель мігранта для спілкування веб-серверу так бази даних.
 ModeratorModel: представляє модель модератора для спілкування веб- серверу так бази даних.
 ClinicModel: представляє модель клініки для спілкування веб-серверу так бази даних.
 StorageManager: представляє сервіс, який дає змогу керувати та взаємодіяти зі складом для ліків, роздачею ліків зі складу.
 VideoConferenceManager: представляє сервіс, який дає змогу запускати конференції, веде облік відкритих конференцій, дає змогу підключати двох користувачів до конференції.
 MedicalJournalManager: представляє сервіс, який дає змогу записувати та зчитувати записи зі журналу.
 PhychologistManager: представляє сервіс, який дає змогу комунікувати з психологом, та виконувати різні функції психолога.
 UrgentSituationManager: представляє сервіс, який дає змогу аналізувати термінову ситуацію, шукати для неї вирішення, та вирішувати термінову ситуацію.

13
 MigrantManager: представляє сервіс, який дозволяє мігранту комунікувати з системою, викликаючи інші сервіси.
 ModeratorManager: представляє сервіс, який дозволяє модератору комунікувати з системою, приймати запити від мігрантів, вирішувати їхні термінові ситуації, використовувати інші сервіси.
 ClinicModel: представляє сервіс для комунікації з клінікою, надає можливість госпіталізовувати мігрантів у клініці.
6. Розробив діаграму компонент для комп’ютерного застосунку.
Рис. 6. Діаграма компонент для комп’ютерного застосунку
На діаграмі компонент для комп’ютерного застосункузображено основні компоненти комп’ютерного клієнта:
 ApplicationController: сервіс, який займається отриманням та відправленням даних до клієнтів. Він використувує компонент Serializer, який серіалізує дані перед відправкою на клієнт та десеріалізує отримані дані.
 Serializer: серіалізатор, який десеріалізує отримані дані та серіалізує дані перед відправкою.
 Unit-Tests: компонент, який містить тести для усіх сервісів та інтерфейсу бази даних, для запобігнення пошкодження моделей під час запису.
 StorageViewModel: представляє модель складу для інтерфейсу.

14
 VideoConferenceViewModel: представляє модель відеоконференсії для
інтерфейсу.
 MedicalJournalViewModel: представляє модель медичного журналу для
інтерфейсу.
 PhychologistViewModel: представляє модель психолога для інтерфейсу.
 UrgentSituationViewModel: представляє модель термінової ситуації для
інтерфейсу.
 MigrantViewModel: представляє модель мігранта для інтерфейсу.
 ModeratorViewModel: представляє модель модератора для інтерфейсу.
 ClinicViewModel: представляє модель клініки для інтерфейсу.
 StorageView: інтерфейс для складу з ліками.
 VideoConferenceView: інтерфейс для відеоконференсії у системі.
 MedicalJournalView: інтерфейс медичного журналу у системі.
 PhychologistView: інтерфейс для психолога у системі.
 UrgentSituationView: інтерфейс термінової ситуації у системі.
 MigrantView: інтерфейс для мігранта у системі.
 ModeratorView: інтерфейс для модератора у системі.
 ClinicView: інтерфейс для клініки у системі.
7. Розробив діаграму компонент для мобільного застосунку.
Рис. 7. Діаграма компонент для мобільного застосунку
 ApplicationController: сервіс, який займається отриманням та відправленням даних на сервер.
 Serializer: серіалізатор, який десеріалізує отримані дані та серіалізує дані перед відправкою.

15
 Unit-Tests: компонент, який містить тести для усіх сервісів та інтерфейсу бази даних, для запобігнення пошкодження моделей під час запису.
 StorageView: інтерфейс для складу з ліками.
 VideoConferenceView: інтерфейс для відеоконференсії у системі.
 MedicalJournalView: інтерфейс медичного журналу у системі.
 PhychologistView: інтерфейс для психолога у системі.
 UrgentSituationView: інтерфейс термінової ситуації у системі.
 MigrantView: інтерфейс для мігранта у системі.
 ModeratorView: інтерфейс для модератора у системі.
 ClinicView: інтерфейс для клініки у системі.
ВИСНОВКИ
Під час виконання лабораторної роботи я розглянув мову UML та навчився створювати чотири типи діаграм. Окрім того, отримав досвід в роботі в команді з різними ролями. Діаграма класів описує класи, які необхідні для роботи програми.
В кожному класі описуються поля та методи. Після цього прописують всі типи взаємодій між існуючими класами. Діаграма класів відображає основні класи системи та їх взаємозв'язки.
Для опису своєї системи я створив наступні класи: мігрант, у якого присутня термінова ситуація та вирішення якої він хоче отримати.
Модератор, який власне шукає вирішення для термінової ситуації мігранта, використовуючи різні сервіси. Модератор надає підтримку вирішення таких термінових ситуацій: онкохворі, вагітні, діти з особливими потреби, люди з хронічними захворюваннями, літні люди, тощо.
На діаграмі класів я виконав вимогу завдання від PO, відобразивши клас
Медичного журналу. Модератор записує у журнал історію розмови з мігрантом, побажання мігранта щодо перенаправлення в лікарню, додаткову інформацію, яка стосується термінової ситуації мігранта, та яка може впливати на подальше лікування.
Вирішення термінової ситуації я загорнув свій відповідний клас, який використовується модератором, для того щоб підібрати вирішення термінової ситуації.
Важливою частиної діаграми була можливість для мігранта надіслати
Діаграма розгортання відображає фізичну архітектуру системи та розташування її компонентів. Система складається з двох баз даних: одна використовується для зберігання та опрацювання даних, а друга - для резервного

16 копіювання. Це забезпечує збереження і доступність даних навіть у випадку виникнення проблем з основною базою даних.
Центральним компонентом системи є веб-сервер, який виконує всі обчислення та дії. Він взаємодіє з базою даних через інтерфейс бази даних та моделі, що забезпечує ефективне спілкування сервера з даними.
Додатково, система має логер, який забезпечує збереження записів, помилок та важливих дій у окремий файл для логування. Це допомагає відстежувати та аналізувати роботу системи, а також виявляти та виправляти проблеми.
Для десктопного додатку було розроблено набір в’ю моделей для графічного відображення клініки, інтерфейсу для складу з ліками, для відеоконференсії, медичного журналу. Моделі для інтерфейсу модератора та мігранта, для термінової ситуації та психолога.
Для мобільного додатку я відобразив струтруку UI для відображення складу з ліками, для відеоконференсії, медичного журналу, модератора та мігранта, для термінової ситуації та психолога.
Усі ці компоненти разом утворюють повну систему, яка дозволяє зберігати, опрацьовувати та обмінюватись даними між клієнтами та сервером. Архітектура системи відображає структурованість та розподілену природу функціональності, що сприяє модульності, розширюваності та підтримці системи.
Ці діаграми допомагають уявити архітектуру системи та взаємодію її компонентів для забезпечення доступу до важливих даних та підвищення довіри переселенців до волонтерів.
Переваги UML: полегшують розуміння всього проекту та допомагають зрозуміти загальну структуру.
Недоліки: проектування за допомогою UML це довгий та складний процес, який потребує досвіду, концентрації та чіткого розуміння предметної області, адже за створеними діаграмами повинен бути реалізований проект.