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

· Визначення об'єктів та класів;

· Підготовка словника даних;

· Визначення залежностей між об'єктами;

· Визначення атрибутів об'єктів та зв'язків;

· Організація та спрощення класів при використанні успадкування;

· Подальше дослідження та удосконалення моделі.

2.2.1. Визначення класів.Аналіз зовнішніх вимог до проектованої ПС дозволяє визначити об'єкти та класи об'єктів, пов'язані з прикладною проблемою, яку має вирішувати ця система. Всі класи повинні бути осмислені в аналізованій прикладної області; класів, пов'язаних з комп'ютерною реалізацією, наприклад список, стек і т.п. цьому етапі вводити годі було.

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

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

· надлишкові класи:якщо два або декілька класів виражають однакову інформацію, слід зберегти лише один із них;

· нерелевантні(що не мають прямого відношення до проблеми) класи: для кожного імені можливого класу оцінюється, наскільки він необхідний у майбутній системі (оцінити це часто буває дуже непросто); нерелевантні класи виключаються;

· нечітко визначені(з погляду проблеми) класи(Див. п. 2.3.1);

· атрибути: деяким іменникам більше відповідають класи, а атрибути; такі іменники, як правило, описують властивості об'єктів (наприклад, ім'я, вік, вага, адреса тощо);

· операції: деяким іменникам більше відповідають не класи, а імена операцій (наприклад, телефонний виклик навряд чи означає будь-який клас);

· ролі: деякі іменники визначають імена ролей в об'єктній моделі (наприклад, власник, водій, начальник, службовець; всі ці імена пов'язані з ролями у різних залежностях об'єктів класу осіб);

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

Після виключення імен усіх непотрібних (зайвих) можливих класів буде отримано попередній список класів, що становлять проектовану систему.

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

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

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

Потім слід усунути непотрібні або неправильні залежності, використовуючи наступні критерії:

· залежності між виключеними класамиповинні бути виключені, або переформульовані в термінах класів, що залишилися (див. п. 2.3.3);

· нерелевантні залежностіта залежності, пов'язані з реалізацією, мають бути виключені (див. п. 2.3.3);

· дії:залежність повинна описувати структурні властивості прикладної області, а чи не малоістотні події (див. п. 2.3.3);

· тренарні залежності:більшу частину залежностей між трьома або більшим числомкласів можна розкласти на кілька бінарних залежностей, використовуючи у разі потреби кваліфікатори (див. п. 2.3.3); у деяких (рідкісних) випадках таке розкладання здійснити не вдається; наприклад, тренарна залежність "Професор читає курс в аудиторії 628" не може бути розкладена на бінарні без втрати інформації;

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

Мал. 2.36. Незайві залежності

Видаливши надлишкові залежності, потрібно уточнити семантику залежностей, що залишилися, таким чином:

· невірно названі залежності:їх слід перейменувати, щоб зміст їх став зрозумілим (див. п. 2.3.3);

· імена ролей:потрібно додати імена ролей там, де це потрібно; ім'я ролі визначає роль, яку відіграє відповідний клас у цій залежності з погляду іншого класу, що у цій залежності; якщо ім'я ролі зрозуміло з імені класу, його можна не вказувати (див. п. 2.3.3);

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

· кратність:необхідно додати позначення кратності залежностей; при цьому слід пам'ятати, що кратність залежностей може змінюватись у процесі подальшого аналізу вимог до системи;

· невраховані залежностіповинні бути виявлені та додані в модель.

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

Атрибути зазвичай відповідають іменникам; наприклад, колір_автомобіля (властивість об'єкта), позиція_курсора (стан об'єкта). Атрибути зазвичай слабко впливають на структуру об'єктної моделі.

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

Поруч із атрибутами об'єктів необхідно запровадити і атрибути залежностей між класами (зв'язків між об'єктами).

При уточненні атрибутів керуються такими критеріями:

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

· Кваліфікатори. Якщо значення атрибуту залежить від конкретного контексту, його слід зробити кваліфікатором (див. 2.3.4).

· Імена. Іменам зазвичай краще відповідають кваліфікатори, аніж атрибути об'єктів; у всіх випадках, коли ім'я дозволяє зробити вибір з об'єктів деякої множини, його слід зробити кваліфікатором (див. п. 2.3.4).

