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

На етапі конструювання при об'єктному підході продовжується процес об'єктного моделювання: уточнюються моделі, побудовані на етапі зовнішнього опису, в термінах опису програмних систем і проводиться подальша декомпозиція об'єктів [15.3, 15.4, 15.5].

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

Мал. 15.5. Архітектура «Клієнт-сервер»

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

Подальша розробка структури програмних підсистем і їх кодування на мовах програмування може здійснюватися вже в рамках реляційного підходу на орієнтованих на нього мовах програмування [15.7] – користувач внутрішню організацію цих підсистем вже «не бачить». Проте, у багатьох випадках існують сильні аргументи за те, щоб продовжити об'єктну декомпозицію цих підсистем. Об'єктна структура цих підсистем може бути істотно зрозумілішою розробникові, ніж їх структура при реляційному підході. Крім того, продовження об'єктної декомпозиції і використання основних понять і методів об'єктного підходу при подальшій розробці ПС представляється «природним», оскільки весь процес розробки стає одноманітним (концептуально цілісним).

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

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

На етапі кодування при об'єктному підході використовуються мови програмування вже іншого типу – об'єктно-орієнтовані [15.7, 15.8]. Вважається, що мову програмування підтримує об'єктно-орієнтоване програмування, якщо він включає конструкції для [15.8]

• інкапсуляції і абстракції даних

• спадкоємство

• динамічного поліморфізму.

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

Змінюється і технологія розробки програмного модуля. При реляційному підході для розробки модуля (в основному, реалізовуючу функцію або процедуру) рекомендувалися структурне програмування і покрокова деталізація (див. лекцію 8). При об'єктно-орієнтованому підході для розробки компоненту (інформаційно міцного модуля) більш підходить запропонована Дейкстрой [15.9] низхідна технологію розробки шаруватої структури модуля. У цій технології кожен модуль розглядається таким, що складається з деякої впорядкованої сукупності програмних шарів (ср. з шаруватою програмною системою в лекції 6), причому кожен шар є реалізацією деякої абстрактної машини (у нашому випадку це можна розглядати як реалізацію класу або логічно зв'язаної сукупності класів). Таким чином, модуль утворює певний ланцюжок ієрархічно зв'язаних абстрактних машин (так звані «намиста» [15.9]) Реалізація кожної абстрактної машини виражається в термінах абстрактної машини (програмного шару, що нижче стоїть), що нижче стоїть, або в термінах вибраної мови програмування (при реалізації абстрактної машини самого нижнього рівня). Розробка модуля починається з розробки абстрактної машини самого верхнього рівня.

Вправи до лекції 15.

15.1. У чому полягає суть об'єктного підходу до розробки програмних засобів (ПС)?

15.2. Які категорії об'єктів можна виділити з погляду розробників ПС?

15.3. Що таке об'єктна модель ПС?

15.4. Що таке динамічна модель ПС?

15.5. Що таке діаграма станів класу?

15.6. Що таке функціональна модель ПС?

15.7. Що таке компонент ПС?

Литература к лекции 15.

15.1. К. Фути, Н. Судзуки. Языки программирования и схемотехника СБИС. – М.: Мир, 1988. С. 85-98.

15.2. В. Даль. Толковый словарь русского языка. – М.: Советская энциклопедия, 1975

15.3. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorenzen. Objekt-OrientedModelingandDesign. –PrenticeHall. 1991.

15.4. Г.Буч. Объектно-ориентированное проектирование с примерами применения: пер. с англ. – М.: Конкорд, 1992.

15.5. М. Фаулер, К. Скотт. UML в кратком изложении. – М.: Мир, 1999.

15.6. Ф. Крачтен. Введение в RATIONAL UNIFIED PROCESS. – М.: Изд. Дом «Вильямс», 2002.

15.7. В.Ш.Кауфман. Языки программирования. Концепции и принципы. – М.: Радио и связь, 1993.

15.8. М. Бен-Ари. Языки программирования. Практический сравнительный анализ. – М.: Мир, 2000.

15.9. Э. Дейкстра. Заметки по структурному программированию / У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. – М.: Мир, 1975. – С. 7-97.