OberonCore
https://forum.oberoncore.ru/

Обсуждение проекта PureBuilder
https://forum.oberoncore.ru/viewtopic.php?f=93&t=3133
Страница 6 из 7

Автор:  Сергей Прохоренко [ Суббота, 15 Январь, 2011 13:51 ]
Заголовок сообщения:  Re: Обсуждение проекта PureBuilder

Из насыщенного обсуждения здесь издесь я сделал следующие выводы применительно к PureBuilder:

В PureBuilder не применяются операторы перехода goto и операторы досрочного выхода exit, break, exit when, continue, return и аналогичные им.

В то же время, попытка все условия запихнуть в заголовок цикла приводит к совершенно нечитабельному коду такого вида:

Код:
WHILE (b # NIL)
   & P(b) & P2(first, b)
   & P3(ta, tb, init_transformed)
   & (~P4() OR (f(b) = count))
DO


Это, конечно, совершенно неприемлемо, поэтому:

Булевы функции в PureBuilder могут задаваться в табличной форме, аналогичной построителю запросов в MS Access
, или таблицами истинности. Такие функции удобны для применения в качестве условий в условных операторах и операторах циклов.

Автор:  Владислав Жаринов [ Воскресенье, 16 Январь, 2011 17:04 ]
Заголовок сообщения:  Re: Обсуждение проекта PureBuilder

Сергей Прохоренко писал(а):
Из насыщенного обсуждения здесь издесь я сделал следующие выводы применительно к PureBuilder:
В PureBuilder не применяются операторы перехода goto и операторы досрочного выхода exit, break, exit when, continue, return и аналогичные им.
...
Добавляет интереса к готовому изделию :)... наряду с подходом к показу связанности частей в различных аспектах:
Сергей Прохоренко в viewtopic.php?p=57512#p57512 писал(а):
Таблицы - не лучшая форма для наглядного изображения алгоритмов с циклами и ветвлениями. Вот использовать таблицы для объявления и спецификации переменных - другое дело!
...
Восприятие в любом случае фрагментами - голова ведь не ризиновая. А интеграция этих кусочков <модулей, процедур> в единое целое должна происходит на вкладках "модуль" и "проект". Кстати, там как раз должно использоваться изображение в форме графа. Реализация соответствующего интерфейса довольно сложна - ведь проблемы графов никуда не деваются, но форма графа здесь очень хороша для восприятия человеком. Однако изобразить в форме графа только крупноблочную структурную схему гораздо проще и дешевле, чем весь алгоритм...
Тут единственное что - структуру программы "с деклар-стороны" тоже можно показать графово - см. это предложение. Там предполагается, что таблица атрибутов (включая значение по умолчанию для переменной) связана с вершиной атомарного типа. Т.е. как раз имеем метод "ГРАФика И Текст/Таблицы" :) (предполагая, как обычно, что он реализован для показа/редактирования наряду с представлением в "чистом тексте").

Сергей Прохоренко писал(а):
...В то же время, попытка все условия запихнуть в заголовок цикла приводит к совершенно нечитабельному коду такого вида:
Код:
WHILE (b # NIL)
   & P(b) & P2(first, b)
   & P3(ta, tb, init_transformed)
   & (~P4() OR (f(b) = count))
DO
Это, конечно, совершенно неприемлемо....
Т.е. правильно, скажем, не продолжать в этом примере дальше линеаризовать тела ЦД-ветвей (в принципе можно, но тогда появится третья ветка)? А вообще если показывать логику дракон-развилками, как предлагается в /Паронджанов, 2001, Гл.9/ (и сделано для входов в ЦД-ветви в примере) - как это Вам?
Сергей Прохоренко писал(а):
...
Булевы функции в PureBuilder могут задаваться в табличной форме, аналогичной построителю запросов в MS Access, или таблицами истинности. Такие функции удобны для применения в качестве условий в условных операторах и операторах циклов.
Это не похоже на таблицы решений здесь? Кстати, есть и "графит-метод" - решающие диаграммы - как Вам?

Автор:  Сергей Прохоренко [ Воскресенье, 16 Январь, 2011 23:35 ]
Заголовок сообщения:  Re: Обсуждение проекта PureBuilder

Не думаю, что это надо применять в PureBuilder:
1) Таблицы решений содержат объединения ячеек и имеют тенденцию к расползанию вширь, причем плотность заполнения ячеек может быть существенно различной - появятся ячейки, для которых связи будут скрываться за пределами области, отображаемой на экране.
2) Решающие диаграммы не имеют каких-либо преимуществ перед таблицами истинности, но гораздо более трудоемки.

Автор:  Владислав Жаринов [ Понедельник, 17 Январь, 2011 07:24 ]
Заголовок сообщения:  Re: Обсуждение проекта PureBuilder

Драконограф в viewtopic.php?p=57868#p57868 писал(а):
Тут единственное что - структуру программы "с деклар-стороны" тоже можно показать графово - см. это предложение. Там предполагается, что таблица атрибутов (включая значение по умолчанию для переменной) связана с вершиной атомарного типа. Т.е. как раз имеем метод "ГРАФика И Текст/Таблицы" :) (предполагая, как обычно, что он реализован для показа/редактирования наряду с представлением в "чистом тексте").
Сергей Прохоренко в viewtopic.php?p=57751#p57751 писал(а):
...В то же время, попытка все условия запихнуть в заголовок цикла приводит к совершенно нечитабельному коду такого вида:
Код:
...
Это, конечно, совершенно неприемлемо....
...А вообще если показывать логику дракон-развилками, как предлагается в /Паронджанов, 2001, Гл.9/ (и сделано для входов в ЦД-ветви в примере) - как это Вам?

Сергей Прохоренко писал(а):
Драконограф в viewtopic.php?p=57868#p57868 писал(а):
Это не похоже на таблицы решений здесь? Кстати, есть и "графит-метод" - решающие диаграммы - как Вам?
Не думаю, что это надо применять в PureBuilder:
1) Таблицы решений содержат объединения ячеек и имеют тенденцию к расползанию вширь, причем плотность заполнения ячеек может быть существенно различной - появятся ячейки, для которых связи будут скрываться за пределами области, отображаемой на экране.
2) Решающие диаграммы не имеют каких-либо преимуществ перед таблицами истинности, но гораздо более трудоемки.
Насчёт таблиц согласен и здесь (как и со структурограммами) - в своё время и за это их критиковали. Насчёт БРД - как видим из источника, они как раз позволяют некомпактное в прямом произведении аргументов (таблице истинности) множество результатов представить компактно (ну и наглядно). Трудоёмкость реализации - может быть... однако Вы, на мой взгляд, справедливо заметили:
Сергей Прохоренко в viewtopic.php?p=57751#p57751 писал(а):
...Реализация соответствующего интерфейса довольно сложна - ведь проблемы графов никуда не деваются, но форма графа здесь очень хороша для восприятия человеком...
Т.е. не забываем, что работаем для потребителя того, что разработает программист (а м.б. и не только - см. первый тип ЖЦ решения в этом сообщении). И надо, чтобы максимально были созданы условия для гарантоспособности решения (включая работу человека/коллектива с искусственной системой-решателем; определение см. на с. 293-296 этой работы). Чтобы не получалось, как в примерах из п. 1.1 этой работы. А это и даёт выбор между текстовым и "графитным" представлениями - и сочинитель, и читатель могут с большими удобствами анализировать и с большей вероятностью обнаруживать и исправлять ошибки разработки...
    Особенно это существенно, если не предполагается формальная верификация - что возможно, если задачу для разработки можно определить как "некризисную" по Г.Р. Громову (см. в этом сообщении).

Как я понимаю, к остальному вышесказанному пока вопросов нет :)

Автор:  Владислав Жаринов [ Понедельник, 17 Январь, 2011 08:05 ]
Заголовок сообщения:  Re: Ещё раз о целях и средствах :)

Сергей Прохоренко писал(а):
Но я всё равно за графику. Только она должна стать менее трудоемкой и не требующей творческих способностей. Для этого ей придется перестать быть двумерной, вытянуться в вертикальном направлении и стать более автоматизированной.
...
Восприятие в любом случае фрагментами - голова ведь не ризиновая. А интеграция этих кусочков в единое целое должна происходит на вкладках "модуль" и "проект". Кстати, там как раз должно использоваться изображение в форме графа.
...
4) Средства автоматического преобразования выделенного кода в инлайновую процедуру, размещаемую на отдельной вкладке.
Драконограф писал(а):
4) Имеется в виду то, что в шампур-методе называется подстановкой (см. определение здесь)?
Да, только автоматически - парой щелчков мышью.
Вот ещё в свете сказанного - имеется в виду как графовое представление маршрутной логики то, что в /Паронджанов, 2001/ называется "алгоритм-концепция" - см. определение здесь при обсуждении степени содержательности визуалов? Пример из книги:
Вложение:
Комментарий к файлу: Визуализация процесса разработки как дракон-модели с концептуализацией входящих визуалов.
Паронджанов-КакУлучшРабУма-извл(Рис105-107).djvu [49.12 КБ]
Скачиваний: 351
Т.е. на высших уровнях иерархии описания логики можно составлять маршруты только из процедур/функций, образующих низший уровень (сборочную базу) модели деятельности (машинной программы, инструкции человеку).
    Кстати, я верно понимаю, что "инлайновая" - это когда тело процедуры/функции можно в текстовой форме записать в одну строку (очевидно, при конкретной стандартной длине строки - определяемой, допустим, типовой шириной области просмотра и размером шрифта)?

Тут надо заметить вот что:
    * Визуал на Рис.107 уже не концепция в чистом виде - т.к. имеются операторы, не являющиеся процедурами (здесь - действия) - т.е. это частично конкретизированный визуал.
    * Замечания в подписях к Рис. 106,107 об их вхождении в визуал на Рис.105 в графит-методе должны заменяться механизмом ссылок по именам из именных полей данного уровня декомпозиции на следующий (и обратно).
    * Синтаксис пометки ВЦ целесообразно видоизменить - см. в этом подпункте Д2М-определения техноязыка.
По первому - Вы предполагаете, что все схемы декомпозиции д.б. чистыми концепциями - т.е. в графовом представлении их вертикали должны содержать только операторы декомпозиции (здесь - вставки)?
По второму - Вы также считаете необходимым организовать связность модели? Или как-то иначе?

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

Автор:  Сергей Прохоренко [ Понедельник, 17 Январь, 2011 14:07 ]
Заголовок сообщения:  Re: Ещё раз о целях и средствах :)

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

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

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


Высокоуровневые представления (проект, подсистема, модуль) должны отображаться двумерными графами, а кроме того, таблицами содержимого. Графы не должны отображать очередность (следование, ветвление, циклы), а только лишь состав элементов и зависимости между ними. Щелкнув по значку элемента или зависимости, можно "провалиться" на уровень ниже (процедура, функция), где увидеть очередность.

Автор:  Владислав Жаринов [ Понедельник, 17 Январь, 2011 19:15 ]
Заголовок сообщения:  Структурные представления

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

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

Автор:  Владислав Жаринов [ Понедельник, 17 Январь, 2011 19:16 ]
Заголовок сообщения:  Re: Параллельное программирование в системе формализации дея

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

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

Автор:  Сергей Прохоренко [ Понедельник, 17 Январь, 2011 23:18 ]
Заголовок сообщения:  Re: Структурные представления

Драконограф писал(а):
А в процедуре/функции очерёдность как предполагается показывать?


Как в обычном программном коде, написанном в парадигме структурного программирования: последовательно сверху вниз, с циклами, с ветвлением с помощью "длинного" IF или CASE/SWITCH.

Автор:  Владислав Жаринов [ Вторник, 18 Январь, 2011 04:18 ]
Заголовок сообщения:  Re: Структурные представления

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

Автор:  Сергей Прохоренко [ Вторник, 18 Январь, 2011 11:49 ]
Заголовок сообщения:  Re: Структурные представления

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


Процедура/функция - это не граф, а вертикальная последовательность блоков, некоторые из которых содержат вложенные блоки, включая многоветочные конструкции:

Modkit

Scratch

Многоветочные конструкции

Автор:  Владислав Жаринов [ Вторник, 18 Январь, 2011 12:05 ]
Заголовок сообщения:  Re: Структурные представления

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

Автор:  Сергей Прохоренко [ Вторник, 18 Январь, 2011 12:08 ]
Заголовок сообщения:  Re: Структурные представления

Драконограф писал(а):
"игривые" :)

В отличие от показанных примеров, блоки в PureBuilder не выделяются цветом и границей "тела" блока, а охватываются слева скобкой со скругленными углами, которая является элементом управления. В программный код также автоматически вставляются и другие элементы управления. "Игривость" отвлекает и утомляет, и поэтому в PureBuilder ее не будет.

Автор:  Владислав Жаринов [ Вторник, 18 Январь, 2011 12:14 ]
Заголовок сообщения:  Re: Структурные представления

Сергей Прохоренко писал(а):
Драконограф писал(а):
"игривые" :)

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

Автор:  Владислав Жаринов [ Вторник, 18 Январь, 2011 12:19 ]
Заголовок сообщения:  Re: Структурные представления

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

Автор:  Владислав Жаринов [ Вторник, 18 Январь, 2011 16:38 ]
Заголовок сообщения:  Re: Параллельное программирование в системе формализации дея

Драконограф в viewtopic.php?p=57934#p57934 писал(а):
...
Как выяснилось из /Поликарпова, Шалыто, 2010, с. 59-60/, автоматное программирование предполагает аналогичный подход к организации взаимодействия.
Можно проиллюстрировать это, составив визуальную импер-информодель по автоматной спецификации. Теперь это сделано в этом примере.
P.S. Добавил визуалы, приведённые к циклу Дейкстры; теперь это можно оформить и в структурном редакторе :)

Автор:  Сергей Прохоренко [ Среда, 19 Январь, 2011 15:20 ]
Заголовок сообщения:  Re: Параллельное программирование в системе формализации дея

Не понял. В PureBuilder реализация препроцессинга не предусмотрена, так как нет текстового исходного кода, и подход "код как данные" не используется.

Автор:  Geniepro [ Среда, 19 Январь, 2011 15:23 ]
Заголовок сообщения:  Re: Параллельное программирование в системе формализации дея

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

Автор:  Владислав Жаринов [ Среда, 19 Январь, 2011 17:56 ]
Заголовок сообщения:  Re: Параллельное программирование в системе формализации дея

Geniepro писал(а):
Сергей Прохоренко писал(а):
... нет текстового исходного кода, и подход "код как данные" не используется.
Почему нет подхода "код как данные"? Если у Вас код будет в виде семантического дерева или в каком-то другом подобном виде, его всё равно можно будет использовать как данные.
Я имел в виду описанное в конце этого поста; наглядно показано в п. Некоторые итоги этого примера (случай "варианты в одно место модели") и в этом примере (случай "варианты в разные места модели"). Обоснование см. здесь в п/п 1.3.2.1 - коротко говоря, так модель (понятно, что необязательно представленная чисто "графитно") учитывает вариантность "предметки".

Автор:  Сергей Прохоренко [ Среда, 19 Январь, 2011 19:01 ]
Заголовок сообщения:  Re: Параллельное программирование в системе формализации дея

Geniepro писал(а):
Сергей Прохоренко писал(а):
... нет текстового исходного кода, и подход "код как данные" не используется.
Почему нет подхода "код как данные"? Если у Вас код будет в виде семантического дерева или в каком-то другом подобном виде, его всё равно можно будет использовать как данные.
Сейчас эта тема весьма модная, так что для Вашего проекта может быть полезным, если такой подход будет реализован. Это будет мощное метапрограммирование, сравнимое с макросами лиспа и немерле.


Я против макросов (кроме случаев, когда они являются по сути частью компилятора, как в Си), перегрузки операторов и подобных им трюков. Код должен исполняться так, как он выглядит при создании, а не так, как он будет выглядеть после обработки. В противном случае программист может легко ошибиться. Да и с точки зрения идеологии PureBuilder - структурный, а не текстовый редактор. В нем зрительный образ, отражающий семантику программы, - самое главное, а внутреннее представление - вещь второстепенная.

Мода приходит и уходит. :wink:

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