
- •Міністерство освіти та науки України в.В. Литвин, н.Б. Шаховська Проектування інформаційних систем
- •Передмова наукового редактора серії підручників «комп’ютинґ»
- •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.2. Відношення асоціації
Відношення асоціації відповідає наявності деякого відношення між класами. Дане відношення позначається суцільною лінією з додатковими спеціальними символами, які характеризують окремі властивості конкретної асоціації. Як додаткові спеціальні символи можуть використовуватися ім'я асоціації, а також імена і кратність класів-ролей асоціації. Ім'я асоціації є необов'язковим елементом її позначення. Якщо воно задане, то записується із заголовної (великої) букви поряд з лінією відповідної асоціації.
Найпростіший випадок такого відношення – бінарна асоціація. Вона зв'язує в точності два класи і, як виняток, може пов'язувати клас із самим собою. Для бінарної асоціації на діаграмі може бути вказаний порядок проходження класів з використанням трикутника у формі стрілки поряд з іменем даної асоціації. Напрям цієї стрілки вказує на порядок класів, один з яких є першим (з боку трикутника), а інший – другим (з боку вершини трикутника). Відсутність такої стрілки поряд з іменем асоціації означає, що порядок проходження класів у такому відношенні не визначений.
Як простий приклад відношення бінарної асоціації розглянемо відношення між двома класами – класом "Компанія" і класом "Співробітник" (рис. 19.5). Вони зв'язані між собою бінарною асоціацією Робота, ім'я якої вказане на рисунку поряд з лінією асоціації. Для даного відношення визначений порядок проходження класів, першим з яких є клас "Співробітник", а другим – клас "Компанія". Окремим прикладом або екземпляром такого відношення може бути пара значень (Петренко І.І., "Рога&копита"). Це означає, що співробітник Петренко І.І. працює в компанії "Рога&копита".
Рис. 19.5. Графічне зображення відношення бінарної асоціації між класами
Тернарна асоціація і асоціації вищої арності в загальному випадку називаються N-кратною асоціацією (читається – "ен кратна асоціація"). Така асоціація зв'язує деяким відношенням 3 і більше за класи, при цьому один клас може брати участь в асоціації більше, ніж один раз. Клас асоціації має певну роль у відповідному відношенні, що може бути явно вказане на діаграмі. Кожний екземпляр N-кратної асоціації є N-кратним кортежем значень об'єктів з відповідних класів. Бінарна асоціація є окремим випадком N-кратної асоціації, коли значення N=2, і має своє власне позначення.
N-арна асоціація графічно позначається ромбом, від якого ведуть лінії до символів класів такої асоціації. У цьому випадку ромб з'єднується із символами відповідних класів суцільними лініями. Зазвичай лінії проводяться від вершин ромба або від середини його сторін. Ім'я N-кратної асоціації записується поряд з ромбом відповідної асоціації.
Порядок класів в N-арній асоціації, на відміну від порядку множин у відношенні, на діаграмі не фіксується. Деякий клас може бути приєднаний до ромба пунктирною лінією. Це означає, що даний клас забезпечує підтримку властивостей відповідної N-арної асоціації, а сама N-арна асоціація має атрибути, операції і/або асоціації. Іншими словами, така асоціація, у свою чергу, є класом з відповідним позначенням у вигляді прямокутника і є самостійним елементом мови UML – асоціацією-класом (Association Class). N-арна асоціація не може містити символу агрегації для жодної зі своїх ролей.
Як приклад конкретної тернарної асоціації розглянемо відношення між трьома класами: "Футбольна команда", "Рік" і "Гра". Така асоціація вказує на наявність відношення між цими трьома класами, яка може задавати інформацію про ігри футбольних команд у національному чемпіонаті протягом декількох останніх років (рис. 19.6).
Як вже згадувалося, окремий клас асоціації має власну роль у відношенні. Ця роль може бути зображена графічно на діаграмі класів. З цією метою в мові UML вводиться в розгляд спеціальний елемент – кінець асоціації (Association End), який графічно відповідає точці з'єднання лінії асоціації з окремим класом. Кінець асоціації є частиною асоціації, але не класу. Кожна асоціація має два або більше кінців асоціації. Найважливіші властивості асоціації вказуються на діаграмі поряд з цими елементами асоціації і повинні переміщуватися разом з ними.
Рис. 19.6. Графічне зображення тернарної асоціації між трьома класами
Однією з таких додаткових позначень є ім'я ролі окремого класу, що входить в асоціацію. Ім'я ролі є рядком тексту поряд з кінцем асоціації для відповідного класу. Вона вказує специфічну роль, яку відіграє клас, що є кінцем такої асоціації. Ім'я ролі не є обов'язковим елементом позначень і може бути відсутнім на діаграмі.
Наступний елемент позначень – кратність окремих класів, що є кінцями асоціації. Кратність окремого класу позначається у вигляді інтервалу цілих чисел, аналогічно кратності атрибутів і операцій класів. Інтервал записується поряд з кінцем асоціації і для N-арної асоціації означає потенційне число окремих екземплярів або значень кортежів цієї асоціації, які можуть мати місце, коли решта N-1 екземпляр або значень класів фіксована.
Так, для розглянутого раніше прикладу (див. рис. 19.5) кратність "1" для класу "Компанія" означає, що кожний співробітник може працювати тільки в одній компанії. Кратність "1..*" для класу "Співробітник" означає, що в кожній компанії можуть працювати декілька співробітників, загальне число яких заздалегідь невідоме і нічим не обмежене. Відмітимо, що замість кратності "1..*" записати тільки символ "*" не можна, оскільки останній означає кратність "0..*". Для даного прикладу це означало б, що окремі компанії можуть зовсім не мати співробітників в своєму штаті. Але така кратність цілком прийнятна в інших ситуаціях, як це видно з розглянутого вище прикладу (рис. 19.6).
Що стосується інших властивостей відношення асоціації, то у разі їх наявності, вони можуть розглядатися як атрибути класу асоціації і можуть бути вказані на діаграмі звичайним для класу способом у відповідній секції прямокутника класу.
Окремим випадком відношення асоціації є так звана виключаюча асоціація (Xor-association). Семантика такої асоціації вказує на той факт, що з декількох потенційно можливих варіантів даної асоціації в кожний момент часу може використовуватися тільки один її екземпляр. На діаграмі класів виключаюча асоціація зображається пунктирною лінією, що з’єднює дві і більше асоціації, поряд з якою записується рядок-обмеження "{Xor}".
Наприклад, рахунок у банку може бути відкритий для клієнта, яким може виступати фізична особа (індивідуум) або компанія, що зображається за допомогою виключаючої асоціації (рис. 19.7).
Рис. 19.7. Графічне зображення виключаючої асоціації між трьома класами
Спеціальною формою або окремим випадком відношення асоціації є відношення агрегації, яке, у свою чергу, теж має спеціальну форму – відношення композиції. Оскільки ці відношення мають свої спеціальні позначення і відносяться до базових понять мови UML, розглянемо їх послідовно.