10 Lectures PDF

1
“Документування програмного забезпечення

та шаблони проектування”
Архітектура програмного
забезпечення

та шаблони проектування” © Іванюк О.О., КСА, НУЛП, 2019
2
Мета і результати вивчення дисципліни
Метою викладання дисципліни є отримання необхідних знань про основні

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

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

© Іванюк О.О., КСА, НУЛП, 2019
3
Розвиток галузі розробки ПЗ
• Індустрія ПЗ почала зароджуватися в середині 50-х років XIX ст., Проте
майже до кінця 60-х їй не приділялося серйозної уваги, оскільки її
частка в комп'ютерному бізнесі була занадто мала.
• У 1970 р річний оборот всіх фірм-розробників ПЗ в США не
перевищував 1/2 млрд дол. - близько 3,7% всього обороту
комп'ютерного бізнесу.
• Серйозне зростання почалося в 70-х роках XX ст., Починаючи з
прийнятого фірмою IBM в 1969 р рішення про розв'язування цін
(окремому призначенні цін на апаратуру, програмне забезпечення та
послуги), і продовжилося до кінця декади і появи персонального
комп'ютера.
• До 1979 р річний обсяг продаж фірм-розробників ПЗ в США становив
близько $ 2 млрд.
• У 80-х роках зростання становило 20% в рік і більше, таким чином, річні
доходи фірм виросли до $ 10 млрд. до 1982 р і $ 25 млрд. до 1985 р
• Сьогодні загальний обсяг продажів ПЗ перевищує $ 100 млрд.
• Виробництво ПЗ сьогодні - найбільша галузь світової економіки, в якій
зайнято близько трьох мільйонів фахівців, які називають себе
програмістами, розробниками ПЗ і т.п.
4
Важливість архітектури
Шведський король бажав мати добре
озброєний, найбільший галеон (70м) на
Балтиці зі струнким профілем, з багато
декорованими високими надбудовами,
особисто затверджуючи його розміри,
озброєння. Корабели виконали
бажання короля, і галеон вийшов
занадто вузьким з надто високими
надбудовами на кормі та щоглами з
поганою стійкістю.
Приблизно через кілька кілометрів від старту від чергового різкого подмуху
вітру корабель нахилився на ліву сторону і, зачерпнувши води через відкриті
артилерійські порти, перевернувся на борт. До прибуття допомоги з інших
кораблів Стокгольма галеон затонув з піднятими вітрилами на глибині 32 м.
Загинуло за різними даними від 50 до 400 осіб.
Було встановлено, що причиною катастрофи стали прорахунки
при проектуванні корабля.
Термін “архітектура” 5
Архітектура: «Мистецтво або наука будівництва; перш за все,

мистецтво і практика проектування і будівництва будівель,
призначених для використання людиною, з урахуванням
естетичних і практичних чинників».
Короткий Оксфордський словник англійської мови, 5-е видання,
2002
Архітектура програми або комп'ютерної системи - це структура або

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

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

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

8
Вплив на архітектуру чинять досвід і звички
архітекторів
• Позитивний досвід - повторення його в наступних роботах.
• Негативний досвід - відмова використовувати його в

наступних роботах.
• Архітектори люблять експериментувати з новими

зразками (pattern) і методиками.

9
Вплив на архітектуру чинить технічна база
Підготовка та досвід архітектора виявляється, зокрема, в

його роботі з технічною базою (technical environment).
До технічної бази можна віднести:
• методи роботи, прийняті в даній галузі
• прийоми програмної інженерії, поширені в
професійному співтоваристві, в яке входить архітектор.

10
Варіативність чинників впливу на
архітектуру

11
Архітектура чинить зворотню дію на
фактори впливу

12
Програмний процес (software process) і
архітектурно-економічний цикл
• створення економічної моделі системи;

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

13
Будівельні елементи архітектури ПЗ -
компонент
Компонент - абстрактна одиниця інструкцій

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

14
Будівельні елементи архітектури ПЗ -
конектор
Конектор - абстрактний механізм, що слугує

посередником в комунікації, координації або
кооперації між компонентами.

15
Будівельні елементи архітектури ПЗ - дані
Дані - елемент інформації, що передається від

одного компонента або отримується від іншого
компонента через конектор.

16
Приклад архітектурного опису

17
Архітектурні зразки, еталонні моделі та
еталонні варіанти архітектури
• Архітектурний зразок – це опис типів елементів і відношень і викладення ряду

обмежень на їх використання.
• Еталонна модель – це розділення між окремими блоками функціональних
можливостей і потоків даних.
• Еталонна архітектура – це еталонна модель відображена на програмні
елементи і потоки даних між ними.

18
Чому програмна архітектура є такою
важливою?
1) Взаємодія між зацікавленими особами. Програмна
архітектура – це така універсальна абстракція системи, на основі
якої всі або майже всі зацікавлені в системі особи можуть шукати
порозуміння, вести перемовини, знаходити компроміси чи просто
спілкуватися.
2) Початкові проектні рішення. Програмна архітектура містить
відомості про те, які рішення були прийняті на ранніх етапах
розробки системи. Аналіз проектних рішень, які визначають
подальшу розробку системи.
3) Мобільна абстракція системи. Програмна архітектура
володіє властивістю переміщення із системи в систему.

19
Критерії якісної архітектури
Ефективність системи. В першу чергу програма, звичайно ж, повинна вирішувати
поставлені завдання і добре виконувати свої функції, причому в різних умовах.
Гнучкість системи. Швидка і зручна зміна існуючого функціоналу.
Можливість розширення системи. Можливість додавати в систему нові сутності
та функції, не порушуючи її основної структури.
Масштабованість процесу розробки. Можливість скоротити термін розробки за
рахунок додавання до проекту нових людей. Архітектура повинна дозволяти
розпаралелити процес розробки, так щоб багато людей могли працювати над
програмою одночасно.
Тестованість. Код, який легше тестувати, буде містити менше помилок і
надійніше працювати.
Можливість повторного використання. Систему бажано проектувати так, щоб її
фрагменти можна було повторно використовувати в інших системах.
Добре структурований, читабельний і зрозумілий код. Супровід коду.
Над програмою, як правило, працює багато людей - одні йдуть, приходять нові.
Тому хороша архітектура повинна давати можливість відносно легко і швидко
розібратися в системі нових людей.

20
Критерії не якісної архітектури
1. Її важко змінити, оскільки будь-яка зміна впливає на занадто велику

кількість інших частин системи. (Жорсткість, Rigidity).
2. При внесенні змін несподівано ламаються інші частини системи.

(Крихкість, Fragility).
3. Код важко використовувати повторно в іншому додатку, оскільки його

занадто важко «виплутати» з поточної програми. (Нерухомість, Immobility).

21
Архітектурні стилі

22
Архітектурні стилі
Архітектурний стиль, іноді називають архітектурним шаблоном

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

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

23
Класифікація архітектурних стилів
Прийнято виділяти 12 базових архітектурних стилів, які діляться

на 5 груп:
1. Потоки даних (Data Flow Systems);
2. Виклик з поверненням (Call-and-Return Systems);
3. Незалежні компоненти (Independent Component Systems);
4. Централізовані дані (Data-Centric Systems);
5. Віртуальні машини (Virtual Machines).

24
1. Потоки даних
До систем, що працюють за принципом потоків даних,

відносять системи двох архітектурних стилів:
• системи пакетно-послідовної обробки (Batch
Sequential Systems)
• системи типу канали і фільтри (Pipe and Filter
Architecture).

25
Системи типу канали і фільтри (Pipe and
Filter Architecture)
Архітектурний опис будується як (або є) зв'язна сукупність фільтрів

і каналів, в якій:
• фільтр - незалежний блок, який одержує на вхід потік(и) даних і
видає потік(и) даних
• можлива досить проста переконфігурація системи фільтрів
(з'єднання їх за допомогою pipes)
• фільтри працюють паралельно

2. Системи, що працюють по принципу 26
виклику з поверненням
До них зазвичай відносять системи, побудовані за принципом
• програма-співпрограми (Main Program and Subroutines)
• клієнт-серверні системи (Client-Server Systems)
• об'єктно-орієнтовані системи (Object-Oriented Systems)
• ієрархічні багаторівневі системи (Hierarchically Layered Systems)

27
Клієнт-серверний стиль
Для розподілених систем типовий випадок застосування

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

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

3. Системи, що працюють за принципом 29
незалежних компонентів
• системи взаємодіючих процесів (Communicating Sequential
Processes)
• системи, керовані подіями (Event-Based-Systems)
У найзагальнішому вигляді ідея взаємодіючих процесів полягає в

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

30
Стиль систем, керованих подіями
Цей стиль використовується для композиції додатків, які

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

31
4. Централізовані дані (репозитарії)
• Системи засновані на використанні бази даних
(Database Systems)
• Системи, що використовують принцип класної дошки

(Blackboard system)

32
5. Віртуальні машини
• Інтерпретатори (Interpreters)
• системи, засновані на правилах (Rule-Based-Systems)
Віртуальна машина являє собою емулятор, який працює поверх

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

33
Документування ПЗ

34
Визначення
Документування - процедура, яка фіксує план, процес і

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

35
Документування архітектури ПЗ
Методи документування ПЗ дуже різноманітні і кожен з

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

36
Для чого потрібно документувати архітектуру?
1. Документація забезпечує «спільний простір» проекту. Будь-який
учасник в будь-який момент часу може отримати необхідну інформацію
як по конкретному завданні, так і по загальному напрямку роботи.
2. Команда говорить «на одній мові» - адже набагато простіше зрозуміти
людину, яка звітує «про помилку в функції, описаній в Use Case №12»,
ніж «про стрьомному базі в тій фігні, яку Вася місяць тому робив».
3. Документування дозволяє чітко розмежувати зони відповідальності
між учасниками проекту.
4. Тільки ретельно описані вимоги можуть бути перевірені на повноту і
несуперечність. «Наколінні записки» - прямий і дуже швидкий шлях до
того, що межі проекту розповзуться жвавими тарганами, а функціонал,
задуманий спочатку, не буде монтуватися з виникаючими в процесі
забаганками замовника.

37
Типи документації на ПЗ
Існує чотири основних типи документації на ПЗ:

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

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

39
Принципи розробки якісної документації
Створення документації для ПЗ може регулюватися різними
системами стандартів ISO, корпоративними стандартами,
галузевими стандартами тощо.
Стандартом зазвичай визначаються:
• Модель життєвого циклу програмного засобу
• Склад документів, які створюються на кожній стадії
• Склад і структура кожного із документів.
При розробці технічної документації враховуються вимоги 2-х видів:

• Загальні вимоги – орфографічна і стилістична грамотність,
мінімальна технічна культура, єдність термінології.
• Додаткові вимоги – детальність викладення, повнота
викладення, строгість подачі інформації, наочність, навчальні
якості тощо .

1
ВСТУП В
УНІФІКОВАНУ МОВУ МОДЕЛЮВАННЯ
(UML)

2
Уніфікована мова моделювання

(Unified Modelling Language, UML)
є графічною мовою для візуального представлення,

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

3
Призначення мови UML
Надати в розпорядження користувачів мову

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

4
Історичний розвиток мови UML
• Починаючи із середини 60-х років і донедавна, широке поширення
мали структурні методології аналізу, проектування і розробки
інформаційних систем, що характеризуються штучним поділом (часто
неоптимальним) системи на підсистеми, а також слабким
взаємозв'язком процесів і даних, які присутні в системі. На відміну від
них, об'єктні технології, орієнтовані на тісний взаємозв'язок процесів і
даних у системах, дозволяють програмним системам бути
надійнішими, легшими для реалізації і стійкішими до змін. Крім того,
така філософія моделювання найбільше відповідає загальним
концепціям поведінки систем реального світу.
• Незважаючи на явну перевагу об'єктно-орієнтованих технологій
аналізу і проектування перед структурними, їхнє поширення було
незначним, оскільки жоден з методів не давав єдиної і цілісної
об'єктної моделі системи. Кожен метод добре висвітлював одну або
декілька сторін реальної системи, залишаючи в тіні багато інших, не
менш важливих сторін. Крім того, відсутність єдиного стандарту дуже
заважало широкому поширенню об’єктно-орієнтованих методів при
розробці програмного забезпечення.
5
Історичний розвиток мови UML
Протягом 1994-96 років творці трьох найпоширеніших методологій
— Граді Буч (BOOCH), Джим Рамбо (OMT — Object Modeling
Technique) і Айвар Якобсон OOSE — Object Oriented Software
Engineering) об'єднали свої зусилля під егідою Rational Software
Corporation для створення єдиної мови моделювання, яка б
об'єднала всі істотні й успішні розробки в даній галузі і стала би
стандартом мови об'єктного моделювання. Грандіозна робота, у
якій поряд з Rational брали участь представники багатьох
компаній, таких, як Microsoft, IBM, Hewlett-Packard, Oracle, DEC і
багатьох інших завершилася створенням у січні 1997 року UML 1.0,
яка після бурхливого обговорення протягом 1997 року у вересні
під версією 1.1 і була передана в OMG для прийняття як галузевий
стандарт мови об'єктного моделювання.
Grady James Ivar