· Ідентифікатори. Ідентифікатори об'єктів пов'язані з їхньою реалізацією. На ранніх стадіях проектування їх не слід розглядати як атрибути.

· Атрибути зв'язків. Якщо деяка властивість характеризує не об'єкт сам собою, яке зв'язок з іншим об'єктом (об'єктами), це атрибут зв'язку, а чи не атрибут об'єкта.

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

· Несуттєві деталі. Атрибути, які впливають виконання більшої частини операцій, рекомендується опустити.

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

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

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

Ознаки пропущеного об'єкта (класу):

· несиметричності зв'язків та узагальнень (спадкування); для виправлення помилки потрібно додати пропущені класи;

· Невідповідність атрибутів та операцій у класу; для виправлення помилки необхідно розщепити клас на кілька інших класів, так щоб атрибути та операції нових класів відповідали один одному;

· Виявлено операцію, яка не має задовільного цільового класу; для виправлення помилки потрібно додати пропущений цільовий клас;

· Виявлено кілька залежностей з однаковими іменами та призначенням; Для виправлення помилки необхідно зробити узагальнення та додати пропущений суперклас.

Ознаки непотрібного (зайвого) класу:

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

Ознаки пропущених залежностей:

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

Ознаки непотрібних (зайвих) залежностей:

· Надмірна інформація в залежностях; для виправлення помилки необхідно виключити залежності, що не додають нової інформації, або позначити їх як похідні залежності;

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

Ознаки неправильного розміщеннязалежностей:

· Імена ролей занадто широкі або занадто вузькі для їх класів; Для виправлення помилки необхідно перемістити залежність вгору або вниз ієрархією класів.

Ознаки неправильного розміщення атрибутів:

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

Приклади практичного застосуванняописаних ознак див. у п. 2.3.6.

Приклад об'єктної моделі

Розглянемо процес побудови об'єктної моделі для системи банківського обслуговування у процесі аналізу вимог та попереднього проектування цієї системи. Для побудови об'єктної моделі аналізованої системи необхідно виконати всі етапи, перелічені у п 2.2.

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

Досліджуємо цей список, виключаючи з нього імена класів відповідно до рекомендацій п. 2.2.1:

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

· нерелевантні класи: таким класом є клас ціна (він не має безпосереднього відношення до роботи банківської мережі);

· нечітко визначені класи: такими класами є служба_ведення_записів та перевірка безпеки (ці служби входять до складу проводки), система (у нашому випадку незрозуміло, що це таке), банківська_мережа (вся ПС обслуговуватиме банківську мережу);

· атрибути: дані проведення, дані рахунки, гроші (маються на увазі реальні гроші, що видаються клієнту касиром або банкоматом, або приймаються касиром), квитанція (видається клієнту разом з грошима) більш природно мати як атрибути;

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

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

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

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

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

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

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

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

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

Комп'ютер_банку - комп'ютер, що належить банку, який взаємодіє з мережею ATM (банкоматів) та власними касовими_терміналами банку. Банк може мати свою внутрішню комп'ютерну мережу для обробки рахунків, але ми розглядаємо тільки той комп'ютер_банку, який взаємодіє з мережею ATM.

Консорціум – об'єднання банків, що забезпечує роботу мережі ATM (банкоматів). Мережа передає до консорціуму проведення банків.

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

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

Центральний_комп'ютер - комп'ютер, що належить консорціуму, який розподіляє проводки та їх результати між ATM (банкоматами) та комп'ютерами_банків. Центральний комп'ютер перевіряє коди банків, але не виконує проводок.

2.3.3. Визначення залежностей.Дотримуючись рекомендацій п. 2.2.3, виділяємо явні та неявні дієслівні оборотиз попередньої постановки завдання та розглядаємо їх як імена можливих залежностей. З постановки завдання про банківську мережу (див. п. 1.3) можна отримати такі обороти:

Дієслівні обороти (явні та неявні):

Банківська мережа включаєкасирів та ATM"и

Консорціум розподіляєрезультати проводок ATM

Банк володієкомп'ютером банку

Комп'ютер банку підтримуєрахунки

Банк володієкасовими терміналами

Касовий термінал взаємодієз комп'ютером банку

Касир вводитьпроведення над рахунком

ATM"и взаємодіютьз центральним комп'ютером під час проведення

Центральний комп'ютер взаємодієз комп'ютером банку

ATM приймаєкартку

ATM спілкуєтьсяз користувачем

ATM видаєготівкові гроші

ATM друкуєквитанції

Система регулюєколективний доступ

Банк надаєпрограмне забезпечення

Консорціум складається збанків

Консорціум володієцентральним комп'ютером

Система забезпечуєпротоколювання

Система забезпечуєбезпека

Клієнти маютькартки

Картка забезпечує доступдо рахунку

У банку служатькасири

Потім виключаємо непотрібні чи неправильні залежності, використовуючи критерії, сформульовані у п. 2.2.3:

· залежності між виключеними класами:виключаються такі залежності: Банківська мережа включаєкасирів та ATM"и (клас банківська_мережа виключений), ATM друкуєквитанції (клас квитанція виключено), ATM видаєготівка (клас гроші виключено), Система забезпечуєпротоколювання проводок (клас служба_ведення_записів виключено), Система забезпечуєбезпека ведення рахунків (клас служба_безпеки виключено), Банки надаютьпрограмне забезпечення (клас програмне_забезпечення виключено);

· нерелевантні залежності та залежності, пов'язані з реалізацією:залежність "Система регулюєколективний доступ" виключається як пов'язана з реалізацією;

· діїописуються такими залежностями як "ATM приймаєкартку" та "ATM спілкуєтьсяз користувачем"; ми виключаємо ці залежності;

· тренарні залежності:залежність "Касир вводитьпроводку над рахунком" розкладається на дві бінарні залежності "Касир вводитьпроводку" та "Проведення відноситься дорахунку". Залежність "ATM" взаємодіютьз центральним комп'ютером під час проведення" розкладається на "ATM" взаємодіютьз центральним комп'ютером" та "Проведення починається з ATM";

· похідні залежності:залежність "Консорціум розподіляє ATM"и" є наслідком залежностей "Консорціум володієцентральним комп'ютером" та "ATM" взаємодіютьіз центральним комп'ютером".

Видаливши надлишкові залежності, отримаємо наступний список залежностей:

Банк володієкомп'ютером банку

Комп'ютер банку підтримуєрахунки

Банк володієкасовими терміналами

Касовий термінал взаємодієз комп'ютером банку

Касир вводитьпроводку

Проведення відноситься дорахунку

ATM"и взаємодіютьз центральним комп'ютером

Проведення починаєтьсяз ATM

Центральний комп'ютер взаємодієз комп'ютером банку

Консорціум складається збанків

Консорціум володієцентральним комп'ютером

Клієнти маютькартки

Картка забезпечує доступдо рахунку

У банку служатькасири

Уточнимо семантику решти залежностей наступним чином:

· перейменуємоневірно названі залежності, щоб зміст їх став більш зрозумілим; так залежність Комп'ютер_банку підтримуєрахунки зручніше замінити залежністю Банк тримаєрахунки.

· імена ролейможна не використовувати, так як вони зрозумілі з імен класів, що беруть участь в залежності, як наприклад, для залежності ATM взаємодіютьіз центральним комп'ютером;

· невраховані залежності:Проведення починаєтьсяз касового_терміналу, Клієнти маютьрахунки, Проведення реєструєтьсякарткою слід додати модель.

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

Мал. 2.37. Перша версія об'єктної діаграми для банківської мережі

2.3.4. Уточнення атрибутів.Застосовуючи критерії, сформульовані у п. 2.2.4, отримаємо:

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

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

2.3.5. Організація системи класів із використанням успадкування.У прикладі природно визначити суперкласи для об'єктів, що визначають різні термінали: касовий_термінал і ATM (банкомат), і для об'єктів, що визначають проводки: проводка_касира і віддалена_проводка (з банкомату).

Внісши відповідні зміни, отримаємо об'єктну діаграму, представлену на рис. 2.39.

Мал. 2.38. Об'єктна діаграма для банківської мережі після уточнення атрибутів та додавання кваліфікаторів

Мал. 2.39. Об'єктна діаграма для банківської з урахуванням успадкування

2.3.6. Подальше вдосконалення моделі.Картка виступає у двох сутностях: як реєстраційна одиниця в банку (ощадкнижка), що забезпечує клієнту доступ до його рахунків, і як структура даних, з якою працює ATM. Тому зручно розщепити клас картка на два класи: реєстрація_картки та картка; перший із цих класів забезпечує клієнту доступом до його рахунках банку, а другий визначає структуру даних, з якою працює ATM.

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

Клас банк природно поєднати з класом комп'ютер_банку, а клас консорціум - з класом центральний_комп'ютер.

Мал. 2.40. Остаточний вид об'єктної діаграми для банківської мережі

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

Виділення підсистем

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

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

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

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

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

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

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

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

Мал. 2.41. Об'єктна діаграма банківської мережі, в якій вказано інтерфейс із системним оточенням

Мал. 2.42. Об'єктна діаграма банківської мережі та її системного оточення

Введення поняття підсистеми та можливість включати в об'єктну модель поряд з об'єктами (класами) та підсистеми визначає ієрархічну структуру об'єктної моделі та дозволяє використовувати методологію OMT при проектуванні досить складних ПС, що містять велике числорізних об'єктів та класів.

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

Інтерфейс об'єктавизначається інтерфейсом відповідного класу та задається списком сигнатур його відкритих операцій (методів). Інтерфейс підсистемивизначається через ітерфейс складових її об'єктів і підсистем наступним чином: операція може бути включена в інтерфейс підсистеми, якщо в складі цієї підсистеми є об'єкт (підсистема), інтерфейс якого містить цю операцію. Інтерфейси описуються мовою опису інтерфейсів IDL (Interface Definition Language).

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

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

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

Мал. 2.43. Об'єктна діаграма банківської мережі після виділення підсистеми банк

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

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

• - абстрагування;
• - інкапсуляція;
• - модульність;
• - Ієрархічність.

Ці принципи є головними у тому сенсі, що без них модель не буде об'єктно-орієнтованою. Крім головних, назвемо ще три додаткові принципи:

• - Типізація;
• - Паралелізм;
• - Зберігається.

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

Абстрагування

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

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

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

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

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

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

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

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

Будемо називати клієнтом будь-який об'єкт, який використовує ресурси іншого об'єкта, який називається сервером. Ми характеризуватимемо поведінку об'єкта послугами, які він надає іншим об'єктам, та операціями, які він виконує над іншими об'єктами. Цей підхід концентрує увагу зовнішніх проявах об'єкта і реалізує так звану контрактну модель програмування. Ця модель полягає в наступному: зовнішній прояв об'єкта розглядається з точки зору його контракту з іншими об'єктами, відповідно до цього має бути виконано та його внутрішній пристрій(Часто - у взаємодії з іншими об'єктами). Контракт фіксує всі зобов'язання, які об'єкт-сервер має перед об'єктом-клієнтом. Іншими словами, цей контракт визначає відповідальність об'єкта - то поведінка, за яку він відповідає.

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

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

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

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

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

Розглянемо елементи реалізації нашої абстракції мовою С++.

typedef float Temperature; // Температура за Цельсієм

typedef unsigned int Location; // Число, що однозначно визначає

// положення датчика

Тут два оператори визначення типів Temperature та Location вводять зручні псевдоніми для найпростіших типів, і це дозволяє нам висловлювати свої абстракції мовою предметної області. Temperature - це числовий типданих у форматі з плаваючою точкою для запису температур. Значення Location позначають місця, де можуть розташовуватися температурні датчики.

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

struct TemperatureSensor (

Temperature curTemperature; // поточна температура в

// місцезнаходження датчика

Location loc; // Місцезнаходження датчика

void calibrate (Temperature actualTemperature); // калібрувати

Temperature currentTemperature (); // поточна температура

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

Об'єкти даного типувводяться так само, як і змінні стандартних типів:

TemperatureSensor TSensors; // масив із ста об'єктів типу

// TemperatureSensor

Функції, оголошені всередині опису, називаються функціями-членами. Їх можна викликати лише для змінної відповідного типу. Наприклад, калібрувати датчик можна так:

TSensors. calibrate (0.); // калібрується датчик номер 3

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

this -> curTemperature = actualTemperature;

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

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

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

Для перевірки умов мова С++ надає спеціальні засоби бібліотеки assert.h.

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

З має спеціальний механізм обробки винятків, чутливий до контексту. Контекстом порушення виключення є блок try (пробний блок). Якщо під час виконання операторів, що усередині блоку try, відбувається виняткова ситуація, то управління передається обробникам винятків, які задаються ключовим словом catch і перебувають нижче блоку try. Синтаксично обробник catch виглядає подібно до опису функції з одним аргументом без вказівки типу значення, що повертається. Для одного блоку try може бути задано кілька обробників, що відрізняються типом аргументу.

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

приклад. Розглянемо стек, реалізований з використанням масиву фіксованої довжини.

int stack; // Не більше ста елементів у стеку

int top=-1; // Номер доступного елемента

void push (int el) (

if(top == 99) throw (1); // Перевірити на переповнення

else stack[++top] = el; // Розмістити елемент у стек

if(top == -1) throw (0); // Перевірити на порожнечу

else return stack; // Витягти елемент зі стека

try( // пробний блок

catch(int error)(. . .) // якщо error = 0, то стек порожній;

// якщо error = 1, то стек повний

Об'єкт – унікальна сутність, що містить атрибути, що описують стану об'єкта реального світу і пов'язані з ними дії (правила поведінки). Багато в чому об'єкт та сутність РБД збігаються за властивостями, проте сутність моделює лише стан, а об'єкт інкапсулює і правила поведінки.

Серед атрибутів об'єкта виділяється атрибут посилань: він містить значення/колекцію значень, яке саме є об'єктом. Інакше кажучи, атрибут посилань концептуально аналогічний зовнішньому ключуу РБД чи покажчикам у ЯП.

Кожному об'єкту в момент створення надається ідентифікатор об'єкта OID. Він має такі властивості:

1. Генерується системою

2. Унікально позначає цей об'єкт

3. Його не можна змінити доки об'єкт продовжує існувати

4. Після створення об'єкта його ідентифікатор не можна використовувати повторно надалі за будь-яких умов.

5. Не залежить від значень атрибутів об'єкта, тобто. 2 об'єкти можуть і мати однаковий стан, але вони завжди мають різні OID.

6. В ідеалі - OID приховано від користувачів.

З допомогою OID цілісність сутностей гарантується автоматично.

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

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

Класи – угруповання однакових об'єктів.

Спадкування – один клас визначається як окремий випадок (підклас) загального класу(супер клас). Підклас успадковує всі властивості суперкласу + дод. визначає свої власні атрибути та методи. Усі екземпляри під класи є екземплярами суперкласу. Принцип підстановки: екземпляр під класу завжди може користуватися будь-яким методом/атрибутом суперкласу або будь-якої конструкції, де використовується суперклас. Поняття під-, суперкласу та успадкування існує також у розширеній РБД моделі. Однак у чисто об'єктної моделі успадкування відноситься і до стану і поведінки.

Перевантаження дозволяє повторно використовувати ім'я методу в одному або кількох методах класу. Окремий випадок перевантаження - перекриття. Воно дозволяє заново визначити ім'я якості у певному підкласі.

Динамічний зв'язування дозволяє відкласти лінковку до виконання.

Об'єктні моделі

Об'єктна модель дозволяє вирішити деякі проблеми, пов'язані з деякими реляційними базами.

Проблеми:

1. Підтримка кількох версій

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

Механізм відстеження версій повинен керувати змінами властивостей об'єктів так, щоб посилання на об'єкт завжди вказували на правильну версію.

Для керування версіями виділяються три типи версій: 1) тимчасова версія - вважається нестабільною, може бути видалена або оновлена, зберігається в закритому робочому просторі розробника проекту.

2) Робоча версія - вважається стабільнішою, може бути оновлена, але може бути видалена її творцем, як і зберігається у закритому робочому просторі розробника.

3) Випущена версія (реліз) - вважається стабільною, не може бути оновлена ​​або видалена, зберігається в відкритій базіі розміщується туди внаслідок вилучення робочої версії із закритого простору розробника.

2. Підтримка тривалих транзакцій

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

Виріанти вирішення проблем: 1) запроваджується протокол управління паралельним виконанням із тимчасовими мітками.

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

У цьому випадку кільком транзакціям дозволяється читати та записувати різні версії одного й того самого елемента даних.

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

1) Визначається тимчасова позначка найстарішої транзакції у системі, усе нижче цієї транзакції видаляться.

