Как это всё виделось в 1990 году.

С сайта www.math.rsu.ru

Объектно-ориентированные системы: состояние и перспективы

Аналитический обзор
по материалам фирмы OVUM (Великобритания) 1990 г.
Обзор подготовил А. Г. Иванов
Москва 1992

ЧАСТЬ А: СОВРЕМЕННОЕ СОСТОЯНИЕ ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ СИСТЕМ

1. ЗНАЧЕНИЕ ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ СИСТЕМ

1.1. Модное слово или "серебряная пуля"?

Для некоторых фирм-распространителей программного обеспечения (ПО) термин "объектно-ориентированный" - это модное слово, помогающее в рекламе их продуктов. Для некоторых разработчиков программных средств (ПС) этот термин означает магическую "серебряную пулю" ("silver bullet") , способную решить задачу производительности. Основная мысль данного обзора заключается в том, что технология объектно-ориентированного программирования (ООП) , являющаяся способом разработки и комплектования ПО, - ключевой момент в любой магической "серебряной пуле". Вот почему объектно-ориентированные системы играют центральную роль в компьютерных технологиях 90-х гг.

Объектно-ориентированная технология - это не новейшее открытие. Такие системы существуют уже около двадцати лет. В конце 80-х появилась новая мощная аппаратура и объектно-ориентированные версии языков программирования, и вместе они составили очень привлекательную перспективу для разработчиков ПС. В данном обзоре показано, что "объекты" встречаются повсюду - от экспертных до издательских систем, от микропроцессоров до оконных оболочек. Производители варьируются от начинающих фирм до гигантов типа фирмы AT&T, являющейся одним из активных сторонников этой технологии, а также разработчиком быстро набирающего популярность языка C++. Тот факт, что многие современные производители начинают как пользователи, дает дополнительный импульс к переходу на объектно-ориентированные системы.

Эта технология представляет не только тайный интерес для профессиональных программистов или научных исследователей. В мире персональных компьютеров энтузиазм всегда означает многое. Bill Gates описал технологию как "выдающуюся штуку". Для демонстрации ее значения он привел пример процессора обработки слов, позволяющего пользователю вводить в документы "объекты" типа данных с голоса, рисунков или таблиц. При выборе голоса его программа обрабатывается соответствующим устройством и пользователь может послушать объект.

Объектно-ориентированными системами занялась фирма Microsoft; некоторое время она использовала их для внутренних работ. В феврале 1989 она впервые заявила об участии в разработках в этой области: это был договор с компанией Glockenspiel (Дублин) на разработку версии языка C++. В этом одинаково заинтересованы и другие предприниматели. Steve Jobs, соучредитель фирмы Apple, в октябре 1988 снабдил NeXT объектно- ориентированным интерфейсом и инструментарием. Основатель фирмы Lotus Mitch Kapor использовал объектно-ориентированный подход в своей новой компании - ON Technology.

1.2. Что такое объектно-ориентированные системы?

Объектно-ориентированная технология - это способ разработки ПО, существенно отличающийся от традиционных методов и способов представления объектов реального мира. В данном обзоре термин "объектно-ориентированные системы" используется для всех языков программирования, инструментариев и методологий, поддерживающих эту технологию.

При разработке ПО понятие объекта исходит из моделирования обычных объектов и видов их взаимодействия. На простейшем уровне объект - это нечто, обозначаемое именем. Объект имеет определенные свойства, используемые для его описания: это состояние объекта. Объект в ответ на некоторые действия ведет себя некоторым образом: он обладает поведением. Программный объект - это копия некоторого объекта реального мира. Он также имеет состояние и поведение, выраженные в виде данных и процедур.

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

Человек объединяет повседневные объекты в классы на основании одинаковых свойств. Например, если мы говорим, что объект является конвертом, то мы может узнать о нем многое, не заботясь о том, что это за конверт. Программные объекты, обладающие одинаковыми свойствами, также группируются в классы.

Наконец, классы повседневных объектов сами образуют иерархию. Они наследуют общие свойства от более старших в иерархии классов, называемых суперклассами. Суперкласс содержит другие классы, называемые его подклассами. Конверты - это суперкласс, содержащий деловые конверты, а контейнеры образуют суперкласс, содержащий в качестве подклассов конверты, картотеки и почтовые ящики. Программные классы могут также наследовать данные и процедуры в иерархии классов.

В данном обзоре объектно-ориентированная система содержит каждое из нижеперечисленных свойств:
- данные и процедуры объединяются в программные объекты;
- сообщения используются для взаимосвязи с этими объектами;
- схожие объекты группируются в классы;
- данные и процедуры наследуются по иерархии классов.

Термин "объектно-ориентированный" иногда используется для систем, содержащих только первые два или три из этих свойств. Чтобы отличить такие системы от систем, поддерживающих все четыре свойства, мы будет называть первые "объектными". Это различие важно потому, что одно из важнейших преимуществ объектно-ориентированной технологии - повторное использование исходных текстов и способность быстрого реагирования на изменения - зависит от механизма наследования классов.

2. ЧТО ДАЮТ ОБЪЕКТНО-ОРИЕНТИРОВАННЫЕ СИСТЕМЫ

2.1. ООС повышают производительность

Объектно-ориентированная технология привлекает пользователя повышенной производительностью в течение всего жизненного цикла ПО, что приводит к реальной отдаче капиталовложений. Повышенная производительность достигается при наличии четырех основных свойств объектно-ориентированных систем и вытекающих из них преимуществ:
- использование объектов в качестве основных моделей позволяет пользователю моделировать сложные системы реального мира;
- гибкость объектно-ориентированных текстов выливается в быстрое реагирование на изменения требования пользователя;
- повторное использование стандартных компонентов снижает как время разработок новых прикладных задач, так и объем сгенерированного кода;
- простота ПО делает его более гибким и снижает затраты на эксплуатацию.

Наряду с этими явными преимуществами, использование объектно-ориентированных языков и сред программирования способствует пошаговой разработке ПО. Быстрое прототипирование интерфейсов позволяет тестировать ответы пользователя независимо от основного тела прикладной задачи. Значение такого подхода наиболее проявляется в проектах, прикладные задачи которых заданы нечетко или трудны для понимания.