Booch Rumbaugh Jacobson
6
Версії UML
Версія Дата прийняття • Поточною версією мови UML є
1.1 листопад 1997
версія 2.5, прийнята консорціумом
1.3 березень 2000
OMG в червні 2015 р. В серпні-
1.4 вересень 2001
вересні 2003 р був опублікований
1.4.2. липень 2004
проект мови UML 2.0, але ця версія
1.5 березень 2003
офіційно прийнята.в липні 2005.
2.0 липень 2005
формально не була
• В даний час всі питання подальшої
2.1
прийнята розробки мови UML сконцентровані
2.1.1 серпень 2007 в рамках консорціуму OMG.
2.1.2 листопад 2007
2.2 лютий 2009
2.3 травень 2010
2.4 beta 2 березень 2011
2.5 червень 2015

7
UML - уніфікована МОВА моделювання
UML - уніфікована мова моделювання. З цих трьох слів

ключовим є слово "мова". Що ж таке мова?
Мова - система знаків, яка слугує:

• засобом людського спілкування і розумової діяльності;
• способом вираження самосвідомості особистості;
• засобом зберігання і передавання інформації.
Мова включає в себе набір знаків (словник) і правила їх
застосування і інтерпретації (граматику).

8
Відзначу, що мови бувають природні і штучні, формальні і

неформальні. UML - формальна і штучна мова.
Штучна вона тому, що в неї є автори, в той же час, розвиток
UML неперервно продовжується, що ставить її в один ряд з
природними мовами.
Формальною її можна назвати, оскільки є правила її
застосування (правда, опис UML містить і явно неформальні
елементи).
Ще один нюанс: UML – графічна мова!

9
При описі формальної штучної мови (наприклад мови

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

10
UML - уніфікована мова МОДЕЛЮВАННЯ
• Друге слово в фразі, якою розшифровується абревіатура

UML - слово "моделювання".
• UML - це мова моделювання, причому об’єктно-
орієнтованого моделювання.
• Слово «моделювання» досить багатозначне.
• В англійській мові є два слова - modeling і simulation, які
обидва перекладаються як "моделювання", хоча означають
різні поняття. Modeling має на увазі створення моделі, яка
лише описує об’єкт, а simulation передбачає отримання за
допомогою створеної моделі деякої додаткової інформації
про об’єкт.
• UML в першу чергу - мова моделювання саме в першому
сенсі, тобто засіб побудови описувальних моделей. Як засіб
симулювання його теж можна використовувати, хоча для
цієї ролі він підходить не так добре.

11
UML - УНІФІКОВАНА мова моделювання
• Третє слово в назві UML - слово " уніфікована". Його можна

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

12
UML - УНІФІКОВАНА мова моделювання

Складнощі з комунікацією і розумінням задачі 13
створення програмного продукта

14
Проблеми програмної інженерії
Рисунок на попередньому слайді ілюструє проблеми програмної
інженерії.
• Зокрема - проблеми з комунікацією і розумінням,
викликані відсутністю чіткої специфікації створюваного
продукту.
• Автори UML визначають його як графічну мову моделювання
загального призначення (тобто її можна застосовувати для
проектування чого завгодно - від простої гойдалки, як на
рисунку, до складного апаратно-програмного комплексу або
навіть космічного корабля), призначену для специфікації,
візуалізації, проектування і документування всіх
артефактів, що створюються в ході розробки.
15
Причини невдалості проектів
• Недостатньо адекватне управління вимогами
• Неузгодженість вимог, проектних рішень і реалізації
• Жорстка архітектура ПЗ
• Наростаюча складність ПЗ
• Неточна і суперечлива комунікація
• Недостатнє тестування
• Суб'єктивне ставлення до пріоритетів окремих артефактів
проекту
• Ігнорування ризиків і відсутність процедур управління
ризиками
• Безконтрольне внесення змін до артефактів проекту
• Недостатнє використання CASE-засобів і засобів
підтримки окремих етапів проекту
16
Ситуація, що існувала в області технологій
програмування до появи UML
Основний недолік:
об'єднання тексту програми (її вихідного коду) з характеристиками
об'єкта автоматизації здійснюється тільки в свідомості програміста, а
документальний зв'язок між ними відсутній.

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

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

19
Призначення UML. Специфікація
• У типових випадках в процесі розробки додатків беруть
участь щонайменше дві дійові особи: замовник і розробник.
• Через те, що дійових осіб двоє, дуже багато залежить. Від
ступеня їх взаєморозуміння.
• Одним з ключових етапів розробки програми є визначення
того, яким вимогам має задовольняти додаток, що
розробляється.
• В результаті цього етапу з'являється формальний або
неформальний документ (артефакт): постановка завдання,
вимоги, технічне завдання, зовнішні специфікації і ін.
• Аналогічні за призначенням артефакти з'являються і на інших
етапах розробки: функціональні специфікації, архітектура
програми та ін.
• Ми будемо всі такі артефакти називати специфікаціями.
• Специфікація - це декларативний опис того, як щось
влаштовано або працює.
20
• Необхідно брати до уваги три тлумачення специфікацій.
• Те, яке має на увазі дійова особа, яка є джерелом
специфікації (наприклад, замовник).
• Те, яке має на увазі дійова особа, що є споживачем
специфікації (наприклад, розробник).
• Те, яке об'єктивно зумовлено природою об'єкта, який
складаює специфікацію.
• Ці три трактування специфікацій можуть не збігатися, і, на
жаль, як показує практика, часто-густо не збігаються,
причому значно.

21
• Основне призначення UML - надати, з одного боку,

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

22
Призначення UML. Візуалізація
• Особливості людського сприйняття такі, що текст з

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

23
Призначення UML. Проектування
В оригіналі це призначення UML визначено за допомогою слова
construct, яке ми передаємо обережним терміном
"проектування". Йдеться про те, що UML призначений не тільки
для опису абстрактних моделей додатків, але і для
безпосереднього маніпулювання артефактами, що входять до
складу цих додатків, в тому числі такими, як програмний код.
Іншими словами, одним з призначень UML є, наприклад,
створення таких моделей, для яких можлива автоматична
генерація програмного коду (або фрагментів коду) відповідних
додатків. Більш того, природа моделей UML така, що можливий
і зворотний процес: автоматична побудова моделі за кодом
готового додатка.

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

3 основних варіанти використання UML 25
(на прикладі діаграми використання UML)

Варіант використання drawing («Рисування діаграм")

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

Варіант використання modeling ("Моделювання систем")

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

Варіант використання development ( "Розробка

додатків")
Передбачає детальне моделювання,
реалізацію та тестування програми в
термінах UML. Значущим для
користувача Developer результатом в
цьому випадку є працюючий додаток,
який може бути скомпільований в
мову, підтримувану конкретною
системою програмування
Programming System або відразу
інтерпретовано середовищем
виконання інструменту. Цей варіант
використання найбільш складний в
реалізації.
Сучасні інструменти підтримують
зазначені варіанти використання
далеко не в рівній мірі.

29
Переваги UML
• Універсальність – єдина технологія, з якою знайомі більшість
програмістів та аналітиків
• Автоматична генерація коду на основі UML діаграм
• Широке застосування – не залежить від мови програмування
(часто застосовується для опису бізнес-моделей чи життєвих
ситуацій)
• Підтримка ООП
• Велика кількість типів діаграм
• Зручні інструменти, готові плагіни для багатьох IDE
• Розбір основних моментів проекту без вивчення коду
• Діаграми можна створювати як на основі готового коду, так і
перед його створенням
• Перенесення діаграм із одного інструменту в інший – часто
можна виконати без особливих проблем

30
Структура UML

31
Структура UML
(три різновиди будівельних блоків)
Сутності (предмети) Відношення Діаграми

1. Структурні 1. Включення 1. Класів
2. Поведінкові 2. Асоціацій 2. Об’єктів
3. Групуючі 3. Узагальнень 3. Прецедентів
4. Анотаційні 4. Розширення 4. Послідовностей
5. Кооперацій
6. Станів
7. Дій
8. Компонентів
9. Розгортання
Модель представляється у вигляді сутностей і відношень між ними, які
показуються на діаграмах.
Сутності (предмети) - це абстракції, які є основними елементами в моделі.
Виділяють 4 типи сутностей, кожна з яких має своє графічне представлення.
Відношення пов'язують предмети. Зображуються графічно у вигляді різних
ліній.
Діаграма – це графічне представлення множини елементів. Зазвичай,
зображується у вигляді графа з вершинами (сутностями) і ребрами
(відношеннями).
32
Сутності (предмети). Типи сутностей
• Сутності є основними об'єктно-орієнтованими елементами
мови. З їх допомогою можна створювати коректні моделі.
• Структурні сутності - це іменники в моделях на мові UML.
Як правило, вони представляють собою статичні частини
моделі, що відповідають концептуальним або фізичним
елементам системи.
• Поведінкові. У деяких джерелах виділяють також
поведінкові сутності взаємодії і кінцеві автомати, але з
логічної точки зору їх слід віднести до діаграм.
• Групуючі - організаційні частини UML-моделей. Це ящики,
по яких може бути розкладена модель.
• Анотаційні (пояснюючі) - пояснюючі частини UML-
моделей. Вони є зауваженнями, застосовуваними для
опису, пояснення і коментування будь-якого елементу
моделі.
33
Структурні сутності

34
Структурні сутності. Класи (class)
• Клас - опис множини об'єктів, які поділяють однакові

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

35
Структурні сутності. Об'єкт (object)
• Об'єкт - сутність, що володіє унікальністю і інкапсулює в собі

стан і поведінку.
• Абстракція реальної чи уявної сутності з чітко вираженими
концептуальними межами, індивідуальністю (ідентичністю),
станом і поведінкою. З точки зору UML об'єкти є
екземплярами класу (екземплярами сутності)
Об'єкт

36
Структурні сутності. Інтерфейс (interface)
• Інтерфейс (interface) - це сукупність операцій, що визначає

сервіс (набір послуг), що надається класом або компонентом.
• На діаграмах інтерфейс зображується у вигляді кола, під
яким вказується його ім'я.
• Інтерфейс дуже рідко, практично ніколи, не існує сам по собі
- зазвичай він приєднується до класу або компоненту, який
його реалізує.
• Ім'я інтерфейсу зазвичай починається з букви «I».
iРозрахунок

37
Структурні сутності. Актор (actor)
• Актор - набір узгоджених ролей, які грають користувачі при

взаємодії з системою (її елементами Use Case). Кожна роль
вимагає від системи певної поведінки.
• Це зовнішня по відношенню до системи сутність, яка
взаємодіє з системою і використовує її функціональні
можливості для досягнення певної мети або вирішення
приватних завдань. Таким чином актор - це зовнішнє
джерело або приймач інформації.
Замовник
38
Структурні сутності. Кооперація (collaboration)
• Кооперація (collaboration) визначає взаємодію, вона являє

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

Структурні сутності. 39
Прецедент/варіант використання (use case)

• Use Case (Прецедент/Варіант використання) - опис
послідовності дій (або декількох послідовностей),
виконуваних системою в інтересах окремого актора, що
виробляють видимий для актора результат.
• У моделі елемент Use Case застосовується для
структурування предметів поведінки. Елемент Use Case
реалізується кооперацією.
Обробка
замовлення

Структурні сутності. 40
Активний клас (active class)

• Активним класом (active class) називається клас, об'єкти
якого залучені в один або кілька процесів, або ниток
(threads), і тому можуть ініціювати керуючий вплив.
• Активний клас схожий на звичайний клас за винятком того,
що його об'єкти діють одночасно з об'єктами інших класів.
• Активний клас зображується як потовщений прямокутник,
зазвичай включає ім'я, властивості (атрибути) і операції.

41
Структурні сутності. Компонент (component)
• Це фізична замінна частина системи, яка відповідає
деякому набору інтерфейсів і забезпечує його реалізацію.
• У систему входять компоненти:
- результати процесу розробки (файли вихідного коду);
- різновиди компонентів (СОМ+-компоненти, Java Beans).
• Компонент - це фізична упаковка різних логічних елементів
(класів, інтерфейсів і кооперацій).

42
Структурні сутності. Вузол (node)
• Вузол (node) - це елемент реальної (фізичної) системи, який

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

43
Групуючі сутності. Контейнер (packages)
• Це ящики, по яким може бути розкладена модель.
Передбачений один різновид групуючого предмета -
контейнер.
• Контейнер - загальний механізм для розподілу елементів
по групах.
• У контейнер поміщаються структурні предмети, предмети
поведінки і інші групи предметів.
• На відміну від компонента, що існує в період виконання,
контейнер - концептуальне поняття.
• Т.ч. контейнер існує тільки в період розробки.
• UML дозволяє згруповувати в контейнери: UseCase; Class;
Components.

Анотаційні (пояснюючі) сутності. 44
Примітка (comment)
Коментар до елементу
• Вони є зауваженнями, застосовуваними для опису,
пояснення і коментування будь-якого елементу моделі.
Передбачений один різновид пояснюючого предмета -
примітка.
• Примітка - символ для відображення обмежень і
зауважень, що приєднуються до елементу або сукупності
елементів.

45
Поведінкові сутності
• Це динамічні частини UML-моделей - дієслова моделей,
представлення поведінки в часі і просторі.
• Описують поведінку моделі в часі і просторі.
• Поведінкові сутності:
- взаємодії
- кінцеві автомати.
• З логічної точки зору їх слід віднести до діаграм.
• Семантично ці елементи асоціюються зі структурними
елементами (з класами, коопераціями та об'єктами).

46
Поведінкові сутності. Взаємодії
• Це поведінка, яка містить в собі набір повідомлень
(Messages), якими обмінюється набір об'єктів в
конкретному контексті для досягнення певної мети. За
допомогою взаємодії можна описати або окрему операцію
або поведінку сукупності об'єктів.
• Елементи взаємодії: повідомлення, послідовність дій
(поведінка, що викликається повідомленням) і зв'язку
(з'єднання між об'єктами).
Над стрілкою пишеться
ім’я операції

Приклад застосування взаємодії 47
Застосування взаємодії
Взаємодія на діаграмі
послідовності

Поведінкові сутності. 48
Скінченні автомати (State machine)

• Скінченні автомати - поведінка, що визначає
послідовність станів об'єкта або взаємодії, що
виконуються в ході його існування у відповідь на події (і з
урахуванням обов'язків за цими подіями).
• За допомогою скінченного автомата може визначатися
поведінка індивідуального класу або кооперації класів.
• Елементи скінченного автомата: стани, переходи (від стану
до стану), події (предмети, що викликають переходи) і дії
(реакції на перехід)
Стан (state) - період в життєвому циклі
об'єкта, перебуваючи в якому об'єкт
Регулювання
задовольняє деякій умові і здійснює власну
діяльність або очікує настання деякої події.

Приклад скінченного автомата, діаграма станів 49
Діаграма
Стан скінченного станів (скінченного
автомата автомата)

50
Відношення

Види відношень UML, що використовуються на 51
діаграмах для вказання зв’язків між сутностями
Основні:
Залежність Асоціація
(dependency) (association)
Узагальнення Реалізація
(generalization) (realization)
Агрегація (aggregation) – Композиція (composition) –

підвид асоціації підвид агрегації

52
Найменування Позначення Визначення (семантика)
Відношення, яке описує значимий зв'язок між двома і
Асоціація
більше сутностями. Найбільш загальний вигляд
(association)
відношення
Підвид асоціації, яка описує зв'язок «частина» -

Агрегація «ціле», в якому «частина» може існувати окремо від
(aggregation) «цілого». Ромб вказується з боку «цілого».
(підвид асоціації) Відношення вказується тільки між сутностями одного
типу
Композиція Підвид агрегації, в якій «частини» не можуть існувати

(composition) окремо від «цілого». Як правило, «частини»
(підвид агрегації) створюються і знищуються одночасно з «цілим»

Відношення 53
Найменування Позначення Визначення (семантика)
Відношення між двома сутностями, в якому зміна в

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

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

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

54
Для асоціації, агрегації і композиції може вказуватися кратність
(multiplicity), що характеризує загальну кількість екземплярів
сутностей, що беруть участь у відношенні.
Вказується з кожного боку відношення близько відповідної сутності.
Способи вказівки кратності:
- * - будь-яка кількість примірників, в тому числі і жодного;
- ціле невід'ємне число - кратність строго фіксована і дорівнює
зазначеному числу (наприклад: 1, 2 або 5);
- діапазон цілих невід'ємних чисел «перше число .. друге число»
(наприклад : 1..5, 2..10 або 0..5);
- діапазон чисел від конкретного початкового значення до довільного
кінцевого «перше число .. *» (наприклад : 1 .. *, 5 .. * або 0 .. *);
- перерахування цілих невід'ємних чисел та діапазонів через кому
(наприклад : 1, 3..5, 10, 15 .. *).
Якщо кратність не вказана, то вона = 1. Кратність екземплярів
сутностей, що беруть участь в залежності, узагальненні та реалізації,
завжди приймається = 1.

55
Відношення в діаграмах класів

56
Діаграми UML

57
Діаграми UML
• Діаграми UML - основна структура, що накладається

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

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

58
Ієрархія діаграм UML
Найчастіше застосовуються
діаграми позначені зеленим
кольором.

Основні діаграми UML 59
• Кожна з цих діаграм деталізує і конкретизує різні уявлення про моделі складної
системи в термінах мови UML.
• При цьому діаграма варіантів використання (функціонал, доступний
користувачам системи) являє собою найбільш загальну концептуальну модель
складної системи, яка є вихідною для побудови всіх інших діаграм.
• Діаграма класів (логічна модель даних системи, сутностей, з яких буде
будуватися БД), по своїй суті, логічна модель, що відображає статичні аспекти
структурної побудови складної системи.
• Діаграми кооперації та послідовностей (опис одного сценарію)
представляють собою різновиди логічної моделі, які відображають динамічні
аспекти функціонування складної системи.
• Діаграми скінченних автоматів або станів (відображення статусів об'єктів)
та діяльності (блок-схема) призначені для моделювання поведінки системи.
• І, нарешті, діаграми компонентів і розгортання служать для подання
фізичних компонентів складної системи і тому відносяться до її фізичної моделі.

60
Діаграми варіантів використання

(Use Case Diagram)

61
Призначення діаграми варіантів
використання (прецедентів, Use Cases)
• Описує функціональне призначення системи, тобто те, що
система буде робити в процесі свого функціонування;
• Є вихідною концептуальною моделлю системи в процесі її

проектування і розробки (верхній рівень опису системи).
• Прецеденти допомагають у розробці GUI
• Розділяють ініціатора (хто запускає процес) і виконувача (хто

реалізовує)
• Після опису прецедентів ви точно будете розуміти, як можна буде

працювати з вашою системою

62
Суть діаграми варіантів використання
• Проектована система представляється у вигляді множини

сутностей або акторів (дійових осіб), які взаємодіють з
системою за допомогою так званих варіантів використання
(прецедентів).
Таким чином
• Основними компонентами діаграми варіантів використання
є:
– актори
– прецеденти
– відношення

63
Варіант використання
• = Прецедент = use case = юскейс;
• Визначає послідовність дій, яка повинна бути
виконана проектованою системою при її взаємодії з
відповідним актором.
Оплатити замовлення
кредитною карткою
Ім'я варіанту використання починається з великої літери і

позначається оборотом дієслова або іменника, що позначає
дію
64
Актор
• = Actor = дійова особа
• Являє собою зовнішню по відношенню до модельованої системи

сутність
• Взаємодіє з системою і використовує її функціональні можливості

для досягнення певних цілей і вирішення приватних завдань.
• Може розглядатися як якась роль щодо конкретного варіанту

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

65
• Один актор може взаємодіяти з декількома варіантами
використання і навпаки.
• 2 варіанти використання, визначені для однієї і тієї ж сутності, не

можуть взаємодіяти один з одним, тому що будь-який з них
самостійно описує закінчений варіант використання цієї сутності
Види відношень:
1) асоціативне відношення (відношення асоціації,

association relationship)
2) відношення розширення (extend relationship)
3) відношення узагальнення (generalization relationship)
4) відношення включення (include, uses relationship)

66
Відношення асоціації
• Відношення між варіантом використання і актором, що відображає
зв'язок між ними.
• Воно встановлює, яку конкретну роль грає актор при взаємодії з
екземпляром варіанту використання.
• Зв'язок може бути одностороннім/двостороннім (від актора до
варіанту використання і/або від варіанту використання до актора)
• Напрямок зв'язку показує хто є ініціатором зв'язку
• Кратність (multiplicity) асоціації вказується поряд з компонентом
асоціації і визначає кількість екземплярів компонента, що беруть
участь в асоціації

67
Відношення розширення (extend)
• Визначає взаємозв'язок базового варіанту використання з
деяким іншим варіантом використання, функціональна
поведінка якого задіюється базовим не завжди, а тільки при
виконанні деяких додаткових умов.
Стрілка вказує на базовий варіант використання!

68
Відношення включення (include, uses)
• Включення – це різновид відношення залежності між
базовим варіантом використання і його спеціальним
випадком.
• Визначає що деякий варіант використання містить поведінку,

визначену в іншому варіанті використання.

69
Відношення узагальнення
• Служить для вказівки того факту, що деякий варіант використання
(ВВ) А може бути узагальнено до варіанту використання Б (або
актор А може бути узагальнено до актора Б).
Стрілка вказує в сторону батьківського ВВ (актора)

Приклад діаграми ВВ процесу оформлення 70
замовлення на купівлю товару

71
Визначення

73
Класи, об'єкти і методи
• Класи потрібні для опису нового типу, що містить поля

і методи
• Об'єкти - це екземпляри класів
• Методи реалізують функціонал класу
<Ім'я об'єкта>. <Ім'я методу> (<аргументи>)
Робота об'єктно-орієнтованої програми може бути

представлена як послідовність дій, що складається з
викликів методами один одного.

74
Діаграма класів (class diagram)
• Діаграма класів (class diagram) - це діаграма, на якій показано
множини класів, інтерфейсів, кооперацій і відносин між ними.
• Діаграма класів служить для представлення статичної структури
моделі системи
• Інформація з діаграми класів може напряму відображатися в
вихідний код додатку - в більшості існуючих інструментів UML-
моделювання можлива генерація коду для певної мови
програмування (зазвичай Java або С++).
Особливості діаграми класів

• На діаграмі класів не вказується інформація про часові аспекти
функціонування системи

75
Шаблони класів
кратність
Ім’я класу *
- <атрибут-1> область
+ <атрибут-2> атрибутів
…
# <атрибут-n>
видимість - <операція-1>
# <операція-2> область
… сигнатури
+ <операція-m>
Позначення ознак видимості:

+ public # protected - private ~ package

76
Відношення між класами
Крім внутрішнього устрою класів на діаграмі класів вказуються різні

відношення (зв'язки) між ними. Сукупність типів відносин фіксована.
Базові відношення в мові UML:
• Відношення залежності (dependency relationship)
• Відношення асоціації (association relationship)
• Відношення узагальнення (generalization relationship)

77
Відношення залежності
Залежність (dependency) - відношення використання, згідно з яким
зміна в специфікації одного елемента може вплинути на інший
елемент, який його використовує, причому зворотне не є
обов'язковим.
Графічно залежність зображується пунктирною лінією зі стрілкою,

спрямованою від залежного елемента на той, від якого він залежить.

Відношення асоціації 78
• Асоціація (association) – структурне відношення, яке показує, що

об'єкти одного типу якимось чином пов'язані з об'єктами іншого
типу.
• Асоціація, що зв'язує два класи, називається бінарною. Можна
створювати асоціації, що зв'язують відразу кілька класів; вони
називаються n-арними.
• У асоціацій можуть бути: ім'я, роль, кратність і агрегування.
class cls 05
Person Person
+Employee 1.. *
work on
+Employer *
Company Company

79
Відношення асоціації
Агрегування (aggregation) показує відношення типу «частина / ціле», в
якому один клас складається з кількох менших класів
class cls 09
Team Person
1 *
Композиція (composition) служить для виділення спеціальної форми

відношення «частина / ціле». Специфіка зв'язку полягає в тому, що частини
не можуть виступати у відриві від цілого, тобто зі знищенням цілого
знищуються і всі його складові частини.
class cls 10
Building Room
1 *

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

81
Приклад діаграми класів
class cls 15
Colledge Faculty
rule
- name - name
- address include 0..1
- phon e 1 1.. * + addInstructor()
+ removeInstructor()
work on
+ attestInst ruct ors() + getInstructor()
+ attestSt udents() : void + getAllInstructor() 1.. *
1.. * 1.. *
studied at
* 1.. * 1.. * +dean 1
Student Cours e Instructor

visit
- id - id
- name * * - name

82
Діаграма діяльності (activity diagram)
Для моделювання динамічних аспектів системи використовуються діаграми
взаємодій і автомати.
Діаграми взаємодій моделюють поведінку групи спільно діючих об'єктів.

Автомати моделюють поведінку окремого об'єкта.
Автомат може показувати:
- передачу потоку управління від одного стану об'єкта до іншого (діаграма

станів)
- передачу потоку управління від однієї діяльності до іншої (діаграма
діяльності)
Діаграма діяльності (activity diagram) - це діаграма, яка показує потік

переходів від однієї діяльності до іншої.

83
Діаграма діяльності

84
Діаграма компонентів (component diagram)
• Діаграма компонентів відображає залежності між компонентами
програмного забезпечення, включаючи компоненти вихідних кодів,
бінарні компоненти, та компоненти, що можуть виконуватись.
• Модуль програмного забезпечення може бути представлено як
компоненту. Деякі компоненти існують під час компіляції деякі — під час
компонування, а деякі під час роботи програми.
• Діаграма компонент відображає лише структурні характеристики, для
відображення окремих екземплярів компонент слід використовувати
діаграму розгортування.
Для позначення можна скористатися ключовим словом «component» (компонент)

85
Приклад діаграми компонентів

86
Діаграма розгортання (deployment diagram)
• Діаграма розгортання моделює фізичне розгортання артефактів на
вузлах.
• Артефакт - якась фізична сутність, програмний компонент, який
використовується або створюється під час роботи програмного
забезпечення. По суті, є елементом діаграми компонентів.
• Існує два типи вузлів:
- вузол пристрою
- вузол середовища виконання
• Вузли пристроїв - це фізичні обчислювальні ресурси зі своєю
пам'яттю і сервісами для виконання програмного забезпечення,
такі як звичайні ПК, мобільні телефони.
• Вузол середовища виконання - це програмний обчислювальний
ресурс, який працює всередині зовнішнього вузла і який надає
собою сервіс, який виконує інші виконувані програмні елементи.

87
Діаграма розгортання (deployment diagram)

89
Механізми розширення
• UML - розвинена мова, що має великі можливості, але
навіть вона не може відобразити всі нюанси, які можуть
виникнути при створенні різних моделей. Тому, UML
створювалася як відкрита мова, що допускає контрольовані
розширення.
• Механізмами розширення в UML є:

- обмеження;
- тегові величини;
- стереотипи.

90
Обмеження (constraint)
Обмеження (constraint) розширює семантику будівельного UML-блоку,
дозволяючи додати нові правила або модифікувати існуючі. Обмеження
показують як текстовий рядок, поміщений в фігурні дужки { }. Наприклад, на
рис. введено просте обмеження на властивість сума класу Сесія Банкомату
- його значення повинно бути кратне 20. Крім того, тут показане обмеження
на два елементи (дві асоціації), воно розташовується біля пунктирної лінії,
що з'єднує елементи, і має наступний сенс - власником конкретного рахунку
не може бути і організація, і персона.

Тегова величина (tagged value) 91
• Тегова величина (tagged value) розширює характеристики будівельного

UML-блоку, дозволяючи створити нову інформацію в специфікації
конкретного елемента. Тегову величину показують як рядок в фігурних
дужках { }. Рядок має вигляд
• ім'я тегової величини = значення.
• Іноді (в разі зумовлених тегів) вказується тільки ім'я тегової величини.
• Відзначимо, що при роботі з продуктом, який має багато реалізацій,
корисно відстежувати версію і автора певних блоків. Версія і автор не
належать до основних понять UML. Вони можуть бути додані до будь-
якого будівельного блоку (наприклад, до класу) введенням в блок
нових тегів величин. Наприклад, на рис. клас ТекстовийПроцессор
розширено шляхом явного вказання його версії і автора.

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

93
Стереотип
• Приклади елементів зі стереотипами наведені на рис. Стереотип
«exception» говорить про те, що клас ВтратаЗначущості тепер
розглядається як спеціальний клас, якому, між іншим, дозволяється
тільки генерація і обробка сигналів винятків. Особливі можливості
метакласом отримав клас ЕлементМоделі. Крім того, тут показано
застосування стереотипу «call» до відношення залежності (у нього
з'явився новий сенс).

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

1
Шаблони в розробці
програмного забезпечення

2
Шаблони (патерни, patterns) у
розробці ПЗ
• У розробці ПЗ часто зустрічаються проблеми, які

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

3
Експертний спосіб мислення
Уявіть, що ви хочете зробити новий автомобіль, але ви ніколи цим
не займалися. Скільки коліс ви спроектуєте для нього?
• Під час розв'язку конкретних проблем експерти звичайно не
намагаються розробити нове рішення, яке відрізняється від уже
існуючих.
• Дії експерта:
– згадують аналогічну проблему, яку вони вже розв'язували,
– стараються повторно використати суть раніше прийнятого
рішення для рішення нової проблеми.
• Такий «спосіб мислення» в термінах пари «проблема - рішення», є
загальним для сукупності різних предметних областей, таких, як:
– архітектура;
– економіка;
– програмна інженерія.
4
Призначення шаблонів ПЗ
• Шаблони дозволяють базуватися на колективному досвіді

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

5
Поняття “шаблон”
• Шаблон (патерн) – це опис добре перевіреної, узагальненої

схеми розв'язку деякої проблеми (задачі), що часто
повторюється під час розробки ПЗ, яка виникає в деяких
специфічних умовах (контексті).
• Схема розв'язку проблеми задається шляхом:
– визначення використовуваних (складових) компонент;
– їх відповідальностей;
– способів їх взаємодії.

6
Історія розвитку
• Ідея патернів проектування спочатку виникла в
архітектурі. Архітектор Крістофер Олександр в 1977-
1979 рр. написав дві революційні книги, що містять
опис шаблонів в будівельній архітектурі і міському
плануванні. В області архітектури ця ідея не
отримала такого розвитку, котрого вона досягла
пізніше в області розробки програмного
забезпечення.
Christopher Alexander
7
• У 1987 р Кент Бек на основі ідеї Крістофера

Олександра створив кілька шаблонів розробки ПЗ
для графічних оболонок на мові Smalltalk.
• У 1988 р Еріх Гамма почав писати дисертацію на тему

загальної переносимості методики патернів
проектування на розробку ПЗ.

8
У 1991 р Гамма дописав

дисертацію, і в
співробітництві з Річардом
Хелм, Ральфом Джонсоном і
Джоном Вліссідсом публікує
книгу Design patterns -
Elements of reusable Object-
Oriented Software. У книзі
були описані 23 патерни, і
незабаром команда авторів
стала відома під назвою
«банда чотирьох» (gang of
four - GoF).

9
Наступним кроком став опис Мартіном Фаулером

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

10
Причини появи шаблонів
В кінці 1980-х в сфері розробки ПЗ, зокрема в ООП,

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

11
Властивості шаблонів
1. Шаблони описують розв'язок для задач

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

12
Властивості шаблонів
5. Шаблони є засобами документування архітектур ПЗ.
Вони можуть описати бачення, яке ви маєте на увазі при
проектуванні системи програмного забезпечення.
6. Шаблони підтримують конструювання ПЗ з певними
властивостями. Шаблони забезпечують скелет
функціональної поведінки і тому допомагають реалізувати
функціональність вашої програми.
7. Шаблони допомагають розробляти складні і різнорідні
архітектури ПЗ. Кожен шаблон забезпечує заздалегідь
визначений набір компонентів, ролей і відносин між ними.
8. Шаблони допомагають боротися зі складністю ПЗ. Коли
ви зіткнетеся з конкретною ситуацією проектування,
охопленою шаблоном, не потрібно витрачати час на
винахідництво нового рішення вашої проблеми.
13
Переваги шаблонів
• Зниження складності розробки

• Спрощення комунікації
• Правильно сформульований шаблон дозволяє
користуватися ним знову і знову
• Набір шаблонів допомагає розробнику вибрати
найбільш оптимальний варіант проектування

14
Недоліки шаблонів
• Сліпе слідування за деяким обраним шаблоном, може

призвести до ускладнення програми
• Необгрунтоване застосування шаблону

15
Процедурні алгоритми
Алгоритми процедурного програмування, на кшталт

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

16
Ідіоми
Шаблони, що описують типові рішення на
конкретній мові програмування.
• Інкремент: inc(i);
i++;
• Обмін temp = a;
значеннями: a = b;
b = temp;
while True:
• Безкінечний do_something()
цикл: for (;;){
do_something();}

17
Антипатерни (Anti-Design-Patterns)
• Патерн - це загальний опис хорошого способу

вирішення завдання.
• Також існує поняття «антипатерн» - це невдале
рішення, яке не рекомендується використовувати.
• Мета патерну - розпізнати можливість правильного
вирішення проблеми.
• Мета антипаттерну - виявити погану ситуацію і
запропонувати підхід для її усунення.

18
Приклади антипатернів
• Жорсткий код, або «прибите цвяхами» - код настільки

прив'язаний до конкретної апаратної конфігурації або
системного оточення, що відірвати його для перенесення в
інше місце можна тільки обценьками -)
• М'який код - код, конфігурується занадто гнучко і заплутано.
Виникає внаслідок виносу в файли всіх налаштувань
програмної логіки.
• Магічні числа - числові літерали в програмі без пояснення
їхнього змісту. Як правило, при зміні магічного числа або
його видаленні код магічно перестає працювати. Типові
приклади - 17 і 54.
• Магічна кнопка - весь код написаний
в обробнику натиснення кнопки.
19
• Непотрібна складність - робити складно те, що можна
зробити просто. Адже як правило, програмісту хочеться
швидше застосувати все, що він вивчив, а ще отримати за
результатами проекту багато нових рядків у резюме.
• Спагеті - це той самий код, який вам одного разу дадуть
супроводжувати. Після п'яти хвилин причісування вставшого
дибки волосся від перегляду цього коду ви мовчки
закриваєте редактор і відкриваєте браузер в пошуках
вакансії в іншій фірмі, де не практикують такого жорстокого
поводження з програмістами.
• Божественний Об'єкт - невелика частина коду, де
сконцентровано ВСЕ. Весь інший код програми - виключно
декорація навколо Божественного Об'єкту.

20
• Детонатор - дуже поширений, але рідко виявляється.
Приклад - «проблема 2000», коли для зберігання дати не
вистачало одного байта.
• Не винувата я - зустрічається в коді, написаному колишніми
співробітниками компанії. В такому коді міститься стільки
старих проблем, що теперішні співробітники можуть
захистити свої напрацювання від звинувачень, стверджуючи,
що саме чужий код - причина всіх виникаючих помилок.
• Паблік Морозов - клас, який за запитом видає доступ до
приватних полів класу-батька.
• Врятувати рядового Райана - доступ до поля отримати в
принципі можна, але для цього треба споряджати
експедицію, пов'язану з безліччю небезпек.

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

22
Класифікація патернів

23
Класифікація патернів
• В ОО аналізі і проектуванні розроблено багато різних патернів.
1. Архітектурні патерни (architecture patterns).
– Описують фундаментальні способи структурування
програмних систем.
– Ці патерни відносяться до рівня систем і підсистем, а не
класів.
2. Патерни проектування (design patters).
– Описують структуру програмних систем в термінах класів.
– Найбільш відомими в цій області є 23 патерни, описані в
[GoF].
3. Патерни аналізу (analysis patterns ).
- Надають загальні схеми організації процесу об'єктно-
4. Патерни тестування (test patterns).
…
24
Особливості застосування шаблонів при
розробці ПЗ
• На етапі аналізу системи:
– шаблони аналізу – комбінації класів для опису
стандартних задач прикладної області;
– шаблони тестування
• На етапі проектування системи:
– архітектурні шаблони.
– шаблони проектування;
– специфічні для конкретної мови програмування
ідіоми.

25
Архітектурні шаблони
• Архітекту́рні шабло́ни програ́много забезпе́чення

(software architectural patterns) — це шаблони
програмного забезпечення, що являють собою звіт
«добрих практик» (good practices) вирішення
архітектурних проблем розробки ПЗ.
• Архітектурні шаблони виражають фундаментальну

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

26
Особливості архітектурних шаблонів
• Архітектурні шаблони ПЗ є шаблонами самого високого
рівня в системі шаблонів ПЗ.
• Вони допомагають визначити базову структуру програмної
системи.
• Кожна робота по розробці ПЗ управляється її структурою:
– детальний опис підсистем;
– комунікація і взаємодія між різними частинами
системи;
– їх наступне розширення.
• Кожен архітектурний шаблон допомагає розробнику
досягти деякої глобальної властивості системи, що
розробляється.
– Наприклад, адаптованість інтерфейсу.
27
Види архітектурних шаблонів
1. Багаторівнева система (layers)
2. Клієнт-серверна архітектура (client-server architecture)
3. Модель-Представлення-Контролер (Model-View-Controller)
4. Представлення-Абстракція-Контролер (Presentation-
Abstraction-Control),
5. Се́рвісно-орієнто́вана архітекту́ра (service-oriented
architecture)
6. Мікросервіси (microservices),
7. Брокер (broker),
8. Пайпи і фільтри (pipes and filters).
9. Подієва архітектура (event-driven architecture).

28
Багаторівнева система (layers)
Відповідно до патерна
"Багаторівнева система" структурні
елементи системи організуються в
окремі рівні з взаємопов'язаними
обов'язками таким чином, щоб на
нижньому рівні розташовувалися
низькорівневі служби та служби
загального призначення, а на більш
високих - об'єкти рівня логіки
додатка. При цьому взаємодія і
зв'язування рівнів відбувається
зверху вниз. Зв'язування об'єктів
знизу вгору слід уникати. Типові рівні логічної
архітектури системи
29
Багаторівнева система (layers)
• Рівень представлення охоплює все, що має
відношення до спілкування користувача з
системою. До основних функцій рівня
представлення відноситься відображення
інформації й інтерпретація користувачем команд
з перетворенням їх у відповідні операції в
контексті домену (бізнес - логіка) і джерела
даних.
• Джерело даних - підмножина функцій, що
забезпечує взаємодію зі сторонніми системами,
які виконуються.
• На відміну від архітектурного патерну "Клієнт -
сервер", рівні зовсім не обов'язково повинні
розташовуватися на різних машинах.
• Багаторівнева система може бути розроблена
покроково (ітеративно).
30
Багаторівнева система (layers). Недоліки
Недоліками даного патерну є:
• Зміна вихідного коду тягне за собою переробку всіх

елементів системи, оскільки всі елементи системи тісно
пов'язані один з одним.
• Логіка програми тісно пов'язана з інтерфейсом користувача

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

31
MVC

32
Шаблони (патерни) проектування
• Шаблони проектування програмного забезпечення (англ.

software design patterns) — ефективні способи вирішення
задач проектування програмного забезпечення.
• Шаблон не є закінченим зразком, який можна

безпосередньо транслювати в програмний код.
• Об'єктно-орієнтований шаблон найчастіше є зразком

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

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

34
Як задачі проектування розв'язуються за
допомогою патернів
• Патерни проектування дозволяють різними

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

35
Класифікація патернів проектування
Мета Породжуючі Структурні патерни Патерни поведінки

Рівень патерни
Клас Factory Method Adapter (класу) Interpreter
Template Method
Об'єкт Abstract Factory Adapter (обєкту) Iterator
Singleton Decorator Command
Prototype Proxy Observer
Builder Composite Visitor
Bridge Mediator
Flyweight State
Facade Strategy
Memento
Chain of Responsibility

36
Породжуючі (твірні) патерни
(creational patterns)
• Абстрагують процес інстанцювання, дозволяють

зробити систему незалежною від способу створення,
композиції та представлення об'єктів.
• Відповідають на питання «хто, коли і як створює
об'єкти в системі».

37
Структурні патерни (structural patterns)
• Структурні шаблони — шаблони проектування, у яких

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

найкращим чином вирішують питання управління
цими даними.

38
Шаблони поведінки (behavioral patterns)
• Шаблони поведінки — шаблони проектування, що

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

39
Патерни аналізу
• Представляють спільні схеми організації процесу об'єктно-
• Патерни аналізу програмного забезпечення або патерни аналізу в
програмній інженерії є концептуальними моделями, які охоплюють
абстракцію ситуації, яка часто зустрічається в моделюванні. Модель
аналізу може бути представлена як "група споріднених, загальних
об'єктів (мета-класів) зі стереотипними атрибутами (визначеннями
даних), поведінкою (сигнатурами методів) і очікуваними взаємодіями.
Event analysis pattern

1
Інверсія управління
та
впровадження залежностей

2
Ідея
• Інверсія керування (англ. Inversion of Control, IoC) — це

програмний принцип, за допомогою якого можна знизити
зв'язаність між компонентами, а також підвищити модульність і
розширюваність ПЗ.
• Суть IoC полягає в тому, що кожен компонент системи повинен

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

орієнтованого програмування.

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

свій код в певних точках виконання (використовуючи callback
або інші механізми), потім запустити «головну функцію»
фреймворка, яка забезпечить всі виконання і викличе код
програміста тоді, коли це буде необхідно. Як наслідок,
відбувається втрата контролю над виконанням коду - це і
називається інверсією управління (фреймворк управляє кодом
програміста, а не програміст управляє фреймворком).
• Hollywood Principle — «Don't call us, we'll call you»).

4
Особливості Inversion of Control
• Інверсія управління є ключовою частиною того, що розрізняє

фреймворк і бібліотеку. Бібліотека це по суті набір функцій, які ви
можете викликати, в наші дні вони організовані в класи. Кожен
виклик виконує деяку роботу і повертає керування назад
користувачеві.
• Фреймворк втілює в собі певний абстрактний дизайн з

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

5
Переваги такої архітектури
• відокремлення виконання завдання від його реалізації
• полегшення перемикання між різними реалізаціями
• велика модульність програми
• спрощення тестування програми шляхом ізоляції

компонента

6
Реалізація Inversion of Control
Існує кілька основних шаблонів проектування, які

використовуються для реалізації IoC в об'єктно-
орієнтованому програмуванні:
• шаблон проектування стратегія (strategy design pattern)
• шаблон локатора послуг (service locator)
• шаблон фабрика (factory pattern)
• впровадження залежностей (dependency injection, DI).

7
Впровадження залежностей
(Dependency Injection)
• Впровадження залежностей (Dependency Injection) – це патерн,

одна з реалізацій принципу IoC.
• Впровадження залежностей – це механізм передачі класу його
залежностей.
• Впровадження (Injection) — це передача залежності (тобто,
сервісу) залежному об'єкту (тобто, клієнту). Передавати залежності
клієнту замість дозволити клієнту створити сервіс є
фундаментальною вимогою до цього шаблону проєктування.
• Залежність (Dependency) — об’єкт, або будь який програмний
юніт, що використовується у клієнті — іншому об’єкті/програмному
юніті. Для прикладу залежність — це сервіс, що повертає дані, які
слід представити у клієнті — веб компоненті, тощо. Часто такий
об’єкт використовується у різних місцях проекту.
8
Впровадження залежностей
(Dependency Injection)
• Впровадження залежностей — це шаблон проєктування, в

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

