OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 17 Ноябрь, 2019 12:28

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




Начать новую тему Ответить на тему  [ Сообщений: 33 ]  На страницу 1, 2  След.

Нужен ли данный механизм (в графит-определении) в граф-языках сред, подобных PureBuilder?
Да, и точка (и объяснять не буду, почему :)) 33%  33%  [ 1 ]
Да, потому что (аргументация в посте) 0%  0%  [ 0 ]
Да, но с доработками (изложение в посте) 33%  33%  [ 1 ]
Нет, потому что (аргументация в посте) 33%  33%  [ 1 ]
Нужен, но принципиально другой (определение в посте) 0%  0%  [ 0 ]
Всего голосов : 3
Автор Сообщение
СообщениеДобавлено: Воскресенье, 06 Февраль, 2011 08:28 

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

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

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


Последний раз редактировалось Владислав Жаринов Суббота, 24 Декабрь, 2011 13:41, всего редактировалось 9 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Февраль, 2011 08:29 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Февраль, 2011 19:09 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Мне не удалось понять, о чем идет речь, поэтому пока не голосую. Если имеется в виду область для рисования графов, отображающих взаимозависимости модулей и их объединение в подсистемы, то такая область в PureBuilder уже предусмотрена. Это - так называемая "панель структуры" на рисунке.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Февраль, 2011 19:34 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3109
Откуда: Астрахань
Слово "зависимость" -очень "скользкое". Почему бы под зависимостью не понимать как раз линейную последовательность исполнения "сверху-вниз". И вторая зависимость - вложенность, где опять - сверху-вниз. То есть модель - это дерево со связями последователь и вложенность.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Февраль, 2011 20:28 

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


Последний раз редактировалось Владислав Жаринов Среда, 09 Февраль, 2011 13:55, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Февраль, 2011 20:33 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Февраль, 2011 23:37 
Аватара пользователя

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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Февраль, 2011 23:48 
Аватара пользователя

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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 07 Февраль, 2011 09:45 
Модератор
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 09 Февраль, 2011 13:48 

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


Последний раз редактировалось Владислав Жаринов Среда, 09 Февраль, 2011 14:00, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 09 Февраль, 2011 13:56 

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


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 09 Февраль, 2011 15:25 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Драконограф писал(а):
...А области - это для времени сочинения... и условия, управляющие ими, тоже... в готовом к исполнению коде (тексте) их уже и не должно быть - только результаты их применения.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 09 Февраль, 2011 20:00 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 09 Февраль, 2011 21:17 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Драконограф писал(а):
Самое главное - что ситуация, когда надо выбрать из многих вариантов формализации некоего фрагмента профессионального знания один, жизненная. У Вас есть предложения, как это можно сделать понятно для "предметника"?


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 10 Февраль, 2011 07:45 

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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 10 Февраль, 2011 15:00 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Выбирается только вариант. Каждый "подвариант" является вариантом. По каждому варианту можно посмотреть справку.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 11 Февраль, 2011 08:13 

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


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 11 Февраль, 2011 10:21 
Аватара пользователя

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


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

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


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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 11 Февраль, 2011 11:47 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9155
Откуда: Россия, Орёл
Имеется ввиду требование отсутствия циклов в графе использования модулями определений из друг друга.

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

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


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

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


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

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


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

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