Лабораторна робота № 3

Тема: Вибір архітектури ІС

Мета роботи: на основі аналізу предметної області вибирати відповідний
тип архітектури ПЗ

Завдання:
 вибрати і погодити з викладачем тематику програмного продукту;
 зібрати інформацію та провести короткий аналіз предметної області
для вибраної ІС;
 проаналізувати та описати завдання, які повинне виконувати ПЗ;
 описати апаратні складові програмної системи;
 розподілити функції програмної системи між функціональними
підсистемами. Описати архітектуру ІС з точки зору системи, що складається з
функціональних підсистем і шарів;
 описати програмні компоненти інформаційної системи, що
реалізують її функціональні підсистеми на різних шарах;
 описати розподіл програмних компонентів по ланках архітектури
«клієнт-сервер» або «файл-сервер»;
 зробити висновок;
 оформити звіт.

Теоретичні відомості
Визначення
"Архітектура ― це фундаментальна організація системи, втілена в
компонентах, їх взаємозв'язках, середовищі, і принципах, що управляють їх
дизайном і еволюцією".
Архітектура програмного забезпечення (англ. Software architecture) - це
структура програми або обчислювальної системи, яка включає програмні
компоненти, видимі зовні властивості цих компонентів, а також відносини між
ними. Цей термін стосується також документування архітектури програмного
забезпечення.
 Документування архітектури ПО спрощує процес комунікації і дозволяє
зафіксувати прийняті на ранніх етапах проектування рішення про
високорівневої дизайні системи і дозволяє використовувати компоненти цього
дизайну і шаблони повторно в інших проектах.
Архітектура програмного забезпечення - сукупність найважливіших
рішень про організацію програмної системи. Архітектура включає:
• вибір структурних елементів і їх інтерфейсів, за допомогою яких
складена система, а також їх поведінки в рамках співпраці структурних
елементів;
• з'єднання обраних елементів структури і поведінки в усі більші системи;
• архітектурний стиль, який направляє всю організацію - все елементи, їх
інтерфейси, їх співпраця і їх з'єднання.
Це, мабуть, все. Крім цього, є багато думок про те, як саме вона повинна
створюватися і які є підходи з управління нею.
Важлива думка, яка є джерелом поняття архітектура, - «Архітектурні
рішення складно міняти» або, іншими словами, «Рішення, які складно
поміняти, - архітектурні». І це дійсно те, що має найбільше значення.
Те, наскільки складно поміняти рішення, визначає ступінь його
архітектурний. Також важливо, що будь-яке рішення легко поміняти на
наступний день після його прийняття або легко поміняти рішення, яке мало на
що впливає. Причому в даному випадку «рішення» - це як програмне рішення,
так і просто домовленість (яка рано чи пізно все одно закріплюється
програмним рішенням).
На рівні коду це можна висловити так: архітектурний код або софт - це
той, який використовується повторно найбільшу кількість разів. Причому це
правда як для коду, написаного вами особисто, так і для запозиченого.
Приклад: ступінь архітектурних бази даних - це кількість даних, які в ній
зберігаються. Тобто чим більше ви зберігаєте даних в цій конкретній базі, тим
більше архітектурною вона є для вас. З іншого боку, підключена до проекту
база даних, в якій поки або вже нічого не зберігається, архітектурою не є. При
цьому важливо зробити наголос саме на те, наскільки складно потім цю базу
змінити.
Дуже важливо відстежувати архітектурність тих чи інших рішень по міру
розвитку проекту, а не тільки при його зародженні. У outsource-компаніях часто
зустрічається підхід, коли в новий проект приходить важливий дехто і створює
архітектуру, а на наступний день іде з проекту. Його рішення дійсно важливі,
але архітектура їм не будується, а будується тими, хто ці рішення
використовує.
Будемо розуміти під архітектурою ПЗ внутрішню структуру продукту
(компоненти і їх зв'язки), основи призначеного для користувача інтерфейсу
продукту, а також квінтесенцію знань і рішень, які є інструментом розробки та
управління проектом.
В рамках багатьох проектів не створюється оригінальної архітектури,
оскільки вони є типовими або невеликими і ґрунтуються на готових
технологіях, архітектурних зразках, моделях команди і оргструктури проекту.
Однак часто виникає задача побудувати оригінальну нову архітектуру,
яка базується на колишніх розробках. Кількість прагне перейти в якість і тут
перш за все важливо помітити цей перехід, усвідомити, що старі методи роботи
не годяться і потрібно принципово новий досвід.

Складові елементи архітектури ПЗ

Архітектура програмної системи складається з трьох взаємодіючих
елементів:
1) структура - статична складова, яка показує розподіл відповідальності
між підсистемами;
2) поведінка - динамічна складова, взаємозв'язки і взаємодія між цими
структурами;
3) стиль - принципи і керівництво, які використовувалися і
використовуватимуться при визначенні структури.
 Архітектура інформаційних систем