2) Вводяться вдосконалені моделі транзакцій. (Повна транзакція розкладається в деревоподібну структуру сум транзакцій які виконуються в паралельному режимі.

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

4) Механізм хронік (саги) субд гарантує що або всі транзакцій, що входять в хроніку, будуть завершені, або будуть запущені компенсуючі транзакції.

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

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

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

Недолік: практично об'єктна база пишеться у ручну.

У об'єктній основі є аналогії з основними прийомами роботи в реляційній основі.

Нормалізація в об'єктній базі означає - кожен атребут об'єкта повинен залежати від ідентифікатора об'єкта.

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

Посилальна цілісність.

Варіанти управління: 1) користувачеві забороняється явно видаляти об'єкти, система сама видаляє об'єкти, які стають недоступними.

2) користувачеві дозволяється видаляти об'єкти, коли вони стають непотрібними, тоді система автоматично виявляє недійсні посилання і присвоює недійсне посилання NULL.

3) користувачеві дозволяється змінювати та видаляти об'єкти, а система використовує зворотні атребути.

ЗАГАЛЬНА ХАРАКТЕРИСТИКА ОБ'ЄКТНО РЕЛЯЦІЙНОЇ МОДЕЛІ ДАНИХ

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

Переваги: ​​повторне та спільне використання стандартних компонентів.

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

