DRAKON.SU
https://forum.drakon.su/

Визуализация знаний - эскизная и детальная
https://forum.drakon.su/viewtopic.php?f=62&t=2527
Страница 1 из 1

Автор:  Владислав Жаринов [ Воскресенье, 04 Апрель, 2010 22:29 ]
Заголовок сообщения:  Визуализация знаний - эскизная и детальная

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

Автор:  Владислав Жаринов [ Воскресенье, 04 Апрель, 2010 22:34 ]
Заголовок сообщения:  Пример выбора логики процесса - визуализация ветки Задачи 1.

Рассмотрим головной визуал задачи (полностью приведён в описании из п. Примеры и задания на этой странице. Т.к. задача силуэтно структурирована, то полное описание для начала не потребуется (в этом достоинство силуэта - ветки м.б. относительно независимы) - достаточно сказать, что к началу исполнения ветки Оформление силуэта имеем рабочий лист, на котором помещены все иконы оформляемого визуала со своими текстами, заготовки линий, и мы решили их организовать как дракон-силуэт (как мы решили ранее по ходу задачи, дракон-примитив нас не устраивает). Процесс рисования силуэта можно визуализировать по-разному; два варианта даны ниже.
Вложение:
Оформление силуэта - вар1.png
Оформление силуэта - вар1.png [ 56.68 КБ | Просмотров: 22137 ]

Вложение:
Оформление силуэта - вар2.png
Оформление силуэта - вар2.png [ 53.48 КБ | Просмотров: 22137 ]

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

Автор:  Владислав Жаринов [ Вторник, 06 Апрель, 2010 05:28 ]
Заголовок сообщения:  Мозговая проверка дракон-модели

Рассмотрите теперь дракон-модель Задачи 1.1.1 целиком, проверив каждый маршрут и шампур-блок решения. Всё ли правильно визуализировано? Любой ли правильный шампур-блок оптимален по структуре и использованным операторам?

Автор:  Владислав Жаринов [ Вторник, 06 Апрель, 2010 05:30 ]
Заголовок сообщения:  Сочинение процесса и оценка средств редактирования дракон-сх

В дракон-модели Задачи 1.1.1 для визуала Подготовить вывод даны варианты тела. Т.к. Вариант 2 считается лучшим, надо бы его вставить на место Варианта 1 (который можно поместить на освободившееся место); линии главных вертикалей вариантов, само собой, должны оставаться на местах (не считая необходимой подгонки под иконы).
Как это сделать в использованном редакторе (OpenOffice.org Draw)? Опишите процесс, используя его команды (выбора меню, манипуляций фигурами).
Теперь представьте, что та же модель визуализирована в приложении "и.с.DRAKON" (Ты-среде); разберитесь в её командах и объектах. Можно ли в и.с.DRAKON воспроизвести содержимое листа рисунка "один к одному"; если нет, то почему? Как можно поменять подсхемы вариантов в этом случае? Предложите процесс, по возможности визуализируйте.

Автор:  Владислав Жаринов [ Вторник, 06 Апрель, 2010 22:14 ]
Заголовок сообщения:  Пример - построение схем типов объектов

Пусть даны иконы, обозначающие атомарные типы алгоязыка (будем иметь в виду Оберон-2). Икона обозначает вхождение элемента атомарного типа в структуру неатомарного, а графика иконы заменяет название типа элемента (числовой, литерный, булевый); т.о. образуется подалфавит визуального деклар-языка определения типов для информатически строгих визуалов (дракон-программ):
Вложение:
Комментарий к файлу: Вариант с дополненными комментариями и согласованным текстом икон.
Простые АТ - иконы.png
Простые АТ - иконы.png [ 58 КБ | Просмотров: 21977 ]

Предполагается, что с иконой связана таблица параметров объекта (величины); в первом приближении - такая, как в этом сообщении. Конкретные значения элементов неатомарной величины определены для терминальных икон (листьев дерева типа).
Также добавлены иконы неатомарных типов.
Вложение:
Комментарий к файлу: Типы по спецификации в пер. Свердлова с добавлением типа последовательность по Н. Вирту.
Неатомарные АТ - иконы.png
Неатомарные АТ - иконы.png [ 82.75 КБ | Просмотров: 21977 ]

Графика их выбиралась из следующих соображений. Массив взят как упрощение символа ГОСТ-блока; показывает порядок по одной координате (для многомерных предполагается "стопка" икон для измерений по шампуру). Запись представляет иерархию произвольных типов-реквизитов, которой символически соответствует некий документ (машино-/видеограмма); поэтому взят ГОСТ-блок документа (а может и представлять класс документов - поэтому, возможно, стоит выбрать правую икону). Множества чаще всего изображают диаграммами Венна как круги/эллипсы; кроме того, форма родственна выбранной для числового типа (принятого для элементов в Обероне). Наконец, тип процедура понимается как деклар-представление визуала-вставки и потому изображается аналогично.
Тип последовательность, как можно понять из анализа спецификаций Оберона, "сконструированный" вне языка (в библиотечном модуле ввода/вывода). Икона типа также взята из ГОСТ по соответствию названия.
При описании неатомарные типы вначале именовал, как в литературе, "типа прилагательными", но потом понял, что нужно следовать "классике", т.е. идти от языка текста, в котором имена употребляются. А этот текст предназначен человеку-носителю естественного языка - в данном случае русского - и нужно следовать его законам, иначе уподобишься Митрофанушке :wink:. Поэтому в итоге неатомарным типам названия даю существительные, в отличие от прилагательных-признаков для атомарных. В самом деле, у нас сложный тип формально неотделим от его простых элементов, а по-русски мы скажем это конструкцией вида "<что?> <[из] чего?|какой?>" - "массив литер[ный]"; "множество <целых|целочисленное>" (собственно, в Обероне другого не предполагается :)); "запись <[из] таких и/или сяких и/или эдаких...>" (т.к. поля м.б. разных типов - в т.ч. расширяющего типа запись); то же справедливо для произвольных типов.
Вопрос вроде частный, но ведь недаром говорится, что программисту в первую очередь нужно знать родной язык... Кроме того, разница словоформ сразу отделяет для читателя атомарные типы от остальных; законы языка начинают работать на когнитивную эргономику текста.