В настоящее время существует мало объективных оценок роста производительности из-за того, что большинство проектов, связанных с объектно-ориентированными системами, находятся на начальной стадии. Одна из компаний, STC Technology (Великобритания), сделавшая сравнительные оценки, подсчитала, что этап разработок объектно-ориентированного проекта занимает времени в два раза меньше, чем аналогичная задача в традиционной системе и требует четвертую часть затрат человеко-часов.

2.2. ООС позволяют справляться со сложностью

Первое важное преимущество объектно-ориентированных систем вытекает из природы их связи с реальным миром. Разработчик может спроектировать физическую систему в программную, первоначально задав все важные физические объекты и соответствующие им программные объекты. Группы взаимосвязанных физических объектов отображаются в классы, которые можно организовать в иерархию, начиная с общих классов и добавляя к ним специализированные подклассы. Процедуры, общие для нескольких классов, находятся в их общем суперклассе и наследуются ими.

Например, в измерительной системе, разработанной в Combuston Engineering (Columbus, Ohio), группа датчиков отображается классом Sensor, задающим общие свойства всех датчиков. Подклассы задаются для каждого типа датчика системы, например, для оптических или инфракрасных. Они наследуют общие процедуры, применимые ко всем датчикам, и содержат дополнительные процедуры, применимые только к оптическим или инфракрасным датчикам.

Объектно-ориентированный подход уменьшает концептуальный разрыв между реальным миром м компьютерной моделью. Он позволяет аналитикам и проектировщикам ясно понимать структуру системы. Как отмечает один из пользователей: "Я могу представить свои мысли текстом программы в таком виде, как я думаю." Поэтому сегодня объектно-ориентированные системы используются для моделирования сложных физических систем на производстве, в телекоммуникациях, а также в военном и оборонном комплексах.

2.3. ООС предназначены для изменений

Второе преимущество объектно-ориентированных систем обусловлено способом взаимосвязи объектов через сообщения. В примере, приведенном выше, общие сообщения типа "начать измерение", можно посылать всем датчикам системы; каждый из них отвечает специфическим образом. Если один из физических датчиков устарел, он заменяется. Одновременно меняется и соответствующий класс системы: для нового типа датчика вводится новый класс, содержащий процедуры, характерные для нового датчика. Новый класс наследует остальные необходимые ему процедуры от суперкласса. При получении новым датчиком общего сообщения он отвечает на него соответствующим образом. Тело всей системы и общие сообщения остаются без изменений.

Гибкость объектно-ориентированных систем является неоспоримым преимуществом для пользователей в быстро меняющихся средах, например, в технологии программирования. Например, Computer Science Corporation использовал объектно-ориентированный язык Smalltalk для разработки продукта Design Generator. Компания отмечает, что благодаря использованию объектно-ориентированной технологии, разработчики программ имеют возможность быстро реагировать на новые течения рынка в условиях возрастающей конкуренции.

2.4. Объекты могут использоваться несколько раз

Третье преимущество объектно-ориентированных систем заключается в том, что классы могут наследовать процедуры от других классов. Компания может составить библиотеки наиболее часто используемых классов, содержащих процедуры, предназначенные для специфических нужд и применяющиеся в последующих прикладных задачах. Например, компания, занимающаяся разработкой программ, может создать библиотеку классов для графических примитивов типа цилиндра, конуса или сферы. Они формируют основу для подклассов типа конического сечения или разреза. Повторное использование исходных текстов снижает время разработок и позволяет проектировщикам уверенно решать задачи в различных областях.

В прошлом библиотеками подпрограмм пользовались разработчики ПО для решения стандартных задач типа математических вычислений. Объектно-ориентированные системы дают более широкий спектр многократного использования текстов программ. Один из первых пользователей, Cadre Technologies, подсчитал, что объем текстов программ для новой прикладной задачи уменьшается в отношении 5:1 в случае использования объектно-ориентированных программ.

Библиотеки объектов также можно приобретать от независимых поставщиков. В настоящее время наиболее активно покупают такие библиотеки классов для создания пользовательских интерфейсов с пиктограммами. Разработка и написание таких интерфейсов с нуля - задача нелегкая. Компании типа Apple и Whitewater Group поставляют инструментарии для быстрого построения таких интерфейсов на основе нескольких базовых классов типа Window, Menu, ScrollBar и Icon. Пользователи могут использовать как эти классы, так и их подклассы, добавляемые в интерфейс, например, специальные пиктограммы.

2.5. ООС легко поддерживаются

Четвертое преимущество заключается в способе комплектования объектно- ориентированных программных модулей. Традиционное ПО состоит из данных и процедур, осуществляющих доступ и изменение данных. Данные и процедуры комплектуются отдельно, поэтому изменение структуры данных влияет на различные модули, написанные разными пользователями. В объектно-ориентированной системе данные и процедуры рассматриваются вместе как часть одного пакета - объекта. При изменении данных все задействованные процедуры легко идентифицируются и изменяются одновременно. Поскольку изменение распространяется только на одну область системы, его побочное влияние на всю систему уменьшается.

Известно, что затраты на сопровождение составляют до 80% стоимости жизненного цикла системы программирования. Разработчики больших сложных систем, часто сталкивающиеся с необходимостью их модификации, склоняются к использованию ООС как одному из способов снижения затрат на сопровождение и повышения надежности их продуктов. Например, Wild Leitz (Торонто, Канада) использовал объектно-ориентированных язык Objective-C для разработки географической информационной системы. Компания посчитала исходные тексты на этом языке более легкими в сопровождении, поскольку они короче, являются изолированными "вещами в себе", что снижает влияние изменения одного модуля на оставшуюся часть системы.

3. ПРОБЛЕМЫ И ПУТИ ИХ РЕШЕНИЯ

3.1. Несовершенство

