Новые решения в области программного обеспечения по-прежнему составляют основу развивающейся взаимосвязи компьютеров и коммуникаций. Некоторые могут возразить, что хотя аппаратные разработки обычно выдерживают темп, определенный в законе Мура, программное обеспечение отстает, все изменения в этой области происходят постепенно, эволюционно, а не революционно. Другие могут заявить, что программные технологии достигли поры зрелости и мы вступаем в новую эпоху, когда усовершенствования в стратегии разработки, языках, архитектурах и интероперабельности будут нарастать не линейно, а экспоненциально.
Учитывая это, Computer обратился к ведущим специалистам, работающим в этой области, чтобы узнать их мнение по поводу направления развития программного обеспечения. Формат круглого стола был достаточно прост. Мы спрашивали участников о некоторых последних разработках в тех областях, где они специализируются, и просили высказать свое мнение о развитии отрасли в целом. И, конечно же, нас интересовал их прогноз о ближайшем будущем технологии.
С большим удовольствием мы представляем читателям Computer мнениеЛарри Уолла, создателя Perl,
Дэвида А. Тейлора, директора компании Enterprise Engines,
Криса Хорна, директора компании IONA Technologies и создателя Orbix,
Пола Бассета, первого вице-президента компании Netron и создателя технологии кадров,
Джона К. Аустераута, директора компании Scriptics и создателя Tcl,
Мартина Л. Грисса, ведущего специалиста компьютерного исследовательского центра Hewlett-Packard Laboratories,
Ричарда Марка Соли, председателя совета директоров и исполнительного директора Object Management Group,
Джима Валдо, ведущего инженера компании Sun Microsystems и главного архитектора Jini,
Чарлза Симоньи, ведущего проектировщика Microsoft Research.
Ответы, которые мы получили на свои вопросы, затрагивают очень широкий диапазон тем, поскольку участники круглого стола рассказывали о многом, начиная с языков описания сценариев и технологий интеграции, и заканчивая оболочками и распределенными вычислениями. Как всегда, мы рады узнать ваше мнение. Направляйте свои письма по адресу computer@computer.org.
Продолжающаяся революция
Ларри Уолл
O?Reilly and Associates
 |
Даже если учитывать миниатюризацию, проектирование оборудования само собой получает преимущество, поскольку удвоение норм проектирования на плате позволяет в четыре раза увеличить число транзисторов - два по цене одного. Но даже на более абстрактном уровне, проблема свободного пространства на аппаратуре не столь важна. Мы подходим к аппаратному обеспечению с более низкими требованиями, чем к программному. Когда мы заставляем компьютер работать в два раза быстрее при том же наборе команд (или даже на сокращенном наборе команд), мы говорим, что он стал в два раза лучше. Но когда мы в два раза улучшаем программное обеспечение по тем или иным параметрам, то тем самым расширяем круг возможных задач в проблемной области, которые могут быть решены с помощью этого ПО, а затем обвиняем его в несоответствии новым требованиям. Это попросту несправедливо.
С другой стороны, программисты слишком часто обвиняют во грехах именно себя. Программистам нужно меньше времени тратить на оправдания. Если программирование не интересно, мы не будем убеждать других стать программистами.
Большие решения для больших задач
Наиболее революционным изменением в проектировании языков на сегодняшний день можно считать тот факт, что мы все больше внимания уделяем более крупным, многофункциональным языкам. Это прямой результат широкого распространения компьютеров. Люди не хотят изучать новый ограниченный язык каждый раз, когда им приходится работать с новым интерфейсом. Сейчас успех будет сопутствовать не маленьким, ограниченным, а большим, многофункциональным языкам, которые могли бы использоваться так, как если бы они были маленькими. В результате, вы не только используете полученные ранее знания, но и ваш язык может лучше масштабироваться с ростом встающих перед вами задач. И вы уверены, что так и будет.
Реальные языки эволюционируют, они не «топчутся на месте». Действительно революционные компьютерные языки похоже не привились. Самыми интересными из последних разработок будут как раз те, которые учитывают особенности и взаимосвязь культурных традиций разных наций. Весь мир превращается в единый компьютер с тесными внутренними связями. Безусловно XML может помочь выполнять преобразование одних форматов данных в другие, но мы работаем и над тем, чтобы упростить процесс программирования для миллиардов потенциальных программистов во всем мире.
Новые версии Perl теперь поддерживают Unicode не только как дынные, но и как программу. Мы думаем о том, как упростить процесс изучения языка Perl. Этот язык уже позволяет вам выбрать уровень обучения, но я считаю, что мы можем сделать больше как для новичков, так и для экспертов. Но в первую очередь для тех новичков, которые хотят стать экспертами.
Не технологический, а социологический
Я надеюсь, что нам не придется столкнуться с кардинально новыми разработками. Это все равно, что ожидать кардинальных изменений в английском языке. Встающие перед нами задачи в области программного обеспечения, скорее можно отнести не к технологическим, а к социологическим. Новое появляется. Но если это новшество не связано с нашим культурным наследием, это скорее новая проблема, а не решение. Массовое использование компьютеров требует массового программирования. Массовое программирование - это обязательно популярное программирование. А люди пока остаются без программы. Большинство людей не могут запрограммировать даже свои видеомагнитофоны.
Такое ощущение, что компьютерная наука ищет некую панацею, которая позволит людям писать корректные программы даже не думая. На самом деле, нам необходимо научить людей думать правильно. И именно здесь компьютерная культура оказывается несостоятельной. Мы забыли о важности фонетических методов изучения компьютерных языков. Мы впали во всеобщее заблуждение, когда считается, что язык надо изучать в целом (лишь недавно от этого избавились наши начальные школы, а некоторые люди не избавятся никогда). Проблема, связанная с изучением языка как единого целого в том, что люди, которые в любом случае хотят выучить язык, его так и так выучат, но те, которым необходимо изучать язык с помощью фонетических методов - откажутся. Также происходит дело и с компьютерами. Существуют миллионы потенциальных программистов, которые не способны изучить C++ или Java просто погружаясь в него. Им необходимо сначала разобраться с простыми концепциями. Им необходимо начинать с детского лепета, прежде чем они смогут защитить свои диссертации (причем быстрее, чем упертые фанатики объектно-ориентированного подхода). Им необходимо начинать петь под душем, прежде, чем брать уроки вокала.
Сама культура компьютерных систем требует эволюционной революции. Онтогенез предполагает закрепление всего накопленного филогенезом. То есть каждый программист должен пройти те же этапы в процессе обучения, через которые прошла и сама компьютерная наука. Программистам необходимо изучать символьное программирование до структурного, а структурное - до модульного и лишь после него - объектно-ориентированное.
Я отдаю себе отчет в том, что подобная точка зрения может вызвать ярость современных революционеров. Называйте меня реакционером, но Perl не смог бы добиться успеха, отвергая уроки прошлого. Один из таких уроков просто-напросто состоит в том, что компьютеры должны помогать людям учиться, когда люди готовы учиться, а в противном случае исчезнуть с глаз долой. Программирование по больше части - вещь необязательная.
Ларри Уолл - создатель языка программирования Perl, модуля чтения новостей rn и популярной системы для генерации «заплаток» для программ. Он получил премию Outstanding Achivment Award за 1994 год, учрежденную System Administrator Guild, и Free Software Award за 1998 год, учрежденную Free Software Foundation. Сейчас он работает в издательстве O?Reilly and Associates, где ведает всеми вопросами, связанными с Perl и сообществом программистов Perl, и рассказывает о том, что вскочить в последний вагон - это еще не значит оказаться в хвосте. Сейчас он работает над третьим изданием книги «Программирование на языке Perl» (Programming Perl, также известной как Camel book), но заявляет, что ему приходиться тратить огромное количество времени на придумывание оригинальных высказываний для своих выступлений, интервью и различных круглых столов вроде этого. С ним можно связаться по адресу larry@wall.org.
Программирование для каждого
Дэвид А. Тейлор
Enterprise Engines
 |
Самое важное для меня в этой ситуации - тот факт, что теперь мы можем предложить эффективное решение. Объектная технология предлагает все лексические новшества, которые нам необходимы для того, чтобы позволить непрограммистам отдавать компьютерам простые команды. Задумайтесь об этом на минутку. Сообщение - это императивное высказывание. Получатель - это предмет данного императивного высказывания (объект, к которому оно обращено), имя метода - это глагол и параметры - прямые и косвенные объекты. Рассмотрим высказывание «Бухгалтерия, предоставить Smith & Co. кредит в размере 420 долл. по инвойсу 1234». Это высказывание можно пословно отразить соответствующим выражением на Smalltalk, подставив вместо параметров соответствующие значения.
Мы создали объекты в соответствии с нашим собственным представлением и они взаимодействуют так, как мы себе это представляем. После того, как нам удалось преодолеть все трудностей, чтобы этого добиться, мы должны использовать то, что мы создали и позволить специалистам по вопросам бизнеса давать простые команды своим компьютерам, предпочтительно с помощью интерфейсов, поддерживающих распознавание речи. Тога мы смогли бы отказаться от этого обременительного компромисса. У нас есть языки описания сценариев, которые могли бы использовать, специалисты, занимающиеся бизнесом, и весь этот процесс был бы настолько далек от того, что мы считаем программированием, что профессиональные программисты об этом даже говорить не будут.
Объектная технология - больше не термин
Наиболее впечатляющий результат эволюции объектной технологии состоит в том, что это выражение больше не является сугубо профессиональным, другими словами, оно теперь для чего-то полезно. Сейчас вы его не употребляете, если конечно не говорите о программных компонентах или технологии агентов и не объясняете, почему эти вещи лучше, чем объекты. Java, который является одним из лучших когда-либо создаваемых объектных языков, ориентирован на Web и не зависит от платформы, но едва ли ассоциируется со словом объектный. Даже Object Magazine изменил название на Component Software, чтобы поддержать свой имидж, как издания, идущего в ногу со временем.
Когда я впервые понял, что это происходит, я был страшно раздосадован, поскольку считал, что отрасль программного обеспечения отказывается от старых объектов, именно в тот момент, когда наконец пришло их время. Затем я вспомнил прогноз, сделанный мною около 15 лет назад о том, что к 2000 году об объектах никто и говорить-то не будет, поскольку эта технология станет настолько распространенной, что никому в голову не придет о ней упоминать. Я подумал, что может быть мое предсказание сбылось.
Использование возможностей компьютера
Существует одно «прорывное» решение, которому я посвятил большую часть своей карьеры и считаю, что мы близки к цели. Я говорю о возможности обычных специалистов по бизнесу в полной мере пользоваться всеми ресурсами компьютера. Сейчас компьютер можно увидеть на столе практически каждого менеджера и мы даем им возможность немного пользоваться базами данных и электронными таблицами. Но даже если они хотят лишь слегка изменить способ работы, они вынуждены обращаться к специалистам по ИТ и пару лет стоять в очереди.
Здесь уместно вспомнить замечание сделанное мною раньше насчет языков описания сценариев. Мы в состоянии предоставить людям возможность отдавать простые устные команды своим компьютерам. Если менеджер диктует серию команд и затем указывает, когда эти команды должны быть выполнены, это и является программированием компьютера. Как только он сможет вносить изменения в свою работу таким образом, не кажется ли вам, что он больше не захочет обращаться к специалистам отдела информационных систем?
Да, я вижу, как вы морщитесь. Поверьте мне, я прекрасно понимаю, почему это плохая идея. Она потребует долгих лет обучения написанию корректных программ. Конечные пользователи способны произвести ужасные разрушения и без этого. Если же такая возможность и будет когда-нибудь реализована, об организации защиты даже подумать страшно. Ну и так далее. Но ни одно из этих возражений не является обоснованной причиной отказываться от очевидных шагов вперед. Если вы вспомните историю развития технологий, то первое внедрение именно тех технологий, которые наиболее зримо изменили нашу жизнь, ограничивалось именно отсутствием специалистов, которые могли бы обучать работе с ними, и реальное распространение они получали только тогда, когда стали предлагаться необученным массам. С компьютерами ситуация несколько иная, но не кардинально.
Революция, начавшаяся с появления ПК, не завершится до тех пор, пока люди, которым эти ПК принадлежат, не смогут использовать их для изменения способа выполнения своих рабочих обязанностей. Сейчас, возможно, в это очень сложно поверить, но со временем это станет очевидно. Я думаю, что когда по прошествии времени мы будем вспоминать этот период, то будет крайне изумляться, почему, чтобы это понять потребовалось так много времени.
Дэвид А. Тэйлор - основатель компании Enterprise Engines. Его предназначение - создавать программное обеспечение нового поколения, которое он называет бизнес-механизмы и определяет как исполняемые бизнес-модели, которые можно динамически модифицировать для адаптации к меняющимся условиям. После пяти лет разработки и создания семи прототипов, его видение реализовалось в основной продукт его компании - Enterprise Engine. Он автор шести книг, в том числе «Объектная технология: руководство менеджера» (Object Technology: A Manager?s Guide Addison Wesley Longman, 1998). Перед тем, как заняться бизнесом он был профессором психологии в университете Рочестера в Нью-Йорке и одним из основателей когнитивистики - науки о мышлении. С ним можно связаться по адресу
dtaylor@engines.com.
Как заставить ПОработать вместе
Крис Хорн
IONA Technologies
 |