Приклад поддерки лінійного програмуванняколи функції виконуються центролізовано.

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

Недоліки: Спотворення об'єктної ідеології.

РОЗШИРЕНИЙ СТАНДАРТ SQL 3. ОСНОВА ДЛЯ ПОБУДУВАННЯ ОБ'ЄКТНО РЕЛЯЦІЙНИХ БД

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

Дозволяються типи, процедури, функції, оператори, що визначаються користувачем.

Як правило, процедури або функції пишуться поза СУБД, і викликаються в SQL за допомогою оператора CALL.

Конструктори для типів колекції: створюється єдина таблиця, у якій є кілька рівнів вкладеності.

Підтримка великих об'єктів. Великий об'єкт- поле таблиці яке містить значну кількість даних.

У стандарті SQL міститься три топи великих об'єктів:

1) великий двійковий об'єкт

2) великий символьний об'єкт

У стандарті SQL 3 допускається виконання деяких операцій з об'єктами: наприклад, оператор конкатенації - повертає символьний рядок утворений з'єднанням символьних рядків у зазначеному порядку.

Є функції вилучення символьної підрядки:

Функція перекриття рядків.

Функція згортки перетворення регістра.

Функція обчислення довжини рядка.

МОДЕЛЬ Сховища даних

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

Сховище даних має багато спільного із реляційною моделлю.