Ограничения современных объектно-ориентированных систем (ООС) в большинстве своем связаны с их несовершенством. Преодоление этих ограничений - это вызов продавцам ПО и возможность появления на рынке новых поставщиков. В этой главе обсуждаются проблемы развития объектно- ориентированных систем и дается временная шкала преодоления их слабостей.

Основное препятствие для объектно-ориентированных систем в настоящее время - это сопротивление технического и управленческого персонала. Такое сопротивление естественно с точки зрения несовершенства многих объектно-ориентированных продуктов на сегодняшнем рынке. Несовершенство проявляется на примере ряда проблем, свойственных большинству новых технологий:
- ограниченный доступ на ряде стандартных платформ;
- необходимость интеграции с существующими системами и базами данных;
- нехватка ПО для программирования широкомасштабных систем.

Успех объектно-ориентированной технологии обусловлен проникновением в основное русло компьютерной индустрии. Чтобы это произошло, следует справиться с вышеупомянутыми проблемами. Но это довольно дорогостоящее и долгое по времени занятие. Часть первых поставщиков объектно-ориентированных систем добавили себе проблем выбором в качестве основы своих продуктов нестандартных запатентованных языков. Получив большие капиталовложения, такие компании столкнутся с большими проблемами в борьбе за занятие своей ниши на рынке.

ДОСТУПНОСТЬ

Текущие требования пользователей на переносимость, открытые системы и стандарты уже приняты во внимание большинством поставщиков объектно- ориентированных систем. Для того, чтобы быть доступными пользователям, основные объектно-ориентированные языки и среды программирования должны быть реализованы для всех основных аппаратных платформ. Это уже можно сказать о языке С++ и Smalltalk-80.

Расхождение со стандартами становится проблемой для поставщиков, от которых ждут совместимости с различными системами и переносимости. Например, программный продукт, доступный для всех аппаратных платформ, должен работать с различными пользовательскими интерфейсами, включая MS Windows, Presentation Manager, Open Look и OSF Motif.

ИНТЕГРАЦИЯ

Как и все новые системы, объектно-ориентированные системы должны подходить под существующие среды программирования и реляционные базы данных. Они должны иметь доступ к программам, написанным на других языках. Существует множество прикладных задач, написанных на языках Си, Паскаль, Фортран и Кобол, и пользователи не собираются их переписывать. Новые прикладные задачи, написанные на объектно-ориентированных языках, должны быть совместимыми с уже существующими задачами.

Вообще говоря, процесс интеграции - это вопрос времени и ресурсов, и он никогда не решается полностью. Сейчас получило развитие огромное число аппаратных и программных сред, но для новых технологий их мало. Кажется, поставщики извлекли уроки из разработок новейших технологий типа экспертных систем и сконцентрировали свои усилия в разработке интерфейсов, необходимых для успешной совместимости.

РАЗРАБОТКА ШИРОКОМАСШТАБНОГО ПО

В то время как объектно-ориентированные среды типа Smalltalk превосходны для отдельных программистов, нынешнее поколение объектно-ориентированных систем слабо поддерживает развитие широкомасштабных проектов в области ПО. С другой стороны, существующие средства технологии программирования (CASE), не поддерживают объектно-ориентированные понятия, языки или методологии. Поэтому продавцы CASE имеют хорошую возможность заполнения этой бреши на рынке. С 1991 г. на рынке стали появляться первые средства поддержки объектно-ориентированного анализа и проектирования в технических и коммерческих задачах.

3.2. Роль сервиса

В настоящее время главным препятствием для принятия объектно-ориентированных систем является консервативность. Преодолев ее, поставщики получат существенные перспективы проникновения на рынок услуг объектно-ориентированных систем. Объектно-ориентированные понятия будут фундаментальными в компьютерной индустрии будущего, но для большинства людей они пока еще новы, и требуется некоторое время на привыкание.

Чтобы убедить потенциальных покупателей в значении объектно- ориентированных систем, требуется проведение эффективного маркетинга наряду с рассказами о преимуществах объектно-ориентированных систем от тех, кто уже поработал в них. Требуется обучение работе в объектно- ориентированных средах наряду с разработкой методологий обучения и передачей технологии. Пользователей также следует обучать понятиям объектно-ориентированного программирования. Многие программисты, знакомые с традиционными языками типа Си и Фортрана, сталкиваются с проблемами в понимании нового подхода. Хотя объектно-ориентированная модель интуитивно понятна разработчикам и инженерам, знакомым с моделируемой задачей, у программистов, привыкших мыслить в терминах процедур, могут возникать трудности. Разрыв в понятиях сдвинулся от интерфейса между реальным миром и моделью к интерфейсу между моделью и программой. На начальном этапе (первые 6 месяцев) пользователи жалуются на трудности, а потом они привыкают мыслить в терминах объектов, сообщений и классов.

Для больших компаний относительно просто развернуть консультации необходимого масштаба, что нельзя сказать о небольших начинающих фирмах, составляющих значительную часть рынка объектно-ориентированных систем. Некоторые поставщики ООС начинают предлагать свои услуги, чтобы восполнить пробел. Сюда относятся компании Arthur Andersen and Coopers & Lybrand, уже имеющие опыт в области экспертных систем и считающие объектно-ориентированную технологию естественным расширением своей деятельности. Кроме того, появились центры консультаций именно в области объектно-ориентированного программирования.

В дальнейшем объектно-ориентированные системы войдут в основное русло, а опыт работы с ними приобретут большинство программистов и разработчиков. Уже некоторые университеты планируют обучение основам объектно- ориентированных языков. Сопротивление программистов спадет после того, как появятся первые выпускники таких курсов. К 1995 г. большинство выпускников в области информатики будут знакомы с этой технологией.

3.3. Постоянство объектов

Кроме проблемы несовершенства, описанной выше, следует решить еще два технических вопроса перед тем, как объектно-ориентированная технология получит широкое распространение. Первое и самое важное техническое ограничение нынешнего поколения объектно-ориентированных систем заключается в том, что данные содержатся в объектах, которые трудно разделить между несколькими пользователями и которые могут быть потеряны при завершении создавшей их программы. Для отдельного пользователя объектно-ориентированной системы, решающего некоторую техническую задачу, проблем нет. Но при использовании этой технологии в коммерческой сфере вышеприведенная проблема становится абсолютным ограничением. Разрешение этой проблемы в первую очередь открывает дорогу разработчикам баз данных и бросает вызов продавцам существующих языков.

