PrIS

61

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

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

Об'єктно-орієнтована модель

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

1.Абстракція. Кожний об’єкт є членом якогось класу. Клас визначається як сукупність властивостей, методів, загальнодоступних і приватних структур даних, а також програми, які виконуються над об'єктами (екземплярами) цього класу. Класи є не що інше, як абстрактні типи даних. Методи – це процедури, які викликаються для того, щоб виконати якісь дії з об'єктом (наприклад, надрукувати себе або скопіювати себе). Властивості – це значення даних, пов'язані з кожним об'єктом класу, які певним чином характеризують його (наприклад, колір, вік).

2.Інкапсуляція. Внутрішнє подання даних і деталей реалізації загальнодоступних і приватних методів (програм) є частиною визначення класу і відоме тільки всередині цього класу. Доступ до об'єктів класу дозволений тільки через властивості і методи цього класу або його батьків, а не шляхом використання знання подробиць внутрішньої реалізації.

3.Наслідування (поодиноке або множинне). Класи визначені як частина ієрархії класів. Визначення кожного класу нижчого рівня успадковує властивості і методи його батька, якщо вони тільки явно не оголошені неуспадковуваними або змінені новим визначенням. При поодинокому успадковуванні клас може мати тільки один батьківський клас (тобто класова ієрархія має деревовидну структуру). При множинному успадковуванні клас може походити від численних батьків (тобто ієрархія класів має структуру орієнтованого нециклічного графу, не обов'язково деревовидну).

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

62

5. Повідомлення. Взаємодія з об'єктами здійснюється шляхом пересилання повідомлень з можливістю отримання відповідей.

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

Висновки

1.Інформаційні системи відносяться до класу організаційних систем керування.

2.Завдання розроблювачів програмних систем – створити в користувача розроблюваної системи ілюзію простоти.

3.Складні структури часто приймають форму ієрархій; корисні обидві ієрархії: і класів, і об'єктів.

4.Складні системи зазвичай створюються на основі стійких проміжних форм.

5.Пізнавальні здібності людини обмежені; ми можемо розсунути їхні рамки, використовуючи декомпозицію, виділення абстракцій і створення ієрархій.

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

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

8.Модель даних – це спосіб структуризації даних, які розглядаються як деяка абстракція у відриві від предметної області. Також це інструмент подання концептуальної моделі предметної області і динаміки її зміни у вигляді бази даних.

9.Є такі моделі даних: концептуальна, логічна, фізична.

10.У концептуальному моделюванні проектується схема понять прикладної області в їх взаємозв'язку.

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

63

CASE-систем. Логічна модель будується за допомогою діаграм «сутність-зв’язок», атрибутів, категоризації. Розрізняють ієрархічну, мережну, реляційну, багатовимірну логічні моделі даних.

12. Фізична модель даних відповідає опису даних в БД конкретної СКБД, тобто схемі даних. Вона враховує такі аспекти, як архітектуру, безпеку, ефективність доступу та інші.

Контрольні запитання

1.Визначення інформаційної системи.

2.Поняття складності системи.

3.Види інформаційних систем.

4.Відмінності у поняттях «методологія» і «метод».

5.Вимоги, які має задовольняти система у контексті проектування.

6.Види ієрархій.

7.Навести приклад декомпозиції.

8.Відмінності між логічною та фізичною моделями.

РОЗДІЛ 3. Розвиток методологій проектування інформаційних систем

Методологія процедурно-орієнтованого програмування

Методологія об'єктно-орієнтованого програмування

Методологія об'єктно-орієнтованого аналізу і проектування

Методологія системного аналізу і системного моделювання

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

64

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

3.1. Методологія процедурно-орієнтованого програмування

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

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

Примітка

Прийнято вважати, що сам термін алгоритм походить від імені середньовічного математика Аль-Хорезмі, який 825 року описав правила виконання арифметичних дій у десятковій системі числення.

Із цього погляду вся історія математики тісно пов'язана з розробленням тих або інших алгоритмів вирішення актуальних для своєї епохи завдань. Понад це, саме поняття алгоритму стало предметом відповідної теорії – теорії алгоритмів, яка займається вивченням загальних властивостей алгоритмів. Із часом зміст цієї теорії став настільки абстрактним, що відповідні результати розуміли тільки фахівці. Як данина цій традиції якийсь період часу мови програмування називалися алгоритмічними, а перший графічний засіб документування програм отримав назву блок-схеми алгоритму. Відповідна система графічних позначень зафіксована в ГОСТ 19.701-90, який реґламентував

65

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

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

Із часом розроблення великих програм перетворилося на серйозну проблему, яку почали розбивати на дрібніші фраґґменти. Основою для такого розбиття якраз і стала процедурна декомпозиція, при якій окремі частини програми або модулі були сукупністю процедур для вирішення деякої сукупності завдань. Головна особливість процедурного програмування полягає в тому, що програма завжди має початок в часі або початкову процедуру (початковий блок) і закінчення (кінцевий блок). При цьому вся програма може зображатися у вигляді напрямленої послідовності графічних примітивів або блоків (рис. 3.1).

Важливою властивістю таких програм є необхідність завершення всіх дій попередньої процедури для початку дій подальшої процедури. Зміна порядку виконання цих дій навітьу межах однієї процедури зажадала включення в мови програмування спеціальних умовних операторів типу if-then-else і Goto для реалізації розгалуження обчислювального процесу залежно від проміжних результатів розв’язування задачі.

66

Рис. 3.1. Графічне представлення програми у вигляді послідовності процедур.

Поява і інтенсивне використання умовних операторів і оператора безумовного переходу стала предметом гострих дискусій серед фахівців з програмування. Річ у тому, що безконтрольне застосування у програмі оператора безумовного переходу goto здатне серйозно ускладнити розуміння коду. Відповідні програми почали порівнювати із спагеті, називаючи їх bowl of spaghetti, маючи на увазі численні переходи від одного фраґмента програми до іншого, або, що ще гірше, повернення від кінцевих операторів програми до її початкових операторів. Ситуація здавалася настільки драматичною, що в літературі зазвучали заклики виключити оператор goto з мов програмування. Саме з того часу прийнято вважати хорошим стилем програмування – програмування без goto.

Примітка

Розглянуті ідеї сприяли становленню деякої системи поглядів на процес розроблення програм і написання програмних кодів, яка отримала назву методології структурного програмування. Основою такої методології є процедурна декомпозиція програмної системи і організація окремих модулів у вигляді сукупності виконуваних процедур. У рамках цієї методології розвинулося покрокове проектування програм або програмування "зверху-вниз". Період найбільшої популярності ідей структурного програмування припадає на кінець 70-х - початок 80-х років ХХ ст.

67

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

У цей період основним показником складності розроблення програм вважали її розмір. Цілком серйозно обговорювалися такі оцінки складності програм, як кількість рядків програмного коду. Правда, при цьому робилися деякі припущення щодо синтаксису самих рядків, які мали відповідати певним правилам. Загальна трудомісткість розроблення програм оцінювалася спеціальною одиницею вимірювання – "людиномісяць" або "людино-рік". А професіоналізм програміста безпосередньо зв'язувався з кількістю рядків програмного коду, яку він міг написати і відлагодити протягом, скажімо, місяця.

Примітка

Зараз спроби оцінити професіоналізм програміста кількістю рядків програмного коду можуть викликати лише усмішку співбесідника. Дійсно, використовуючи вбудовані засоби сучасних інструментаріїв розроблення (MS Visual C++ або Inprise/Borland Delphi), навіть новачок може за лічені секунди послідовним натисненням кнопок діалогових меню створити працездатну програму, що містить сотні рядків програмного коду і складається з десятка окремих файлів проекту.

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

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

68

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

Стало очевидним, що традиційні методи процедурного програмування не здатні справитися ні зі складністю програм і їх розроблення, що постійно зростає, ні з необхідністю підвищення їх надійності. У другій половині 80-х років ХХ ст. виникла потреба в новій методології програмування, яка була б здатна вирішити весь цей комплекс проблем. Такою методологією стало об'єктно-орієнтоване програмування (ООП).

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

Примітка

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

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

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

69

Прикладами найзагальніших понять можуть служити такі абстрактні категорії, як система, структура, інтелект, інформація, сутність, зв'язок, стан, подія і багато інших. У процесі вивчення цих категорій з'являються нові особливості їх змісту і об'єму. Саме з цих причин завжди важко дати їм точне визначення. Як приклади конкретних понять можна навести поняття книги, яку читач тримає в руках, або поняття мікропроцесора Intel Pentium.

Примітка

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

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

Для ілюстрації принципу успадкування можна навести такий приклад. Розглянемо загальний клас "Автомобіль". Цей клас визначається як деяка абстракція властивостей і поведінки всіх наявних автомобілів. При цьому властивостями класу "Автомобіль" можуть бути такі загальні властивості, як наявність двигуна, трансмісії, коліс, керма. Якщо як похідний клас розглянути клас "Легковий автомобіль", то всі виділені вище властивості будуть властиві і цьому класу. Можна сказати, що клас "Легковий автомобіль" успадковує властивості батьківського класу "Автомобіль". Проте, окрім перерахованих властивостей, клас-нащадок матиме додаткові властивості, наприклад такі, як наявність салону з кількістю посадкових місць 2-5.

Своєю чергою, клас "Легковий автомобіль" здатний породжувати інші підкласи, які цілком можуть відповідати, наприклад, моделям конкретних фірм-виробників. Отже, можна розглядати клас "Легковий автомобіль виробництва ВАЗ". Оскільки Волжський автомобільний завод випускає декілька моделей автомобілів, одним з похідних класів для попереднього класу може бути конкретна модель автомобіля, наприклад, ВАЗ-21083. Нарешті, виготовлений автомобіль має унікальний

70

заводський номер, що відрізняє один автомобіль від іншого. Таким номером може бути, наприклад, XTA-210830S1594301. В останньому випадку клас складатиметься з єдиного об'єкту або екземпляра, яким буде легковий автомобіль виробництва ВАЗ із вказаним вище заводським номером.

Описана вище інформація про співвідношення класів у нашому прикладі має один серйозний недолік, а саме: відсутність наочності. У зв'язку з цим виникає запитання: а чи можливо подати ієрархію успадкування класів у візуальній формі? Традиційно для зображення понять у формальній логіці використовувалися кола або прямокутники. Тоді для розглянутого прикладу ієрархія породження класів може зображатися у вигляді вкладених прямокутників, кожен з яких відповідає окремому класу (рис. 3.2).

Клас „Автомобіль”

Клас „Легковий автомобіль”

Клас „Легковий автомобіль виробництва ВАЗ”

Клас „Модель ВАЗ-21083”

Клас „Легковий автомобіль з номером ХТА-210830 S1594301”

Рис. 3.2. Ієрархія вкладеності класів для прикладу "Автомобіль".

Поява об'єктно-орієнтованих мов програмування пов'язана з необхідністю реалізації концепції класів і об'єктів на синтаксичному рівні. Із погляду ООП клас є подальшим розширенням структури (structure) або запису (record). Включення у відомі мови програмування С і Pascal класів і деяких інших можливостей привело до появи відповідно C++ і Object Pascal, які на сьогодні є найбільш поширеними мовами розроблення програм. Розповсюдженню C++ і Object Pascal сприяла та обставина, що мова C++ була вибрана як базова для програмного інструментарію MS Visual C++, а мова Object Pascal– для популярного засобу швидкого розроблення програм Borland/Inprise Delphi.