DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 22:25

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




Начать новую тему Ответить на тему  [ Сообщений: 380 ]  На страницу Пред.  1 ... 12, 13, 14, 15, 16, 17, 18, 19  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 24 Январь, 2011 17:16 

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

И кстати, как насчет того, чтобы сохранять и накапливать подобные фрагменты для дальнейшего использования в качестве единого элемента?


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Валерий Лаптев писал(а):
И кстати, как насчет того, чтобы сохранять и накапливать подобные фрагменты для дальнейшего использования в качестве единого элемента?
Так это и есть макроблок! ;)


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

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Валерий Лаптев писал(а):
И кстати, как насчет того, чтобы сохранять и накапливать подобные фрагменты для дальнейшего использования в качестве единого элемента?
В ИС Дракон можно открыть несколько листов. На отдельных листах можно разместить фрагменты для дальнейшего использования, в виде схем "Примитив" для шампур-блоков, схем "Силуэт" для веток-блоков. Использование и накопления макроблоков производить путем копирования и вставки через графический буфер. Переключение листов производится достаточно просто.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Январь, 2011 20:22 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Геннадий Тышов писал(а):
В ИС Дракон можно открыть несколько листов... Таким образом, есть все средства для сохранения и накапливания макроблоков. Дорабатывать ИС Дракон в этой части не требуется, необходимо нарабатывать технику его использования.
Держите меня, я сейчас матом ругаться буду.


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

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Alexey_Donskoy писал(а):
Геннадий, чрезвычайно не хватает макроблоков (то есть свёртывания участков схем).
Также (возможно, проще в реализации) - возможности заключать участки схем в рамочки с подписями, например:
Вложение:
q2.PNG

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

Да, это было бы интересное развитие ИС Дракон, как интерактивного документа.
Эти надо заняться, но это будет после обеспечения раскладки схем без пересечений, без ручного устранения пересечений.


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

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Alexey_Donskoy писал(а):
Держите меня, я сейчас ... ругаться буду.
Что не устраивает?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Январь, 2011 20:55 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Геннадий Тышов писал(а):
Что не устраивает?
То, что Вы начинаете предлагать "решения", не понимая основных свойств предмета обсуждения.

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

А макроблок - это класс. И от него создаются экземпляры. Экземпляр макроблока Вы изменять не можете, его внутренняя структура остаётся, как в классе описано.
Если же изменить структуру класса, она обязана измениться и во всех экземплярах.

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

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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Январь, 2011 21:32 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Ответ был на сообщение Лаптева, полагаю вполне адекватный.

Alexey_Donskoy писал(а):
А макроблок - это класс. И от него создаются экземпляры. Экземпляр макроблока Вы изменять не можете, его внутренняя структура остаётся, как в классе описано.
Если же изменить структуру класса, она обязана измениться и во всех экземплярах.
Ну, это сложно не только реализовать, но и представить.

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


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Геннадий Тышов писал(а):
Но, если до настоящего времени мы воспринимаем икону "Вставка" как процедуру или функцию, то давайте воспринимать ее еще как макроблок. Смотрим на икону "Вставка" и воспринимаем ее как макроблок, определенный в соответствующей дракон-схеме, т.е. макроопределении или у вас классе. Икона "Вставка" именно так трактуется у В.Д. Паронджанова.
Да, как частный случай можно и так.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Январь, 2011 22:04 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Alexey_Donskoy писал(а):
Но, помимо всего прочего, макроблок может иметь несколько входов-выходов (например, один выход для нормального маршрута, другой для выхода по ошибке, ну и т.п.).
Множество выходов в макроопределении - это будет вообще абстракция, трудно воспринимаемая в духе Дракона. Потребуется идентификация каждого вывода. В чистом Драконе идентификация не применяется, только содержательные тексты в иконах.

Исходя из принципа автомата Калашникова, т.е. Окаама не следует плодить сущности без крайней необходимости.

Цитата:
Связанная и свертывающаяся область, т.е. рамка. ... Да, это было бы интересное развитие ИС Дракон, как интерактивного документа.
Это более реально и более требуется, после решения первоочередных проблем.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Январь, 2011 22:14 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Валерий Лаптев писал(а):
как насчет того, чтобы сохранять и накапливать..?
Конечно! Например, в БД. И отдавать либо копированием, либо именованной ссылкой. Тогда и вопросы целостности будут автоматически отработаны на уровне БД.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 26 Январь, 2011 16:58 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Драконограф в viewtopic.php?p=58389#p58389 писал(а):
Alexey_Donskoy в viewtopic.php?p=58387#p58387 писал(а):
Драконограф в viewtopic.php?p=58383#p58383 писал(а):
А, ну тогда всё-таки что-то вроде вершины Область. Кстати, она не только для выборочной свёртки - но и для пошаговой детализации
Ну да, и это тоже. Следующий шаг в юзабилити, скажем так.
И тогда наконец-то можно будет юзать только один тип приложений к вершинам - неформальный ("управленческий") - а всё остальное визуализировать с возможной сменой представляемого языка на более формальный :)