Коммерческое ПО должно быть доступным большому числу программистов, работающих над одним проектом. Пользователи коммерческих пакетов прикладных задач должны иметь доступ к общим данным. Чтобы реализовать это, надо найти способ, при котором объекты, содержащие данные и процедуры, продолжают существовать после завершения программы. Такие объекты называются "постоянными" и хранятся в объектно-ориентированной базе данных. Развитию таких баз данных сейчас уделяется огромное внимание. Несколько продуктов являются коммерчески доступными: это продукты таких компаний, как Graphael, Servio Logic и Ontologic, но и они сильно страдают от проблем несовершенства, упомянутых выше.

Кроме составления объектно-ориентированных баз данных, прикладные задачи также должны иметь доступ к данным существующих баз данных. Некоторые разработчики занимаются этими вопросами. Например, Intellicorp, поставляет продукт KeeConnection, позволяющий разновидности набора инструментов AI, Kee, свободно работать с Oracle или Ingres. ParcPlace Systems, поставщик Smalltalk-80, разработала доступ к базам данных Oracle, Informix и др. К 1991 году, когда основные разработчики реляционных баз данных управления появились на рынке со своими объектно- ориентированными продуктами, связки с базами данных были полностью завершены. С этого момента широкий спектр коммерческих задач стал доступным в объектно-ориентированных системах.

3.4. Производительность

Реализации объектно-ориентированных языков существенно различаются по своим требованиям к операционной системе. В настоящий момент большие накладные системные расходы, вызывающие проблемы производительности, могут возникать в трех случаях:
- если связь или связывание между сообщением, посланным объекту, и соответствующей процедурой, должны быть сделаны динамически во время работы программы, а не статически во время компиляции;
- если место в памяти для нежелательных объектов должно освобождаться автоматически с помощью сборки мусора, а не программистом;
- если система содержит много небольших объектов, которые подкачиваются из основной памяти во вспомогательную по мере поступления запросов программы.

Насущность этих проблем и наилучшие методы их разрешения являются предметами обсуждения и исследований в настоящее время.

К середине 90-х гг., когда упомянутые проблемы будут решены, объектно- ориентированные системы станут частью основных элементов компьютерной техники. Тогда на первый план выйдет проблема производительности, усиленная фактом претенциозных систем, пытающихся объединить несколько прикладных задач в одном слое ПО, поддерживающего различные стандарты. Будет подниматься вопрос не о возрастании производительности, а об извлечении наибольшей выгоды из существующих мощностей. Для производителей аппаратуры есть хорошая возможность предвосхитить эту заинтересованность и разрабатывать теперь системы, оптимизирующие производительность объектно-ориентированных систем на уровне ОС и аппаратуры.

И т. д

ЧАСТЬ B: КОНЦЕПЦИИ И ИХ ПРИМЕНЕНИЕ

1. ОСНОВНЫЕ ПОНЯТИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ СИСТЕМ

1.1. Определение

Хотя термин "объектно-ориентированный" и широко применяется в настоящее время, универсального определения его не существует. Обычно, по соглашению, оно охватывает множество свойств, каждое из которых может существовать отдельно от другого. Однако, включение или исключение определенных свойств все еще спорно. Это приводит к вольной трактовке термина: точка зрения, что объектно-ориентированный = хороший может смазать истинную картину. В реальном мире сила современных объектно- ориентированных систем (ООС) основана на уникальной комбинации идей, составляющих и углубляющих друг друга. В разделе 1.2 будет показано, как преимущества использования ООС могут стать естественным следствием таких основных идей.

В данном обзоре термин объектно-ориентированный определяется на основе четырех базовых свойств:
- данные и процедуры соединяются в совокупности, называемые объектами;
- сообщения используются для взаимосвязи этих объектов;
- схожие объекты группируются в классы;
- данные и процедуры могут наследоваться в иерархии классов.

Любая система (язык, инструментальное средство или методология) является объектно-ориентированной, если она поддерживает все четыре понятия. Если она удовлетворяет только первым двум, то система называется просто объектной. Если она удовлетворяет только первым трем понятиям, то она основана на классах [Wegner 1987]. То обстоятельство, что система не поддерживает все четыре понятия, вовсе не означает, что она плохая. Объектные системы играют важную роль в таких областях, как проектирование ОС или составление документации.

Дальнейшее различие следует сделать между системами, поддерживающими ООС и теми, которые просто позволяют им существовать. В данном отчете принята точка зрения, что "язык поддерживает стиль программирования, если он имеет средства, делающие его удобным (достаточно простым, надежным и эффективным) для применения этого стиля" [Stroustrup 1988]. В противоположность этому, язык может просто давать возможность применять стиль - с ощутимой изобретательностью и сложностью. Можно писать объектно-ориентированные программы на языке Си (и на любом другом языке), но Си не поддерживает ни одно из вышеперечисленных свойств. Поскольку на рынке уже появилось множество объектно-ориентированных языков, такие упражнения выглядят мазохистски.

Объектно-ориентированная идея также очень близка при проектировании баз данных и в методологиях разработки ПО. Эти вопросы обсуждаются в части C. В этой главе подробно описаны основные свойства объектно-ориентированных языков с использованием терминологии языка Smalltalk, считающегося самым "чисто" объектно-ориентированным из имеющихся на сегодняшний день языков. В других языках для тех же понятий используются другие термины, чаще всего по историческим причинам. Краткий список таких терминов приводится в конце главы.

1.2. Объекты

В традиционных процедурных языках текст программ пишется и хранится в модулях, соответствующих специфическим процедурам, подпрограммам или функциям. Эти модули составляют блоки, из которых строится полная программа. Структура программы представляет собой последовательность операторов, содержащих вызовы подпрограмм, процедур или функций. Обычно один модуль выполняет одну функцию: например, он может вычислять квадратный корень или длину строки символов.

