OberonCore
https://forum.oberoncore.ru/

Механизм Область для визуально-структурного редактирования
https://forum.oberoncore.ru/viewtopic.php?f=93&t=3242
Страница 1 из 2

Автор:  Владислав Жаринов [ Воскресенье, 06 Февраль, 2011 08:28 ]
Заголовок сообщения:  Механизм Область для визуально-структурного редактирования

Сначала - почему здесь тема. Исходя, в частности, из этого:
Сергей Прохоренко в viewtopic.php?p=57913#p57913 писал(а):
...
Высокоуровневые представления (проект, подсистема, модуль) должны отображаться двумерными графами, а кроме того, таблицами содержимого. Графы не должны отображать очередность (следование, ветвление, циклы), а только лишь состав элементов и зависимости между ними. Щелкнув по значку элемента или зависимости, можно "провалиться" на уровень ниже (процедура, функция), где увидеть очередность.
А исходя из естественной во многих случаях многовариантности назначения (условий применения), может понадобиться делать ту или иную схему проекта для одного случая такой, а для другого - в чём-то иной. Вот я и определяю путь, как это представлять наглядно. Конечно, у ведущего форум м.б. своё мнение...

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

В качестве примера следования порядку подаю голос (конечно же, не ради примера :), а выражая собственное мнение) и аргументирую его в следующем сообщении.

Автор:  Владислав Жаринов [ Воскресенье, 06 Февраль, 2011 08:29 ]
Заголовок сообщения:  Почему голосую "Да, но с доработками"?

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

Автор:  Сергей Прохоренко [ Воскресенье, 06 Февраль, 2011 19:09 ]
Заголовок сообщения:  Re: Почему голосую "Да, но с доработками"?

Мне не удалось понять, о чем идет речь, поэтому пока не голосую. Если имеется в виду область для рисования графов, отображающих взаимозависимости модулей и их объединение в подсистемы, то такая область в PureBuilder уже предусмотрена. Это - так называемая "панель структуры" на рисунке.

Автор:  Валерий Лаптев [ Воскресенье, 06 Февраль, 2011 19:34 ]
Заголовок сообщения:  Re: Механизм Область для визуально-структурного редактирован

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

Автор:  Владислав Жаринов [ Воскресенье, 06 Февраль, 2011 20:28 ]
Заголовок сообщения:  Re: Почему голосую "Да, но с доработками"?

Сергей Прохоренко в viewtopic.php?p=59673#p59673 писал(а):
... Если имеется в виду область для рисования графов, отображающих взаимозависимости модулей и их объединение в подсистемы, то такая область в PureBuilder уже предусмотрена. Это - так называемая "панель структуры" на рисунке.
Имелось в виду другое - что любую структуру (в частности и предназначенную для представления на данной панели) реальная жизнь нет-нет да и требует определять вариативно в зависимости от некоторых факторов. И сочинителю даём возможность отразить зависимость графовой модели от этих факторов (в областях представленных условиями вхождения) наглядно.

Автор:  Владислав Жаринов [ Воскресенье, 06 Февраль, 2011 20:33 ]
Заголовок сообщения:  Re: Механизм Область для визуально-структурного редактирован

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

Автор:  Сергей Прохоренко [ Воскресенье, 06 Февраль, 2011 23:37 ]
Заголовок сообщения:  Re: Почему голосую "Да, но с доработками"?

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


Нет, всяческие условия должны остаться на более низком уровне - в процедурах и функциях.

Автор:  Сергей Прохоренко [ Воскресенье, 06 Февраль, 2011 23:48 ]
Заголовок сообщения:  Re: Механизм Область для визуально-структурного редактирован

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


Речь идет о модулях, для которых не существует понятий "раньше-позже", "вышестоящий-нижестоящий" и "вложенный-объемлющий". Эти понятия нужно оставить на более низком уровне: в процедурах и функциях. Модули служат лишь для удобной группировки функций и процедур, а также для их одновременной загрузки/выгрузки из памяти во время исполнения программы. Зависимость между модулями - это использование переменных, функций и других объектов одного модуля другим.

Автор:  Евгений Темиргалеев [ Понедельник, 07 Февраль, 2011 09:45 ]
Заголовок сообщения:  Re: Почему голосую "Да, но с доработками"?

Сергей Прохоренко писал(а):
Мне не удалось понять, о чем идет речь, поэтому пока не голосую.
Возможно, тов. Драконографу, стоит более пристальное внимание уделить пункту 4.4 правил?
Цитата:
... Старайтесь использовать общепринятые термины.

Автор:  Владислав Жаринов [ Среда, 09 Февраль, 2011 13:48 ]
Заголовок сообщения:  Re: Почему голосую "Да, но с доработками"?

Евгений Темиргалеев писал(а):
Возможно, тов. Драконографу, стоит более пристальное внимание уделить пункту 4.4 правил?
Цитата:
... Старайтесь использовать общепринятые термины.
Спасибо за совет :) Вообще-то правильно, но... Прежде всего - кто ощущает, что главным препятствием к пониманию стала слишком высокая доля неизвестных для него терминов и/или определений - тот так конкретно и укажет (в рамках конструктивной критики). Далее, если во что-то вкладываю смысл, вполне соответствующий какому-то общепринятому определению - ясное дело, стремлюсь использовать и общепринятый в пару к нему термин (или один из таковых - и такое бывает - хотя чаще для одного термина существуют разные определения :) ). Но не всегда вижу таковой в тех вещах, которые формулирую. Кто-то может знать больше меня - буду рад конкретным замечаниям и предложениям.

