- •Міністерство освіти та науки України в.В. Литвин, н.Б. Шаховська Проектування інформаційних систем
- •Передмова наукового редактора серії підручників «комп’ютинґ»
- •1.1. Складність програмного забезпечення
- •1.2. Структура складних систем
- •1.2.1. Приклади складних систем
- •1.2.2. П'ять ознак складної системи
- •1.2.3. Організована і неорганізована складність
- •1.3. Методи подолання складності
- •1.3.1. Роль декомпозиції
- •1.3.3. Роль абстракції
- •1.3.4. Роль ієрархії
- •1.4. Про проектування складних систем
- •1.4.1. Інженерна справа як наука і мистецтво
- •1.4.2. Сенс проектування
- •4. Методи подолання складності.
- •2.1. Базові означення
- •2.2. Методи проектування інформаційних систем
- •2.3. Види інформаційних систем
- •2.4. Рівні моделей даних
- •3. Види інформаційних систем.
- •3.1. Методологія процедурно-орієнтованого програмування
- •3.2. Методологія об'єктно-орієнтованого програмування
- •3.3. Методологія об'єктно-орієнтованого аналізу і проектування
- •3.4. Методологія системного аналізу і системного моделювання
- •4.1. Передісторія. Математичні основи
- •4.1.1. Теорія множин
- •4.1.2. Теорія графів
- •4.1.3. Семантичні мережі
- •4.2. Діаграми структурного системного аналізу
- •4.3. Основні етапи розвитку uml
- •3. Семантичні мережі.
- •5.1. Принципи структурного підходу до проектування
- •5.2. Структурний аналіз
- •5.3. Структурне проектування
- •5.4. Методологія структурного аналізу
- •5.5. Інструментальні засоби структурного аналізу та проектування
- •6.1. Основні елементи
- •6.2. Типи зв’язків
- •6.3. Техніка побудови
- •6.4. Діаграма бізнес – функцій
- •6.4.1. Призначення діаграми бізнес-функцій
- •6.4.2. Основні елементи
- •7.1. Призначення діаграм потоків даних та основні елементи
- •7.1.1. Зовнішні сутності
- •7.1.2. Процеси
- •7.1.3. Накопичувачі даних
- •7.1.4. Потоки даних
- •7.2. Методологія побудови dfd.
- •8.1. Діаграма «сутність-зв’язок»
- •8.2. Діаграма атрибутів
- •8.3. Діаграма категоризації
- •8.4. Обмеження діаграм сутність-зв’язок
- •8.5. Методологія idef1
- •9.1. Основні елементи
- •9.2. Типи керуючих потоків
- •9.3. Принципи побудови
- •10.1. Структурні карти Константайна
- •10.2. Структурні карти Джексона
- •11.1. Призначення case-технологій
- •11.2. Інструментальний засіб bPwin
- •11.2.4. Інші діаграми bpWin
- •11.2.5. Моделі as is і to be
- •11.3.1. Основні властивості
- •11.3.2. Стандарт idef1x
- •11.4. Програмний засіб Visio
- •12.1. Системний аналіз області наукових досліджень
- •12.1.1. Аналіз предметної області
- •12.2. Системний аналіз біржі праці
- •12.2.1. Дерево цілей
- •12.2.2. Опис об’єктів предметної області
- •12.2.3. Концептуальна модель
- •14.1. Еволюція об'єктної моделі
- •14.1.1. Основні положення об'єктної моделі
- •14.2. Складові частини об'єктного підходу
- •14.2.1. Парадигми програмування
- •14.2.2. Абстрагування
- •14.2.3. Інкапсуляція
- •14.2.4. Модульність
- •14.2.5. Ієрархія
- •14.2.7. Паралелізм
- •14.2.8. Збереженість
- •14.3. Застосування об'єктної моделі
- •14.3.1. Переваги об'єктної моделі
- •14.3.2. Використання об'єктного підходу
- •14.3.3. Відкриті питання
- •15.1. Природа об'єкта
- •15.1.1. Що є й що не є об'єктом?
- •15.1.2. Стан
- •15.1.3. Поведінка
- •15.1.4. Ідентичність
- •Void drag(DisplayItem I); // Небезпечно
- •15.2. Відношення між об'єктами
- •15.2.1. Типи відношень
- •15.2.2. Зв'язки
- •15.2.3. Агрегація
- •15.3. Природа класів
- •15.3.1. Що таке клас?
- •15.3.2. Інтерфейс і реалізація
- •15.3.3. Життєвий цикл класу
- •15.4. Відношення між класами
- •15.4.1. Типи відношень
- •15.4.2. Асоціація
- •15.4.3. Успадкування
- •15.4.4. Агрегація
- •15.4.5. Використання
- •15.4.6. Інсталювання (Параметризація)
- •15.4.6. Метакласи
- •15.5. Взаємозв'язок класів і об'єктів
- •15.5.1. Відношення між класами й об'єктами
- •15.5.2. Роль класів і об'єктів в аналізі й проектуванні
- •16.1. Важливість правильної класифікації
- •16.1.1. Класифікація й об’єктно-орієнтовне проектування
- •16.1.2. Труднощі класифікації
- •16.2. Ідентифікація класів і об'єктів
- •16.2.1. Класичний і сучасний підходи
- •16.2.2. Об’єктно-орієнтований аналіз
- •16.3. Ключові абстракції й механізми
- •16.3.1. Ключові абстракції
- •16.3.2. Ідентифікація механізмів
- •17.1. Призначення мови uml
- •17.2. Загальна структура мови uml
- •17.3. Пакети в мові uml
- •17.4. Основні пакети мета-моделі мови uml
- •17.5. Специфіка опису мета-моделі мови uml
- •17.6. Особливості зображення діаграм мови uml
- •18.1. Варіант використання
- •18.2. Актори
- •18.3. Інтерфейси
- •18.4. Примітки
- •18.5. Відношення на діаграмі варіантів використання
- •18.5.1. Відношення асоціації
- •13.5.2. Відношення розширення
- •18.5.3. Відношення узагальнення
- •18.5.4. Відношення включення
- •18.6. Приклад побудови діаграми варіантів використання
- •18.7. Рекомендації з розроблення діаграм варіантів використання
- •19.1. Клас
- •19.1.1. Ім'я класу
- •19.1.2. Атрибути класу
- •19.1.3. Операція
- •19.2. Відношення між класами
- •19.2.1. Відношення залежності
- •19.2.2. Відношення асоціації
- •19.2.3. Відношення агрегації
- •19.2.4. Відношення композиції
- •19.2.5. Відношення узагальнення
- •19.3. Інтерфейси
- •19.5. Шаблони або параметризовані класи
- •19.6. Рекомендації з побудови діаграми класів
- •20.1. Автомати
- •20.2. Стан
- •20.2.1. Ім'я стану
- •20.2.2. Список внутрішніх дій
- •20.2.3. Початковий стан
- •20.2.4. Кінцевий стан
- •20.3. Перехід
- •20.3.2. Сторожова умова
- •20.3.3.Вираз дії
- •15.4. Складений стан і підстан
- •20.4.1. Послідовні підстани
- •20.4.2. Паралельні підстани
- •15.5. Історичний стан
- •20.6. Складні переходи
- •15.6.1. Переходи між паралельними станами
- •20.6.2. Переходи між складеними станами
- •20.6.3. Синхронізуючі стани
- •20.7. Рекомендації з побудови діаграм станів
- •21.1. Стан дії
- •21.2. Переходи
- •21.5. Рекомендації до побудови діаграм діяльності
- •22.1.1. Лінія життя об'єкта
- •22.1.2. Фокус керування
- •22.2. Повідомлення
- •22.2.1. Розгалуження потоку керування
- •22.2.2. Стереотипи повідомлень
- •22.2.3. Тимчасові обмеження на діаграмах послідовності
- •22.2.4. Коментарі або примітки
- •22.3. Приклад побудови діаграми послідовності
- •22.4. Рекомендації з побудови діаграм послідовності
- •23.1. Кооперація
- •23.2.1. Мультиоб'єкт
- •23.2.2. Активний об'єкт
- •23.2.3. Складений об'єкт
- •23.3. Зв'язки
- •23.3.1. Стереотипи зв'язків
- •23.4. Повідомлення
- •23.4.1. Формат запису повідомлень
- •23.5. Приклад побудови діаграми кооперації
- •23.6. Рекомендації з побудови діаграм кооперації
- •24.1. Компоненти
- •24.1.1. Ім'я компоненту
- •24.1.2. Види компонент
- •24.2. Інтерфейси
- •24.3. Залежності
- •24.4. Рекомендації з побудови діаграми компонент
- •25.1. Вузол
- •25.2. З'єднання
- •25.3. Рекомендації з побудови діаграми розгортання
- •26.1. Загальна характеристика case-засобу Rational Rose
- •26.2. Особливості робочого інтерфейсу Rational Rose
- •26.1.1. Головне меню програми
- •26.1.2. Стандартна панель інструментів
- •26.1.3. Вікно браузера
- •26.1.4. Спеціальна панель інструментів
- •26.1.5. Вікно діаграми
- •26.1.6. Вікно документації
- •26.1.7. Вікно журналу
- •26.3. Початок роботи над проектом у середовищі Rational Rose
- •26.4. Розроблення діаграми варіантів використання в середовищі Rational Rose
- •26.5. Розроблення діаграми класів у середовищі Rational Rose
- •26.6. Розроблення діаграми станів у середовищі Rational Rose
- •26.7. Розроблення діаграми послідовності в середовищі Rational Rose
- •26.8. Розроблення діаграми кооперації в середовищі Rational Rose
- •26.9. Розроблення діаграми компонентів у середовищі Rational Rose
- •26.10. Розроблення діаграми розгортання в середовищі Rational Rose
19.2.5. Відношення узагальнення
Відношення узагальнення є звичайним таксономічним відношенням між загальнішим елементом (батьком або предком) і частковішим або спеціальним елементом (нащадком). Таке відношення може використовуватися для представлення взаємозв'язків між пакетами, класами, варіантами використання й іншими елементами мови UML.
Стосовно діаграми класів таке відношення описує ієрархічна будова класів і успадкування їх властивостей і поведінки. При цьому передбачається, що клас-нащадок володіє всіма властивостями і поведінкою класу-предка, а також має свої власні властивості і поведінку, які відсутні в класу-предка. На діаграмах відношення узагальнення позначається суцільною лінією з трикутною стрілкою на одному з кінців (рис. 14.12). Стрілка вказує на загальніший клас (клас-предок або суперклас), а її відсутність – на спеціалізований клас (клас-нащадок або підклас).
Рис. 19.12. Графічне зображення відношення узагальнення в мові UML
Як правило, на діаграмі може вказуватися декілька ліній для одного відношення узагальнення, що відображає його таксономічний характер. У цьому випадку загальніший клас розбивається на підкласи одним відношенням Узагальнення. Наприклад, клас Геометрична_фігура_на_площині (курсив позначає абстрактний клас) може виступати як суперклас для підкласів, що відповідають конкретним геометричним фігурам, таким як, Прямокутник, Коло, Еліпс і ін. Даний факт може бути представлений графічно у формі діаграми класів такого вигляду (рис. 19.13).
Рис. 19.13. Приклад графічного зображення відношення узагальнення класів
З метою спрощення позначень на діаграмі класів сукупність ліній, що позначають одне і те ж відношення узагальнення, може бути об'єднана в одну лінію. У цьому випадку окремі лінії зображаються такими, що сходяться до єдиної стрілки, що має з ними загальну точку перетину (рис. 19.14).
Рис. 19.14. Варіант графічного зображення відношення узагальнення класів для випадку об'єднання окремих ліній
Це позначення відповідає графові спеціального вигляду, який розглядався в розділі 4, а саме – ієрархічному дереву. У цьому випадку клас-предок є коренем цього дерева, а класи-нащадки – його листям. Відмінність полягає в можливості вказівки на діаграмі класів потенційної можливості наявності інших класів-нащадків, які не включені в позначення представлених на діаграмі класів (багатокрапка замість прямокутника).
Поряд із стрілкою узагальнення може розміщуватися рядок тексту, який вказує на деякі додаткові властивості цього відношення. Цей текст відноситиметься до всіх ліній узагальнення, які йдуть до класів-нащадків. Іншими словами, відмічена властивість стосується всіх підкласів даного відношення. При цьому текст слід розглядати як обмеження, і тоді він записується у фігурних дужках.
Як обмеження можуть бути використані наступні ключові слова мови UML:
{complete} – означає, що у відношенні узагальнення специфіковані всі класи-нащадки, а інших класів-нащадків у даного класу-предка бути не може. Приклад – клас Клієнт_банку є предком для двох класів: Фізична_особа і Компанія, а інших класів-нащадків він не має. На відповідній діаграмі класів це можна вказати явно, записавши поряд з лінією узагальнення даний рядок-обмеження;
{disjoint} – означає, що класи-нащадки не можуть містити об'єктів, що одночасно є екземплярами двох або більше класів. У приведеному вище прикладі ця умова також виконується, оскільки передбачається, що ніяка конкретна фізична особа не може бути одночасно і конкретною компанією. У цьому випадку поряд з лінією узагальнення можна записати даний рядок-обмеження;
{incomplete} – означає випадок, протилежний першому. А саме, передбачається, що на діаграмі вказані не всі класи-нащадки. У подальшому можливо заповнити їх перелік не змінюючи вже побудовану діаграму. Приклад – діаграма класу "Автомобіль", вказівка всіх без виключення моделей автомобілів тотожне із створенням відповідного каталогу. З іншої сторони, для окремої задачі, такої як розроблення системи продажу автомобілів конкретних моделей, у цьому немає необхідності. Але вказати неповноту структури класів-нащадків усе ж таки треба;
{overlapping} – означає, що окремі екземпляри класів-нащадків можуть належати одночасно декільком класам. Приклад – клас "Багатокутник" є класом-предком для класу "Прямокутник" і класу "Ромб". Проте існує окремий клас "Квадрат", екземпляри якого одночасно є об'єктами перших двох класів. Цілком природно таку ситуацію вказати явно за допомогою даного рядка-обмеження.
З врахуванням можливості використання рядків-обмежень діаграма класів (рис. 19.14) може бути зображена без багатокрапок і без втрати інформації (рис. 19.15).
Рис. 19.15. Варіант графічного зображення відношення узагальнення класів з використанням рядка-обмеження
Щоб проілюструвати особливості використання відношення узагальнення, перетворимо один з розглянутих раніше прикладів зображення класів у графічну нотацію мови UML. В якості такого прикладу розглянемо ієрархію вкладеності класів для абстрактного класу "Автомобіль" (див. рис. 3.2, 4.7). Відношення між окремими класами на цих рисунках є саме відношенням узагальнення, яке в мові UML має спеціальне графічне позначення. З врахуванням цієї графічної нотації, фрагмент семантичної мережі для представлення ієрархії класу "Автомобіль" (див. рис. 4.7) може бути представлений у вигляді діаграми класів, наведеної на рис. 19.16.
Рис. 19.16. Фрагмент діаграми класів з відношенням узагальнення для подання ієрархії класів "Автомобіль" з розглянутого раніше прикладу (див. рис. 4.7)
Відмітимо, що у такому прикладі всі класи верхніх рівнів є абстрактними, тобто не можуть бути представлені своїми екземплярами. Саме тому їх імена записані курсивом. На відміну від них класи нижнього рівня є конкретними, оскільки можуть бути представлені своїми екземплярами, якими виступають виготовлені автомобілі відповідної моделі з унікальним заводським номером.
Примітка
Як вправа для закріплення розглянутого матеріалу можна спробувати побудувати діаграму класів для бібліотек стандартних класів MFC (Microsoft) і VCL (Borland/Inprise) з використанням графічної нотації мови UML.