Основи створення інформаційних систем (стр. 39 )

- залежно від виду прикладних задач можна змінювати фізичну організацію інформації у базі даних.

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

Якщо є хоча б найменша ймовірність того, що база даних користу­вача або довжина файла буде швидко збільшуватися, краще із самого початку скористатися потужнішими апаратними засобами або модел­лю типу «клієнт — сервер».

Основна відмінність між СУБД, орієнтованою на локальну мере­жу, і СУБД типу «клієнт — сервер» полягає в тому, в який спосіб розподіляються процеси бази даних.

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

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

Прикладом СУБД типу «клієнт — сервер» Огасl, Sуbаsе, ХQL фірми Novell.

У великій мережі СУБД типу «клієнт — сервер» має забезпечувати виконання великої кількості транзакцій у секунду порівняно із систе­мою, орієнтованою на локальну мережу.

Недоліки архітектури «клієнт — сервер»:

- на її реалізацію витрачається більше засобів і коштів, оскільки потенціальне тут вимагається кілька серверів, потужніші центральні процесори й оперативна пам'ять;

- невеликий досвід застосування цих засобів і недостатня розробка програмного інструментарію;

- вимагається дуже висока кваліфікація персоналу.

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

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

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

Традиційна помилка - використання великої кількості блокувань протягом надто тривалого часу.

Необхідно передбачити відсутність блокувань як файлів, так і за­писів у той час, поки користувач збирає інформацію для наступного оновлення бази даних. Прикладна програма має відкривати необхідні таблиці, одержувати інформацію, що вимагається, і закривати таб­лиці, а також вводити блокування, додавати або змінювати інфор­мацію, і знімати блокування тільки після того, як інформація буде підготовлена для подання у базу даних.

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

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

При пошуку необхідного поєднання компонентів локальної мережі і СУБД - розробки необхідно враховувати такі особливості:

- розуміти відмінності в СУБД, що орієнтовані на локальну мережу, і СУБД типу «клієнт — сервер», а також усвідомлювати обмежені можливості СУБД, орієнтованої на локальну мережу, зокрема при об­слуговуванні великої кількості кінцевих користувачів;

- використовувати нормалізацію БД при розробці її логічної оптимізованої моделі, базуючись на потребах користувача;

- узгоджувати рівень паралелізму інформації з потребами кінцевого користувача;

- обмежувати рівень блокування файлів і записів;

- підтримувати файли у закритому стані якомога далі;

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

- добирати ємкість буферів кешування файлів з урахуванням серед­ньої довжини запису СУБД (система працюватиме ефективно, якщо довжина запису у більшості операцій менша ємкості окремого буфера кешування);

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

- проектувати СУБД, розраховані на дублювання диска або роботу з інтерфейсом SCSI для того, щоб дістати переваги із сполученням за часом окремих операцій пошуку інформації.

14.7. Об'єктно-орієнтоване проектування ІС

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

Відповіддю на проблему зростаючої складності в ІС стало виникнення об'єктно-орієнтованого підходу. У мережах об'єктного підходу виділяють:

об'єктно-орієнтоване програмування (ООР),

об'єктно-орієнтоване проектування (00П),

об'єктно-орієнтований аналіз (ООА).

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

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

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

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

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

Таким чином, ідеальна гіпотетична мова програмування повинна представляти алгоритм розв'язання задачі на основі понятійного апа­рату заданої проблемної сфери. Вихід бачиться у використанні універсальної метамови для всіх предметних областей - мови теорії систем і системного аналізу. Основні поняття цієї мови: об'єкт, клас об'єктів, атрибут (властивість), процес, функція, метод, структура то­що. На цьому й базується ключова ідея ООР - створення мовних за­собів, які на основі абстрактних типів даних дозволяють специфі­кувати нові класи програмних об'єктів, адекватних об'єктам конкрет­ної проблемної сфери.

Об'єктні програми складаються з готових компонентів-об'єктів. ЦІ об'єкти можуть відповідати:

- об'єктам або процесам реального світу (деталь, документ, клієнт);

- абстрактним поняттям (екран, таблиця, графічний елемент то­що).

У традиційних програмах дані відділені від процедур і методів, в об'єктних — дані та процедури об'єднуються в об'єкті.

Приклад 1. Об'єкт — «клієнт». Усе, що відомо користувачеві про клієнта, включається у цей об'єкт. Дії з клієнтом реалізуються як ме­тоди (функції) для даного об'єкта, що також входять в опис об'єкта.

Таким чином, основа ООП — формування з простих об'єктів, які складаються з даних і набору функцій, більш складних, здатних мо­делювати об'єкти проблемної сфери.

Проведений огляд дозволяє зробити цікавий висновок: об'єктно-орієнтована технологія стирає межу між «чистим» проектувальником (системним аналітиком) і «чистим» програмістом. З'являється новий тип розробника — проектувальник-програміст, здатний самостійно поставити, спроектувати задачу і реалізувати її у вигляді об'сктно-орієнтованої програми.

Приклад 2. Розглянемо описання об'єктів мовою Турбо Паскаль (YG>0). Об'єкт-структура даних, що містить поля даних різних типів (у тому числі й абстрактні) і заголовки методів.

Ім'я Об'єкта=оbyect (Ім'я Класу)

поле; ...; поле;

метод;...; метод;

еnd;

Метод — це процедура або функція, оголошена всередині оголо­шення елемента типу об'єкт

ргосеduге Ім'я Об'єкта. Метод

(параметр, ..., параметр n) '

bеgіn

еnd;

Оголошення методу всередині оголошення об'єкта:

ргосеduге Метод ( параметр, .„, параметр n).

Історично склалося так, що першочергово були розроблені мови ООР у відсутність теорії об'єктно-орієнтованого проектування. І тіль­ки після усвідомлення спеціалістами в області інформатики, що ООП є основою для чергового перевороту в інформаційних технологіях, по­чалась активна розробка теорії об'єктно-орієнтованого аналізу та про­ектування.

Вперше поняття класів і об'єктів введені у мові Simula 67. У сис­темі Smalltalk-80 ідеї Sіmulа доведені до логічного завершення - усі дії виконуються на основі класів. У 70-х роках створені мови, що ре­алізують дії абстрактних даних: Alpharad, СLV, Еuclid, Моdulа. Зане­сення об'єктно-орієнтованого підходу у С привело до створення мов С ++ і Objectiioe С. На основі мови Раscal виникли Object Pascal, Еiffel i Аdа. З'явились такі діалекти LIPS, як LООРS і СLOS, з можливостями мов Simula і Smalltalk.