власної логіки клієнта, що дозволяє компонентам бути
слабко зв'язаними і притримуватися принципів інверсії
залежностей і єдиного обов'язку (Single responsibility).

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

діаграми послідовності

12
Види впровадження залежностей
• Існує кілька конкретних видів або патернів

впровадження залежностей:
1) впровадження залежності через
конструктор (Constructor Injection),
2) через метод (Method Injection)
3) через властивість (Property Injection).

13
Приклад 1.
Код без інверсії управління
class TodoRepository {
// other code
}
class TodoService {
TodoRepository todoRepository = new TodoRepository();
// other code
}
Застосування інверсії управління передбачає, що об'єкт класу

TodoRepository повинен бути створений за межами класу TodoService,
але в подальшому повинен бути переданий об'єкту цього класу.
14
Приклад 1.
Впровадження залежності через конструктор
class TodoService {
TodoRepository todoRepsitory;
TodoService(TodoRepository todoRepository) {
this.todoRepository = todoRepository;
}
}
class Application {
public static void main(String[] args) {
TodoService todoService = new TodoService(todoRepository);
}
}
15
Приклад 1.
Впровадження залежності через set-метод
class TodoService {
TodoRepository todoRepository;
void setTodoRepository(TodoRepository todoRepository) {
}
}
class Application {
TodoService todoService = new TodoService();
todoService.setTodoRepository(todoRepository);
}
}
16
Приклад 1.
Впровадження залежності через інтерфейс
class TodoService implements Consumer<TodoRepository> {
@Override
public void accept(TodoRepository todoRepository) {
}
}
class Application {
todoService.accept(todoRepository);
}
}
17
Приклад 1.
Впровадження залежності через властивості
class TodoService {
}
class Application {
todoService.todoRepository = new TodoRepository();
}
}

18
IoC контейнер
IoC Container – бібліотека, фреймворк для реалізації

автоматичного впровадження залежності (Dependency Injection).
1. Create С
IoC Container Object C
2. Create B, Object B
inject C
Object C
Object A
3. Create A,
inject B Object B
Object C

19
Бібліотеки та фреймворки, які реалізують DI
Наведемо ряд бібліотек та фреймворків, які дають змогу

реалізувати DI:
 Spring DI
 Dagger
 Google Guice
 Java EE6 CDI
 PicoContainer

20
Приклад 2. Застосування IoC-контейнера
Згідно з підходом інверсії управління якщо у нас є клієнт, який

використовує певний сервіс, то він повинен робити це не
безпосередньо, а через посередника.
Те, як технічно це буде зроблено, і визначає кожна з реалізацій

підходу IoC.

21
 без інверсії управління
class ScheduleManager
{
public Schedule GetSchedule()
{
// Do Something by init schedule...
}
}
class ScheduleViewer
{
private ScheduleManager _scheduleManager = new ScheduleManager();
public void RenderSchedule()
{
_scheduleManager.GetSchedule();
// Do Something by render schedule...
}
}

22
 використання впровадженням залежностей (DI)
interface IScheduleManager
{
Schedule GetSchedule();
}
class ScheduleManager : IScheduleManager

{
public Schedule GetSchedule()
{
// Do Something by init schedule...
}
}

23
 використання впровадженням залежностей (DI)
class ScheduleViewer
{
private IScheduleManager _scheduleManager;
public ScheduleViewer(IScheduleManager scheduleManager)
{
_scheduleManager = scheduleManager;
}
public void RenderSchedule()
{
_scheduleManager.GetSchedule();
// Do Something by render schedule...
}
}
 далі, там, де ми хочемо скористатися нашим класом для відображення
розкладу ми пишемо:
ScheduleViewer scheduleViewer = new ScheduleViewer(new ScheduleManager());

24
Практично досягли бажаного результату, але що якщо у нас багато

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

25
 створюємо конфігурацію контейнера:
class SimpleConfigModule : NinjectModule

{
public override void Load()
{
Bind<IScheduleManager>().To<ScheduleManager>();
// нижній рядок необов'язковий, ця поведінка стоїть
за замовчуванням:
// тобто клас підставляє сам себе
Bind<ScheduleViewer>().ToSelf();
}
}

26
 створюємо сам контейнер, вказуючи його конфігуратор:
IKernel ninjectKernel = new StandardKernel(new SimpleConfigModule());
// там де потрібно створити екземпляр ScheduleViewer ми замість new,

робимо так:
ScheduleViewer scheduleViewer = ninjectKernel.Get<ScheduleViewer>();
В результаті контейнер сам створить екземпляр класу ScheduleManager, викличе

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

27
Inversion of Dependency Dependency

Control Inversion Injection
concept OOP principle pattern

28
ВИСНОВКИ
 Inversion of Control (інверсія управління) - це деякий

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

актуальних реалізацій - впровадження залежностей (dependency
injection).

29
ПОСИЛАННЯ
1. Understanding Inversion of Control (IoC) Principle

https://medium.com/@amitkma/understanding-inversion-of-control-
ioc-principle-163b1dc97454
2. Внедрение зависимостей в ASP.NET MVC
https://metanit.com/sharp/mvc5/21.1.php

1
Шаблон MVC

2
Концепція MVC
• MVC - Model-View-Controller - це програмний архітектурний

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

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

3
Концепція MVC
• У рамках архітектурного шаблону модель–представлення–
контролер (MVC) програма поділяється на три окремі, але
взаємопов'язані частини з розподілом функцій між компонентами.
• Модель (Model) відповідає за зберігання даних та їх структуру.
• Представлення (View) відповідальне за відображення цих даних
користувачеві, тобто інтерфейс програми.
• Контролер (Controller) керує компонентами, отримує сигнали у
вигляді реакції на дії користувача (зміна положення курсора миші,
натискання кнопки, ввід даних в текстове поле) і передає дані у
модель.

4
Трохи історії
• Концепція MVC була описана Трюгве Реенскаугом в 1978 році,
який працював в науково-дослідному центрі «Xerox PARC» над
мовою програмування «Smalltalk».
• Остаточна версія концепції MVC була опублікована лише в 1988

році в журналі Technology Object.
• Згодом шаблон проектування став еволюціонувати. Наприклад,

була представлена ієрархічна версія HMVC; MVA, MVVM.
• Подальше зростання популярності відбулося завдяки розвитку

фреймворків, орієнтованих на швидку розгортку, на мовах
Python і Ruby, Django і Ruby on Rails відповідно.

Позиція MVC в топі веб-фреймворків 5

6
Ідея MVC
• Основна ідея патерна в тому, що і Контролер, і Представлення залежать від

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

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

7
Приклад застосування MVC
• Ви прийшли в McDonald's, щоб замовити гамбургер.
Model:
Кухня
View: Controller:
Бутерброд Продавець
User:
Ви
• Модель: кухня, на якій кухар робить гамбургер.

• Представлення: готовий бутерброд, який ви із задоволенням їсте.
• Контролер: продавець або касир, який приймає замовлення і
передає його на кухню.
8
Застосування MVC в веб-додатках
• Незважаючи на те, що спочатку MVC був розроблений для

настільних комп'ютерів, він набув широкого поширення в
якості шаблону проектування додатків World Wide Web на
основних мовах програмування.
• Було створено кілька веб-фреймворків, які застосовують

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

9
Застосування MVC в веб-додатках
• У деяких веб-фреймворках MVC використовується підхід

тонкого клієнта, який розміщує майже всю модель,
представлення і логіку контролера на сервері. Це
відображено в таких середовищах, як Django, Rails і ASP.NET
MVC. При такому підході клієнт відправляє або запити
гіперпосилань, або подання форми на контролер, а потім
отримує повну і оновлену веб-сторінку (або інший документ)
з представлення; модель існує повністю на сервері.
• Інші платформи, такі як AngularJS, EmberJS, JavaScriptMVC і

Backbone, дозволяють компонентам MVC частково
виконуватися на клієнті.

10
Цілі MVC
1) Одночасний розвиток
• Оскільки MVC розділяє різні компоненти програми,
розробники можуть працювати паралельно над різними
компонентами, не впливаючи і не блокуючи один одного.
• Наприклад, команда може розділити своїх розробників між
фронт-ендом і бек-ендом. Бек-енд розробники можуть
спроектувати структуру даних і те, як користувач взаємодіє з
ними, не вимагаючи завершення користувацького
інтерфейсу.
• І навпаки, розробники фронт-енду можуть спроектувати і
протестувати макет додатка ще до того, як структура даних
стане доступною.

Цілі MVC 11
2) Повторне використання коду

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

одночасно над моделлю, контролером і представленнями.
• Висока когезія - MVC дозволяє логічно групувати пов'язані
дії на контролері разом. Представлення для конкретної
моделі також згруповані разом.
• Слабкий зв'язок - сама структура MVC така, що існує
малий зв'язок між моделями, представленнями або
контролерами.
• Простота модифікації - через поділ обов'язків майбутня
розробка або модифікація простіша.
• Кілька представлень для моделі - моделі можуть мати
кілька представлень.
13
Недоліки застосування MVC
• Навігація по коду - навігація по фреймворку може бути складною, оскільки
вона вимагає від користувачів адаптації до критеріїв декомпозиції MVC.
• Консистенція декількох артефактів - розбивка об'єкта на три артефакти
призводить до розсіювання. Таким чином, потрібно, щоб розробники
підтримували узгодженість декількох представлень одночасно.
• Надлишковий шаблон - через те, що обчислення додатку і стан зазвичай
об'єднуються в одну з 3 частин, інші частини вироджуються в шаблонні
прокладки або кодовий елемент, який існує тільки для відповідності шаблону
MVC.
• Яскраво виражена крива навчання - знання декількох технологій стає
нормою. Розробники, що використовують MVC, повинні бути досвідченими у
багатьох технологіях.
• Відсутність додаткових переваг - додатки для користувача інтерфейсу вже
розділені на компоненти і забезпечують повторне використання коду і
незалежність за допомогою архітектури компонентів, не залишаючи ніяких
додаткових переваг для MVC.
14
Типові помилки застосування MVC
• Початківці програмісти дуже часто трактують архітектурну

модель MVC як пасивну модель MVC: модель виступає
виключно сукупністю функцій для доступу до даних, а
контролер містить бізнес-логіку.
• В результаті - код моделей за фактом є засобом отримання
даних з СУБД, а контролер - типовим модулем,
наповненим бізнес-логікою.
• В результаті такого розуміння - MVC-розробники стали
писати код, який Pádraic Brady охарактеризував як Fat
Stupid Ugly Controllers («Товсті, тупі, потворні
контролери»).

Особливості шаблону MVC 15
• Пасивна модель - лише контролер

маніпулює моделлю. Контролер
змінює модель, а потім інформує
представлення, що модель була
змінена, і представлення треба
оновити.
• Модель у цьому сценарії повністю
незалежна від представлення та
контролера, що означає, що для
моделі немає можливостей
повідомляти про зміни в її стані.
• Протокол HTTP є прикладом цього.
У браузері немає простих способів
отримання асинхронних оновлень з
сервера. Браузер відображає
представлення і реагує на ввід
користувача, але не виявляє змін у
даних на сервері. Тільки тоді, коли
користувач явно запитує оновлення - © Іванюк О.О., КСА, НУЛП, 2020
сервер проводить запит змін.
Особливості шаблону MVC 16
• Активна модель використовується,

коли модель змінює стан без участі
контролера. Це може статися, коли
інші джерела змінюють дані, і зміни
повинні відображатися в
представленнях.
• Розглянемо біржову індикацію. Ви
отримуєте дані про запас із
зовнішнього джерела та хочете
оновити представлення даних
(наприклад, діапазон тікера та вікно
оповіщення), коли дані про фондові
дані змінюються. Оскільки тільки
модель виявляє зміни свого
внутрішнього стану, коли вони
виникають, то модель повинна
повідомити представлення, щоб
оновити відображення даних.
17
Шаблон MVP (Model-View-Presenter)
• Model-View-Presenter (MVP) – архітектурний шаблон
проектування, похідний від MVC, який використовується в
основному для побудови користувацького інтерфейсу.
• Елемент Presenter в даному шаблоні бере на себе
функціональність посередника (аналогічно контролеру в MVC) і
відповідає за управління подіями користувацького інтерфейсу
(наприклад, використання миші) аналогічно, як в інших шаблонах
зазвичай відповідає представлення. Містить всю бізнес-логіку.

Шаблон MVP (Model-View-Presenter) 18
• MVP - шаблон проектування користувацького

інтерфейсу, який був розроблений для
полегшення автоматичного модульного
тестування та вдосконалення розділення
відповідальності в презентаційній логіці
(відділення логіки від відображення)
• В представленні View не потрібно описувати
зміни моделі, тепер Presenter, дозволяє
переглянути інформацію про зміни.
• Цей підхід дозволяє створити абстракцію
представлення.
• Цей підхід дозволяє нам розробляти додатки,
використовуючи методологію TDD (Test-driven
development).

Шаблон MVP (Model-View-Presenter) 19
• Для того, щоб створити абстракцію

представлення, необхідно виділити інтерфейс
представлення з певним набором властивостей
і методів. Презентер, в свою чергу, отримує
посилання на реалізацію інтерфейсу,
підписується на події представлення і за
запитом змінює модель.
Ознаки презентера:
• Двостороння комунікація з представленням;
• Представлення взаємодіє безпосередньо з
презентером, шляхом виклику відповідних
функцій або подій екземпляра презентера;
• Презентер взаємодіє з View шляхом
використання спеціального інтерфейсу,
реалізованого представленням.
20
Шаблон MVVM (Model-View-ViewModel)
• Патерн MVVM (Model-View-ViewModel) дозволяє відокремити логіку
додатка від візуальної частини (представлення). Даний патерн є
архітектурним, тобто він задає загальну архітектуру програми.
• MVVM був представлений Джоном Госсманом (John Gossman) в 2005 році
як модифікація шаблону Presentation Model і був спочатку націлений на
розробку додатків в WPF. Але зараз цей патерн вийшов за межі WPF і
застосовується в самих різних технологіях, в тому числі при розробці під
Android, iOS.
• MVVM зручно використовувати замість класичного MVC в тих випадках,
коли в платформі, на якій ведеться розробка, є «зв'язування даних». У
шаблонах проектування MVC/MVP зміни в інтерфейсі не впливають
безпосередньо на Mодель, а попередньо йдуть через Контролер або
Presenter. У таких технологіях як WPF і Silverlight є концепція «зв'язування
даних», що дозволяє пов'язувати дані з візуальними елементами в обидві
сторони. Отже, при використанні цього прийому застосування моделі MVC
стає вкрай незручним через те, що безпосередня прив'язка даних до
представлення не вкладається в концепцію MVC / MVP.
21
Шаблон MVVM (Model-View-ViewModel)
• Модель (Model) (так само, як в класичній MVC) являє собою логіку роботи з
даними і опис фундаментальних даних, необхідних для роботи програми.
• Представлення (View) - графічний інтерфейс (вікна, списки, кнопки і т. п.).
Виступає підписником на події зміни значень властивостей або команд, що
надаються Моделлю Представлення. У разі, якщо в Моделі Представлення
змінилася якась властивість, то вона сповіщає всіх підписників про це, і
Представлення, в свою чергу, запитує оновлене значення властивості з Моделі
Представлення. У разі, якщо користувач впливає на який-небудь елемент
інтерфейсу, Представлення викликає відповідну команду, надану Моделлю
Представлення.
• Модель Представлення (ViewModel) - з одного боку, абстракція
Представлення, а з іншого - обгортка даних з Моделі, які треба зв'язувати.
Тобто, вона містить Модель, перетворену до Представлення, а також команди,
якими може користуватися Представлення, щоб впливати на Модель.

22
Приклад застосування
MVC

23
Створення проекту MVC

24
Створення проекту MVC

Структура проекту 25

26
Створення контролера

27
Реалізація контролера

28
Створення представлення

29
Представлення Index.cshtml

30
RouteConfig.cs

31
Method with parameters

32
ПОСИЛАННЯ
1. ASP.NET MVC 5
https://metanit.com/sharp/mvc5/1.1.php
2. MVC Framework Tutorial
https://www.tutorialspoint.com/mvc_framework/index.htm

1
Шаблони GRASP
“Документування програмного забезпечення © Іванюк О.О., Павельчак А.Г.,

та шаблони проектування” КСА, НУЛП, 2020
2
Походження терміну
• Термін GRASP вперше з’являється в книзі

канадського комп’ютерного науковця Крейга
Лармана «Застосування UML і шаблонів
проектування».
• GRASP (General Responsibility Assignment

Software Patterns) – шаблони (принципи), які
використовуються в об'єктно-орієнтованому
проектуванні для вирішення спільних завдань
щодо призначення відповідальностей класів і
об'єктів.

3
Особливості GRASP
• На відміну від класичних патернів проектування GoF, GRAPS патерни

не мають:
- вираженої структури
- чіткої області застосування
- конкретної розв'язуваної проблеми
• GRASP представляють собою узагальнені патерни (підходи,

рекомендації, принципи), які використовуються при проектуванні
дизайну системи.

4
Особливості GRASP. Відповідальність
(Responsibility)
• Відповідальність може бути:
– виконана одним об'єктом.
– група об'єктів спільно виконує відповідальність.
GRASP допомагає нам:
• вирішити, яка відповідальність повинна бути покладена на який

об’єкт / клас
• визначити об'єкти та обов'язки з проблемної області, а також

визначити, як об’єкти взаємодіють між собою.
• визначити шаблон для цих об'єктів - наприклад, клас із

методами, що реалізують ці обов'язки.
5
Шаблони GRASP
До складу GRASP входить 9 шаблонів:

