Принимаясь за статью, посвященную объектно-ориентированному подходу, чувствуешь себя ломящимся в открытую дверь. Действительно, известия о новых ОО продуктах и технологиях поступают чуть ли не ежедневно; а фраза типа "при разработке данной системы использовались передовые методы ОО программирования" стала стандартным рекламным слоганом. Если разбудить темной ночью любого студента компьютерной специальности, и то он, не протирая глаз, отрапортует, что ОО зиждется на трех китах - инкапсуляции, наследовании и полиморфизме, и что он всем этим владеет, потому как программирует на С++. А опрос руководителей программистских подразделений отечественных кампаний на предмет овладения объектными технологиями покажет, что 90% их разработчиков являются специалистами в С++ , а 60% - в других ОО языках. Так что агитировать за ОО вроде бы некого и незачем - все и так уже сагитированы и, надо полагать, пожинают плоды передовой технологии. Так ли это? Не претендуя на всеохватность и отвлекаясь от технических деталей, данная статья представляет обзор тенденций развития объектных технологий.

А как на Западе обстоит дело с ОО? Исходя из того непреложного факта, что все, имеющее отношение к ОО, будь то концепции, технологии, операционные системы, СУБД, CASE-средства, среды и языки программирования, книги, статьи, просто новости, наконец, приходят к нам "оттуда", можно было бы ожидать, что уж там-то ничего из разряда "не ОО" просто не осталось. Однако, это далеко не так. Часто приходится слышать, что от объектной технологии не в восторге программисты, ее с трудом понимают менеджеры, что ее эффективность проблематична, что ее внедрение требует слишком радикального изменения процесса разработки, что это дорого и т.д. Наконец, еще один немаловажный факт: доля разработчиков крупнейших американских кампаний, владеющих ОО методами, составляет лишь 3% (хотя эта цифра и отражает искажающее влияние огромного на Западе контингента Cobol-программистов).

Что ж, сравнивая "два мира - две судьбы", можно сделать один из двух выводов. Либо все дело в том, что наши программисты просто-напросто могут дать 100 очков вперед западным коллегам. Либо мы как-то не так понимаем, в чем же, собственно, суть ОО технологии, потому что не видим ее за многочисленными техническими деталями, часто черпаемыми в материалах коммерческого толка.

На Западе, во всяком случае, некоторые крупные авторитеты сомневаются, что суть объектной технологии полностью понята ее возможным массовым потребителем. Видимо, не случайно такие общепризнанные гуру объектного подхода, как Гради Буч (Grady Booch) и Бертран Мейер (Bertrand Meyer) недавно сочли необходимым выйти к профессиональной аудитории с новым описанием мотивации, глубинной философии и базисных принципов, лежащих в основе ОО подхода. С другой стороны, с серией публикаций о глобальных перспективах программных технологий недавно выступили такие признанные во всем компьютерном мире специалисты, как Тед Льюис (Ted Lewis) и Эдвард Йодан (Edward Yourdon).

Глобальная ОО футурология и современный кризис

В известном футурологическом труде Френсиса Фукуямы "Конец Истории и Последний Человек" [1] утверждается, что существует две глобальные движущие силы, определяющих эволюцию всех социальных институтов. Первая - это логика и направление развития современной науки (в весьма широком смысле слова), приводящая в конечном итоге через накопление знаний об эффективном распределении и использовании человеческих и природных ресурсов в рамках свободных рынков к современному постиндустриальному обществу - логичному, стабильному и в этом смысле окончательному - последнему в Истории. Вторая - это борьба (в широком смысле) индивидуального человека за признание, которая и реализует упомянутую логику через изменение общественных отношений. В постиндустриальном обществе роль человека существенно иная и не требует привычной борьбы за лучшее будущее. Вот почему этот человек - "последний": революционные потрясения, предполагавшие постоянную смену парадигмы его устремлений, закончились.

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

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

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