Геннадий Тышов в viewtopic.php?p=58442#p58442 писал(а):
Alexey_Donskoy в viewtopic.php?p=58441#p58441 писал(а):
А макроблок - это класс. И от него создаются экземпляры. Экземпляр макроблока Вы изменять не можете, его внутренняя структура остаётся, как в классе описано.
Если же изменить структуру класса, она обязана измениться и во всех экземплярах.
Ну, это сложно не только реализовать, но и представить.
Но, если до настоящего времени мы воспринимаем икону "Вставка" как процедуру или функцию, то давайте воспринимать ее еще как макроблок...
Геннадий Николаевич прав - представить (логически) сложно. Но можно - добавил обсуждение макроблоков (вершин Область) в конце этого примера. Очевидны следующие вещи:
    * Макроблок - это не вставка. Вставки связаны со схемами отношением "вызывающий-вызываемый" (времени выполнения, или "рунтаймовым", если угодно :)). Макроблоки - отношением "включающий-включаемый" (времени сочинения - именно тогда вопрос вхождения должен разрешиться).
    * Макроблок может параметризоваться по вхождениям, если их более одного.
    * Каждому вхождению можно сопоставить более одного макроблока (варианта), из которых один выбирается для включения (как основной) командой сочинителя (безусловно) либо по условию (как при препроцессинге на ТЯП типа Си).
    * Возможно многообразие вхождения макроблоков в схемы, которое надо ограничивать на уровне стандарта, чтобы не усложнять сочинителю.
    * Область д.б. в общем случае со многими входами/выходами, но не все они обязательно связаны - могут существовать несвязные фрагменты.
Общее представление - вынесенная область логически первична (источник содержания для каждой включённой области, с которой наведена связь). Соответственно "экземпляры класса" получаются параметризацией по местам вхождения (или входят "один в один").

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

Рэйлвэй Каген писал(а):
Валерий Лаптев писал(а):
как насчет того, чтобы сохранять и накапливать..?
Конечно! Например, в БД. И отдавать либо копированием, либо именованной ссылкой. Тогда и вопросы целостности будут автоматически отработаны на уровне БД.
Видимо, имеется в виду то что описывалось в конце этого примера (п. Некоторые итоги), в частности, на этом рисунке. Тут как раз подразумевается, что вынесенные области (макроблоки) где-то накапливаются и откуда-то берутся.
По сути, это на ту же тему - только там логика предполагалась попроще, поэтому и синтаксис (индексация, в частности) менее развит.

Вопрос назрел - как и с заменой Ты-ГНОМа в роли языка схематизации документа среды (см. в этом сообщении).


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

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Драконограф писал(а):
Вопрос назрел - как и с заменой Ты-ГНОМа в роли языка схематизации документа среды (см. в этом сообщении).

Если вопрос ко мне, то что необходимо практически сделать?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 26 Январь, 2011 22:42 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Драконограф писал(а):
Видимо, имеется в виду то что описывалось..
Мне трудно судить об эквивалентности подразумеваемого, поскольку для этого требуется детально изучить всю drakonografika.narod.ru, а с этим проблемы - я как-то отмечал, что в материале часто "плавает" терминология. Лично мне проще работать с авторской терминологией из "Как улучшить работу ума".
Что касается конкретного рисунка, то, честно говоря, не вижу необходимости использовать для изображённой конфигурации специальный термин - "макроблок". Ведь там изображён обычный "шампур-блок", который легко сворачивается во "Вставку" (в терминологии Паронджанова). А о возможности использования "Вставки" для реализации макроопределений упоминалось ещё в этой теме.
Что касается областей, то для себя я пришёл к выводу, что наибольший интерес представляет вырожденный случай - когда область топологически эквивалентна "Ветке". В частности, обработка ситуаций и изображение параллельных процессов отчасти основаны на использовании именно таких областей.
Вот и Алексей Донской нарисовал такой вырожденный случай. Уж не знаю, может случайно получилось?

Хранить ли "вставки" и "Ветки" в БД? Для меня ответ всегда был - да.


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Рэйлвэй Каген писал(а):
Вот и Алексей Донской нарисовал такой вырожденный случай. Уж не знаю, может случайно получилось?
Во-первых, случайно ;)
Во-вторых, там не вырожденный случай - там два выхода из области (хотя я точно не помню, что в этой терминологии называется веткой ;) )
В-третьих, вроде бы вход обычно один, а выходов может быть много (ах, нет, внутри может быть какая-нибудь синхронизация параллельных действий, тогда входов тоже много может быть)...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Январь, 2011 09:37 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Alexey_Donskoy писал(а):
..внутри может быть какая-нибудь синхронизация параллельных действий, тогда входов тоже много может быть...
Плюс ещё случай когнитивно-эргономического объединения фрагментов схемы в область. Но что плохого в наличии нескольких входов в область?


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Рэйлвэй Каген писал(а):
Плюс ещё случай когнитивно-эргономического объединения фрагментов схемы в область. Но что плохого в наличии нескольких входов в область?
Да, именно так. Ничего плохого ;)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Январь, 2011 09:23 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Рэйлвэй Каген писал(а):
Драконограф в viewtopic.php?p=58631#p58631 писал(а):
Видимо, имеется в виду то что описывалось..
Мне трудно судить об эквивалентности подразумеваемого, поскольку для этого требуется детально изучить всю drakonografika.narod.ru, а с этим проблемы - я как-то отмечал, что в материале часто "плавает" терминология...
Что где плавает - просьба уточнять "по месту". Будем осмысливать и исправлять :)
Для понимания того, что сказал, в принципе детально изучать весь сайт не нужно - достаточно этих примеров. Как можно заметить, примеры содержат обсуждение общих вопросов, обоснование основных решений. Единственное, что иногда требуется, когда обсуждаются ЯПЗ и их реализация - что-то из языковых предложений... но тут пока и это не нужно - всё по области сосредоточилось в примере.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Январь, 2011 09:38 

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Январь, 2011 10:00 

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

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 380 ]  На страницу Пред.  1 ... 12, 13, 14, 15, 16, 17, 18, 19  След.

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


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

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


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

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