1) Сховище даних організується не навколо областей діяльності, а довкола (предметів, товарів та ін.).

2) Дані не оновлюються, лише поповнюються.

3) Реляційна база проектується для забезпечення інтенсивної обробки невеликої кількості транзакцій, сховище даних проектується для обробки одиничних довільних запитів.

4) Базовим об'єктом моделі сховища є прив'язаний до часу факт.

5) Основна операція це агрегування та основна проблема максимальна швидкістьдоступу до факту.

Сховище даних.

Бази даних у концепції сховища описуються з допомогою методу «моделювання розмірностей».

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

Кожна таблиця розмірностей має складову (простий) первинний ключщо точно відповідає одному з компонентів складеного ключа в таблиці фактів

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

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

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

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

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

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

Схема сніжинка -варіант схеми зірка, в якій кожна розмірність може мати свої власні розмірності.

Перевага сховищ даних:

1. Ефективність - однаковість структури забезпечує ефективніший доступом до даних, незалежно від засобів доступу.

2. Всі розмірності однаково забезпечують доступ до таблиці фактів, отже проект має більшу здатність підтримувати довільні запити користувача.

3. Розширюваність – типові зміни:

1. Додавання нових фактів, це можна робити за умови, що вони мають такий самий ступінь деталізації, як і таблиця фактів.

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

