
- •Государственный комитет рф по высшему образованию
- •0. Введение.
- •0.1. Идея общей интеграции.
- •0.2. Взаимодействие на уровне процедур.
- •0.3. Распределенные объекты.
- •0.4. Почему corba.
- •1. Поддержка на различных платформах.
- •2. Устойчивость стандарта.
- •3. Сложность освоения.
- •4. Поддержка повторного использования кода.
- •1. Постановка задачи.
- •1.1. Классические объекты.
- •1.2. Распределенные объекты в терминах спецификации corba.
- •1.3. Требования, предъявляемые к orb-у.
- •2. СпецификацияCorba.
- •2.1. Объектная модель.
- •2.2. Обзор архитектурыCorba.
- •2.3. Пример Брокеров Объектных Запросов.
- •3. Структура системы.
- •3.1. Уточнение деталей реализации.
- •3.2. Структура ядра системы.
- •3.3. Структура библиотеки.
- •3.4.Структура подсистемы обработки запросов.
- •3.5. Входные и выходные данные.
- •4. Протокол обменаGiop.
- •4.1. Особенности и цели протокола.
- •4.2. Обзор протоколаGiop.
- •4.3. Синтаксис Общего Представления Данных -cdr.
- •4.4. Формат сообщений протокола giop.
- •4.5. Транспорт для протоколаGiop.
- •4.6. Реализация взаимодействия по протоколуGiop.
- •4.7. Поддержка протоколаGiop в рамках отображения дляObject Pascal.
- •5. Разработка отображения для языкаObject Pascal.
- •5.1. Множественное наследование.
- •5.2. Статические экземпляры классов.
- •Initialization
- •Initialization
- •6. Технология написания и отладки приложений, работающих с распределенными объектами.
- •6.1. Этапы разработки программы.
- •6.2. Технология написания сервера объекта.
- •6.3. Технология написания клиента объекта.
- •6.4. Отладочные возможности библиотеки.
- •7. Пример программы, работающей с распределенными объектами.
- •7.1. Последовательность действий при создании объекта.
- •7.2. Объект библиотека.
- •7.3. Сервер объекта.
- •7.3. Клиент объекта.
- •7.4. Окончательный результат.
- •8. Анализ конкурентоспособности программного продукта.
- •8.1. Введение.
- •8.2. Ситуация на рынке.
- •8.3. Программные продукты - конкуренты.
- •8.4. Основные понятия.
- •8.5. Параметры для оценки эффективности.
- •8.6. Расчет эффективности.
- •8.7. Цена.
- •8.8. Конкурентоспособность.
- •8.9. Выводы и прогнозы.
- •9. Вопросы эргономики и их решение для создания комфортных условий труда программистов.
- •9.1. Введение.
- •9.2. Рабочее место программиста.
- •9.3. Вредные факторы, присутствующие на рабочем месте и их классификация.
- •9.4. Вредные производственные воздействия.
- •9.5. Эргономические требования.
- •9.6. Эргономика окружающей среды.
- •9.7. Экологическая безопасность.
- •9.8. Выводы.
3. Сложность освоения.
Очень показательными являются следующие цифры, взятые из [1]. Минимальный набор документации, необходимый для полного ознакомления и использования объектной моделиCOMвключает в себя руководство разработчика (925 страниц), справочное руководство поAPI (650 страниц), руководство поOLE Automation (400 страниц). В тоже время спецификацияCORBA определяется в документе, состоящем из 178 страниц. Такая картина является частично является следствием слишком ускоренного развития технологииOLE/COM с попытками охватить большое количество всевозможных дополнительных технологий. В то же время спецификацияCORBA задает лишь основные, необходимые для обеспечения взаимодействия стандарты, полностью оставляя реализацию всех дополнительных сервисов на разработчика конкретной системы.
4. Поддержка повторного использования кода.
Большинство реализаций спецификации CORBA поддерживают наследование между объектами, позволяющей вызывать для производного объекта все методы, доступные в базовом. МодельCOM не поддерживает прямого наследования. Вместо этого допускается делегирование, то есть реализация в объекте определенного набора функций. Тем не менее в каждом объекте эти функции должны быть заново реализованы.
Учитывая все приведенные характеристики, объектная модель, устанавливаемая спецификацией CORBA является более приемлемым кандидатом для реализации. Кроме того, реализация объектной моделиCOM ввиду всей ей объемности возможна только как результат работы большого коллектива разработчиков и, вероятно, изначально не способна конкурировать с реализациями, произведенными фирмойMicrosoft на соответствующих платформах - фирмаMicrosoft склонностью к утверждению и развитию своих собственных стандартов, игнорируя при этом все остальное. Поэтому и было принято решение о разработке системы, удовлетворяющей спецификацииCORBA.
1. Постановка задачи.
1.1. Классические объекты.
Перед тем, как определить круг требований к системе, установим, что же скрывается под понятием объекта. Для определенности исследование будет происходить на примере языка C++,так как этот язык является наиболее полным и наглядным в смысле объектной ориентированности1.
Любой класс состоит из двух составных частей:
данных (полей);
кода (методов).
В общем случае данные принадлежат отдельному экземпляру класса, то есть каждый объект имеет свою собственную копию данных. Код наоборот, отождествляется с классом и используется всеми экземплярами данного класса. Когда какой-нибудь объект изменяется, то меняются связанные с объектом данные. Код при этом не меняется, но зачастую изменение данных объекта происходит именно посредством методов данного класса.
Три основных категории действий, которые можно производить над объектами, это:
создание экземпляра объекта;
вызов методов объекта и доступ к его полям;
уничтожение экземпляра объекта.
В языке C++ объект создается и уничтожается с помощью специализированных методов класса - конструктора и деструктора соответственно. Конструктор нельзя явно вызвать из любого места программы, кроме как при создании нового объекта. Деструктор же вообще вызывается неявно при выходе из блока программы, в котором объект был создан. Кроме того, конструктор и деструктор вызываются при динамическом создании и уничтожении объектов операторамиnew иdelete соответственно. Вызов методов у объекта и изменение значений его полей разрешаются только в период между созданием и уничтожением данного объекта2.
От одного или нескольких имеющихся классов можно породить новый класс, который неявно обладает всеми свойствами, присущими его базовым классам. Производный класс может изменить или расширить поведение, унаследованное от родительских классов.