Модуль №1 "Методологічні основи розробки інформаційних систем" (стр. 4 )

Визначення залежностей

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

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

·  нерелевантні залежності виключаються;

·  залежності пов'язані з реалізацією теж виключаються;

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

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

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

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

·  невірно названі залежності - перейменовуємо, щоб зміст їх став зрозумілий;

·  імена ролей додаються, де це необхідно;

·  додаємо квалификаторы, де це необхідно;

·  кратність: додаємо позначення кратності залежностей;

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

Уточнення атрибутів

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

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

·  квалификаторы: якщо значення атрибута залежить від конкретного контексту, те його можна зробити квалификатором;

·  імена звичайно краще відповідають квалификаторы, чим імена атрибутів;

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

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

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

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

Лекція 7

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

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

Прийоми безкомп'ютерного пошуку:

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

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

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

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

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

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

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

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

Ознаки зайвих залежностей:

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

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

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

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

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

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

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

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

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

1)  ATM (банкомат);

2)  банк;

3)  банківська мережа;

4)  дані проводки;

5)  дані рахунки;

6)  гроші;

7)  доступ;

8)  картка;

9)  касир;

10)  касовий термінал;

11)  квитанція;

12)  клієнт;

13)  комп'ютер банку;

14)  консорціум;

15)  користувач;

16)  проводка;

17)  програмне забезпечення;

18)  система;

19)  перевірка безпеки;

20)  служба ведення записів;

21)  рахунок;

22)  ціна;

23)  центральний комп'ютер.

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

1)  надлишкові класи: клієнт = користувач, користувач - удаляем;

2)  нерелевантні класи - ціна;

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

4)  атрибути: даної проводки, дані рахунки, гроші, видавані клієнтові касиром або банкоматом, квитанція більш природно мати як атрибути;

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

Після виключення всіх зайвих імен можливих класів одержуємо список класів проектованої системи:

1)  ATM (банкомат);

2)  банк;

3)  картка;

4)  касир;

5)  касовий термінал;

6)  клієнт;

7)  комп'ютер банку;

8)  консорціум;

9)  проводка;

10)  рахунок;

11)  центральний комп'ютер.

Лекція 8

Формування словника даних

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

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

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

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

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

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

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

Консорціум – об'єднання банків, що забезпечує роботу всієї мережі банкоматів. Банкомат передає сюди проводки банку.

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

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

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

Визначення залежностей

Додержуючись вище наведених рекомендацій, виділимо явні й неявні дієслівні оберти:

·  Банківська мережа включає касирів і банкомати

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

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

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

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

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

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

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

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

·  Банкомат приймає картку

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

·  Банкомат видає готівку

·  Банкомат друкує квитанції

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

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

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

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

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

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

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

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

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

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

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