2.2 Моделювання програмного забезпечення
Специфікація вимог до програмного забезпечення – це повний опис поведінки системи що розробляється. Вона включає множину прецедентів які описують всі взаємодії, які користувачі мають з програмним забезпеченням. Прецеденти також відомі як функціональні вимоги. На додачу до прецедентів SRS також включає нефункціональні (чи додаткові) вимоги. Нефункціональні вимоги є вимогами які накладають обмеження на проект, чи реалізацію (такі як вимоги інженерії продуктивності, стандарти якості, чи обмеження проектування).
Діаграма прецедентів – діаграма, на якій зображено відношення між користувачем та прецедентами в системі (рис. 2.1).
Для проектування діаграми прецедентів спочатку необхідно визначити дійових осіб (акторів), а потім визначити, які дії у системі може виконувати кожен з акторів.
Рисунок 2.1 – Діаграма прецедентів
Діаграми прецедентів виступають основою подальшої деталізації системи у формі різних логічних і фізичних моделей. Зокрема, прецеденти допомагають перевіряти й контролювати архітектуру програмної системи у процесі її розробки.
2.3 Моделювання даних
Інформаційна модель – модель об'єкта, представлена у вигляді інформації, що описує істотні для даного розгляду параметри та змінні величини об'єкта, зв'язки між ними, входи і виходи об'єкта і дозволяє шляхом подачі на модель вхідних величин моделювати можливі стани об'єкта.
База даних містить таблиці, представлені нижче:
Admins, призначена для зберігання інформації про користувачів (рис. 2.2).
Рисунок 2.2 – Конструктор таблиці «Admins»
Cabinet. В даній таблиці відбувається збереження інформації про кабінети комплексу (рис 2.3).
Рисунок 2.3 – Конструктор таблиці «Cabinet»
Cards, призначена для зберігання інформації про абонементи клієнтів комплексу (рис 2.4).
Рисунок 2.4 – Конструктор таблиці «Cards»
CardTypes, призначена для зберігання інформації про типи абонементів закладу (рис 2.5).
Рисунок 2.5 – Конструктор таблиці «CardTypes»
Client, призначена для зберігання особистої інформації про клієнтів комплексу (рис 2.6).
Рисунок 2.6 – Конструктор таблиці «Client»
Data, призначена для зберігання інформації про відвідування комплексу клієнтами. (рис 2.7).
Рисунок 2.7 – Конструктор таблиці «Data»
Materials, призначена для зберігання інформації про розхідні матеріали комплексу (рис 2.8).
Рисунок 2.8 – Конструктор таблиці «Materials»
Service, призначена для зберігання інформації про послуги закладу (рис 2.9).
Рисунок 2.9 – Конструктор таблиці «Service»
Spec, призначена для зберігання інформації про спеціалізацію інструкторів закладу (рис 2.10).
Рисунок 2.10 – Конструктор таблиці «Spec»
Speciality, призначена для зберігання інформації про працівників комплексу (рис 2.11).
Рисунок 2.11 – Конструктор таблиці «Speciality»
Інші таблиці створені за аналогічною структурою.
На основі інформаційної моделі розроблена логічна модель даних (рис 2.12).
Рисунок. 2.12 – Логічна модель даних
В даній моделі представлені зв’язки між реляційними таблицями, що дозволяє відслідковувати цілісність зв’язків та даних.