Слайд 1ЛК.14 - Аналіз і моделювання компонентів
Слайд 2Загальна характеристика фізичних моделей у UML.
Місце діаграм компонентів у
загальному процесі ОО аналізу і проектування.
Визначення діаграми компонентів.
Представлення
діаграм компонентів у UML.
Основні елементи діаграми компонентів.
Компоненти.
Інтерфейси
Залежності між компонентами.
Рекомендації по побудові діаграми компонентів
Перелік питань
Слайд 3Питання 1. Загальна характеристика фізичних моделей у UML
Логічні моделі відображають
концептуальні та логічні моделі системи, оперують поняттями, які не мають
матеріальної реалізації.
Реалізація логічної моделі передбачає перетворення усіх елементів системи в конкретні фізичні сутності.
Фізичні моделі (діаграми реалізації) відображають реально існуючий прототип моделі системи.
Фізична реалізація моделі передбачає розподіл її на модулі, файли, реалізацію графічних інтерфейсів, взаємодію із СУБД та ін.
Слайд 4Типи фізичних діаграм
UML передбачає два типи діаграм реалізації:
Діаграми компонентів –
використовується для опису фізичного представлення системи, визначення її архітектури і
залежностей між програмними компонентами
Діаграми розгортання – використовується для представлення загальної конфігурації і топології розподіленої програмної системи та містить зображення фізичних зв’язків – маршрутів передачі інформації між пристроями, які задіяні в реалізації системи
Слайд 5Питання 2. Місце діаграм компонентів у загальному процесі ОО аналізу
і проектування
Діаграми прецедентів
Концептуальні діаграми
Діаграми послідовностей
Діаграми співробіт-ництва
Вимоги
Діаграми класів
Діаграми
стану
Діаграми
компонентів
Слайд 6Питання 3. Визначення діаграми компонентів
Діаграма компонентів – діаграма UML, яка
описує особливості фізичного представлення системи, дозволяє визначити архітектуру системи, встановити
залежності між програмними компонентами, в ролі яких може виступати вихідний та бінарний код.
В розробці діаграм компонентів приймають участь як системні аналітики і архітектори, так і програмісти.
Діаграма компонентів забезпечує узгоджений перехід від логічного представлення до конкретної реалізації проекту у формі програмного коду.
Одні компоненти можуть існувати лише на етапі компіляції коду, інші – на етапі його виконання.
Діаграма компонентів відображає загальні залежності між компонентами.
Слайд 7Питання 4. Представлення діаграм компонентів у UML
Для представлення діаграм компонентів
у UML використовуються спеціальні елементи:
Слайд 8Приклад діаграми компонентів
Слайд 9Питання 5. Основні елементи діаграми компонентів
Основні елементи:
Компонент
Зв’язок між компонентами
Стереотип
Слайд 10Питання 6. Компоненти
Компонент – частина системи, яка існує фізично і
забезпечує реалізацію класів та відносин та функціональну поведінку системи, що
моделюється
Компонент призначений для представлення фізичної організації асоційованих з ним елементів моделі. Додатково компонент може мати текстовий стереотип, а окремі – власне графічне представлення.
Компонентом може бути бінарний код певного модуля, командні файли, файли, які містять код, що інтерпретується та ін.
Компонент слугує для загального позначення елементів фізичного представлення моделі та може реалізовувати певний набір інтерфейсів.
Слайд 11Приклад графічного представлення компоненту
Графічне представлення компоненту бере своє походження від
модуля програми, який використовувався у структурному підході для інкапсуляції даних
та процедур
Модуль – частина програмної системи, яка вимагає пам’яті для свого зберігання та ресурсів процесору для виконання
На рис а. – зазначено ім’я типу, на рис. б – ім’я екземпляру
Слайд 12Графічні стереотипи компонентів
а) – бібліотеки
б) – Web-сторінки на HTML
в) –
файли довідки
г) – файли з вихідними текстами програм
Слайд 13Текстові стереотипи компонентів
“file” – найбільш загальна різновидність компоненту у вигляді
довільного файлу
“executable” – різновидність файлу, який може виконуватися на комп’ютерній
платформі
“document” – документ, який містить певну інформацію
“library” – бібліотека бінарного коду
“source” – файл з вихідним текстом програми
“table” – таблиця БД
Слайд 14Питання 7. Інтерфейси
На діаграмі компонентів зображуються інтерфейси, з якими взаємодіють,
або які реалізують компоненти
Якщо компоненті реалізує певний інтерфейс, то він
має назву експортований інтерфейс – зображується за допомогою позначення інтерфейсу
Якщо компонент використовує певний інтерфейс, то він має назву імпортований інтерфейс – зображується за допомогою залежності
Слайд 15Питання 8. Залежності між компонентами
Компонент Control залежить від імпортованого інтерфейсу
IDialog, який , в свою чергу, реалізується компонентом Database
Слайд 16Відношення програмного виклику та компіляції між різними типами компонентів
Слайд 17Представлення залежності між компонентами та класами
Слайд 18Позначення реалізації класів певним компонентом
Слайд 19Питання 9. Рекомендації по побудові діаграми компонентів
Спочатку необхідно визначити, із
яких частин чи файлів буде складатися програмна система. Слід враховувати
таку реалізацію системи, яка б передбачала можливість повторного використання коду за рахунок раціональної декомпозиції компонентів
Загальна продуктивність програмної системи залежить від раціонального використання програмних ресурсів. Слід створювати лише ті екземпляри класів, які потрібні у конкретний момент часу, а саму систему доцільно розподілити на окремі бібліотеки, які слід завантажувати по необхідності
В процесі структуризації фізичного представлення системи необхідно доповнити модель інтерфейсами та схемами бази даних. Під час розробки інтерфейсів слід звертати увагу на узгодженість різних частин програмної системи
