12.9. Розробка діаграми компонентів в середовищі Rational Rose
Діаграма компонентів є частиною фізичного представлення моделі і грає важливу роль в процесі ООАП. Активізація діаграми компонентів може бути виконана одним з наступних способів:
Клацнути на кнопці із зображенням діаграми компонентів на стандартній панелі інструментів.
Розкрити компонентне уявлення в браузере (Component View) і двічі клацнути на піктограмі Main (Головна).
Через пункт меню Browse‑ »Component Diagram (Браузер‑ »Диаграмма компонентів).
Після активізації діаграми компонентів спеціальна панель інструментів придбає наступний вигляд (мал. 12.18).
Мал. 12.18. Зовнішній вигляд спеціальної панелі інструментів для діаграми компонентів
Додавання і видалення елементів відбувається аналогічно, проте для кожного компоненту можна визначити різні деталі, такі як стереотип, язик програмування, декларації, класи. Робота з цими деталями компонентів здійснюється через специфікацію компоненту, доступну після виклику контекстного меню.
Нижче наводиться приклад графічного зображення елементів діаграми компонентів (мал. 12.19).
При роботі з діаграмою компонентів можна створювати пакети і компоненти, змінювати їх специфікацію і залежність між різними елементами діаграми. При встановленні реалізації класів на компоненті можна виділити клас в браузере і перетягнути його на потрібний компонент діаграми.
Мал. 12.19. Приклад графічного зображення діаграми компонентів в середовищі Rational Rose
12.10. Розробка діаграми розгортання в середовищі Rational Rose
Діаграма розгортання є другою складовою частиною фізичного представлення моделі. Активізація діаграми розгортання може бути виконана одним з наступних способів:
Клацнути на кнопці із зображенням діаграми розгортання на стандартній панелі інструментів.
Двічі клацнути на піктограмі представлення розгортання в браузере (Deployment View).
Через пункт меню Browse‑ »Deployment Diagram (Браузер‑ »Диаграмма розгортання).
Після активізації діаграми розгортання спеціальна панель інструментів придбає наступний вигляд (мал. 12.20).
Мал. 12.20. Зовнішній вигляд спеціальної панелі інструментів для діаграми розгортання
Робота з діаграмою розгортання полягає в створенні процесорів і пристроїв, їх специфікації, встановленні зв'язків між ними, а також додаванні і специфікації процесів. Стосовно окремих процесорів можна використовувати стереотипи.
Нижче наводиться приклад графічного зображення діаграми розгортання (мал. 12.21).
Мал. 12.21. Приклад графічного зображення діаграми розгортання в середовищі Rational Rose
Однією з наймогутніших властивостей середовища Rational Rose є можливість генерації програмного коду після побудови моделі. Як вже наголошувалося раніше, можливість генерації тексту програми на тому або іншому язиці програмування залежить від встановленої версії Rational Rose.
Загальна послідовність дій, які необхідно виконати для цього, складається з шести етапів:
Перевірка моделі незалежно від вибору язика генерації коду.
Створення компонентів для реалізації класів.
Відображення класів на компоненти.
Установка властивостей генерації програмного коду.
Вибір класу, компоненту або пакету.
Генерація програмного коду.
Особливості виконання кожного з етапів можуть змінюватися залежно від вибору язика. В середовищі Rational Rose передбачено завдання достатньо великого числа властивостей, що характеризують як окремі класи, так і проект в цілому. Проте опис цих властивостей виходить за межі справжньої книги.
Висновок
В даний час повністю специфікована і документована версія 1.3 язики UML і продовжується подальша робота по його розвитку. Хоча вже анонсована наступна версія язика UML – 1.4, на момент написання книги остаточна документація за цією версією ще не специфікована. Можливо, з цієї причини наступною версією стане UML 2.0, роботу над якою планується розвернути в 2001 році. Хід цієї роботи і її стан відображаються на офіційному сайті OMG: http://www.omg.org/. Там же містяться повні специфікації стандарту OMG‑ UML, надані для вільного доступу.
Іншим джерелом інформації по язику UML в Інтернеті є сайт компанії Rational Software Corp.: http://www.rational.com/, в якій зосереджені основні розробники і з боку якої здійснюється загальна координація роботи над черговими версіями язика. Ця компанія також є розробником CASE‑ засобу Rational Rose 98/2000, в якому реалізуються поточні доповнення язика UML.
З вітчизняних ресурсів не можна не згадати сайт компанії «Інтерфейс» – 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‑ засобів. Можна з упевненістю припустити, що ця область розвитку інформаційних технологій має широкі перспективи і стратегічне значення не тільки як язик спілкування між замовниками і розробниками програмних систем, але і для документування проектів в цілому. При цьому досягається необхідний рівень стандартизації і уніфікації всіх позначень, що використовуються для цієї мети.
Розробивши модель і специфицировав її на язиці UML, розробник має всі підстави бути понятим і по гідності оціненим своїми колегами. При цьому можуть бути виключені ситуації, коли той або інший розробник застосовує свою власну графічну нотацію для представлення тих або інших аспектів моделі, що практично виключає її розуміння іншими фахівцями у разі нетривіальності початкової моделі.
Не менше важливий аспект вживання язика UML пов'язаний з професійною підготовкою відповідних фахівців. Йдеться про те, що знання різних наукових дисциплін характеризують різні аспекти реального миру. При цьому принципи системного аналізу дозволяють розглядати ті або інші об'єкти як системи.
Подальша розробка моделі системи, направлена на рішення певних проблем, може зажадати залучення знань з різних дисциплін. З цієї точки зору язик UML може бути використаний не тільки для уніфікації представлень цих знань, але що не менше важливо – для їх інтеграції, направленої на підвищення адекватності много‑ модельных представлень складних систем.
Можливо з часом язик UML стане тим «есперанто», на якому зможуть спілкуватися математики, системні аналітики, фізики, програмісти, менеджери, економісти і фахівці інших професій, представляючи свої професійні знання в уніфікованому вигляді. Адже, по суті, кожний з фахівців оперує модельними уявленнями в своїй області знань. І саме цей модельний аспект може бути специфікований засобами язика UML.
У зв'язку з цим значення язика UML істотно зростає, оскільки він все більш придбаває риси язика представлення знань. При цьому наявність в язиці UML образотворчих засобів для представлення структури і поведінки моделі дозволяє досягти адекватного представлення декларативних і процедурних знань і, що не менше важливе, встановити між цими формами знань семантичну відповідність. Всі ці особливості язика UML дозволяють зробити висновок про те, що він має найсерйозніші перспективи вже в найближчому майбутньому.