Программы моделируют реальный мир, в котором нет такого разделения между данными и процедурами. Реальный мир состоит из объектов, состоящих из комбинированной информации, и инструкций для действий над объектами. Между реальным миром и моделирующей его программой возникает концептуальный разрыв. Трудности в его ликвидации наиболее ясны в программах управления поведением физических систем, например, в авиации. Одним из первых применений объектно-ориентированной технологии была разработка системы запуска ракет Minuteman в 1957 г. Компьютер использовался для проектирования и моделирования полета экспериментальных ракет. Процесс был разделен на дискретные компоненты, созданные специалистами. Система выдавала информацию, передаваемую между компонентами: траектория, например, могла запросить у сопла, какую нагрузку на ось использовать для данной скорости и высоты [Ten Dyke 1988]. Хотя в то время еще не использовался термин "объектно- ориентированный", уже присутствовало основное понятие объектов, содержащих данные и методы, и взаимодействующих через посылку сообщений.

В 60-х гг. необходимость моделирования физических систем с помощью компьютерных программ привело к созданию языка Simula, в котором основной строительный блок или модуль был объектом: пакет, состоящий из данных и обрабатывающих их процедур, называемых методами. Данные и методы хранились и модифицировались как единое целое. Эта простая идея стала основой построения объектно-ориентированных систем.

Объекты дают естественный механизм скрытия информации. "Потребитель", использующий объекты, должен знать только имена и функции находящихся в них методов. Данные объекта и тексты функций известны только "производителю", создавшему их. Механизм защиты такой информации называется инкапсуляцией. Представьте объект в виде капсулы, в центре которой хранятся данные. Доступ к данным ведется через методы, доступ к которым осуществляется через сообщения от потребителя. Поверхность капсулы состоит из общей информации, содержащей имена и определения методов. Для вызова метода объекту посылается сообщение, сравнивающее его со списком имен методов. Если находится соответствие, метод активизируется и соответствующий ответ посылается потребителю; в противном случае посылается сообщение об ошибке.

1.3. Классы

1.3.1. Связь между объектами

Объекты реального мира не существуют изолированно - они связаны между собой общими свойствами и отличаются друг от друга тем, что не является общим. Например, все домашние кошки относятся к виду Кошачьих. Вид обладает набором характеристик, являющихся общими для всех его представителей: зубы, прячущиеся когти. Определенное животное, кот Том, живущий в доме, имеет характеристики, отличающие его от других кошек: вес (3 кг), окрас (рыжий) и порванное левое ухо. Мы можем рассматривать Тома как экземпляр класса Кошачьи, наделенный от рождения собственными частными данными, хранящимися в его генах, и модифицирующийся сообщениями от других кошек.

Поскольку объект вводится как основной блок построения структуры программы, естественным шагом было объединение схожих объектов в классы. Класс - это объект, содержащий определение всех данных и методов, применяемых к его членам. Некоторая часть информации принадлежит самому классу: это переменные класса и методы класса. Некоторая часть информации принадлежит отдельным объектам, являющимся экземплярами класса: во время их создания они инициализируются специальными данными, или переменными экземпляра, отличающими их от других объектов этого класса. Методы, которые можно применить к этим данным, называются методами экземпляра.

И т. д.

1.4. Наследование

1.4.1. Иерархии классов

Одним из первых действий, предпринимаемых человеком при попытке понять окружающий мир, является применение к нему некоторой структурной формы. При встрече с неизвестным объектом мы пытаемся втиснуть его в нашу существующую структуру: другими словами, классифицировать его. Большинство людей знакомо по крайней мере с несколькими классификационными структурами или иерархиями, например, используемыми специалистами по животным для демонстрации связей между различными типами животных.

Мы примерно представляем себе, какое место в иерархии животных занимает семейство кошачьих Felidae. Если в зоопарке мы встречаем оцелота, то мы сразу можем сказать, что он принадлежит семейству кошачьих. Латинское название (Felis pardalis) подтверждает это. Мы многое знаем об этом животном. Мы знаем, какие характеристики унаследованы от класса позвоночных, млекопитающих, плотоядных и кошачьих. Для полного описания нам требуется только отметить те черты, которые отличают оцелота от других кошек: например, размер и отметины на шкуре.

Использование иерархии классов вводит необходимость абстракции. Классы становятся более абстрактными по мере продвижения вверх по иерархии. Мы еще имеем представление о том, как может выглядеть обобщение кошачьих (Felidae) , но что касается плотоядных - это уже смутное изображение зубов и когтей. Абстракции типа "плотоядный" позволяет специалисту по животным строить иерархию, в которой подклассы определяются путем добавления дополнительных деталей в существующие классы.

Объектно-ориентированные языки используют такой же подход. Иерархии обычно начинаются с нескольких абстрактных классов. Каждый новый класс представляется как подкласс существующего класса (называемого его суперклассом) . Он наследует данные и методы от классов, стоящих выше в иерархии. Только те данные и методы, которые являются новыми для этого класса, следует определить и реализовать.

И т. д.

1.5. Полиморфизм

1.5.1. Интерпретация сообщений

Объекты реального мира отвечают по-разному на одно и то же сообщение. Животные, даже в пределах одного семейства, по-разному реагируют на угрозу атаки. В физической системе сигнал, посланный группе датчиков, приведет к различным ответам отдельных датчиков. Сообщения, посланные объектам, наделены таким же свойством. При этом такие сообщения называются полиморфными, так как они выступают в нескольких различных видах. Например, операция "+" обычно используется для получения разнообразных результатов:
- сложение целых чисел: 1 + 2 = 3
- сложение чисел с плавающей точкой: 1.1 + 2.5 = 3.6
- сложение дробей: 1/2 + 5/6 = 4/3
- сложение векторов: (1, 2) + (5, 6) = (6, 8)
- конкатенация строк символов: `abc' + `def' = `abcdef'

Первые две интерпретации этой операции поддерживаются в большинстве современных языков. Для интерпретации остальных следует предпринять специальные шаги.

