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 писал(а): ... А исходя из естественной во многих случаях многовариантности назначения (условий применения), может понадобиться делать ту или иную схему проекта для одного случая такой, а для другого - в чём-то иной. Вот я и определяю путь, как это представлять наглядно. Конечно, у ведущего форум м.б. своё мнение...Высокоуровневые представления (проект, подсистема, модуль) должны отображаться двумерными графами, а кроме того, таблицами содержимого. Графы не должны отображать очередность (следование, ветвление, циклы), а только лишь состав элементов и зависимости между ними. Щелкнув по значку элемента или зависимости, можно "провалиться" на уровень ниже (процедура, функция), где увидеть очередность. Уточню, что имеется в виду определение графит-вершины Область:
* конкретно-статическое - здесь в п/п 1.3.2.1 и правиле СЕ (п/п 1.3.2.2); * конкретно-динамическое - здесь в правиле ДИ (п/п 1.3.2.3).
* вариация содержания шампура вставки в импер-графит-модели - сопоставление области с фрагментом-выноской; * вариация содержания шампура вставки в импер-графит-модели - см. образы графчасти и текста для просмотра; * вариация содержания шампура вставки в импер-графит-модели - пример показывает сокращение объёма и повышение регулярности модели за счёт рациональной областной декомпозиции; * графит-модель автоматной программы с вариациями содержания шампуров и схем (императивных, декларативных) - пример также содержит пояснения по применению областей; * вариация содержания шампуров автоматного алгоритма - пример также содержит пояснения по сути механизма; * вариация содержания шампуров и схем (императивных, декларативных) в графит-программе; * вариация содержания импер-схем в графит-программе. Теперь о голосовании. Как можно понять из формулировок вопросов, за ними стоит некий регламент, в принципе независимый от темы опроса (как, собственно, и состав вопросов). Предлагается (обязывать было бы невежливо с моей стороны, но разумно придерживаться - и в то же время, конечно, высказать замечания и предложения в соответствии с п.2 ) такой порядок : 1. Формулировки вопросов взаимоисключающие, поэтому выбирается один вариант ответа. Участнику предложена возможность отвечать с дополнительными пояснениями (предполагаемый характер которых включён в формулировку вопроса) или без пояснений. 2. Пояснения даются в сообщениях участников. Предполагается, что каждому голосу, требующему пояснений, соответствует одно первоначальное сообщение с пояснениями от подавшего участника
В качестве примера следования порядку подаю голос (конечно же, не ради примера , а выражая собственное мнение) и аргументирую его в следующем сообщении. |
Автор: | Владислав Жаринов [ Воскресенье, 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: Почему голосую "Да, но с доработками"? |
Сергей Прохоренко писал(а): Драконограф писал(а): ...А области - это для времени сочинения... и условия, управляющие ими, тоже... в готовом к исполнению коде (тексте) их уже и не должно быть - только результаты их применения. Я против препроцессоров.Самое главное - что ситуация, когда надо выбрать из многих вариантов формализации некоего фрагмента профессионального знания один, жизненная. У Вас есть предложения, как это можно сделать понятно для "предметника"? |
Автор: | Сергей Прохоренко [ Среда, 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/ |