Компонентное программное обеспечение, ч. 1, 2

оглавление

© 1997, Cuno Pfister (Oberon Microsystems, Inc.)
© 2005, русский перевод: Ермаков И.Е.
Для публикации текста требуется письменное разрешение автора и переводчика.

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

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

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

Однако, заказное ПО имеет также серьезные недостатки. Это — обычно более высокая стоимость, чем для стандартного «коробочного» ПО и его разработка может потребовать длительного времени. Время, прошедшее от начала разработки до внедрения, является особенно критичным, поскольку к тому времени, как ПО будет готово, он может оказаться уже устаревшим, поскольку развитие бизнеса внесло новые коррективы.

В прошлом десятилетии сложность программных сред значительно возросла. Интерактивные ПК с разнообразными мультимедийными возможностями, сети — в диапазоне от локальных до всемирной, и возросшие требования к графическому интерфейсу привели ко взрывному росту сложности как операционных систем, так и прикладных приложений. Чтобы сохранять конкурентоспособность, каждая новая версия приложения должна поддерживать хотя бы некоторые из новых возможностей операционной системы и оборудования. Такая направленность ведет к обилию возможностей, объемному («жирному») ПО, затянутым циклам разработки, и, наконец, что не менее важно, — к большему количеству дефектов в производимых продуктах. Поспевать за новыми проблемами становится все труднее. Поэтому неудивительно, что рисков собственной разработки стремятся избежать всюду, где это возможно. Вместо нее люди приобретают стандартное ПО.

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

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

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

Рис. 1-1. Спектр требуемых возможностей

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

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

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

Текстовые процессоры являются ярким примером серийного программного обеспечения. Каждое новое поколение текстовых процессоров предоставляет новые возможности, только чтобы идти в ногу с конкурентами. Часто эти возможности мало нужны большинству покупателей, которые, тем не менее, должны за них платить. Поскольку серийное программное обеспечение продается большими партиями, стоимость его может становиться очень низкой. Но здесь есть скрытые затраты, например, затраты на подготовку сотрудников, или на обновление оборудования на более мощное. Последнее происходит особенно часто, поскольку новые версии ПО обычно более громоздки и медленны, чем их предшественники. Операционные системы — наглядный пример этим тенденциям: когда ваша компания перешла с Windows 98 на Windows XP, сколько денег было потрачено на обновления и замены в аппаратной части?

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

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

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

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

Фундаментальное требование к компонентному ПО состоит в том, чтобы компоненты могли разрабатываться и продаваться независимо друг от друга, и, таким образом, могли комбинироваться потребителем. Понятие «продажа» имеет особое значение, так как очевидно, что вы не сможете покупать программные компоненты, если нет рынка таких компонентов. Мы позднее поговорим о различных технических аспектах компонентов и об индустриальных стандартах, но те могут быть только конечными средствами. В конечном счете, единственная вещь, которая имеет значение для покупателя — это наличие компонентного рынка. Определения программных компонентов должны отражать этот факт. В частности, мы не утверждаем, что модульное или объектно-ориентированное ПО автоматически окажется компонентным. Эти аспекты внутреннего устройства невидимы, а потому безразличны покупателю.

Следующее определение, которое базируется на результатах 1996 Workshop on Component-Oriented Programming in Linz [WCOP96], послужит основой для обсуждения компонентного ПО в последующих главах.

Компонент — это элемент конструкции с определенным, зафиксированным в спецификации, интерфейсом и явными зависимостями от контекста. Компоненты могут распространяться независимо друг от друга и компоноваться третьей стороной.

Рыночное значение здесь имеют фразы: «независимо распространяться» и «компоноваться третьей стороной». Остальные условия имеют скорее техническую природу. Более детально об интерфейсах мы поговорим в главе 3.2, и об определении — в главе 4.1. Поскольку все зависимости между компонентом и его контекстом задаются в его интерфейсе (см. Рис. 2-1), компонент может быть заменен на любой другой с тем же интерфейсом. Например, компонент может быть заменен своей новой версией, и это не повлияет на другое ПО. Если интерфейсы есть в открытом доступе, независимые производители могут начать предоставлять совместимые компоненты. Интерфейс таким образом становится стандартом, который создает рынок, с конкурирующими производителями и с выбором для потребителей.

Рис. 2-1. Программный компонент — это черный ящик, все взаимодействия с которым происходят через опубликованный интерфейс

Следуя данному выше определению компонентов, компонентное программное обеспечение является конструкцией из компонентов, часть из которых могут быть серийными компонентами, а другие — изготовленными на заказ (см. Рис. 2-2).

Рис. 2-2. Компонентное ПО как сборка из стандартных и заказных компонентов

Это значит, что компонентное ПО снимает остроту выбора между изготовлением собственного ПО и покупкой серийного продукта. В настоящий момент продолжается переходный период, когда старые монолитные приложения дополняются API — программными интерфейсами — некоторые из них достаточно общие (например, используют Microsoft COM и OLE), некоторые более специализированные (например, Netscape Plug-Ins). Microsoft Office — это пример коллекции тяжеловесных компонентов, которые произошли из монолитных приложений, со всеми сопутствующими последствиями.

Существуют и более легковесные компоненты (например, элементы управления ActiveX, объекты Cyberdog или JavaBeans). Все преимущества компонентного ПО будут раскрыты, только если станет доступным множество компонентов, которые сильно «сфокусированы» (и потому относительно малы). Об этом рассказывает данная книга.

Разделение программ на отдельные компоненты следует старому принципу «разделяй и властвуй». При разбиении сложной проблемы на более простые, которые могут быть решены независимо друг от друга, проблема становится более управляемой. Это инженерный аспект компонентного ПО важен для всех типов приложений, которые состоят из более чем двух сотен строк кода. Конечно, чем больше и сложнее проект, тем более необходимой становится модульность компонентного ПО. Для больших задач модульность становится необходимой также потому, что она делает возможной командную разработку, когда различные члены команды реализуют различные компоненты в одно и то же время.

Компоненты могут разрабатываться параллельно, если заранее ясно определено, что каждый компонент должен предоставлять, так что программист может немедленно использовать интерфейс компонента, который разрабатывается другим сотрудником — даже если его реализация еще не существует. Для того, чтобы так работать, необходимо, чтобы интерфейс компонента был четко определен и полностью отделен от его реализации, которую затем можно считать черным ящиком. Другими словами: нас не заботит, как интерфейс выглядит изнутри, на каком языке программирования он реализован (С++? Компонентный Паскаль? Ассемблер?) или в каком стиле он исполнен (процедурном? функциональном? объектно-ориентированном? «спагетти»?) — до тех пор, пока это является правильной реализацией данного интерфейса.

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

Компонентная реализация может быть заменена новой версией, если ее интерфейс остается прежним. Это делает возможным, например, отсылать клиенту частичные обновления, а не новый выпуск целого приложения (или операционной системы). Следовательно, клиенту можно послать только исправленный или улучшенный компонент.

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

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

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

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

Чтобы использовать компонент, программист должен иметь описание его интерфейса. Если интерфейс точен и полон, любой компетентный программист может разработать альтернативу для существующих реализаций. Допустим, мы имеем текстовый редактор Write и средство проверки орфографии Spell. Контроллер орфографии позволяет вам проверять тексты, набранные во Write, то есть, он использует его программный интерфейс. Но вот на рынке появляется лучший текстовый процессор WritePro, и вам бы хотелось перейти с Write на WritePro, но не менять при этом контроллер орфографии. Это возможно, если WritePro реализует тот же интерфейс, что Write (или строго расширяет его), и если Spell получает доступ к тексту только через этот интерфейс. В этом примере мы заменяем один элемент на другой, который реализует тот же интерфейс.

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

