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

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

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

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

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

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

Цілком система буде складатися з безлічі об'єктів: читачі, книги, сховище, бібліотекар і т. Д. Ці об'єкти взаємодіють між собою, посилаючи один одному повідомлення. Наприклад, читач може отримати повідомлення про необхідність здати книгу (оскільки добігає кінця термін, на який вона видана) і у відповідь виконати операцію "здати". Іншим прикладом повідомлення може бути питання бібліотекаря до читача: "Як Вас звати?". Щоб правильно відреагувати на таке повідомлення, об'єкту "читач" необхідно мати операцію "назвати своє ім'я".

В системі зазвичай функціонує безліч об'єктів одного класу. Читачі Іванов, Петров і Сидоров - екземпляри класу "читач". Всі екземпляри одного і того ж класу мають один і той же набір операцій і можуть реагувати на одні і ті ж повідомлення. Клас іноді називають типом об'єктів. Клас в певному сенсі відповідає поняттю абстрактного типу даних, введеному в програмування досить давно, ще в мові Модула-2.

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

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

Таким чином, класи утворюють ієрархію, показану на малюнку.

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

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

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

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

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

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

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

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

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

Етапи розробки і їх реалізація в рамках об'єктної моделі

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

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

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

Існує безліч методів об'єктно-орієнтованого аналізу. Мабуть, найцікавішою розробкою останнього часу є спроба створення так званого Об'єднаного методу (Unitied Method). Три законодавця мод в об'єктно-орієнтованому аналізі - Grady Booch, James Rumbaugh і Ivar Jacobson - об'єдналися під дахом компанії Rational Software для того, щоб з'єднати найкраще з трьох раніше самостійних методів в один. Слід зазначити, що більшість методів ООА не залежить від конкретної мови програмування. Результуюча модель одна і та ж для Сі ++ і Smalltalk.

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

В об'єднаному методі аналіз і дизайн - просто дві стадії однієї і тієї ж моделі з одним і тим же мовою опису і одними і тими ж CASE-засобами.

Уже на етапі дизайну можливо багаторазове використання наявних рішень. Справжню революцію в програмуванні справило проектування "за зразками" (Design Patterns). Зразки - це добре документовані, аргументовані проектні рішення. Наприклад, якщо в системі може існувати не більше одного об'єкта певного класу, можна скористатися зразком Singleton; якщо потрібен об'єкт, який контролює доступ до іншого об'єкту, - зразком Proxy, і т. п. Фактично зразки - це розвиток поняття алгоритму, але з упором на структуру для вирішення певної задачі, а не на послідовність дій.

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

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

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

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

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

Велика частина часу розробки йде на аналіз і дизайн. На численні оцінками, ці стадії віднімають не менше 60% загального часу. Це часто ускладнює взаємодію з замовником, який хоче бути впевнений, що розробляється саме те, що йому потрібно. (На допомогу приходять засоби прототипування - за браком місця ми не можемо зупинитися на них докладніше.) Використання зразків дизайну вимагає кваліфікації, вивчення і, отже, часу. Те ж саме відноситься і до методів ООА / ООД і CASE-засобів.

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

Олександр Фрідман

література

Booch G. Object-Oriented Analisys and Design with Applications. 2nd ed. 1994.

Jacobson I. ea Object-Oriented Software Engineering. Addison-Wesley, 1992.

Gamma E. ea Design Patterns. Addison-Wesley, 1995.

FAQ.comp.objects - ftp://ftp.rtfm.mit.edu:/pub/usenet/comp.object. http://www.rational.com.

Версія для друку