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

Клас А залежить від особливостей класів B і C

Відношення асоціації

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

Графічне зображення відносини бінарної асоціації між класами

Асоціація може мати ім'я. Асоціація може бути тернарной (наявність відносини між 3 класами).

Графічне зображення тернарной асоціації між трьома класами

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

Графічне зображення асоціації, що виключає, між трьома класами

Відношення агрегації

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

Діаграма класів для ілюстрації відносини агрегації на прикладі ПК

Відношення композиції

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

Діаграма класів для ілюстрації відносини композиції на прикладі класу вікна програми

Відношення узагальнення

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

Приклад графічного зображення відносини узагальнення класів

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

Інтерфейс

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

Приклад графічного зображення інтерфейсу на діаграмі класів

Об'єкт

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

Приклад графічного зображення об'єкта на діаграмі мови UML

Рекомендації з побудови діаграми класів

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

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

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

Лекція 5

Наскрізний приклад объектно-ориентированной розробки ПС на базі методології OMT

1.  Нотація Буча.

2.  Нотація OMT.

3.  Нотація UML.

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

Схема банківської мережі

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

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

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

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

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

Попереднє проектування системи

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

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

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

·  динамічної моделі, що описує роботу окремих частин системи;

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

Об'єктна модель системи

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

Виділення класів

Виділимо класи для нашої системи:

·  банкомат;

·  ЦК;

·  рахунок;

·  консорціум банків;

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

·  проводка;

·  банк;

·  картка;

·  клієнт;

·  касова станція (термінал);

·  касир.

Залежності між класами в методології UML

Приклад атрибута залежності, а також доопределение якимось атрибутом

Асоціація може бути й спрямованою.

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

Класифікатором називається атрибут, що дозволяє знизити ефективно кратність залежності. Класифікатор звичайно застосовується при 1:m, n:m.

Приклад класифікатора

Лекція 6

Побудова об'єктної моделі

Процес побудови об'єктної моделі складається з:

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

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

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

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

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

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

Визначення класів

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

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

·  нерелевантні класи - не мають прямого відношення до проблеми;

·  нечітко певні;

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

·  операції: деяким іменником більше відповідають не класи, а імена операцій;

·  ролі: деякі іменники визначають імена ролей в об'єктній;

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

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

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