Взаємодія з іншими засобами

Конфігурація Vantage Team Builder for Uniface забезпечує спільне використання двох систем у рамках єдиного технологічного середовища проектування, при цьому схеми БД (SQL-моделі) переносяться в репозиторій Uniface, і, навпаки, прикладні моделі, сформовані засобами Uniface, можуть бути перенесені в репозиторій Vantage Team Builder. Можливі розузгодження між репозиторіями двох систем усуваються за допомогою спеціальної утиліти. Розробка екранних форм в середовищі Uniface виконується на базі діаграм послідовностей форм (FSD) після імпорту SQL-моделі.

13.2.2. Uniface

Uniface 6.1 [15] – продукт фірми Compuware (США) – є середовищем розроблення великомасштабних застосувань в архітектурі «клієнт-сервер» і має наступну компонентну архітектуру:

¨ Application Objects Repository (репозиторій об’єктів застосувань) містить описи елементів, які автоматично використовуються усіма останніми компонентами впродовж життєвого циклу ІС (прикладні моделі, описи даних, бізнес-правила, екранні форми, глобальні об’єкти і шаблони). Репозиторій може зберігатися у будь-якій з баз даних, підтримуваних Uniface;

¨ Application Model Manager підтримує прикладні моделі (ER моделі), кожна з яких є підмножиною загальної схеми БД з точки зору заданого застосування, і включає відповідний графічний редактор;

¨ Rapid Application Builder – засіб швидкого створення екранних форм і звітів на базі об’єктів прикладної моделі. Включає графічний редактор форм, засоби прототипування, відлагодження, тестування і документування. Реалізований інтерфейс з різними типами віконних елементів керування (Open Widget Interface) для існуючих графічних інтерфейсів – MS Windows, Motif, OS/2. Універсальний інтерфейс презентації (Universal Presentation Interface) дозволяє використовувати одну і ту ж версію застосування у середовищі різних графічних інтерфейсів без зміни програмного коду;

¨ Developer Services (служби розробника) –реалізують контроль версій (Uniface Version Control System), права доступу (розмежування повноважень), глобальні модифікації і так далі. Забезпечує розробників засобами паралельного проектування, вхідного і вихідного контролю, пошуку, перегляду, підтримки і видачі звітів за даними системи контролю версій;

¨ Deployment Manager (керування поширенням застосувань) – засоби, що дозволяють підготувати створене застосування для поширення, встановлювати і супроводжувати його (при цьому платформа користувача може відрізнятися від платформи розробника). У їх склад входять мережеві драйвери, сервер застосувань, засоби поширення застосувань і управління базами даних. Uniface підтримує інтерфейс практично зі всіма відомими програмно-апаратними платформами, CASE-засобами, протоколами і менеджерами транзакцій;

¨ Personal Series (персональні засоби) – використовуються для створення складних запитів і звітів у графічній формі (Personal Query і Personal Access – PQ/PA), а також для перенесення даних у такі системи, як Word і Excel;

¨ Distributed Computing Manager – засіб інтеграції з менеджерами транзакцій Tuxedo, Encina, CICS, OSF DCE.

13.3. Designer/2000 + Developer/2000

CASE-засіб Designer/2000 2.0 фірм ORACLE [23] є інтегрованим CASE-засобом, що забезпечує в сукупності зі засобами розроблення застосувань Developer/2000 підтримку повного ЖЦ ПЗ для систем, що використовують СКБД ORACLE.

Designer/2000 є сімейством методологій і програмних продуктів, що їх підтримують. Базова методологія Designer/2000 (CASE*Method) - структурна методологія проектування систем, що повністю охоплює усі етапи життєвого циклу ІС [8,9]. Відповідно до цієї методології на етапі планування визначаються цілі створення системи, пріоритети і обмеження, розробляється системна архітектура і план розроблення ІС. У процесі аналізу будуються модель інформаційних потреб (діаграма "сутність-зв'язок"), діаграма функціональної ієрархії (на основі функціональної декомпозиції ІС), матриця перехресних посилань і діаграма потоків даних.

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

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

Designer/2000 забезпечує графічний інтерфейс при розробці різних моделей (діаграм) предметної області. У процесі побудови моделей інформація про них заноситься в репозиторій. До складу Designer/2000 входять наступні компоненти:

¨ Repository Administrator - засоби керування репозиторієм (створення і знищення застосувань, керування доступом до даних з боку різних користувачів, експорт і імпорт даних);

¨ Repository Object Navigator - засоби доступу до репозиторія, що забезпечують багатовіконний об'єктно-орієнтований інтерфейс доступу до усіх елементів репозиторія;

¨ Process Modeller - засіб аналізу і моделювання ділової діяльності, що грунтується на концепціях глобальної системи керування якістю (TQM - Total Quality Management);

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

¨ Systems Designer - набір засобів проектування ІС, що включає засіб побудови структури реляційної бази даних, а також засоби побудови діаграм, що відображають взаємодію з даними, ієрархію, структуру і логіку застосувань, які виконуються збереженими процедурами на мові PL/SQL;

¨ Server Generator - генератор описів об'єктів БД ORACLE (таблиць, індексів, ключів, послідовностей і так далі). Окрім продуктів ORACLE, генерація БД може виконуватися для СКБД Informix, DB/2, Microsoft SQL Server, Sybase, а також для стандарту ANSI SQL DDL і баз даних, доступ до яких реалізується за допомогою ODBC;

¨ Forms Generator (генератор застосувань для ORACLE Forms). Застосування, що генеруються, включають різні екранні форми, засоби контролю даних, перевірки обмежень цілісності і автоматичні підказки. Подальша робота зі застосуванням виконується у середовищі Developer/2000;

¨ Repository Reports - генератор стандартних звітів, інтегрований з ORACLE Reports.

Репозиторієм Designer/2000 є сховище усіх проектних даних. Він може працювати у багатокористувацькому режимі, забезпечуючи паралельне оновлення інформації декількома розробниками. У процесі проектування автоматично підтримуються перехресні посилання між об'єктами словника і можуть генеруватися більше 70 стандартних звітів модельованої предметної області. Фізичне середовище зберігання репозиторія - база даних ORACLE.

Генерація застосувань, окрім продуктів ORACLE, виконується також для Visual Basic.

Designer/2000 можна інтегрувати з іншими засобами, використовуючи відкритий інтерфейс застосувань API (Application Programming Interface). Крім того, можна використовувати засіб ORACLE CASE Exchange для експорту/імпорту об'єктів репозиторія з метою обміну інформацією з іншими CASE-засобами.

РОЗДІЛ 14. Об'єктна модель

à Еволюція об'єктної моделі

à Складові частини об'єктного підходу

à Застосування об'єктної моделі

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

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

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

14.1. Еволюція об'єктної моделі

14.1.1. Основні положення об'єктної моделі

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

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

ООАП відображають еволюційний, а не революційний розвиток проектування; нова методологія не перекреслює попередні методи, а будується з врахуванням попереднього досвіду. На жаль, більшість програмістів в даний час формально і неформально натреновані на вживання лише методів структурного проектування. Зрозуміло, багато хороших проектувальників створили і продовжують удосконалювати велику кількість програмних систем на основі цієї методології. Проте алгоритмічна декомпозиція допомагає лише до певної межі, і звернення до об'єктно-орієнтованої декомпозиції необхідне. Більш того, при спробах використовувати такі мови, як C++ або Ada, як традиційні, алгоритмічно орієнтовані, ми не лише втрачаємо їх внутрішній потенціал - швидше за все результат буде навіть гірше, ніж при використанні звичайних мов С і Pascal. Дати електродриль тесляру, який не чув про електрику, означає використовувати її як молоток. Він зігне декілька цвяхів і розіб'є собі пальці, тому що електродриль мало придатна для заміни молотка.

14.1.2. OOP, OOП і ООА

Успадкувавши від багатьох попередників, об'єктний підхід, на жаль, перейняв і заплутану термінологію. Програміст в Smalltalk користується терміном метод, в C++ - терміном віртуальна функція, в CLOS - узагальнена функція. УObject Pascal використовується термін приведення типів, а в мові Ada те ж саме називається перетворення типів. Аби зменшити плутанину, слід визначити, які властивості є об'єктно-орієнтованими, а які - ні. Визначення найвживаніших термінів і понять ви знайдете в глосарії в кінці книги.

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

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

¨ прогрес в області архітектури ЕОМ;

¨ розвиток мов програмування, таких як Simula, Smalltalk, CLU, Ada;

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

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

¨ розвиток теорії баз даних;

¨ дослідження в області штучного інтелекту;

¨ досягнення філософії і теорії пізнання.

Поняття "об'єкт" вперше було використане більше 20 років тому під час конструювання комп'ютерів з descriptor-based і capability-based архітектурами. У цих роботах робилися спроби відійти від традиційної архітектури фон Неймана і здолати бар'єр між високим рівнем програмної абстракції і низьким рівнем ЕОМ. На думку прибічників цих підходів, тоді були створені якісніші засоби, що забезпечують: краще виявлення помилок, велику ефективність реалізації програм, скорочення набору інструкцій, спрощення компіляції, зниження об'єму необхідної пам'яті. Ряд комп'ютерів має об'єктно-орієнтовану архітектуру.

З об'єктно-орієнтованою архітектурою тісно пов'язані об'єктно-орієнтовані операційні системи (ОС). Дейкстра, працюючи над мультипрограмною системою THE, вперше ввів поняття машини з рівнями стану як засіб побудови системи. Серед перших об'єктно-орієнтованих ОС слід зазначити: Plessey/System 250 (для мультипроцесора Plessey 250), Hydra (для CMU C.mmp), CALTSS (для CDC 6400), CAP (для комп'ютера Cambridge CAP), UCLA Secure UNIX (для PDP 11/45 і 11/70), STAROS (для CMU Cm*), Medusa (також для CMU Cm*) і iMAX (для Intel 432).

Найзначніший вклад в розвиток об'єктного підходу внесений об'єктними і об'єктно-орієнтованими мовами програмування. Вперше поняття класів і об'єктів введені в мові Simula 67. Система Flex і діалекти Smalltalk-72, що слідували за нею -74, -76 і, нарешті -80, взявши за основу методи Simula, довели їх до логічного завершення, виконуючи всі дії на основі класів. У 1970-х роках створено ряд мов, що реалізовують ідею абстракції даних: Alphard, CLU, Euclid, Gypsy, Mesa і Modula. Потім методи, що використовуються в мовах Simula і Smalltalk, були використані в традиційних мовах високого рівня. Введення об'єктно-орієнтованого підходу в С привело до виникнення мов C++ і Objective С. На основі мови Pascal виникли Object Pascal, Eiffel і Ada. З'явилися діалекти LISP, такі, як Flavors, LOOPS і CLOS (Common LISP Object System), з можливостями мов Simula і Smalltalk.

Першим, хто вказав на необхідність побудови систем у вигляді структурованих абстракцій, був Дейкстра. Пізніше Парнас ввів ідею приховування інформації, а в 70-х роках ряд дослідників, головним чином Лісков, Жиль, Гуттаг, і Шоу розробили механізми абстрактних типів даних. Хоар доповнив ці підходи теорією типів і підкласів.

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

Розробники способів подання даних в області штучного інтелекту також внесли свій вклад в розуміння об'єктно-орієнтованих абстракцій. У 1975 р. Мінські висунув теорію фреймів для представлення реальних об'єктів в системах розпізнавання образів і природних мов. Фрейми стали використовуватися як архітектурна основа в різних інтелектуальних системах.

Об'єктний підхід відомий ще здавна. Грекам належить ідея про те, що світ можна розглядати в термінах як об'єктів, так і подій. А в XVII столітті Декарт відзначав, що люди зазвичай мають об'єктно-орієнтований погляд на світ. У XX столітті цю тему розвинув Ренд у своїй філософії об'єктивістської епістемології. Пізніше Мінські запропонував модель людського мислення, в якій розум людини розглядається як сукупність по-різному мислячих агентів. Він доводить, що лише спільна дія таких агентів приводить до осмисленої поведінки людини.

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

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

У цьому визначенні можна виділити три частини: 1) OOP використовує як базові елементи об'єкти, а не алгоритми (ієрархія "бути частиною"); 2) кожний об'єкт є екземпляром якого-небудь певного класу; 3) класи організовані ієрархічно (див. поняття про ієрархію "is_а"). Програма буде об'єктно-орієнтованою лише при дотриманні всіх трьох вказаних вимог. Зокрема, програмування, не засноване на ієрархічних відношеннях, не відноситься до OOP, а називається програмуванням на основі абстрактних типів даних.

Відповідно до цього визначення не всі мови програмування є об'єктно-орієнтованими. Якщо термін об'єктно-орієнтована мова взагалі що-небудь означає, то він повинен означати мову, що має засоби підтримки об'єктно-орієнтованого стилю програмування... Забезпечення такого стилю у свою чергу означає, що в мові зручно користуватися цим стилем. Якщо написання програм в стилі OOP вимагає спеціальних зусиль або воно неможливе зовсім, то ця мова не відповідає вимогам OOP. Теоретично можлива імітація об'єктно-орієнтованого програмування на звичайних мовах, таких, як Pascal і навіть COBOL або асемблер, але це вкрай складно. Мова програмування є об'єктно-орієнтованою тоді і лише тоді, коли виконуються наступні умови:

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

¨ об'єкти відносяться до відповідних типів (класів),

¨ nипи (класи) можуть успадковувати атрибути супертипів (суперкласів).

Підтримка успадкування в таких мовах означає можливість встановлення відношення "is-а" ("є", "це є" " - це"), наприклад, червона троянда - це квітка, а квітка - це рослина. Мови, що не мають таких механізмів, не можна віднести до об'єктно-орієнтованих. Карделлі і Вегнер назвали такі мови об'єктними, але не об'єктно-орієнтованими. Згідно цьому визначенню об'єктно-орієнтованими мовами є Smalltalk, Object Pascal, C++ і CLOS, а Ada - об'єктна мова. Але, оскільки об'єкти і класи є елементами обох груп мов, бажано для них використовувати методи об'єктно-орієнтованого проектування.

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

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

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

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

Об'єктно-орієнтований аналіз. На об'єктну модель вплинула модель життєвого циклу програмного забезпечення. Традиційна техніка структурного аналізу заснована на потоках даних в системі. Об'єктно-орієнтований аналіз (або OOA, object-oriented analysis) направлений на створення моделей реальної дійсності на основі об'єктно-орієнтованого світогляду.

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

Як співвідносяться ООА, OOП і OOP? На результатах ООА формуються моделі, на яких ґрунтується OOП; OOП у свою чергу створює фундамент для остаточної реалізації системи з використанням методології OOP.

14.2. Складові частини об'єктного підходу

14.2.1. Парадигми програмування

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

процедурно-орієнтований алгоритми

об'єктно-орієнтований класи і об'єкти

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

орієнтований на правила правила "якщо-то"

орієнтований на обмеження інваріантні співвідношення

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

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

¨ абстрагування;

¨ інкапсуляція;

¨ модульність;

¨ ієрархія.

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

¨ типізація;

¨ паралелізм;

¨ збережуваність.

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

Без такої концептуальної основи можна програмувати на мові типу Smalltalk, Object Pascal, C++, CLOS, Eiffel або Ada, але з-під зовнішньої краси виглядатиме стиль FORTRAN, Pascal або С. Виразна здатність об'єктно-орієнтованої мови буде або втрачена, або спотворена. Але ще важливішим буде те, що при цьому буде мало шансів впоратися із складністю вирішуваних завдань.

14.2.2. Абстрагування

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

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

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

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

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

¨ Абстракція сутності. Об'єкт є корисною моделлю деякої сутності ПО.

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

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

¨ Довільна абстракція. Об'єкт включає набір операцій, які не мають одна з одною нічого спільного.

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

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

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

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

Відмітимо, що поняття операція, метод і функція-член походять від різних традицій програмування (Ada, Smalltalk і C++ відповідно). Фактично вони позначають одне і те ж і надалі будуть взаємозамінні.

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

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

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

Одна з ключових абстракцій в такій задачі - датчик. Відомо декілька різновидів датчиків. Все, що впливає на урожай, повинно бути виміряне, так що ми повинні мати датчики температури води і повітря, вологості, рН, освітлення і концентрації живильних речовин. Із зовнішньої точки зору датчик температури - це об'єкт, який здатний вимірювати температуру там, де він розташований. Що таке температура? Це числовий параметр, що має обмежений діапазон значень і певну точність, означає число градусів за Фаренгейтом, Цельсієм або Кельвіном. Що таке місце розташування датчика? Це деяке місце, що ідентифікується в теплиці, температуру в якому нам необхідно знати; таких місць, ймовірно, небагато. Для датчика температури істотно не стільки саме місце розташування, скільки той факт, що даний датчик розташований саме в даному місці і це відрізняє його від інших датчиків. Тепер можна поставити питання про те, які обов'язки датчика температури? Ми вирішуємо, що датчик повинен знати температуру в своєму місцезнаходженні і повідомляти її за запитом. Які ж дії може виконувати по відношенню до датчика клієнт? Ми приймаємо рішення про те, що клієнт може калібрувати датчик і отримувати від нього значення поточної температури.

Для демонстрації проектних вирішень буде використана мова C++. Ось опис, який встановлює абстрактний датчик температури на C++.

// Температура по Фаренгейту

typedef float Temperature;

// Число, що однозначно визначає положення датчика

typedef unsigned int Location;

class TemperatureSensor {

public:

TemperatureSensor (Location);

~TemperatureSensor();

void calibrate(Temperature actualTemperature);

Temperature currentTemperature() const;

private:

...

};

Тут для двох операторів визначення типів Temperature і Location вводять зручні псевдоніми для простих типів, і це дозволяє нам виражати свої абстракції на мові ПО. На жаль, конструкція typedef не визначає нового типу даних і не забезпечує його захисту. Наприклад, наступний опис в C++: " typedef int Count; " просто вводить синонім для примітивного типу int. Temperature - це числовий тип даних у форматі з плаваючою крапкою для запису температур в шкалі Фаренгейта. Значення типу Location позначає місце ферми, де можуть розташовуватися температурні датчики.

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

Temperature temperature;

Temperaturesensor greenhouse1sensor(1);

Temperaturesensor greenhouse2sensor(2);

temperature = greenhouse1sensor.currentTemperature();

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

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

class ActiveTemperatureSensor {

public:

Поиск по сайту: