Тема 7. Елементи графічної нотації діаграми компонентів

План.

1. Призначення діаграми компонентів, її основні елементи.

2. Особливості фізичного представлення програмних систем.

3. Компоненти програмних систем, їх різновиди.

4. Інтерфейси, їх реалізація компонентами.

5. Використання діаграми компонентів для проектування залежностей між компонентами.

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

7. Діаграма компонентів і особливості її побудови

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

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

Фізична система (physical system) - реально існуючий прототип моделі системи.

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

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

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

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

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

Компоненти

Для представлення фізичних сутностей в UML застосовується спеціальний термін - компонент.

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

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

Компонент служить для загального позначення елементів фізичного представлення моделі і може реалізовувати деякий набір інтерфейсів. Для графічного представлення компонента використовується спеціальний символ - прямокутник зі вставленими зліва двома більш дрібними прямокутниками (рис. 12,1). Усередині прямокутника записується ім'я компоненту і, можливо, додаткова інформація. Цей символ є базовим позначенням компонента в мові UML.

Рис. 12.1. Графічне зображення компонента

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

Модуль (module) - частина програмної системи, що вимагає пам'яті для свого зберігання і процесора для виконання.

У цьому випадку верхній маленький прямокутник концептуально асоціювався з даними, які реалізує цей компонент (іноді він зображується у формі овалу). Нижній маленький прямокутник асоціювався з операціями або методами, реалізованими компонентом. У простих випадках імена даних і методів записувалися явно в маленьких прямокутниках, проте в мові UML вони не вказуються.

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

Якщо компонент представляється на рівні типу, то записується тільки ім'я типу з великої літери у формі: <Ім'я типу>. Якщо ж компонент представляється на рівні екземпляра, то його ім'я записується у формі: <ім'я компонента ':' Ім'я типу>. При цьому вся рядок імені підкреслюється. Так, в першому випадку (рис. 12.1, а) для компонента рівня типів вказується ім'я типу, а в другому (рис. 12.1, б) для компонента рівня екземпляра - власне ім'я компонента і ім'я типу.

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

В якості власних імен компонентів прийнято використовувати імена виконуваних файлів, динамічних бібліотек, веб-сторінок, текстових файлів або файлів довідки, файлів баз даних або файлів з вихідними текстами програм, файлів скриптів та інші.

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

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

Для більш наочного зображення компонентів були запропоновані і стали загальноприйнятими наступні графічні стереотипи:

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

• По-друге, стереотипи для компонентів у формі робочих продуктів. Як правило - це файли з вихідними текстами програм (рис. 12.2, г).

Рис. 12.2. Варіанти графічного зображення компонентів на діаграмі компонентів.

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

Інший спосіб специфікації різних видів компонентів - вказівка текстового стереотипу компоненту перед його ім'ям. В UML для компонентів визначені наступні стереотипи:

• <<file>> (файл) - визначає найбільш загальну різновид компоненту, який представляється у вигляді довільного фізичного файлу.

• <<executable>> (виконуваний) - визначає різновид компонента-файлу, який є здійснимим файлом і може виконуватися на комп'ютерній платформі.

• <<document>> (документ) - визначає різновид компонента-файлу, який представляється у формі документа довільного змісту, який не є виконуваним файлом або файлом з вихідним текстом програми.

• <<library>> (бібліотека) - визначає різновид компонента-файлу, який представляється у формі динамічної або статичної бібліотеки.

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

• <<table>> (таблиця) - визначає різновид компоненту, який представляється у формі таблиці бази даних.

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

Інтерфейси

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

Рис. 12.3. Графічне зображення інтерфейсів на діаграмі компонентів.

Крім того, інтерфейс на діаграмі компонентів може бути зображений у вигляді прямокутника класу із стереотипом << interface>> і секцією підтримуваних операцій (рис. 12.3, б). Як правило, цей варіант позначення використовується для представлення внутрішньої структури інтерфейсу.

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

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

Залежності між компонентами

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

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

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

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

Рис. 12.4. Фрагмент діаграми компонентів з відносинами залежності і реалізації

