Діаграми компонентів

Размещено на http://www.allbest.ru/

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

КИЇВСЬКИЙ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ

БУДІВНИЦТВА І АРХІТЕКТУРИ

Кафедра інформаційних технологій проектування та прикладної математики

Розрахунково-графічна робота

з теми: діаграми компонентів

Студент групи ІУСТ-21

Хланя В.М.

Перевірив викладач:

Терейковська Л. О.

Київ-2016

Діаграми компонентів компонент графічний діаграма

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

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

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

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

1) Компоненти

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

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

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

Размещено на http://www.allbest.ru/

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

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

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

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

Як власні імена компонентів прийнято використовувати імена файлів або блоків апаратури.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2) Інтерфейси

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

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

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

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

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

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

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

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

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

Рис. 4. Відношення залежності і реалізації

Іншим випадком відношення залежності на діаграмі компонентів є відношення програмного виклику і компіляції між різними видами компонентів. Для фрагмента діаграми компонентів на рис. 5 наявність подібної залежності означає, що виконуваний компонент Control.exe використовує або імпортує деяку функціональність компонента Library.dll, викликає сторінку гіпертексту Home.html і файл допомоги Search.hlp, а вихідний текст цього виконуваного компонента зберігається у файлі Control.cpp. При цьому характер окремих видів залежностей може бути відмічений додатково за допомогою текстових стереотипів.

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

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

Размещено на http://www.allbest.ru/

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

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

Размещено на http://www.allbest.ru/

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

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

Размещено на http://www.allbest.ru/

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

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

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

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

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

3. Приклад розробки діаграми компонентів

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

Рис. 9. Приклад діаграми компонентів програмного забезпечення інформаційної технології

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

Список використаної літератури

Леонков А.В.Самоучитель UML. СП б.: БХВ-Петербург, 2001. - 304 с.

Боггс Ч., Боггс М. UML Rational. - M.: ЛОРИ, 2000;

Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования - М.:Мир, 1999. - 191 с.

Размещено на Allbest.ru