Реальное время и реальная среда исполнения визуала. Виопы Ввод и Вывод

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

Как известно, искусственные исполнители алгоритмов в их современном виде (дискретные автоматические программируемые информашины) были описаны и созданы (по крайней мере, в англосаксонском мире) в 1940-е годы для ускорения решения ряда военных задач: вскрытия шифров, физических расчётов по атомному проекту, вычислений для управления огнём зенитной артиллерии (УАЗО). Именно реализацию исполнителя для третьего вида задач удобно рассмотреть; вначале дадим её сжатую словесную формулировку.

Основная задача УАЗО – вычисление упреждения, т.е. намеренного отклонения линии прицеливания от направления выстрела, проходящего через т.н. точку встречи. В эту точку нужно наводить орудие, чтобы его снаряд, летящий по известной траектории, встретился с движущейся целью через конечное время полёта (нелинейно пропорциональное дальности); прибор-взрыватель подрывает снаряд при прохождении пути, равного дальности до цели в момент выстрела (устанавливаемого перед этим) или приближении к цели на заданное расстояние (непрерывно определяемое в полёте). Считаются известными текущие курс и скорость цели, дальность до неё и метеоусловия, также влияющие на движение снаряда; они получаются с измерительных приборов (локатора, метеостанции и т.п.). По ним определяется расчётная точка встречи, а по ней искомый результат – величины поправок на упреждение (насколько надо «сбить» прицел орудия по азимуту и по углу места). Орудие (батарею) наводят относительно прицельной линии (положения прицела, которым человек-наводчик "ведёт" цель). Прицел обычно связан с механизмами наводки.

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

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

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

Другой пример. Информашину можно поставить у орудия (точнее, на батарее), вводить в неё исходные данные и сразу получать поправки; имеем т.н. прибор УАЗО (ПУАЗО). При этом работа расчёта проще в том отношении, что данные не надо интерполировать, можно также заложить в матмодель индивидуальные особенности орудия; но ПУАЗО должен работать в реальном времени – летящая цель ждать не будет. Среда же для искусственного исполнителя не становится реальной – его данные для решения задачи по-прежнему использует другой исполнитель (в данном случае человек).

Третий пример. Будем вводить в связь прицела с механизмами наводки также поправки с выходов ПУАЗО; т.о. для него эти механизмы станут исполнительными и у информашины образуется реальная среда управления (здесь – разомкнутого).

Информашину можно подключить также и к источникам исходных данных о цели, замкнув контур управления; так получим т.н. станцию орудийной наводки (СОН). Здесь меняется сам подход к задаче для искусственного исполнителя, а значит и к моделированию и формализации – цель обрабатывается киберсистемой «СОН-орудие», испускающей рабочее тело – поток снарядов. Ограниченное решение задачи предполагает, что рабочее тело стремится к текущему местоположению цели с заданной погрешностью. Полное решение предполагает, что заданный расход рабочего тела вызывает прекращение движения цели в сторону прикрываемого объекта (в результате её поражения или выхода из боя). Человек выводится из контура управления на более высокий уровень – теперь он не наводит орудие, а указывает цели и время от времени меняет те или иные условия решения задачи (напр., допустимый расход снарядов).

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

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

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

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

В визуале, чтобы подать сигнал вовне, значение выводится оператором Д14. Однако возникает вопрос: откуда и куда? Если предположить, что память выводимой величины физически связана со средой, то её значение и так постоянно транслируется объекту, но это явно не совсем то, что мы хотим; исходя из здравого смысла, нужно отдельно вычислять значения, а отдельно использовать их. То же справедливо и для констант.

Устройство реального исполнителя (информашины) предполагает, что под именем величины при присваивании фигурирует область основной (оперативной) памяти, а при выводе (и вводе) – отдельная область-порт ввода-вывода. Значение переменной (или константы) из числа ИмяВывВел в операторе Вывод, при выполнении этого оператора переписывается в нужный порт; именно тогда новое значение становится доступно во внешней среде, а до тех пор доступно значение, выведенное в порт ранее. То же относится и ко вводу: значение из внешней среды поступает в порт, а при выполнении вершины Ввод передаётся в область конкретной переменной из числа ИмяВвПер; как бы ни менялось входное значение, алгоритм будет работать с переданным до нового ввода. Так реализуется отделение обработки данных от обмена ими со внешней средой; понятно, что при наличии внешнего управления возможен конфликт за порт, разрешаемый дополнительными средствами исполнителя.

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

Отметим, что у Паронджанова фактически предлагается неявно указывать общее направление (категорию устройств) ввода-вывода в развёрнутом названии оператора (на верхнем этаже виопов Д14,15); так, в /1, рис.83/ название Выдать команду фактически указывает на порты управления, а в /1, рис.92/ названия Запрос и Сообщение указывают на порты консоли оператора.

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

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

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

Один из способов описания – синтаксические диаграммы операций. Далее показаны диаграммы ввода и вывода, заданные для отечественного учебного прогязыка Робик¹.

Примеры синтаксиса операций ввода и вывода

Эти схемы сжато отражают основные случаи обмена со внешней средой.

Видно, что изображение не слишком читабельно из-за того, что «втиснуто» в ширину страницы при вёрстке.

Определение языка синтдиаграмм приведено в п/р 5.2 Приложения 2. Оно отличается от использованного на схемах; в первую очередь введены строгие правила размещения синтдиаграмм на диосцене, исключающие «слепление» соединений и разветвлений. Длинные тела диаграмм переносятся аналогично строкам текста (имея в виду, что диаграмма и есть инвариантная запись некоего текста, обобщающая все варианты его содержания); ломаные линии переноса могут пересекаться для нескольких путей.

Можно изображать синтдиаграммы и по-другому, если воспользоваться возможностями ДРАКОНа; нужны только дополнения, предложенные в п/п 2.1.3.12.

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

1. Все перечисленные величины передаются разом; для различения мы устанавливаем порядок их следования, как написано в тексте виопа (из этого исходят алгоритмы передачи и приёма данных).

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

2. Предполагается, что внешняя сущность всегда готова ко взаимодействию с исполнителем; это значит, что приём оповещения о выводе (запроса на ввод) прерывает текущие алгопроцессы внешней сущности.

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

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

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

Протокольное описание относится ко вспомогательным средствам моделирования: ПД-схемы не содержат полных и целостных сведений о моделируемой деятельности.

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

С учётом сказанного о значении операторов, их определения имеют следующий вид:

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

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

Именно так изначально предложено сделать для виопов Сохранение и Извлечение.

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

Т.о. формально мы не можем описать эту процедуру одним виопом; мы и будем делать иначе.

Это видно и на диаграммах протоколов; если переходы между сущностями для вывода сонаправлены, то для ввода – противонаправлены, т.е. имеют место разные операции.

1 Звенигородский Г.А. Первые уроки программирования. – Новосибирск: Наука, 1985. – с. .

2 Много примеров этому можно найти, напр., в работе: Хаусли Т. Системы передачи и телеобработки данных. – М.:Радио и связь, 1994.

3 Более или менее «формальна» эта система по определению, чем исполнитель визуала – неважно, главное, чтобы она придерживалась тех же правил обмена.