Практичне завдання №3
ТВ-33 Козінченко Тимофій Олександрович
1. Визначення основних функціональних та нефункціональних вимог
Функціональні вимоги:
1. Облік вантажу:






Реєстрація надходження вантажу на термінал (звідки, куди, тип вантажу, вага,
габарити, ідентифікатор).
Розподіл вантажу:
o Визначення вантажу для місцевого споживача.
o Визначення вантажу для транзиту на інший термінал.
Відстеження статусу вантажу (на терміналі, в дорозі, доставлено).
Генерація супровідних документів (накладні, маршрутні листи).
Пошук вантажу за ідентифікатором.
Зберігання історії переміщень вантажу.
2. Управління персоналом:




Облік робочого часу постійних працівників (з урахуванням 40-годинного
робочого тижня та різних змін).
Облік робочого часу тимчасових працівників (довільна кількість годин).
Розрахунок заробітної плати (можливість, але не обов'язкова вимога на даному
етапі).
Планування графіків роботи (з урахуванням пікових навантажень).
3. Управління терміналами:




Облік терміналів (розташування, місткість).
Призначення вантажу на термінали (маршрутизація).
Моніторинг завантаженості терміналів.
Інформація про наявність вільних доків
4. Звітність:




Генерація звітів про обсяги перевезень (за період, за напрямками, за типами
вантажу).
Генерація звітів про завантаженість терміналів.
Генерація звітів про роботу персоналу.
Генерація звітів про час перебування вантажу на терміналах.
Нефункціональні вимоги:
1. Продуктивність:




Система повинна обробляти великі обсяги даних про вантаж та перевезення.
Час обробки запитів повинен бути мінімальним (швидкий пошук вантажу,
швидке формування звітів).
Система повинна витримувати пікові навантаження (кінець тижня).
Система повинна забезпечувати швидкий доступ до данних.
2. Масштабованість:


Система повинна бути здатна до розширення (додавання нових терміналів,
збільшення обсягів вантажу).
Додавання нових функцій не повинно суттєво впливати на продуктивність.
3. Надійність:




Система повинна бути стійкою до збоїв.
Дані повинні бути захищені від втрати або пошкодження.
Система повинна мати механізми резервного копіювання та відновлення.
Система не повинна допускати, щоб вантаж знаходився на терміналі довше 16
годин.
4. Безпека:



Доступ до даних повинен бути обмежений (авторизація користувачів).
Різні користувачі повинні мати різні рівні доступу (ролі).
Повинна бути забезпечена конфіденційність даних.
5. Зручність використання (Usability):


Інтерфейс користувача повинен бути інтуїтивно зрозумілим.
Система повинна бути легкою у використанні для різних категорій користувачів
(диспетчери, менеджери, адміністратори).
6. Повторне використання:
Компоненти системи повинні бути розроблені таким чином, щоб їх можна було
повторно використати в інших проектах компанії, якщо це можливо.
7. Здатність до змін:
Система повинна бути спроектована з урахуванням легкого внесення змін.
8. Простота (розробки та супроводу):
Архітектура повинна бути якомога простішою, при цьому задовільняти решту
вимог.
9. Ефективність (використання ресурсів):

Мінімальне споживання ресурсів серверів.

Мінімальне навантаження на мережу.
2. Побудування функціональної та структурної схеми архітектури ПЗ.
Функціональна схема:
3. Представлення діаграми компонентів для системи.
Діаграма компонентів:
Діаграма компонентів відображає загальну архітектуру системи транспортної
компанії, показуючи основні функціональні блоки, такі як Користувацький інтерфейс,
Система Авторизації, Управління Вантажем, Управління Персоналом, Управління
Терміналами та Звітність, а також Базу Даних. Діаграма ілюструє залежності між цими
компонентами, демонструючи потік даних та управління. Наприклад, Користувацький
інтерфейс залежить від Системи Авторизації для контролю доступу, а всі функціональні
компоненти взаємодіють з Базою Даних для зберігання даних. Система спроектована як
масштабована, надійна та продуктивна, про що свідчить центральний компонент
"Система".
4. Представлення структурного елементу у вигляді діаграми класів
Ця діаграма класів деталізує структуру компонента "Управління персоналом - Облік
часу, планування змін". Вона представляє ключові сутності, необхідні для керування
графіками роботи та обліком робочого часу працівників. Діаграма включає класи Employee,
Shift, WorkSchedule та TimeRecord, що відображають працівників, робочі зміни, графіки
роботи та записи робочого часу відповідно. Також, представлені класи, що візуально
імітують нотатки, для відображення перелічень, таких як EmployeeType та DayOfWeek, та
описові нотатки для основних класів. Діаграма ілюструє взаємозв'язки між цими класами,
наприклад, планування графіків роботи працівниками, включення змін до графіків та
наявність записів робочого часу у працівників. Ця структура забезпечує можливість
системи керувати як постійними, так і тимчасовими працівниками, їхніми змінами та
робочими годинами.
5. Діаграма послідовностей процесу реєстрації надходження вантажу на
термінал
Діаграма ілюструє процес, що починається з запиту диспетчера через
користувацький інтерфейс на реєстрацію вантажу. Інтерфейс передає дані вантажу до
компонента "Управління вантажем", який ініціює перевірку авторизації користувача через
"Систему авторизації". У разі успішної авторизації, "Управління вантажем" зберігає дані
нового вантажу в базі даних, оновлює статус вантажу на "На терміналі" та відправляє
підтвердження реєстрації з ID вантажу назад через інтерфейс диспетчеру. Якщо авторизація
відхилена, "Управління вантажем" повідомляє інтерфейс про помилку авторизації, яка
відображається диспетчеру.
6. Обрання шаблонів проектування, які задовольняють вимогам ПЗ
Для забезпечення ефективної розробки та подальшої підтримки програмного
забезпечення транспортної компанії, доцільно розглянути застосування декількох
ключових шаблонів проектування.
Перш за все, багатошарова архітектура є фундаментальним рішенням для
організації системи. Розподіл на рівні – представлення, бізнес-логіки, даних та зберігання –
забезпечує чітку структуру та поділ відповідальності. Перевагою такого підходу є
підвищення модульності та здатності до модифікації. Внесення змін в одному шарі
мінімізує вплив на інші, що спрощує оновлення та розширення функціоналу. Така
структура сприяє повторному використанню компонентів та загальній стабільності
системи.
Для оптимізації взаємодії з даними рекомендується використання шаблону
Репозиторій. Він створює рівень абстракції між бізнес-логікою та фізичним зберіганням
даних. Застосування Репозиторію дозволяє ізолювати бізнес-логіку від специфіки
роботи з базою даних. Це значно полегшує тестування та міграцію на інші системи
управління базами даних в майбутньому, забезпечуючи гнучкість та адаптивність
рішення.
В контексті управління різними алгоритмами, такими як маршрутизація чи
планування, шаблон Стратегія є вельми корисним. Він дозволяє інкапсулювати різні
алгоритми та забезпечити їх взаємозамінність. Використання Стратегії надає можливість
легко додавати нові алгоритми або модифікувати існуючі, не змінюючи клієнтський
код, що підвищує гнучкість системи та її здатність до еволюції з часом.
Для реалізації механізмів реального часу, таких як відстеження статусу вантажу,
шаблон Спостерігач є ефективним рішенням. Він забезпечує автоматичне сповіщення
зацікавлених компонентів про зміни стану об'єкта. Впровадження Спостерігача дозволить
забезпечити оперативне оновлення інформації в користувацькому інтерфейсі та інших
підсистемах, підвищуючи інформативність та чуйність системи.
Для управління процесом створення різних типів об'єктів, таких як вантажі,
працівники чи звіти, доцільно застосувати Фабричний метод або Абстрактну фабрику.
Ці шаблони спрощують процес створення об'єктів та зменшують залежність коду від
конкретних класів. Використання Фабричних шаблонів сприяє розширюваності
системи та полегшує додавання нових типів об'єктів без значних змін в існуючому коді,
забезпечуючи гнучкість розробки.
Застосування зазначених шаблонів проектування є обґрунтованим вибором для
розробки програмного забезпечення транспортної компанії, оскільки вони сприяють
створенню модульної, гнучкої, масштабованої та надійної системи, що відповідає
сучасним вимогам до корпоративних інформаційних систем.
7. Обґрунтування компонентів та з’єднань
Так як у нас діаграма компонентів вже є, то одразу її обґрунтуємо.
Компоненти та їх обґрунтування (скорочено):
1. Користувацький інтерфейс: Забезпечує зручність використання для різних
користувачів, мінімізуючи час навчання та помилки, підвищуючи продуктивність.
2. Система авторизації: Гарантує безпеку даних та контроль доступу на основі
ролей, забезпечуючи конфіденційність.
3. Управління вантажем: Ключовий компонент для ефективного управління
перевезеннями, відстеження вантажу та прозорості послуг.
4. Логіка маршрутизації: Забезпечує оптимізацію маршрутів, зниження витрат та
прискорення доставки.
5. Генерація документів: Автоматизує створення супровідних документів,
забезпечуючи відповідність нормам та ефективний документообіг.
6. Управління персоналом: Оптимізує використання трудових ресурсів,
планування змін та облік робочого часу.
7. Планування графіків: Забезпечує гнучке планування з урахуванням пікових
навантажень, гарантуючи своєчасну обробку вантажу.
8. Управління терміналами: Централізоване управління мережею терміналів,
маршрутизація вантажів та моніторинг доків для оптимізації ресурсів.
9. Моніторинг завантаженості: Забезпечує оперативний моніторинг стану
терміналів, дозволяючи швидко реагувати на зміни.
10. Звітність: Генерує різноманітні звіти для аналізу ефективності та прийняття
стратегічних рішень.
11. Генерація звітів: Забезпечує глибоку аналітику даних за різними критеріями,
виявляючи тенденції та проблемні зони.
12. База даних: Забезпечує надійне зберігання та швидкий доступ до даних,
фундамент для всієї системи.
13. Резервне копіювання: Гарантує захист від втрати даних та безперервність
бізнесу.
З'єднання та їх обґрунтування (скорочено):