Но при этом существует огромное количество конкурирующих технологий, таких как MOM, ORB, OTM, TPM, EAI, EJB, DCOM, COM+, сервер приложений и сервер Web-приложений, которые используют различные подходы для решения тех же задач. В силу вышесказанного, вполне вероятно, что в ближайшее время разработчики и их компании окончательно запутаются в выборе решений. Какой подход принять? Какие необходимы инструментальные средства? Какие стандарты они поддерживают? Какова конечная цель?
Три основных сегмента
Чтобы разобраться, необходимо представлять себе промежуточное программное обеспечение как совокупность контейнеров, компонентов и соединителей. При таком подходе контейнер обеспечивает среду, где могут быть развернуты компоненты приложений. Эти компоненты могут базироваться на таких стандартах, как CORBA, EJB или COM, или они могут представлять существующие монолитные системы, но не унаследованные системы. Я считаю, что унаследованных систем не существует - есть работающие системы. Контейнер поддерживает широкий диапазон сервисов, в том числе кроссплатформенные возможности, асинхронную обработку сообщений, защиту, обработку транзакций, управляемость, поддержку развертывания и расширяемость.
Что касается компонентов, важно подчеркнуть различие между компонентами уровня приложений и компонентами уровня систем. Первые объединяются вместе для создания прикладных систем и регулируются несколькими стандартами, такими как CORBA, EJB и COM, в то время как компоненты уровня системы скрыты от пользователя и являются частью архитектуры контейнера. Компонентный уровень более совершенен с точки зрения удобства использования и разработки.
Наконец, соединители предоставляют мосты между контейнером и компонентами и другими системами и средами, такими как пакетные приложения, созданные независимыми производителями. Эти три области обеспечивают контекст, в рамках которого необходимо рассматривать и оценивать различные элементы, входящие в состав промежуточного программного решения, которое, как можно надеяться, позволит разобраться в путанице различных терминов и подходов.
Объединение систем
Разработчики и организации понимают преимущества решений, позволяющих объединить возможности различный систем. Самое главное - тот факт, что промежуточное программное обеспечение предлагает эволюционный подход к совершенствованию информационных технологий. Оно позволяет сохранить инвестиции в существующие системы, навыки и инструментальные средства, а со временем и расширить эти ресурсы. Промежуточное программное обеспечение и стратегия компании Iona, которую можно выразить словами «пусть программы работают вместе», были вызваны пониманием необходимости объединить возможности различных систем, используемых в подразделении.
Вам нужно иметь возможность более широко использовать свои приложения в сети и изменить эти приложения и системы в соответствии с меняющимися требованиями рынка. При таком подходе к разработке систем эволюция смыкается с революцией. Он не только позволяет сохранить и расширить уже имеющиеся навыки и уровень применения технологий, но и предлагает компоненты. Широкое распространение CORBA, EJB и COM свидетельствует об успехе промежуточного программного обеспечения, а использование столь различных моделей для реализации тех же принципов проекта объясняет рост его популярности.
Помимо связи новых и имеющихся систем и приложений, организациям приходится решать задачу адаптации новых моделей. Это свидетельствует о значимости промежуточного программного обеспечения: оно предлагает поддержку технологии, которую вы используете сейчас, и открывает путь для новых разработок.
Хотя в стремлении упростить проектирование, разработку и развертывание промежуточных программных решений мы уже добились немалого, цель пока не достигнута. Я уверен, что в течение ближайшего года стоит ожидать появления серверных инструментальных средств, которые обеспечат то же удобство работы на уровне корпоративной серверной разработки, которую уже получили разработчики на стороне клиента благодаря таким инструментальным средствам, как Visual Basic и Visual Cafе. Появление таких инструментальных средств значительно упростит создание высокоуровневых прикладных сервисов, таких как транзакции, и будет способствовать более широкому применению промежуточного программного обеспечения на рынке. Это основной приоритет для Iona.
Другая цель - это расширение применения различных компонентных моделей в организациях. Производителям промежуточного программного обеспечения необходимо знать, каков спрос на встроенную поддержку этих модулей в любом промежуточном программном решении, и их сторонники особо подчеркивают, почему промежуточное программное обеспечение по-прежнему останется базовой технологией в будущем.
Крис Хорн - председатель совета директоров и директор компании Iona Technologies, которую он основал в 1991 году. Он стал первым разработчиком Orbix, возглавляет компанию с момента ее создания и благодаря ему IONA стала одной из ведущих фирм на рынке промежуточного программного обеспечения. Он руководит экспертной группой Expert Group on Future Skills, входящей в состав ирландского фонда Education Technology Investment Fund, который планирует инвестировать 350 млн. ирландских фунтов в сферу образования в Ирландии. До создания IONA Хорн изучал компьютерные науки в Тринити-колледж в Дублине, где принимал участие во многих панъевропейских проектах, связанных с исследованиями в области информационных технологий, в том числе и с распределенными вычислениями. Он также работал в Европейской комиссии в Брюсселе и активно участвовал в длившейся 10 лет программе Esprit, цель которой - способствовать развитию технологической отрасли Европы. С ним можно связаться по адресу chorn@iona.com.
Выборка полезных решений
Пол Бассетт
Netron
 |