Согласно учебникам, среди авторов которых не последнее место занимает и сам Буч, процесс разработки должен на всех стадиях жизненного цикла быть упорядоченным, дисциплинированным, управляемым и предсказуемым, следующим четкой методологии на базе идеи адекватной программной архитектуры. На практике, как отмечает Т.Льюис [3], эта модель далека от реальности. На самом деле вместо "божественного плана" царствует "цифровой дарвинизм". За примером далеко ходить не надо: история разработки объектной линии DLE - OLE - ActiveX являет собой приложение теории хаоса к программной индустрии. Различные версии этих продуктов столь не похожи друг на друга, и столь архитектурно ущербны, что становится ясно: в процессе разработки вместо заранее продуманного плана имели место малоуправляемые мутации. Причем аналогичным образом обстоит дело и у конкурентов Microsoft. Подобных примеров "лихорадки джунглей" Т.Льюис набрал на целую книгу, которая вскоре выйдет из печати.

Об этом свидетельствует и статистика. Среди многих и часто разноречивых цифр, характеризующих ситуацию с программными проектами, сошлемся на сравнительно недавнее исследование фирмы Standish Group под красноречивым названием "Хаос" [4]. В 1995 году ожидалось, что только 9% проектов, выполняемых крупными компаниями, будут завершены в срок и без превышения запланированного бюджета; 52% проектов должны были стоить в среднем 189% от их первоначально оцененной стоимости; в то же время 31% всех проектов вообще ожидало приостановление или полное прекращение, причем затраты на них - ничем не компенсируемые убытки - оценивались ни много ни мало в 81 млрд. долл. - цифра, просто поражающая воображение.

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

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

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

И все-таки именно объектная технология в ответ на "индустриальный вызов" предлагает небольшой, но в определенном смысле исчерпывающий набор из (по выражению Б.Мейера [5]) "пяти мощных идей". Рассмотрим их более подробно, тем более, что в совокупности они предлагают нечто большее, чем обычно упоминаемая триада из инкапсуляции, наследования и полиморфизма.

ОО концепты

Децентрализация. ОО технология - это прежде всего - архитектурная дисциплина в том смысле, что она позволяет сфокусироваться на высокоуровневой структуре программной системы, издаваемой как сеть сотрудничающих агентов-объектов, между которыми определены только два отношения: поставщик-клиент и родитель-наследник. Именно эти поистине драконовские ограничения обеспечивают то критическое свойство системы, которое Ф.Брукс назвал концептуальной целостностью (conceptual integrity). При этом уходят от таких понятий, как "основная программа", "глобальные переменные", "проектирование сверху-вниз" и т.п., предполагающих, что система обязательно имеет некий центр.

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

Выбор "стратегической" архитектуры оказывает определяющее влияние на разработку системы. Г.Буч [6] выделяет следующие восемь взаимопересекающихся категорий, располагая их в виде четырех слоев:

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

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

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

Самодостаточность (selfishness). Как замечает Б.Мейер, это наиболее известная, но наименее понимаемая часть ОО технологии - около 10% от практикующих ОО подход специалистов на самом деле владеют ею. Обычно используются более привычные, но и в какой то степени затуманивающие суть термины - "скрытие информации" или "инкапсуляция". Основная идея в том, что объект-поставщик раскрывает клиентам только часть своих свойств, причем в идеале именно в том объеме, который необходим. Большинство программистов привыкло считать, что этот механизм помимо возможности изменения реализации без изменения спецификации введен прежде всего для защиты поставщика от несанкционированного клиентского доступа, дабы тот не прознал тайны реализации, или не испортил ее. Это чисто программистский взгляд, имеющий мало общего с существом ОО методологии.

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

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

Классификация. Какие объекты (классы и их экземпляры) использовать в конкретной разработке - вот критический вопрос при применении ОО технологии. То, что в ОО технологии называется "создание иерархий с наследованием" и есть классификация, отображающая неупорядоченный реальный мир в упорядоченный мир объектов с попутным обнаружением общности в их ключевых абстракциях и реализующих поведение механизмах. Б.Мейер [7] описывает 12 различных типов наследования, разделенных на три категории.

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

Бесшовность. Идея бесшовности (связности, цельности - seamlessness) относится к наименее понимаемым аспектам ОО технологии. Суть ее в том, что модели системы на этапах анализа, проектирования и реализации обладают такой степенью связности, что изменения в одной из них можно легко и безболезненно отобразить на другие. Это позволяет реализовать такое важное при итеративном проектировании свойство, как трассируемость (traceability). Очевидно, что при этом должно быть четкое (прежде всего - структурное) соответствие между элементами моделей на различных фазах жизненного цикла. Из бесшовности следует обратимость (reversibility), гарантирующая согласованное изменение моделей не только в прямом (от требований к реализации), но и в обратном направлении. Реализация этой идеи предполагает большую моделирующую мощь используемой ОО методологии и интеграцию применяемых на ранних фазах жизненного цикла CASE-средств со средой программирования. Свойства трассируемости и обратимости являются основой для реализации эволюционных моделей жизненного цикла программных систем, будь то "спиральная" модель Боэма, "водоворотная" модель Вильямса (Williams) или "фонтанная" модель Хендерсона-Селлерса (Henderson-Sellers).

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

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

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