• Information Expert (Інформаційний експерт)
• Creator (Творець)
• Controller (Контролер)
• Low Coupling (Слабка зв'язність)
• High Cohesion (Висока згуртованість)
• Pure Fabrication (Чиста вигадка чи чистий синтез)
• Indirection (Посередник)
• Polymorphism (Поліморфізм)
• Protected Variations (Приховування реалізації або захищені зміни)

6
Information Expert (інформаційний експерт)
• Проблема: Який основний принцип, за яким можна розподіляти обов'язки

між об'єктами?
• Рішення: Відповідальність повинна бути призначена тому, хто володіє

максимумом необхідної інформації для виконання - інформаційному
експерту.
• Застосування шаблону інформаційний експерт підвищує зв'язність модулів і

не суперечить властивості інкапсуляції.

7
Information Expert (інформаційний експерт)
• У наступному прикладі клас Customer містить посилання на всі замовлення

клієнтів, тому закономірно, щоб він взяв на себе відповідальність за
обчислення загальної вартості замовлень:
public class Customer

{
private readonly List<Order> _orders = new List<Order>();
public decimal GetTotalAmount(Guid orderId)
{
return this._orders.Sum(x => x.Amount);
}
}

8
Creator (творець)
• Проблема: “Хто” повинен відповідати за створення екземплярів класу?
• Рішення: Клас B повинен (може) відповідати за створення екземплярів

класу A, якщо застосовується одне або, переважно, кілька з наступного:
- еземпляри B містять або агрегують екземпляри A;
- еземпляри B записують екземпляри A;
- еземпляри B тісно використовують екземпляри A;
- еземпляри B мають ініціалізуючу інформацію для екземплярів A і

передають її при створенні.
• Основна ідея: Творець повинен в будь-якому випадку зберігати посилання і

буде часто використовувати створений об'єкт

9
public class Customer

{
private readonly List<Order> _orders = new List<Order>();
public void AddOrder(List<OrderProduct> orderProducts)
{
var order = new Order(orderProducts); // творець
_orders.Add(order);
}
}

10
• Переваги: Використання цього патерну не підвищує зв'язності,

оскільки створений клас, як правило, видно тільки для класу - творця.
• Недоліки: Якщо процедура створення об'єкта досить складна

(наприклад, виконується на основі якоїсь зовнішньої умови), логічно
використовувати патерн "Абстрактна Фабрика", тобто, делегувати
обов'язок створення об'єктів спеціальному класу.

11
Controller (контролер)
• Проблема: Як делегувати запит від об'єктів рівня UI до об'єктів рівня

домену?
• Рішення: Коли запит надходить від об'єкта рівня UI, шаблон Controller
допомагає нам визначити, що це за перший об'єкт, який отримує
повідомлення від об'єктів рівня UI.
• Об'єкт називається об'єктом контролера, який отримує запит від об'єкта

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

загальну активність.

12
Bloated Controllers (роздуті контролери)
• Ми можемо зробити об'єкт в якості контролера, якщо

- об'єкт являє всю систему (контролер фасаду);
- об'єкт являє собою сценарій використання, що обробляє
послідовність операцій (контролер сеансу).
• Переваги:
- можна повторно використовувати цей клас контролера.
- можна використовувати для підтримки стану варіанта використання.
- може контролювати послідовність дій

13
Controller (контролер). Приклад

14
Controller (контролер). Приклад

15
Coupling & Cohesion

16
Coupling & Cohesion
• Зв'язність (Coupling) - стосується відносин між модулями

(класами)
• Згуртованість (Cohesion) - стосується відносин всередині

модуля (класу)
• Мета: ми хочемо мати слабкозв'язані модулі (класи)

з високою внутрішньою зв'язністю

17
Low Coupling (Слабка зв'язність)
• Проблема: Як зменшити зв’язність між об’єктами в додатку? Як збільшити

повторне використання та зменшити вплив змін?
• Рішення: У нашому додатку ми повинні створити якомога меншу кількість

посилань між об'єктами. Ми можемо досягти цього шляхом розумного
розподілу відповідальності.
• Два елементи зв’язані, якщо

– один елемент має агрегацію/композицію з іншим елементом.
– один елемент реалізує/наслідує інший елемент.

18
• Зв'язність позначає те, наскільки клас знає про інші класи.
• Існує два типи зв'язності:

- Міцна (висока) зв'язність ( Tight (High) Coupling ) - невдалий дизайн
програмування
- Слабка (низька) зв'язність ( Loose (Low) Coupling) - хороший дизайн
програмування

19
Tight (High) Coupling
Якщо клас A має кілька членів публічних даних, а інший клас B

отримує доступ до цих членів безпосередньо за допомогою
оператора “точка”, кажуть, що ці два класи міцно зв‘язані (tightly
coupled).
class A class B

20
Tight (High) Coupling. Приклад
class A {
public String name;
public String getName() {
if (name != null) return name;
else return "not initiaized";
Checking a valid }
access to "name"
public void setName(String name) {
if (name == null) System.out.println("You can't initialized name to a null");
else this.name = name;
}
}
Directly setting
class B {
the value of data
public static void main(String... arg) {
member of class A
A obj = new A();
obj.name = null;
System.out.println("Name is " + obj.name);
Direct access of data }
member of class A }
Output:
Name is null
21
Хорошим дизайном додатків є створення аплікації зі слабко

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

22
class A {
private String name;
public String getName() {
if (name != null) return name;
else return "not initiaized";
Checking a valid }
access to "name"
public void setName(String name) {
if (name == null) System.out.println("You can't initialized name to a null");
else this.name = name;
}
}
Calling setter method,
class B {
as the direct access of
public static void main(String... arg) {
"name" is not possible
A obj = new A();
obj.setName(null);
System.out.println("Name is " + obj.getName());
}
Calling getter method,
}
as the direct access of
"name" is not possible Output:
You can't initialized name to a null
Name is not initiaized
23
Tight (High) Coupling

24
• Програмуйте на основі абстракцій (інтерфейс, абстрактний

клас і т.п.), а не реалізацій

25
High Cohesion (Висока згуртованість)
• Проблема: Як забезпечити можливість управління складністю?
• Рішення: Забезпечити розподіл обов'язків з високим ступенем

згуртованості (зачеплення)
• Об'єкт має високий ступінь згуртованості, якщо його обов'язки

тісно пов'язані між собою і він не виконує величезних обсягів
роботи.
• Antipattern: God object

26
Cohesion (згуртованість)
• Згуртованість означає ступінь, в якій клас визначений для виконання
конкретного спеціалізованого завдання.
• Існує два типи згуртованості:
- низька згуртованість (Low cohesion) - невдалий дизайн програмування
- висока згуртованість (High Cohesion) - хороший дизайн програми
• Клас, створений з високою згуртованістю, орієнтований на єдину

конкретну мету, а не виконання багатьох різних конкретних цілей.
27
• Низька згуртованість відноситься до модулів, які мають різні незв'язані
між собою обов'язки.
• Висока згуртованість відноситься до модулів, які мають багато в чому

подібні функції.
Low cohesion High cohesion

class Editor { class Editor {
public void editBooks() { /* ... */ } public void useEditTools() { /* ... */ }
public void manageBookPrinting() { /* ... */ } public void editFirstDraft() { /* ... */ }
public void reachOutToNewAuthors() { /* ... */ } public void clearEditingDoubts() { /* ... */ }
} }
Редактор виконує Редактор виконує

різноманітний набір кілька, але пов'язаних
непов'язаних завдань
завдань

28
Сценарії:
• Дуже низька згуртованість: клас несе повну відповідальність за багато речей
в самих різних функціональних областях
• Низька згуртованість: клас несе одноосібну відповідальність за складну
задачу в одній функціональної області.
• Висока згуртованість. Клас має помірну відповідальність в одній
функціональній області і співпрацює з іншими класами для виконання
завдань.
Переваги:
• Класи легше підтримувати
• Легше зрозуміти
• Часто підтримують низьку зв'язність (low coupling)
• Підтримує повторне використання через тонку відповідальність
Емпіричне правило: клас з високим ступенем згуртованості має відносно
невелику кількість методів, з тісно пов'язаною функціональністю і не виконує
занадто багато роботи.
29
Pure Fabrication (Чиста вигадка чи чистий синтез)
• Проблема: Який клас повинен забезпечувати реалізацію патернів "Низька
зв'язність" і "Висока згуртованість"?
• Рішення: Клас, що не відображає ніякої реальної сутності предметної

області, але спеціально придуманий для підсилення згуртованості,
послаблення зв'язності або збільшення ступеня повторного використання.
• Переваги: Новостворений клас буде володіти низьким ступенем зв'язності і

високим ступенем згуртованості.
• Недоліки: Даним патерном не слід зловживати інакше всі функції системи

перетворяться в об'єкти.

30
Pure Fabrication. Приклад
• Який клас повинен зберігати екземпляри класу “Sale" в реляційній базі
даних?
• Якщо покласти цей обов'язок на клас “Sale", то будемо мати низьку ступінь
згуртованості і високий ступінь зв'язності (оскільки клас “Sale" повинен бути
пов'язаний з інтерфейсом реляційної бази даних).
• Зберігання об'єктів в реляційній базі даних це загальне завдання, яке

доведеться вирішувати для багатьох класів.
• Рішенням даної проблеми буде створення нового класу "SaleRepository",

відповідального за збереження об'єктів деякого виду в базі даних.
SaleRepository
SaveObject()
UpdateObject()
31
Indirection (Посередник)
• Проблема: Як визначити відповідальність об'єкта і уникнути сильної

зв'язності між об'єктами, навіть якщо один клас потребує функціоналу
(сервісів), якого надає інший клас?
• Рішення: Покладіть відповідальність на проміжний об'єкт, щоб він

здійснював зв'язок між іншими компонентами або службами, щоб вони
не були безпосередньо пов'язані.
• Таке рішення можна реалізувати за допомогою GoF паттерна медіатор
• Приклад: В архітектурі Model-View-Controller, контролер (Controller)

послаблює зв'язність даних (Model) з їх представленням (View).

32
Polymorphism (Поліморфізм)
• Проблема: Як обробляти альтернативні варіанти поведінки на
основі типу?
• Рішення: Коли пов'язані альтернативи або поведінки

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

орієнтованого дизайну. У цьому контексті принцип тісно
пов'язаний із патерном Стратегія.

33
Polymorphism (Поліморфізм)
• Приклад

34
Protected Variations (Приховування реалізації або
захищені зміни)
• Проблема: Як спроектувати об’єкти, підсистеми та

системи так, щоб зміни або нестабільність цих елементів
не мали небажаного впливу на інші елементи?
• Рішення: Визначте точки передбачуваної зміни чи

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

35
Protected Variations (Приховування реалізації або
захищені зміни)
• Приклад


10 Lectures PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

10 Lectures PDF

Uploaded by

Copyright:

Available Formats

1

“Документування програмного забезпечення

“Документування програмного забезпечення

Метою викладання дисципліни є отримання необхідних знань про основні

Результати навчання полягають в отримані знань про:

“Документування програмного забезпечення

Архітектура: «Мистецтво або наука будівництва; перш за все,

Архітектура програми або комп'ютерної системи - це структура або

Архітектура програмного забезпечення системи або набору систем

“Документування програмного забезпечення

“Документування програмного забезпечення

• Позитивний досвід - повторення його в наступних роботах.

• Негативний досвід - відмова використовувати його в

• Архітектори люблять експериментувати з новими

“Документування програмного забезпечення

Вплив на архітектуру чинить технічна база

Підготовка та досвід архітектора виявляється, зокрема, в

“Документування програмного забезпечення

“Документування програмного забезпечення

“Документування програмного забезпечення

• створення економічної моделі системи;

“Документування програмного забезпечення

Компонент - абстрактна одиниця інструкцій

“Документування програмного забезпечення

Конектор - абстрактний механізм, що слугує

“Документування програмного забезпечення

Будівельні елементи архітектури ПЗ - дані

Дані - елемент інформації, що передається від

“Документування програмного забезпечення

Приклад архітектурного опису

“Документування програмного забезпечення

• Архітектурний зразок – це опис типів елементів і відношень і викладення ряду

“Документування програмного забезпечення

“Документування програмного забезпечення

“Документування програмного забезпечення

1. Її важко змінити, оскільки будь-яка зміна впливає на занадто велику

2. При внесенні змін несподівано ламаються інші частини системи.

3. Код важко використовувати повторно в іншому додатку, оскільки його

“Документування програмного забезпечення

“Документування програмного забезпечення

Архітектурний стиль, іноді називають архітектурним шаблоном

Архітектурний стиль покращує секціонування і сприяє повторному

“Документування програмного забезпечення

Класифікація архітектурних стилів

Прийнято виділяти 12 базових архітектурних стилів, які діляться

1. Потоки даних (Data Flow Systems);

2. Виклик з поверненням (Call-and-Return Systems);

3. Незалежні компоненти (Independent Component Systems);

4. Централізовані дані (Data-Centric Systems);

5. Віртуальні машини (Virtual Machines).

“Документування програмного забезпечення

До систем, що працюють за принципом потоків даних,

“Документування програмного забезпечення

Архітектурний опис будується як (або є) зв'язна сукупність фільтрів

“Документування програмного забезпечення

До них зазвичай відносять системи, побудовані за принципом

• програма-співпрограми (Main Program and Subroutines)

• клієнт-серверні системи (Client-Server Systems)

• об'єктно-орієнтовані системи (Object-Oriented Systems)

• ієрархічні багаторівневі системи (Hierarchically Layered Systems)

“Документування програмного забезпечення

Для розподілених систем типовий випадок застосування

“Документування програмного забезпечення