3. Діаграма варіантів використання Web-платформи для створення оголошень про спортивні події

Діаграма варіантів використання (Use case diagram) описує взаємовідносини і залежності між групами варіантів використання і дійовими особами, які беруть участь в процесі [16].

На діаграмі (рис. 2.7), зображені функції адміністратора і користувача в системі. Відповідно до даної діаграми користувач може виконувати такі функції, як:

• реєстрація;

• авторизація;

• зміна особистої інформації у системі;

• створення нового оголошення;

• розміщення оголошення до стрічки новин;

• змінювати та редагувати оголоешння;

• ділитися оголошенням в інших соціальних мережах.

Рис. 2.7 – Функції адміністратора і користувача у системі

Адміністратор системи може виконувати такі функції як:

• перевірка оголошень створених користувачем на предмет порушення законодавства

• адміністрування даних користвувача

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

3. Компоненти інформаційної системи підтримки спортивних змагань навчального закладу

1. Розробка структурної схеми інформаційної системи підтримки спортивних змагань навчального закладу.

В результаті проведеного аналітичного огляду існуючих інформаційних систем забезпечення діяльності спортивних клубів навчальних закладів було розроблено структурну схему, яку наведено на рисунку 3.1.

Рис. 3.1 – Стуктурна схема інформаційної системи підтримки спортивних змагань навчального закладу

На приведеній структурній схемі можна побачити елементи інформаційної системи підтримки спортивних змагань навчального закладу. Ця система складається з наступних компонентів:

• база даних;

• блок статистики та агрегації;

• блок створення оголошення;

• блок адміністрування оголошень;

• інтерфейс користувача;

• блок моделювання структури спортивних змагань, закріплених за навчальними закладами.

2. Вибір архітектури системи

Архітектура програмного забезпечення – спосіб структурування програмної системи, тобто розділ системи на абстракції [27]. Залежно від потреб і технологій існують різні типи «Model-View-Controller (MVC)», «Сервіс-орієнтована архітектура (SOA)», «Трирівнева архітектура (Multitier architecture)», «Клієнт-серверна архітектура» [31]. Для розроблюваної програмної системи оптимальною є клієнт-серверна архітектура, схема якої зображена на рис. 3.2.

Рисунок 3.2 – Схема клієнт-серверної архітектури

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

3. Логічне та фізичне моделювання бази даних системи

Логічне та фізичне моделювання бази даних автоматизованої системи проводилося з використанням CASE-засобу «Allfusion ErWin Data Modeler». Даний засіб дозволяє змоделювати логічну і фізичну моделі даних системи, що б визначити набір сутностей, які беруть участь в роботі системи, і визначити структуру сховища даних [28].

Методика створення моделі реляційної бази даних з використанням CASE-засобу «Allfusion Erwin Data Modeler» складається з наступних етапів: складання логічної моделі даних, потім, на її основі, фізичної моделі даних.

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

Після цього будується фізична модель даних. Вона представляє із себе вже діаграму готової для створення в конкретній СУБД структури сховища даних.

Для цього необхідно конкретизувати доменні типи атрибутів сутностей, присвоївши атрибутам типи даних обраної системи управління базами даних.

Логічна модель бази даних інформаційної системи наведена на рис. 3.3.

Рис. 3.3 – Логічна модель бази даних системи

Сутності предметної області, які увійшли у модель, зображені в таблиці 3.1

Рис. 3.4 – Фізична модель бази даних

Створення БД (серверної частини) системи здійснювалося за допомогою CASE-засобу Allfusion Erwin Data Modeler [30].

Сутність Users необхідна для збереження усіх даних про користувача, а також для прив’язки до нього аккаунтів із соціальних мереже таких як Twitter, Facebook.

Сутність Template необхідна для збереження інформації про макети, доступні для створення оголошень.

Сутність Active_Storage_Blob необхідна для збереження всіх ресурсів оголошення на сторонньому сервісі Amazon Web Services (AWS) [33]. Таким чином, система зможе зберігати об’єкти типу Blob на сторонньому ресурсі та зменшити навантаження на основний сервер.

Сустності Favorite_template, Template_tag, Template_keyword, Tag та Keyword націлені на спрощення пошуку макету для оголошення, а також для SEO оптимізації сайту, що збільшує можливість потрапляння нових користувачів на сайт, за рахунок релевантних пошукових запитів.

Сутність Institution націлена на збереження інформації про існуючі установи, навчальні заклади, спортивні гуртки тощо.

Сутність Preset націлена на збереження інформації про попередні установки оголошення, які вносив користувач.

Сутність PictureBase64 націлення на збереження необхідних користувачеві ресурсів.

Сутність Folder націлена на створення стуктуризації ресурсів користувача, необхідних для створення оголошення.