Начато обновление версии; подробности см.
Разд. История Стр. Введение в ресурс.
Сказано: "в этот день никому не верь"
- и правда, если про элементы нестрогой визуализации наконец добавлено, то обещанное тогда же по протокольным диаграммам по-прежнему нет... зато сделано кое-что другое.
Расширенная редакция пункта об объектах, как видно, навеяна новым изданием "Алгоритмов и структур данных" Вирта. Вопросы типизации выходят за рамки программирования, требуя согласованного понимания начиная уже с качественной формализации, и потому мне показалось возможным изложить их в русле этого источника, но чуть под другим углом зрения - ближе к предметнику, которому важнее не математика и реализация, а связь типов данных с сущностями своей сферы (каким образом данные, говоря по Вирту (с.11-12), "...являются прежде всего абстракциями реальных явлений...", вследствие чего их "...предпочтительно формулировать как абстрактные структуры безотносительно к их <структур> реализации в распространённых прогязыках."). Прежде всего это требует введения классификации объектов по уровню сложности; использована иерархия "простой-сложный-произвольный", ранее уже применённая к структурам визуальных алгоритмов на ДРАКОНе.
Важно, что сопоставление структур данных и управления Виртом в табл. 4.1 можно продолжить. Эту возможность открывает начатая создателем техноязыка типизация безусловных переходов, выраженная в определении разрешённых (петлёй силуэта) БП. В классификации Драконографики БП с возвратом соответствует вызову процедуры и даёт рекурсивные структуры; Р-БП оказываются частным случаем обычных БП и одним из случаев нерекурсивно-указательной связи (определяют граф вызова для веток, допускающий их перестановки на "ленте памяти") наряду с линейными БП (определяют граф вызова и перестановки уже для отдельных вертикалей и/или их фрагментов).
А вот к другим случаям "общих графов" управления, я полагаю, относятся: оператор Параллельный процесс, трактуемый как БП с расщеплением рабочей точки (для алгоритмов в целом); механизм динамического связывания процедуры с типом приёмника (по сути — условный переход к подпрограмме).
Классификацию можно уточнить, но общая идея, полагаю, ясна.Среди добавленных примеров имеется эскиз техпроцесса оформления дракон-схем в офисном пакете. Он специально сделан так, чтобы возникло желание его усовершенствовать - более того, дракон-модель содержит ошибки для самостоятельного обнаружения
Остальные примеры на самостоятельную работу, начиная с постановки - при этом обязательно возникнут вопросы и даже проблемы в связи с качеством исходных описаний. Здесь все вопросы к авторам использованных публикаций - если у Вас вдруг есть возможность их задать
- иначе визуализировать в меру своего понимания, "как правильно" в данной сфере деятельности.
Для передачи в сети материалы "ужаты"; кое-что дано в формате DjVu.В этом пункте наряду с вершинами "смягчения" режима визуализации описана возможность силуэтного представления синтдиаграмм.
Пока описание ввода и вывода показано не на протокольных, а на синт-диаграммах - тем самым вводится синт-язык как элемент метаязыка информатики. В описании этот язык сопоставлен с ДРАКОНом; более того, показано, как можно сделать синтдиаграммы подобными дракон-схемам.
Может возникнуть вопрос: для чего это, коль скоро по "чистому" шампур-методу схемы получаются более эргономичными? Возможный ответ здесь: "Мы хотим предостеречь от навязывания одной точки зрения, одного языка, одной терминологии, одной формы записи (синтаксиса), одной семантики и побудить к выявлению связей, к облегению переходов и перемен точек зрения, языков, терминов, синтаксисов, семантик. Взаимопонимания следует добиваться не столько путём жёсткой унификации и единообразия, сколько с помощью налаживания обозримой и упорядоченной сети "мостов", "дорог", "переключателей" и "указателей", позволяющей легко перемещаться в пространстве понятий." (Агафонов В.Н., 1990. - с.151).
Такие преобразования как раз показывают, как можно навести мосты между разными языками; конечно, в основном читатель будет делать это сам и по-своему.Кстати, синтопределение циклов, IMHO, по-своему проясняет, зачем нужно особо разбирать эту структуру (что делает Илья Ермаков, "объясняя циклы начинающим") - получается, что и при регулярной организации эта структура с надлежаще подобранными условиями позволяет "начитать" любой текст в заданном её телами алфавите, т.е. в импер-интерпретации - фактически исполнить любую последовательность действий (элементарных или укрупнённых), и эта структура м.б. принята за исходную; досрочные же выходы из цикла и/или уходы до конца его тела на новую итерацию появляются как результат попыток оптимизации исходной структуры ("втащить" вложенность по возможности внутрь одной петли)... или я не прав?
Для протокольных диаграмм мне показалось интересным обдумать связь с техноязыком, учитывая заявленную
в этом сообщении возможность использовать именно протоколы для генерации исходных текстов.
В целом подход к обновлению обычный - понятия, определение которых сложилось, вводятся в ресурс по мере необходимости для других, в первую очередь поисковых, вопросов.
P.S. Обновление завершено; добавлено Приложение 4, где решил исправить труднонаходимые ошибки
.
P.P.S. Пропустил в Приложении 4 документы-раскладки форматов на страницы для поячеечной печати с описанием соединения в формат (хотя с этим-то знаком тот, кому приходилось делать плакаты на принтере
); добавлено на примере схем из Задачи 1.1.1 и указано в самом тексте приложения. Всё включено в обновлённую загрузку Примеры и задания
на этой странице.