С. Тарасенко писал(а):
. В принципе, это могла бы быть и простая фигура "Вывод", но она тоже несовершенна, и это может исправить только автор: со стрелкой должна быть ближняя фиура, тогда она указывает на дальнюю, протыкая её. А здесь дальняя указывает куда-то в сторону, а ближняя в форме квадрата на неё наслаивается, и запросто можно перепутать, где значение, а где приёмник. Владимир Паронджанов предполагал, чтобы в верхней строке фигуры писалось только ключевое слово ("Сообщение" и т.п.), но такие слова именно и засоряют внимание, а вот поважнее было бы указать в ней сам приёмник. Причём приёмником могла бы быть не только переменная, но и файл, и область памяти, и программа, которой передаётся внутреннее сообщение, - всё зависит от ключевого слова перед именем приёмника. В таких случаях знак равенства был бы противопоказан, а вот фигурой "Вывод" или пока хотя бы "Запоминателем" - вполне возможно и притом с прекрасным визуальным эффектом.
Разумею под "приёмником" фигуры "Вывод" порт вывода исполнителя иконы
Вывод (а "значение" относится к величине-источнику в ОП исполнителя). Согласен с недоопределённостью текста этой иконы - см.
в конце этого подпункта.
Поддерживаю, что адрес порта (имя линии, "приклеенное к объекту"), нужно указывать в дракон-программах; согласен с размещением его в непрямоугольном поле иконы.
Под "в принципе" разумею, что Стас хотел бы для общего случая (или в каких-то частных, напр. показывая сдвиг элементов массива) использовать дракон-икону
Вывод, а не гном-икону
Запоминатель, как визуализацию присваивания - что не считаю правильным.
В комментарии к 4-му техтребованию уже предлагал икону
Полка. Эргономически это даёт нужный эффект - следуя по шампуру, мы берём значение из текста верхнего поля-"этажа" (как говорит Стас, ЧТО; точнее говорить ОТКУДА, т.к. это необязательно литерал, т.е. значение "как есть" - чаще это переменная или константа) и помещаем это значение в переменную (набор переменных допустимых типов) по тексту нижнего "этажа" (КУДА; здесь только имена без вариантов).
Для сообщения другой программе есть оператор
Параллельный процесс, работающий "на передачу" из того визуала, где находится - правда, считаю, нужен парный ему, работающий "на приём" в том визуале, где находится - уже говорил об этом
в конце этого подпункта и на форуме.
Для обмена со внешней памятью считаю необходимым ввести отдельные иконы, как показано
в этом подпункте.
Если мы хотим делать "визуальный ассемблер" - тогда, конечно, нужно описывать и пересылки в области памяти по физическим (числовым) адресам. Если же нас интересует гарантоспособный прогязык высокого уровня - то адрес мы должны скрывать за именем величины (притом не изменяя его в интересах герметичности типов), а остальной памятью пусть распоряжается сборщик мусора, как в Обероне - см. также
в этом подпункте при описании типа указатель.
Т.о. адресуемая физически область памяти как приёмник нецелесообразна.
С. Тарасенко писал(а):
В конце концов, для этих целей можно использовать не "Вывод", а "Ввод", но тогда внимание напарывается на противоестественное направление влево. Мы читаем текст слева направо, значит и все указатели должны смотреть направо.
Аналогично предыдущему разумею под "приёмником" фигуры "Ввод" порт ввода. Также как при выводе, смысл оператора ограничен пересылкой, только в обратном направлении - от среды (каким-то образом передающей данные в порт по протоколу ввода) к исполнителю.
"Для этих целей" связываю с 4-м требованием - использовать икону
Ввод, а не Вывод, как визуализацию присваивания для общего случая - что опять же не считаю правильным.
Насчёт компоновки икон
Ввод и
Вывод. Есть одна штука в понимании сопряжения импер- и деклар-моделей, а также исполнителя этих моделей и внешней среды. Проиллюстрирую свой взгляд на примере ФЛОКСа.
Владимир Паронджанов писал(а):
12. Дам еще одно пояснение.
Для этого приведу пример. На стр. 41 указан идентификатор силовой команды
КС1УФ.ОТКЛЮЧИТЬ.ФИДЕР.УМ1
13. На какой объект указывает этот идентификатор?
На этот вопрос следует дать два принципиально разных ответа.
14. С точки зрения прибористов и комплексников этот идентификатор указывает на объект, НАХОДЯЩИЙСЯ ВНЕ КОМПЬЮТЕРА. А именно на команду, которая выскакивает из бортового компьютера Бисер, бежит по проволоке через прибор «устройство обмена» и в конечном итоге попадает в прибор «силовой коммутатор».
Результатом выдачи этой команды является тот факт, что прибор «силовой коммутатор» образует нужный силовой фидер (то есть нужную шину электропитания).
Зачем комплексник выдает эту команду? Чтобы образовать нужный ему фидер питания.
15. С точки зрения программиста дело обстоит совершенно по другому. Программист отлично понимает, что идентификатор указывает на какие-то объекты, находящиеся в оперативной памяти Бисера.
Какие же это объекты?
Ответ не прост.
Чтобы образовать фидер, надо выдать из компьютера не одну команду, а серию посылок по определенной циклограмме.
Эта операция достигается путем сложного взаимодействия программ центрального процессора и программ процессора ввода-вывода (канала ввода-вывода).
Из рисунка на стр. 41 Извлечения следует, что Бисер имеет 8 процессоров ввода-вывода.
IMHO, установлен важный факт: различие между виртуальными объектами алгоритма/программы (как модели переработки данных) и реальными объектами, которые моделируются посредством виртуальных. Это следует из "слоистой" модели архитектуры исполнителя алгоритмов (данные-программы-аппаратура), которую впервые встретил у В.В. Мельникова и развил
во второй части этого подпункта; возможно, она вводилась кем-то и ранее.
Различие есть следствие ведущего принципа второго (программного) слоя этой модели - принципа программного управления: любой программно-недоступный объект для управления физически связан с неким множеством программно-доступных элементов (ПДЭ) субъекта управления, имеющих смысл величин прямой и обратной связи в контуре управления.
Далее некоторые тривиальности. ПДЭ реализованы как порты ввода-вывода, а в основной (адресуемой) памяти (ОП) они дублируются для обработки (память м.б. как оперативной, так и постоянной - всё зависит от способа задания значений; напр, можно брать значение константы или ряд значений переменной из таблицы, хранимой в ПЗУ). Именно для выдачи значений из ОП (загрузки в ОП) и нужно взаимодействие (сложное или простое - зависит от организации ввода-вывода в конкретной архитектуре). Сокрытие же особенностей происходит на верхнем уровне данных - здесь предметник-"комплексник" имеет дело только с портами. Однако "родная" ему система понятий формируется исключительно за счёт осмысленного называния портов (т.е. вводятся аналоги DNS-имён, употребляемые непрограммистами вместо числовых (IP-подобных) адресов портов). Также, как видно из дальнейшего, это нужно ещё и отразить в символической форме в виде надписей, "приклеенных смолой" к физическим цепям портов; т.о. деклар-средства используются не только в модели, но и на моделируемом объекте.Принцип ориентации непрямоугольных полей у Владимира Даниеловича, видимо, исходит из метафоры "вертикаль как представление исполнителя" (вспомним "дракон-поезд", едущий по схеме). Т.о. справа от вертикали визуала, содержащей иконы ввода-вывода, нужно мысленно провести вертикаль, отражающую процесс внешней среды, которым происходит обмен; направленные поля сдвинуты в сторону этой вертикали.
Отсюда ясно, почему эти поля не указывают в одну сторону - при выводе значение идёт от исполнителя вовне, при вводе извне к исполнителю. Так что это я бы не трогал, а вот порядок полей по вертикали для иконы
Вывод можно поменять, чтобы как предлагает Стас, они показывали по ходу чтения шампура сначала источник-ОП, а затем приёмник-порт (для
Ввода нужно сохранить как есть, т.к. порт-источник, а ОП-приёмник).
Кстати, если вводить иконы
Сохранение и
Извлечение, то для них я так и предложил делать...
Отметим, что эта метафора подходит и для построения иконы
Параллельный процесс - только надо взаимодействующую программу представлять уже как вертикаль слева от вертикали рассматриваемого визуала. Возможно, и здесь сдвинутое (уже влево) поле стоило бы сделать направленным - уже на эту вертикаль (а для парной иконы - от неё)...