Автор:  Владислав Жаринов [ Среда, 09 Февраль, 2011 13:56 ]
Заголовок сообщения:  Re: Почему голосую "Да, но с доработками"?

Сергей Прохоренко писал(а):
Драконограф в viewtopic.php?p=59682#p59682 писал(а):
Сергей Прохоренко писал(а):
...
Имелось в виду другое - что любую структуру (в частности и предназначенную для представления на данной панели) реальная жизнь нет-нет да и требует определять вариативно в зависимости от некоторых факторов. И сочинителю даём возможность отразить зависимость графовой модели от этих факторов (в областях, представленных условиями вхождения) наглядно.
Нет, всяческие условия должны остаться на более низком уровне - в процедурах и функциях.
Условия времени исполнения - да, тут и вопросов нет :) А области - это для времени сочинения... и условия, управляющие ими, тоже... в готовом к исполнению коде (тексте) их уже и не должно быть - только результаты их применения.

Автор:  Владислав Жаринов [ Среда, 09 Февраль, 2011 14:11 ]
Заголовок сообщения:  Области и процедуры

Драконограф в viewtopic.php?p=59660#p59660 писал(а):
...
На сегодня употребление областей проиллюстрировано прежде всего этими примерами:
...
В цитированное сообщение добавлен ещё один пример - первым в список - снова на автоматное графит-моделирование. Точнее, т.к. пример большой, помещена выдержка, иллюстрирующая применение областей и различие между ними и процедурами.
Имеется в виду следующее. Процедуру можно определить как механизм повторного использования кода во время выполнения.
Процесс в примере визуализирован для языка без процедур. При этом мы можем повторно использовать код только во время сочинения ("распасовывая" с конкретизацией по месту отдельных фрагментов текста). Что и сделано посредством областей.

Автор:  Сергей Прохоренко [ Среда, 09 Февраль, 2011 15:25 ]
Заголовок сообщения:  Re: Почему голосую "Да, но с доработками"?

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


Я против препроцессоров.

Автор:  Владислав Жаринов [ Среда, 09 Февраль, 2011 20:00 ]
Заголовок сообщения:  Re: Почему голосую "Да, но с доработками"?

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

Автор:  Сергей Прохоренко [ Среда, 09 Февраль, 2011 21:17 ]
Заголовок сообщения:  Re: Почему голосую "Да, но с доработками"?

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


Как в PureBuilder - выбираем нужный вариант в палитре, щелкаем мышкой - и готово.

Автор:  Владислав Жаринов [ Четверг, 10 Февраль, 2011 07:45 ]
Заголовок сообщения:  Re: Почему голосую "Да, но с доработками"?

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


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

Автор:  Сергей Прохоренко [ Четверг, 10 Февраль, 2011 15:00 ]
Заголовок сообщения:  Re: Почему голосую "Да, но с доработками"?

Выбирается только вариант. Каждый "подвариант" является вариантом. По каждому варианту можно посмотреть справку.

Автор:  Валерий Лаптев [ Пятница, 11 Февраль, 2011 08:13 ]
Заголовок сообщения:  Re: Механизм Область для визуально-структурного редактирован

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


Речь идет о модулях, для которых не существует понятий "раньше-позже", "вышестоящий-нижестоящий" и "вложенный-объемлющий". Эти понятия нужно оставить на более низком уровне: в процедурах и функциях. Модули служат лишь для удобной группировки функций и процедур, а также для их одновременной загрузки/выгрузки из памяти во время исполнения программы. Зависимость между модулями - это использование переменных, функций и других объектов одного модуля другим.

Для модулей - тоже существует. Например, прописанное выше или ниже. Это вполне определяется принципом: сначала объяви, потом используй.

Автор:  Сергей Прохоренко [ Пятница, 11 Февраль, 2011 10:21 ]
Заголовок сообщения:  Re: Механизм Область для визуально-структурного редактирован

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


Речь идет о модулях, для которых не существует понятий "раньше-позже", "вышестоящий-нижестоящий" и "вложенный-объемлющий". Эти понятия нужно оставить на более низком уровне: в процедурах и функциях. Модули служат лишь для удобной группировки функций и процедур, а также для их одновременной загрузки/выгрузки из памяти во время исполнения программы. Зависимость между модулями - это использование переменных, функций и других объектов одного модуля другим.

Для модулей - тоже существует. Например, прописанное выше или ниже. Это вполне определяется принципом: сначала объяви, потом используй.


А можно поподробнее: что Вы имеете в виду?

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

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

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

Автор:  Илья Ермаков [ Пятница, 11 Февраль, 2011 11:47 ]
Заголовок сообщения:  Re: Механизм Область для визуально-структурного редактирован

Имеется ввиду требование отсутствия циклов в графе использования модулями определений из друг друга.

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

Это касается графа использования понятий, так сказать. А граф использования функциональности может быть и цикличным (за счёт динамических связей).

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