3. Додавання нових атрибутів.

4. Розбиття існуючих розмірностей на записи з меншим рівнем деталізації, починаючи з певного моментучасу.

Модель даних OLAP

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

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

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

2. Куб легко розширюється, можна кожну комірку куба розвернути в підкуб.

3. Існує найпотужніший мат апарат для роботи з багатовимірними кубами, це матриці.

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

2. Зазвичай такі структури є сильно розріджені матриці. Багато NULL.

Для створення ефективної багатовимірної базиможливо кілька шляхів:

1. Виявити ієрархічну структуру даних.

2. Виявити інші порядки типу ґрат типових розмірностей.

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

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

Модель слабоструктурованих даних

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

Якщо в СУБД повинні зберігатися слабоструктуровані дані, субд повинна формувати схему на основі цих даних.

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

Варіанти запису слабоструктурованих даних:

1. Модель обміну об'єктними даними OEM. Модель представлення множених об'єктів визначається сама через себе. Дозволяється відобразити дані з нерегулярною структурою та невизначеним типом. Є розміченим, орієнтованим графом, у вузлах якого знаходяться особливі об'єкти (об'єкти OEM), для кожного об'єкта задаються унікальний ідентифікатор, описова текстова мітка, Тип, значення. Об'єкти поділяються на елементарні та складові. Елементарне - це листя, воно на графі відображається без вихідних ребер. всі інші називаються складовими, причому один і той самий об'єкт може мати довільне числобатьківських об'єктів. Тип конкретного об'єкта визначено як безліч ВД об'єкта. Працювати з конструкціями такого типу важко, тому що неможливо виділити порожню структуру графа.

