Примітка. Кажучи про додаткові графічні зображення для вузлів діаграми розгортання, перш за все мають на увазі наочність їх подання

Кажучи про додаткові графічні зображення для вузлів діаграми розгортання, перш за все мають на увазі наочність їх подання. Наприклад, процесор можна зобразити як у вигляді загального вузла (рис. 25.1), так і у формі зображення зовнішнього вигляду комп'ютера. Відповідно, консоль може бути зображена у вигляді клавіатури. У будь-якому з цих випадків розробник повинен володіти ще й художніми здібностями.

25.2. З'єднання

Окрім власне зображень вузлів на діаграмі розгортання вказуються відношення між ними. Відношеннями виступають фізичні з'єднання між вузлами, залежності між вузлами та компонентами, зображення яких теж можуть бути присутніми на діаграмах розгортання.

З'єднання є різновидом асоціації і зображаються відрізками ліній без стрілок. Наявність такої лінії вказує на необхідність організації фізичного каналу для обміну інформацією між відповідними вузлами. Характер з'єднання може бути додатково специфікована приміткою, поміченою значенням або обмеженням. Так, на поданому нижче фрагменті діаграми розгортання (рис. 25.4) явно визначені не тільки вимоги до швидкості передачі даних в локальній мережі за допомогою поміченого значення, але й рекомендації з технології фізичної реалізації з'єднань у формі примітки.

Рис. 25.4. Фрагмент діаграми розгортання із з'єднаннями між вузлами

Окрім з'єднань на діаграмі розгортання можуть бути присутніми відношення залежності між вузлом і розгорненими на ньому компонентами. Подібний спосіб є альтернативою вкладеному зображенню компонентів всередині символу вузла, що не завжди зручно, оскільки робить цей символ надмірно об'ємним. Тому при великій кількості розгорнених на вузлі компонентів відповідну інформацію можна подати у формі відношення залежності (рис. 25.5).

Діаграми розгортання можуть мати складнішу структуру, що включає вкладені компоненти, інтерфейси та інші апаратні пристрої. На зображеній нижче діаграмі розгортання (рис. 25.6) представлений фрагмент фізичного подання системи видаленого обслуговування клієнтів банку. Вузлами цієї системи є видалений термінал (вузол-тип) і сервер банку (вузол-екземпляр).

Рис. 25.5. Діаграма розгортання з відношенням залежності між вузлом і розгорненими на ньому компонентами

Рис. 25.6. Діаграма розгортання для системи віддаленого обслуговування клієнтів банку

На цій діаграмі розгортання вказана залежність компоненту реалізації діалогу "dialog.exe" на видаленому терміналі від інтерфейсу ІAuthorise, який реалізований компонентом "main.exe", що, у свою чергу, розгорнутий на анонімному вузлі-екземплярі "Сервер банку". Останній залежить від компоненту бази даних "Клієнти банку", який розгорнений на цьому ж вузлі.

Примітка вказує на необхідність використання захищеної лінії зв'язку для обміну даними в цій системі. Інший варіант запису цієї інформації полягає в доповненні діаграми вузлом із стереотипом "закрита мережа".

Розроблення так званих вбудованих систем припускає не тільки створення програмних кодів, але й узгодження між собою всіх апаратних засобів і механічних пристроїв. Як приклад розглянемо фрагмент моделі керування видаленим механічним засобом типу транспортної платформи. Така платформа призначена для переміщення в агресивних середовищах, де присутність людини неможлива через цілий ряд фізичних причин.

Транспортна платформа оснащується власним мікропроцесором, цифровою відеокамерою, датчиками температури і місцеположення, а також приводами, що керують, для зміни напряму і швидкості переміщення платформи. Керуюча і телеметрична інформація від платформи по радіолінії передається в центр керування, який оснащений комп'ютером, що керує маніпуляторами керування і великим інформаційним табло.

На мікропроцесорі платформи розгорнені програмні компоненти для реалізації простих дій, що керують приводами, що дозволяє дискретно змінювати напрям і швидкість переміщення платформи. На комп'ютері центру керування розгорнені програмні компоненти аналізу телеметричної інформації, які характеризують стан окремих пристроїв платформи, а також реалізовані алгоритми керування переміщенням платформи в цілому.

Варіант фізичного подання цієї транспортної системи показаний на діаграмі розгортання (рис. 25.7).

Ця діаграма містить найзагальнішу інформацію про розгортання такої системи і в подальшому може бути деталізована під час розроблення власне програмних компонентів керування. Як видно з рисунка, під час розроблення цієї діаграми розгортання використано додатковий стереотип "приймач", який відсутній в описі мови UML, і спеціальні зображення для окремих апаратних і механічних пристроїв.

25.3. Рекомендації з побудови діаграми розгортання

Розроблення діаграми розгортання починається з ідентифікації всіх апаратних, механічних та інших типів пристроїв, які необхідні для виконання системою всіх своїх функцій. У першу чергу специфікуються обчислювальні вузли системи, що володіють пам'яттю і/або процесором. При цьому використовуються наявні в мові UML стереотипи, а у разі відсутності останніх, розробники можуть визначити нові стереотипи. Окремі вимоги до складу апаратних засобів можуть бути задані у формі обмежень, властивостей і значень.

Рис. 25.7. Діаграма розгортання для моделі системи керування транспортною платформою

Подальша побудова діаграми розгортання пов'язана з розміщенням всіх виконуваних компонентів діаграми за вузлами системи. Якщо окремі виконувані компоненти виявилися не розміщеними, то подібна ситуація повинна бути виключена введенням в модель додаткових вузлів, що містять процесор і пам'ять.

