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

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

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

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

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

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

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

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

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

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

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

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

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

Таблиця 3.1 – Сутності логічної моделі БД

№	Назва сутності	Назва атрибуту	Опис	Тип даних	Обмеження
1	Users	user_id	Ідентифікатор користувача	Лічильник, ціле	PK
		email	Електрона пошта	Текст, довжиною 255 символів
		encrypted_password	Зашифрований пароль	Текст, довжиною 255 символів
		reset_password_token	Токен для зміни паролю	Текст, довжиною 255 символів
		created_at	Дата створення аккаунта	Дата
		updated_at	Дата зміни даних	Дата
		first_name	Ім’я користувача	Текст, довжиною 255 символів
		organization_name	Назва організації	Текст, довжиною 255 символів
		role	Призначення	Текст, довжиною 255 символів
		fb_token	Токен для Facebook	Текст, довжиною 255 символів
		fb_uid	Унікальний ідентифікатор Facebook	Текст, довжиною 255 символів
		fb_avatar	Аватар Facebook	Текст, довжиною 255 символів
		twitter_token	Токен для Twitter	Текст, довжиною 255 символів
		twitter_uid	Унікальний ідентифікатор Twitter	Текст, довжиною 255 символів
		role_in_organization	Посада в організації	Текст, довжиною 255 символів
		city	Місто	Текст, довжиною 255 символів
		state	Стать	Ціле
		approved	Налаштування для підтвердження акаунту	Ціле
2	template	template_id	Ідентифікатор макету	Лічильник, ціле	PK
		name	Назва макету	Текст, довжиною 255 символів
		class_name	Назва класу	Текст, довжиною 140 символів
		created_at	Дата створення макету	Дата
		updated_at	Дата зміни даних	Дата
		preview_image_url	Посилання на зображення для передпоказу макету	Текст, довжиною 255 символів
		default_preset	Налаштування макету за замовчування	Текст, довжиною 255 символів
3	template_tag	template_tag_id	Ідентифікатор зв’язки тегу та макету	Лічильник, ціле	PK
		template_id	Ідентифікатор макету	Ціле	FK
		tag_id	Ідентифікатор тегу	Ціле	FK
		created_at	Дата створення	Дата
		updated_at	Дата оновлення	Дата
4	tag	tag_id	Ідентифікатор тегу	Лічильник, ціле	PK
		name	Назва тегу	Текст, довжиною 255 символів
		created_at	Дата створення	Дата
		updated_at	Дата оновлення	Дата
5	template_keyword	template_keyword_id	Ідентифікатор ключового слова та макету	Лічильник, ціле	PK
		template_id	Ідентифікатор макету	Ціле	FK
		keyword_id	Ідентифікатор ключового слова	Ціле	FK
		created_at	Дата створення	Дата
		updated_at	Дата оновлення	Дата
6	keyword	keyword_id	Ідентифікатор ключового слова	Лічильник, ціле	PK
		name	Назва ключового слова	Текст, довжиною 255 символів
		created_at	Дата створення	Дата
		updated_at	Дата оновлення	Дата
7	favorite_template	favorite_template_id	Ідентифікатор улюбленого макету	Лічильник, ціле	PK
		user_id	Ідентифікатор користувача	Ціле	FK
		template_id	Ідентифікатор макету	Ціле	FK
		created_at	Дата створення	Дата
		updated_at	Дата оновлення	Дата
8	institution	institution_id	Ідентифікатор установи	Лічильник, ціле	PK
		institution_name	Назва установи	Текст, довжиною 255 символів
		logo	Логотип установи	Текст, довжиною 255 символів
		is_college	Перевірка на коледж	Ціле
		created_at	Дата створення	Дата
		updated_at	Дата оновлення	Дата
9	user_annoucement	user_annoucement_id	Ідентифікатор оголошення	Лічильник, ціле	PK
		user_id	Ідентифікатор користувача	Ціле	FK
		title	Деталі	Текст, довжиною 255 символів
		folder_id	Ціле	Ціле	FK
10	folder	folder_id	Ідентифікатор папки	Лічильник, ціле	PK
		name	Назва папки	Текст, довжиною 255 символів
		ancestry	Каталог підпапок	Текст, довжиною 255 символів
		created_at	Дата створення	Дата
		updated_at	Дата оновлення	Дата
		user_id	Ідентифікатор користувача	Ціле	FK
		picture_folder	Налаштування для збережння оголошень	Ціле
11	pictureBase64	pictureBase64_id	Ідентифікатор картинок в форматі Base64	Лічильник, ціле	PK
		base_64	Код картинки	Блоб
		template_id	Ідентифікатор макету	Ціле	FK
		user_id	Ідентифікатор користувача	Ціле	FK
		folder_id	Ідентифікатор папки	Ціле	FK
		created_at	Дата створення	Дата
		updated_at	Дата оновлення	Дата
12	preset	preset_id	Ідентифікатор попередіх налаштувань макету	Лічильник, ціле	PK
		user_id	Ідентифікатор користувача	Ціле	FK
		template_id	Ідентифікатор макету	Ціле	FK
		body	Тіло попередніх установок макету
		created_at	Дата створення	Дата
		updated_at	Дата оновлення	Дата
		name	Назва попередньої установки макету	Текст, довжиною 255 символів
		new_preset	Налаштування для перевірки, на новизну установки	Текст, довжиною 1024 символів

На рисунку 3.4 приведена фізична модель бази даних

Рис. 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 націлена на створення стуктуризації ресурсів користувача, необхідних для створення оголошення.