К анализу семантики базисных понятий информатики

Берс А.А.
Институт систем информатики им. А. П. Ершова СО РАН

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

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

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

Этот системный анализ опирается на следующие методологические [1,2] принципы:

• рассматриваются ограниченные целостные системы и/или их части;

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

• рассмотрение должно быть конструктивным, т.е. отвечать на один из вопросов: "как этим пользоваться?" или "как это устроено?". Ответ на первый вопрос даёт нам внешнюю спецификацию, объясняя, что это и/или зачем это, а на второй — (проектное) описание, которое объясняет, почему это работает именно так.

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

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

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

Для программного фрагмента можно определить единичное исполнение соответствующим исполнителем в замкнутой операционной обстановке [3]. Оказывается воз­­можным отнести каждое из предписаний ПФ к одному из четырех родов: 1) структурное, явно задающее преемника (ов); 2) команду исполнителя; 3) обращение к объекту; 4) вызов протокола взаимодействия. В соответствии с этим определяется шесть составляющих операционной обстановки: а) программный фрагмент, б) исполнитель, в) перечень доступных объектов, г) перечень доступных протоколов, д) рабочая область для исполнителя, е) сигналы, связывающие исполнителя с внешним миром.

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

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

Внутри обстановки исполнение каждого предписания ПФ является элементарной деятельностью и продвигает внутреннее время исполнения на один t-акт. Кроме полной формы обстановки, далее называемой Е-ка (читается "ешка" — от Environment и в честь А. П. Ершова), полезно рассматривать усеченные формы, такие как: L-ка (не нуждающихся в объектах и протоколах), С-ка (без внешних протоколов) и т.п.

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

Упоминаемые в перечнях объекты и протоколы, являются внешними по отношению к обстановке, существующими и до начала единичного исполнения.

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

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

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

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

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

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

Заметим, что при обсуждении семантики программ почти всегда упускают из виду, что все программные конструкции суть системы знаков, и находятся в особенном знаковом мире. Однако еще в 1960 г. в работах Московского методологического кружка было показано [см. 3, 156-196], что свойства и связи вещей (т.е. отдельных целостностей реального мира) не только не совпадают со свойствами и связями их образов в знаковом мире — объектов, но и не являются их параллельным (изоморфным) отображением. Кроме того правила работы со знаками позволяют получать новые знаки, обозначающие знаковые формы, и для которых уже нет вещного соответствия в реальном мире. Важным примером такого знака может служить указатель — объект, обеспечивающий косвенную адресацию.

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

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

      I.     Всякое единичное исполнение должно завершаться;

    II.     Целостность и корректность доступов должны обеспечиваться;

  III.     При обращении к объекту для записи всякий другой доступ должен быть запрещен.

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

Известно сколько неприятностей причиняет так называемый "побочный эффект", имен­но поэтому при определении операционных обстановок столько внимания было уделено различным аспектам их замкнутости. Для объекта в отсутствие обращений его состояние не изменяется, однако при обращении всегда возможно изменение его состояния, что и отмечалось ранее как эффект соответствующего рода предписаний. Скажем, что объект информационно замкнут, если при обращениях к нему не могут измениться состояния ни в каких других объектах. Рассмотрим следствия замкнутости объектов. Во-первых, никакие объекты не могут иметь общие подобъекты, во-вторых, подобъект не может быть объектом, а в-третьих, ни один из методов объекта не может обращаться к какому-либо другому объекту. Такой перечень ограничений выглядит страшновато — список не объект, строка матрицы не объект, и экземпляр класса C++, со статическими объявлениями — тоже не объект. Однако если разобраться то окажется, что всё так и должно быть. Состояния подобъектов объекта суть части его состояния и отражены в его домене, а потому подобъекты несамостоятельны, и понятие замкнутости для них вводить не нужно. Все сразу станет ясным, если признать, что объектность — это статус, и что объект — понятие относительное, что он существует не вообще, а как объект в некотором подпространстве. Я считаю, что объекты должны быть замкнутыми, а средства объектно-ориентированных систем — подправлены.

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

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

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

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

Итак все предыдущее предполагало, что для выполнения некоторой конкретной деятельности берется реализующий её программный фрагмент, операционная обстановка для него и происходит требуемое единичное исполнение, осуществляемое активным исполнителем. Понятно, что содержание обстановки должно быть согласовано с содержанием программного фрагмента, а последний с возможностями исполнителя. Чтобы отчетливее представить, что за что отвечает, рассмотрим еще две усеченные формы операционной обстановки: X-ку — без исполнителя и F-ку — без программного фрагмента. X-ка, которая может также быть названа оболочкой операционной обстановки — это её статическая часть, которая может быть заранее построена (в той или иной степени готовности) системой программирования (с учетом её запасов готовых решений) по исходному тексту ПФ и спецификациям деятельности. При этом формируются перечни требуемых объектов и протоколов, определяется объем рабочей области с учетом типа необходимого исполнителя. Чтобы оценить роль F-ки зададимся на первый взгляд странным вопросом: "Что делает в операционной обстановке, сформированной для обеспечения единичного исполнения данного программного фрагмента, этот самый ПФ?". Хорошо подумав, найдем не менее парадоксальный ответ: "Мешает работать исполнителю!". Действительно, вполне возможно, что в обстановке запасены возможности работать с множеством объектов и протоколов, исполнитель снабжен богатым репертуаром команд, и из всего этого спектра ПФ вырезает тонкую единственную тропу, потому что в нем больше ничего не предусмотрено. Другими словами, сама F-ка представляет собой исполнитель с большими возможностями, чем исполнитель, входящий в неё в качестве активного элемента.

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

В свете сказанного выше рассмотрим диаграмму с двумя вершинами и связывающими их ребрами, на которых нет пометок. Будем считать, что эта диаграмма представляет систему с двумя состояниями, самостоятельно сменяющими друг друга, и назовем её "Тик-так" или активатор-1. Реальную вещь с такими свойствами легко построить из двух транзисторов и малого числа пассивных  элементов, — конденсаторов и сопротивлений, и называется она — мультивибратор. Со знаковым миром её онтологический образ, который я буду называть субъект, придется связать как новую независимую элементарную сущность. Далее, имея Тик-так, можно построить активатор-2, у которого тоже будет два состояния: первое "взять предписание из ПФ", а второе "исполнить предписание". Его детальное проектирование и постройку можно поручить фирме Intel, которая легко с этим справится.

Активатор-2 избавит нас от необходимости рисовать диаграммы состояний для сложных систем, так как известно, что любую из них можно заменить его продвижением по некоторому программному фрагменту. Более того, у нас уже почти есть исполнитель для операционных обстановок. Посмотрим еще раз на диаграмму активатора-2, но сосредоточимся на сей раз на интерпретации её стрелок, с помощью которых представляются переходы между состояниями. Назовем стрелку, выходящую из состояния S₀, стрелкой "выполнить", а стрелку, выходящую из состояния S₁, стрелкой "взять". Будем рассматривать каждую из них как предписание осуществить указанную конкретную деятельность. Представляемый таким образом субъект назовем активатор-3. Чтобы не путать новую интерпретацию со старой будем изображать стрелки этого субъекта с внутренними (активизирующими) предписаниями светлыми. Но если светлая стрелка есть предписание "выполнить", то можно заготовить некоторый ПФ для активатора-2 и запустить для его единичного исполнения (в качестве реализации этого предписания) соответствующую L-ку. Таким образом, исполнение команды уже можно представлять, состоящим из нескольких шагов, например, проверить, нет ли внешнего сигнала и, если есть, то исполнить предписание по реакции на него, а иначе обрабатывать выбранную команду и т.п. Логика дальнейшего расширения репертуара возможностей исполнителей более или менее очевидна.

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

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

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

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

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

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

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

Литература:

[1] Щедровицкий Г. П. Избранные труды. Москва, 1995.

[2] Берс А. А., Об объектной ориентации и организации архитектуры программных систем. // Актуальные вопросы технологии программирования, Л. 1989, 4-15.

[3] Берс А. А., Операционная обстановка высокого уровня. // Сибирская конференция по прикладной и индустриальной математике, Том 1 , Н., 1997, 18-30.

Ваши комментарии

[Головная страница] [Конференции] [СО РАН]

© 2001, Сибирское отделение Российской академии наук, Новосибирск
© 2001, Объединенный институт информатики СО РАН, Новосибирск
© 2001, Институт вычислительных технологий СО РАН, Новосибирск
© 2001, Институт систем информатики СО РАН, Новосибирск
© 2001, Институт математики СО РАН, Новосибирск
© 2001, Институт цитологии и генетики СО РАН, Новосибирск
© 2001, Институт вычислительной математики и математической геофизики СО РАН, Новосибирск
© 2001, Новосибирский государственный университет
Дата последней модификации Sunday, 09-Sep-2001 17:09:20 NOVST