- •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
11.2. З'єднання
Окрім власне зображень вузлів на діаграмі розгортання указуються відносини між ними. Як відносини виступають фізичні з'єднання між вузлами і залежність між вузлами і компонентами, зображення якої теж можуть бути присутні на діаграмах розгортання.
З'єднання є різновидом асоціації і зображаються відрізками ліній без стрілок. Наявність такої лінії указує на необхідність організації фізичного каналу для обміну інформацією між відповідними вузлами. Характер з'єднання може бути додатково специфікований приміткою, поміченим значенням або обмеженням. Так, на представленому нижче фрагменті діаграми розгортання (мал. 11.4) явно визначені не тільки вимоги до швидкості передачі даних в локальній мережі за допомогою поміченого значення, але і рекомендації за технологією фізичної реалізації з'єднань у формі примітки.
Мал. 11.4. Фрагмент діаграми розгортання із з'єднаннями меходу вузлами
Окрім з'єднань на діаграмі розгортання можуть бути присутні відносини залежності між вузлом і розгорненими на ньому компонентами. Подібний спосіб є альтернативою вкладеному зображенню компонентів усередині символу вузла, що не завжди зручне, оскільки робить цей символ надмірно об'ємним. Тому при великій кількості розгорнених на, вузлі компонентів відповідну інформацію можна представити у формі відношення залежності (мал. 11.5).
Діаграми розгортання можуть мати складнішу структуру, що включає вкладені компоненти, інтерфейси і інші апаратні пристрої. На зображеній нижче діаграмі розгортання (мал. 11.6) представлений фрагмент фізичного представлення системи видаленого обслуговування клієнтів банку. Вузлами цієї системи є видалений термінал (вузол‑ тип) і сервер банку (вузол‑ екземпляр).
Мал. 11.5. Діаграма розгортання з відношенням залежності між вузлом і розгорненими на ньому компонентами
Мал. 11.6. Діаграма розгортання для системи видаленого обслуговування клієнтів банку
На цій діаграмі розгортання вказана залежність компоненту реалізації діалогу «dialog.exe» на видаленому терміналі від інтерфейсу lAuthorise, реалізованого компонентом «main.exe», який, у свою чергу, розгорнений на анонімному вузлі‑ екземплярі «Сервер банку». Останній залежить від компоненту бази даних «Клієнти банку», який розгорнений на цьому ж вузлі.
Примітка указує на необхідність використовування захищеної лінії зв'язку для обміну даними в даній системі. Інший варіант запису цієї інформації полягає в доповненні діаграми вузлом із стереотипом «закрита мережа».
Розробка так званих вбудованих систем припускає не тільки створення програмного коду, але і узгодження між собою всіх апаратних засобів і механічних пристроїв. Як приклад розглянемо фрагмент моделі управління видаленим механічним засобом типу транспортної платформи. Така платформа призначена для переміщення в агресивних середовищах, де присутність людини неможлива через цілий ряд фізичних причин.
Транспортна платформа оснащується власним мікропроцесором, цифровою відеокамерою, датчиками температури і місцеположення, а також управляючими приводами для зміни напряму і швидкості переміщення платформи. Управляюча і телеметрична інформація від платформи по радіолінії передається в центр управління, оснащений управляючим комп'ютером, маніпуляторами управління і великим інформаційним табло.
На мікропроцесорі платформи розгорнені програмні компоненти для реалізації найпростіших управляючих дій на приводи, що дозволяє дискретно змінювати напрям і швидкість переміщення платформи. На комп'ютері центру управління розгорнені програмні компоненти аналізу телеметричної інформації, що характеризує стан окремих устройств' платформи, а також реалізовані алгоритми управління переміщенням платформи в цілому.
Варіант фізичного представлення цієї транспортної системи показаний на наступній діаграмі розгортання (мал. 11.7).
Мал. 11.7. Діаграма розгортання для моделі системи управління транспортною платформою
Дана діаграма містить найзагальнішу інформацію про розгортання даної системи і в подальшому може деталізуватися при розробці власне програмних компонентів управління. Як видно з малюнка, при розробці цієї діаграми розгортання використані додатковий стереотип «приймач-передавач», який відсутній в описі язика UML, і спеціальні зображення для окремих апаратних і механічних пристроїв.