2. Мова XML – мета мова, мова для опису інших мов. Система визначення структурованих типів документів та мов розмітки, що становлять екземпляри документів даного типу. Достоїнства:

1. Може застосовуватись для розмітки будь-яких документів, у тому числі текстових та мультимедійних.

2. Дозволяється наочно описати структуру даних. Можна використовувати для опису гетерогенних (різнорідних) БД.

3. Дозволяє зберігати вміст документа та окремо (незалежно) спосіб його подання.

Реляційна алгебра та реляційне обчислення

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

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

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

Обчислення кортежів - змінною є кортеж(рядок) тіла відношення.

p align="justify"> Для формування умов вибірки з набору відносин використовуються так звані правильно побудовані формули (well formed formula) - це умови накладаються на кортежні змінні.

Приклад: СЛУЖАЧИЙ СЛ_НОМ= НАЧАЛЬНИК НАЧ_НОМ

Для побудови WFF використовуються логічні зв'язки та правила математики.

Механізм роботи: Система перебирає всі наявні в бд комбінації кортежів, наприклад для кожного кортежу проект, проглядається обладати визначень кортежів службовців і виділяє ті поєднання кортежів для яких WFF вірно.

Таким чином, це еквівалентно тому, що система за замовчуванням виконує операцію join.

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

Зіставлення Реляційної алгебри та Реляційного обчислення.

Формально між ними є відмінності, проте з точки зору системи, що виконує, реляційна алгебра і реляційні обчислення логічно еквівалентні. Кожен вираз реляційної алгебриможе бути однозначно перетворено на вираження реляційного обчислення та навпаки.

Приклади: Субд які працюють на лінукс це INGRES (Integratie graphics retrielale System) (хз че написано у неї підкреслення кривої).

Та мова таблична форма Query by Example

Розглянемо процес побудови об'єктної моделі для системи банківського обслуговування (див. п. 1.3) у процесі аналізу вимог та попереднього проектування цієї системи. Для побудови об'єктної моделі аналізованої системи необхідно виконати всі етапи, перелічені у п.2.2.

2.3.1. Визначення об'єктів та класів

У п. 1.3 сформульовано завдання та наведено схему мережі банківського обслуговування (рис. 1.3). Аналізуючи цю постановку завдання, можна виділити можливі класи, зіставивши їх іменником, згаданим у її попередньому формулюванні; вийде наступний список можливих імен класів (за абеткою):

Досліджуємо цей список, виключаючи з нього імена класів відповідно до рекомендацій п. 2.2.1:

надлишкові класи: ясно, що клієнт і користувач означають те саме поняття; для банківської системи природніше залишити клас клієнт;

