DRAKON.SU

Текущее время: Пятница, 13 Декабрь, 2019 16:41

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 51 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Ещё о предложениях Дмитрия_ВБ
СообщениеДобавлено: Вторник, 06 Апрель, 2010 22:23 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Разбираясь с описанием исполнителей, увидел кое-какую аналогию со структурой программ и интересную возможность интерпретации ВЯЗБС-силуэта; отсюда новая редакция обзора предложений, заменяющая прежнюю в этом сообщении. Ну и кое-что ещё изменено и дополнено.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: О визуализации цикла Дейкстры
СообщениеДобавлено: Четверг, 08 Апрель, 2010 04:47 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Нашлось немного времени на вопрос, поставленный в этом сообщении. Предварительный результат получился с применением для цепочки развилок (которой соответствует ТЯП-оператор IF-ELSIF-END) инверсной записи и выглядит так:
Вложение:
Рисунки А4 Цикл Дейкстры - визуализация (инверсная).png
Рисунки А4 Цикл Дейкстры - визуализация (инверсная).png [ 69.55 КБ | Просмотров: 14915 ]

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Апрель, 2010 05:07 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Вот тут встал вопрос о том как "раскладывать" экранные листы для вывода твёрдых копий...
Вообще это частная составляющая ситуации - с того момента, как встал вопрос о визуализации знаний "предметниками", мы находимся на этапе техподготовки производства моделей как массовых изделий, и определяющим становится фактор экономии живого труда сочинителя (прежде всего умственного в данном случае - но и затрат на моторику работы с консольными устройствами тоже). Оцениваются же трудозатраты, как обычно, такими показателями:
    * норма времени на изготовление (здесь - двуединый процесс оформления-досочинения дракон-схемы по первоначальной задумке) - о сущности и значении этого фактора хорошо сказано у Грабина (можно посмотреть выдержку в этом сообщении).
    * сложность изделия (здесь - не когнитивная, а структурно-элементная);
    * сложность техпроцесса изготовления.
Норма времени в конечном итоге определяется сложностью обеих родов, но опосредованно - работник может по разным техпроцессам уложиться в норму на одно и то же изделие, но затратить разные усилия.
Сложность оценивается как субъективно, так и объективно (насколько возможно). Существуют способы нормирования времени изготовления от сложности программ - хотя бы методики Б. Боэма - где, кстати, есть что-то и о блок-схемах. Однако нужно развивать это для визуализации - и тогда важно иметь качественное представление о сложности именно полноценных информоделей деятельности.
Очевидно, труд сочинителя мы должны беречь - а его затраты складываются не только из усилий на понимание диосцены и целевое действие над её содержимым, но и из расхода сил на неоптимально оформленное ожидание результата исполнения своих команд, на осмысление и исправление того, что автоматически делается неестественным образом или не делается, хотя должно бы.
В случае формализации это связано ещё и с тем, что для предметника это не основная деятельность, а "общественная нагрузка", на которую ему часто не выделяют нужных ресурсов.
    Пример из жизни - как делается описание бизнес-процессов для СМК? Мало того, о чём уже писал - специалист СМК обычно лишь подвергает документы описания нормоконтролю и оформляет их в дела - больше его просто ни на что не хватит, а заняться ему ещё есть чем :); но и для подготовки описаний обычно выделяется один специалист в крупном подразделении, который знает его процессы и создаёт описания, минимально консультируясь с другими участниками (читатель, видимо, уже догадался, что в этой роли доводилось выступать и мне :)).
Это реальность, и её требования поистине олимпийские - быстрее, адекватнее, понятнее. Часто моделирование деятельности проводят лишь "для галочки", но если мы ориентируемся на серьёзное - тем более надо учесть, что это работа творческая, идеи совершенствования процессов приходят неожиданно, а времени и сил на их оформление (хотя бы закрепление в эскизах) всегда будет нехватать.

Сложность описания как изделия предопределена свойствами языка и допускаемым методом "говорения" на нём.
    Могу привести опять-таки пример из жизни - для описания логики процессов в СМК нам был спущен некий язык блок-схем. Там мало того, что, как водится, условие ромбом и никаких шампур-икон, кроме действия, нету, но применялись межстраничные соединители (вставки-то не предусмотрены) и игнорировался принцип главной вертикали (т.е. выходы блока условия "распальцованы" влево-вправо - как в 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, но туда можно помещать и рисунки; формат второй же выбирается любым из ряда).

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


Последний раз редактировалось Владислав Жаринов Понедельник, 19 Апрель, 2010 04:49, всего редактировалось 3 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Апрель, 2010 20:42 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Драконограф

Написано много, отвечу частично и позже.

Разработка и.с. DRAKON выполнена в соответствии с книгами В.Д. Паронджанова и действующим стандартом ГОСТ 19.701-90. Пользователь с ними давно знаком.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 17 Апрель, 2010 04:58 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Ну что же, vladfind в этом сообщении внёс конкретные предложения - и сразу, как и от предложений Дмитрия_ВБ, пахнуло "солёным ветром моря практики". Если двигаться в этом направлении - создания среды визуализации не просто программных решений, а системы произвольных знаний о решении задач - то выделяются три группы вопросов организации дела:

А) Сущность фазы разработки в составе пожицикла системы/среды как изделия. В настоящее время мы имеем дело с общедоступными инфопрогами - но вот vladfind в следующем сообщении спросил: а где можно найти исходные тексты и концепции - и сразу высветил, что на самом деле важна не только свобода получения, но и открытость изделия.
Как это влияет на ход разработки? Дело в том, что открытость означает, что сочинитель:
    * сначала формулирует явно техзадание (или принимает внешнюю формулировку, выработанную, возможно, с его участием);
    * далее разрабатывает по требованиям техзадания изделие и документацию (базовую) на него;
    * затем документированно оценивает степень достижения заданных показателей - "<это, это и это> реализовано полностью, <это и это> - в <такой-то части>, а <это> не удалось вообще" - но не ограничивается констатацией фактов, а делает выводы по существу - "я считаю, что <это> не удалось потому, что <такое-то> техтребование невыполнимо в силу <таких-то соображений теоретического|прикладного порядка>", "а <это> потому, что <такие-то мои проектные решения|свойства выбранных мною средств, технологий реализации> оказались неоптимальными; для преодоления этого, считаю, нужно <делать так-то и так-то>, <пользоваться тем-то и тем-то>";
    * всё это представляет для всеобщего сведения.
Только в этом случае мы можем говорить об открытости разработки. Поскольку речь идёт о её использовании прежде всего в учебных и научных целях - то изделия д.б. и свободно распространяемыми (на условиях, аналогичных лицензии GNU).
Помимо повышения качества изделия и его эксплуатации потребителями, это облегчит как сопровождение изделия, так и утилизацию его решений в новых изделиях того же разработчика (возможно, совершенно иного назначения и необязательно некоммерческих).

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

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

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

    * Визуальная отладка дракон-модели по принципу "рабочей точки".
Обеспечивает симуляцию (имитомоделирование исполнения) отдельно взятой дракон-модели прямо из редактора. Как я это вижу - описал при рассмотрении предложений Дмитрия_ВБ в п/п 2.1.2.5 этого документа - по сути это интерпретирующее выполнение дракон-Х-модели без получения исходного текста на языке Х в отдельном трансляторе. Наверное, у программистов будет больше конкретики, как делать это.

    * Трансляция дракон-программ на базовый текстовый прогязык.
Естественным образом вытекает из первого пункта. Нужно обеспечить существование дракон-программ как части дракон-руководства наряду с дракон-инструкциями - именно так можно совместить разработку и документирование программ наиболее естественным для сочинителя образом.

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

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

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

    * Более сложные виды анализа моделей с настраиваемыми отчётами о результатах.
Как пример можно посмотреть возможности AllFusion Process Modeller (BPWin).
Вложение:
AllFPM-Внешние_связи.djvu [85.92 КБ]
Скачиваний: 254

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

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

    * Генерация инфологических моделей ("нейтральных схем") для баз данных и программ на языках СУБД.

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

В) Средства разработки и документирования самих средств разработки и документирования :). Коль скоро все поддерживаем визуальные языки - то не пора ли документировать и разработку самих средств визуализации на них? Разумеется, для этого ДРАКОН должен сочетаться с ЯПЗ других классов; так, можно исходить из следующего:
    * Для обобщённой визуализации задач я бы предложил IDEF0-язык. ФМ на нём может играть роль модулярной схемы.
    * Конечно, нужен метаязык описания языков - и естественной визуализацией РБНФ является синт-язык (опять же с силуэтизацией диаграмм, как описано, напр. в этом подпункте).
    * Нужно и определять язык визуализации структур данных, развивая то, что начато Я. Романченко.
    * ГОСТ 19.701-90 фактически устанавливает и языки описания исполнителей алгоритмов. Можно предложить СТО-язык с распределением его операторов по элементам блочной структуры исполнителя.
    * Необходим язык когнитивно-эргономичной схематизации РДП-документов в целом, который кладётся в основу их символического представления (оформления человеком для человека).
Здесь опять получится выгода и для коммерческой части разработок - их авторы, проходя путь визуализации открытой части сами (и/или разбираясь в пути других), приобретут опыт полноценного дракон-программирования реальных задач, что послужит совершенствованию и их продуктов. А если есть полноценный широкодоступный базис функций - нетрудно реализовать любые его расширения с учётом оценок широкого круга пользователей.
    Средства разработки для повышения гарантоспособности кода РДП-изделий я бы ограничил только "нетяжёлыми" и необъектными (в первую очередь Блэкбоксом) - но это всё-таки чересчур жёстко для начала. Но это не снимает ответственности за неуклонное улучшение данного показателя, как и за снижение нагрузки на человека и машину...

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

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

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


Последний раз редактировалось Владислав Жаринов Вторник, 20 Апрель, 2010 05:09, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Апрель, 2010 04:38 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
О требованиях к качеству инфопрогизделий
В связи со сказанным ранее об оценке реализации естественен вопрос: какова м.б. её единая основа? Показатели качества, данные в Драконографике, конечно, весьма общие. Более конкретна, напр., такая форма:
Вложение:
Комментарий к файлу: Свёрнутая форма (оценка наличия).
Протокол Оценка качества [имя-инфопрога] (бланк).odt [45.44 КБ]
Скачиваний: 421

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

В конце содержатся требования к качеству. На с. 55 описано средство прототипирования форм ГИО - интересно было бы узнать, имеются ли другие свободные средства такого рода, м.б. более развитые (на коммерческие типа Visio при некоммерческом проектировании, наверное, не стоит ориентироваться). Важно, что сквозной нитью проходит инженерно-психологический подход - нужно рассматривать средство в контексте работы, для которой оно предназначено.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Как устанавливать нормы времени?
СообщениеДобавлено: Понедельник, 19 Апрель, 2010 04:42 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Вот ещё выдержка из Грабина:
Вложение:
Комментарий к файлу: Начиная с середины с. 490 и до конца выдержки описывается роль нормы времени на изготовление и способы её установления.
Грабин-Оружие_победы-извл(норма времени).djvu [24.98 КБ]
Скачиваний: 277

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Апрель, 2010 05:22 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Геннадий Тышов писал(а):
Драконограф

Написано много, отвечу частично и позже.

Разработка и.с. DRAKON выполнена в соответствии с книгами В.Д. Паронджанова и действующим стандартом ГОСТ 19.701-90. Пользователь с ними давно знаком.


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

P.S. Кстати, в простом ответе "письмом на письмо" смысла не вижу (и потому, собственно, не ожидаю) - в рамках дракон-сообщества Вы ведёте свою важную работу, которая к тому же для вас неосновная, и абстрактная полемика отвлекла бы Вас от этого. Лучший ответ конкретный - публикация в дальнейшем документов, о которых говорилось ранее - авторских техтребований на Ты-среду (где будет и то, что vladfind называет "концепцией") и отчёта о самооценке - что удалось, что не удалось в данной версии. Простые заявления же о том, что каждая версия среды финальная и в ней реализовано всё задуманное вкупе с отсутствием исходных текстов как раз указывают на закрытый характер разработки - что нисколько не противоречит её свободной распространяемости - во введённой в этом сообщении "системе координат" оценки это просто разные измерения. Возможно, именно закрытый характер Вы и подразумеваете - но об этом стоит заявить явно с указанием мотивов. Рекламная ценность этого подхода, IMHO,
также относительна - когда у очередного пользователя пройдёт этап "любительского" интереса, он станет "верить только делам" - насколько удобна среда как инструмент повседневной работы при реальных условиях труда в полном цикле формализации знаний.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 23 Апрель, 2010 04:52 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Формализация "здравого смысла" на математической стадии используется для согласования суждений человека с его чувственным опытом, с фактами действительности. Кроме строгой логики, т.о. возникает многообразие псевдофизических, где выводы не "вечны", а ситуативны, участвующие объекты неопределённы. Если так посмотреть - и правда исчезает особая двойственность ИТ, и даже скорее не в силу нематериальности, знаковости - просто здесь постановки задач как точных предоставили возможность миновать "псевдофизику" и поначалу работать со строгой логикой и математикой.
В "псевдофизике" нужно определять понятия, связанные с пространством, временем, движением. Хорошая иллюстрация этому - примеры с мартышкой и детективной историей в отрывке из Мичи и Джонстона из этого сообщения (в книге есть и ещё на эту тему). Но для информоделирования этого мало - надо ещё переводить эти представления в деятельность - и тут вспоминается один случай из жизни.
    Иногда доводится бывать вблизи железной дороги - и как-то наблюдал следующую ситуацию. Бригада путевых рабочих сносит отслужившую своё опору контактной сети. Наверное, обычно это не представляет для них трудности - но тут в опору вросло дерево. Это ли сыграло роль или ещё что - но только пока проходил мимо, они всё время приступали к делу то так, то эдак, потом бросали и начинали спорить, а как надо. По примыкающему пути тем временем приближался состав. Иду дальше - бац, состав экстренно тормозит. Смотрю назад - они-таки спилили опору с деревом, но так, что она завалилась на пути - точнее, там между действующими опорами натягивается с обратной стороны такой трос, вот на него - но всё равно перекрывает габарит пути. Потом состав тронулся - хорошо, что товарный был, хоть торможение было не суперэкстренным, но какая-то часть пассажиров с багажом вполне могла с полок попадать :(
Что здесь важно? Математически существует некое исчисление физических действий для решения задачи - но при информатизации по нему нужно ещё построить алгоритм, дающий практически полезный результат. В данном случае "процедура вывода" этого алгоритма не сработала. А теперь представим себе, что бригадиру поручили формализовать процесс сноса опор. Пусть он даже хорошо знает, как писать - но не владея техникой вывода "по здравому смыслу", он не знает, что писать :) И поможет ли ему здесь обычная логика и математика - даже если он хорошо их знает по школе? По идее, "здравый смысл" формируется предшествующим опытом жизни - но для формализации надо сформировать ещё опыт отчуждения этого опыта. Не в том ли дело, что надо рассматривать "наивную физику и математику" явно и совместно со строгой, перекидывая мосты между ними?


Последний раз редактировалось Владислав Жаринов Пятница, 23 Апрель, 2010 06:38, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Некоторые теоретические вопросы
СообщениеДобавлено: Пятница, 23 Апрель, 2010 04:55 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Вот такие "детские" вопросы :)

1) В этой теме: viewtopic.php?f=79&t=2426&start=0 в частности, говорится о шампуре как о состоянии автомата, моделирующего программу. Однако шампур(ы) - это всего лишь укрупнение структуры программы. Наверное, новое состояние прежде всего порождается отдельным оператором и соответственно автоматный граф изначально строится на множестве икон? Более того, не примитивизируется ли силуэт для кодогенерации с устранением веточных икон (разрешённых БП) и соответственно с исчезновением оснований для выделения состояний по веткам силуэта?

2) Можно ли считать алгоритмом текст с неформальным языком операторов (напр. блок-схему с естественным языком текста)? И если визуализировать вот такую модель деятельности:
Вложение:
Орлов-МетаАРИЗ-схема.png
Орлов-МетаАРИЗ-схема.png [ 88.71 КБ | Просмотров: 14739 ]

будет ли она алгоритмом?
В частности, М.А. Орлов говорит о подобном в своей книге (с. 72; образ см. выдержку в этом сообщении):
"Само понятие «алгоритм изобретения» до сих пор иногда вызывает критические замечания. Критика аргументируется тем, что в наиболее известном определении алгоритма, ориентированном на программирование компьютеров первых поколений, нет места неопределенности. Но это слишком узкое определение даже для современной компьютерной математики, оперирующей понятиями размытых, вероятностных, итерационных, рекуррентных или еще более сложных алгоритмов. А с точки зрения современной конструктивной математики, а также математической лингвистики, оперирующих моделями категорий и функторов, афинными и более сложными отображениями, такое применение термина «алгоритм» является уже совершенно корректным."
Вопрос по-прежнему простой - снимает ли всё упомянутое неопределённость настолько, чтобы с его применением к неформальному [визуальному] описанию можно было построить [визуальный] алгоритм для формального исполнителя и далее [дракон-]программу? Ведь это всё в общем случае математика "необязательно конечная"... или как?

3) Не являются ли произвольные циклы без досрочных выходов просто "запутыванием" цикла Дейкстры - т.е. возможно ли делать с его помощью всё то, что делается посредством одной петли для сложного тела с "наворотами" continue? К этому интуитивно подводит визуализация цикла Дейкстры. И каковы в связи с этим возможности (и целесообразности) применения цикла Паронджанова (где сложное ветвление на выходе из ПОКА-тела аналогично досрочным выходам по break) ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 23 Апрель, 2010 05:02 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Некоторые практические вопросы
1) Как должен выглядеть машинный документ среды РДП? Представляю себе такие концепции его построения (названия условные):
    * натурализованный - просто поддерживает совокупность форматированных текста, таблиц, графики без фиксации их структуры (пример - документ в офисном пакете).
    * структурный - поддерживает динамическую структуру элементов-реквизитов, заполняемых пользователем; логические связи реквизитов вне структуры автоматически не интерпретируются (пример - любая БД, напр. в системах типа "Предприятие", документ SADT-пакета);
    * модельный - поддерживает логическую схему данных с установлением отношений между элементами не только по заданной структуре (то, что называется "базой знаний"; с учётом Фридланда так можно говорить лишь условно, примеры - системы типа гипотетической "семантической сети", Антиплагиата и т.п.).
Конечно, можно мечтать о том, чтобы РДП-система вела документы третьего типа - но думаю, успешно реализовать сегодня можно второй тип документа.
Возможно, общая структура должна образовываться как поля КогниСтиль, связанные на листе в синт-силуэт. Формат и размер полей настраиваются пользователем; содержание поля образуют текстовые абзацы, таблицы, графика - среди последней и визуальные модели на ДРАКОНе и других языках, и внесхемные графоэлементы. Иконы-метки горизонтального БП могут играть и роль запоминателей - для чего имеют, как и обычные иконы, также смысловую метку (понимаемую как термин, определением которого служат последующие поля строки).
Всё содержание отображается внутри поля; ссылки оформляются только как отдельные поля-вставки на другие листы/документы.

Кто как себе это представляет?

2) Можно ли понимать предложенное Дмитрием_ВБ в п/р 7.1 этого документа представление ВЯЗБС как "человекочитаемое" описание абстрактной коммутации между операторами и программами?

3) Можно ли рассматривать схемы деятельности с расщеплением рабочей точки как разновидность межпрограммных конструктивных схем?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Июнь, 2010 14:35 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Всем привет.
Давно не писал, но недавно появилось время,
чтобы сделать и выложить что-нибудь новое.

Предлагаю вашему вниманию программу ab 2.XX

Наконец-то я сделал к ab графическую оболочку !


Вложение:
Комментарий к файлу: описание ab 2.0
ab_htm.rar [81.81 КБ]
Скачиваний: 235


Последний раз редактировалось Дмитрий_ВБ Понедельник, 11 Апрель, 2011 12:45, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 28 Июнь, 2010 21:00 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Всем привет.
Подумал и решил своей авторской волей превратить программу
ab_vjaz в бесплатное ПО с открытым кодом, который и выкладываю.

Раз уж вопрос идет о создании открытого стандарта для
систем документирования ПО РВ, то думается мне, что и код
программы, реализующей предполагаемые концепции такого
стандарта, тоже должен быть открытым и создаваться
совместными усилиями.

re от 29.06.10: кстати, вот и первые исправления (вместо ab 2.1 ab 2.11):

1) Исключена возможность образования паразитной вертикали для действия
"ВЫХОД" (readfile.cpp, вставлена строка 560)
2) Изменен формат описателя заголовка блок-схемы, см. п.1. ab.htm (в
исходном коде - gbs.cpp, метод see_gbs, // рисуем заголовок)
3) Подчеркиваются метки действий, у которых есть ссылки
4) Приведен пример дерева достаточно сложных блок-схем в файлах
l_gac1.txt и rospusk.txt

re от 4.07.2010, ab 2.12 :

Для тех, кто не хочет связываться с AutoCadом, усовершенствовано
копирование ветки силуэта в bmp-файл. Ветка будет скопирована в bmp-файл
целиком, даже если для фонта 1 по высоте она вся не помещается в окне АВ.
Подробнее см. ab.htm в архиве ab_212.rar .

Вложение:
Комментарий к файлу: ab 2.12 с исходным кодом и примерами
ab_212.rar [459.58 КБ]
Скачиваний: 257


Вложение:
Комментарий к файлу: силуэт в ab
ab.JPG
ab.JPG [ 160.78 КБ | Просмотров: 14590 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Июль, 2010 09:11 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Всем привет.
Выкладываю появившиеся обновления.

Программа ab 2.14 с примером.


Добавления функциональности в версии 2.14 :

1) Тексты нужных процедур можно просматривать в окне браузера, если
разметить текст файлов исходного кода как pre-формат htm-файлов.
2) Поле поиска: кликнуть мышкой по полю ввода комбобокса и ввести
строку поиска, а затем нажать Enter.
3) Если html-ссылка не умещается в 40 символов, то можно задать ее
в несколько строк, которые будут восприниматься как одна строка.



В качестве примера взят приведенный в книге Б.Сойера и Д.Л.Фостера
"Программирование экспертных систем на Паскале", Москва, "Финансы и
статистика", 1990, проект простой экспертной системы на Паскале.
Проект перетащен под BCB с сохранением паскалевского модуля с основной
логикой работы экспертной системы. Unit1.cpp отвечает за диалог с
пользователем.
Проект находится в каталоге expsys.

Основные файлы проекта:

expsys.bpr - проект BCB
expsys.cpp - главный модуль проекта
exps.pas - модуль основной логики экспертной системы
Unit1.cpp - модуль диалога экспертной системы
Unit1.h - модуль определений для Unit1.cpp
expsys.txt - модуль проекта АВ с блок-схемами процедур
экспертной системы и со ссылками на остальные
файлы проекта
expsys.htm - краткий реферат книги "Программирование экспертных
систем на Паскале"