Деякі визначення

Сервер - це віддалений потужний комп'ютер на якому встановлено

серверне програмне забезпечення, яке обслуговує клієнтів. Нас як веб-
розробників цікавить веб-сервер. Дуже часто на типовому сервері ми маємо
справу з веб-сервером Apache і мовою програмування PHP.

Клієнт - це наш комп'ютер, який стоїть у нас на столі і за допомогою

якого ми подорожуємо по просторах мережі. На клієнтській машині
встановлено клієнтське програмне забезпечення, необхідне для зв'язку з
сервером. У нашому випадку це веб-браузер.

Архітектура "файл-сервер»
Історично першими з'явилися інформаційні системи з використанням
файл-сервера.
В цьому випадку база даних розташовується на мережевому сервері, а
додаток клієнта - на персональному комп'ютері користувача. Кількість
користувачів не більше 10-15. Кожен користувач переписує на свій
персональний комп'ютер копію бази даних, яка періодично оновлюється з
сервера. Є додаткова складність по блокуванню записів, які використовуються
іншими користувачами. Тому в деякі моменти часу кожен користувач може
бачити недостовірні записи, які були змінені іншими користувачами, а
оновлення бази даних з сервера ще не було. Додаток клієнта в цій архітектурі
формує запити до бази даних, забезпечує достовірність і цілісність даних,
реалізує систему заходів щодо безпеки даних.
Переваги:
Застосування архітектури «файл-сервер» приваблює своєю простотою,
зручністю використання і доступністю. Вона становить інтерес для малих
робочих груп, а нерідко й досі використовується і в інформаційних системах
масштабу невеликого підприємства.
• можливість роботи з базою даних декількох користувачів.
 Недоліки:
• перевантаження мережі (великий мережевий трафік). Якщо клієнт
послідовно змінює кілька записів, то він звертається до своєї копії бази даних.
Тому перед фіксацією чергової зміни на персональний комп'ютер клієнта буде
копіюватися остання версія бази даних з сервера, і зміни будуть вноситися в цю
оновлену копію бази даних. В кінці сеансу зв'язку з сервером остання версія
бази даних клієнта буде зафіксована на сервері;
• забезпечити достовірність і цілісність даних - досить важке завдання,
так як в кожному додатку клієнта передбачені свої процедури їх забезпечення
(або не передбачені зовсім);
• дуже важко (або практично неможливо) забезпечити секретність даних,
так як кожен клієнт має доступ в каталог сервера і може змінювати будь-яку
таблицю на свій розсуд, а також копіювати їх і видаляти;
• необхідність систематичного оновлення даних на всіх персональних
комп'ютерах користувачів;
• блокування даних. Один користувач працює, а інші користувачі
чекають, поки сервер звільнить заблоковані записи.
Прикладом архітектури «файл-сервер» може служити Microsoft Access.
На даний момент файл-серверні СУБД вважаються застарілими.
Застосування архітектури «файл-сервер» приваблює своєю простотою,
зручністю використання і доступністю. Вона становить інтерес для малих
робочих груп, а нерідко й досі використовується і в інформаційних системах
масштабу невеликого підприємства.
Клієнт-серверна архітектура
Клієнт-серверна архітектура - шаблон проектування, основа для
створення веб-додатків. Дана архітектура складається з трьох компонентів:
1. Клієнт - це користувач сервісу (веб-додаток), який звертається до
сервера для отримання якоїсь інформації. На клієнтській машині встановлено
клієнтське програмне забезпечення, необхідне для зв'язку з сервером. У
нашому випадку це веб-браузер.
 2. Сервер - це віддалений потужний комп'ютер на якому встановлено
серверне програмне забезпечення, яке обслуговує клієнтів. Тобто, сервер -
місце, де розташовується веб-додаток або його серверна частина. Він має
необхідну інформацію про користувачів або може її запитувати. Також при
зверненні клієнта сервер повертає йому запитувану інформацію.
3. Мережа - забезпечує обмін інформацією між клієнтом і сервером.
Сервер може обробляти величезну кількість запитів від різних
користувачів. Тобто клієнтів може бути багато, а якщо їм потрібно обмінятися
інформацією між собою, робити це доведеться через сервер. Таким чином,
сервер отримує ще одну додаткову функцію - контроль трафіку. Якщо мова йде
про створений нами многопользовательском чаті, весь програмний код буде
складатися з двох модулів:
• клієнтського - містить графічний інтерфейс для авторизації, надсилають
/ отримання повідомлень;
• серверного - веб-додаток, яке розміщується на сервері і приймає
повідомлення від користувачів, обробляє їх, а потім відправляє адресатам.
Проста клієнт-серверна архітектура застосовується дуже рідко і тільки
для дуже простих додатків. Для дійсно великих і складних проектів
використовуються різні типи архітектур.
Весь інтернет побудований за клієнт-серверною архітектурою:

Багаторівнева архітектура
Цей архітектурний підхід поділяє комплекс ПО на рівні за принципом
взаємодії "клієнт-сервер". Архітектура може мати один, два і більше рівнів, які
поділяють відповідальності між постачальником даних і споживачем.
 Однорівнева система
В даному підході єдина система працює як на стороні сервера, так і
клієнта. Це забезпечує простоту розгортання і відмінну швидкість зв'язку, а
також усуває необхідність межсистемного взаємодії (Inter-system
communication - ISC).
Така система підходить тільки для невеликих розрахованих на одного
користувача додатків.
Дворівнева система

Так виглядає дворівнева архітектура

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

Трирівнева архітектура
Це архітектурний шаблон, в якому з'являється третій учасник - сховище
даних. При використанні цього шаблону, три рівня прийнято називати шарами:
1. Клієнтський шар - інтерфейс користувача. Це може бути веб-браузер,
яким відправляються HTML-сторінки, або графічне додаток, написане за
допомогою JavaFX. Головне, щоб з його допомогою користувач міг
відправляти запити на сервер і обробляти його відповіді.
2. Шар логіки - сервер, на якому відбувається обробка запитів /
відповідей. Часто його ще називають серверним шаром. Також тут
відбуваються всі логічні операції: математичні розрахунки, операції з даними,
звернення до інших сервісів або сховищ даних.
3. Шар даних - сервер баз даних: до нього звертається наш сервер. У
цьому шарі зберігається вся необхідна інформація, якою користується додаток
при роботі.
Таким чином, наш сервер приймає на себе всі зобов'язання щодо
поводження до даних, не даючи можливості користувачеві звернутися до них
безпосередньо.

Так виглядає трирівнева архітектура

Переваги
• Більш проста реалізація в порівнянні з іншими підходами.
• Пропонує абстракцію завдяки поділу відповідальностей між рівнями.
• Ізолювання захищає одні шари від змін інших.
• Підвищує керованість програмного забезпечення за рахунок слабкої
зв'язаності.
Недоліки
• Не пропонує великий масштабованості.
 • ПЗ, створене з таким підходом, буде мати монолітну структуру, що
ускладнює внесення модифікацій.
• Дані повинні проходити по кожному шару, навіть якщо немає
необхідності передавати їх з певних верств.
Переваги трирівневої архітектури
Використовуючи таку архітектуру, ми отримуємо чимало плюсів, серед
яких:
1. Можливість побудувати захист від SQL-ін'єкцій - це атака на сервер,
при якій передається SQL-код, і при виконанні цього коду зловмисник може
впливати на нашу базу даних.
2. Розмежування даних, до яких ми хочемо регулювати призначений для
користувача доступ.
3. Можливість модифікувати дані перед відправкою клієнту.
4. Масштабованість - можливість розширити наш додаток на кілька
серверів, які будуть використовувати одну і ту ж базу даних.
5. Менші вимоги до якості з'єднання користувача. Формуючи відповідь
на сервері, ми часто беремо з бази даних багато різної інформації, форматіруем
її, залишаючи лише те, що потрібно користувачеві. Таким чином ми
скорочуємо обсяг інформації, який відправимо в якості відповіді клієнту.
Архітектура не має на увазі якесь обов'язкове кількість рівнів - їх може
бути три, чотири, п'ять і більше. Найчастіше використовують триланкову
системи: з рівнем уявлення (клієнтом), рівнем логіки і рівнем даних.
Багаторівнева архітектура - природний вибір для багатьох корпоративних
додатків. Так як в компаніях (особливо великих) часто відбувається поділ
компетенцій: є команда, відповідальна за фронтенд, є люди, які відповідають за
бекенд, і так далі. Звідси випливає природне поділ додатків на рівні: одні
розробники трудяться над клієнтом, інші - над логікою.
 Контрольні запитання
1. Які незручності, виникають при роботі з системою, побудованої на основі
архітектури «Файл-сервер»?
2. Що передбачає архітектура "файл-сервер"?
3. Які переваги має архітектура "файл-сервер"?
4. Перерахуйте недоліки файл-серверного підходу при забезпеченні
багатокористувацького доступу до бази даних?

Форма звіту
1. Тема та мета.
2. Коротко теоретичні відомості.
3. Запис завдання згідно варіанту.
4. Виконане завдання згідно варіанту на основі наведеного прикладу та
теоретичних відомостей.

Варіанти виконання лабораторних робіт:

1. Інформаційна система продажу квитків в кінотеатрі.
2. Інформаційна система «Магазин меблів».
3. Інформаційна система «Готель».
4. Інформаційна система взаємодії з клієнтами туристичної компанії.
5. Інформаційна система «Магазин».
6. Інформаційна система «Салон краси».
7. Інформаційна система «Бібліотека».
8. Інформаційна система «Автосалон».
9. Інформаційна система «Агенція нерухомості».
10. Інформаційна система «Автовокзал».