Открытость системы. Система открыта, но что-то мешает

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

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

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

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

Открытой называется модульная система, которая допускает замену любого модуля на аналогичный модуль другого производителя, имеющийся в свободной продаже по конкурентоспособным ценам, а интеграция системы с другими системами (в том числе с пользователем) выполняется без преодоления чрезмерных проблем. Понятие открытости обсуждается на веб-сайтах OMAC (Open Modular Architecture Controls , www.omac.org), и в работах [Helei , Business - Wang ].

Масштабируемость ( наращиваемость)

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

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

Стандартность пользовательского интерфейса

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

1.3.2. Средства достижения открытости

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

Промышленные сети и протоколы

Наиболее распространенными в России являются сети Modbus , Profibus , CAN , Ethernet . Оборудование, совместимое с ними, выпускается сотнями конкурирующих предприятий в разных странах мира, что обеспечивает отсутствие монопольных цен.

Интерфейсы

Наибольшая часть средств промышленной автоматизации, представленных на Российском рынке, имеет интерфейсы RS -232, RS -485, RS -422, CAN , Ethernet , USB . Большое значение для повышения степени открытости имеют преобразователи интерфейсов и межсетевые шлюзы, которые позволяют объединять в единую систему несовместимое по интерфейсам и протоколам оборудование.

Программные интерфейсы

Для взаимодействия открытых систем на программном уровне наибольшее распространение получила DCOM -технология фирмы Microsoft , воплощенная в промышленный стандарт OPC (OLE for Process Control ) [Iwanitz ], который пришел на смену устаревшей технологии DDE (Dynamic Data Exchange ). Стандарт ОРС обеспечил возможность применения оборудования различных производителей практически с любыми SCADA , имеющимися на рынке, поскольку большинство из них поддерживает стандарт OPC .

Аналогичная задача может быть решена также с помощью технологии Jini фирмы SUN и CORBA фирмы OMG [Feldmann ], однако воплощение в международный стандарт OPC получила только технология DCOM , ориентированная на Windows -платформы (подробнее см. "OPC-сервер").

Интерфейс пользователя

Интерфейс между SCADA и пользователем в настоящее время выполняется примерно одними и теми же визуальными средствами, которые стали стандартом де-факто: кнопки пуск/стоп, цифровое табло, линейный или радиальный индикатор уровня, цветовая сигнализация, окна с текстовыми сообщениями, окна ввода данных, графики и т.п. Такой интерфейс легко осваивается операторами АСУ ТП.

Программирование контроллеров поддерживается тремя международными стандартами: стандартом МЭК 61131-3 [Lewis ] на языки программирования и стандартами МЭК 61499 [First Edition, 2005-01. - International Electro...">International , Гулько ] и МЭК 61804 на функциональные блоки. Стандарты поддерживаются большинством производителей программного обеспечения. Примером могут быть системы ISaGRAF фирмы ICS Triplex и CoDeSys фирмы 3S . Поддержку открытости обеспечивают также конверторы блоков UML (Unifid Modeling Language [Буч ]) в функциональные блоки стандарта IEC 61499, а также UML в XML (eXtended Markup Language ).

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

Программная совместимость

Важным достоинством SCADA пакетов, повышающим степень их открытости, является связь с программами Microsoft Office (Word, Excel, Access) , которая снижает затраты на обучение персонала и расширяет возможности представления и обработки результатов измерений.

Совместимость баз данных со SCADA обеспечивает широко распространенный язык запросов SQL , соответствующий международному стандарту и поддерживаемый несколькими СУБД (системами управления базами данных), например, Informix, Sybase, Ingres, MS SQL Server . Интерфейс ODBC (Open Data Base Connectivity ) позволяет подключать к одной и той же SCADA различные СУБД, что повышает степень ее открытости.

Обеспечение в некоторых SCADA пакетах возможности программирования на языке Visual Basic , а также возможность встраивания ActiveX и COM объектов сторонних производителей позволяет адаптировать SCADA к аппаратуре, не поддерживающей стандарт ОРС, а также применить принцип повторного использования программного кода, написанного для других приложений.

1.3.3. Достоинства и недостатки

Основным преимуществом систем с открытой архитектурой является низкая стоимость их жизненного цикла [Business ]. Жизненный цикл АСУ ТП состоит из следующих фаз:

• разработка концепции и эскизное проектирование;
• проектирование и изготовление системы;
• монтаж и пуско-наладка;
• эксплуатация системы;
• обслуживание;
• реконфигурация, модернизация, разборка, утилизация.

В работе [White paper version 1.0. - Users ...">Business ] подробно рассмотрена стоимость каждого из перечисленных этапов.

Выгодой от применения открытых систем являются:

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

В работе [Pizzica ] описаны конкретные преимущества, полученные при создании открытой системы для тестирования военного авиационного оборудования:

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

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

Недостатки открытых систем видны не сразу. И все же они имеются:

• при создании автоматизированной системы на базе открытых решений ответственность за работоспособность системы в целом ложится на системного интегратора, а не на производителя системы. Поэтому при появлении в системе невоспроизводимых отказов некому предъявить претензии, поскольку поставщиков много, а системный интегратор отвечает только за монтаж и пусконаладку системы;
• универсальность всегда находится в противоречии с простотой. Универсальные протоколы, интерфейсы, сети и программное обеспечение, чтобы быть универсальными, должны быть достаточно сложными, следовательно, дорогими и ненадежными. Хотя снижение надежности, вызванное сложностью, компенсируется повышением надежности благодаря большому тиражу и, следовательно, продолжением отладки после начала продаж;
• эффект снижения надежности программного обеспечения, части которого пишутся разными производителями. Когда ПО пишется внутри одной фирмы, можно предвидеть почти все ситуации, которые могут возникнуть на границе между ПО и пользователем или аппаратурой. Если же в этом участвуют несколько разных команд в разных фирмах, между которыми нет взаимодействия, то становится непонятно, кто отвечает за надежность всего комплекса. Кроме того, с ростом числа программистов, участвующих в создании ПО, по законам статистики увеличивается вероятность того, что появится хотя бы один программист, не умеющий писать надежные программы. А этого достаточно, чтобы сделать всю систему ненадежной. Надежность и безопасность открытых систем остаются темами, требующими решения [Wang ];
• иногда к признакам открытости относят открытость исходных кодов. Однако наличие открытых кодов снижает надежность программной системы, поскольку нарушается принцип инкапсуляции, необходимость которого обоснована в идеологии объектно-ориентированного программирования;
• как и любая стандартизация, открытость накладывает ограничения на диапазон возможных технических решений, затрудняя творчество и снижая вероятность появления новых и плодотворных технических решений.

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

1.4. Заключение к главе "Архитектура автоматизированных систем"

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

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

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

Обзор публикаций

В работе [Basso ] описана хорошо опробованная технология для управления в реальном времени через интернет на основе Linux -сервера. Компоненты системы, находящиеся на сервере, предоставляют свои свойства и методы клиентам через интернет, используя удаленный вызов процедур и язык XML . В [Groza ] предложена архитектура распределенной системы управления, основанная на интернете и Java . В [Kapsalis , ]. В предложена открытая архитектура интеллектуального датчика, с идеологией "Plug&Play", основанная на интернет-технологии. Такой датчик может работать с любой аппаратно- программной платформой. В [Neag ] описана открытая архитектура коммерческой системы автоматизированного тестирования и диагностики сложной аппаратуры. Система способна к расширению путем применения аппаратуры других производителей: блоков диагностики, оборудования для выполнения тестов, оборудования для отображения информации, систем накопления результатов тестирования и др. В работе [Xia ] сформулированы требования к открытой модульной архитектуре распределенной системы автоматизации, использующей стандарт IEC 61499 на функциональные блоки для обеспечения интероперабельности подсистем.

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

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

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

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

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

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

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

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

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

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

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

Классификация по степени распределенности

Открытая система - это система, состоящая из компонентов, которые взаимодействуют друг с другом через стандартные интерфейсы.

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

Свойства открытых систем:

Расширяемость/ масштабируемость;

Мобильность (переносимость) - простота переноса информационной системы на любую аппаратно-программную платформу, соответствующую стандартам;

Интероперабельность (способность к взаимодействию с другими системами);

Дружественность к пользователю, в том числе легкая управляемость.

Подход открытых систем обеспечивает преимущества для разного рода ИТ-специалистов. Для пользователя (заказчика) открытые системы обеспечивают:

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

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

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

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

7.4.1.1. Модель взаимосвязи открытых систем (ISO/OSI)

Протокол - набор соглашений, принятый двумя взаимодействующими системами.

Интерфейс - набор соглашений, принятый двумя (или более) взаимодействующими элементами одной системы.

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

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

Модель состоит из семи уровней (рис. 1.).

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

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

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

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

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

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

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

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

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

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

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

История концепции открытых систем начинается с того момента, когда возникла проблема переносимости (мобильности) программ и данных между компьютерами с различной архитектурой. Одним из первых шагов в этом направлении, оказавшим влияние на развитие отечественной вычислительной техники, явилось создание компью­теров серии 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) под­черкнул, что стандарты открытых систем должны играть важнейшую роль при создании информационной инфраструктуры общества. Ве­дется работа по созданию глобальной информационной инфраструк­туры, также основанной на принципах открытых систем.

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

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