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 як базова нотація візуального моделювання.

Примітка

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