ОО методологии

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

По сложившейся практике, наряду со смысловыми названиями (или вместо них), методологии получали имена своих создателей. Среди них Booch, OMT (Object Modeling Technique), Object-Oriented Systems Analysis and Recursive Design (Shlaer/Mellor), CRC (Class, Responsibility, and Collaborations), Responsibility-Driven Design (Wirfs-Brock), Object-Oriented Analysis and Design (Coad/Yourdon) и другие. Почти все методологии имели оригинальные графические нотации и нашли поддержку в виде соответствующих CASE-средств. Появились и CASE-средства, поддерживающие одновременно несколько методологий.

В последующие несколько лет резко увеличилось количество публикаций и конференций, посвященных ОО тематике. Интенсивный обмен идеями вместе с приобретаемым опытом реальных проектов привел к появлению методологий второго поколения, Например, Booch 93/94 фактически вытеснил версию 1991 года, а методология Fusion использует CRC, Booch, OMT (плюс формальные методы). Методологии второго поколения стали сосуществовать с более ранними, тоже, впрочем, непрерывно развивающимися.

Тем временем стали проявляться проблемы с рынком CASE средств, которые поначалу многими воспринимались как панацея, а на самом деле оказались лишь инструментом автоматизированной поддержки поставленной методологии. В России фетишизация CASE средств продолжается; показательно, что в русскоязычной литературе принято именовать "CASE технологией" то, что во всем мире называют Software Engineering. Как саркастически подытоживает Т. Льюис [8], "CASE-средства борются с системами искусственного интеллекта за звание самой перерекламированной и не оправдавшей ожиданий софтверной технологии десятилетия". Назрела необходимость в унификации если не подходов, то хотя бы нотаций. Основа для этого - имеющийся консенсус между приверженцами разных методологий относительно основных элементов, которые и должны моделироваться как составная часть ОО анализа и проектирования. Прежде всего, это статические структуры классов и динамические взаимодействия объектов в сценариях. Помимо прочего, унификация позволила бы сократить ассортимент предлагающихся на рынке CASE средств и таким образом нивелировать нынешнюю раздробленность рынка в условиях ухудшения конъюнктуры.

Провозвестником методологий третьего поколения стала попытка унификации под крышей фирмы Rational Software двух самых распространенных методологий. Согласно [8], на конец 1994 г. лидером американского рынка с долей в 40% являлся OMT, разработанный Джеймсом Рамбо (James Rumbaugh) в научно-исследовательском центре фирмы General Electric. Далее с 11% шел Booch93/94 Гради Буча. В конце 1995 г. к Бучу и Рамбо присоединился еще один известный методолог - Ивар Якобсон (Ivar Jacobson), автор OOSE (Object-Oriented Software Engineering) - метода, также известного под названием Objectory, который особо подходит для проектирования больших систем, в частности телекоммуникационных.

О единой методологии говорят с осторожностью как о методологии будущего [9]; пока же работа концентрируется на определении как концептуальных, так и исполняемых ОО артефактов (artifacts), под которыми понимаются "реальные продукты-сущности процесса разработки" [6], а также взаимосвязей между ними. Создана и систематически описана базисная метамодель, определившая семантику всех моделирующих понятий, необходимых на этапах анализа, проектирования и конструирования ОО сложных систем. Удалось выработать единую нотацию - "Унифицированный Моделирующий Язык (Unified Modeling Language - UML)". Версия 0.8 обнародована и - более того - уже поддерживается рядом CASE-средств. Готова и версия 0.9, в которой учтена специфика подхода Якобсона. В начале 1997 года ожидается версия UML 1.0, которая вместе с базисной метамоделью, должна быть признана стандартом через консорциум Object Management Group (OMG). Это будет означать, что UML может быть использован для описания процессов в рамках различных методологий. Следует добавить, что авторы одновременно ведут работу над несколькими книгами, посвященными разным аспектам их подхода.

