PrIS

512

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

Графічно на діаграмі розгортання вузол зображається у формі тривимірного куба (строго кажучи, псевдотривимірного прямокутного паралелепіпеда). Вузол має власне ім'я, яке вказується всередині цього графічного символа. Самі вузли можуть подаватися типами (рис. 25.1, а) або екземплярами (рис. 25.1, б).

Рис. 25.1. Графічне зображення вузла на діаграмі розгортання.

У першому випадку ім'я вузла записується без підкреслення і починається з великої літери. У другому – ім'я вузла-екземпляра записується у вигляді <ім'я вузла ':' ім'я типу вузла>. Ім'я типу вузла вказує на деякий різновид вузлів, які присутні в моделі системи.

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

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

513

Рис. 25.2. Графічне зображення вузла-екземпляра з додатковою інформацією у формі позначеного міткою значення.

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

Рис. 25.3. Варіанти графічного зображення вузлів-екземплярів з розміщуваними на них компонентами.

Другий спосіб дозволяє показувати на діаграмі розгортання вузли з вкладеними зображеннями компонентів (рис. 25.3, б). Важливо пам'ятати, що такими вкладеними компонентами можуть виступати тільки виконувані компоненти.

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

514

пристроїв, графічне зображення яких пояснює призначення або виконувані пристроєм функції.

Примітка

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

25.2. З'єднання

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

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

515

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

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

:Сервер

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

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

516

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

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

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

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

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

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

517

комп'ютером, що керує маніпуляторами керування і великим інформаційним табло.

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

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

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

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

518

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

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

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

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

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

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

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

519

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

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

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

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

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

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

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

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

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

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

520

Висновок

Джерелами інформації про мову UML в Інтернеті є сайт ресурсів

UML: http://www.uml.org/; сайт компанії Rational Software Corp.: http://www.rational.com/, на якому зосереджено основні розроблення та здійснюється загальна координація роботи над черговими версіями мови. Ця компанія також є розробником CASE-засобу Rational Rose, в якому реалізуються поточні доповнення мови UML. Повні специфікації стандарту OMG-UML надані для вільного доступу за адресою http://www.omg.org.

На сайті http://www.interface.ru міститься інформація про сучасні CASE-засоби, розглядаються їх характеристики і можливості, а також особливості окремих технологій ООАП.

Перспективи подальшого розвитку UML зв'язані зі становленням та інтенсивним розвитком нової парадигми об’єктно-орієнтованого аналізу – компонентного розроблення програмних комплексів (Component-Based Development – CBD). У цьому зв'язку розгорнута робота над додатковою специфікацією мови UML для технологій CORBA і СОМ+. Мова йде про розроблення так званих профілів, що містять нотацію всіх необхідних елементів для подання в мові UML компонентів відповідних технологій. При цьому інтенсивно використовується механізм розширення мови UML за рахунок додавання нових стереотипів, позначених значень і обмежень.

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

Зокрема, для моделювання бізнес-процесів можуть бути використані: для підсистем – стереотипи "organization unit" та "work unit",

для класів – стереотипи "worker", "case worker", "internal worker". При цьому, наприклад, стереотип "worker" служить для позначення класу, що відображає абстракцію людини, яка виконує певну роботу в бізнессистемі. Працівник взаємодіє з іншими співробітниками підсистеми при виконанні окремих операцій, що утворять бізнес-логіку процесу.

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