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

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

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

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

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

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

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

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

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

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

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

На чолі 12 деякі з цих аспектів будуть розглянуті більш детально на прикладі CASE‑ засобу Rational Rose 98/981.

РОЗДІЛ 12

Особливості реалізації язика UML в CASE‑ інструментарії Rational Rose 98/2000

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

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

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

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

Примітка

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