Презентация: ЛК.14 - Аналіз і моделювання компонентів

ЛК.14 - Аналіз і моделювання компонентів Перелік питань Питання 1. Загальна характеристика фізичних моделей у UML Типи фізичних діаграм Питання 2. Місце діаграм компонентів у загальному процесі ОО аналізу і проектування Питання 3. Визначення діаграми компонентів Питання 4. Представлення діаграм компонентів у UML Приклад діаграми компонентів Питання 5. Основні елементи діаграми компонентів Питання 6. Компоненти Приклад графічного представлення компоненту Графічні стереотипи компонентів Текстові стереотипи компонентів Питання 7. Інтерфейси Питання 8. Залежності між компонентами Відношення програмного виклику та компіляції між різними типами компонентів Представлення залежності між компонентами та класами Позначення реалізації класів певним компонентом Питання 9. Рекомендації по побудові діаграми компонентів ЛК.14 - Аналіз і моделювання компонентів ЛК.14 - Аналіз і моделювання компонентів ЛК.14 - Аналіз і моделювання компонентів ЛК.14 - Аналіз і моделювання компонентів
1/23
Средняя оценка: 4.2/5 (всего оценок: 84)
Скачать (295 Кб)
Код скопирован в буфер обмена
1

Первый слайд презентации: ЛК.14 - Аналіз і моделювання компонентів

2

Слайд 2: Перелік питань

Загальна характеристика фізичних моделей у UML. Місце діаграм компонентів у загальному процесі ОО аналізу і проектування. Визначення діаграми компонентів. Представлення діаграм компонентів у UML. Основні елементи діаграми компонентів. Компоненти. Інтерфейси Залежності між компонентами. Рекомендації по побудові діаграми компонентів Перелік питань

3

Слайд 3: Питання 1. Загальна характеристика фізичних моделей у UML

Логічні моделі відображають концептуальні та логічні моделі системи, оперують поняттями, які не мають матеріальної реалізації. Реалізація логічної моделі передбачає перетворення усіх елементів системи в конкретні фізичні сутності. Фізичні моделі (діаграми реалізації) відображають реально існуючий прототип моделі системи. Фізична реалізація моделі передбачає розподіл її на модулі, файли, реалізацію графічних інтерфейсів, взаємодію із СУБД та ін.

4

Слайд 4: Типи фізичних діаграм

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

5

Слайд 5: Питання 2. Місце діаграм компонентів у загальному процесі ОО аналізу і проектування

Діаграми прецедентів Концептуальні діаграми Діаграми послідовностей Діаграми співробіт-ництва Вимоги Діаграми класів Діаграми стану Діаграми компонентів

6

Слайд 6: Питання 3. Визначення діаграми компонентів

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

7

Слайд 7: Питання 4. Представлення діаграм компонентів у UML

Для представлення діаграм компонентів у UML використовуються спеціальні елементи:

8

Слайд 8: Приклад діаграми компонентів

9

Слайд 9: Питання 5. Основні елементи діаграми компонентів

Основні елементи: Компонент Зв ’ язок між компонентами Стереотип

10

Слайд 10: Питання 6. Компоненти

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

11

Слайд 11: Приклад графічного представлення компоненту

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

12

Слайд 12: Графічні стереотипи компонентів

а) – бібліотеки б) – Web- сторінки на HTML в) – файли довідки г) – файли з вихідними текстами програм

13

Слайд 13: Текстові стереотипи компонентів

“file” – найбільш загальна різновидність компоненту у вигляді довільного файлу “executable” – різновидність файлу, який може виконуватися на комп ’ ютерній платформі “ document ” – документ, який містить певну інформацію “ library ” – бібліотека бінарного коду “ source ” – файл з вихідним текстом програми “ table ” – таблиця БД

14

Слайд 14: Питання 7. Інтерфейси

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

15

Слайд 15: Питання 8. Залежності між компонентами

Компонент Control залежить від імпортованого інтерфейсу IDialog, який, в свою чергу, реалізується компонентом Database

16

Слайд 16: Відношення програмного виклику та компіляції між різними типами компонентів

17

Слайд 17: Представлення залежності між компонентами та класами

18

Слайд 18: Позначення реалізації класів певним компонентом

19

Слайд 19: Питання 9. Рекомендації по побудові діаграми компонентів

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

20

Слайд 20

21

Слайд 21

22

Слайд 22

23

Последний слайд презентации

Похожие презентации

Ничего не найдено