В файле ab.cfg нужно правильно задать пути к файлу expsys.txt и
к браузеру.
Т.к. пути к файлам в html-ссылках файла expsys.txt совпадают с путем к
expsys.txt, то пути к файлам в html-ссылках указывать не нужно, только их
имена.
При обработке из АВ html-ссылок на файлы exps.pas и Unit1.cpp перед
запуском браузера будет выполняться копирование: exps.pas -> exps.htm и
Unit1.cpp -> Unit1.htm .

Вложение:
ab_214.rar [451.13 КБ]
Скачиваний: 224


Вложение:
expsys.rar [453.83 КБ]
Скачиваний: 252


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 25 Август, 2010 22:51 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Когда нужно визуальное программирование ?

(мысли по дальнейшему развитию предлагаемой системы
разработки и документирования ПО)

---------------------------------------------------------------------
Илья Ермаков:

Оберон-парадигма в ИТ
Джоэл Спольски о сборке мусора
Добавлено: Понедельник, 09 Август, 2010 19:04 

Цитата:
В начале девяностых многие из нас полагали, что главная битва
произойдет между процедурным и объектно-ориентированным стилем
программирования, и воспринимали объектно-ориентированное
программирование как средство резкого повышения продуктивности
программистов. Я тоже так думал. Некоторые до сих пор так думают.
Получается, мы ошибались. Объектно-ориентированное программирование
прикольная штука, но не повышает продуктивность, как это обещалось.
Реальное и значительное повышение производительности мы получили от
программирования на языках, автоматически управляющих памятью
вместо вас. Это может быть подсчет ссылок или «сборка мусора», это
может быть Java, Lisp, Visual Basic (даже 1.0), Smalltalk или любой
язык написания скриптов. Если ваш язык программирования позволяет
выделять кусок памяти без раздумий о его последующем освобождении,
то вы используете язык с управляемой памятью, и вы будете
значительно эффективней программиста, использующего язык, где
управление памятью производится в явном виде.
---------------------------------------------------------------------

По аналогии с вышеприведенной цитатой можно предположить, что
визуальное программирование становится нужным, если оно позволяет
существенно сократить усилия программиста по вводу и проверке
правильности ввода маршрутной части алгоритма процедуры.

Выкладываю 2-ю часть предложений по развитию предлагаемой
системы разработки и документирования ПО РВ,
файл srdporw2.htm в rar-овском архиве.

Буду рад вашим замечаниям и предложениям.

Вложение:
srdporw2.rar [205.62 КБ]
Скачиваний: 247


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 27 Август, 2010 08:15 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий_ВБ писал(а):
...визуальное программирование становится нужным, если оно позволяет
существенно сократить усилия программиста по вводу и проверке
правильности ввода маршрутной части алгоритма процедуры.
...
Применимы ли все эти размышления для ускорения практического
программирования ?

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

Вообще-то практику нужно поддерживать наукой и учёбой - и Оберон именно на это рассчитан, являясь и производственным, и учебным языком. Есть простое конструктивное положение о соответствии текстового и графического языков - для сохранения смысла ТАЯ/ТЯП каждому типу его оператора в графе должен соответствовать тип вершины (вариант типа с особенностями графики/текста иконы/макроиконы) - а иначе и в том же Обероне можно было бы оставить только три типа операторов - Действие, Условие и Заголовок :) , а их почему-то там больше (см. спецификацию в этом сообщении). Тогда будет, IMHO, ускорение ввода и проверки не просто "сейчас" и "для меня", а вполне независимое от состава коллектива сочинителей - люди один раз изучают язык, а он им помогает эффективно структурировать каждое описание на этом языке и при сочинении и при чтении (в т.ч. "чужого" или "своего", но уже основательно подзабытого). А то будут создаваться лишние условия, чтобы получалось вот так:
Илья Ермаков в viewtopic.php?p=50098#p50098 писал(а):
Если говорить лично от себя, почему проблема столь наболевшая...
То это связано с невозможностью быстро пустить в проект ни одного из посторонних программистов. Есть острая - не то слово - необходимость именно в аккуратных, толковых исполнителях, которые могут реализовывать по заданию модули так, чтобы ведущий разработчик проекта был уверен на в них на 100%, как в своих. Чтобы с приходом нового человека в коллектив не возвращалось подзабытое слово "надо отладить".

Кстати, в своих первоначальных требованиях Вы тоже упоминали эту проблему (см. начало текста п. 1.1 вложения в это сообщение)... :wink:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 27 Август, 2010 19:15 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Драконографу:

Как-то так случилось, что на Паскале и Модуле-2 я программировал
под DOS, а к началу 2000-х в основном перешел на С/С++, хотя и
Паскаль не забывал. До Оберона так руки и не дошли.

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

По поводу рамок - это не вопрос.
У меня в текстовом формате можно в индексной строке задать тип
рамки, а дальше - уже программная реализация.
Например:

..14 f1 |+ 17
Условие выполнено ?

Задаем явно тип рамки равным 1.

Но, признаюсь, меня слегка напрягают блок-схемы с блоками сложной
формы типа "распечатать на АЦПУ" или "записать на диск", а также
диаграмы с текстами в облачках.

Я предпочитаю более строгий стиль, например:

Вложение:
actions.JPG
actions.JPG [ 48.34 КБ | Просмотров: 14360 ]


SOS получилось случайно, хотя и в этом есть, наверное, свой смысл.

Народ реагирует крайне вяло, а на основной вопрос - "Как вам нравится
новая реализация силуэта ?" только Вы мне и ответили, да и то, еще до
того как я выложил ab 2.0.

Я выкладываю предложения, чтобы получить замечания по делу. Но есть
ли у кого-нибудь интерес к этому делу ?
Я готов развивать ab дальше как opensource и учитывать все разумные
предложения, если, конечно, такие предложения будут.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 27 Август, 2010 23:09 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Дмитрий_ВБ писал(а):
Народ реагирует крайне вяло, а на основной вопрос - "Как вам нравится
новая реализация силуэта ?" ...

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

Весьма спорное утверждение.

Дмитрий_ВБ писал(а):
У меня в текстовом формате можно в индексной строке задать тип
рамки, а дальше - уже программная реализация.
Например:

..14 f1 |+ 17
Условие выполнено ?

Задаем явно тип рамки равным 1.

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

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

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

Дмитрий_ВБ писал(а):
... если программисты постепенно привыкнут так поступать.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 28 Август, 2010 10:26 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Ну вот это совсем другое дело. Наконец вижу конструктивную критику.
Правда, конкретных предложений по теме нет - у меня все-таки программистская тема, а не "Тенденции развития IT" - с
общими рассуждениями просьба туда, но на это замечание я отвечу, т.к. в нем есть все "общие" вопросы.

Ильченко Эдуард писал(а):
Чем Вам ДРАКОН не угодил? Всё просто и понятно даже не программистам. Проверено временем, людьми, техникой.


К самому ДРАКОНу существенных претензий нет. Если бы была мощная, эффективная (фокус в том, что эффективность
визуального программирования - значительное снижение усилий программиста при вводе маршрутной части алгоритма -
определяется не самим визуальным языком, а средой визуального программирования, реализующей этот язык) и полностью
отлаженная VIDE ДРАКОН, генерирующая полноценный код для всех распространенных ЯПВУ, я бы и сам такой средой
пользовался. Но и.с.Дракон Г.Н.Тышова пока на такое определение не тянет, а поскольку она не opensource, то другие
программисты помочь ему в разработке не могут.
"2 института 10 лет работали над разработкой САПР "ГРАФИТ-ФЛОКС ..." - у меня нет таких глобальных ресурсов.
Только иногда появляется свободное время по выходным. Да и не ставлю я перед собой таких глобальных задач.
Я заранее оговорил, что отказ от запрета на пересечение линий и от многочисленных правил ввода - это не покушение
на ДРАКОН, а способ существенно упростить написание моей программки.
Да и не ДРАКОН я пишу, а ВЯЗ БС. Я не ставлю задачи сверхвысокого понимания визуальной схемы. По мне, достаточно
уровня читаемости, сопоставимого с уровнем читаемости принципиальных электрических схем - одного из стандартов
современной технической документации.

И, кстати, я с самого начала написал, что мои предложения МОГУТ (но не обязательно должны - тут я с Вами полностью
согласен) заинтересовать в первую очередь программистов, поэтому не программисты пусть уж не обижаются.

Ильченко Эдуард писал(а):
В наше время компьютеру пора стили угадывать : ) Ну, или прогнозировать.


Ну да. "Приключения Электроника: До чего дошел прогресс - труд физический исчез, да и умственный заменит
электрический процесс". А людЯм что делать ?

Ильченко Эдуард писал(а):
Зачем вообще лезть в текст псевдокода, отображающего визуальный алгоритм?


Ну, некоторым программистам это нравится.

Ильченко Эдуард писал(а):
Вот если бы из всего этого некий программный продукт создавал документацию (кстати и ГОСТы всякие есть по оформлению доков) было бы замечательно. А если ещё и бесплатно, так и вообще сказка : )


