О.О.П / ооп / 3_техн / Лекції / Лекція 2 у

Лекція 2:

Тема: Основні принципи і етапи об'єктно-орієнтованого програмування

План:

1.Принципи об'єктно-орієнтованого програмування.

2.Об'єктно-орієнтовані мови програмування.

3.Етапи розробки програмних систем з використанням ООП.

1. Принципи об'єктно-орієнтованого програмування

У теорії програмування ООП визначається як технологія створення складного

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

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

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

повідомлень (мал. 1).

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

імітаційного моделювання складних систем Simula, що з'явився ще в 60-х роках.

Природний для мов моделювання спосіб представлення програми отримав розвиток в іншій спеціалізованій мові моделювання - мові Smalltalk (70-і роки), а потім був використаний в нових версіях універсальних мов програмування, таких як Pascal, C++,

Ада, Modula.

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

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

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

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

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

У основу ООП покладені наступні принципи: абстрагування, обмеження

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

1

Розглянемо, що є кожним принципом.

Объект 1

Данные

Объект 1

Данные

Подпрограммы с локальными данными

Мал. 1. Архітектура програми при ООП

Абстрагування - процес виділення абстракцій в наочній області завдання.

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

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

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

Обмеження доступа- заховання окремих елементів реалізації абстракції, що не

зачіпають істотних характеристик її як цілого.

Необхідність обмеження доступу припускає розмежування двох частин в описі

абстракції:

2

інтерфейс - сукупність доступних ззовні елементів реалізації абстракції (основні характеристики стану і поведінки);

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

(внутрішня організація абстракції і механізми реалізації її поведінки).

Обмеження доступу в ООП дозволяє розробникові:

1.виконувати конструювання системи поетапно, не відволікаючись на

особливості реалізації використовуваних абстракцій;

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

організованій системі не зажадає зміни інших об'єктів.

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

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

Модульність - принцип розробки програмної системи, що припускає реалізацію

її у вигляді окремих частин (модулів). При виконанні декомпозиції системи на модулі

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

кількості зовнішніх зв'язків між модулями. Принцип успадкований від модульного

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

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

У ООП використовуються два види ієрархії:

Ієрархія «целое/часть» - показує, що деякі абстракції включені в дану

абстракцію як її частини, наприклад, лампа складається з цоколя, нитки розжарення і

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

на фізичному рівні - при декомпозиції системи на модулі і при виділенні окремих процесів в мультипроцессной системі).

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

уточнення тих, що є.

Один з найважливіших механізмів ООП - спадкоємство властивостей в

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

3

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

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

Використання принципу типізації забезпечує:

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

програмними об'єктами (помилки виявляються на етапі компіляції програми при перевірці допустимості виконання даної операції над

програмним об'єктом);

2.спрощення документування;

3.можливість генерації ефективнішої коди.

Тип може зв'язуватися з програмним об'єктом статично (тип об'єкту визначений

на етапі компіляції - раннє скріплення) і динамічно (тип об'єкту визначається тільки під

час виконання програми - пізнє скріплення). Реалізація пізнього скріплення в мові

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

класам (поліморфні об'єкти), що істотно розширює можливості мови.

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

Існує цілий ряд завдань, вирішення яких вимагає одночасного виконання деяких

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

управління декількома процесами.

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

часу процесора між завданнями управління різними процесами. Залежно від типу використовуваної операційної системи (одноабо мультипрограмною) розділення часу може виконуватися або системою (як в MS DOS), що розробляється, або використовуваною ОС (як в системах Windows).

Стійкість - властивість абстракції існувати в часі незалежно від процесу,

породжувача даний програмний об'єкт, і/або в просторі, переміщаючись з адресного

простору, в якому він був створений.

Розрізняють:

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

наприклад обчислень;

4

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

3.глобальні об'єкти, що існують поки програма завантажена в пам'ять;

4.сохраняемые объекты, данные которых хранятся в файлах внешней памяти между сеансами работы программы.

Всі вказані вище принципи в тому або іншому ступені реалізовані в різних версіях

об'єктно-орієнтованих мов.

2. Об'єктно-орієнтовані мови програмування

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

Примітка. Окрім цього, в теорії програмування прийнято розрізняти об'єктно-

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

об'єктна мова, а C++ і об'єктні версії Паскаля - об'єктно-орієнтовані.

Не дивлячись на те, що принципово ООП можливо на багатьох мовах

програмування, бажано для створення об'єктно-орієнтованих програм використовувати

об'єктно-орієнтовані мови, що включають спеціальні засоби, наприклад, Borland Pascal

(починаючи з версії 5.5), C++, Delphi і так далі

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

Найпростіша об'єктна модель використана при розробці Borland Pascal 7.0. Вона

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

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

Особливе місце займають об'єктні моделі Delphi і C++Builder. Ці моделі узагальнюють досвід ООП для MS DOS і включають деякі нові засоби, що забезпечують ефективне створення складніших систем. На базі цих моделей створені візуальні середовища для розробки застосувань Windows. Складність програмування

під Windows вдалося істотно понизити за рахунок створення спеціальних бібліотек об'єктів, що «заховали» багато елементів техніки програмування.

3. Етапи розробки програмних систем з використанням ООП

Процес розробки програмного забезпечення з використанням ООП включає чотири етапи: аналіз, проектування, еволюція, модифікація.

Розглянемо ці етапи.

5

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

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

також виконується опис абстракцій.

Проектування. Розрізняють:

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

устаткування);

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

Логічне проектування полягає в розробці структури класів: визначаються поля

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

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

класів (спадкоємство, композиція, наповнення, поліморфізм і так далі). Результатом є

ієрархія або діаграма класів, що відображають взаємозв'язок класів, і опис класів.

Фізичне проектування включає об'єднання описів класів в модулі, вибір схеми їх підключення (статична або динамічна компоновка), визначення способів взаємодії з устаткуванням, з операційною системою і/або іншим програмним забезпеченням

(наприклад, базами даних, мережевими програмами), забезпечення синхронізації

процесів для систем паралельної обробки і так далі

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

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

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

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

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

6

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

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

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

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

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

витрачаються величезні тимчасові і матеріальні ресурси.

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

інтерфейсні класи вже реалізовані, а структура класів наочної області ще тільки

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

області досить повно описаний в процесі аналізу.

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

Об'єктна декомпозиція Як вже згадувалося вищим, при використанні технології ООП рішення

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

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

завдання.

У такій системі кожен функціональний елемент, отримавши деяку вхідну дію

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

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

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

Функціональні елементи системи, параметри і поведінка якої визначаються умовою завдання, що володіють самостійною поведінкою (тобто що «уміють»

виконувати деякі дії, залежні від отриманих повідомлень і стану елементу), отримали назву об'єктів.

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

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

7

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

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

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

заявок на заправку паливом (розглядаємо паливо одного типу).

Завдання такого вигляду зазвичай вирішуються з використанням імітаційних

моделей. Модель програмно імітує реальний процес із заданими параметрами,

паралельно фіксуючи його характеристики. Багато разів повторюючи процес імітації з

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

Процес роботи бензоколонки з трьома заправними місцями можна представити у

вигляді малюнка.

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

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

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

виконуватися таким чином.

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

який ми зможемо визначити час надходження наступної автомашини.

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

У циклі імітації модель бензоколонки опитуватиме модель потоку машин і блок колонок, яка подія відбудеться раніше: прийде наступна автомашина або звільниться

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

8

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

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

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

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

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

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

Модель

потока

автомашин

Мал. 2. Діаграма об'єктів імітаційної моделі бензоколонки

Отриману модель можна реалізувати у вигляді об'єктно-орієнтованої програми.

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

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

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

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

цього виконаємо декомпозицію об'єкту Блок колонок.

9

Приклад Декомпозиція об'єкту (Блок колонок). Модель блоку колонок повинна включати моделі колонок і деякий об'єкт, що управляє, який назвемо Монітором.

Монітор, отримавши повідомлення, інтерпретує його і при необхідності генерує

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

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

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

(мал. 3).

Занять колонку

Когда освободитсяколонка?

Активизировать

Вільно?

Мал. 3. Об'єктна декомпозиція Блоку колонок:

1- коли звільниться колонка? 2- звільнити колонку; 3 - колонка вільна? 4 - зайняти колонку

Безумовно, це не єдиний варіант декомпозиції об'єкту Блок колонок. За бажання

можна знайти інші механізми реалізації тієї ж поведінки. Вибір конкретного варіанту в

кожному випадку здійснюється розробником.

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

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

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

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

Приклад Простий графічний редактор Здійснимий об'єктну декомпозицію

програми, яка по запиту користувача малює одну з двох фігур: квадрат або круг. За

бажання користувач повинен мати можливість змінити колір контура, розмір фігури і

координати її центру.

10