Лекція 03 _ Принципи та фундаментальні питання проектування

Паралелізм

Паралельні обчислення

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

Паралельний алгоритм

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

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

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

Одночасні події

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

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

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

Ціль паралелізму

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

Приклад 01

Проблема зменшення ваги

Проблема зменшення ваги - дві параллельно виконуємі задачі:

- дієта

- фізичне навантаження

Для вирішення цієї проблеми треба застосовувати строгу дієту та фізичні навантаження в той самий інтервал часу (але НЕ обовязково в ті самі моменти часу).

Приклад 02

Веб-сайту важливо якнайдовше утримувати користувачів

Тому важливо не те наскільки швидко відбуватиметься підключення користувачів, а скільки користувачів ОДНОЧАСНО може зайти на сайт. Відповідно ціль проектування ПЗ такого сайту - обробка максимальної кількості підключень.

Підходи до отримання паралельності

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

Паралельне програмування

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

Розподілене програмування

Методи розподіленого програмування дозволяють розподілити роботу програми між двома чи більше процесами.

Типічна архітектура побудови паралельної та розподіленої програм:

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

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

Приклад

Контроль та обробка подій

Подія

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

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

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

Події - це повідомлення, що отримуються або передаються об'єктом іншим об'єктам або додаткам. Події дозволяють об'єктам виконувати дії при кожному входженні. Прикладом події для класу «Автомобіль» може служити «Перевірка_двигуна». Події можуть поступати з інших об'єктів, додатків або від користувача (наприклад, клацання мишею або натиснення клавіші).

Надійність ПЗ

Надійність ПЗ

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

Система стійка до відмов

система, що зберігає працездатність в результаті видалення наслідків помилок ПЗ

Помилка ПЗ

програмний дефект, що може призвести до відмови в роботі деякої частини ПЗ

Стійкість до відмов

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

Деякі відмови ПЗ є результатами дефектів в програмах, інші - результатами виключних умов

Виключна умова (виключення)

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

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

Схема рівнів складності стійкості до відмов

Рівень 1

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

Рівень 2

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

Рівень 3

Помилки та виключення, що виникають при взаємодії процесів які виконуються на одному комп’ютері

Рівень 4

Помилки та виключення, що виникають при взаємодії процесів які виконуються на декількох комп’ютерах, але в одні мережі

Рівень 5

Помилки та виключення, що виникають при взаємодії процесів які виконуються на декількох комп’ютерах, але в різних мережах (з різними протоколами)

Обробка помилок, виключень та небажаних умов

Характеристики обробки помилок, виключень та небажаних умов

Обробка помилок

Логічні помилки - виявляються на етапі тестування та відладки

Коректно працюючі програми не містять помилок

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

Підтримується нормальний хід виконання програми

Обробка виключень

Описує непередбачені умови під час виконання

Коректно написані програми можуть потрапляти у виключні ситуації

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

Нормальний хід виконання програми порушується

Обробка небажаних умов

Описує небажані умови, які цілком імовірні під час виконання

Коректно написані програми можуть потрапляти в небажані ситуації

Для виправлення небажаних умов використовується програмна логіка

Робиться спроба підтримати нормальний хід виконання прграми

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

Відновлення та корекція працездатності додатків

запит користувачу повторного вводу даних,

повторна обробка файлів,

повернення із бази даних,

зміна мережевого маршруту,

повторна ініціалізація приладів,

перезавантаження підсистеми ПЗ тощо.

Спрощений компонент обробки помилок

Діаграми подій

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

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

Рисунок

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

Якщо буде відмова в задачах А чи С, то програма згенерує виключення. І аналогічно по іншим гілкам. Проте видно, що завершення програми буде успішним, якщо буде успішним виконання хоча б однієї з гілок. Тому слід проектувати обробник виключень таким чином, аби він виконував один зі альтернативних наборів компонентів.

Рисунок

Цілісність даних

Повнота даних

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

Цілісність даних

Цілісність даних означає коректність даних і їх несуперечність

Інкапсуляція

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

Користувач може взаємодіяти з об'єктом лише через цей інтерфейс. Користувач не може використовувати закриті дані і методи.

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

Приховання реалізації доцільно застосовувати в наступних випадках:

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

Лекція 04

Повторне використання коду

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

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

Модульність систем

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

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

Повторне використання в малому

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

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

Повторне використання коду та метасистемний перехід у програмуванні

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

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

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

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

Шаблони проектування

Шаблон проектування або паттерн

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

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

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

Правильно сформульований шаблон проектування дозволяє, відшукавши вдале рішення, користуватися ним знову й знову.

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

Структура шаблону

Ім'я

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

Завдання

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

Рішення

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

Результати

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

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

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

Опис шаблонів проектування

Назва й класифікація шаблону

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

Призначення

Лаконічна відповідь на наступні питання:

Відомий також під ім'ям

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

Мотивація

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

Застосовність

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

Структура

Графічне подання класів у шаблоні з використанням нотації, заснованої на методиці Object Modelіng Testіng (ОМТ) та на діаграмах взаємодій для ілюстрації послідовностей запитів і відносин між об'єктами.

Учасники

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

Відносини

Взаємодія учасників для виконання своїх функцій.

Результати

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

Реалізація

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

Приклад коду

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

Відомі застосування

Можливості застосування шаблону в реальних системах.

Шаблони родичі

Зв'язок інших шаблонів проектування з даним. Важливі розходження. Використання даного шаблону в сполученні з іншими.

Каталог шаблонів проектування

Abstract factory (абстрактна фабрика)

Надає інтерфейс для створення сімейств, зв'язаних між собою, або незалежних об'єктів, конкретні класи яких невідомі.

Adapter (адаптер)

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

Brіdge (міст)

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

Buіlder (будівельник)

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

Chaіn of responsіbіlіty (ланцюжок обов'язків)

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

Command (команда)

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

Composіte (компоновщик)

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

Decorator (декоратор)

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

Facade (фасад)

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

Factory method (фабричний метод)

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

Flyweіght (пристосованець)

Використає поділ для ефективної підтримки великої кількості дрібних об'єктів.

Іnterpreter (інтерпретатор)

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

Іterator (ітератор)

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

Medіator (посередник)

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

Memento (хранитель)

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

Observer (спостерігач)

Визначає між об'єктами залежність типу 1→M (один-до-багатьох), так що при зміні станe одного об'єкта всі залежні від нього одержують повідомлення s автоматично обновляються.

Prototype (прототип)

Описує види створюваних об'єктів за допомогою прототипу й створює нові об'єкти шляхом його копіювання.

Ргоху (заступник)

Підмінює інший об'єкт для контролю доступу до нього.

Sіngleton (одинак)

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

State (стан)

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

Strategy (стратегія)

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

Template method (шаблоновий метод)

Визначає кістяк алгоритму, перекладаючи відповідальність за деякі його кроки на підкласи. Дозволяє підкласам перевизначати кроки алгоритму, не міняючи його загальної структури.