- •1.1. Методологія процедурно‑ орієнтованого програмування
- •1.2. Методологія об'єктно-орієнтованого програмування
- •1.3. Методологія об'єктно-орієнтованого аналізу і проектування
- •1.4. Методологія системного аналізу і системного моделювання
- •Розділ 2
- •2.1. Передісторія. Математичні основи
- •Мал. 2.4. Приклади неорієнтованого (а) і орієнтованого (б) графів
- •Мал. 2.5. Приклади неорієнтованого (а) і орієнтованого (б) дерев
- •Мал. 2.6. Ієрархічні схеми неорієнтованого дерева (а) і орієнтованого дерева (б)
- •2.2. Діаграми структурного системного аналізу
- •I (Input) – вхід, т. Е. Все, що поступає в процес або споживається процесом.
- •2.3. Основні етапи розвитку uml
- •2. Забезпечити початкові поняття язика uml можливістю розширення і спеціалізації для більш точного представлення моделей систем в конкретній наочній області.
- •3. Опис язика uml повинен підтримувати таку специфікацію моделей, яка не залежить від конкретних язиків програмування і інструментальних засобів проектування програмних систем.
- •4. Опис язика uml повинен включати семантичний базис для розуміння загальних особливостей ооап.
- •7. Інтегрувати в себе новітні і якнайкращі досягнення практики ооап.
- •3.2. Загальна структура язика uml
- •3.3. Пакети в язиці uml
- •3.4. Основні пакети метамоделі язика uml
- •3.5. Специфіка опису метамоделі язика uml
- •3.6. Особливості зображення діаграм язика uml
- •4.1. Варіант використовування
- •4.2. Актори
- •4.3. Інтерфейси
- •4.4. Примітки
- •4.5. Відносини на діаграмі варіантів використовування
- •4.6. Приклад побудови діаграми варіантів використовування
- •4.7. Рекомендації по розробці діаграм варіантів використовування
- •5.1. Клас
- •5.2. Відносини між класами
- •5.5. Шаблони або класи, що параметризуються
- •5.6. Рекомендації по побудові діаграм класів
- •6.1. Автомати
- •Include – ця мітка використовується для звернення до підавтомата, при цьому наступний за нею вираз дії містить ім'я цього підавтомата.
- •6.3. Перехід
- •6.4. Складовий стан і підстан
- •6.5. Історичний стан
- •Мал. 6.10. Графічне зображення недавнього (а) і давнього (б) історичного стану
- •6.6. Складні переходи
- •Мал. 6.11. Графічне зображення паралельного переходу з паралельних станів (а) і паралельного переходу в паралельні стани (б)
- •6.7. Заключні рекомендації по побудові діаграм станів
- •7.1. Стан дії
- •7.2. Переходи
- •7.5. Рекомендації по побудові діаграм діяльності
- •8.2. Повідомлення
- •Мал. 8.7. Діаграма послідовності із стереотипними значеннями повідомлень
- •8.3. Приклад побудови діаграми послідовності
- •8.4. Заключні рекомендації по побудові діаграм послідовності
- •9.1. Кооперація
- •9.3. Зв'язки
- •9.4. Повідомлення
- •9.6. Заключні рекомендації по побудові діаграм кооперації
- •10.1. Компоненти
- •10.2. Інтерфейси
- •10.3. Залежність
- •10.4. Рекомендації по побудові діаграми компонентів
- •11.1. Вузол
- •11.2. З'єднання
- •Мал. 11.4. Фрагмент діаграми розгортання із з'єднаннями меходу вузлами
- •11.3. Рекомендації по побудові діаграми розгортання
- •12.1. Загальна характеристика case‑ засобу Rational Rose 98/2000
- •12.2. Особливості робочого інтерфейсу Rational Rose
- •12.3. Початок роботи над проектом в середовищі Rational Rose
- •12.4. Розробка діаграми варіантів використовування в середовищі Rational Rose
- •12.5. Розробка діаграми класів в середовищі Rational Rose
- •12.6. Розробка діаграми станів в середовищі Rational Rose
- •12.7. Розробка діаграми послідовності в середовищі Rational Rose
- •12.8. Розробка діаграми кооперації в середовищі Rational Rose
- •12.9. Розробка діаграми компонентів в середовищі Rational Rose
- •12.10. Розробка діаграми розгортання в середовищі Rational Rose
9.1. Кооперація
Поняття кооперації (collaboration) є одним з фундаментальних понять в язиці UML. Воно служить для позначення безлічі взаємодіючих з певною метою об'єктів в загальному контексті модельованої системи. Мета самої кооперації полягає в тому, щоб специфікувати особливості реалізації окремих найзначущіших операцій в системі. Кооперація визначає структуру поведінки системи в термінах взаємодії учасників цієї кооперації.
Кооперація може бути представлена на двох рівнях:
На рівні специфікації – показує ролі класифікаторів і ролі асоціацій в даній взаємодії.
На рівні прикладів – указує екземпляри і зв'язки, створюючі окремі ролі в кооперації.
Діаграма кооперації рівня специфікації показує ролі, які грають елементи, що беруть участь у взаємодії. Елементами кооперації на цьому рівні є класи і асоціації, які позначають окремі ролі класифікаторів і асоціації між учасниками кооперації.
Діаграма кооперації рівня прикладів представляється сукупністю об'єктів (екземпляри класів) і зв'язків (екземпляри асоціацій). При цьому зв'язки доповнюються стрілками повідомлень. На даному рівні показуються тільки релевантні об'єкти, т. е. мають безпосереднє відношення до реалізації операції або класифікатора.
В кооперації рівня прикладів визначаються властивості, які повинні мати екземпляри для того, щоб брати участь в кооперації. Окрім властивостей об'єктів на діаграмі кооперації також указуються асоціації, які повинні мати місце між об'єктами кооперації. При цьому зовсім не обов'язково зображати всі властивості або всі асоціації, оскільки на діаграмі кооперації присутні тільки ролі класифікаторів, але не самі класифікатори. Таким чином, тоді як класифікатор вимагає повного опису всіх своїх екземплярів, роль класифікатора вимагає опису тільки тих властивостей і асоціацій, які необхідні для участі в окремій кооперації.
Звідси витікає важливе слідство. Одна і та ж сукупність об'єктів може брати участь в різних коопераціях. При цьому, залежно від даної кооперації, можуть змінюватися як властивості окремих об'єктів, так і зв'язки між ними. Саме це відрізняє діаграму кооперації від діаграми класів, на якій повинні бути вказані всі властивості і асоціації між елементами діаграми.
Діаграма кооперації рівня специфікації
Кооперація на рівні специфікації зображається на діаграмі пунктирним еліпсом, усередині якого записується ім'я цієї кооперації (мал. 9.1). Таке представлення кооперації відноситься до окремого варіанту використовування і деталізує особливості його подальшої реалізації. Символ еліпса кооперації з'єднується відрізками пунктирної лінії з кожним з учасників цієї кооперації, як які можуть виступати об'єкти або класи. Кожна з цих пунктирних ліній позначається роллю (role) учасника. Ролі відповідають іменам елементів в контексті всієї кооперації. Ці імена потрактують як параметри, які обмежують специфікацію елементів при будь-якій їх появі в окремих представленнях моделі.
Мал. 9.1. Загальне представлення кооперації на діаграмах рівня специфікації
Простий клас на діаграмі кооперації позначається прямокутником класу, усередині якого записується рядок тексту. Цей рядок тексту називається роллю класифікатора (classifier role). Роль класифікатора показує особливість використовування об'єктів даного класу. Звичайно в прямокутнику показується тільки секція імені класу, хоча не виключається можливість вказівки секцій атрибутів і операцій.
Рядок тексту в прямокутнику повинен мати наступний формат:
'/ ‹Ім'я ролі классификатора‑ :' ‹Ім'я классификатора‑
[ :' ‹Ім'я классификатора‑ ]*
Тут Ім'я класифікатора, якщо це необхідне, може включати повний шлях всіх вкладених пакетів. При цьому один пакет від іншого відділяється подвійною двокрапкою"::". Якщо не виникає плутанини, можна обмежитися вказівкою тільки найближчого з пакетів, якому належить дана кооперація. Символ "*" застосовується для вказівки можливості ітеративного повторення імені класифікатора.
Якщо кооперація допускає узагальнене уявлення, то на діаграмах можуть бути вказані відносини узагальнення відповідних елементів. Цей спосіб може бути використаний для визначення окремих кооперацій, які є, у свою чергу, окремим випадком або спеціалізацією іншої кооперації. Така ситуація зображається звичайною стрілкою узагальнення, направленою від символу дочірньої кооперації до символу кооперації‑ предка (мал. 9.2). При цьому ролі дочірніх кооперацій можуть бути спеціалізаціями ролей кооперацій‑ предків.
Мал. 9.2. Графічне зображення відношення узагальнення між окремими коопераціями рівня специфікації
В окремих випадках виникає необхідність явно вказати той факт, що кооперація є реалізацією деякої операції або класифікатора. Це можна представити одним з двох способів.
По-перше, можна з'єднати символ кооперації пунктирною лінією із стрілкою узагальнення з символом класу, реалізацію операції якого специфікує дана кооперація (мал. 9.3, а). Так, якщо як клас розглянути «Замовлення на покупку товару», у якого є операція "оформить_заказ (), то її реалізація може бути специфікована у формі кооперації.
Мал. 9.3. Способи представлення кооперації, яка реалізує операцію класу
По-друге, можна просто зобразити символ кооперації, усередині якого вказати всю необхідну інформацію, записану за певними правилами (мал. 9.3, би). Ці правила визначають формат запису імені кооперації, після якого записують двокрапку і ім'я класу. За ім'ям класу слідує подвійна двокрапка і ім'я операції.
Подібне загальне представлення кооперації на рівні специфікації використовується на початкових етапах проектування. В подальшому кожна з кооперацій підлягає деталізації на рівні прикладів, на якому розкривається зміст і структура взаємозв'язків її елементів на окремій діаграмі кооперації. При цьому як елементи діаграми кооперації виступають об'єкти і зв'язки, доповнені повідомленнями. Саме ці елементи є предметом подальшого розгляду в справжньому розділі.
9.2. Об'єкти
Окремі аспекти специфікації об'єктів як елементів діаграм вже розглядалися раніше при описі діаграм класів (див. розділ 5) і послідовності (див. розділ 8). Зараз ми більш детально зупинимося на особливостях їх семантики і графічної нотації, оскільки об'єкти є основними елементами або графічними примітивами, з яких будується діаграма кооперації на рівні прикладів. Для графічного зображення об'єктів використовується такий же символ прямокутника, що і для класів.
Як наголошувалося вище, об'єкт (object) є окремим екземпляром класу, який створюється на етапі виконання програми. Він може мати своє власне ім'я і конкретні значення атрибутів. Стосовно об'єктів формат рядка класифікатора доповнюється ім'ям об'єкту і набуває наступний вигляд (при цьому весь запис підкреслюється):
‹Ім'я объекта‑ /' ‹Ім'я ролі классификатора‑ :' ‹Ім'я классификатора‑
[ :' ‹Ім'я классификатора‑ ]*
Тут Ім'я ролі класифікатора може не указуватися. В цьому випадку воно виключається з рядка тексту разом з подальшою двокрапкою. Ім'я ролі може бути опущено в тому випадку, якщо існує тільки одна роль в кооперації, яку можуть грати об'єкти, створені на базі цього класу.
Таким чином, для позначення ролі класифікатора достатньо вказати або ім'я класу (разом з двокрапкою), або ім'я ролі (разом з похилою межею). Інакше прямокутник відповідатиме звичайному класу. Якщо роль, яку повинен грати об'єкт, успадковується від декількох класів, то всі вони повинні бути вказані явно і розділятися комою і двокрапкою.
Примітка
В прямокутнику об'єкту ім'я об'єкту, ім'я ролі з символом Т або ім'я класу можуть бути відсутні. Проте двокрапка завжди повинна стояти перед ім'ям класу, а коса риска – перед ім'ям ролі. Слід ще раз акцентувати увагу на тій обставині, що стосовно об'єктів весь запис повинен бути підкреслена, а ім'я об'єкту повинне бути записано з рядкової букви.
Нижче приводяться можливі варіанти запису рядка тексту в прямокутнику об'єкту.
: З – анонімний об'єкт, утворюваний на основі класу З.
/ R
–
анонімний об'єкт, що грає роль R.
/
R: З –
анонімний об'єкт, утворюваний на основі
класу З і граючий роль R.
Про
/ R –
об'єкт з ім'ям Про, граючий роль R.
Про:
З –
об'єкт з ім'ям Про, утворюваний на основі
класу З.
Про
/ R: З –
об'єкт з ім'ям Про, утворюваний на основі
класу З і граючий роль R.
Про або – об'єкт з ім'ям О.
Про:
– «об'єкт‑ сирота» з ім'ям О.
/ R – роль з ім'ям R
: З – анонімна роль на базі класу З.
/ R: З – роль з ім'ям R на основі класу З.
Окремі приклади зображення об'єктів і класів на діаграмі кооперації приводяться на наступному малюнку (мал. 9.4).
Мал. 9.4. Приклади різних варіантів запису імен об'єктів, ролей і класів на діаграмах кооперації
Так, в першому випадку (мал. 9.4, а) позначений об'єкт з ім'ям «клієнт», що грає роль «ініціатор запиту». Далі (мал. 9.4, би) слідує позначення анонімного об'єкту, який грає роль ініціатора запиту. В обох випадках не вказаний клас, на основі якого будуть створені ці об'єкти. Позначення класу присутнє в наступному варіанті запису (мал. 9.4, в), причому об'єкт також анонімний.
Стосовно рівня специфікації на діаграмах кооперації можуть бути присутні іменовані класи з вказівкою ролі класу в кооперації (мал. 9.4, г) або анонімні класи, коли указується тільки його роль (мал. 9.4, д). Останній випадок характерний для ситуації, коли в моделі можуть бути присутні декілька класів з ім'ям «Клієнт», тому вимагається явно вказати ім'я відповідного пакету База даних (мал. 9.4, е).
Мультиобъект
мультиобъект (multiobject) є цілою безліччю об'єктів на одній з кінців асоціації. На діаграмі кооперації мультиобъект використовується для того, щоб показати операції і сигнали, які адресовані всій безлічі об'єктів, а не тільки одному. мультиобъект зображається двома прямокутниками, один з яких виступає через верхню праву вершину іншого (мал. 9.5, а). При цьому стрілка повідомлення відноситься до всієї безлічі об'єктів, які позначають даний мульти‑ объект. На діаграмі кооперації може бути явно вказано відношення композиції між мультиобъектом і окремим об'єктом з його множини (мал. 9.5, би).
Мал. 9.5. Графічне зображення мультиобъектов на діаграмі кооперації
Активний об'єкт
В контексті язика UML всі об'єкти діляться на дві категорії: пасивні і активні. Пасивний об'єкт оперує тільки даними і не може ініціювати діяльність по управлінню іншими об'єктами. Проте пасивні об'єкти можуть посилати сигнали в процесі виконання запитів, які вони одержують.
Активний об'єкт (асtive object) має свою власну нитку (thread) управління і може ініціювати діяльність по управлінню іншими об'єктами. При цьому під ниткою розуміється деякий полегшений потік управління, який може виконуватися паралельно з іншими обчислювальними нитками або нитками управління в межах одного обчислювального процесу або процесу управління.
Примітка
Відмінність між процесом і ниткою полягає в ступені використовування ресурсів. Кажучи про процес, мають у вигляді ресурсоємний потік управління, т. е. процес повністю монополізує ресурси системи. Нитка може використовувати лише невелику частину ресурсів системи. Прикладом може служити виконання деякої програми в своєму адресному просторі або у фоновому режимі.
Активні об'єкти на канонічних діаграмах позначаються прямокутником з більш широкими межами (мал. 9.6). Іноді може бути явно вказано ключове слово (помічене значення) {асtive}, щоб виділити активний об'єкт на діаграмі. Кожний активний об'єкт може ініціювати єдину нитку або процес управління і представляти початкову точку потоку управління. В приведеному фрагменті діаграми кооперації активний об'єкт «а: Зухвалий абонент» є ініціатором процесу встановлення з'єднання для обміну інформацією з іншим абонентом (на діаграмі не показаний).
Мал. 9.6. Графічне зображення активного об'єкту (зліва) на діаграмі кооперації
В наступному прикладі розглядається ситуація з викликом функції друку з текстового редактора (мал. 9.7). Анонімний активний об'єкт «Текстового редактора» спочатку посилає повідомлення анонімному мультиобъекту «Принтер», яке ініціює вибір єдиного об'єкту «Принтер», можливо, задовольняючого деяким додатковим умовам. Після цього вибраному об'єкту посилається повідомлення про необхідність надрукувати документ, завантажений в текстового редактора.
Мал. 9.7. Фрагмент діаграми кооперації для виклику функції друку з текстового редактора
Складовий об'єкт
Складовий об'єкт (composite object) або об'єкт‑ контейнер призначений для представлення об'єкту, що має власну структуру і внутрішні потоки (нитки) управління. Складовий об'єкт є екземпляром складового класу (класу‑ контейнера), який зв'язаний відношенням агрегації або композиції (див. розділ 5) з своїми частинами. Аналогічні відносини зв'язують між собою і відповідні об'єкти.
На діаграмах кооперації такий складовий об'єкт зображається як звичайний об'єкт, що складається з двох секцій: верхньої і нижньої. У верхній секції записується ім'я складового об'єкту, а в нижній – його складові частини замість списку його атрибутів (мал. 9.8). При цьому допускається мати як частини інші складові об'єкти.
Мал. 9.8. Графічне зображення складового об'єкту на діаграмі кооперації