Іншим випадком відношення залежності на діаграмі компонентів є відношення програмного виклику і компіляції між різними видами компонентів. Для розглянутого фрагмента діаграми компонентів (рис. 12,5) наявність подібної залежності означає, що здійсненний компонент Control. EXE використовує або імпортує деяку функціональність компоненту бібліотеки. DLL, викликає сторінку гіпертексту будинку. HTML і файл допомоги пошуку. HLP, а вихідний текст цього виконуваного компоненту зберігається у файлі управління. CPP. При цьому характер окремих видів залежностей може бути відзначений додатково за допомогою текстових стереотипів.

.

Рис. 12,5. Графічне зображення відношення залежності між компонентами.

На діаграмі компонентів можуть бути також представлені відносини залежності між компонентами і реалізованими в них класами. Ця інформація має значення для забезпечення узгодження логічного і фізичного представлень моделі системи. Зрозуміло, зміни в структурі описів класів можуть призвести до зміни цієї залежності. Нижче наводиться фрагмент залежності подібного роду, коли здійсненний компонент Control. EXE залежить від відповідних класів (рис. 12,6).

.

Рис. 12.6. Графічне зображення залежності між компонентом і класами.

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

.

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

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

.

Рис. 12.8. Графічне зображення компонента-екземпляра, що реалізовує окремі об'єкти.

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

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

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

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

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

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

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

Якщо ж проект містить фізичні елементи, опис яких відсутня в мові UML, то слід скористатися механізмом розширення. Зокрема, можна застосувати додаткові стереотипи для окремих нетипових компонентів або помічені значення для уточнення окремих характеристик компонентів.

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

Діаграма розгортання , особливості її побудови

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

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

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

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

Першою з діаграм фізичного представлення є діаграма компонентів. Друга форма фізичного представлення програмної системи - це діаграма розгортання ( розміщення ) .

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

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

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

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

Вузол

Вузол ( node ) являє собою фізично існуючий елемент системи , який може володіти обчислювальним ресурсом або бути технічним пристроєм .В якості обчислювального ресурсу вузла може розглядатися один або кілька процесорів , а також обсяг електронної або магнитооптической пам'яті. Однак у мові UML поняття вузла включає в себе не тільки обчислювальні пристрої ( процесори ) , а й інші механічні або електронні пристрої, такі як датчики , принтери , модеми , цифрові камери , сканери і маніпулятори. Графічно вузол на діаграмі розгортання зображується у формі тривимірного куба. Вузол має ім'я , яке вказується всередині цього графічного символу. Самі вузли можуть представлятися як на рівні типу ( рис. 13.1 , а ) , так і на рівні примірника (рис. 13.1 , б).

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

У першому випадку ім'я вузла записується у формі: <Ім'я типу вузла > без підкреслення і починається з великої літери. У другому - ім'я вузла - екземпляра записується у вигляді : <ім'я вузла ':' Ім'я типу вузла > , а вся запис підкреслюється. Ім'я типу вузла вказує на різновид вузлів , присутніх в моделі системи . Так , на представленому малюнку (рис. 13.1 , а ) вузол з ім'ям Відеокамера відноситься до загального типу і ніяк не конкретизується . Другий вузол ( рис. 13.1 , б) є вузлом - екземпляром конкретної моделі сканера. Зображення вузлів можуть розширюватися , щоб включити додаткову інформацію про специфікації вузла. Якщо додаткова інформація відноситься до імені вузла , то вона записується під цим ім'ям у формі поміченого значення ( рис. 13.2 ) .

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

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

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

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

Як доповнення до імені вузла можуть використовуватися різні текстові стереотипи , які явно специфікують призначення цього вузла. Для цієї мети було запропоновано такі текстові стереотипи : " processor " (процесор) , " sensor " ( датчик ) , " modem " ( модем) , " net " (мережа ) , " printer " (принтер ) та інші , зміст яких зрозумілий з контексту.

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

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

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

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

З'єднання і залежності на діаграмі розгортання

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Патерни , їх класифікація

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

• архітектурні патерни    

• патерни проектування    

• патерни аналізу    

• патерни тестування    

• патерни реалізації

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

Архітектурні патерни призначені для специфікації фундаментальних схем структуризації програмних систем . Найбільш відомими патернами цієї категорії є патерни GRASP ( General Responsibility Assignment Software Pattern ) . Ці патерни ставляться до рівня системи і підсистем , але не до рівня класів . Як правило , формулюються в узагальненій формі , використовують звичайну термінологію і не залежать від області додатка . Патерни цієї категорії систематизував і описав К. Ларман .

Патерни проектування ( Design patterns ) - спеціальні схеми для уточнення структури підсистем або компонентів програмної системи і відносин між ними.

Патерни проектування описують загальну структуру взаємодії елементів програмної системи , які реалізують вихідну проблему проектування в конкретному контексті. Найбільш відомими патернами цієї категорії є патерни GoF ( Gang of Four ) , названі на честь Е. Гамми , Р. Хелма , Р. Джонсона і Дж. Вліссідес ​​, які систематизували їх і представили загальний опис . Патерни GoF включають в себе 23 патерну . Ці патерни не залежать від мови реалізації , але їх реалізація залежить від області додатка

Патерни аналізу ( Analysis patterns ) - спеціальні схеми для представлення загальної організації процесу моделювання .Патерни аналізу відносяться до однієї або декількох предметних областях і описуються в термінах предметної області. Найбільш відомими патернами цієї групи є патерни бізнес-моделювання ARIS ( Architecture of Integrated Information Systems ), які характеризують абстрактний рівень представлення бізнес -процесів. Надалі патерни аналізу конкретизуються в типових моделях з метою виконання аналітичних оцінок або імітаційного моделювання бізнес -процесів.

Патерни тестування ( Test patterns ) - спеціальні схеми для представлення загальної організації процесу тестування програмних систем .До цієї категорії патернів відносяться такі патерни , як тестування чорного ящика , білого ящика , окремих класів , системи . Патерни цієї категорії систематизував і описав М. Гранд . Деякі з них реалізовані в інструментальних засобах , найбільш відомими з яких є IBM Test Studio . У зв'язку з цим патерни тестування іноді називають стратегіями або схемами тестування.

Патерни реалізації ( Implementation patterns ) - сукупність компонентів та інших елементів реалізації , що використовуються в структурі моделі при написанні програмного коду. Ця категорія патернів ділиться на наступні підкатегорії : патерни організації програмного коду , патерни оптимізації програмного коду , патерни стійкості коду , патерни розробки графічного інтерфейсу користувача та ін Паттерни цієї категорії описані в роботах М. Гранда , К. Бека , Дж. Тідвелл та ін деякі з них реалізовані в популярних інтегрованих середовищах програмування у формі шаблонів створюваних проектів . У цьому випадку вибір шаблону програмного додатка дозволяє отримати деяку заготовку програмного коду.

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

Рис . 14.1 . Зображення патерну у формі параметризрвані кооперації

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

Таблица 14.1. Повний список патернів проектування GoF
№	Назва патерну	Переклад	Призначення патерну
1	Abstract Factory	Абстрактна фабрика	Надає інтерфейс для створення безлічі пов'язаних між собою або незалежних об'єктів , конкретні класи яких невідомі.
2	Adapter(синоним - Wrapper)	Адаптер (Обгортка)	Перетворює існуючий інтерфейс класу в інший інтерфейс , який зрозумілий клієнтам . При цьому забезпечує спільну роботу класів , неможливу без даного патерну через несумісність інтерфейсів.
3	Bridge	Міст	Відокремлює абстракцію класу від його реалізації , завдяки чому з'являється можливість незалежно змінювати те й інше.
4	Builder	Будівельник	Відокремлює створення складного об'єкта від його уявлення , дозволяючи використовувати один і той же процес розробки для створення різних уявлень .
5	Chain of Responsibility	Ланцюжок обовязків	Дозволяє уникнути жорсткої залежності відправника запиту від його одержувача , при цьому об'єкти - одержувачі зв'язуються в ланцюжок , а запит передається по ланцюжку , поки якийсь об'єкт його не оброблені .
6	Command	Команда	Інкапсулює запит у вигляді об'єкта , забезпечуючи параметризацію клієнтів типом запиту , встановлення черговості запитів , протоколювання запитів і скасування виконання операцій .
7	Composite	Компонувальник (збирач)	Групує об'єкти в ієрархічні структури для представлення відносин типу " частина - ціле" , що дозволяє клієнтам працювати з одиничними об'єктами так само, як з групами об'єктів.
8	Decorator	Декоратор	Застосовується для розширення наявної функціональності і є альтернативою породженню підкласів на основі динамічного призначення об'єктам нових операцій .
9	Facade	Фасад	Надає єдиний інтерфейс до безлічі операцій або інтерфейсів в системі на основі уніфікованого інтерфейсу для полегшення роботи з системою..
10	Factory Method	Фабричний метод	Визначає інтерфейс для розробки об'єктів , при цьому об'єкти даного класу можуть бути створені його підкласами
11	Flyweight	Пристосуванець	Використовує принцип поділу для ефективної підтримки великого числа дрібних об'єктів..
12	Interpreter	Інтерпретатор	Для заданої мови визначає подання його граматики на основі інтерпретатора пропозицій мови , що використовує це подання
13	Iterator	Ітератор	Дає можливість послідовно перебрати всі елементи складеного об'єкта , не розкриваючи його внутрішнього представлення .
14	Mediator	Посередник	Визначає об'єкт , в якому інкапсульоване знання про те , як взаємодіють об'єкти з деякої безлічі . Сприяє зменшенню числа зв'язків між об'єктами , дозволяючи їм працювати без явних посилань один на одного і незалежно змінювати схему взаємодії .
15	Memento	Зберігач	Дає можливість отримати і зберегти в зовнішній пам'яті внутрішній стан об'єкта , щоб пізніше об'єкт можна було відновити точно в такому ж стані , не порушуючи принципу інкапсуляції .
16	Observer	Спостерігач	Специфікує залежність типу " один до багатьох" між різними об'єктами , так що при зміні стану одного об'єкта всі залежні від нього отримують повідомлення і автоматично оновлюються.
17	Prototype	Прототип	Описує види створюваних об'єктів за допомогою прототипу , що дозволяє створювати нові об'єкти шляхом копіювання цього прототипу ..
18	Proxy	Замісник	Підміняє вибраний об'єкт іншим об'єктом для управління контролю доступу до вихідного об'єкту
19	Singleton	Одинак	Для обраного класу забезпечує виконання вимоги єдиності екземпляра і надання до нього повного доступу .
20	State	Стан	Дозволяє вибраному об'єкту варіювати свою поведінку при зміні внутрішнього стану. При цьому створюється враження , що змінився клас об'єкта.
21	Strategy	Стратегія	Визначає безліч алгоритмів , інкапсуліруя їх всі і дозволяючи підставляти один замість іншого . При цьому можна змінювати алгоритм незалежно від клієнта , який ним користується.
22	Template Method	Шаблоний метод	Визначає структуру алгоритму , перерозподіляючи відповідальність за деякі його кроки на підкласи . При цьому підкласи можуть перевизначати кроки алгоритму , не змінюючи його загальної структури
23	Visitor	Відвідувач	Дозволяє визначити нову операцію , не змінюючи описів класів , у об'єктів яких вона викликається

Як приклади розглядаються два патерну проектування , які знайшли найбільше застосування при проектуванні програмних систем : патерни Фасад і Спостерігач ...

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

Рис . 14.2 . Загальне уявлення патерну проектування Фасад

Зображена параметрезованих кооперація містить 4 параметра : клас Facade ( Фасад ), інтерфейс IFacade , інтерфейси IConcreteClass і конкретні класи ConcreteClass , в яких реалізовані інтерфейси IConcreteClass . Пунктирна лінія зі стрілкою у формі трикутника служить для позначення відношення реалізації ( не плутати з відношенням узагальнення класів).При вирішенні конкретних завдань проектування даний патерн може бути конкретизований . У цьому випадку замість параметрів зображеної кооперації повинні бути зазначені класи , призначені для вирішення окремих завдань.Нижче наведено приклад , який ілюструє використання патерну Фасад для виконання операцій за завданням і зчитуванню адрес з бази даних співробітників. Частковий відповідної діаграми класів містить 2 класу : Адреса і інтерфейс до операцій цього класу IАдрес (рис. 14.3) . При завданні адреси нового співробітника необхідно звернутися до цього інтерфейсу і послідовно виконати операції : задатьУліцу ( ) , задатьДом ( ) , задатьКорпус ( ) , задатьКвартіру ( ) , використовуючи як аргумент ідентифікаційний номер нового співробітника. Для отримання інформації про адресу співробітника , необхідно також звернутися до цього інтерфейсу і послідовно виконати операції : прочітатьУліцу ( ) , прочітатьДом ( ) , прочітатьКорпус ( ) , прочітатьКвартіру ( ) , використовуючи як аргумент ідентифікаційний номер цікавить співробітника .

Рис. 14.3. Фрагмент диаграммы классов до применения паттерна Фасад

Очевидно, відстежувати при кожному зверненні правильність виконання цих послідовностей операцій незручно. З цією метою до даного фрагменту слід додати ще один інтерфейс, реалізацію патерну Фасад для ситуації, що розглядається. Відповідний фрагмент модифікованої діаграми класів буде містити 4 класу (рис. 14.4), зображені таким чином, щоб ілюструвати реалізацію параметричної кооперації (рис. 14.2).

Рис . 14.4 . Конкретна реалізація патерну проектування Фасад

При завданні адреси нового співробітника в цьому випадку досить звернутися до інтерфейсу IФасад і виконати єдину операцію : задатьАдрес ( ) , використовуючи як аргумент ідентифікаційний номер нового співробітника. Для отримання інформації про адресу співробітника також досить звернутися до цього інтерфейсу і виконати єдину операцію : прочитатиАдресу ( ) , використовуючи як аргумент ідентифікаційний номер цікавить співробітника . Реалізацію даних операцій слід передбачити в класі Фасад . Взаємодія об'єктів цих класів може бути представлено за допомогою діаграми послідовності (рис. 14.5 ) .

Рис . 14.5 . Діаграма послідовності для виконання операції завдання адреси

Аналогічна діаграма послідовності може бути побудована для виконання операції з читання адреси. Використання патерну Фасад забезпечує для клієнта не тільки простоту доступу до інформації про адреси , але і незалежність представлення об'єктів класу Адреса від запитів клієнтів. Ця обставина особливо актуально при зміні формату представлення інформації або зміні відповідної бази даних. У цьому випадку буде потрібно внести зміни тільки в реалізацію операцій класу Фасад .Патерн Спостерігач і його позначення в нотації мови UMLПатерн Спостерігач призначений для контролю змін стану об'єкта та передачі інформації про зміну цього стану безлічі клієнтів. У загальному випадку патерн Спостерігач також може бути зображений у вигляді параметризованих кооперації (рис. 14.6 ) .

Рис . 14.6 . Загальне уявлення патерну проектування Спостерігач

Зображена параметрезованих кооперація містить 4 параметра : абстрактний клас Subject ( Суб'єкт ), клас ConcreteSubject ( Конкретний Суб'єкт ) , абстрактний клас Observer ( Спостерігач ) і клас ConcreteObserver ( Конкретний Спостерігач ) . Пунктирна лінія зі стрілкою у формі трикутника служить для позначення відношення узагальнення класів .При вирішенні конкретних завдань проектування даний патерн також може бути конкретизований . У цьому випадку замість параметрів зображеної кооперації повинні бути зазначені класи , призначені для вирішення окремих завдань.Тепер можна розглянути приклад , який ілюструє використання патерну Спостерігач для відстеження змін в таблиці БД і відображенні цих змін на діаграмах. Для визначеності можна використовувати таблицю БД MS Access і дві діаграми - кругову і Стовпчикові . Частковий відповідної діаграми класів містить 5 класів ( рис. 14.7 ) .

Рис . 14.7 . Конкретна реалізація патерну проектування Спостерігач

У цьому випадку за суб'єктом Таблицею MS Access може "стежити " довільне число спостерігачів , причому їх додавання або видалення не впливає на подання інформації в БД. Клас Таблиця MS Access реалізує операції з відстеження змін у відповідній таблиці , і при їх наявності відразу інформує абстрактного спостерігача. Той у свою чергу викликає операції з перемальовуванні відповідних діаграм у конкретних спостерігачів , в якості яких виступають класи Кругова Діаграма і Столбиковая Діаграма .Використання патерну Спостерігач не тільки спрощує взаємодію між об'єктами відповідних класів , але і дозволяє вносити зміни в реалізацію операцій класів суб'єкта і спостерігачів незалежно один від одного. При цьому процес додавання або видалення спостерігачів ніяк не впливає на особливості реалізації класу суб'єкта