Під час розроблення простих програм, які виконуються локально на одному комп'ютері, так само як у випадку діаграми компонентів, необхідність в діаграмі розгортання може бути взагалі відсутньою. У складніших ситуаціях діаграма розгортання будується для таких програмних комплексів, як:

¨ Моделювання програмних систем, що реалізують технологію доступу до даних "клієнт-сервер". Для подібних систем характерне чітке розділення повноважень і, відповідно, компонентів між клієнтськими робочими станціями і сервером бази даних. Можливість реалізації "тонких" клієнтів на простих терміналах або організація доступу до сховищ даних приводить до необхідності уточнення не тільки топології системи, але й її компонентного складу.

¨ Моделювання неоднорідної розподіленої архітектури. Мова йде про корпоративні інтрамережі, що налічують сотні комп'ютерів і інші периферійні пристрої, що функціонують на різних платформах і під різними операційними системами. При цьому окремі вузли такої системи можуть бути віддалені один від одного на сотні кілометрів (філії компаній). У цьому випадку діаграма розгортання стає важливим інструментом візуалізації загальної топології системи і контролю міграції окремих компонент між вузлами.

Нарешті, вже згадувані раніше, системи з вбудованими мікропроцесорами, які можуть функціонувати автономно. Такі системи можуть містити найрізноманітніші додаткові пристрої, що забезпечують автономність їх функціонування і вирішення цільових завдань. Для подібних систем діаграма розгортання дозволяє візуалізувати склад цих пристроїв і їх взаємозв'язок у системі.

Як правило, розроблення діаграми розгортання здійснюється на останньому етапі ООАП, що характеризує закінчення фази проектування фізичного подання. З іншої сторони, діаграма розгортання може будуватися для аналізу існуючої системи з метою її подальшого аналізу і модифікації. При цьому аналіз припускає розроблення цієї діаграми на її початкових етапах, що характеризує загальний напрям аналізу від фізичного подання до логічного.

Під час моделювання бізнес-процесів діаграма розгортання, окрім комп'ютерів корпоративної мережі, може містити в якості вузлів різні засоби оргтехніки (факсимільні пристрої, багатоканальні телефонні станції, розмножувальні апарати, екрани для презентацій та ін.). При цьому кожний з подібних пристроїв може функціонувати як автономно, так і у складі корпоративної мережі.

Якщо необхідно включити в модель ресурси Інтернету, то на діаграмі розгортання Інтернет позначається у формі "хмарки" з відповідним іменем. Строго кажучи, подібне позначення не специфіковане в мові UML, проте воно часто використовується під час розроблення моделей розподілених систем.

На закінчення слід зазначити одну важливу обставину, характерну для розроблення всіх канонічних діаграм. Хоча в мові UML визначена графічна нотація для всіх елементів канонічних діаграм, способи графічного зображення окремих інструментальних засобів мають свої специфічні особливості. Застосування того або іншого інструментального CASE-засобу накладає певні обмеження на візуалізацію моделей програмних систем. Мова йде про те, що деякі елементи мови UML можуть бути взагалі відсутніми в CASE-засобах. Вихід з подібної ситуації може бути пов'язаний або з вибором іншого інструментарію, що підтримує останні версії мови UML, або спрощенні моделі на основі її типізації.

В розділі 26 деякі з цих аспектів будуть розглянуті детальніше на прикладі CASE-засобу Rational Rose.

Висновки

Контрольні питання

1. Призначення діаграми розгортання.

2. Вузли на діаграмі розгортання.

3. Види з'єднань.

4. Наведіть приклад побудови діаграми розгортання.

РОЗДІЛ 26. Особливості реалізації мови UML в CASE-інструментарії Rational Rose.

à Загальна характеристика CASE-засобу Rational Rose

à Особливості робочого інтерфейсу Rational Rose

à Розроблення діаграм в середовищі Rational Rose

Поява на ринку програмних продуктів перших CASE-засобів (Computer Aided Software Engineering) ознаменувало новий етап розвитку програмної інженерії, характерними рисами якої є істотне скорочення термінів розроблення програмних проектів, реалізації проектів групою програмістів й орієнтації на візуальні засоби специфікації компонентів програмного забезпечення.

Класичною областю застосування цих засобів стали бази даних, особливо ті з них, які вимагали серйозних зусиль під час розроблення своїх концептуальних схем. Підтримка можливості автоматичної генерації програмного коду на основі попередньо розробленої концептуальної схеми виявилася настільки конструктивною, що стимулювала появу більше двох десятків CASE-засобів різних фірм.

Як ми вже відзначали, початковий етап розвитку CASE-технологій характеризувався тим, що різні фірми пропонували свої власні засоби візуального подання концептуальних засобів. Найчастіше вибір того або іншого CASE-засобу розробниками визначався простотою нотації підтримуваного засобом мови подання схем і діаграм. Поява перших стандартів у цій області лише на якийсь час стабілізувало ситуацію. Однак найгостріша конкуренція серед фірм-виробників програмного забезпечення вимагала від CASE-засобів реалізації обєктно-орієнтованої технології розроблення програм і підтримки широкого діапазону мов програмування й конкретних баз даних.

Серед всіх фірм-виробників CASE-засобів саме компанія Rational Software Coip одна з перших усвідомила стратегічну перспективність розвитку обєктно-орієнтованих технологій аналізу й проектування програмних систем. Ця компанія виступила ініціатором уніфікації мови візуального моделювання в рамках консорціуму OMG, що, в остаточному підсумку, привело до появи перших версій мови UML. І ця ж компанія першою розробила інструментальний обєктно-орієнтований CASE-засіб, у якому була реалізована мова UML як базова нотація візуального моделювання.

Поиск по сайту: