Понятие открытой системы, ее свойства. Понятие открытых систем Промышленные сети и протоколы

СТАНДАРТИЗАЦИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

ОСНОВЫ ПОСТРОЕНИЯ СИСТЕМЫ СТАНДАРТОВ ИТ

Понятие открытых систем

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

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

Единое информационное пространство складывается из следующих основных составляющих:

Информационные ресурсы, содержащие данные, сведения, информацию и знания, собранные, структурированные по некоторым пра­вилам, подготовленные для доставки заинтересованному пользовате­лю, защищенные и архивированные на соответствующих носителях;

Организационные структуры, обеспечивающие функционирова­ние и развитие единого информационного пространства: поиск, сбор, обработку, хранение, защиту и передачу информации;

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

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

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

История концепции открытых систем начинается с того момента, когда возникла проблема переносимости (мобильности) программ и данных между компьютерами с различной архитектурой. Одним из первых шагов в этом направлении, оказавшим влияние на развитие отечественной вычислительной техники, явилось создание компью­теров серии IBM 360, обладающих единым набором команд и способ­ных работать с одной и той же операционной системой. Корпорация «IBM», кроме того, предоставляла лицензии на свою ОС пользовате­лям, которые предпочли купить компьютеры той же архитектуры у других производителей.

Частичное решение проблемы мобильности для программ обеспе­чили ранние стандарты языков, например ФОРТРАН и КОБОЛ. Языи позволяли создавать переносимые программы, хотя часто ограни­чивали функциональные возможности. Мобильность обеспечивалась также за счет того, что эти стандарты были приняты многими произ­водителями различных платформ. Когда языки программирования приобрели статус стандарта де-факто, их разработкой и сопровожде­нием начали заниматься национальные и международные организа­ции по стандартизации. В результате языки развивались уже незави­симо от своих создателей. Достижение мобильности уже на этом уровне было первым примером истинных возможностей открытых систем.

Следующий этап в развитии концепции открытости - вторая по­ловина 1970-х гг. Он связан с областью интерактивной обработки и увеличением объема продуктов, для которых требуется переносимость (пакеты для инженерной графики, системы автоматизации проекти­рования, базы данных, управление распределенными базами данных). Компания «DIGITAL» начала выпуск мини-ЭВМ VAX, работающих под управлением операционной системы VMS. Машины этой серии имели уже 32-разрядную архитектуру, что обеспечило значительную эффективность программного кода и сократило издержки на работу с виртуальной памятью. Программисты получили возможность напря­мую использовать адресное пространство объемом до 4 Гбайт, что прак­тически снимало все ограничения на размеры решаемых задач. Маши­ны этого типа надолго стали стандартной платформой для систем про­ектирования, сбора и обработки данных, управления экспериментом и т.п. Именно они стимулировали создание наиболее мощных САПР, систем управления базами данных и машинной графики, которые широко используются до настоящего времени.

Конец 1970-х гг. характеризуется массовым применением сетевых технологий. Компания «DIGITAL» интенсивно внедряла свою архитек­туру DECnet. Сети, использующие протоколы Интернет (TCP/IP), пер­воначально реализованные Агентством по перспективным исследова­ниям Министерства обороны США (DARPA), начали широко приме­няться для объединения различных систем - как военных, так и академических организаций США. Фирма «IBM» применяла собствен­ную сетевую архитектуру SNA (System Network Architecture), которая стала основой для предложенной Международной организацией по стан­дартизации ISO архитектуры Open Systems Interconnection (OSI).

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

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

Существует достаточное число определений, даваемых различны­ми организациями по стандартизации и отдельными фирмами. Напри­мер, Ассоциация французских пользователей UNIX и открытых сис­тем (AFUU) дает следующее определение: «Открытая система - это система, состоящая из элементов, которые взаимодействуют друг с другом через стандартные интерфейсы».

Производитель средств вычислительной техники - компания Hewlett Packard: «Открытая система - это совокупность разнородных компьютеров, объединенных сетью, которые могут работать как еди­ное интегрированное целое независимо от того, как в них представлена информация, где они расположены, кем они изготовлены, под уп­равлением какой операционной системы они работают».

Определение Национального института стандартов и технологий США (NIST): «Открытая система - это система, которая способна взаимодействовать с другой системой посредством реализации меж­дународных стандартных протоколов. Открытыми системами являют­ся как конечные, так и промежуточные системы. Однако открытая си­стема не обязательно может быть доступна другим открытым систе­мам. Эта изоляция может быть обеспечена или путем физического отделения, или путем использования технических возможностей, ос­нованных на защите информации в компьютерах и средствах комму­никаций».

Другие определения в той или иной мере повторяют основное со­держание определений, приведенных выше. (Анализируя их, можно выделить некоторые общие черты, присущие открытым системам:

Технические средства, на которых реализована информационная система, объединяются сетью или сетями различного уровня - от ло­кальной до глобальной;

Реализация открытости осуществляется на основе функциональ­ных стандартов (профилей) в области информационных технологий;

Информационные системы, обладающие свойством открытости, могут выполняться на любых технических средствах, которые входят в единую среду открытых систем;

Открытые системы предполагают использование унифицирован­ных интерфейсов в процессах взаимодействия в системе «человек - компьютер»;

Применение положений открытости предполагает некоторую из­быточность при разработке программно-аппаратных комплексов.

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

Это определение, сформулированное специалистами Комитета IEEE POSIX 1003.0 Института инженеров по электротехнике и элек­тронике (IEEE), унифицирует содержание среды, которую предостав­ляет открытая система для широкого использования. Базовым в этом определении является термин «открытая спецификация», имеющий следующее.толкование: «это общедоступная спецификация, которая поддерживается открытым, гласным, согласительным процессом, на­правленным на постоянную адаптацию новой технологии, и которая соответствует стандартам». Таким образом, под открытыми система­ми следует понимать системы, обладающие стандартизованными ин­терфейсами. Решение проблемы открытости систем основывается на стандартизации интерфейсов систем и протоколов взаимодействия между их компонентами.

В качестве примеров использования технологии открытых систем можно привести технологии фирм «Intel» Plug&Play и USB, а также операционные системы UNIX и (частично) ее основного конкурента - Windows NT. Многие новые продукты сразу разрабатываются в соот­ветствии с требованиями открытых систем, примером тому может слу­жить широко используемый в настоящее время язык программирова­ния Javaфирмы «Sun Microsystems».

Общие свойства открытых информационных систем можно сфор­мулировать следующим образом:

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

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

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

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

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

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

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

Функционирование систем в условиях информационной и реализа­ционной неоднородности, распределенности и автономности информа­ционных ресурсов системы. Информационная неоднородность ресур­сов заключается в разнообразии их прикладных контекстов (понятий, словарей, семантических правил, отображаемых реальных объектов, видов данных, способов их сбора и обработки, интерфейсов пользова­телей и т.д.). Реализационная неоднородности источников проявляет­ся в использовании разнообразных компьютерных платформ, средств управления базами данных, моделей данных и знаний, средств про­граммирования и тестирования, операционных систем и т.п.

Интеграция систем. Системы эволюционируют от простых, авто­номных подсистем к более сложным, интегрированным системам, ос­нованным на требовании взаимодействия компонентов.

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

Трансформация унаследованных систем. Практически любая систе­ма после создания и внедрения противодействует изменениям и имеет тенденцию быстрого превращения в бремя организации. Унаследован­ные системы (Legacy Systems), построенные на «уходящих» техноло­гиях, архитектурах, платформах, а также программное и информаци­онное обеспечение, при проектировании которых не были предусмот­рены нужные меры для их постепенного перерастания в новые системы, требуют перестройки (Legacy Transformation) в соответствии с новы­ми требованиями бизнес-процессов и технологий. В процессе транс­формации необходимо, чтобы новые модули системы и оставшиеся компоненты унаследованных систем сохраняли способность к взаимо­действию.

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

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

Свойство интероперабельности информационных ресурсов явля­ется необходимой предпосылкой удовлетворения перечисленных выше требований.

Таким образом, основной принцип формирования открытых сис­тем состоит в создании среды, включающей в себя программные и ап­паратурные средства, службы связи, интерфейсы, форматы данных и протоколы. Такая среда в основе имеет развивающиеся доступные и общепризнанные стандарты и обеспечивает значительную степень вза­имодействия (Inter-operability), переносимости (Portability) и масш­табирования (Scalability) приложений и данных.

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

Принципы создания и использования открытых систем применя­ются в настоящее время при построении большинства классов систем:вычислительных, информационных, телекоммуникационных, систем управления в реальном масштабе времени, встроенных микропроцес­сорных систем. В условиях широкого использования интегрирован­ных вычислительно-телекоммуникационных систем принципы откры­тости составляют основу технологии интеграции, В развитии и при­менении открытых систем заинтересованы все участники процесса информатизации: пользователи, проектировщики систем и системные интеграторы, производители технических и программных средств вы­числительной техники и телекоммуникации. В частности, по встроен­ным микропроцессорным системам (МПС) в рамках программы ESPRITсуществует проект OMI (Open Microprocessor Initiative), на­правленный на создание коллективной пользовательской библиотеки МПС в соответствии с принципами открытых систем.

В условиях перехода к информационному обществу, когда государ­ственное управление и большинство секторов экономики становятся активными потребителями информационных технологий, а сектор производителей средств и услуг информационных технологий непре­рывно растет, проблема развития и применения открытых систем со­ставляет для каждой страны национальную проблему. Так, админист­рация Клинтона еще в 1993 г. объявила о программе создания Нацио­нальной информационной инфраструктуры на принципах открытых систем (NationalInformation Infrastructure Initiative), вкладывала в эту программу большие деньги и содействовала инвестициям со стороны частного сектора. Совет Европы в 1994 г. в своих рекомендациях о пу­тях перехода к информационному обществу (Bangemann Report) под­черкнул, что стандарты открытых систем должны играть важнейшую роль при создании информационной инфраструктуры общества. Ве­дется работа по созданию глобальной информационной инфраструк­туры, также основанной на принципах открытых систем.

Таким образом, в условиях перехода к информационному обществу технология открытых систем становится основным направлением ин­формационных технологий.

Похожая информация.

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

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

Как следует из определения, необходимыми условиями открытости являются:

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

Требование модульности вытекает из требования возможности замены части системы (т. е. модуля) аналогичными изделиями других производителей. Для этого система должна состоять из модулей.

Соответствие стандартам необходимо для обеспечения совместимости.

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

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

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

В отличие от открытых, закрытые системы разрабатываются по внутренним стандартам отдельных предприятий. Части (модули) закрытых систем не могут быть заменены аналогичными изделиями других производителей, а заказчик, однажды применив закрытую систему, навсегда оказывается привязанным к ее разработчику.

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

Модель OSI, как это следует из ее названия (Open System Interconnection), описы­вает взаимосвязи открытых систем. Что же такое открытая система?

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

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

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

Для реальных систем полная открытость является недостижимым идеалом. Как правило, даже в системах, называемых открытыми, этому определению соответствуют лишь некоторые части, поддерживающие внешние интерфейсы. На­пример, открытость семейства операционных систем Unix заключается, кроме всего прочего, в наличии стандартизованного программного интерфейса между ядром и приложениями, что позволяет легко переносить приложения из среды одной версии Unix в среду другой версии. Еще одним примером частичной открытости является применение в достаточно закрытой операционной системе Novell NetWare открытого интерфейса Open Driver Interface (ODI) для включе­ния в систему драйверов сетевых адаптеров независимых производителей. Чем больше открытых спецификаций использовано при разработке системы, тем бо­лее открытой она является.

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

Если две сети построены с соблюдением принципов открытости, то это дает следующие преимущества:

Возможность построения сети из аппаратных и программных средств различ­ных производителей, придерживающихся одного и того же стандарта;

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

Возможность легкого сопряжения одной сети с другой;

Простота освоения и обслуживания сети.

Ярким примером открытой системы является международная сеть Internet. Эта сеть развивалась в полном соответствии с требованиями, предъявляемыми к от­крытым системам. В разработке ее стандартов принимали участие тысячи специа­листов-пользователей этой сети из различных университетов, научных организаций и фирм-производителей вычислительной аппаратуры и программного обеспече­ния, работающих в разных странах. Само название стандартов, определяющих ра­боту сети Internet - Request For Comments (RFC), что можно перевести как «запрос на комментарии», - показывает гласный и открытый характер принимаемых стан­дартов. В результате сеть Internet сумела объединить в себе самое разнообразное оборудование и программное обеспечение огромного числа сетей, разбросанных по всему миру.

1.3.5. Модульность и стандартизация

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

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

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

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

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

1.3.6. Источники стандартов

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

стандарты отдельных фирм (например, стек протоколов DECnet фирмы Digital Equipment или графический интерфейс OPEN LOOK для Unix-систем фирмы Sun);

стандарты специальных комитетов и объединений, создаваемых несколькими фирмами, например стандарты технологии АТМ, разрабатываемые специально созданным объединением АТМ Forum, насчитывающем около 100 коллектив­ных участников, или стандарты союза Fast Ethernet Alliance по разработке стан­дартов 100 Мбит Ethernet;

национальные стандарты, например, стандарт FDDI, представляющий один из многочисленных стандартов, разработанных Американским национальным ин­ститутом стандартов (ANSI), или стандарты безопасности для операционных систем, разработанные Национальным центром компьютерной безопасности (NCSC) Министерства обороны США;

международные стандарты, например, модель и стек коммуникационных про­токолов Международной организации по стандартам (ISO), многочисленные

стандарты Международного союза электросвязи (ITU), в том числе стандарты

на сети с коммутацией пакетов Х.25, сети frame relay, ISDN, модемы и многие

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

Более того, ввиду широкого распространения некоторые фирменные стандарты становятся основой для национальных и международных стандартов де-юре. Например, стандарт Ethernet, первоначально разработанный компаниями Digital Equipment, Intel и Xerox, через некоторое время и в несколько измененном виде был принят как национальный стандарт IEEE 802.3, а затем организация ISO утвердила его в качестве международного стандарта ISO 8802.3.

Международная организация по стандартизации (International Organization / or Standardization , ISO , часто называемая также International Standards Organization ) представляет собой ассоциацию ведущих национальных организаций по стан­дартизации разных стран. Главным достижением ISO явилась модель взаимо­действия открытых систем OSI, которая в настоящее время является концеп­туальной основой стандартизации в области вычислительных сетей. В соответ­ствии с моделью OSI этой организацией был разработан стандартный стек ком­муникационных протоколов OSI.

Международный союз электросвязи (International Telecommunications Union , ITU ) - организация, являющаяся в настоящее время специализированным органом Организации Объединенных Наций. Наиболее значительную роль в стандарти­зации вычислительных сетей играет постоянно действующий в рамках этой организации Международный консультативный комитет по телефонии и теле­графии (МККТТ) (Consultative Committee on International Telegraphy and Telephony, CCITT). В результате проведенной в 1993 году реорганизации ITU CCITT несколько изменил направление своей деятельности и сменил назва­ние - теперь он называется сектором телекоммуникационной стандартизации ITU (ITU Telecommunication Standardization Sector, ITU-T). Основу деятельно­сти ITU-T составляет разработка международных стандартов в области телефо­нии, телематических служб (электронной почты, факсимильной связи, телетекста, телекса и т. д.), передачи данных, аудио- и видеосигналов. За годы своей дея­тельности ITU-T выпустил огромное число рекомендаций-стандартов. Свою работу ITU-T строит на изучении опыта сторонних организаций, а также на результатах собственных исследований. Раз в четыре года издаются труды ITU-T в виде так называемой «Книги», которая на самом деле представляет собой целый набор обычных книг, сгруппированных в выпуски, которые, в свою очередь, объединяются в тома. Каждый том и выпуск содержат логически взаимосвязан­ные рекомендации. Например, том III Синей Книги содержит рекомендации для цифровых сетей с интеграцией услуг (ISDN), а весь том VIII (за исключе­нием выпуска VIII.1, который содержит рекомендации серии V для передачи данных по телефонной сети) посвящен рекомендациям серии X: Х.25 для сетей с коммутацией пакетов, Х.400 для систем электронной почты, Х.500 для гло­бальной справочной службы и многим другим.

Институт инженеров по электротехнике и радиоэлектронике - Institute of Electrical and Electronics Engineers , IEEE ) - национальная организация США, определяющая сетевые стандарты. В 1981 году рабочая группа 802 этого инсти­тута сформулировала основные требования, которым должны удовлетворять локальные вычислительные сети. Группа 802 определила множество стандар­тов, из них самыми известными являются стандарты 802.1,802.2, 802.3 и 802.5, которые описывают общие понятия, используемые в области локальных сетей, а также стандарты на два нижних уровня сетей Ethernet и Token Ring.

Европейская ассоциация производителей компьютеров (European Computer Manu ­ facturers Association , ЕСМА) - некоммерческая организация, активно сотрудни­чающая с ITU-T и ISO, занимается разработкой стандартов и технических обзоров, относящихся к компьютерной и коммуникационной технологиям. Из­вестна своим стандартом ЕСМА-101, используемым при передаче отформати­рованного текста и графических изображений с сохранением оригинального формата.

Ассоциация производителей компьютеров и оргтехники (Computer and Business Equipment Manufacturers Association , CBEMA ) - организация американских фирм-производителей аппаратного обеспечения; аналогична европейской ассоциации ЕКМА; участвует в разработке стандартов на обработку информации и соответ­ствующее оборудование.

Ассоциация электронной промышленности (Electronic Industries Association , EIA ) - промышленно-торговая группа производителей электронного и сетевого обору­дования; является национальной коммерческой ассоциацией США; проявляет значительную активность в разработке стандартов для проводов, коннекторов и других сетевых компонентов. Ее наиболее известный стандарт - RS-232C.

Министерство обороны США (Department of Defense , DoD ) имеет многочислен­ные подразделения, занимающиеся созданием стандартов для компьютерных систем. Одной из самых известных разработок DoD является стек транспорт­ных протоколов TCP/IP.

Американский национальный институт стандартов (American National Standards Institute , ANSI ) - эта организация представляет США в Международной орга­низации по стандартизации ISO. Комитеты ANSI ведут работу по разработке стандартов в различных областях вычислительной техники. Так, комитет ANSI ХЗТ9.5 совместно с фирмой IBM занимается стандартизацией локальных сетей крупных ЭВМ (архитектура сетей SNA). Известный стандарт FDDI также яв­ляется результатом деятельности этого комитета ANSI. В области микрокомпь­ютеров ANSI разрабатывает стандарты на языки программирования, интерфейс SCSI. ANSI разработал рекомендации по переносимости для языков С, FORTRAN, COBOL.

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

Основным из них является Internet Society (ISOC) - профессиональное сооб­щество, которое занимается общими вопросами эволюции и роста Internet как гло­бальной коммуникационной инфраструктуры. Под управлением ISOC работает Internet Architecture Board (IAB) - организация, в ведении которой находится технический контроль и координация работ для Internet. IAB координирует на­правление исследований и новых разработок для стека TCP/IP и является конеч­ной инстанцией при определении новых стандартов Internet.

В IAB входят две основные группы: Internet Engineering Task Force (IETF) и Internet Research Task Force (IRTF). IETF - это инженерная группа, которая занимается ре­шением ближайших технических проблем Internet. Именно IETF определяет спе­цификации, которые затем становятся стандартами Internet. В свою очередь, IRTF координирует долгосрочные исследовательские проекты по протоколам TCP/IP.

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

Сначала в IETF представляется так называемый рабочий проект (draft ) в виде, доступном для комментариев. Он публикуется в Internet, после чего широкий круг заинтересованных лиц включается в обсуждение этого документа, в него вносятся исправления, и наконец наступает момент, когда можно зафиксиро­вать содержание документа. На этом этапе проекту присваивается номер RFC (возможен «. другой вариант развития событий - после обсуждения рабочий проект отвергается и удаляется из Internet).

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

Если результаты практических исследований показывают эффективность пред­лагаемого стандарта, то ему, со всеми внесенными изменениями, присваивается статус проекта стандарта. Затем в течение не менее 4-х месяцев проходят его, дальнейшие испытания «на прочность», в число которых входит создание по крайней мере двух программных реализации.

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

1.3.7. Стандартные стеки коммуникационных протоколов

Важнейшим направлением стандартизации в области вычислительных сетей явля­ется стандартизация коммуникационных протоколов. В настоящее время в сетях используется большое количество стеков коммуникационных протоколов. Наибо­лее популярными являются стеки: TCP/IP, IPX/SPX, NetBIOS/SMB, DECnet, SNA и OSLBce эти стеки, кроме SNA на нижних уровнях - физическом и канальном, - используют одни и те же хорошо стандартизованные протоколы Ethernet, Token;

Ring, FDDI и некоторые другие, которые позволяют использовать во всех сетях одну и ту же аппаратуру. Зато на верхних уровнях все стеки работают по своим! собственным протоколам. Эти протоколы часто не соответствуют рекомендуемому! моделью OSI разбиению на уровни. В частности, функции сеансового и представи-" тельного уровня, как правило, объединены с прикладным уровнем. Такое несоот-| ветствие связано с тем, что модель OSI появилась как результат обобщения ужи существующих и реально используемых стеков, а не наоборот.

Следует четко различать модель OSI и стек OSI. В то время как модель OSI явля-| ется концептуальной схемой взаимодействия открытых систем, стек OSI представ| ляет собой набор вполне конкретных спецификаций протоколов. В отличие от други[ стеков протоколов стек OSI полностью соответствует модели OSI, он включает спецификации протоколов для всех семи уровней взаимодействия, определенных этой модели. На нижних уровнях стек OSI поддерживает Ethernet, Token Ring FDDI, протоколы глобальных сетей, Х.25 и ISDN, - то есть использует разработанные вне стека протоколы нижних уровней, как и все другие стеки. Протокола сетевого, транспортного и сеансового уровней стека OSI специфицированы и реализованы различными производителями, но распространены пока мало. Наиболее популярными протоколами стека OSI являются прикладные протоколы. К ним относятся: протокол передачи файлов FTAM, протокол эмуляции терминала VTPJ протоколы справочной службы Х.500, электронной почты Х.400 и ряд других. :

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

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

Стек OSI - международный, независимый от производителей стандарт. Его поддерживает правительство США в своей программе GOSIP, в соответствии с которой все компьютерные сети, устанавливаемые в правительственных учрежде­ниях США после 1990 года, должны или непосредственно поддерживать стек OSI, или обеспечивать средства для перехода на этот стек в будущем. Тем не менее стек OSI более популярен в Европе, чем в США, так как в Европе осталось меньше старых сетей, работающих по своим собственным протоколам. Большинство орга­низаций пока только планируют переход к стеку OSI, и очень немногие приступи­ли к созданию пилотных проектов. Из тех, кто работает в этом направлении, можно назвать Военно-морское ведомство США и сеть NFSNET. Одним из крупнейших производителей, поддерживающих OSI, является компания AT&T, ее сеть Stargroup полностью базируется на этом стеке.

Стек TCP/IP был разработан по инициативе Министерства обороны США более 20 лет назад для связи экспериментальной сети ARPAnet с другими сетями как набор общих протоколов для разнородной вычислительной среды. Большой вклад в развитие стека TCP/IP, который получил свое название по популярным протоко­лам IP и TCP, внес университет Беркли, реализовав протоколы стека в своей вер­сии ОС UNIX. Популярность этой операционной системы привела к широкому распространению протоколов TCP, IP и других протоколов стека. Сегодня этот стек используется для связи компьютеров всемирной информационной сети Internet, а также в огромном числе корпоративных сетей.

Стек TCP/IP на нижнем уровне поддерживает все популярные стандарты фи­зического и канального уровней: для локальных сетей - это Ethernet, Token Ring, FDDI, для глобальных - протоколы работы на аналоговых коммутируемых и вы­деленных линиях SLIP, РРР, протоколы территориальных сетей Х.25 и ISDN.

Основными протоколами стека, давшими ему название, являются протоколы IP и TCP. Эти протоколы в терминологии модели OSI относятся к сетевому и транспортному уровням соответственно. IP обеспечивает продвижение пакета по составной сети, a TCP гарантирует надежность его доставки.

За долгие годы использования в сетях различных стран и организаций стек TCP/IP вобрал в себя большое количество протоколов прикладного уровня. К ним относятся такие популярные протоколы, как протокол пересылки файлов FTP, протокол эмуляции терминала telnet, почтовый протокол SMTP, используемый в электронной почте сети Internet, гипертекстовые сервисы службы WWW и многие Другие.

Сегодня стек TCP/IP представляет собой один из самых распространенных стеков транспортных протоколов вычислительных сетей. Действительно, только в сети Internet объединено около 10 миллионов компьютеров по всему миру, кото­рые взаимодействуют друг с другом с помощью стека протоколов TCP/IP.

Стремительный рост популярности Internet привел и к изменениям в расста­новке сил в мире коммуникационных протоколов - протоколы TCP/IP, на кото­рых построен Internet, стали быстро теснить бесспорного лидера прошлых лет - стек IPX/SPX компании Novell. Сегодня в мире общее количество компьютеров, на которых установлен стек TCP/IP, сравнялось с общим количеством компьюте­ров, на которых работает стек IPX/SPX, и это говорит о резком переломе в от­ношении администраторов локальных сетей к протоколам, используемым на настольных компьютерах, так как именно они составляют подавляющее число мирового компьютерного парка и именно на них раньше почти везде работали прото­колы компании Novell, необходимые для доступа к файловым серверам NetWare. Процесс становления стека TCP/IP в качестве стека номер один в любых типах сетей продолжается, и сейчас любая промышленная операционная система обя-1 зательно включает программную реализацию этого стека в своем комплекте поставки.

Хотя протоколы TCP/IP неразрывно связаны с Internet и каждый из много­миллионной армады компьютеров Internet работает на основе этого стека, суще­ствует большое количество локальных, корпоративных и территориальных сетей, непосредственно не являющихся частями Internet, в которых также используют

протоколы TCP/IP. Чтобы отличать их от Internet, эти сети называют сетями TCP/IP, или просто IP-сетями.

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

Другой особенностью технологии TCP/IP является гибкая система адресации, позволяющая более просто по сравнению с другими протоколами аналогичного назначения включать в интерсеть сети других технологий. Это свойств также способствует применению стека TCP/IP для построения больших гетер» генных сетей.

В стеке TCP/IP очень экономно используются возможности широковещательных рассылок. Это свойство совершенно необходимо при работе на медленных каналах связи, характерных для территориальных сетей.

Однако, как и всегда, за получаемые преимущества надо платить, и платой здесй оказываются высокие требования к ресурсам и сложность администрирования IP-сетей. Мощные функциональные возможности протоколов стека TCP/IP требуют для своей реализации высоких вычислительных затрат. Гибкая система адресации! и отказ от широковещательных рассылок приводят к наличию в IP-сети различных централизованных служб типа DNS, DHCP и т. п. Каждая из этих служб на­правлена на облегчение администрирования сети, в том числе и на облегчение кон­фигурирования оборудования, но в то же время сама требует пристального внима­ния со стороны администраторов.

Можно приводить и другие доводы за и против стека протоколов Internet, од­нако факт остается фактом - сегодня это самый популярный стек протоколов, широко используемый как в глобальных, так и локальных сетях.

Стек IPX/SPX

Этот стек является оригинальным стеком протоколов фирмы Novell, разработан­ным для сетевой операционной системы NetWare еще в начале 80-х годов. Прото­колы сетевого и сеансового уровней Internetwork Packet Exchange (IPX) и Sequenced Packet Exchange (SPX), которые дали название стеку, являются прямой адаптаци­ей протоколов XNS фирмы Xerox, распространенных в гораздо меньшей степени, чем стек IPX/SPX. Популярность стека IPX/SPX непосредственно связана с опе­рационной системой Novell NetWare, которая еще сохраняет мировое лидерство по числу установленных систем, хотя в последнее время ее популярность несколько снизилась и по темпам роста она отстает от Microsoft Windows NT.

Многие особенности стека IPX/SPX обусловлены ориентацией ранних версий ОС NetWare (до версии 4.0) на работу в локальных сетях небольших размеров, состоящих из персональных компьютеров со скромными ресурсами. Понятно, что для таких компьютеров компании Novell нужны были протоколы, на реализацию которых требовалось бы минимальное количество оперативной памяти (ограни­ченной в IBM-совместимых компьютерах под управлением MS-DOS объемом 640 Кбайт) и которые бы быстро работали на процессорах небольшой вычисли­тельной мощности. В результате протоколы стека IPX/SPX до недавнего времени хорошо работали в локальных сетях и не очень - в больших корпоративных сетях, так как они слишком перегружали медленные глобальные связи широковещатель­ными пакетами, которые интенсивно используются несколькими протоколами этого стека (например, для установления связи между клиентами и серверами). Это об­стоятельство, а также тот факт, что стек IPX/SPX является собственностью фир­мы Novell и на его реализацию нужно получать лицензию (то есть открытые спецификации не поддерживались), долгое время ограничивали распространен­ность его только сетями NetWare. Однако с момента выпуска версии NetWare 4.0 Novell внесла и продолжает вносить в свои протоколы серьезные изменения, на­правленные на их адаптацию для работы в корпоративных сетях. Сейчас стек IPX/ SPX реализован не только в NetWare, но и в нескольких других популярных сете­вых ОС, например SCO UNIX, Sun Solaris, Microsoft Windows NT.

Стек NetBIOS/SMB

Этот стек широко используется в продуктах компаний IBM и Microsoft. На физи­ческом и канальном уровнях этого стека используются все наиболее распростра­ненные протоколы Ethernet, Token Ring, FDDI и другие. На верхних уровнях работают протоколы NetBEUI и SMB.

Протокол NetBIOS (Network Basic Input/Output System) появился в 1984 году как сетевое расширение стандартных функций базовой системы ввода/вывода (BIOS) IBM PC для сетевой программы PC Network фирмы IBM. В дальнейшем этот протокол был заменен так называемым протоколом расширенного пользова­тельского интерфейса NetBEUI - NetBIOS Extended User Interface. Для обеспече­ния совместимости приложений в качестве интерфейса к протоколу NetBEUI был сохранен интерфейс NetBIOS. Протокол NetBEUI разрабатывался как эффектив­ный протокол, потребляющий немного ресурсов и предназначенный для сетей, насчитывающих не более 200 рабочих станций. Этот протокол содержит много полезных сетевых функций, которые можно отнести к сетевому, транспортному и сеансовому уровням модели OSI, однако с его помощью невозможна маршрутиза­ция пакетов. Это ограничивает применение протокола NetBEUI локальными сетя­ми, не разделенными на подсети, и делает невозможным его использование в составных сетях. Некоторые ограничения NetBEUI снимаются реализацией этого протокола NBF (NetBEUI Frame), которая включена в операционную систему Microsoft Windows NT.

Протокол SMB (Server Message Block) выполняет функции сеансового, пред­ставительного и прикладного уровней. На основе SMB реализуется файловая служба, а также службы печати и передачи сообщений между приложениями.

Стеки протоколов SNA фирмы IBM, DECnet корпорации Digital Equipment и AppleTalk/AFP фирмы Apple применяются в основном в операционных системах и сетевом оборудовании этих фирм.

Рис. 1.30. Соответствие популярных стеков протоколов модели OSI

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

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

Формализованные правила, определяющие последовательность и формат сооб­щений, которыми обмениваются сетевые компоненты, лежащие на одном уров­не, но в разных узлах, называются протоколом.

Формализованные правила, определяющие взаимодействие сетевых компонен­тов соседних уровней одного узла, называются интерфейсом. Интерфейс опре­деляет набор сервисов, предоставляемый данным уровнем соседнему уровню.

Иерархически организованный набор протоколов, достаточный для организа­ции взаимодействия узлов в сети, называется стеком коммуникационных про­токолов.

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

Модель OSI стандартизует взаимодействие открытых систем. Она определяет 7 уровней взаимодействия: прикладной, представительный, сеансовый, транс­портный, сетевой, канальный и физический.

Важнейшим направлением стандартизации в области вычислительных сетей является стандартизация коммуникационных протоколов. Наиболее популяр­ными являются стеки: TCP/IP, IPX/SPX, NetBIOS/SMB, DECnet, SNA и OSI.

Итак, предметом синергетики являются сложные самоорганизующиеся системы. Один из основоположников синергетики Г. Хакен определяет понятие самоорганизующейся системы следующим образом:

Хакен Г. Информация и самоорганизация. Макроскопический подход к сложным системам. М., 1991. С. 140

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

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

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

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

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

Вместе с тем уже во второй половине XIX в., и особенно в XX в., биология, прежде всего теория эволюции Дарвина, убедительно показала, что эволюция Вселенной не приводит к снижению уровня организации и обеднению разнообразия форм материи. Скорее, наоборот. История и эволюция Вселенной развивают ее от простого к сложному, от низших форм организации к высшим, от менее организованного к более организованному. Иначе говоря, старея, Вселенная обретает все более сложную организацию. Попытки согласовать второе начало термодинамики с выводами биологических и социальных наук долгое время были безуспешными. Классическая термодинамика не могла описывать закономерности открытых систем. Такая возможность появилась только с переходом естествознания к изучению открытых систем. Николис Г., Пригожин И. Познание сложного. М., 1990 С. 293

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

Ты балда, Коломб, - скажу по чести. Что касается меня, то я бы лично - я б Америку закрыл, слегка почистил, а потом опять открыл - вторично. В.В. Маяковский "Христофор Коломб" (ПСС в 13-ти т., т. 7, с. 38)

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

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

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

Открытость операционной системы

Возьмем, к примеру, широкораспространенную операционную систему MS DOS и ее оболочку Windows 3.11, и попытаемся проанализировать, как там поставлено дело в части подключения и отключения приложений. Иначе говоря, очевидным образом расширим толкование открытости системы, включив в него также и легкость перемещения приложения в обоих направлениях: пусть теперь открытая система должна обеспечивать и свободу добавления новых приложений, и свободу исключения существующих. Оказывается, что под таким углом зрения рассматриваемые системы выглядят недостаточно открытыми; более того, дела тут обстоят из рук вон плохо.

Если в организации процедуры добавления (инсталляции) приложения еще можно не разглядеть определенных недоработок, то уж деинсталляция буквально вопиет. Каждый, кому выпало хоть раз искоренять глубоко засевшее в бесчисленных системных файлах (config.sys, autoexec.bat, win.ini, system.ini, ...) приложение, не может без дрожи вспоминать об этих нескольких мучительных часах своего программистского бытия. Обиднее всего, что борьба эта, как правило, обречена на бесславное поражение: обычно так и не удается полностью выявить и изничтожить все крючья, которыми сложное приложение сцепилось с операционной системой.

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

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

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

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

Некоторое приближение к описанной схеме можно найти в Windows 95. Что же помешало разработчикам Microsoft с самого начала применить подобное решение? Причин можно назвать несколько, но лишь одна из них представляется достаточно весомой, хотя и далеко не очевидной.

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

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

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

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

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

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

Рассредоточенный набор

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

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

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

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

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

Рисунок 1.
Рассредоточенный набор.

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

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

Открытость системы программирования

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

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

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

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

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

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

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

Модный термин "масштабируемость", говорящий о потенциале наращивания мощности аппаратуры, почему-то мало кому приходит в голову применить и к программным структурам. Что случилось бы со строительством, если бы все архитекторы работали только над уникальными сооружениями, отказавшись и от типовых проектов, и от типовых строительных блоков?! А в программировании нередко проектируют уникальный, но консервативный зоопарк там, где требуется всего лишь серийный, но масштабируемый коровник или свинарник.

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

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

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

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

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

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

Литература

. Горбунов-Посадов М.М. Безболезненное развитие программы // Открытые системы. - 1996. - # 4(18). - С.65-70.

. Горбунов-Посадов М.М. Конфигурации программ. Рецепты безболезненных изменений. - 2-е изд., испр. и доп. - М.: Малип, 1994. - 272 с.

. Parnas D.L. On the criteria to be used in decomposing systems into modules // Comm.ACM. - 1972. - V.15, # 12. - P.1053-1058.

. Ben-Ari M. Understanding programming languages. - Chichester: John Wiley & Sons, 1996. - 360 p.

Работа выполнена при финансовой поддержке Российского фонда фундаментальных исследований.