Розглянемо системні вимоги, спираючись на основні цілі, для досягення яких має бути створена система.
Серверна частина веб-додатку має вміщувати в себе базу даних, а також програмний код, який є інтерфейсом доступу з клієнтської частини до бази даних.
Система повинна мати мікросервісну архітектуру, що дозволить покращувати та додавати нові можливості у майбутньому не дивлячись на вже створені модулі.
Одна з причин використання мікросервісів полягає в тому, що компанії хочуть мати можливість швидко щось змінювати, щоб швидше реагувати на зміни бізнес-вимог, випереджати конкурентів. Мікросервіси допомагають розробникам доставляти зміни швидше, безпечніше і з більш високою якістю, тобто зберігати швидкість розвитку продукту, навіть коли той стає неосяжних розмірів. Адже не тісно зв’язані сервіси дають можливість проводити зміни з більшою частотою ітерацій мінімізуючи вплив змін на решту частин системи [1].
Інформаційна система повинна мати інтуїтивно зрозумілий інтерфейс користувача, для зменшення порогу входу у систему, та користування всіма її функціями.
Для визначення функціональних вимог до інформаційної системи розроблена її функціональна модель з використанням стандарту IDEF0 [2].
Одними з найвідоміших і широко використовуваних методологій в області моделювання бізнес-процесів є методології сімейства IDEF. Сімейство IDEF з'явилося в кінці 60-х рр. XX ст. під назвою SADT (Structured Analysis and Design Technique) .
IDEF0 - методологія функціонального моделювання. Використовується для створення функціональної моделі, що відображає структуру і функції системи, а також потоки інформації і матеріальних об'єктів, що зв'язують ці функції [3].
На рис. 2.1 представлена концептуальна діаграма, яка відображає погляд на функцію «Автоматизоване створення оголошень про спортивні змагання навчального закладу» з точки зору користувача системи.
Концептуальна діаграма дозволяє побачити систему в цілому у вигляді «чорного ящика», коли відомі входи системи, і результат роботи системи.
Рисунок 2.1 – Концептуальна діаграма функції «Автоматизоване створення оголошень про спортивні змагання навчального закладу» з точки зору користувача
Для створення повноцінної автоматизованої системи необхідно провести її аналіз. Для цього була розроблена декомпозиція системи першого рівня.
На концептуальній діаграмі входами є «інформація про спортивне змагання» та «інформація про спортивні заклади», а виходом є «оголошення» або «відмова». В цьому випадку, для створення оголошення, потрібні дані спортивне змагання та про навчальні заклади між якими воно проходить. В якості керуючих стрілок вказані «Законодавство» та «Закон України про використання інтелектуальної власності». Механізмами слугують «користувач» і «система».
Мета – уточнення функціональних вимог Web-ресурсу.
Точка зору – користувач програмної системи.
На рис. 2.2 представлена декомпозиція концептуальної діаграми. Декомпозиція дозволяє розбити процес на менші підпроцеси, що в свою чергу дозволяє розробнику системи проникнутися всіми функціональними залежностями системи. Для отримання ще точніших результатів діяльності процесу можна розбити його підпроцеси на інші оперції, дії, функціїї.
Рисунок 2.2 – Діаграма декомпозиції, яка представляє функції системи
На рис. 2.2 представлена декомпозиція функції «Автоматизоване створення оголошень про спортивні змагання навчального закладу» системи. Ця операція декомпозується на три підфункції «Обробка інформації», «Побудова підходящої стурктури для візуалізації оголошення» і «Візуалізація оголошення». Під час виконання функції обробки інформації на вхід подаються дані про спортивні змагання та про спортивні заклади. В ці дані входить інформація про конкретну спортивну подію, про яку йтиметься в оголошенні, а також інформацію про спортивний заклад, гурток, комманду чи її членів. Далі дані оброблюються системою, перевіряються на використання чужої інтелектуальної власності та на виході формуються оброблені дані. В хід вступає функція «Побудова підходящої стурктури для візуалізації оголошення», за допомогою якої система будує структурний вигляд оголошення, враховуючи оброблені дані, що прийшли на вхід. Передавши структуру оголошення на вхід до функції, що реалізує візуалізацію оголошення, система виконує програмний алгоритм візуалізації даних, після чого на виході з’являється готове оголошення. На рис. 2.3 представлена декомпозиція функції «Обробка інформації» системи.
Рис. 2.3 – Діаграма декомпозиції функції «Обробка інформації»
Ця функція декомпозується на 3 підфункції: «Визначення виду спорту», «Визначення спортивного закладу», «Перевірка інформації».
Під час виконання функції «Визначення виду спорту» користувач системи вносить інформацію про вид спорту, за яким буде закріплене оголошення.
Під час виконання функції «Визначення спортивного закладу» користувач системи вносить інформацію про спортивні заклади між командами якого, буде проходити змагання, за закріплений видом спорту.
Після того, як користувач вніс дані про спортивні заклади, інформація на виході передається для перевірки інформації на права інтелектуальної власності. В якості керуючих стрілок були використані «Законодавство» та «Закон України про використання інтелектуальної власності». Коли оголошення не проходить перевірку іформації то система на виході подає відмову у створені такого оголошення, якщо перевірка закінчилась вдало, то функція подає на вихід оброблену інформацію.
На рис. 2.4 представлена декомпозиція функції «Побудова підходящої структури для візуалізації оголошення» системи. Ця функція має 2 підфункції: «Підбір підходящого макету для оголошення» і «Створення структури».
Рис. 2.4 – Діаграма декомпозиції функції «Побудова підходящої структури для візуалізації оголошення»
Під час виконання першої функції відбувається підбір макету для створення структури оголошення. За допомогою оброблених даних, система видає макети, які підходять найбільше, що дає змогу користувачу зменшити час для створення власного макету. Користувач системи вибирає із запропонованих йому макетів для оголошень на основі оброблених даних. На основі вибору, система будує структурний вигляд оголошеня, що і є виходом функції.
На рис. 2.5 представлена декомпозиція функції «Візуалізація оголошення» системи. Ця функція має 2 підфункції: «Формування графічної презентації оголошення» і «Формування оголошення».
Рис. 2.5 – Діаграма декомпозиції функції «Візуалізація оголошення»
На вхід першої функції «Формування графічної презентації оголошення» надходить структурний вигляд оголошення, користувач має можливість внести остаточні зміни в оголошенні, після підтвердження яких, система подає на вихід графічний вигляд оголошення. Далі на основі цих даних, система формує і створює оголошення про спортивну подію.
На рис. 2.6 представлена структура IDEF0 діаграми.
Рис. 2.6 – Структура IDEF0 діаграми
Таким чином, проведене функціональне моделювання дозволило уточнити функціональні вимоги до розроблюваної системи.
Функціональні вимоги до системи створення оголошень про спортивні змагання навчальних закладів:
система повинна збирати та зберігати інформаці про оголошення та їх авторів;
система повинна надавати можливість користувачу зареєструватися та внести особисті дані про себе;
система повинна прив’язувати створені оголошення до аккаунту його автора;
система повинна виконувати функцію перевірки інформацію на права інтелектуальної власності, перед створення будь-якого оголошення;
система повинна надавати можливість редагувати оголошення після його створення;
система повинна надавати користувачеві вибір з існуючих макетів для створення структури оголошення;
система повинна надавати можливість користувачеві прив’язати свої сторінки з соціальних мереж;
система повинна надавати можливість поділитися своїм оголошенням в інші соціальні мережі або медіа-ресурси;
система повинна надавати можливість скачати оголошення у вибраному форматі;
система повинна надавати можливість розмістити оголошення у власній стрічці новин.
Діаграма варіантів використання (Use case diagram) описує взаємовідносини і залежності між групами варіантів використання і дійовими особами, які беруть участь в процесі [16].
На діаграмі (рис. 2.7), зображені функції адміністратора і користувача в системі. Відповідно до даної діаграми користувач може виконувати такі функції, як:
реєстрація;
авторизація;
зміна особистої інформації у системі;
створення нового оголошення;
розміщення оголошення до стрічки новин;
змінювати та редагувати оголоешння;
ділитися оголошенням в інших соціальних мережах.
Рис. 2.7 – Функції адміністратора і користувача у системі
Адміністратор системи може виконувати такі функції як:
перевірка оголошень створених користувачем на предмет порушення законодавства
адміністрування даних користвувача
Таким чином, адміністратор виконує функції перевірки інформації, введеної користувачем, що дозволяє йому забороняти публікацію оголошень, та блокувати користувачів.
В результаті проведеного аналітичного огляду існуючих інформаційних систем забезпечення діяльності спортивних клубів навчальних закладів було розроблено структурну схему, яку наведено на рисунку 3.1.
Рис. 3.1 – Стуктурна схема інформаційної системи підтримки спортивних змагань навчального закладу
На приведеній структурній схемі можна побачити елементи інформаційної системи підтримки спортивних змагань навчального закладу. Ця система складається з наступних компонентів:
база даних;
блок статистики та агрегації;
блок створення оголошення;
блок адміністрування оголошень;
інтерфейс користувача;
блок моделювання структури спортивних змагань, закріплених за навчальними закладами.
При виборі СУБД є важливим наявність ефективних засобів розробки. Це кошти, інтуїтивно-зрозумілий і зручний для розробника інтерфейс, що надають можливість користувачам самостійно і швидко налаштовувати інформаційні системи відповідно до вимог бізнесу. На сьогоднішній день відомо велика кількість різних серверів баз даних SQL.
Oracle Database – це об'єктно-реляційна система, яка підтримує технології, що забезпечують управління створення та використання баз даних (об'єктно-орієнтований підхід) [24].
Oracle має ряд переваг:
більш зручні і функціональні засоби адміністрування;
технічна підтримка корпоративного рівня;
література по продукту;
сертифікація з обладнанням та у продуктах інших фірм;
наявність навчальних центрів;
підтримка старих версій.