Вопрос: как можно на этой основе визуализировать определения неатомарных типов Оберона-2 (произвольных)?
Предполагаем, что можно вводить в деклар-язык ещё иконы для целей организации сложных структур.
Ещё вопрос: как можно отобразить расширение типа запись? Нужно ли вообще это делать на уровне алфавита или вопрос решается выше - на уровне составления конструкций АТ-языка?
И третий вопрос: а как можно показать значение величины (атомарного типа) на АТ-схеме? Нужно ли это делать на схеме или достаточно в связанной ("выпадающей") таблице? Мнение интересно опять-таки в первую очередь от "предметников", которым схемы составлять.

Автор:  Владислав Жаринов [ Вторник, 06 Апрель, 2010 22:17 ]
Заголовок сообщения:  Формальная типизация эскизного визуала

В этом подпункте изложено определение типов Оберона-2 с обозначениями для текста икон техноязыка. По сути, это часть определения гибридного техноязыка, условно называемого далее ДО2 (Дракон-Оберон-2).
Рассмотрите объявления типов величин в дракон-модели Задачи 1.1.1. Соответствуют ли они ДО2? Подумайте над типом величины ПредстРешения. Можно ли изменить его?

Автор:  Владислав Жаринов [ Понедельник, 12 Апрель, 2010 05:30 ]
Заголовок сообщения:  Проектирование "рекле"-вывода твёрдой копии большого формата

Для подготовки вывода листов на устройство твёрдой копии меньшего формата на примере Задачи 1.1.1 предложена процедура раскладки на страницы-ячейки служебного документа "Лист [N]*". Можно ли выполнить её для любой дракон-схемы (в общем случае - совокупности дракон-схем), нарисованной на листе? А как решить ту же задачу в и.с.DRAKON? Можно ли прямо из этой среды разложить на ячейки любую дракон-схему (совокупность дракон-схем с одного листа проекта), соблюдая единый масштаб?

Автор:  ==== [ Вторник, 13 Апрель, 2010 20:01 ]
Заголовок сообщения:  Re: Визуализация знаний - эскизная и детальная

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

В графический файл при настройке "Планшет" выводятся все дракон-схемы листа, про настройке "Картотека" выводится одна, верхняя дракон-схема листа.

В справке к и.с. DRAKON, в разделе "Вопросы и ответы" написано:
Цитата:
4. Можно поподробнее? Что, формат drt понимается каким-то распространенным графическим редактором? Каким?

Говорилось о выводе листа в графический файл .png.
Файл с расширением png прочитайте редактором Paint.
Можете редактировать: убрать ненужное, добавить логотип фирмы, красивый заголовок, угловой штамп для подписей.
Подготовить для печати, т.е. установить параметры страницы: формат бумаги, размер полей = 0, выбрать ориентацию, раскладку картинки на N*M страницах, центрировать, подогнать или масштабировать.
Предварительно просмотреть. Напечатать. Обрезать кромки поля (подумайте часть или все), склеить скотчем или клеем.
Повесить на стену, провести презентацию.

Автор:  Владислав Жаринов [ Среда, 14 Апрель, 2010 05:11 ]
Заголовок сообщения:  Re: Визуализация знаний - эскизная и детальная

Геннадий Тышов писал(а):
Драконограф писал(а):
А как решить ту же задачу в и.с.DRAKON? Можно ли прямо из этой среды разложить на ячейки любую дракон-схему (совокупность дракон-схем с одного листа проекта), соблюдая единый масштаб?

В графический файл при настройке "Планшет" выводятся все дракон-схемы листа, про настройке "Картотека" выводится одна, верхняя дракон-схема листа.

В справке к и.с. DRAKON, в разделе "Вопросы и ответы" написано:
Цитата:
4. Можно поподробнее? Что, формат drt понимается каким-то распространенным графическим редактором? Каким?

Говорилось о выводе листа в графический файл .png.
Файл с расширением png прочитайте редактором Paint.
Можете редактировать: убрать ненужное, добавить логотип фирмы, красивый заголовок, угловой штамп для подписей.
Подготовить для печати, т.е. установить параметры страницы: формат бумаги, размер полей = 0, выбрать ориентацию, раскладку картинки на N*M страницах, центрировать, подогнать или масштабировать.
Предварительно просмотреть. Напечатать. Обрезать кромки поля (подумайте часть или все), склеить скотчем или клеем.
Повесить на стену, провести презентацию.


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

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

Автор:  ==== [ Четверг, 15 Апрель, 2010 19:56 ]
Заголовок сообщения:  Re: Визуализация знаний - эскизная и детальная

Драконограф

Т.к. известно, что "Нельзя объять необъятное", то разработка и.с. DRAKON выполнена с использование интеграции с другими средствами пользователя: графическими и текстовыми редакторами, средами языков программирования.

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

Полагаю, основное время пользователь будет будет затрачиваться на работу в и.с. DRAKON и необходимое дополнительное время будет незначительным.

Автор:  Владислав Жаринов [ Суббота, 17 Апрель, 2010 05:12 ]
Заголовок сообщения:  Re: Визуализация знаний - эскизная и детальная

Геннадий Тышов писал(а):
Драконограф

Т.к. известно, что "Нельзя объять необъятное", то разработка и.с. DRAKON выполнена с использование интеграции с другими средствами пользователя: графическими и текстовыми редакторами, средами языков программирования.

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

Полагаю, основное время пользователь будет будет затрачиваться на работу в и.с. DRAKON и необходимое дополнительное время будет незначительным.


Время - наверное, но при этом м.б. разная по кропотливости работа может требоваться, и соответственно разные силы затрачены (особенно, если плакат нужен срочно). Впрочем, о времени и силах на данную операцию - это лишь деталь того, о чём подробнее опять-таки в этом сообщении. Для сохранения раскладок достаточно реализовать печать из редактора в файл.
О необъятном - вот vladfind фактически предложил его "объять" и предлагает свою помощь. Что там как - нужно разбираться, но сам взгляд - вполне системный - IMHO, показателен...

Автор:  Владислав Жаринов [ Суббота, 17 Апрель, 2010 05:14 ]
Заголовок сообщения:  Re: Формальная типизация эскизного визуала

Драконограф писал(а):
В этом подпункте изложено определение типов Оберона-2 с обозначениями для текста икон техноязыка...


Вот мои ответы к поименованному примеру:

1. Конечно же, типы объявлены неправильно. Во-первых, формат объявления в Обероне-2 обратный. Во-вторых, типы формальных параметров сложные, и нужно сначала объявить каждый из них под именем собственным, придуманным сочинителем. Однако это требует ответа на второй вопрос.

2. По сути, мы не знаем структуры ПредстРешения; именно поэтому мы "схитрили" при объявлении, не описав структуру порождающего её типа запись.
Можно предложить два подхода:

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


Итак, простая вроде бы задача рисования оказывается по-своему фундаментальной, выходя на самые разные вопросы формализации знаний :)

Автор:  Владислав Жаринов [ Понедельник, 03 Май, 2010 05:07 ]
Заголовок сообщения:  Re: Сочинение процесса и оценка средств редактирования драко

Попробуем ответить на вопросы. поставленные в исходном сообщении. При этом воспользуемся определениями критерия и показателя эффективности, данными в словаре ресурса и использованными качественно при описании информашин в п/п 2.1.4.1 на этой странице. При этом будем рассматривать ряд реализаций, а именно:
    * визуализации "в машинном карандаше", без фиксации в документе структуры и свойств модели, на базе офисного пакета и типовых документов к нему;
    * редактора Ты-среды визуализации, фиксирующего содержание модели по правилам техноязыка в базовом алфавите, но с расширенной атрибуцией икон;
    * предполагаемого редактора полнофункциональной РДП-системы, использующей расширенный алфавит, определённый в п. 2.1.3 на этой странице.
Здесь существующие первые две реализации используются для формулирования требований к третьей. При этом охватываются и характеристики оформления схем и внесхемной графики.

Итак, как поменять местами фрагменты в исходном документе? Возможен следующий порядок действий:
    *выделить Вариант 1 без блока зоны и отбуксировать его в сторону (в данном случае - влево), освободив место на схеме (что возможно, т.к. модель листа в Draw основана на принципе "холста", т.е. имеет поля за пределами формата);
    * выделить элементы Варианта 2 без блока зоны и отбуксировать его на поле рядом со свободным местом;
    * подогнать шампур и блок зоны на схеме по высоте Варианта 2;
    * выделить элементы Варианта 2 и отбуксировать на схему, совместив иконы главной вертикали с её шампуром;
    * выделить элементы Варианта 1 и отбуксировать его на место Варианта 2, оставив выступающий конец шампура сверху;
    * подогнать шампур и блок зоны по новому содержимому;
    * изменить номера вариантов в блоках зоны.
Если ограничиваться только визуализацией "в карандаше", то данное решение безусловно пригодно. Оно также оптимально, т.к. требует интуитивно ясных и легко выполнимых операций (в Draw на бюджетной платформе - без заметных задержек машинного исполнения). Для любого элемента мы можем задать нужный формат графики и текста надписи в "почти полиграфическом" виде.
Решение является и адаптивным (в том же ограниченном смысле), т.к. можно легко менять структуру схем, размещение их по форматам.

А как сделать то же самое в Ты-среде? Здесь можно вырезать/вставлять только в шампуры созданной схемы. Поэтому понадобится схема-времянка для обмена и фиктивная схема для каждого варианта. С их участием можно построить следующую процедуру обмена (имея в виду, что Вариант 2 уже оформлен как фиктивный примитив, называемый в иконе Заголовок):
    * создать схему-времянку типа примитив;
    * выделить на схеме Варианта 2 содержимое шампура и вырезать его в графбуфер Ты-среды;
    * вставить в шампур времянки содержимое графбуфера;
    * выделить на основной схеме участок (шампур-блок), соответствующий Варианту 1 и вырезать его в графбуфер Ты-среды;
    * вставить в шампур фиктивной схемы содержимое графбуфера;
    * выделить содержимое шампура времянки (Вариант 2) и вырезать его в графбуфер Ты-среды;
    * вставить в шампур основной схемы содержимое графбуфера;
    * заменить номер варианта в иконе Заголовок фиктивной схемы.
В сравнении с офисным документом здесь работа оператора с одной стороны упрощается, т.к. в Ты-среде схемы автоматически перечерчиваются по вводу; однако длительность этой операции сильно зависит от сложности ввода (в данном случае - вставляемого фрагмента) и принимающей/отдающей схемы. Поэтому возможна психологическая перегрузка оператора при ожидании, превышающем оптимальный интервал 0,5...2 с. Поэтому пригодность Ты-среды в плане работы сильно зависит от конфигурации платформы АРМ.
Оценим теперь качество представления моделей. Прежде всего, в Ты-среде отсутствует внесхемная графика, поэтому блок зоны (в терминах 1С-языка - "декорацию") наложить на произвольную часть листа невозможно. Для фиктивной схемы некоторым приближением зоны служит рамка схемы. Однако схема-вариант содержит ненужные иконы Заголовок и Конец, "зашумляющие" восприятие оператора. Отсутствие же рамки фрагмента на основной схеме делает бессмысленным ведение вариантов в Ты-среде - читателю как-то нужно указать границы варианта. Внимательный читатель может найти паллиативное решение этой проблемы, которое мы здесь обсуждать не будем - всё равно при этом получается "бесплатный цирк" :) Т.о., содержательно решение по ведению вариантов содержания дракон-схем не м.б. признано даже пригодным.
Из-за "машинописного" стиля текста Ты-документов не представляется возможным воспроизвести схемы Задачи 1.1.1 даже в этой части.

Что можно реализовать в гипотетическом РДП-редакторе для ведения вариантов? Расширенный алфавит даёт нам возможность применить икону Область. Обмен сведётся к команде переопределения варианта области, рассматриваемого как основной. Тем самым решение пригодно, причём крайне эффективно в плане трудозатрат оператора - а о том, чтобы избежать машинного ожидания, должен позаботиться разработчик такого редактора.
Для оптимальности реализации желательно, чтобы область-вариант была оформлена как зона КогниСтиль. Добиться этого можно опять-таки настройкой вида икон в объёме, обычном для графоэлементов офисного пакета - линии контура, площади фигуры. Форму можно оставить со скруглёнными углами в отличие от зоны. Также нужно реализовать "полиграфический" стиль текста икон.
Для адаптивности определение иконы Область, данное в этом подпункте, нужно уточнить - следует ввести возможность отображения основного варианта прямо в экземпляре области, вставленном в схему (очевидно, как свойство-триггер иконы). Так вариантность будет нагляднее, чем при выносе всех вариантов за пределы основной схемы.

Автор:  Владислав Жаринов [ Понедельник, 05 Июль, 2010 05:15 ]
Заголовок сообщения:  О "сборочном проектировании" визуальных моделей

Используя каталоги областей, как определено в п.3 4-го техтребования от меня, можно реализовать полуавтоматическую детализацию схем (в частности, дракон-моделей). В самом деле, в РДП-системе мы можем поставить каталогизированной области на некотором языке в соответствие икону на более высокоуровневом языке (напр. области-схеме на дракон-ассемблере - оператор ДО-2). Тогда можно, выбрав язык для детализации и подгрузив нужные каталоги, просто при выборе очередной иконы отвечать на вопрос о "визуальном автозаполнении" её области из области каталога.
Возможно, что одной иконе в каталоге соответствует более одной области; тогда сочинитель должен выбрать нужную.
    Естественно, соответствие устанавливается в абстрагированной форме - и икона, и область в тексте имеют условные имена объектов, и совпадение с детализируемой иконой проверяется при абстрагировании также и её текста (т.к. согласно 9-му техтребованию от меня в системе определён шаблон синтаксиса текста на любом языке, то он и используется РДП-редактором для этой цели).

Каталоги постепенно формируются коллективом сочинителей, эксплуатирующим РДП-систему (среду) и составляют то, что Грабин в выдержке, вложенной в этом сообщении, называет "творческой базой" проектирования.

Автор:  Владислав Жаринов [ Пятница, 03 Сентябрь, 2010 19:45 ]
Заголовок сообщения:  Визуализация модулярной структуры процессов для Оберона-2

Итак, вот предложения по описанию таких структур как граф-схем в редакторе перспективной РДП-системы.

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

Структуры программ и иные примеры см. /Свердлов С.З., 2007, П. Объектно-ориентированное программирование/. Спецификация Оберон-2 см. /Свердлов С.З., 2007, Прил.1/.
В ДМ-схеме показывается именно структура вызовов, то, что у /Непейвода Н.Н., Скопин И.Н., 2002, с. 363/ называется технологической модуляризацией - ПК-схема же показывает в терминах Непейводы модуляризацию для сегментации.
    Т.к. автору неизвестны детали реализации базового модуля javalang компилятора JOB, то ДМ-схема сочинена в предположении, что существует процедура PString, обеспечивающая ведение массива из Ява-строк - возможно, это предположение ошибочно.

Как и ПК-схема, ДМ-схема м.б. сводной для общего состава или частной для состава конкретного процесса (проекта). Пример по Свердлову на рисунке:
Вложение:
A3LS О-2 Программа Hello - ДМ-схемы.png
A3LS О-2 Программа Hello - ДМ-схемы.png [ 65.81 КБ | Просмотров: 20716 ]
    Здесь иконы Модуль показаны с одноколонной организацией частного содержания.
Фактически сводная схема является обзорной и строится для сведения сочинителя, работающего в РДП-системе с рядом проектов одновременно. Аналогичную роль играют обновляемая страница Node Tree и временная страница Page Structure в DesignIDEF.
Принят следующий принцип образования такой схемы: включаются все модули (или процедуры), причём одинаковые модули входят только один раз независимо от суммарного числа вхождений в процессы; отношения по разным процессам показываются по разным вертикалям, проходящим параллельно через икону модуля (процедуры).

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

P.S. Множественное использование в ДМ-схемах можно показывать более логично. Примеры ПК- и ДМ-схем (частных) теперь в документе, вложенном в это сообщение.

Автор:  Владислав Жаринов [ Вторник, 28 Сентябрь, 2010 21:17 ]
Заголовок сообщения:  Языковой базис визуализации

Изменены примеры ПК- и ДМ-схем. В качестве основы взята Оберон-программа работы с гетерогенной очередью из /Свердлов С.З., 2007, с. 159-168/
Вложение:

Результаты оформлены как РДП-документ; в связи с этим определены некоторые положения по стандарту таких документов (во Введении в предмет и на схемах), комментируемые ниже.
Ссылки подразделены на наводимые, как обычно, вручную сочинителем, и наводимые автоматически. Вторые предлагается выделять другим цветом, чтобы при чтении отличать. Выделены также перекрёстные ссылки; в реальном документе можно, наверное, как это принято, показывать их как обычные, но можно и оставить (напр. для контроля вхождения в тезаурус).
Поскольку это по-прежнему макет РДП-документа, то также цветом показаны цели ссылок; реально, конечно, они обозначены тегами, а показываются, как обычно в гипердоках, в отдельном режиме отображения документа "показать поля".
В работе с графикой возможности, превосходящие офисные пакеты, нужны для создания чертежей материальных объектов. В РДП-редакторе это не требуется - нужные изображения должны вставляться из чертёжных приложений или документы этих приложений подключаться к РДП-документу по ссылке.
В основном из этого очевиден проект стандарта языка лист-силуэтов.
Индексно-ссылочный аппарат РДП-документа должен среди прочего поддерживать элементы информатической культуры, напр. упомянутые Фридландом (ограничение сокращений, человекочитаемые псевдонимы для кодовых имён).
Описание элемента схемы, как в развитых МФЗ типа SADT, содержит только один (неформальный) тип комментария. Вся формальная часть должна отражаться видом элемента (для сочинителя визуализируется графикой) и заполнением (текстовыми полями ребра, фигур вершины), без "лирических рассуждений на формальные темы" - если что-то из желаемого смысла не отражается, значит граф-язык (и его изоморфную ТФРД-запись) нужно специфицировать тщательнее.

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

Некоторые решения по визуализации обусловлены "макетным" характером документа. Так, в реальном РДП-редакторе необязательно на маршрутах лист-силуэтов присваивать значения для вывода переменным - можно задать их как служебные переменные прямо в операторах синт-вывода, а значения переменных, подобно литералам, в режиме редактирования д.б. доступны в окне просмотра/ввода.

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

Содержание документа заменяет 2-е техтребование от меня к РДП-системе, но не полностью; новые предложения по РДП-стандарту также будут позднее.

И о языковой базе. Описания языков визуализации знаний уже публиковались в Драконографике; в то же время лишь определённая совокупность ЯПЗ должна первоначально реализовываться как РДП-метаязык (допускающий расширение новыми языками).
Первым среди базовых, безусловно, является язык лист-силуэтов. Глядя на его конструкции, читатель может воскликнуть: "-Так это же дракон-программа!". В принципе это верно, только она повёрнута по гооризонтали :) - в то же время это интерактивное описание, задающее процесс диалога с оператором, поэтому скорее можно говорить о дракон-сценарии. По сути, в отличие от "пассивных" языков схематизации, этот язык даёт сочинителю возможность построить диалоговую (в т.ч. игровую) среду, результат "путешествия" по которому зависит и от влияния читателя. Подобную среду известный отечественный учёный А.Г. Шмелёв называл "мир поправимых ошибок"; конечно, очевидным назначением её является учебное (что и показывает приведённый пример), но оно, безусловно, м.б. и научным (напр., представление экспериментальной деятельности), и прикладным (напр., описание условной трансляции программ). Многое здесь зависит от возможностей РДП-среды; поэтому приводятся и соображения по реализации.

P.S. Начата публикация языков, предлагаемых для РДП-среды; см. это сообщение.

P.P.S. Любезно ослабленное администрацией ограничение на объём загрузок позволило вложить машобраз-дубликат РДП-документа:
Вложение:

Правда, решил сжать в *.djvu, так что действующие гиперссылки (в основном с титульного листа) всё равно можно только через оригинал смотреть :)

Автор:  Владислав Жаринов [ Вторник, 12 Октябрь, 2010 19:58 ]
Заголовок сообщения:  Об использовании иерархии импер-ЯПЗ

Введённые на этой странице определения языков дракон-семейства могут употребляться для детализации следующим образом. Для постановки сочиняется эскиз с ДР-алгоритмами (обычно "предметником"). Далее при традиционном программировании сочинитель выбирает для "областной" детализации ДРАКОН-Алго и визуализирует вершины или группы. При инженерном проектировании (с верификацией модели; предполагаем, что в среде типа Spin) выбирается ДО7Pr и на нём делается спецификация; при этом скорее всего нужно допустить только повершинную детализацию, т.к. переходим от неинформатизованного языка к информатически формальному в смысле п/п 1.1.1.1 на этой странице (структура маршрутов, сделанная эскизно, и меняется при подъёме на уровень эскиза). В том и другом случае обычно сочинитель делает неалгоритмический "каркас" процесса на ПК-языке, подключая дракон-процедуры (если только он не начал сразу с модуляризации, что желательно; тогда он задаёт процедуры именами в модуле, а РДП-среда сразу создаёт под очередное имя дракон-заготовку). Спецификация служит как формализованным техзаданием на проектируемый процесс, так и материалом для проверки (путём генерации Promela-текста и загрузки его в среду проверки); далее текст в случае коррекций в этой среде обратно ретранслируется в РДП, обновляя проект. По готовности получаем Оберон-текст (выбирая соответствующий режим генерации, где необероновские элементы диалекта игнорируются). В обоих случаях РДП-среда для исходного текста должна автоматически преобразовывать ДО7Pr-силуэты в ЦД по переменной Имя ветки (силуэтные).
Вывод ДО7Pr-схем определён по шампур-методу; для этого потребовалось переопределение и самого метода :) Изменения внесены как в составе ДО7Pr, так и в базовые тезисы.

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

Разумеется, если стороны регулярно используют указанный языковой базис, со временем всё чаще процесс упрощается; "предметник" сразу делает ДО7Pr-спецификацию, которую аналитик только уточняет.

P.S. В связи со введением типов точек ввода забыл определить "динамику" их использования - имеется в виду, что тип всех точек во вновь введённом атоме должен устанавливаться по типу использованной точки. Добавлено в базовое определение шампур-метода (Тезис 10 в этом подпункте).

Автор:  Владислав Жаринов [ Пятница, 31 Декабрь, 2010 21:11 ]
Заголовок сообщения:  Варианты визуализации систем процессов

Хоть и говорил, что не стремлюсь рассматривать криптографические знания - но описания PGP показались удобным материалом для иллюстрации некоторых вопросов визуализации. Правда, заодно на них удобно показать и ограничения использования шифрсредств. Итак, используем описание процесса закрытой связи с применением данной программы, данное в книге: Левин М. PGP: кодирование и шифрование информации с открытым ключом. - М.: Майор, 2001.
Визуализируем на Д2М-языке; проходим стадии формализации согласно свёртки Фридланда, проведённой на этой странице, поэтому вначале качественное описание по Левину математизируется как краткая спецификация задачи. Результат оформлен как этот пример.

Полученная Д2М-модель адекватно отражает логику процессов, но несколько громоздка. Однако систему функций можно визуализировать и на другом языке - вычислительных, или функциональных графов (как ещё говорят, сетей зависимостей; их разновидность с синтаксисом, усложнённым для фиксации элементов актив-знания, известна как потоковые диаграммы и служит языковой частью ДПД-МФЗ). Мы не будем давать это описание; знакомым с языком понятно, что описание получается проще.
Можно говорить об ограничении сферы применения техноязыка в зависимости как от наглядности, так и от свойств исполнителя (какого типа модель исполнения в нём реализована).
    Ну и о правовых ограничениях. Видно, что PGP использует как асимметричное (двухключевое с открытием одного из ключей), так и симметричное (с одним закрытым ключом) шифрование. Правовые условия же применения СШ и АШ (в частности, в России) различны; это следует иметь в виду.

Встаёт вопрос: как удобнее описывать системы процессов, в частности на уровне спецификаций, имея в виду опять же когнитивное качество с учётом квалификации "предметников"? Понятно, что графит-модель и тут удобнее; но какова концепция её построения? Существует подход, предоставляющий сочинителю некий "игровой мир", где элементы модели и процесс их организации максимально напоминают "строительство из кубиков". Примерами служат приложение HiAsm и упоминаемая здесь среда Scratch. Однако и сами авторы ограничивают их потенциальную область примененения; и неспроста. В самом деле, можно ли рассматривать построенные с их помощью спецификации, а тем более информодели, как "убедительные"? Возможно, техноязык не решает всех проблем эргономичного представления для систем процессов, но он задаёт правильное направление - необходимой абстракции визуального синтаксиса - как и схемные описания материальных систем. В результате рационально изображаются любые выявленные в аспекте моделирования связи "предметки", а сочинитель ориентирован на максимально полное и целостное отображение. А "игривый" синтаксис рассмотренных сред (особенно второй) не располагает к этому. Что не означает полную невозможность их применения - просто она д.б. ограничена начальной подготовкой в визуальном моделировании. Как и матобъекты дети строят "из кубиков" - а потом переходят ко взрослым технологиям (в которых и знания уже передаются реалистичными чертежами) - и понимают, что элементы не обязательно д.б. типовыми, а их соединения - единообразными - есть разумный уровень унификации размеров и форм крепежа, габаритно-присоединительных, допуски и посадки, а во всём остальном детали и сборочные единицы конструируются свободно, исходя из тройки Витрувия "польза-прочность-красота" (конструктивный, служебно-эксплуатационный и эстетический аспекты техтребований). И описываются так, что можно по описанию проверить работу изделия. Есть сомнения, что даже спецификация (не говоря об инфопрогмодели) "из кубиков" пригодна, чтобы разобраться в свойствах решения настолько, насколько нужно было бы в случае с "Протоном", чтобы выявить дефекты реализации управления... а ещё лучше - чтобы их не допустить... Тогда как шампур-метод закладывает основу для доказательного анализа/синтеза решений - при соответствующем развитии.

И ещё одно. Довольно часто (и на данной конференции) встаёт вопрос о препроцессинге информоделей (конкретно - условной компиляции программ). Видно, что "областная декомпозиция" позволяет решить и этот вопрос по-своему интересно. В самом деле, достаточно сопоставить каждому варианту условие его вхождения в схему, проверяемое РДП-редактором - и можно собирать графит-модель в зависимости от сочетания значений величин, входящих в эти условия. Величины в принципе м.б. любыми из РДП-документа, содержащего модель, и/или служебными ("переменными окружения" РДП-системы) - как реализован РДП-редактор. Условие задаёт сочинитель как сборочный атрибут вершины Область (мыслящий в терминах Ты-среды мог бы назвать это "приложением трансляции" - но оно совершенно не имеет отношения к трансляции собственно схемы в исхтекст - только к сборке схемы из неохваченной вариациями части и/или подсхем-вариантов). Т.о. атрибуты сборки областей выступают как аналоги IFDEF-операторов.

Автор:  Владислав Жаринов [ Вторник, 01 Март, 2011 13:14 ]
Заголовок сообщения:  О целях и задачах РДП

На макете, который теперь находится в этом примере, реализованы общеязыковые требования с уточнениями; в частности, унификация описаний РДП-объектов доведена до близкой к логически целесообразной, а структура документа приведена к текстобазированному шаблону условной УСД, используемому в примерах здесь.

Что же иллюстрирует этот пример? Прежде всего то, что представление документа в самом передовом виде при реализации д.б. увязано с традиционным. И дело здесь не только в позиции, которую неоднократно озвучивал (подразумевая, что текст - это письменная внешняя речь :)) тот же Фёдор Васильевич - что картинками, взятыми сами по себе, не обойдёшься - и которая с самого начала (собственно, ещё до знакомства с ней :)) нашла отражение в виде поэтапного уточнения классификации формализуемых знаний по Паронджанову (в полном виде и содержащейся в примере). Нужно помнить также, что существуют стандарты документирования, закрепляющие вполне определённую логическую организацию как системы реквизитов (с закономерными их вариациями по составу и содержанию) - и если физику мы можем перевести на графовую базу, то логику надо сохранить - чтобы был изоморфизм для той же символ-сборки. Кроме того, и физика реквизитов практически полезного документа вполне определённая (по атрибутам свойств формата, которые должны объединяться в стили) - и это тоже нужно учесть. Чтобы можно было из схематизированного массива данных в редакторе получить документ, определённый у тех же Пшенко и Охотникова в этом сообщении - конечно, при некоторых условиях, определяемых сочинителем.
    Важным обстоятельством является и участие документа в таких операциях, как согласование (с возможными исправлениями) и визирование (с принятием исправлений). Эти вопросы освещены в статьях из того же сообщения - а технология коллективной работы с формализованным знанием в таких стандартах, как IDEF (см. в этом сообщении).
Без этого любой супер-пупер-редактор, каким бы визуально-структурным он ни был (пусть даже там будут реализованы все частные графит-языки, придуманные мной ;)), превратится для массового пользователя, желающего формализовать профессиональные знания, в проблему даже при когнитивной эргономичности его интерфейса и технической эффективности как приложения. Ибо придётся как-то "подгонять" допускаемые представления документа и операции над ним под реальные требования - а это лишняя работа, та же "избыточная сложность" - не говоря о том, что некоторые вещи и не получится реализовать таким путём.
Конечно, это относится как к любому готовому инфопрогизделию, так и к любому проекту требований на него - начиная с концепции инфор-документа. Именно поэтому РДП-требования сочетают лист-силуэтную основу графбазированного представления документа со стандартной структурой докэлементов. И прорабатываются в направлении предоставления пользователю средств управления этой структурой.
Конечно, из тех же стандартных 30 типов реквизитов документа активно используются едва ли десяток-дюжина - но и их нужно определить (притом информатизованно - как прототипы конечных структур данных). Некоторые специфичны только для текстовых или для графических в стандартном понимании документов - и чётко там описаны.
    Кстати, поэтому детально не определяются реквизиты РДП-листа - в ЕСКД есть про форматы и основную надпись, а в условном шаблоне, как можно видеть, колонтитулы представляют как раз их упрощённую (и учитывающую машинный документооборот) версию.
    Также не определено представление для формул и динатабов - предполагается, что они готовятся внешними средствами и вставляются как объекты (изображения или внедрённые) - аналогично неграфовым иллюстрациям.
    Возможно, такие решения нужно обсуждать - но следует отметить, что РДП-документ мыслится как интегрирующий результаты относительно специализированной переработки данных об объектах деятельности в других приложениях (расчётно-логической, специально-оформительской) - а не как заменяющий их. Сама РДП-среда обрабатывает (для чего и содержательно представляет внутри себя) только структуры деятельности (в т.ч. реализуемой [программно-]аппаратно).
    Ещё один вопрос - об авторизации редактирования документов. Пока предполагается, что для каждого объекта, представленного РДП-переменной, ведутся версии по пользователям и меткам времени, и в редакторе можно сличать версии (с отображением разницы). Возможно, следует принять подход офисных пакетов - вести непосредственно исправления по авторам и меткам с возможным добавлением обосновывающих комментариев - но это м.б. сложнее в реализации.

    Здесь и в общеязыковых требованиях также не детализируется представление о графит-вершине как модельном объекте (логика как оператора визуализируемого языка) и как элементе графит-схемы (физика как одно/многоячеечной автофигуры на листе). Отчасти эти вопросы разбирались, напр., для своей реализации Дмитрием_ВБ в этой теме.
Сказанное распространяется на другие концепции инфор-документа, такие как схемокурс, Ты-проект, "текст как интерфейс" - но последняя-то как раз даёт пример разумной информатизации на текстовой базе. Более того, наметилось движение к совместимости её реализации в ББ-среде со стандартами документов - примером может служить появление построителя оглавлений по заголовкам. Кроме того, что это стоит продолжить, единственное, что можно заметить - для массового пользователя-непрограммиста д.б. привычный интерфейс редактирования - впрочем, ББ-среда позиционируется для программистов. Ряд операторов ЛС-диалекта в принципе соответствует сущностям "текста как интерфейса" - так, ЛС-вставка может пониматься как визуальный коммандер.
Некоторые концепции (как-то PureBuilder-документа), видимо, ещё не вполне определены (во всяком случае, форма PureBuilder-описания или извлечения из него как документа, допускающего согласование и визирование, на сегодня неясна).
    По поводу РВ-интерфейса можно также заметить вот что. Распределение категорий содержания документа по вкладкам вполне удобно для программного проекта как "вещи в себе". Когда же мы документируем порождающую его задачу, тем более во взаимосвязи с другими задачами, то нужно найти каждому программному компоненту (в его видимом представлении) место в документе. И вкладки естественно назначить уже документам - а также компонентам содержания, не вошедшим (быть может, временно) в документирующие структуры.


Чтобы показать, как сделан макет, здесь приводится файл с выдержкой из его подлинника:
Вложение:
Комментарий к файлу: Макет бланка РДП-документа (начало).
РДП-макет А2LS [имя-РДП-докум] (бланк 2xA4LSx2, с титулом).odg [273.26 КБ]
Скачиваний: 461

Включён только титульный раздел, т.к. объём файла Draw растёт с увеличением числа врезок-таблиц (которыми смакетированы жёсткие поля), а для иллюстрации этого достаточно.
    Если взглянуть на лист-силуэтную структуру документа, то можно сказать, что она в некотором смысле представляет дерево докэлементов (схемных; понятно, что внесхемные образуют альтернативное дерево, где все вершины "на одной ветке"), "прошитое" регулярными ссылками (по адресам строк; нерегулярные - из текстов вершин - конечно, должны представляться отдельно, если это требуется) и помеченное наборами атрибутов вершин.
    Конкретно титульный раздел играет роль интерфейса к элементам структуры (естественно, находящимся за его пределами :); сам раздел есть предопределённое содержание РДП-документа и управляется из РДП-редактора только в плане показывать/скрыть); на макете показан общий состав, а использование в сочиняемой части определяется вручную.

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

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

Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/