нерелевантні класи: таким класом є клас ціна (він не має безпосереднього відношення до роботи банківської мережі);

нечітко визначені класи: такими класами є служба ведення записів та перевірка безпеки (ці служби входять до складу проводки), система (у нашому випадку незрозуміло, що це таке), банківська мережа (вся наша програмна системаобслуговуватиме банківську мережу);

атрибути: дані проведення, дані рахунку, гроші (маються на увазі реальні гроші, що видаються клієнту касиром або банкоматом, або прийняті касиром), квитанція (видається клієнту разом з грошима) більш природно мати як атрибути;

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

Після виключення всіх зайвих імен можливих класів отримуємо наступний список класів, що становлять проектовану систему банківського обслуговування (ці класи представлені малюнку 2.5):

2.3.2. Підготовка словника даних

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

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

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

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

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

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

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

Комп'ютер банку – комп'ютер, що належить банку, який взаємодіє з мережею ATM (банкоматів) та власними касовими терміналами банку. Банк може мати свою внутрішню комп'ютерну мережу для обробки рахунків, але ми розглядаємо лише той комп'ютер банку, який взаємодіє з мережею ATM.

Консорціум – об'єднання банків, що забезпечує роботу мережі ATM (банкоматів). Мережа передає до консорціуму проведення банків.

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

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

Центральний комп'ютер – комп'ютер, що належить консорціуму, який розподіляє проводки та їх результати між ATM (банкоматами) та комп'ютерами банків. Центральний комп'ютер перевіряє коди банків, але не виконує проведення самостійно.

Резюме

Недоліки моделі TCP/IP

Незважаючи на величезну популярність, у моделі TCP/IP та її протоколів є ряд недоліків:

· Відсутність розмежувань концептуальних понять інтерфейсу, протоколу та рівневого сервісу, що досить чітко зроблено в моделі ISO/OSI. Внаслідок цього модель TCP/IP не може застосовуватися для розробки нових мереж;

· За допомогою моделі TCP/IP не можна описати ніякий інший стек протоколів, крім TCP/IP;

· У моделі не розрізняються фізичний і канальний рівні, у той час як вони абсолютно різні і в коректній моделі це повинно враховуватися;

· Найбільш ретельно продумані та опрацьовані протоколи IP та TCP. Багато інших протоколів стека розроблялися студентами (студентам до роздумів!) і вільно поширювалися, внаслідок чого широко укорінилися в практиці і тепер їх важко замінити на щось нове, пропоноване за комерційною схемою.

Як резюме зазначимо, що модель ISO/OSI є корисною для теоретичних досліджень та розробок нових мереж, хоча протоколи OSIне набули широкого поширення. Для TCP/IP можна зробити зворотне твердження: стек не може розглядатися як повноцінна модель, тоді як самі протоколи добре апробовані і надзвичайно популярні.

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

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

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

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

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

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

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

Ієрархія програмного забезпечення (ПЗ) може бути представлена ​​в наступному вигляді:

· прикладне ПЗ;

· проміжне ПЗ;

· базове ПЗ.

У прикладному ПЗреалізовано об'єкти додатків. Розрізняють два типи додатків, що впливають на структуру організації ПЗ – локально обмеженіі розподіленіпрограми.

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

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

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

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

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

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

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

Розрізняють наступні типиоб'єктних інтерфейсів ( програмних інтерфейсів):

· прикладний протокол (Application Protocol, АР) - логічний інтерфейсміж прикладними об'єктами;

· інтерфейс прикладних програм (Application Program Interface, API) – логічний інтерфейс між прикладними об'єктами та об'єктами проміжного ПЗ, які підтримують прикладні об'єкти;

· протокол проміжного ПЗ(Managing Protocol, МР) – логічний інтерфейс між об'єктами проміжного ПЗ;

· інтерфейс базових програм(Base Program Interface, ВРІ) – логічний інтерфейс між об'єктами проміжного та базового ПЗ, які підтримують об'єкти проміжного ПЗ;

· інтерфейс людина-комп'ютер(User-Computer Interface, UCI) – логічний інтерфейс між користувачем і, головним чином, об'єктами базового ПЗ, однак він може включати також логічний інтерфейс з об'єктами проміжного ПЗ і навіть об'єктами додатків.

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