Замечание про прогресс см. выше.

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


Когда я в 1989 закончил институт (я учился на факультете кибернетики, но тогда все наше реальное общение с компьютером
сводилось к выделению нам несколько раз в семестр машинного времени на ЕС ЭВМ, где мы прогоняли наши учебные
программы на перфокартах - а вот через несколько лет для студентов IT настала лафа - я им по-хорошему завидую) мне тоже
не нравилось документировать свой код. А сейчас мне уже 44, возможно, что мои лучшие годы как программиста уже позади.
Из институтов приходят молодые эрудиты (это я говорю про тех, из которых в будущем получатся настояшие программисты),
которые все схватывают на лету, и они тоже не любят документировать свой код. А через несколько лет, набравшись опыта,
они уходят на более высокооплачиваемую работу, оставляя свой недокументированный код, который другим приходящим
программистам приходится опять переписывать заново (Я подозреваю, что такая ситуация не только у меня в конторе). Впустую
тратятся большие силы, а Минобразования на 10% сократило число бесплатных мест в ВУЗах в связи с надвигающейся
демографической ямой. Мы живем слишком расточительно, 90% наших усилий пропадают зря. А хорошо ли это?

Все, на общие вопросы в этой теме просьба больше не рассуждать. Напоминаю - здесь тема
"СИСТЕМА РАЗРАБОТКИ И ДОКУМЕНТИРОВАНИЯ ПО РВ".
Убедительная просьба: писать только с конкретными предложениями по теме !


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Дракон-схемы - на поток
СообщениеДобавлено: Суббота, 28 Август, 2010 11:35 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий_ВБ в viewtopic.php?p=50794#p50794 писал(а):
Если пометить основные действия процедуры числовыми метками, а
затем в текстовом файле расшифровать, что они означают - то это
уже будет огромный рывок в документировании программ...

Я верно понял, что смысл этих меток - номер вершины (которой в ТФАП отвечает строка её текстового определения) для ведения связей в графе? Тогда пометка д.б. автоматической.

Эдуард Ильченко в viewtopic.php?p=50795#p50795 писал(а):
Дмитрий_ВБ писал(а):
У меня в текстовом формате можно в индексной строке задать тип
рамки, а дальше - уже программная реализация.

Программист, кроме всего прочего, должен вручную прописывать стили оформления? Абсурд какой-то. В наше время компьютеру пора стили угадывать : ) Ну, или прогнозировать.

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

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

Дмитрий_ВБ в viewtopic.php?p=50794#p50794 писал(а):
Но, признаюсь, меня слегка напрягают блок-схемы с блоками сложной
формы типа "распечатать на АЦПУ" или "записать на диск", а также
диаграмы с текстами в облачках.

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

Эдуард Ильченко в viewtopic.php?p=50795#p50795 писал(а):
Имхо, для качественного документирования ПО достаточно текстового описания для чего программа предназначена, как она это делает, ДРАКОН-схемы с необходимой степенью детализации (и лучше вообще человеческим языком) и самого текста программы с небольшими комментариями по ходу кода. Конечно, нужно ещё всякое другое, типа структуры классов, описание объектов, возможных событий, используемых протоколов, конфигурации железа, взаимодействия с интерфейсом и т.д. и т.п., но это уже мелочи : ) Вот если бы из всего этого некий программный продукт создавал документацию (кстати и ГОСТы всякие есть по оформлению доков) было бы замечательно. А если ещё и бесплатно, так и вообще сказка : )

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


И ещё раз об организации процесса. Не верю я, что оправданно заставлять, волюнтаристски цену сбивать - рабский труд неэффективен:) А вот если документирование неотделимо от программирования - это другое дело. А это достигается последовательной декомпозицией - напр. "областным методом", о котором говорил в этом сообщении. При этом процесс[ы] для программирования сочинитель выделяет из общей системы процессов задачи, организуя её как дракон-руководство - конкретно что я имею в виду, можно посмотреть в этом примере. Тогда отдельной программы для создания документации не надо - это будет "побочным эффектом" применения РДП-системы коллективом "предметник-аналитик-программист" (понятно, что я имею в виду роли, а не должности - это всё и один человек может совмещать, напр. создатель "утилитарного" инфопрога - если ему подготовка позволяет, а также инструментарий).
Что можно сказать о степени детализации? Это прямо связано со следующим утверждением:

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

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

Т.е. нужно комплексно решать вопросы визуального программирования даже для одного прогязыка. И это-то при внимательном рассмотрении не так просто - см. вопросы, затронутые для Оберона в этом сообщении.


Последний раз редактировалось Владислав Жаринов Воскресенье, 29 Август, 2010 03:45, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 51 ]  На страницу Пред.  1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2019, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB