Приложение 4.
КАТАЛОГ ПРИМЕРОВ ВИЗУАЛИЗАЦИИ

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

Здесь даны примеры визуализации импер-знаний на техноязыке и других типов знаний на иных языках, рассмотренных в документе. В каждом примере используется ряд языков.

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

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

Рассмотрим решение учебно-производственной задачи в «жёстком» реальном времени. Это реальная разработка (дипломное проектирование) автора; здесь она представлена выборочно и дополнена вопросами визуализации.

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

Пусть нужно контролировать состояние в различных точках распределённого объекта с одного рабочего места (поста); исполнителем верхнего уровня является человек. Состояние представляет ряд однородных параметров, измеряемых датчиками; каждой КТ соответствует 1 датчик. Выход датчика двузначный со смыслами, допустим, «норма/отклонение». Физически это м.б. двухпозиционный контакт с состояниями «замкнуто/разомкнуто».

Также каждой контрольной точке (КТ) приписан статус со значениями «активный/пассивный»; смысл – известное исполнителю задачи из других источников состояние части объекта, включающей данную КТ (допустим, «в работе/на техобслуживании»). Состояние каждого датчика должно отображаться в зависимости от текущего статуса КТ.

КТ образуют компактные группы переменного размера (допустим, в силу того, что объект состоит из агрегатов); предельное число КТ (и значит, датчиков) в группе – 8. Предельное число групп – 50; также известно предельное удаление групп друг от друга (в т.ч. по возможным маршрутам прокладки коммуникаций).

Период опроса датчиков связан с динамикой состояния объекта. Принято минимальное время изменения состояния 1 с; применив теорему Котельникова аналогично другим задачам дискретизации, получаем максимальный интервал опроса датчиков 0,5 с.

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

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

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

Общая идея решения очевидна – включить между оператором и датчиками косавт, кторый будем называть дискретной системой контроля ДСК.

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

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

Найдено (при патентном поиске) апробированное решение по сбору данных с КТ, требующее минимального числа линий связи с датчиками. Оно реализовано как сеть сбора СтСб данных в виде узлов контроля УК, соединённых линиями связи в кольцо; контроллер датчиков КД служит ведущим узлом сети.

По постановке задачи была составлена функциональная модель ФМ работы ДСК.

Функциональная модель задачи (декомпозиция контекста)

Функциональная модель задачи (декомпозиция функции А4)

Видно, что ФМ имеет два уровня декомпозиции, причём второй лишь для одной функции первого уровня; такой объём в данном случае достаточен, т.к. основная разработка должна касаться алгоритма решения и его технической реализации (состава и свойств узлов ДСК).

В декомпозиции контекста был использован стиль моделирования, в настоящее время называемый «объёмным» и безусловно рекомендуемый для ФМ оргсистем. Его сущность в том, что в модель обязательно вводится функция управления, генерирующая управляющие ограничения (дуги) для остальных функций и получающая от них входные ограничения состояния. Т.о. ФМ отражает природу моделируемой системы как кибернетической¹.

Декомпозиция функции А4 определяет преобразование исходных данных в результатные и служит связующим звеном для перехода к частному моделированию решения (императивному, декларативному, активному). Фактически получена частная структурно-топологическая (СТ) схема отдельных рабочих трактов исполнителя.

Далее м.б. составлена общая СТ-схема (здесь не показана), из которой определяются тракты переработки (в данном случае только данных); в реальности она не составлялась. Эти результаты используются для проектирования структуры средств решения задачи.

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

Структурная схема механизма (человеко-машинной системы) показана в ГЧ.

Структурная схема механизма решения задачи

По классу формализуемых частных знаний это актив-схема. На ней дано соответствие блоков ДСК функциям ФМ (в скобках), а также показано вхождение ПДЭ в блоки.

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

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

Полученные данные позволили разработать алгоритм работы ДСК (на псевдокоде и в блок-схеме) и программу на языке Ассемблер Интел МК51.

Здесь алгоритм визуализирован как эскиз дракон-программы работы ДСК на техноязыке ДРАКОН-2 (с авторскими расширениями – как общезначимыми, описанными в п. 2.1.3, так и специфическими для задач данного типа, описанными ниже), см. кадр 1 диофильма в ГЧ:

Алгоритмическая модель задачи (дракон-руководство, кадр 1)

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

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

Исходя из этого, построена дракон-инструкция, показанная в ГЧ (см. кадр 2 диофильма).

Алгоритмическая модель задачи (дракон-руководство, кадр 2)

Ряд элементов работы оператора оформлен как параллельные процессы; в то же время имеется и процесс-вставка (алгопроцедура).

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

Можно говорить о реальном (и даже о «жёстко» реальном) времени решения, т.к. с исполнителем решения связан реальный объект, динамика которого учитывается в алгоритмах. В то же время в терминах п/п 1.4.2.2 для дракон-программы время условное – имеем один процесс на одного исполнителя, полностью использующий его ресурсы.

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

В схемах операторы техноязыка модифицированы в соответствии с п. 2.1.3. В частности, добавлена парная иконе И20 икона Сообщение от процесса. По расширенному алфавиту она должна иметь индекс Д28; однако имеет смысл переставить иконы после Д20, чтобы однотипные иконы стояли рядом. Графика этих икон модифицирована. Для присваивания использована икона Действие, а не Полка, чтобы сэкономить высоту шампура.

Дракон-руководство принципиально является дракон-моделью, т.к. должно содержать отдельные процессы для человека и машины. Однако не любая дракон-модель является дракон-руководством; допустим, в /1/ приведены как раз примеры иного рода.

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

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

Видно, что рабочий цикл организован как гнездо циклов ДЛЯ (с параметром). Это обусловлено организацией ПДЭ в ДСК – длина слова ОЭВМ (и других БИС) равна 8 бит, а число КТ на ГКП – 64 ( каждый ГКП выполнен на базе одной БИС КВВ и обслуживает для каждой КТ датчик статуса и индикаторы Актив и Пассив на компас-табло). Поэтому внешним является цикл по ГКП. В его теле сначала из сети сбора в ОЗУ данных ОЭВМ КД накапливается до 64 бит данных состояния датчиков в цикле опроса (для последнего ГКП это число переменное в зависимости от общего числа КТ в системе), а затем в цикле обработки-отображения эти данные и данные из ГКП формируют (уже побайтно) новые значения Актив и Пассив, которые пересылаются в ГКП и становятся текущими отображаемыми. Обработка реализует логику декомпозиции функции А4; в качестве предыдущих данных естественно используются значения, считываемые перед обработкой целевой информации из ОЗУО в БИС КВВ текущего ГКП.

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

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

Отметим эффективное использование площади диосцены дракон-схемами; дракон-программа занимает неполный лист А2, как и текстовое описание (псевдокод двух уровней детализации с комментариями и «лирические отступления» относительно смысла ключевых условий маршрутизации), оформленное по ЕСКД (через 1,5 интервала ЭПШ кегля 14, примерно соответствующего по высоте литерам машинописи). При этом на схему в сравнении с текстом накладываются дополнительные ограничения компоновки в ячейки, а на текст икон – в замкнутые поля с учётом внутренних и внешних отступов. Данных же дракон-программа содержит больше, чем текст; она фиксирует и укрупнённую структуру алгоритма (заданную первым псевдокодом), и детальную, и точные формулировки условий в тексте развилок (понятные без объяснений) – а кроме того, в ней даны определения элементов данных и некоторые дополнительные пояснения (в иконах КогниСтиль), текст икон расширен, да и ряд действий прописан детальнее, чем в псевдокоде.

Дракон-инструкцию оказалось возможным скомпоновать в ячейки А4 только так, что ветка Работа с системой (реализующая основной режим решения задачи) встала правее ветки Работа без системы (реализующей запасной режим), т.е. нарушился логический порядок. Однако наличие веточных циклов дало возможность через назначение их индексов показать логику – основной ветке дан индекс 1, а запасной – 2.

Для рациональной компоновки на листе в дракон-программе введена «ступенька» (в первом звене шампура ветки Продолжение цикла обслуживания ГКП); само звено растянуто по высоте. Можно видеть, что это не ухудшает читаемость схемы (хотя у разных читателей м.б. своё мнение :)).

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

Функциональная модель задачи не вполне увязана со структурной схемой решения и с дракон-руководством. Это следствие того, что в исходном проекте использовался т.н. «несистемный» стиль ФМ, когда контекст включает только блок задачи без внешней среды; на тот момент автору было неизвестно о системном стиле².

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

В ветке Работа с системой дракон-инструкции формулировки условий запуска параллельных процессов – это, конечно, где-то лирика, но она соответствует природе исполнителя-человека. Попытка же уточнить их до «машинной строгости» с использованием механизмов паузы – как делалось в программе – может оказаться «формализацией ради формализации», а её результат – малопонятным реальному читателю документа, неспециалисту в ИТ. А вот таймер здесь подошёл бы – только надо использовать его значение не через боковики Пуск по таймеру, а непосредственно в условии развилки «Есть время на тек. обновление статуса ?», которое тем самым информатизуется.

В основном модуле Работа с системой (веточном цикле) вспомогательное действие Уточнить статус КТ оформлено параллельным процессом, который управляется «триггерно» по условию наличия времени. Т.к. первым в ветке всегда идёт основное действие Реагировать (вставка), то по введённой дисциплине этого достаточно.

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

Логика работы с системой «хромает» и ещё в одном отношении. Работа оператора зависит от результатов самотестирования ДСК; это показано сложным ветвлением по СобТест в конце ветки. Однако зависимость на самом деле более общая: мы вправе считать, что при возникновении события теста все отображаемые оператору данные недостоверны (в частности, если имеет место событие ошибки распределения, т.е. выборки датчика для опроса). Поэтому логично начинать цикл с ветвления по СобТест.

Вообще же проверку СобТест следует ввести в каждый процесс работы с системой; поэтому имеет смысл выделить эту часть во вставку.

Кроме того, этой проверке предшествует действие Уточнить статус КТ, время выполнения которого не лимитировано. Надо переписать алгоритм этого процесса так, чтобы продолжительность выполнения стала конечной, т.е. без «зацикливания»; при этом окончание должно также зависеть от времени по таймеру.

Все изменения м.б. оформлены как вариант ветки в иконе Область.

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

Если допустить, что оператор исполняет одновременно более одного процесса (как Юлий Цезарь :)), то возникнут другие вопросы. Так, процесс Уточнить статус КТ не завершится и будет отвлекать ресурсы исполнителя-оператора; нужна будет количественная оценка, насколько это допустимо. В этом случае в процесс Реагировать можно ввести оператор останова уточнения статуса. Он показан как содержимое иконы Область; место вставки обозначено на схеме такой же иконой с совпадающим индексом. Однако нужны более глубокие изменения; следует построить логику исполнения заново, для доказательности привлекая темпоральную (временную) логику.

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

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

Рассмотренная задача потребовала корректив «классической» ДРАКОН-МФЗ. Их описание начнём с расширений техноязыка, необходимость которых возникла при визуализации.

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

Понятно, что теоретически возможен и совмещённый ввод-приём сообщения процессом-адресатом; в данной задаче такая ситуация не встречается.

Оператор получает данные контроля от ДСК асинхронно; из-за разброса длительности циклов его работы моменты считывания показаний с пульта ДСК не привязаны к каким-то конкретным циклам контроля (длительность которых к тому же много меньше циклов работы с ДСК; по результатам проектирования она составила ок. 0,05с).

Также при визуализации данной задачи выявлены неявные взаимодействия процессов.

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

Неявные сообщения процессу показаны как варианты икон с изменённой формой направленного поля в соответствии с п/п 2.1.3.7.

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

Операторы неявного сообщения даны в разных формах графики для сравнения и выбора лучшего варианта.

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

Видно, что в одинаковых операторах в одном случае текст м.б. записан так, а в другом – иначе. Это связано с поиском лучшего синтаксиса текстов дракон-программ.

Наконец, использованы типы, отражающие аппаратное представление данных. В первую очередь это тип БИТ. Его свойства обусловлены возможностью ОЭВМ обращаться к отдельным битам ячеек своей памяти данных (регистров, ОЗУ).

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

В самом деле, пусть значение константы байтовое. Директива отведения под него памяти кодируется как команда загрузки в регистр (ячейку ОЗУ), адрес которой будет фигурировать в командах, использующих значение; можно принять код команды также байтовым (для МК51). Непосредственное значение будет указано в команде вместо этого адреса; тем самым экономим и в тексте, и в коде команду загрузки (когда значение такой же длины, как код адреса). Если значение длиннее адреса, то экономия объёма кода «съедается», но всё равно текст без лишней команды короче и читабельнее³. Однако адрес может оказаться длиннее (напр. двухбайтовым), и тогда экономия, напротив, растёт.

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

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

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

Визуальное ассемблирование данной в примере дракон-программы можно провести и по «областной» технологии, если располагать подходящим редактором. На схеме программы показаны детализируемые иконы; для каждой из них составляется схема-лиоформа. Далее в зависимости от возможностей дракон-системы (см. п/р 4.4) редактор кодирует схему либо в системе команд, либо на прогязыке.

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

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

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

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

Назначать физические адреса может схемотехник независимо от программиста – если дракон-программа и актив-схема реализованы как часть единой модели задачи, то при трансляции среда моделирования сама подставит адреса. В то же время программист может, скажем, давать имена ПДЭ – и при их переименовании в программе автоматически изменения распространятся на актив-схему.

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

Почему именно эти иконы? Для границ цикла ДЛЯ ответ очевиден, если посмотреть на их представление в п. 2.2.3 – каждой соответствует более одного оператора и равно – машинной команды. Иконы Пауза кодируются так же как цикл ЖДАТЬ – командой УП на саму себя (если цикл с пустым телом) либо на вставленную перед ней т.н. холостую команду. Если же говорить о командах вывода, то детализации требуют те, которые выводят меньше данных, чем предусмотрено режимом обмена с периферийными БИС (в данной системе – по 4 бит в РгКС1,2 ППА и по 8 бит в остальные порты) – в этом случае, чтобы не затрагивать другие разряды, нужно выполнить цепочку команд «чтение(слова из порта)-модификация(отдельных разрядов)-запись(слова в порт)», используя возможность ОЭВМ работать с битами в своём ОЗУ.

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

Для примера мы можем показать «визуальное ассемблирование» иконы Пауза по принципам, заданным в п/р 4.4. Мнемоники команд здесь условные, не обязательно совпадающие с ассемблером конкретной машины.

Визуализация машинного кода иконы Пауза (пример)

Как и ранее, индекс i – это порядковый номер вхождения конструкции в схему.

Пауза на ассемблере детализирована как цикл ДО, в теле которого декрементируется регистр-счётчик проходов (в сущности, это цикл с параметром). Условие цикла – переход, если счётчик не равен нулю – машинная команда (ПЕРеход, если НЕ Ноль <в таком-то регистре>). Команда визуализирована макроиконой из развилки и адреса на побочном выходе. Вход в цикл визуализирован как икона Имя ветки, служащая меткой для иконы Адрес в составе макроиконы-команды ветвления. Видно, что при ассемблировании эта метка ставится в строке той команды, перед которой стоит икона; при получении же исполняемого кода вычисляется адрес помеченной команды и записывается везде, где стоит имя ветки с тем же текстом.

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

Загрузка же регистра константы (непосредственным значением, которое здесь обозначено <X>) есть не что иное, как реализация объявления этой константы (что и показано как запись в иконе Полка); конечно, эта операция не относится собственно к паузе.

Т.к. побочная вертикаль здесь пустая, то выкладка конструкции в лиоформу возможна единственным образом, что и показано в ассемблерном тексте.

Ещё один вариант детализации построен в предположении, что в системе команд есть сложная команда (ДЕКремент и ПЕРеход, если НЕ Ноль <в таком-то регистре>). Здесь ДО-подтело цикла пустое, поэтому условный переход происходит на саму команду УП (по адресу её начальной ячейки).

Безусловный переход здесь показан, как и ранее, форматом линии, отличным от естественного.

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

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

Исходная постановка задачи (с текстовым алгоритмом) также была предложена автором для визуализации группе непрофессионалов (студентов-заочников). Интересно рассмотреть результаты этого эксперимента. Для этого предлагается построенная одной из бригад (наиболее близкой к заданию) схема (в оригинале оформлялась сочинителями вручную на бумаге также по «ячеечному» принципу).

Дракон-программа работы ДСК (непрофессиональная)

При этом следует не упускать из виду условий, в которых выполнялось задание:

Задание состояло в визуализации псевдокода «как есть» на «классическом» ДРАКОНе-2; поэтому тексты икон максимально повторяют псевдокод, и это не ошибка. Также величины не требовалось типизировать и определять, поскольку исходным стандартом техноязыка это не предусмотрено (Паронджанов предлагал выносить деклар-часть отдельно от схемы в таблицу). Разбор ошибок начнём с тех, которые обусловлены прежде всего качеством исходных данных, предоставленных сочинителям.

Многие операторы заполнены текстом неправильно – имеются пустые поля. И этому есть объяснение – в условиях дефицита времени для уточнения синтаксиса сочинители обращались к алфавиту из /1, Гл.6/, а там приведены «слепыши» – примеры из книги в этом деле не помогали, т.к. там часто одни и те же иконы имеют разный текстовый синтаксис, а общих правил нигде не устанавливается. Поэтому сочинители просто выбирали для всего текста оператора одно поле иконы.

Взаимосвязана с этим ещё одна ошибка – неверно визуализированы некоторые действия. Так, программирование периферийных БИС (служащих устройствами ввода/вывода для исполнителя программы – ОЭВМ) иногда обозначается как вывод, а иногда – как действие (иконы с текстом, начинающимся с «настроить») да ещё с выносом части текста в комментарий («актив», «пассив»). И здесь это не только невнимание к сути действия – опять «слепыши» икон не дают должной опоры.

В авторской версии алфавита синтаксис текста задан РБНФ-выражениями – в них, конечно, надо разбираться, но будучи усвоенными, они становятся когнитивной опорой сочинителю.

Далее, перевран участок кода в начале цикла по ГКП; заголовок цикла ДЛЯ по и пропущен, а вывод значения и поставлен вне цикла – в конце предыдущей ветки алгоритма. Здесь уже причина ошибки коренится в когнитивном качестве псевдокода – человеку зачастую трудно следить за маршрутной структурой, показанной в нём «полуторамерно» через интендации строк – и при лимите времени запросто можно «зевнуть» кусок, что и произошло. Есть ещё причина из области информатической культуры сочинителей – невнимание к областям действия переменных – иначе можно было задуматься, а откуда собственно брать и для вывода, если предыдущее её использование в цикле инициализации ГКП завершено? ;)

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

Далее, неправильно трактована часть маршрутной структуры, заданная метками. В результате появились «хвосты» вместо выходов на конечную ветку. Хотя пример текстового представления силуэта есть в /1, с.92/, но этого сочинителям оказалось недостаточно даже вместе с консультацией при получении задания и на промежуточном контроле⁴. Естественно, у сочинителей не нашлось другого средства оформить эти «хвосты», кроме иконы И21. Отсюда же «хвост» вместо замыкания веточного цикла обслуживания ГКП через «подвал» силуэта.

Мало того – в оригинальной схеме иконы И21 были размещены на горизонталях, т.е. в «произвольном» стиле компоновки, характерном опять же для языка блок-схем; здесь на это места не было, поэтому автор ввёл изломы вниз.

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

При визуализации циклов ДЛЯ не использованы формальные комментарии-определения параметров цикла, хотя в примерах из /1, Гл.12/ прямо указано на такую возможность. Конечно, и это можно отчасти отнести за счёт того, что примеры человек может воспринимать как рекомендательные, а алфавит опять-таки ничего на этот счёт не указывает...

Текст икон-границ цикла ДЛЯ и в остальном ненаглядный – а это уже следствие «куцего» синтаксиса цикла с параметром в обычных блок-схемах, изучаемых в школе.

Тело внешнего цикла ДЛЯ (по и) разнесено по веткам вместо преобразования к циклу ДО; это опять-таки не всеми ИТ-профессионалами понимается как ошибка – что уж говорить о начинающих...

Ну и встречаются просто пропуски операторов, которые ничем, кроме невнимательности сочинителей, не объясняются. Так, в конце ветки инициализации две пары операторов установления сигналов «слиты» каждая в один оператор; в псевдокоде они выписаны отдельно, исходя из смысла – установить в нужное состояние схемы ЛБ действием пары сигналов, устанавливаемых/снимаемых в определённом порядке. Неспециалисту это объяснять необязательно – он просто должен следовать тексту.

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

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

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

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

Материал по техноязыку, приведённый в документе /3/, выработан автором в т.ч. и с учётом результатов этого эксперимента; в частности, все структуры шампур-метода даны инвариантно и абстрактно, что даёт возможность сжато объяснить их суть.

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

1 Честно говоря, на момент моделирования (исходный проект был начат в 1997 г.) автору ничего не было известно ни о каком объёмном стиле :); возможно, что это понятие и появилось-то позже. Такое построение модели было продиктовано элементарной для автора логикой организации объекта.

2 Хотя вопрос о том, куда деваются дуги контекста, у автора возникал, но IDEF0-стандарт /5/ этот вопрос не решает, а возможности самостоятельного поиска не было. Целесообразное решение содержится в работе: Костров А.В., Александров Д.В. Уроки информационного менеджмента. – М.: Финансы и статистика, 2005. – Рис. 7.1.

3 Вообще говоря, это не обязательно так; если исходный текст укорачивается за счёт каких-то «программных трюков», допускаемых языком, то понятность его (а м..б. и другие качества не только текста, но и кода) даже ухудшается (примеры можно найти в работе: /Свердлов С.З., 2007/ – для прогязыка высокого уровня на с. 91-94, для Ассемблера (условного) – на с. 411-412). Но т.к. этот приём не является «трюковым», то в этом случае можно говорить о большей читабельности получаемого текста.

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