Полиморфизм - это естественное следствие инкапсуляции методов в объектах. Поскольку интерпретация сообщения производится получившим его объектом, такое же сообщение можно посылать различным объектам. Например, при получении имени метода "+", объект-вектор проверяет, есть ли у него метод для этого имени. Если он есть, метод выполняется; в противном случае выдается сообщение об ошибке.

1.5.2. Связывание сообщения с методом

Объектно-ориентированные языки могут осуществлять поддержку более широкого использования полиморфизма по сравнению с другими языками. Интерпретация полиморфного сообщения зависит от типа задействованных данных. Однако, языки различаются по степени проверки типов данных и затраченного на это времени. Проверка типов может осуществляться либо компилятором, либо во время выполнения программы. При проверке типов во время компиляции связка между сообщением и методом может делаться компилятором. Это называется статическим (ранним) связыванием. Полиморфные сообщения можно посылать только объектам, тип которых известен во время компиляции. Динамическое (позднее) связывание происходит при проверке типов данных и связывании сообщения и метода во время работы программы. В этом случае полиморфное сообщение можно посылать любому объекту, который сможет его интерпретировать. На пути достижения полного полиморфизма встречается несколько стадий:
- для языка определен небольшой набор фиксированных типов. Если данные определяются для использования в программе, им дается один из таких типов: например, числовые данные можно определить как целые или с плавающей точкой. В язык встроена небольшая степень полиморфизма, например, использование операции "+" как для сложения целых, так и чисел с плавающей точкой;
- программисту разрешается определять новые типы данных. В языке Си, например, тип векторных данных можно задать как пару целых чисел с помощью оператора typedef. Однако, операция "+" не может использоваться для сложения таких векторов, поскольку нет способа расширить ее смысл для такого применения;
- для расширения смысла операций применяется переопределение существующих операций. Операцию "+" можно использовать для сложения векторов в языке Ада, поскольку компилятор проверяет тип параметров и определяет, какую интерпретацию дать данной операции;
- типы данных проверяются во время работы программы. В зависимости от задействованных типов данных система может интерпретировать сообщение несколькими различными способами. Связь между сообщением и методом осуществляется динамически. Можно выполнять общие операторы типа X + Y, при условии, что каждый объект X имеет метод, соответствующий сообщению + Y.
- Smalltalk принимает подход динамического связывания, который иногда считается ключевой особенностью объектно-ориентированных языков. На практике необходимость статического или динамического связывания зависит от типа обрабатываемых данных. Набор объектов может быть связан прочно и непрочно [Cox 1986] в зависимости от того, как много заранее известно о природе объектов, составляющих набор. Тип данных каждого объекта можно узнать во время компиляции: например, при работе с числами с плавающей точкой или векторами. Такие тесно связанные наборы больше всего подходят для статического связывания. Непрочно связанные наборы объектов, поведение которых трудно предсказать, требуют динамического связывания. Например, проект автоматизации почтовой связи может содержать объект Container с именем Mailbox. Он может содержать ряд объектов разнообразных типов (Calendar, Envelope, Pricelist) . Конкретное содержание Mailbox в любое время предсказать нельзя.

И т. д.

2. ПЛЮСЫ И МИНУСЫ ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ СИСТЕМ

2.1. Введение

Объектно-ориентированные системы названы в прессе последним ответом на "кризис ПО". Такие же заявления ранее делались и для других технологий и методологий - поэтому понятно, прочему при чтении таких строк менеджеры цинично усмехаются. Fred Brooks сравнил поиск решения проблемы роста цен на ПО с поисками серебряной пули, которой можно убить оборотня в сказках. Он заключает: "Нет ни одной разработки ни в технологии, ни в управлении, которая бы предложила хотя бы одно безоговорочное увеличение производительности, надежности и простоты" [Brooks, 1987]. Однако, он уверен, что объектно-ориентированное программирование более перспективное, чем другие технические новинки сегодняшнего дня. Он указал три линии атаки, к которым применимы объектно-ориентированные технологии: 1) лучше покупать, чем делать самому; 2) принятие быстрого прототипирования; и 3) расширение ПО, а не его разработка.

В главе указаны четыре важных преимущества, полученных от использования доступных сейчас объектно-ориентированных систем. Они основаны на опыте первых пользователей. Вот эти преимущества:
- концептуальная ясность в разработке системы;
- надежность системы, вытекающая из простоты работы с ней;
- повторное использование исходных текстов программ; гибкость при модификации и расширении системы.

Из этих преимуществ естественно вытекает увеличение производительности. Эти преимущества связаны с основными объектно-ориентированными идеями, обсуждавшимися в 1. Однако, большинство упоминаемых в обзоре систем находятся на начальной стадии своего развития, поэтому реальность имеет тенденцию быть субъективной. В общем случае в настоящий момент существует мало объективных оценок выигрыша в производительности, полученных в результате использования объектно-ориентированной технологии. Причины:
- коммерческие реализации встречаются пока редко;
- стандартные оценки производительности применять нельзя. Например, повторное использование текстов программ снижает общее количество строк программы, но это нельзя использовать как оценку производительности.
- прикладные задачи не могут заменить существующие системы: они дополняют эти системы или обеспечивают их новыми функциями, которые сложно или дорого было реализовать с помощью общепринятых систем.

Более того, разброс цен на жизненный цикл ПО показывает, что около 67% общей цены составляет фаза сопровождения ПО [Hewlett and Durham 1987]. Затраты на написание программ равны около 7% стоимости жизненного цикла, поэтому выигрыш в 300 или 400% дает только видимость эффекта. Реальный выигрыш от использования ООС можно подсчитать только по достижении конца жизненного цикла первого поколения систем.

Если объектно-ориентированные системы настолько производительны, то почему они не так широко применяются? Основная причина заключается в том, что пользователи и прикладные задачи ограничены определенными техническими областями, указанными в разделе 3.1, вследствие ограничений самих объектно-ориентированных систем. Пользователи привели примеры проблем, возникающих вследствие несовершенства доступных продуктов - эти проблемы обсуждаются в разделе 2.3. Кроме того, на использование объектно-ориентированных систем в коммерческих задачах влияют две технических проблемы: недостаток постоянной памяти для объектов и производительность. Эти проблемы рассматриваются в разделах 2.4 и 2.5.

