Понятие открытых систем. Открытая система (теория систем) Основы построения системы стандартов ит

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что же такое открытая система?

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

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

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

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

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

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

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

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

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

Легкость сопряжения одной сети с другой.

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

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

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

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

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

Тарасенко Ф.П. Прикладной системный анализ (наука и искусство решения проблем): Учебник. - Томск; Издательство Томского университета, 2004. ISBN 5-7511-1838-3