Что является одной из самых важных особенностей компонентного ПО: оно заменяет решения «или/или» на более мягкие, и таким образом, менее критичные решения. Вопрос уже состоит не в том, заменять или нет существующее ПО целиком, а в том, какие компоненты заменять. Вопрос уже не в том «сделать» или «купить»; вопрос в том, какие компоненты купить и какие компоненты разработать. Компонентное ПО вводит плавный выбор туда, где ранее господствовали жесткие абсолютные решения. Рис. 2-1 иллюстрирует промежуток спектра от «создать» до «купить», этот промежуток покрывается компонентным ПО:

Рис. 2-3. Спектр от полной разработки и полной покупки

Никакая компания никогда не сможет разработать распространенные продукты в любой возможной категории ПО и интегрировать их в единый пакет. Компонентное ПО позволяет покупателю выбрать лучшие продукты среди всех поставщиков в мире, и интегрировать их в стиле «plug-and-play». Чем большие размеры и различия приобретают рынки компонентов, тем больше рычагов имеет покупатель для построения уникальной, мощной и подходящей именно для него среды.

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

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

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

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

Мы увидели, что компонентное ПО интересно и малым, и большим производителям, и интеграторам, и покупателям. Все только выигрывают. Но есть ли области, в которых компонентное ПО просто не работает? Если мы посмотрим на спектр требуемых возможностей (см. Рис. 1-1), то станет ясно, что наиболее подходящими кандидатами в компонентное ПО будут продукты в середине шкалы, то есть, элементы, которые требуются многим, но не всем, потребителям. Именно здесь рынок компонентов имеет наибольшее значение. Если бы у всех были полностью уникальные требования, то не было бы рынка для многократно используемых компонентов. С другой стороны, если бы у всех были совершенно одинаковые потребности, то на рынке осталось бы только несколько производителей. Однако, даже эти левые и правые края спектра выигрывают от компонентного ПО, из-за тех инженерных преимуществ, которое оно дает, в частности, за счет больших возможностей для развития. Однако такое применение довольно дорого, чтобы помочь обогнать признанных лидеров на рынке в этих областях.

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

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

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

Какие возлагались надежды на то, что компьютеры сделают возможным безбумажное делопроизводство! Произошло обратное: производство бумаг — это одно из наиболее эффективных применений компьютеров. Как много приложений, которые помогают создавать документы для распечатки: текстовые процессоры, графические редакторы, электронные таблицы, построители графиков и т.д. Пользователь желал бы комбинировать все эти способы представления в одном документе. Например, если ваш любимый редактор математических формул не является частью вашего любимого текстового редактора, вам будет сильно хотеться использовать редактор для создания формул и затем поместить их в текст, набранный в вашем текстовом процессоре. Это типичный случай, когда вам хотелось бы использовать лучшие продукты различных поставщиков в манере «plug-and-play», а не надеяться на то, что одна-единственная компания окажется лучшей во всех сферах подготовки документов.

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

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

Рис. 2-4. Пример составного документа

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

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

Рис. 2-5. Табличный объект этого OLE-объекта в настоящий момент имеет фокус

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

Составные документы являются намного более общим понятием, чем то можно выразить термином «документ». Отображения в документе могут быть активными, то есть, они могут показывать видеоролики или телевизионные каналы. Они могут быть интерактивными, то есть, реагировать на ввод пользователя. Например, при щелчке пользователя на кнопке может произойти некоторое действие. Такие интерактивные элементы пользовательского интерфейса носят общее название «элементы управления» (controls).

Что элементы управления должны делать в документе? Документ, который содержит в основном элементы управления, превращается в диалоговое окно или маску для ввода данных. Эти вещи обычно не считаются документами; но трактовка их как документов дает много преимуществ. Например, отпадает необходимость в отдельном редакторе для диалоговых окон, нужен только подходящий контейнер для формы. Более того, диалоговые формы хранятся как документы. Это весьма полезно, например, при переводе на другой язык, — для этого больше не требуется перекомпиляции. Другими словами: программный код большей частью отделен от деталей пользовательского интерфейса, например, от положения кнопок, текстовых надписей и т.п. Рис. 2-6 показывает разметку формы ввода данных, а рядом — та же форма в режиме, в котором она будет использоваться:

Рис. 2-6. Форма ввода данных в режиме разметки (сзади) и в режиме маски (впереди)

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

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

Рис. 2-7. Составной пользовательский интерфейс логического симулятора, который использует текстовый контейнер и специальные элементы управления для показа формы сигнала

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

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

Составление документов, меню, диалоговых окон, и написание соответствующих сценариев (или более сложных командных пакетов, см. ниже) — это то, что делается при сборке компонентов. Говоря техническим языком, сценарии и командные пакеты также могут быть компонентами (как в случае с BlackBox Component Builder), но поскольку такие компоненты не реализуют объекты (то есть, обычно не содержат классов), мы называем это «сборкой компонентов».

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

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

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

описание типов компонентов (примеры)

визуальные

элемент управления (control) — реализует связанный с контекстом интерактивный объект (командную кнопку, флажок, переключатель, текстовое поле)

редактор (editor) — реализует контекстно-независимые интерактивные объекты (текстовый редактор, электронная таблица, головоломка)

контейнер (container) — реализует интерактивные объекты, формирующие контекст, обычно специальные редакторы (HTML-браузер, визуальный конструктор)

средство просмотра (viewer) — редактор с отключенными возможностями, то есть, с содержимым только для чтения (графический браузер, система помощи, Adobe Acrobat)

обертка (wrapper) — специальный контейнер, который расширяет или изменяет поведение обернутого объекта (блок прокрутки, фоновая подкладка, слой)

невизуальные

командный пакет (command package) — коллекция интерактивных команд, которые обычно работают с визуальными объектами (контроллер орфографии, инструмент компиляции, команды/стражи/уведомления для графического интерфейса)

сценарий (script) — простой командный пакет, часто для автоматизации работы, написанный пользователем (получить e-mail → разобрать заголовок → сохранить в нужной папке)

библиотека (library) — коллекция достаточно независимых функций или классов (математическая, для работы со строками, классы коллекций)

служба (service) — предоставляет каркас, который может расширяться через plug-ins'ы (потоковый ввод/вывод, хранение документов, доступ к СУБД)

plug-in — реализует объекты, которые используются некоторой службой (драйвер SCSI, компилятор из промежуточного кода, файловый конвертер, драйвер к СУБД)

деловой (business) — реализует специфичную для отрасли программную логику (таблицы учета/клиентов/баланса, система контроля процессов)

Таблица 2-8. Классификация компонентов

Чтобы стал возможным любой тип рынка компонентов, сначала должна быть создана стандартизированная программная инфраструктура (так называемое промежуточное ПО, «middleware»). Никто не захочет устанавливать ПО, которое сразу же не будет полезным, таким образом, промежуточное ПО должно немедленно предоставить некоторые преимущества, которые оправдают инвестиции клиента. Для требуемого промежуточного ПО нужен катализатор рынка.

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

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

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

Эта проблема может быть решена с помощью интернета. Интернет — дешевое пространство для распространения всех видов цифровой продукции, так почему его нельзя использовать в случае программных компонентов? Фактически, в интернете уже есть первые примеры «киосков программного обеспечения», в которых вы можете купить компоненты и тут же получить их в электронном виде. В случае успеха электронная торговля позволит даже малому производителю продавать компоненты экономически выгодным способом, без включения каких-либо промежуточных агентов. Кроме того, такое распределение всемирно. В то время, когда писались эти строки, в Сети было несколько киосков ПО, например:

http://java.wiwi.uni-frankfurt.de
http://www.buydirect.com
http://www.broadcast.com
http://www.componentsource.co.uk
http://www.cybout.com/cyberian.html
http://www.devdepot.com
http://www.partbank.com
http://www.pparadise.com
http://www.software.net
http://www.stream.com
http://www.unboxed.com

Таблица 2-9. Список киосков ПО

Хотя модемы все время становятся быстрее, никто не захочет передавать мегабайты данных через интернет, если этого можно избежать. Таким образом, «жирное» ПО (fatware) плохо подходит для интернета; компоненты должны быть как можно меньше. Огромные приложения останутся в прошлом, несмотря на то, что объемы дисковой и оперативной памяти так сильно возросли. Инструменты разработки, в которых минимальный размер создаваемых «компонентов» превышает 2Мб, когда 2Кб были бы излишними, становятся действительно невыносимыми. Интернет является хорошим доводом в пользу компонентного ПО, а более всего — в пользу маленьких компонентов.

Первые Веб-страницы были статическими, но Java-апплеты изменили состояние дел. Апплеты — это компоненты, которые могут пересылаться через Интернет к веб-браузеру и выполняться там. Таким образом, Сеть становится более активной и одновременно это еще один шаг к компонентному ПО. Компонентное ПО выигрывает в Интернете как пространстве для своего распространения, а Интернет выигрывает от компонентного ПО, становясь насыщенней и интерактивней.

Мы упомянули составные документы как самый главный катализатор для технологий компонентного ПО. Они являются таковыми из-за большого числа персональных компьютеров, которые сегодня используются, которые дают беспрецедентную экономию в масштабах. Но корпоративные сети в больших компаниях становятся вторым катализатором, который дает необходимые инвестиции в промежуточное ПО, которое может оказаться пригодным для компонетного ПО. На больших предприятиях главное приложение, построенное на такой технологии, добавляет программные интерфейсы к старым унаследованным приложениям, так что они могут поключаться к огромным корпоративным сетям более просто и систематически, чем это было возможно ранее. К сожалению, это может привести к заблуждению, что компонентное ПО и коммуникации между объектами, которые находятся на других машинах («распределенные объекты») — это одно и то же [OHE96].

Но многие системы распределенных объектов должны быть развернуты как единое целое, поскольку они очень тесно связаны — даже если связи выстраиваются через сеть. Их части не являются независимо развертываемыми компонентами, и, следовательно, такие системы не являются компонентным ПО. С другой стороны, Microsoft OLE — это пример истинно компонентного ПО, которое не предполагает распределенных взаимодействий в сети¹⁾.

Распределенные объекты — это несколько иное, но становящееся необходимым, приложение компонентной технологии. Но большинство компонентов, в частности, легковесные компоненты, взаимодействуют только локально. Сегодня распределённые объекты часто позиционируются как будущее компьютерных технологий. По нашему мнению, такое видение распределенных объектов сильно преувеличено. Распределенные объекты скрывают самые важные характеристики распределенных систем, в частности — огромные отличия в скорости (задержки, вызваные передачами по сети в обоих направлениях) и возможность ошибок (каждый вызов метода может прерваться из-за проблем сети). В результате, полная прозрачность локальности/распределенности — возможно, самый привлекательный аспект распределенных объектов — не могут воплотиться на практике. Замена сложного кода сетевого взаимодействия, обычно базирующегося на широко распространенном «сокетном» API, является сегодня главным преимуществом использования распределенных объектов.Менее скромные, такие как полная прозрачность расположения, или неограниченная масштабируемость за счет децентрализации ресурсов, пока не подтверждены на практике.

Ясно, однако, что большим предприятиям будет полезна любая технология, которая упрощает и систематизирует процесс интеграции приложений, и что они располагают средствами для создания привлекательного рынка. Фактически, наиболее интересными компонентными рынками, возможно, будут бизнес-компоненты на стороне сервера, нежели на стороне клиента (ПК), где ограничения ниже, а требования более общие. Этого следует ожидать независимо от того, будут ли такие бизнес-компоненты связаны с распределенными объектами или с другими промежуточными технологиями. Например, промежуточная технология, базирующаяся на сообщениях, может вновь стать более популярной, поскольку модель сообщений адекватней и проще для использования (например, упрощает обработку ошибок), и более гибкая (например, за счет групповых связей вместо связи «точка-точка»).

Интернет, с его «всемирной информационной сетью», сочетает аспекты как составных документов, так и сетевых архитектур. Таким образом, это комбинированный катализатор рынка, который постепенно становится главной движущей силой для компонентного ПО.

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