От новшества к правилу
Новая парадигма может решить проблемы, которые в существующей парадигме вы считали неразрешимыми. Примером тому служит технология оболочки, которая примерно на 90 - 95% не более, чем возвращение к старому. Но на то, чтобы новая парадигма из новинки превратилась в традицию требуется жизнь одного поколения, а то и больше. Объектно-ориентированная технология существует более 30 лет! И в течение почти всего этого времени данная парадигма использовалась практически повсюду, оставаясь при этом невидимой. «Как случилось, что я никогда о вас не слышал?» Затем наступил этап невозможности. «Я слышал о вас, но не верил в то, что вы существуете». Затем эффект неверия, где бы вы не видели применение нового способа, вы интерпретировали его как реализацию старой методики. И, наконец, все начинают понимать, что же в действительности происходит.
Сейчас, как мне кажется, мы находимся на третьем этапе - эффект неверия - все его признаки налицо. Чтобы прийти к конечной цели, нужно заменить менталитет ремесленника на дух инженера. В компаниях, занимающихся программным обеспечением, идеи управления активами и гибкие производственные процессы во внимание не принимаются. С другой стороны, размер и сложность систем вышли далеко за рамки возможного при старой парадигме. Вкладывая значительные средства в повторно используемые ресурсы менеджеры рассчитывают на приемлемый возврат от этих инвестиций. Эта потребность изменит ход событий.
Классификация унаследованных текстов
Одной из революционных разработок могут стать инструментальные средства для автоматической классификации унаследованных программ. Классификатор находит аналогичные функции, где бы не располагались фрагменты ее кода, и определяет входные и выходные параметры, а также локальные переменные.
Поиск новых шаблонов «похожести» скорее всего окажется крайне сложной в вычислительном плане задачей - время вычислений растет экспоненциально при увеличении объема анализируемого текста. «Прорывное» решение будет связано с изобретением способа, позволяющего анализировать и по характерным признакам распознавать шаблоны в программе, написанной на языке Кобол, таким образом, чтобы шаблоны появлялись за линейное время. Наш инструментарий, получивший название HotRod, классифицирует сотни тысяч строк кода в час. А если вы хотите найти только бизнес-правила, сделать это можно еще быстрее. Поскольку иногда важные компоненты старого текста найти очень трудно, создание такого инструментария сделает перенос крупных унаследованных систем вполне реальным.
Попытка предсказать появление прорывных решений не столь уж дурацкое занятие. Уже изобретено больше, чем мы в состоянии с пользой применять. На самом деле, проблема в том, как отделить зерна от плевел.
А это и так непростая проблема усугубляется верой в серебряные пули (необходимые для победы в так называемых религиозных войнах) и волшебную палочку (иначе называемую «дутым» программным обеспечением). А кроме того, не обходиться и без нарочитого игнорирования и скептицизма, когда (рискуя утомить вас обилием метафор) некоторые действительно передовые детки выплескиваются из купели вместе с водой.
Недорогие системы, реализованные в срок и в строгом соответствии с бюджетом никогда не выдут из моды. Да-да, они никогда не станут банальными. Ах вам нужно подлинное новшество? В этом-то и вся загвоздка.
Пол Бассетт - один из основателей и первый вице-президент компании Netron, где он помогает фирмам, работающим в области информационных технологий перейти к гибкой парадигме создания программного обеспечения. За свое изобретение технологии кадров он получил премию Information Technology Innovation Award, учрежденную Canadian Information Processing Society. Его книгу «Повторное использование кадрового программного обеспечения: уроки реального мира» (Framing Software Reuse: Lessons From the Real World Prentice Hall, 1997) Эд Йордон назвал «лучшей книгой о повторном использовании, которую мне приходилось видеть за всю мою карьеру». Он также является соавтором создаваемого IEEE стандарта Standard P1517: Software Reuse Life Cycle Processes. С ним можно связаться по адресу pbassett@netron.com.
Интеграция: новый стиль программирования
Джон Аустераут
Scriptics
 |
Инфраструктура современного бизнеса состоит из бессчетного числа приложений, устройств, протоколов, источников данных и оболочек. Чтобы организация могла работать эффективно, все эти ресурсы необходимо координировать, а кроме того, должен существовать способ, позволяющий легко создавать новые приложения, способные на новом уровне использовать возможности существующих ресурсов. Более того, чтобы компания могла реализовать новые технологии, необходимо иметь возможность интегрировать их с существующими системами.
Появление языков описания сценариев
По мере роста важности интеграции приложений, растет и использование таких языков описания сценариев, как Tcl. Традиционные языки программирования, такие как Cи, C++ и Java, плохо подходя для решения задачи интеграции. Их ориентация на компиляцию и строгую поддержку типов, не позволяет им достаточно просто адаптировать огромное разнообразие и быструю эволюцию, что характерно для интеграции приложений.
С другой стороны, языки описания сценариев являются интерпретируемыми и не имеют строгой поддержки типов, что позволяет реализовать интеграцию приложений в 5 - 10 раз быстрее, чем с помощью системных языков программирования. В результате, в ближайшие годы для разработки большой части приложений будут использоваться языки описания сценариев.
Совершенствование
Хотя языки описания сценариев существуют уже несколько десятилетий, за последние несколько лет они стали значительно совершеннее. Изначально они использовались для менее критически важных приложений, таких как текстовая обработка и генерация отчетов, но современные языки описания сценариев, в частности, Tcl - достаточно развиты, чтобы поддерживать более крупные и более критически важные приложения.
Благодаря новым разработкам, которые появятся в ближайшие год - два, языки описания сценариев станут более приемлемы чем раньше для использования на уровне предприятия. К примеру, последняя версия Tcl поддерживает Unicode для локализованных приложений, и благодаря реализации защиты потоков, его можно использовать в высокопроизводительных серверных приложениях. Tcl также рассчитан на работу с XML, ActiveX, CORBA и другими ключевыми протоколами уровня предприятия. Хотя эти совершенствования носят эволюционный характер, совокупный эффект состоит в том, что язык описания сценариев может применяться для нового большого класса приложений.
Новые разработки, связанные с языками описания сценариев, по-прежнему будут эволюционными, а не революционными. Однако, есть разработка, которая, скорее всего, будет иметь особое значение. Речь идет об интеграции языков описания сценариев с XML.
XML может внести революционные изменения в процесс обмена информацией как внутри организации, так и между компаниями, но он обеспечивает лишь статичное представление данных. Сам по себе XML выполняет только описательную функцию. Однако, языки описания сценариев могут предоставить тот активный компонент, который даст XML новую жизнь. Языки описания сценариев могут легко извлекать данные из XML, преобразовывать XML в другие представления, обеспечивать интерфейс XML для существующих приложений и предпринимать действия на основе данных, содержащихся в документе XML.
Благодаря своей строчной природе языки описания сценариев прекрасно согласуются со слабо структурированной строчной природой XML. Сейчас уже выпускаются свободно распространяемые расширения Tcl, предназначенные для работ с документами XML, а коммерческие инструментальные средства в скором времени планирует представить компания Scriptics. Я уверен, что языки описания сценариев обеспечат самый лучший механизм для работы с XML, а объединение языков описания сценариев и XML значительно расширит диапазон их применения.
Джон К. Аустераут - директор компании Scriptics, которую он создал в 1998 году для распространения Tcl в качестве платформы для интеграции. Аустераут - автор языка описания сценариев Tcl и инструментального пакета разработки Tk, а кроме того, он потратил немало времени на пропаганду нового стиля программирования. К области его интересов относятся языки описания сценариев, программирование для Internet, пользовательские интерфейсы и операционные системы. До создания Scriptics Аустераут был профессором по компьютерным наукам университета Беркли (Калифорния) и ведущим инженером корпорации Sun Microsystems. Аустераут имеет звание Fellow of the ACM и является лауреатом многих престижных премий, в том числе ACM Software Systems Award, ACM Grace Murray Hopper Award и UC Berkeley Distinguished Teaching Award. С ним можно связаться по адресу ouster@scriptics.com.
Внутренний инжиниринг и повторное использование
Мартин Л. Грисс
Hewlett-Packard
 |
