
- •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
3.3. Пакети в язиці uml
Пакет – основний спосіб організації елементів моделі в язиці UML. Кожний пакет володіє всіма своїми елементами, т. е. тими елементами, які включені в нього. Про відповідні елементи пакету говорять, що вони належать пакету або входять в нього. При цьому кожний елемент може належати тільки одному пакету. У свою чергу, одні пакети можуть бути вкладені в інші пакети. В цьому випадку перші називаються подпаке‑ тами, оскільки всі елементи підпакету належатимуть більш загальному пакету. Тим самим для елементів моделі задається відношення вкладеності пакетів, яке є ієрархією.
Примітка
При розгляді відношення «пакет‑ підпакет» найбільш природно асоціювати його з більш загальним відношенням «множина‑ підмножина», яка була розглянута на чолі 2. Дійсно, оскільки пакет можна розглядати як окремий випадок множини, така інтерпретація допомагає нам використовувати і графічні засоби для представлення відповідних відносин між пакетами.
З розділу 2 нам також відомо, що для графічного представлення ієрархій можуть використовуватися графи спеціального вигляду, які називаються деревами (див. мал. 2.5Г2.6). Проте в язиці UML ці графічні позначення настільки модифіковані, що відповідні асоціації із загальнотеоретичними поняттями можуть представляти певну трудність для початківців розробників. Проте, протягом всієї книги підкреслюється важливість уміння асоціювати спеціальні конструкції язика UML з відповідними поняттями теорії множин і системного моделювання, що, в деякому розумінні, формує стиль мислення системного аналітика. Інакше не виключені прикрі помилки не тільки на початковому етапі концептуалізації наочної області, але і в процесі побудов різних представлень систем.
В язиці UML для візуалізації пакетів розроблена спеціальна символіка або графічна нотація, якої ми і користуватимемося надалі. Саме з опису цієї системи позначень ми приступимо до вивчення основних елементів даного язика.
Для графічного зображення пакетів на діаграмах застосовується спеціальний графічний символ – великий прямокутник з невеликим прямокутником, приєднаним до лівої частини верхньої сторони першого (мал. 3.2 а, би). Можна сказати, що візуально символ пакету нагадує піктограму теки в популярному графічному інтерфейсі. Усередині великого прямокутника може записуватися інформація, що відноситься до даного пакету. Якщо такої інформації немає, то усередині великого прямокутника записується ім'я пакету, яке повинне бути унікальним в межах даної моделі (мал. 3.2, а). Якщо ж така інформація є, то ім'я пакету записується у верхньому маленькому прямокутнику (мал. 3.2, би).
Мал. 3.2. Графічне зображення пакету в язиці UML
Примітка
Кажучи про ім'я пакету, слід зупинитися на загальній угоді про імена в язиці UML. В даному випадку ім'ям пакету може бути рядок (або декілька рядків) тексту, що містить будь-яке число букв, цифр і деяких спеціальних знаків. З метою зручності специфікації пакетів прийнято як їх імена використовувати одне або декілька іменників, наприклад, контроллер, графічний інтерфейс, форма введення даних.
Перед ім'ям пакету може поміщатися рядок тексту, що містить деяке ключове слово. Подібними ключовими словами є наперед певні в язиці UML слова, які одержали назву стереотипів. Такими стереотипами для пакетів є слова facade, framework, stub і topLevel. Як вміст пакету можуть виступати імена його окремих елементів і їх властивості, такі як видимість елементів за межами пакету. Більш докладно стереотипи і видимість елементів будуть розглянуті в подальших розділах книги.
Звичайно, самі по собі пакети можуть знайти обмежене вживання, оскільки містять лише інформацію про вхідні в їх склад елементи моделі. Не менше важливо представити графічно відносини, які можуть мати місце між окремими пакетами. Як і в теорії графів, для візуалізації відносин в язиці UML застосовуються відрізки ліній, зовнішній вигляд яких має смисловий зміст.
Одним з типів відносин між пакетами є відношення вкладеності або включення пакетів один в одного. З одного боку, в язиці UML це відношення може бути зображено без використовування ліній простим розміщенням одного пакету‑ прямокутника усередині іншого пакету‑ прямокутника (мал. 3.3). Так, в даному випадку пакет з ім'ям ПакетЛ містить в собі два підпакети: Пакет_2 і Пакет_3.
Мал. 3.3. Графічне зображення вкладеності пакетів один в одного
Мал. 3.4. Графічне зображення вкладеності пакетів один в одного за допомогою явної візуалізації відношення включення
З другого боку, це ж відношення може бути зображено за допомогою відрізків ліній аналогічно графічному представленню дерева. В цьому випадку самий загальний пакет (метапакет або контейнер) зображається у верхній частині малюнка, а його підпакети – рівнем нижче. Метапакет з'єднується з підпакетами суцільною лінією, на кінці якої, що примикає до метапакету, зображається спеціальний символ © (знак плюс в кружечку). Цей символ означає, що підпакети є «власністю» або частиною контейнера, і, окрім цих підпакетів, контейнер не містить ніяких інших підпакетів. Розглянутий вище приклад (мал. 3.3) може бути представлений за допомогою явної візуалізації відношення включення (мал. 3.4).
На графічних діаграмах між пакетами можуть указуватися і інші типи відносин, частина з яких будуть розглянуті з подальших главах книги.