Значительно более амбициозной, направленной не просто на традиционный процесс анализа, проектирования и реализации программного продукта, но имеющей целью охватить полный жизненный цикл программного проекта, включая стратегии стратегического планирования, управления и оценки качества, повторного использования, унаследованных систем и др., является методология OPEN (Object-oriented Process, Environment, and Notation) [10]. Неформальный коллектив, состоящий из двух десятков всемирно признанных экспертов, вознамерился создать не просто новую методологию, а скорее "метаметодологию" в виде открытой ОО инфраструктуры, которая инкорпорирует большое количество идей, методов и приемов из практически всех существующих подходов.

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

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

ОО языки

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

  • Звание языка, "наиболее используемого профессионалами", принадлежит, естественно, C++. Его достоинства и недостатки, проистекающие из его "гибридности" (сосуществования в нем наряду с объектами процедурных сущностей), хорошо известны. Отметим негативное отношение к С++ многих классиков программирования, полагающих, что именно доминирование С++ обусловило многие беды индустрии программирования. Очень характерно, например, следующее высказывание Д.Кнута [12]: "Одна только мысль о программировании на С++ способна сделать его (Э.Дейкстру) физически больным." Соперничает с С++ Smalltalk, который сегодня лидирует в разработках для ряда вертикальных рынков, особенно это заметно в финансовом секторе (где так важно быстрое изготовление системы), а также в архитектуре клиент-сервер, обычно с клиентской стороны. В ближайшем будущем в этой номинации, очевидно, появится Java.
  • "Наиболее элегантным" можно признать Eiffel, являющийся, пожалуй, самым концептуально чистым ОО языком. Особо отметим, что в отличие от других (и прежде всего от С++), в этом языке явно присутствует контрактная модель, поддержанная предусловиями, постусловиями, инвариантами и механизмом исключений. Это позволяет резко повысить надежность разрабатываемых программных средств, особенно в контексте повторного использования. Как следствие, Eiffel, вероятно, наиболее подходит для изучения в качестве первого ОО языка.
  • "Самым <научно-обоснованным> и нетребовательным к ресурсам" является Oberon [17]. Отметим лишь (как еще одно свидетельство зыбкости устоявшихся, вроде бы, понятий) принципиальное нежелание великого программиста использовать в его ОО языке такие, казалось бы, фундаментальные ОО термины, как "наследование","класс" или "метод", которые, по его мнению, ничего не добавляют к понятиям "совместимость", "тип" и "процедура". Думается, однако, что такой ригористический подход слишком акцентирует значимость чисто программистских понятий, что может вызвать проблемы на предреализационных этапах разработки сложных систем. Коммерческие перспективы этого во многих отношениях замечательного языка связаны с судьбой недавно заявленной технологии Juice.
  • "Наиболее надежным для разработки сверхсложных систем" является Ada. Заметим, что Ada 9X - это не просто объектный, но полностью ОО язык. Приведем здесь высказывание Г.Буча [11]: "Многие из систем управления воздушным движением следующего поколения разрабатываются на Ada; как человек, которому приходится часто летать, я чувствую себя очень комфортно, зная это!"
  • "Наиболее гибким" признан CLOS. Будучи интегрированным расширением языка Common Lisp и обладая мощными средствами определения полиморфных операций, он дает программисту очень большую свободу действий во время исполнения, позволяя динамически вводить новые классы и добавлять новые методы. Еще одна уникальная для коммерческих ОО языков особенность - отсутствие механизмов предотвращения доступа одного класса к деталям реализации другого. Такое пренебрежение к сокрытию внутренней структуры класса - одного из базисных принципов ОО программирования - принято считать крайне нежелательным. Существует отличающаяся от ОО парадигма программирования - "определительное программирование" (definitive programming), где ослаблены принципы инкапсуляции и целостности. Здесь объектам позволяется не просто "заглядывать" внутрь друг друга, но и достаточно радикально изменять значения атрибутов как численные, так и функционально или процедурно заданные, а то и саму структуру другого объекта. Это может быть особенно полезно при моделировании небольших по размеру, но сложных по поведению систем с сильным межобъектным взаимодействием. Впрочем, реализация систем определительного программирования пока не вышла за рамки академических разработок.
  • Наиболее любопытным с точки зрения, результата является ОО Cobol. Как известно, около 80% всего программного обеспечения написано именно на Cobol (50 миллиардов строк). Более 2 миллионов программистов продолжают разрабатывать и поддерживать Cobol-программы. Поэтому особенно любопытно, удастся ли ОО технологии разрешить проблему поддержки этого богатого, но тяжелого наследия ("legacy systems" - это ныне особенно быстро развивающееся направление).
  • "Самый перспективный и рекламируемый" - это, конечно, Java. Он важен даже не сам по себе, а как провозвестник принципиально новой технологии, о которой есть смысл поговорить подробнее.

ОО сценарий перехода к технологии 21 века

Наиболее надежной мерой для измерения производительности программистского труда (и одновременно содержательной метрикой применительно к программе) признается FP - "функциональный пункт" (function point) - взвешенная сумма присутствующих в блоке программного кода вводов, выводов, запросов к данным и общих обрабатывающих операций с учетом наличия распределенной обработки, степени повторного использования кода и т.п. По данным фирмы Software Productivity Research [13], выражаемая в виде усредненной стоимости одного FP производительность программистского труда возрастает в среднем на 4.6% в год и составляет сейчас приблизительно 1000 долл./FP. Усреднение проводилось по специальной методике, позволяющей учесть различные виды программных приложений, написанные на различных языках и имеющие разные размеры.

Стоит отметить, что ввод в практику новых языков программирования не слишком принципиально изменяет отношение SLOC/FP (SLOC - source lines of code - количество строк кода), которое уменьшается в среднем на 11% в год (для С++ это отношение около 100, для Smalltalk - около 20). Это означает, что мощность языков и средств программирования растет быстрее, чем производительность программистского труда, но гораздо медленнее производительности аппаратуры. При этом прогноз относительно дальнейшего прогресса обоих показателей в обозримом будущем не выглядит утешительным: например, отношение долл./FP к 2010 году не упадет ниже 500; равно как и показатель мощности языка SLOG/FP не может быть значительно улучшен.

Как следствие, Т.Льюис в своей фундаментальной статье [13] делает вывод: практически всем нынешним коммерческим ОО языкам уготована в будущем маргинальная роль. Так, к 1998 году доход от продаж как С++, так и Smalltalk должен достигнуть 300 млн. долл., после чего прогнозируется плавный рост до 0.5 млрд. и стабилизация на этом уровне вплоть до 2012 г. Кстати, примерно те же оценки справедливы и для Visual Basic. Эти языки слишком сложны с точки зрения массового разработчика будущих программных систем и приводят к содержащим массу потенциальных ошибок продуктам. С++ сможет использовать лишь довольно немногочисленная программистская элита, и даже значительно более простой Smalltalk так и останется "языком программирования", а не станет высокопроизводительным бизнес-инструментом. При этом быстро развивающиеся среды визуальной разработки, будь то Visual C++, PowerBuilder или Delphi все равно требуют от разработчика глубокого погружения в многоуровневые иерархии классов; необходимо также знание архитектурных "образцов", которые могут быть весьма сложны. Следовательно, потребитель в любом случае должен быть квалифицированным инженером, а значит рынок таких средств будет ограничен.

В то же время потенциал ОО технологий позволяет уже к 2000 году прогнозировать доход от их продаж в размере около 5 млрд. долл. Ожидается рост рынка во всех сегментах - ОО операционных систем, баз данных и средств разработки, которые будут опираться на языки и системы нового поколения.

Как указывает Э. Йодан [14], концептуальная ценность Java не в синтаксисе и даже не в органической связи с Web-технологией, а в определении вектора движения к компонентной технологии. Главное следствие - прекращение имевшей место последние годы экспансии "жирного" - слишком объемного программного обеспечения и рост "коттеджной" индустрии программирования, которую пока можно ассоциировать с созданием Java-апплетов, прикрепленных к Web-страницам. Эти транзакционно-ориентированные апплеты можно будет арендовать вместо покупки монолитных программных пакетов.

В отличие от нынешних ОО языков, где фундаментальным средством абстракции является класс, в "языках новой эры" в этом качестве выступает более "крупное" понятие - специфическая для отдельного приложения интегрированная среда (application-specific framework); а вычислительная модель опирается не на стандартное для ОО языков взаимодействие типа "метод/сообщение", а на взаимодействие "событие/обработчик".

Нынешние интегрированные ОО среды, такие как Taligent или OpenStep, могут рассматриваться как прообразы будущего. В соответствии с ОО концептом децентрализации, останется в прошлом подход "главная программа плюс компоненты". Вместо этого, программы будут конструироваться настройкой существующей интегрированной среды с помощью компонентов - модулей, которые не просто инкапсулируют функциональность и данные, но могут быть динамически встраиваемыми (plug-in).

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

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

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

ОО "artisan" как "Последний программист"

Вероятно, самая характерная черта "последнего программиста" - это все меньший акцент на программировании в привычном, особенно для процедурных языков, смысле слова. И уж во всяком случае, не ставится знака равенства между программированием на современных ОО языках (прежде всего - на С++) и ОО технологией разработки программных систем. Одно из главных правил, формулируемых Г.Бучем [6], гласит: "Приступайте к кодированию только тогда, когда откладывать эту работу более невозможно". "Программирование без программирования" - так называет Буч основную деятельность разработчика, главное содержание которой - кодификация абстракций и механизмов, характерных для конкретной предметной области.

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

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

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

***

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

Это и означает, что в скором будущем фактически каждая прикладная структура должна будет существовать в ОО мире. Приведем прогноз Э. Йодана [15]: при разработке приложений объектная технология будет применяться в 40% проектов в 1996 году, 60% - в 1998 и 80% - в 2000 году. Отсюда следует, что в обозримом будущем альтернатив ОО технологиям нет и, как пишет Г.Буч: "Я вижу будущее, и оно - объектно-ориентированное".

P.S. "они" - о "нашем" вкладе в ОО

При подготовке статьи я - увы - нигде не встретил ни одного упоминания о вкладе в ОО технологию российских специалистов. И все-таки, уязвленные патриотические чувства были умиротворены: свидетельство о нашем вкладе в ОО было найдено в очень солидном издании [16] - и весьма многозначительное. Правда, находилось оно в юмористическом разделе и представляло собой одно из первоапрельских "антипредсказаний" - предсказаний о событиях, которые не произойдут в течение года . Вот пара образцов из этой статьи: "Будет обнаружена программа без ошибок"; "Ассоциация Менеджеров Разработки Систем предъявит убедительные свидетельства, что CASE-средства окупают себя".

Предъявляю искомое свидетельство в первозданной чистоте, оставляя перевод и комментарии на долю не лишенного чувства юмора читателя.

"Object orientalism is exposed as the last vestiges of a global Communist plot originally intended to undermine the West"s information systems infrastructure".

Литература

1. F.Fukuyama "The End of History and the Last Man", - New York, NY: The Free Press, 1991

2. G.Booch "The End of Objects and the Last Programmer", - htpp://www.rational.com/pst/tech_papers

3. T.Lewis "Software Architectures: Divine plan or digital Darwinism", - Computer, 8/96, pp. 13-15

4. "Cancelled Software Development Project costs Bilions", - Computer, 8/95, p.94

5. B.Meyer "Object Technology: The Conceptual Perspective", - Computer, 1/96, pp. 86-88

6. G.Booch "Objects Solutions", - Addison-Wesley, 1996

7. B.Meyer "The many faces of inheritance: A taxonomy of taxonomy", - Computer, 5/96, pp. 105-108

8. T.Lewis "The Big Software Chill", - Computer, 3/96, pp. 12-14

9. "Gurus share insights on objects", - Computer, 6/96, pp. 95-98

10. B.Henderson-Sellers, I.Graham "OPEN: Toward Method Convergence? "- Computer, 4/96, pp.86-89

11. G.Booch "Coming of Age in an Object-oriented World", - IEEE Software, Nov/94, pp. 33-41

12. Dr.Dobb"s Journal, 4/96, p. 18

13. T.Lewis "The Next 10,0002 Years: Part 2", - Computer, 5/96, pp. 78-86

14. E.Yourdon "Java, the Web and Software Development", - Computer, 8/96, pp. 25-30

15. E.Yourdon "The Rise and Resurrection of the American Programmer", - Prentice Hall, Englewood Cliffs, N.J., 1996

16. S.Reisman, "Antipredictions for a Perfect World", - IEEE Software, 3/94, pp. 120-119

17. Н.Вирт "Долой жирные программы", Открытые системы # 6, 1996.