Для достижения успеха в главном направлении коммерческой деятельности объектно-ориентированные системы сами должны стать частью этого направления. Для этого они должны удовлетворять основным требованиям в пяти областях: Надежность, Доступность, Сопровождаемость, Производительность и Безопасность, которые можно зашифровать по-английски RAMPS: Reliability, Accessibility, Maintainability, Performance и Security) [Ten Duke 1988]. Среди этих требований надежность и сопровождаемость считаются преимуществами данной технологии. Однако, если ООС будут широко использоваться, поставщиками также должны выполняться другие требования:
- ООС должны работать на стандартной аппаратуре под традиционными ОС;
- ООС должны иметь интерфейсы для существующих прикладных пакетов и баз данных;
- ООС должны поддерживать несколько пользователей;
- ООС должны охватывать все важные области применения;
- ООС должны конкурировать с традиционными языками в вопросах эффективности и производительности;
- ООС должны обеспечивать защиту ценной информации от неопытных или посторонних пользователей.

Производители ООС в целом высоко оценивают эти требования и пытаются решить существующие задачи. ParcPlace Systems, Digitalk и Stepstone отмечают в качестве основной области разработок необходимость переноса их ПО на различные платформы. Tektronix работает над поддержкой групп программистов, работающих на языке Smalltalk. Bull разрабатывает связки с традиционными языками программирования и 4GLs.

По мере принятия объектно-ориентированных систем все более широким кругом пользователей вопросы производительности становятся все важнее. В то время как некоторые разработчики полагаются в этом вопросе на быстрые процессоры, другие считают, что ответом послужит развитие аппаратной поддержки объектно-ориентированной архитектуры. Текущие исследования в этой области описаны в 4.

2.2. Преимущества объектно-ориентированных систем

2.2.1. Концептуальная чистота

Использование программных объектов для моделирования объектов реального мира имеет два важных эффекта:
- уменьшает концептуальный разрыв, преодолеваемый разработчиками при создании компьютерной системы;
- позволяет разработчику моделировать системы, ранее считавшиеся слишком трудными или сложными для работы.

"Реальный мир" используется здесь в очень широком смысле, поскольку моделируемой системой может быть все, что угодно, от ракетной установки до другой программной системы. Зернистость разработки (т.е. размер модулей, на которые она расчленяется) основывается на определении соответствующих объектов данной области, которые можно сгруппировать для формирования классов объектно-ориентированной системы. Примеры широкого спектра таких классов:
- датчики и сканеры в измерительных и управляющих системах;
- дома в географической информационной системе;
- кружки для диаграмм данных в CASE;
- файлы и очереди в ОС;
- сети в адаптивной инженерии знаний.

Естественное соответствие один-в-один между объектами в предметной области и программными объектами подчеркивается большинством пользователей. Например, Wild Leitz обнаружил, что объектно- ориентированные понятия отлично проявили себя в больших графических задачах, требующих комплексного управления данными. В BehavHeuristics плавный переход от понятия к классу и от процесса к методу позволил гораздо легче разрабатывать и использовать ПО.

2.2.2. Надежность

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

Сокрытие информации и использование абстрактных классов - это способы снижения риска случайной порчи текстов программ, при которых объем информации о внутренней структуре других модулей, доступной пользователю, ограничен. Инкапсуляция - это форма скрытия информации, увеличивающая надежность и упрощающая работу, вследствие:
- ограничения информации до определения интерфейса модуля, в котором указано, какие сообщения можно посылать модулю и какой может быть ответ - т.е. разделение на "что" и "как";
- ограничения влияния любых изменений данных на объект, работающий с этими данными.

Наследование поддерживает понятие абстракции, гарантируя, что общие методы можно держать в классах на верху дерева иерархии и что доступ к ним осуществляется только через механизм наследования. Только те методы, которые являются специальными для разрабатываемого класса, должны быть заново запрограммированы.

Сейчас слишком рано давать количественные оценки о повышении надежности объектно-ориентированных систем, полученных в результате практического использования таких систем. Пользователи сделали качественные оценки, на основе которых можно сказать, что использование объектно-ориентированных языков продемонстрировало новый подход к вопросу дальнейшего развития ПО.

2.2.3. Повторное использование

Текст программы в некоторой степени всегда использовался несколько раз. Программисты используют свои собственные программы, а также заимствуют на неформальной основе программы других. Фирмы составляют собственные библиотеки программ. Существуют библиотеки стандартных программ, например, для вычисления синуса углов, квадратного корня. Можно пользоваться графическими примитивами для разработки графических пакетов. Особая форма повторного использования, присущая только объектно-ориентированным системам, вытекает из наследования. Классы могут быть:
- частью языка, например, в языке Smalltalk;
- добавлены в язык продавцом, например, Stepstone;
- получены от третьих лиц, например, Knowledge Systems Corp;
- созданы для внутреннего пользования в определенной задаче.

Наибольший интерес представляет последняя группа. Фирмы обычно разрабатывают одновременно целый ряд взаимосвязанных пакетов программ. Область, моделируемая этими пакетами, остается той же самой, хотя отдельные объекты могут меняться: некоторые устаревают и заменяются новой технологией. Наследование позволяет фирме наилучшим образом тратить время и силы на основе существующего ПО, в то же время быстро реагируя на изменения рынка.

Преимущества повторного использования стали видны, как только первые пользователи перешли на новую фазу разработок с помощью существующих библиотек классов. Cadre обнаружил тенденцию к снижению стоимости: тексты новых программ стали намного меньше вследствие использования механизма наследования. Выбор языка Smalltalk означал для CSC и BehavHeuristics, что пользовательский интерфейс поставлялся бесплатно, сократив важное время на разработки. Программа была быстро написана и распространена, что означало, что фирма могла быстро реагировать на требования рынка, а стоимость разработок стала ниже, благодаря снижению объема текстов.

2.2.4. Гибкость

В процедурном программировании строительные блоки, составляющие полную программу - это функции и подпрограммы. Многие из них специально предназначены для доступа к данным, например, модули для открытия файла, вывода содержимого файла на экран или печати диагностики. Данные и исходные тексты хранятся и изменяются по-отдельности. Таким образом, изменение структуры данных означает, что все процедуры доступа к этой структуре должны быть изменены и перекомпилированы. Расширение программы данными, не входящими в исходное представление - сложное и вызывающее ошибки дело.

Обработка набора элементов в процедурных языках осуществляется с помощью оператора CASE или вложенных операторов IF. При добавлении в набор дополнительного элемента оператор CASE должен модифицироваться, а содержащий его модуль - перекомпилироваться. На практике на набор можно ссылаться в различных местах системы. Расширение набора для включения в него нового элемента приводит к определению всех модулей, ссылающихся на набор, внесению исправлений во все операторы CASE и перекомпиляции всех модулей.

Полиморфизм повышает гибкость системы. При добавлении в набор нового элемента в систему добавляется новый программный объект. Этот объект обладает методами реализации всех функций, выполнения которых можно запросить у этого элемента. Только эти новые методы нуждаются в написании и компиляции: существующая система остается прежней. Сообщения, уже применяемые к другим элементам, можно применить и к новому элементу.

Гибкость, обеспечиваемая объектно-ориентированной технологией, является важным фактором для многих пользователей. Combustion Engeneering смогла разработать систему, в которую в будущем станет гораздо легче интегрировать новые типы аппаратуры типа датчиков. Новый датчик будет иметь соответствующий ему программный объект, который унаследует обобщенное поведение от своего класса, и в то же время сможет отвечать на стандартные сообщения специфическим образом. Coopers & Lybrand пользуется объектно-ориентированной технологией баз данных в качестве части систем учета членов профсоюза, т.к. производство постоянно меняется и системы требуют постоянной модификации.

2.3. Сложности, с которыми столкнулись пионеры

2.3.1. Смена парадигмы

Хотя разработчики и отмечают, что объектно-ориентированный подход облегчил переход от реального мира к программной системе, программисты, работающие в области объектно-ориентированного программирования, отмечают сложности в переходе от процедурных к объектно-ориентированным языкам. Это означает, что концептуальный разрыв сдвинулся со стадии разработок до стадии программирования. Объектно-ориентированный подход ставит перед программистом новую парадигму, или шаблон, которому надо следовать. Возникающее изменение иногда называется "сменой парадигмы". Программист должен перейти к новым терминам:
- новый строительный блок: объект;
- новая модель коммуникации: посылка сообщений;
- новая связь между модулями: наследование.

В некоторых объектно-ориентированных языках, например, в Smalltalk, они должны также разбираться в обширной библиотеке классов.

С другой стороны, инженеры отмечают, что им легче приспособиться к новому подходу. У них есть преимущество - их работа ближе к области моделируемого реального мира, кроме того, вследствие образования они более знакомы с идеями иерархии классов.

Переход от процедурного к объектно-ориентированному программированию оказался наиболее трудной задачей для некоторых пользователей: Wild Leitz и Cadre отмечают, что обучение было более длительным, а наличие навыков управления проектированием - более важным по сравнению с традиционными системами.

2.3.2. Нехватка инструментальных средств

Для первых пользователей проблемой было несовершенство доступных продуктов, что очевидно для новой технологии. Первые пользователи Objective-C (Combustion Engineering и Wild Leitz) и C++ (Cadre) отмечали, что нехватка полной программной среды замедляла проект и увеличивала уже имеющиеся сложности в изучении нового подхода. С другой стороны, Smalltalk дает достаточную поддержку отдельному программисту: это было отмечено как преимущество (CSC and BehavHeuristics).

Поддержка использования объектно-ориентированной технологии в больших проектах остается проблемой. Инструментальные средства, в настоящее время доступные пользователям, описаны в С2, в то время как инструменты Case для поддержки объектно-ориентированных проектов, приведены в С5.

2.3.3. Возрастающая нужда в управлении проектами

Недостаток инструментальных средств и опыта программистов означает, что дополнительные требования предъявляются к менеджерам проектов (наряду с необходимостью убедить высшие инстанции в целесообразности проекта) . Советы начинающим пользователям:
- Выбор проекта: начните с небольшого, изолированного проекта или с нескольких интерфейсов и локализуйте переход.
- Штат: выделите основных исполнителей, имеющих гибкий ум или большой опыт в разработке проектов. Убедите их в необходимости перехода к новой технологии. Если есть возможность, наберите людей, знакомых с объектно-ориентированной технологией.
- Обучение: от разработки системы, объектно-ориентированных понятий до собственного опыта программистов. Используйте известные термины и пробуйте углубить познания с помощью примеров программ. Затем добавьте формальное обучение. Допустите более длительные сроки обучения и не скупитесь на начальные усилия.
- Процесс разработки: пользуйтесь прототипами. Работайте небольшой командой.
- Навыки управления проектом: не надо недооценивать необходимость усилий и хорошей структуры проекта. Объектно-ориентированная технология - это инструмент, а не причина ослабления принципов менеджмента и управления.

2.4. Нехватка постоянной памяти

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

С другой стороны, объектно-ориентированные системы, не предназначались изначально для коммерческих задач обработки данных, требующих управления большими объемами данных. Они происходили из языков типа Simula, предназначенных для моделирования дискретных событий. Данные в объектно- ориентированных системах скрыты внутри объектов и теряются при завершении программы даже если предприняты шаги к их сохранению.

Например, Smalltalk был предназначен для индивидуального пользователя на мощной рабочей станции: он имеет различные способы сохранения и распространения работы пользователя. Тексты программ можно записать в файл диска и затем восстановить. Текущее состояния системы можно сохранить в виде образа системы, а затем восстановить. Изменения в системе записываются в файл change.log, позволяющий координировать различные версии и восстановить систему в случае ее краха.

Дальнейшие ограничения накладываются на объектно-ориентированные системы объемом памяти для хранения всех объектов, созданных в системе.

И т. д.