Лабораторна робота №7

Діаграма компонентів (Component Diagram) 

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

Теоретичні відомості

Щоб пояснити відмінність логічного і фізичного подань, розглянемо у загальних рисах процес розроблення деякої програмної системи. Її початковим логічним поданням можуть служити структурні схеми алгоритмів і процедур, описи інтерфейсів і концептуальні схеми баз даних. Проте для реалізації цієї системи необхідно розробити початковий текст програми на деякій мові програмування (C++, Pascal, Basic/VBA, Java). При цьому вже в тексті програми передбачається така організація програмних кодів, яка припускає її розбиття на окремі модулі.

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

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

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

Діаграма компонентів розробляється для таких цілей:

• візуалізації загальної структури початкового коду програмної системи;

• специфікації здійснимого варіанту програмної системи;

• забезпечення багатократного використання окремих фраґментів програмних кодів;

• подання концептуальної і фізичної схем баз даних.

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

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

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

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

В першому випадку (рис. 7.1, а) з компонентом рівня екземпляра зв'язується тільки його ім'я, а в другому (рис. 7.1, б) – додаткове ім'я пакету і позначене міткою значення.

У мові UML для компонентів визначені такі стереотипи:

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

• таблиця (table) – також визначає перший різновид компонента, який подається у формі таблиці бази даних;

• файл (file) – визначає другий різновид компонента, який подається у вигляді файлів з початковими текстами програм;

• документ (document) – визначає другий різновид компонента, який подається у формі документу;

• викональний (executable) – визначає третій вид компонента, який може виконуватися у вузлі.

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

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

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

Іншим способом подання інтерфейсу на діаграмі компонентів є його зображення у вигляді прямокутника класу і з стереотипом "інтерфейс" і можливими секціями атрибутів і операцій (рис. 7.2, б). Як правило, цей варіант позначення використовується для подання внутрішньої структури інтерфейсу, яка може бути важлива для реалізації.

3. Залежності

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

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

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

Рис. 7.3. Фраґмент діаграми компонентів з відношенням залежності.

Іншим випадком відношення залежності на діаграмі компонентів є відношення між різними видами компонентів (рис. 7.4). Наявність подібної залежності означає, що внесення змін до початкових текстів програм або динамічних бібліотек приводить до змін самого компонента. При цьому характер змін може бути відзначений додатково. 

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

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

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

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

Хід роботи

1. Ознайомитися з теоретичними відомостями.

2. Побудувати відповідну діаграму за допомогою UML згідно до своєї предметної області.

3. Оформити звіт за результатами лабораторної роботи.

Зміст звіту

1. Мета роботи

2. Короткі теоретичні відомості.

3. Хід роботи.

4. Висновки.

З повагою ІЦ "KURSOVIKS"!