Інтерфейс -> Авторизація: Контроль доступу користувачів.
Авторизація -> Функціональні компоненти: Контроль доступу до функцій.
Управління вантажем -> Маршрутизація: Передача даних для визначення
маршруту.
Управління вантажем -> Генерація документів: Передача даних для генерації
документів.
Управління персоналом -> Планування графіків: Передача даних для
планування графіків.
Управління терміналами -> Моніторинг: Отримання даних про завантаженість
терміналів.
Звітність -> Генерація звітів: Передача параметрів для генерації звітів.


Функціональні компоненти -> База даних: Зберігання та отримання даних.
База даних -> Резервне копіювання: Захист даних від втрати.
8. Архітектурні та шаблонні адаптації на основі пріоритетів вимог
1. Розширення (Пріоритет підвищено):


Архітектура ПЗ: Система проектується з фокусом на модульність та компонентність.
Для досягнення гнучкості розглядаються мікросервісні або плагінні архітектури, що
дозволяють незалежно додавати нові функції. В межах моноліту робиться акцент на
слабку зв’язність між модулями, щоб нові функції інтегрувалися без значних змін
існуючого коду.
Шаблони проектування: Стають більш актуальними шаблони, що сприяють
розширюваності та гнучкості. До них належать Абстрактна фабрика, Декоратор,
Адаптер, та Стратегія. Ці шаблони мінімізують залежності та полегшують додавання
нових можливостей у майбутньому.
2. Здатність до змін (Пріоритет підвищено):


Архітектура ПЗ: Наголос робиться на адаптивності та гнучкості. Розглядаються подіїорієнтовані архітектури, що дозволяють компонентам реагувати на події асинхронно,
зменшуючи залежності. Також, Доменно-орієнтоване проектування (DDD) може
використовуватись для організації системи навколо бізнес-доменів, спрощуючи зміни
в окремих областях бізнесу.
Шаблони проектування: Шаблони, що підтримують слабку зв'язність та гнучкість
поведінки стають ключовими. Це включає Стратегію, Стан, Команду, Спостерігача,
Посередника. Ці шаблони дозволяють змінювати поведінку системи без значних
архітектурних змін, роблячи систему більш стійкою до нових вимог.
3. Простота (Пріоритет підвищено):


Архітектура ПЗ: Пріоритетом стає простота розробки та підтримки. Розглядаються
монолітні або прості багатошарові архітектури, якщо вони задовольняють основні
вимоги. Уникають зайвої складності та розподілених систем. Використовуються
конвенції над конфігурацією для спрощення налаштування та зменшення обсягу коду.
Шаблони проектування: Акцент робиться на шаблонах, що спрощують код та
проектування. Це можуть бути Фабричний метод, Стратегія, та Шаблонний метод.
Уникають складних шаблонів, якщо простіші рішення є достатніми.
4. Ефективність (Пріоритет підвищено):

Архітектура ПЗ: Система оптимізується для максимальної продуктивності.
Мікросервіси можуть використовуватись для масштабування продуктивних частин.
Застосовується кешування на різних рівнях, оптимізуються запити до бази даних,

використовуються черги повідомлень для асинхронної обробки. Вибір технологій та
інфраструктури підпорядковується вимогам ефективності.
Шаблони проектування: Пріоритетними стають шаблони, що покращують
продуктивність та ефективність використання ресурсів. Це включає Легковаговик
(Flyweight), Шаблони кешування, та Замісник (Proxy). Ретельно аналізується вплив
кожного шаблону на продуктивність.
9. Звіт
Зроблено