Ильченко Эдуард писал(а):
Зачем вообще лезть в текст псевдокода, отображающего визуальный алгоритм?
Ну, некоторым программистам это нравится.
Согласен
Вот чисто практическая работа - извлечение, вложенное
в это сообщение.
Проводится тот же подход, что у Вас - единый (предметный) источник представляется в различных (символических) формах, и каждое представление можно редактировать. Однако не забывается и про эргономику - те же "цветные" типы модельных сущностей. И предусматривается ряд именно визуальных представлений.
Я по-прежнему согласен с Агафоновым (имею в виду цитату
в этом сообщении) , что нужно использовать разные языки для представления одного и того же знания (в частности, спецификации программы). А что даёт такую возможность? Разные визуальные представления, делающие акцент на той или иной стороне содержания.
Если говорить об отдельно взятой процедуре - то это м.б. представление на Вашем языке, где оператор показан содержащим собственно операцию и ссылки на операторы далее по маршруту, а суть оператора-действия и его логика графически не выделяется - но оно имеет право на существование именно наряду с дракон-представлением, где как раз выделяется графикой икон суть различных действий и (многими полями) их логическая структура.
Для визуализации, скажем, системы процедур представление через вставки в визуалах дракон-модели, показывающее конкретно вхождение каждого вызова на маршруте, м.б. дополнено сжатым - в виде ДМ-схемы, которую описал выше - где выделены только вызовы без указания их местоположений внутри процедур, что даёт возможность сделать акцент на показе передачи управления между процедурами.
Аналогично система потоков может иметь разные визуализации. Да и на процесс в целом мы можем посмотреть как на IDEF0-модель, а можем - как на модулярную структуру (визуализируемую ПК-схемой).
Конечно, система РДП должна строить эти представления по командам оператора - но используя единый ТФРД-документ. И очень важно
IMHO, что Вы работаете над его языком как над метаязыком разметки представления входящих граф-схем на конкретных ЯПЗ - это ляжет в основу дальнейшего перехода к полноценной РДП-системе.
Далее о том, как можно понимать концепцию ВЯЗБС и связать её с когнитивно-эргономичной формализацией знаний.
Фактически ВЯЗБС-представление задаёт возможный способ визуализации полного текстового описания любого графа. Ссылки на номера вершин в сущности кодируют связность вершин, причём содержание вершины-оператора БП (и
Конец) - только ссылка, вершины
Имя ветки (и
Заголовок) - только метка для перехода по ссылке между ветками визуала-силуэта (разных визуалов), а вершины-оператора
Вставка - ссылка для вызова по заголовку и метка для возврата по концу, т.е. вставка кодирует присоединение двух разнонаправленных дуг межоператорного перехода (от вставки к началу вызываемой схемы и от конца вызываемой ко вставке); вершина-условие же присоединяет две однонаправленные (от неё) дуги. В таком виде удобно прежде всего редактировать вручную структуру графа, не влезая непосредственно в текстовое представление; это более эргономично. Редактировать же содержание графа, конечно, лучше через обычное представление для каждого типа схем (дракон-, АТ-, ПК-, ДМ- и т.д.).
Чтобы "расписать" для обычного представления содержание действий по многим полям иконы, достаточно допустить, что описание иконы м.б. как однополевым, так и вложением полей (опять же как однополевых икон). При этом кодам вершин (сочетаниям этих кодов) соответствуют ключевые слова визуализируемого схемой текстового языка/подъязыка (не путать с текстовым описанием самой схемы); эти слова подставляются при переводе схемы/набора схем на этот язык (напр. дракон-Оберон-модели, АТ-Оберон-модели и ПК-схемы - на Оберон); также здесь используется указание на язык схемы. Аналогично сочетанием кодов полей при данном языке схемы определяется синтаксис текста каждого поля многополевой иконы (потому что она представляет один оператор, а текст по полям мы распределяем из удобства целостного восприятия этого смысла человеком, уверенного различения этого смысла в окружении других икон).
Ну и с форматированием текста совсем просто: вводятся типы подполей, на которые м.б. разбит текст поля, подполя обрамляются тегами формата, как в тексте сообщений данного форума
, а для РДП-редактора вводятся правила разбивки поля на типы и обрамления в зависимости от типа (о базовом делении см.
в этом подпункте и
в конце этого подпункта).
Я это пишу подробно, конечно, не для Дмитрия - он это уже реализовал, хоть и упрощённо, и конечно, понимает, как эту реализацию усложнить , - а как ответ на цитату, для того, чтобы показать, что в основе строения текста, отображающего любую граф-схему - и визуал, и неалгоритмическую - могут лежать в общем-то логически простые соображения, и даже непрограммист, руководствуясь ими, вполне может "лезть в псевдокод", т.е. в этот текст - только Дмитрий предложил способ как раз визуально представить всё его содержание и редактировать это представление.
Тут возможен вопрос: а нужно ли такое представление, если мы не допускаем ручного редактирования топологии схем? Однако ведь и при автоматизированном построении машинный алгоритм РДП-редактора манипулирует ссылками на номера вершин; также ему нужны и данные об их геометрии (размерах, координатах базовых точек), чтобы выполнять топологические соотношения (в т.ч. запреты шампур-метода). Так что у Дмитрия всё нормально; просто это детальное представление, как описать граф-схему текстом, имея шаблоны контуров полей икон (параметризуемые рисовальной частью редактора по заданным размерам).
Единственное, что надо будет добавить на уровне концепции для полноценной РДП (кроме вхождения многих полей в одну икону) - описание вхождения физически (привязки) одних схем в поля других; на верхнем уровне привязки, как уже говорил ранее, будут лист-силуэты, описанные
во 2-м техтребовании от меня. Ну и раскрытие содержания вершины/области схемы иконой
Область - с возможной вариантностью раскрывающего содержания, а также атомизацию группы действий для формализации взаимодействия процессов - это топологически однородные случаи, только границы области могут проходить по любым соседним вертикалям (достаточно, чтобы их оси порядка, введённые при обсуждении лиорасширения
пока в этом примере, образовывали монотонную последовательность), а атома - только в пределах одной вертикали (выделяя на ней шампур-блок).
Может возникнуть вопрос - а не ввести ли IDEF0-язык для описания процесса в РДП-документ? Тут вступает в силу "принцип Оккама" - не следует умножать число языков без нужды. Коль скоро ПК-схемы описывают то же самое более строго - останавливаемся на этом представлении; другая т. зр. на проект, как уже говорилось, содержится в ДМ-схеме. Сочинитель, знающий Оберон или иной модуляризующий язык, естественным образом будет мыслить такими представлениями. IDEF0-модель может играть роль эскиза, ибо в отношении точно-инструктивной и тем более программной формализации является "костыльным" представлением - и кому охота, может делать её в любом известном приложении (типа DesignIDEF или BPwin).
Это касается не только визуальных ЯПЗ но и ТЯП, на которые нужно транслировать - почему и здесь стоит ограничиться одним ТЯП, расширение которого будет использоваться и для записи дракон-схем текстом. Принимая аргументацию Ильи Ермакова, в частности, в докладе из этого сообщения, считаю нужным ограничиться языками семейства Оберон.
P.S. И об отражении некоторых аспектов специфики программирования в не чисто текстовой форме. Принцип визуализации прерываний был показан
в этом подпункте. Исключения имеет смысл отражать аналогично (только помечая операторы, для которых определена их обработка, отдельным признаком). Получится, что процедура TRY-CATCH будет визуально-структурно занимать место, аналогичное обработчику прерывания - как бы "сноски" из текста, прочитываемой только "по случаю" (здесь - возникновению исключительного состояния) - такое решение связано с аргументацией по общему смыслу исключения, выдвинутой при обсуждении на форуме РСДН в соответствующей теме, с которой и я согласен. Такую "сноску", как и для прерывания, удобно не включать в основной текст (насчёт дальнейшей классификации самих исключений есть разные мнения, но это не влияет на данный вопрос).
P.P.S. Ещё нашёл наглядный пример разметки текста в "Современном компьютере"
Вложение:
Комментарий к файлу: Иллюстрация принципа форматирования текста и языка описания форматов.
Терри_Виноград-Работа_с_ЕЯ-извл(разметка_текста).djvu [23.61 КБ]
Скачиваний: 389
Здесь визуализация доведена до показа предметного (битового) представления. Дальше уже некуда - разве что перейти на физический уровень и показать состояния ячеек памяти текста, наподобие того, как это сделано в заключительной статье того же "Современного компьютера"
Имхо, для качественного документирования ПО достаточно текстового описания для чего программа предназначена, как она это делает, ДРАКОН-схемы с необходимой степенью детализации (и лучше вообще человеческим языком) и самого текста программы с небольшими комментариями по ходу кода. Конечно, нужно ещё всякое другое, типа структуры классов, описание объектов, возможных событий, используемых протоколов, конфигурации железа, взаимодействия с интерфейсом и т.д. и т.п., но это уже мелочи : ) Вот если бы из всего этого некий программный продукт создавал документацию (кстати и ГОСТы всякие есть по оформлению доков) было бы замечательно. А если ещё и бесплатно, так и вообще сказка : )
Ещё и ещё раз - всё это для того, чтобы не "документировать" отдельно от "программирования" - и то, и другое работа творческая, и никакой "программный продукт автоматически создавать документацию" на ПО не будет (по крайней мере, от начала до конца автономно от оператора) - ведь он должен делать это по алгоритму, а создание такого алгоритма - задача,
IMHO, того же класса, что "построить алгоритм, строящий решение самой задачи по её постановке" - в математике же доказывается невозможность такого построения (т.е. это проблема из ряда т.н. алгоритмически неразрешимых). Но для того, чтобы ПРОГРАММИРУЯ, ДОКУМЕНТИРОВАТЬ - тем самым возлагая творческую работу на человека, но делая её ход естественным - сочинитель всё более точно описывает ход и обстоятельства решения (отнюдь не забывая надлежаще оформить то, что Эдуард определил как "мелочи" - не мелочи это, а равноправные составляющие знания о процессе), пока не появляется возможность какие-то его части выделить в автоматизируемые.