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

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

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

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

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

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

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

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

Висновки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поиск по сайту: