Вот тут встал вопрос о том как "раскладывать" экранные листы для вывода твёрдых копий...
Вообще это частная составляющая ситуации - с того момента, как встал вопрос о визуализации знаний "предметниками", мы находимся на этапе техподготовки производства моделей как массовых изделий, и определяющим становится фактор экономии живого труда сочинителя (прежде всего умственного в данном случае - но и затрат на моторику работы с консольными устройствами тоже). Оцениваются же трудозатраты, как обычно, такими показателями:
* норма времени на изготовление (здесь - двуединый процесс оформления-досочинения дракон-схемы по первоначальной задумке) - о сущности и значении этого фактора хорошо сказано у Грабина (можно посмотреть выдержку в этом сообщении).
* сложность изделия (здесь - не когнитивная, а структурно-элементная);
* сложность техпроцесса изготовления.
Норма времени в конечном итоге определяется сложностью обеих родов, но опосредованно - работник может по разным техпроцессам уложиться в норму на одно и то же изделие, но затратить разные усилия.
Сложность оценивается как субъективно, так и объективно (насколько возможно). Существуют способы нормирования времени изготовления от сложности программ - хотя бы методики Б. Боэма - где, кстати, есть что-то и о блок-схемах. Однако нужно развивать это для визуализации - и тогда важно иметь качественное представление о сложности именно полноценных информоделей деятельности.
Очевидно, труд сочинителя мы должны беречь - а его затраты складываются не только из усилий на понимание диосцены и целевое действие над её содержимым, но и из расхода сил на неоптимально оформленное ожидание результата исполнения своих команд, на осмысление и исправление того, что автоматически делается неестественным образом или не делается, хотя должно бы.
В случае формализации это связано ещё и с тем, что для предметника это не основная деятельность, а "общественная нагрузка", на которую ему часто не выделяют нужных ресурсов.
Пример из жизни - как делается описание бизнес-процессов для СМК? Мало того, о чём уже писал - специалист СМК обычно лишь подвергает документы описания нормоконтролю и оформляет их в дела - больше его просто ни на что не хватит, а заняться ему ещё есть чем ; но и для подготовки описаний обычно выделяется один специалист в крупном подразделении, который знает его процессы и создаёт описания, минимально консультируясь с другими участниками (читатель, видимо, уже догадался, что в этой роли доводилось выступать и мне ).
Это реальность, и её требования поистине олимпийские - быстрее, адекватнее, понятнее. Часто моделирование деятельности проводят лишь "для галочки", но если мы ориентируемся на серьёзное - тем более надо учесть, что это работа творческая, идеи совершенствования процессов приходят неожиданно, а времени и сил на их оформление (хотя бы закрепление в эскизах) всегда будет нехватать.
Сложность описания как изделия предопределена свойствами языка и допускаемым методом "говорения" на нём.
Могу привести опять-таки пример из жизни - для описания логики процессов в СМК нам был спущен некий язык блок-схем. Там мало того, что, как водится, условие ромбом и никаких шампур-икон, кроме действия, нету, но применялись межстраничные соединители (вставки-то не предусмотрены) и игнорировался принцип главной вертикали (т.е. выходы блока условия "распальцованы" влево-вправо - как в 1С-алфавите в этом сообщении - потому сразу и отнёсся к нему иронически), а в результате сколько-нибудь сложные маршруты, конечно, запутывались. Правда, паллиативное средство было предусмотрено - схемы предлагались литеральными (чтобы блок был маленьким), литера имела смысл номера блока на схеме, а схема... вписывалась в колонку таблицы пооператорно (на листах А4!) - в другой колонке давалось имя оператора. Расшифровка содержания по номерам шла отдельным текстом.
Так вот, чем кончилось внедрение этого - схемы предметники стали рисовать БЕЗ всяких таблиц и укрупнённо, чтобы влазило на один лист ("...а медикаментов груды - в унитаз, кто не дурак." (С) В.Высоцкий )) - ну а имена операторов помещались там, где расшифровка. Можно понять всю "наглядность" такой модели - однако на исходном языке она была гораздо хуже.
А кстати, для сложных ветвлений в 1С-алфавите, напротив, принят принцип шампур-метода - точка выбора варианта, видимо, предполагает выходы горизонтально в одну сторону. Вот такой анархизм: "это у автора мне понравилось - приму, а это не понравилось/непривычно - сделаю по-своему" надо преодолевать - тем более, что это может искажать позицию автора (хоть он, возможно, и не всегда будет возражать против этого). Анархизм другого рода - как описан выше для блок-схем - есть защитная психологическая реакция (в ИП называют "избегание/отказ") на неестественность условий достижения цели и может преодолеваться только совершенствованием этих условий (в данном случае языка); но для внедрения этих усовершенствований нужно приводить аргументы именно экономические - позволит ли это "добавлять стоимости" быстрее и с меньшими издержками?
Среда может накладывать дополнительные сложности на "устройство" описания, но они д.б. "упрятаны" в машинное представление и автоматические (запрограммированные) операции над ним.
О методах уже, похоже, договорились - выделяются строгий и нестрогий. Оба нужны, оба уместны в ходе работы над одной и той же моделью - и значит, должны поддерживаться в РДП-системе.
Сложность же техпроцесса определяется во многом свойствами оборудования и приспособлений, образующих среду переработки.
Можно сравнить опять-таки с материальным производством. При этом не будем обсуждать, скажем, как делаются лодки в СПО "Арктика" - можно легко прийти к разглашению гостайны - возьмём что-нибудь общего пользования. Всем знакомые электролампочки накаливания делаются на роторно-конвейерных линиях, придуманных нашим соотечественником Кошкиным (вообще-то сначала для патронного производства). Станок такой линии устроен весьма сложно (можно посмотреть, напр. во 2-м изд. БСЭ) - но на нём за один оборот роторного стола собирается лампочка полностью. А вначале лампочки, конечно, делались вручную.
Среда визуализации, установленная на АРМ, и есть не более чем такой станок - или верстак с напильниками и другими ручными инструментами, каждый из которых надо брать в руки, что-то с ним делать, потом класть на место, брать следующий... - вот от такого типа деятельности оператора-сочинителя надо решительно уходить.
Что имеется в виду применительно к визуализации? Прежде всего - естественная модель организации икон и дракон-схем на диосцене - как мы можем рисовать схемы вручную, так и должно допускаться на экране (с учётом новых возможностей динамики объекта), а значит, необходимы:
* свобода размещения графоэлементов - поддержка планов глубины, области схем произвольной формы; должна допускаться внесхемная графика - на лист по желанию накладывать фигуры с редактируемой геометрией (прежде всего элементы КогниСтиль - которые, кстати, реализованы в 1С-алфавите как "декоративные");
* возможность выбора кегля/формата шрифтов абзаца и знака для текста каждого графоэлемента (поля иконы);
* вызываемая рамка/штамп листа, причём сменная, в т.ч. по ЕСКД, IDEF или ещё чему-то;
* сетка для икон/линий по обеим координатам (с возможностью привязки).
Далее - диалог д.б. естественным для человека с учётом WIMP-концепции интерфейса, а значит:
* всё с объектами должно делаться мышью, без исключений;
* клавиатурная команда предусматривается как вариант для некоторых операций (в основном шаговое перемещение подгоняемых объектов);
* никаких безответных ожиданий исполнения команд (если продолжительное - выводим прогресс-индикаторы, поэтапные информаторы и т.п.);
* тем более - никаких "спецэффектов", напр. в виде мерцаний при перечерчивании. Человек смотрит на экран и не должен утомляться от этих "инфотерактов" или отворачивать глаза, чтобы "увернуться" от них.
Ещё формат машинного представления модели - здесь такие вопросы:
* об открытости - конечно да, но есть ещё предложения, чтоб был человекочитаемым. Уже предложены форматы: текстовый от Дмитрия_ВБ и XML от vladfind; есть над чем подумать...
* о структуре - хотелось бы, чтоб состоял из одного файла (м.б., как в семействе Open Document Format, архивом документа, обрабатываемым средой - тогда, надо думать, человекочитаемость файла обеспечивается только внутри неё). При совместной работе модель часто нужно будет передавать - не нужно лишней нагрузки на операторов, неизбежной при многофайловости.
Ну и альфа и омега языка - алфавит - нужно дать полноценный для системного моделирования, что предполагает:
* возможность рисовать пользователю свои элементы и объявлять их иконами (или переносить их форму/структуру полей на иконы, как в DesignIDEF);
* реализацию некоторых общезначимых наборов знаков, скажем, того же КогниСтиль.
Наконец, никаких завышенных требований среды как приложения к платформе - должна работать на любом "бюджетном" автораме, а это значит - в конфигурации, характерной за несколько лет до её выпуска. Массовая формализация будет проходить в любых условиях, особенно если "моду на менеджмент качества" спустят организациям любого масштаба и формы собственности (напр. как результат вхождения в ВТО), и никакой малый бизнес не будет апгрейдить железо и ось ради неизвестного (ему
) ДРАКОНа...
Множество (но взаимоувязанное) языков необходимо и для того, чтобы воплотить идею vladfind о создании базы знаний в предметной области - одним ЯПЗ не обойдёшься. Достаточно сказал об этом
в этом сообщении; в качестве более широкого определения языков для такой базы можно ещё посмотреть Агафонова, вложенного
в это сообщение; там же в другом вложении о концепции "трёх схем" представления знаний, а о том, как я понимаю расширенную интерпретацию этой концепции, написал
в этом подпункте.
Какие же операции следует прежде всего "упрятать" в алгоритмы работы РДП-системы и что они должны давать сочинителю в автоматизированном исполнении? Здесь говорю о наиболее очевидном и настоятельном; возможно, что-то впоследствии дополню.
Во-первых, перечерчивание схемы после геометрических изменений - то, что в Ты-среде сделано, и очень правильно - но по описанию от разработчика
в этом сообщении как раз видно, что принятая модель организации листа не даёт получить полноценный результат, когда всё перемещается наиболее естественным, ожидаемым образом (свою т. зр. высказал
в этом сообщении).
Во-вторых, вывод твёрдой копии - прямо из среды с автораскладкой (деление по ячейкам-страницам закладывается в модель организации листа, параметры деления настраиваются пользователем).
В-третьих, генерация исходного текста (то, что и делает среду визуализации системой программирования) - нельзя программиста/спецификатора нагружать "определением правил трансляции" и "посточисткой" текста от меташаблонных элементов.
Почему в дракон-системе для "Бурана" человек "нажимает кнопку и получает ишный файл", который можно сразу передавать в текстовый транслятор? Да потому,
IMHO, что язык этой системы - ГРАФИТ-ФЛОКС - один импер- и один деклар-язык, а по сути - единый прогязык, структурированный согласно классификации частных знаний Паронджанова, с отработанной реализацией, а не некое множество прогязыков, на каждый из которых приходится транслировать полувручную. Возможно, не только в этом дело - но и это "не только" профессионалы-разработчики РДП-систем должны выявить и исключить в практически пригодной массовой реализации.
Все правила трансляции на прогязык д.б. определены при разработке РДП-системы - естественно, для случаев, когда язык текста икон является прогязыком. Дмитрий_ВБ подошёл к определению механизмов этого - наверное, это подлежит дальнейшему развитию и уточнению.
В-четвёртых, конечно, нестрогие преобразования топологии схем - точнее, их синтаксический контроль. Для пересадки лиан как пример описал ситуацию
в конце этого сообщения; свои особенности будут и у заземления лиан.
В-пятых - операции определения существенных характеристик деятельности по построенным моделям. Здесь и имитомоделирование ("прогон" с получением временной диаграммы исполнения, для чего определяются протоколы и задаются нормы времени исполнения для вершин), и вычисление трудоёмкости (по заданным показателям операторов). За основу можно взять то, что определено в том же DesignIDEF. Это следует считать опцией, и потому, наверное, реализовывать как "плагины", работающие с файлом модели.
В-шестых и едва ли не в главных - механизм исправлений/рецензирования, который есть давно и в офисных пакетах. С одним файлом (комплектом) модели в общем (и практически распространённом) случае работают не только разные исполнители, но и разные сочинители - напр. предметник, аналитик и программист - да и каждая из этих ролей м.б. представлена коллективом. Методика коллективной работы известна, напр. из стандартов IDEF.
Тут говорилось о компромиссе между программистами и предметниками. Можно предложить такие направления его достижения:
* включать/отключать строгий грамматический контроль, как это сделано в том же DesignIDEF (сохраняя минимум правил, допустим, описанный в п/р 2 Задачи 1.1.1 из Приложения 4 Драконографики);
* закономерно "менять костюм", т.е. немаршрутный язык дракон-схем, от обычного к программному (тем самым устанавливая иерархию нормализации импер-отношений); это уже некоторым образом реализовано в Ты-среде, но нужно не просто выбирать язык, а именно формально связать одно описание с другим (м.б. как декомпозицию).
Возможно, это и будет достаточным.
Как можно ввести иерархию нормализации? Мне видится такой путь - реализовать режим сочинения, в котором выбор вместо неформального языка одного из формальных означает, что каждая шампур-икона схемы неформального языка рассматривается как своеобразная "икона Область" (описана
в этом подпункте) - т.е. её нужно независимо детализировать иконами с формальным текстом - нешмапур-иконы же (ветвления) остаются самими собой, но требуют формальной записи логвыров от величин формального текста. Т.о., получается вторая схема одного процесса, композиция частей которой задаётся первой схемой.
Если в РДП-среде определена многоуровневая иерархия формальности языков, то имеем ряд схем, полученных последовательно детализацией икон предыдущей (хотя больше трёх уровней смысла не вижу - допустим, текстовая-математическая-прогязыковая, а в конкретике, скажем: русскоязычная - словесно-формульная - Оберон-2+пультовые языки непрограммируемых сочинителем устройств).
Реально, разумеется, можно разрабатывать то одну, то другую схему, поскольку процессы взаимозависимы - и при каждом изменении высокоуровневой в среде перестраивается непустое содержание низкоуровневых (а пустое можно показывать вершинами более высоких уровней с указанием, что они на этом уровне ещё не определялись). Разными языками вообще могут пользоваться разные люди (на разных, но связанных по данным АРМ) - файл модели просто передаётся между ними.
Можно заметить, что есть детализация икон на "управленческом" уровне и на "программном" - но это разные т. зр. на одну и ту же вершину в одной схеме. Это должно дополнять иерархию разных схем - но, возможно, смыслы приложений здесь потребуется уточнить (у меня не вызывает сомнений именно управленческий, т.к. смысл любого оператора, конечно, определяется в первую очередь какими-то нормативными документами).
Тем самым мы можем реализовать описанную
в этом подпункте детализацию от дракон-эскиза к дракон-руководству. В общем случае эта детализация также приводит к тому, что одной частью руководства служит дракон-программа/система программ, а другой - дракон-инструкция, что с устройством, исполняющим эту программу/систему, делать человеку; притом любая одна из частей необязательна). Возможно, стоит заложить подержку какой-то концепции явной декомпозиции руководства, но над этим надо ещё подумать (обычно сочинитель творчески выделяет машинно-исполняемые части).
Итак, чтобы сочинителю было проще - среда д.б. сложней устроена внутренне. Между прочим, и труд сочинителя-программиста тоже экономить надо...
Главный критерий функциональной оценки РДП-среды отныне должен быть - трудоёмкость как нормы времени на построение моделей (дракон-схем и не только) различной сложности из некоего эталонного набора в совокупности с оценкой участниками трудности этой работы в различных аспектах. На снижение её в таких измерениях д.б. направлены основные усилия разработчиков; все их замыслы нужно поверять этими критериями.
Главный же целевой критерий - возможность формального описания реальных процессов - с учётом динамики состава и свойств семейства языков это значит, что среда д.б. открытой для развития.
Если будем игнорировать сложность работы в среде визуализации для реальных целей и в реальных условиях - значит, "интеллектуально тероризируем" сочинителя - притом, что для читателя получаемый результат м.б. вполне приемлем по качеству. В результате сочинитель помянет не раз недобрым словом эту среду - и рано или поздно это перенесётся на сам язык - психология есть психология. Как итог устроим для ДРАКОНа ситуацию "1941-го года" - аудитория пройдёт естественный путь от "этого не может быть" до "это уже всем ясно", потянется к языку и в большинстве своём разочаруется, столкнувшись с "неготовностью к войне" как тяжестью автоматизированного рисования дракон-схем (и лёгкость атрибуции икон приложениями и пр. не спасает - это другой вопрос формализации, к тому же основа моделирования именно в схеме произвольной сложности - иначе оно не есть визуальное).
Ну и ещё раз напомню, что нужно дать более широкие возможности оформления графо- и текстоэлементов - это уже чтобы не "терроризировать интеллектуально" читателей моделей. Даже перед самой кодогенерацией (а равно и после неё) описание в среде - это символический документ, и так его и нужно представлять - для человека, а не для машины.
Здесь ещё один резон - для первоначальной схематизации нужен язык, позволяющий структурировать документ на иконы (подобно ГНОМ), в которые вписывать как рисунки, так и текст - и конечно, текст д.б. оформлен не хуже, чем в инфордок-процессорах офисных пакетов. Тогда будет удобно определить весь комплексный текстово-графический документ внутри РДП-среды как схему на таком языке - но язык д.б. шире ГНОМа и вообще устроен иначе, чтобы возможно было и сочинять, и читать документ на листах произвольных форматов - подошёл бы КогниСтиль с его областями, в которые можно вписывать другие области (включая схемы на других языках и пояснители), свободно компонуя их на листе. Формат листа, кстати, лучше менять от страницы к странице - или ввести, как в ЕСКД, разделение документа РДП на текстовую и графическую части (м.б. условно, имея в виду, что формат листа первой всегда А4, но туда можно помещать и рисунки; формат второй же выбирается любым из ряда).
И между прочим, хоть я и спорил с Дмитрием_ВБ по ряду упрощений языка, но не могу не согласиться с его позицией в другом - человеку надо дать полноценный язык представления знаний, но в то же время оправданно упростить работу с этим языком, перекладывая на РДП-среду максимум рутины. При этом всё сказанное следует рассматривать именно как требования к перспективной среде, а не как оценку существующих решений - понятно, что не всё сразу получается, главное - чтобы взгляд "от предметника" был осмыслен, уточнён (не только мной), и соответствующие ему изделия подоспели как раз к моменту, когда интерес к ДРАКОНу и другим языкам визуализации знаний начнёт у широкой аудитории становиться конкретно-практическим...