Так что компоненты и описание сценариев становятся стандартом, по которому будут оцениваться крупномасштабные корпоративные разработки. Все эти технологии вместе могут радикально изменить способ, которым пользуются люди для реализации возможности повторного использования, при том, что ни одна из технологий сама по себе не является революционной.
Общность, изменяемость и гибкость
Сейчас я считаю, что создание агентов, объединенных с языком описания потоков работ, станет следующим шагом к увеличению гибкости и возможности повторного использования. Как JavaBeans превратились в корпоративные JavaBeans, так и бизнес-компоненты будут включать в себя понятие агентов, обеспечивая специализированные интерфейсы и используя сервисы, которые увеличивают уровень их автономности и надежности. Более того, для поддержки согласованности действий бизнес-компонентов, четко отражающей бизнес-процессы, необходимо обеспечить их взаимодействие в соответствии с локальными и глобальными потоками работ. Таким образом, чтобы организовать это взаимодействие точно и гибко, языки описания потоков работ станут следующим поколением языков описания сценариев.
Кроме того, мы пришли к выводу, что невозможно повторно использовать произвольные компоненты в контексте, для которого они не предназначены. И нельзя создать вещь, которая сама по себе будет обладать возможностью повторного использования. Вы должны подумать о том, как компоненты в группе будут дополнять друг друга, как они будут взаимодействовать и как эти компоненты могут по отдельности изменяться.
Для внутреннего инжиниринга требуется общность и изменяемость. Это необходимо каким-либо образом выразить, а затем использовать при создании компонентов. Работа, которую Ивар Якобсон и я проделали в отношении возможности повторного использования, состояла в добавлении некоторых расширений к элементам UML, которые мы назвали точками изменений. Их можно рассматривать как обобщение точек расширения или «горячих точек», которые позволят вам заявить об изменчивости определенных моделей, не уточняя как именно они меняются.
Постепенные инвестиции
Сейчас существует большой поток технологических новшеств, таких как совершенствования в Java, инструментарии Web и генераторах. Кроме того, есть аспектно-ориентированное программирование, новые средства моделирования и создания шаблонов, ну и так далее. Успех широкомасштабного повторного использования обусловлен не только технологией; архитектура и стандарты - это процессы социальные. Решение о повторном использовании компонента, вместо инвестиций в создание его «с нуля», зависит от массы причин, в том числе связанных с культурой, образованием, управлением и профессиональной подготовкой.
Многие компании предпочитают оперативные решения, которые ограничивают инвестиции в архитектуру, разработку компонентов, внутренний инжиниринг и повторное использование. Чтобы изменить такой подход, должно быть известно об успехе иного решения, свидетельствующего о том, что иной подход действительно работает и дает отдачу. Есть примеры успешных решений, но я не думаю, что мы в достаточной мере информируем о них широкую публику. Крайне редко в журнале Computer можно увидеть обсуждение последних и самых значительных успехов.
Еще один момент - сокращение расходов. Приобретая компоненты, позволяющие реализовать искомое решение (на создание которого у вас просто нет времени), вы можете уже сами достаточно легко реализовать всю внешнюю архитектуру и внутренний инжиниринг. Многие считают, что это невозможно, что нужно или все делать самим, или ничего. Или вы решаете задачу с помощью внутреннего инжиниринга, или не делаете ни то, но другое. Это не так. Вы можете добиться постепенных преимуществ с помощью постепенных инвестиций.
Все больше компаний приходят к выводу, что они могут создавать компоненты, ориентированные сугубо на свою работу и при этом соответствующие тем или иным стандартом. Но пока все это довольно сложно. Я считаю, что мы можем следовать двухэтапной стратегии. То есть, наша технология позволяет написать некоторые достаточно совершенные компоненты и использовать их вместе с менее совершенными. Я работаю над документом, посвященным переходу от компонентов и сценариев к агентам и потокам работ, другими словами, более компетентным компонентом, более богатой оболочке и более стилизованному языку описания сценариев.
Мартин Л. Грисс - ведущий научный специалист по разработке ПО исследовательского центра Hewlett-Packard Laboratories. Сейчас он занимается исследованиями управления приложений на базе агентов, определяемых моделями; вопросами повторного использования объектно-ориентированных систем; инструментарием разработчика, ориентированным на предметную область. До этого Грисс был доцентом компьютерных наук университета штата Юта, где сейчас он занимает должность адъюнкт-профессора. Вместе с Иваром Якобсоном и Патриком Джонссоном, он написал книгу «Повторное использование программного обеспечения» (Software Reuse, Addison Wesley Longman, 1997. Он является автором более 45 публикаций, справочника HP о повторном использовании и многих технических отчетов. Грисс - член Sigsoft Executive Committee и принимает участие в Software Engineering Education Project, совместном проекте IEEE и ACM. С ним можно связаться по адресу griss@hpl.hp.com.
Мысленное объединение
Ричард Марк Соли
Object Management Group
 |
Опыт программной разработки
Тем не менее, я уверен, что существует тенденция, способная оказать существенное влияние на развитие отрасли программного обеспечения. Эта тенденция - эволюционное слияние некоторых направлений мышления - как раз не объектной технологии, а концепции компонентов, инструментальных средств для поддержки повсеместного моделирования и возвратное (round-trip) проектирование и реализация. Все эти идеи составляют опыт программной разработки, который и станет самой лучшей поддержкой повторного использования и интеграции, что, в конечном итоге, одно и то же.
С точки зрения специалистов Object Management Group именно это и происходило в течение 10 лет, от инфраструктуры промежуточного программного обеспечения (CORBA) и языка моделирования (UML) к стандартам, ориентированным на вертикальные рынки, начиная от здравоохранения и телекоммуникаций и заканчивая живой наукой, производством и транспортом.
Хорошо структурированный механизм связи
Назвать возникающий рынок компонентного программного обеспечения я мог бы только эволюционным. Фактически, OMG была создана для того, чтобы предложить не стандартизованное объектное программное обеспечение, а стандартизованные программные интерфейсы, которые способны на новом уровне использовать распределенную объектную технологию. Это эволюционное изменение: объектная технология становится абсолютно господствующей тенденцией; распределенная объектная технология для интеграции гетерогенных систем превращается в повседневную, то есть, наконец системные интеграторы могут подумать о создании системы из унаследованных компонентов за конечное время.
Это привело, к примеру, к появлению нового класса системных интеграторов, которых обычно называют «интеграторами корпоративных приложений» и которые используют слияние распределенных объектов и программного моделирования для создания приложений из унаследованных компонентов за вполне разумное время.
То, что всего несколько лет назад считалось экзотическим промежуточным программным обеспечением сейчас стало применяться действительно в критически важных системах - ведение историй болезни в госпиталях, управление траекториями спутников, кабельные телевизионные приставки, национальные системы управления полетами, управление розничными продажами на мировом рынке, распространение оперативных новостей по всеми миру и управление международной иммиграцией. Все эти реализации, к примеру, отличаются развернутыми, зрелыми решениями CORBA. И это говорит о том, что эволюционная концепция хорошо структурированного «механизма объединения» существующих приложений стала весьма популярной.
Я действительно считаю, что в ближайшее время ждать появления каких-то кардинально новых достижений в области промежуточного программного обеспечения действительно не стоит. Я думаю, что в основном нужно рассчитывать на интеграцию концепций. Например, мобильность Java будет объединена с интероперабельностью CORBA и возможностями моделирования UML, что позволит создавать системы в первую очередь за счет интеграции, а не разработки с нуля.
Наличие стандартов в этих областях, в том числе стандартов на интеграцию хранилищ и использование эволюционных идей, таких как XML, означает, что мы можем сосредоточиться на реализации необходимых функций, а не на генерации новой инфраструктуры. В то же время, появление всяких yacc-ов и lex-ов позволяет разработчикам компиляторов игнорировать компоненту синтаксического разбора и сосредоточиться на архитектуре языка и генерации кода. Появятся стандартизованные компоненты и объединяющиеся процессы, которые в конечном итоге позволят нам концентрироваться на так называемой бизнес-логике - функциональности систем, которые мы создаем.
Ричард Марк Соли - председатель совета директоров и исполнительный директор компании OMG, где он выполняет широкий круг обязанностей, начиная от руководства советом директоров компании и заканчивая очень трудоемкими процессами согласования технических деталей стандартов, таких как CORBA, UML и MOF. В OMG он руководит всеми техническими процессами, в том числе работой всех подкомитетов и рабочих групп. До прихода в OMG Соли был одним из основателей, председателем совета директоров и генеральным директором компании AI Architects, выпускавшей 386 HummingBoard и другое программное и аппаратное обеспечение для ПК и рабочих станций. До этого он давал консультации различным технологическим компаниям и совместным предприятиям по вопросам, касающимся инвестиций в программное обеспечение. С ним можно связаться по адресу soley@omg.org.
Главное - мобильность
Джим Валдо
Sun Microsystems
 |
Революционный аспект переносимости в том, что он разрушает жесткую связь двоичного кода программы и конкретного процессора. Это же, в свою очередь, означает, что код можно переносить с машины на машину, связанные сетью, не думая о том, какой на них установлен процессор и какая операционная система. Это меняет все правила распределенных вычислений. Это тот фактор, который позволил нам создать систему Jini, но это всего лишь начало того, что мы можем сделать с переносимым кодом.
Хватит сложностей
В определенном смысле происходят и революционные изменения. Это революция, которая позволяет отказаться от сложности в угоду простоте. Одним из признаков этой революции является переход от C++ к Java. Когда я говорю с людьми о Jini, мне приходится долго рассказывать, как много времени мы потратили на то, чтобы максимально упростить систему. Люди начинают понимать, что простота - это залог надежности. Огромные залежи программного обеспечения можно заменить на небольшие и простые программные компоненты, которые делают только то, что нам необходимо и их можно объединять друг с другом. Это переход от дворцов стиля барокко к блочным домам и я считаю, что нам всем следует поддержать такое решение.
Частью этой революции является тенденция к использованию систем на базе языка. Стало привычным, что язык, который мы применяем при разработке системы или компонента, выбирается в общем-то случайно, и все, что пишется - пишется с учетом того, что оно должно взаимодействовать с компонентами, написанными на других языках. Это приводит к увеличению сложности и часто снижает эффективность связей между системами до обработки наименьшего общего кратного типов данных. Но теперь появляются системы, которые требуют использования конкретного языка. В силу этого мы имеем возможность для описания взаимодействий применять обширный диапазон типов языка. Благодаря этому система в целом становится намного проще, в то же время увеличивает свои выразительные возможности.
Объединение технологий
Способность распространять код по сети была действительно революционным шагом, который и позволил создать Jini. Но были и другие преимущества, как эволюционные, так и революционные, которые помогли сделать его реальностью. Революционным шагом стало понятие защищенного языка и защищенной среды исполнения. Перемещение кода - еще не все; вам нужна уверенность в том, что код, который вы передали, при исполнении не вызовет проблем. Для этого необходимо, чтобы язык не позволил программистам делать то, что может вызвать катастрофу. Катастрофа может быть планируемой или случайной. Вирус - это как раз программная ошибка, которая была запланирована. Создание защищенного языка дало возможность увеличить надежность программ, но, в конечном итоге, это позволило использовать переносимость кода, которое нам требовалось для Jini.
Эволюционный шаг состоял в объединении языков со строгой поддержкой типов и динамических языков. Раньше такие языки обычно не объединялись. Никакой конкретной причины тому не было, но динамические языки обычно не поддерживали строгое соответствие типов, а языки со строгой поддержкой типов предполагали статические связи. Шаг к конвергенции их обоих обеспечил тот вид защиты, который нам был необходим для гибкой среды времени исполнения, столь привычной для динамических языков. Для распределенных систем, которым необходима стабильность, но которые к тому же постоянно меняются - комбинация была естественной.
Следующие два года могут оказаться весьма интересными. Люди как раз начинают понимать, что им нет необходимости связывать код, который работает на процессоре конкретно с этим процессором, то есть компьютер теперь может получать код помимо локального диска еще и из сети. Таким образом значительно увеличивает диапазон возможностей того, что мы называем компьютером. Это касается не только настольных систем или серверов, но и PDA, сотовых телефонов, наших машин и в очень скором времени многих устройств и домашних электронным систем.
Большинству из нас раньше никогда не приходилось программировать подобные устройства, и мы, конечно же, особо и не думали о том, что делать с сетью таких устройств. Будут придуманы новые способы обмена информацией и функциями и опробованы новые способы взаимодействия. Мир вдруг оказывается намного богаче, чем мы привыкли думать, и привычные для нас методики становятся неадекватными. Я думаю все это будет очень интересно.
Джим Валдо - ведущий инженер компании Sun Microsystems, главный архитектор Jini - распределенной системы программирования на основе Java. До этого Валдо работал в JavaSoft и Sun Microsystems Laboratories, где вел исследования в области объектно-ориентированного программирования и систем, распределенных вычислений и пользовательской среды. До прихода в Sun он восемь лет проработал в компаниях Apollo Computer и Hewlett-Packard, занимаясь распределенными объектными системами, пользовательским интерфейсом, библиотеками классов, текстами и локализацией продуктов. В HP Валдо руководил проектированием и разработкой первого брокера объектных запросов и очень много сделал для того, чтобы данная технология была включена в первую спецификацию OMG CORBA. Он преподает в Гарвардском университете. С ним можно связаться по адресу waldo@sun.com.
Задуманное будущее
Чарлз Симоньи
Microsoft Research
 |
IP позволяет воплотить эту мечту в жизнь за счет создания программ из экземпляров понятий, точно также как системы автоматизированного проектирования создают план сложных механизмов из объектов. Методы понятий IP не запускаются во время исполнения, что было бы всего лишь объектно-ориентированным программированием, а вместо этого вызываются системой IP в момент программирования, всякий раз, когда IP использует экземпляр понятия. Функциональность понятий выражается за счет преобразования метода понятия, который переводит экземпляр понятия в традиционные для компьютерной науки примитивы. За счет действия дополнительных методов, понятие может адаптировать другие аспекты разработки программ, от управления исходными текстами до редактирования, проверки исходных текстов, просмотра, тестирования и отладки.
Программирование за счет переопределения
Эффект использования программирования такого типа будет как эволюционным, так и революционным. Эволюционным, поскольку могут быть сохранены инвестиции в унаследованное программное обеспечение. Начальный набор понятий может выражать абстракции унаследованных языков, их модули синтаксической интеграции (unparser) в состоянии хорошо моделировать традиционные понятия и их преобразования могут найти отражение в уровне производительности и совместимости, которые идентичны унаследованной реализации. В этом отличие от предыдущих революций в программном инжиниринге, при котором программисты обычно стремятся дистанцироваться от унаследованного кода и пойти на новые компромиссы.
Революционные аспекты IP также беспрецедентны. Вполне вероятно, что IP спровоцирует новую волну усовершенствований со стороны независимых разработчиков, которые, впервые будут иметь возможность добавить новую абстракцию, новое понятие или новое преобразование в области инжиниринга программного обеспечения. Новые понятия или новые методы для существующих понятий могут создаваться, оцениваться, распространяться, использоваться и совершенствоваться как независимые сущности.
В прошлом модернизация часто осуществлялась за счет разделения и создания промежуточного решения для связи системных компонентов. С появлением операционных систем для персональных компьютеров, начался цикл независимых инноваций. Независимые разработки позволили значительно улучшить системы по сравнению с их начальным состоянием. Чтобы понять, что необходимым условием совершенствования было разделение интересов достаточно задаться простым вопросом: «Могла бы какая-либо организация, специализирующаяся на вопросах текстовой обработки, добиться того, чего добилась вся отрасль ПК в целом?»
Новейшие понятия
IP создает аналогичное разделение и выполняет роль посредника. С точки зрения программиста - пользователя, решение о том, нужно ли использовать новейшее понятие, достаточно отметить, что в таком случае обеспечивается защита инвестиций в унаследованные системы. Пользователи смогут экспериментировать с радикально новыми понятиями и представлениями своих программ (без каких-либо изменений кода) - используя только вновь приобретенные модули синтаксической интеграции. Существенного увеличения производительности программы, о котором заявляют сторонники трансформирующего программирования, сможет добиться любой программист.
Самое важное, что новые абстракции могли бы применяться без пересмотра или переписывания унаследованного кода. Кроме того, если необходимо усовершенствовать существующий код, IP и здесь мог бы оказаться полезным. Алгоритмы трансформации могут выступать в качестве инструментария редактирования: унаследованные шаблоны можно найти механически и заменить их на новые абстракции. Фрагменты кода можно будет механически перенести в новые процедуры. Реализация новых абстракций может быть выбрана так, чтобы сохранить совместимость с существующими структурами и совершенствование исходных текстов может проводиться постепенно.
С точки зрения рационализаторов от программирования, у IP есть два важнейших достоинства. Во-первых, потенциал массового рынка, описанный выше, а во-вторых, беспрецедентный простор для новшеств. Частично такая свобода обусловлена тем, что методы понятий могут исполнять произвольный код. А частично - изобилием интерфейсов методов к IP. Диапазон понятий, которые можно генерировать, необычайно широк.
Мы можем только предполагать, к чему в итоге может привести создание новых решений в области программного инжиниринга. В ближайшее время возможно появятся знакомые абстракции и понятия, чья новизна будет проявляться в том, что ими смогут пользоваться все. Пре- и постусловия, счетчик или процедурная специализация будут доступны каждому, вне зависимости от того, какими унаследованными языками они пользуются. Затем акцент будет перенесен на абстракции, специфические для каждой предметной области, которые значительно упростят представление задач, возникающих в соответствующих областях.
Поскольку большинство проблем выходит за рамки одной предметной области, способность IP смешивать абстракции станет крайне важной для эффективного использования особо значимых абстракций, которые объединяют в себе значительную часть знаний конкретной сферы и, тем самым, ее специфики. IP также поможет открыть новые направления развития, в том числе и в самой области программного инжиниринга.
IP отдача от любой из этих предметных областей сама по себе окажется недостаточной для того, чтобы оправдать разработку и использование конкретного, ориентированного на узкую предметную области языка.
Чарлз Симоньи - ведущий исследователь Microsoft Research, отвечающий за разработку новых подходов в технологии программирования. Симоньи работает в Microsoft с 1981 года и начинал свою деятельность с создания микрокомпьютерных прикладных программ, а затем создал группу, которая разрабатывала Excel, Word и другие продукты. До прихода в Microsoft Симоньи работал в Xerox PARC, где создавал Bravo - первый редактор WYSIWYG. В 1997 году он был избран членом Национальной академии инжиниринга за «вклад в разработку широко известного настольного офисного программного обеспечения». Симоньи является почетным профессором популяризации науки Оксфордского университета, теоретической физики Института специальных исследований в Принстоне и образовательной технологии в Стэнфорде. С ним можно связаться по адресу charless@microsoft.com.
| Software [R]evolution: A Rountable, Larry Wall, David A. Taylor, Chris Horn, Paul Bassett, John K. Ousterhout, Martin L. Griss, Richard Mark Soley, Jim Waldo, and Charles Simonyi. IEEE Internet Computer, May 1999, pp. 48-57, Reprinted with permission, Copyright IEEE CS, 1999, All rights reserved. |
