Исполненные смысла тексты

Вначале были две сущности, на которых строились вычислительные машины: операции, преобразующие и выдающие значения, и элементы памяти, хранящие значение в своём состоянии. Работа же программиста заключалась в составлении программ составленных из предписаний, объединяющих указанные сущности и определяющих порядок их исполнения [1].

На грани 50-х и 60-х годов прошлого века произошла смена парадигмы применения вычислительных машин – составление программы для машины заменилось на выражение программы в некотором языке (высокого уровня). Использование внутренне присущих языкам средств свертки, во-первых, сделало программы более наглядными, а во-вторых, позволило проектировать всё более сложные системы. Образованный в это время Отдел программирования внёс заметный вклад [2] и в эту смену парадигмы.

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

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

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

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

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

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

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

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

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

Категорная пара: интерпретация–трансляция описывает следующее важное различение модусов исполнения. Интерпретация может и использует текущие значения знаков программного текста, а трансляция – нет. Именно для обслуживания трансляции появились понятия тип и описание в языках программирования. Разработанная А. П. Ершовым концепция смешанных вычислений [3] внесла полную ясность в этом направлении. Поскольку часть представленной в программе информации отрабатывается в ходе её трансляции, мы можем говорить об исходной форме программы и её исполнимой части, которую можно представить [4] как совокупность составленных из предписаний программных фрагментов, вызываемых один из другого.

Далее текст сопровождается двумя рисунками — «вызовы фрагментов» и «операционная обстановка».

Корректное (т.е. предусмотренное программистом) исполнение программного фрагмента требует соблюдения определённых условий, которые могут быть выражены в виде операционной обстановки (высокого уровня) [5]. Можно определить понятие единичного исполнения конкретного программного фрагмента в заданной обстановке.

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

• Всякое единичное исполнение, будучи инициировано, всегда завершается;

• Всякий доступ сохраняет корректность связи к значению;

• Невозможно одновременное изменение состояния разными процессами.

• Обращение к объекту может изменить состояние только этого объекта.

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

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

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

Любое предписание может быть отнесено к одному из четырёх родов:

• структурные – изменяющие порядок исполнения по сравнению с линейным порядком записи предписаний в программном фрагменте;

• команды исполнителя, которые он «сам знает, как исполнить»;

• обращение к объектам, предусмотренным в перечне в обстановке;

• обращение к протоколам организации взаимодействия с объектами (подробности будут разъяснены ниже).

Предписания в общем случае характеризуются следующими шестью атрибутами:

• исполняемой функцией;

• значениями доступов к аргументам;

• значением-результатом, если оно предусмотрено;

• эффектом, т.е. остающимся после исполнения изменением состояния затронутых объектов;

• целеуказанием на реализующий предписание программный фрагмент;

• смыслом, которым является само исполнение предписания.

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

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

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

Предыдущие два абзаца сопровождаются картинкой «интерфейс»

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

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

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

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

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

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

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

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

Ещё две картинки «сигналы» («программный объект», «перечень протоколов» и «перечень объектов»)

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

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

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

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

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

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

Однако вполне может оказаться, что предъявляемый для исполнения программный фрагмент сможет быть исполнен (а значит – понят) и в некоторой другой обстановке, а значит, будет иметь смысл и в ней. Только смысл может быть будет другой: «всякая обстановка создаёт при исполнении смысл в меру своего наполнения».

Вот и сейчас: я прочел доклад, а каков его смысл, каждый слушавший придумал сам. А вы говорите: «интеллектуальная собственность»…

Список литературы

Уилкс М., Уиллер Д., Гилл С. Составление программ для электронных счетных машин. М.: Изд-во иностранной литературы, 1953.
АЛЬФА – система автоматизации программирования: Сб науч труд. / Под ред. А. П. Ершова. – Новосибирск: Наука. Сиб отд-ние, 1967.
Ершов А. П. Об одном теоретическом принципе системного программирования // Докл. АН СССР – 1977. т. 233, № 2.
Берс А. А. К анализу семантики базисных понятий информатики // Конференция, посвященная 90-летию со дня рождения А.А.Ляпунова. – Новосибирск. ИВТ СО РАН, 2001.
Берс А. А. Операционная обстановка высокого уровня. //Сибирская конференция по прикладной и индустриальной математике, Том 1, - Новосибирск, 1997

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

Берс А.А.

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

Аннотация

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

Abstract.

The analysis of a system of basic notions of computer science is considered. Semantics of the basic notions and their connections is analyzed treating program execution as ontology of concrete activity. Strong significance of an information closure of basic notions and constructions is underlined, as valuable both for system analysis and construction. The indispensable conditions are formulated, which violation reduces in loss of serviceability of computer systems ("three sacred cows of computer science"). The corollaries, splinterings and improvements are given. The importance of notions relativity is discussed. The boundary of notion "programming" is defined more precisely.

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

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

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

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

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

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

годы ведущая парадигма и основные понятия

50-е Составление программ для ЭВМ (адресность, управление, подпрограммы, микропрограммирование);

60-е Выражение задачи "наЯВУ"* (языки, их основные структуры, описания и типы данных, блочность и модульность, трансляторы и интерпретаторы);

70-е Обеспечение эффективного использования ЭВМ (операционные системы, базы данных, прерывания, страничная и сегментная организация, кэширование, параллельность);

80-е Объектная ориентированность (объекты, сообщения, управление потоком данных и по событиям);

90-е Сеть, системы "клиент-сервер" (активные компоненты, асинхронные взаимодействия, распределенная обработка).

*на языке высокого уровня (формулировка А. П. Ершова)

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

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

http://www.ict.nsc.ru/ws/Lyap2001/2199/image002.jpg

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

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

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

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

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

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

http://www.ict.nsc.ru/ws/Lyap2001/2199/image004.jpg

http://www.ict.nsc.ru/ws/Lyap2001/2199/image006.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://www.ict.nsc.ru/ws/Lyap2001/2199/image008.jpg

http://www.ict.nsc.ru/ws/Lyap2001/2199/image010.jpg

http://www.ict.nsc.ru/ws/Lyap2001/2199/image012.jpg

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

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

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

http://www.ict.nsc.ru/ws/Lyap2001/2199/image014.jpg

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

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

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

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

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

Литература:

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

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

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