DRAKON.SU

Текущее время: Четверг, 26 Ноябрь, 2020 20:58

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




Начать новую тему Ответить на тему  [ Сообщений: 74 ]  На страницу Пред.  1, 2, 3, 4
Автор Сообщение
СообщениеДобавлено: Воскресенье, 05 Июль, 2009 21:59 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
dvuugl писал(а):
нужна и композиция..
"развилка-вставка" - это не композиция. Это инцест(мягко говоря).

КОМПОЗИЦИЯ
1. вложенные процедуры - по контексту
2. исключения, прерывания - по поведению
3. параллельный процесс - по времени (есть в Драконе)
4. переключатель - по значениям поля данных (есть в Драконе)
5. силуэт - по построению (есть в Драконе)
..
Мэй би как-то продолжить надо. Да и Дракону полезно будет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 05 Июль, 2009 22:31 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Ещё немного о композиции:

Основные виды отношений между программными объектами
"Отличие парадигм программирования заключается в реализациях моделей состояния и поведения, а также отношений между этими понятиями, осуществляемых через такие элементарные программные объекты как данные и операции. Абстрагирование от конкретных экземпляров достигается за счет введения понятий "абстрактный тип данных" и "процедура" (понятие "функция" используется как синоним процедуры). Элементарные понятия используются для построения составных программных объектов путем объединения в агрегаты и разделения по категориям. Категорию Г. Буч [Буч98] называет иерархией типа "is-a". Она также трактуется как обобщение программных объектов [Цикритзис]. Агрегаты и обобщения используются при конструировании композиций данных и процедур. В каждой из существующих парадигм программирования вопросы такого конструирования композиций решаются по-своему, что и вносит определенные отличительные черты." (Легалов А.И.)

Думается, что такая абстракция может быть более результативна, чем линейная комбинация существующих в Драконе изобразительных средств.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 05 Июль, 2009 22:57 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1082
Откуда: Россия, Чебоксары
Однако, dvuugl прав. Неудобно вызывать функцию, затем проверять её результат. Загромождается схема.

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

В этом смысле рулит фортовский принцип - всё, что написано, может быть вызовом процедуры.

1. Это удобно.
2. Это соответствует процессу разработки сверху вниз.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 06 Июль, 2009 07:11 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Нет, dvuugl неправ. Докажу "от противного".

Предположим, что dvuugl прав.
dvuugl писал(а):
Два раза отвечаем на один и тот же вопрос. Сначала на него отвечает вставка-функция. Потом на него же отвечает вопрос к этой вставке-функции.
Тогда имеется возможность изобразить функцию, обозначенную вставкой, примитивом или силуэтом с двумя и более выходами. Но по правилам Дракона, выход("Конец") может быть только один. Получили противоречие. Следовательно, исходное предположение неверно. чтд.
Alexey_Donskoy писал(а):
Развилка трактуется как вставка - всегда.
С какого перепугу? Или я что-то пропустил? Ветвление по локальным/глобальным данным будет действием, определённым в другом месте? Эдак мы тут окончательно народ запутаем :roll:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 06 Июль, 2009 07:31 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1082
Откуда: Россия, Чебоксары
А с какого перепугу рассматривать только ветвление по данным?

В ветвлении (как и в операторе if) имеет место логическое выражение (условие).
В логическом выражении допустимо использование функций.
Сложное условие может быть целесообразно вынести в отдельную процедуру (или свернуть).
Никакой нет путаницы, а есть эргономичная организация структуры кода.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 06 Июль, 2009 07:56 

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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 06 Июль, 2009 09:58 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1082
Откуда: Россия, Чебоксары
То есть ссылка, то нету. Лишние сущности плодятся. Нехорошо это.

Ещё раз повторяю, что в системах с большим потенциалом (само)развития - всё есть ссылка.

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 06 Июль, 2009 11:14 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Ссылки - это, конечно, интересно. На неё можно посмотреть и так, и эдак. Но это хорошо только с высоты определённого опыта и понимания, что делать это можно тоже "по слоям". Что, кстати, может накладывать и порядок представлений.

Вот и в упомянутой работе Легалова можно усмотреть некую аналогию: рассмотрены две парадигмы - процедурная и ООП(слои), определённые абстракции - агрегат и обобщение, а на стр13. объяснена возможность смотреть на обобщение, как на агрегат. Поскольку агрегат и обобщение - проекции одной абстракции(композиции).
Цитата:
"от языков, отображающих одни и те же понятия разными способами, надо переходить к инструментам, позволяющим отображать множественные отношения и ассоциации между базовыми понятиями. Захотели, посмотрели на программные объекты как на процедуры и данные, захотели - посмотрели как на классы.(Легалов А.И. Разнорукое программирование.2001г.)"


Только вот просто ввести такую мощную абстракцию в инструмент - что гранату обезьяне подарить. Своя проекция - в свой слой, наверное будет вернее. У ссылки ведь тоже могут быть проекции?

Проекции и слои могут быть парадигмозависимыми. Получится "Проект "Логика"


p.s.: заодно уж и саму брошюру прилепил:
Вложение:


Последний раз редактировалось Рэйлвэй Каген Понедельник, 06 Июль, 2009 17:27, всего редактировалось 4 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 06 Июль, 2009 12:37 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 112
Откуда: Беларусь, Минск
Рэйлвэй Каген писал(а):
Получили противоречие.
Получили техническое противоречие : )...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 13 Ноябрь, 2009 05:54 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Уважаемые участники!
Как я понимаю, икону Вставка можно привлечь также для визуализации прерываний т.е. вызова другого визуала (обработчика) не тогда, когда это задано маршрутом сочиняемого визуала (назовём его целевым), а тогда, когда происходит обрабатываемое событие. В программировании я понимаю мало, но имхо, для решения этой задачи нужно привлечь какое-то представление об исполнителе алгоритма. Вот как можно, мне кажется, рассудить. Формальный исполнитель (машина) работает по командному циклу, который также есть алгоритм, только "зашитый" в логику процессора (схемы устройства управления, т.е. обычно - вентили комбинационной части + кодировка взаимосвязанной памяти микропрограмм). Типичный алгоритм командного цикла изображался как блок-схема, например, в учебнике: Каган Б.М. ЭВМ и системы. - М.:Энергоатомиздат, 1991 (см. вложение). Если выделить то, что нам нужно, то получим тело командного цикла как блок, где целевому оператору (в данном случае - микрооперациям, реализующим назначение машинной команды) предшествует ветвление по вопросу "есть ли (необработанные) сигналы прерываний ?". На вопрос отвечает система прерываний исполнителя (проверяя, есть ли несброшенные/незамаскированные сигналы о событиях). Если нет, то выходим на ненагруженную вертикаль; если да - в другой вертикали вызываем алгоритм-обработчик (головной) как вставку. При его визуализации для исполнителя-машины нужно учесть все особенности её системы прерываний: как обрабатываются вложенные прерывания, как кодируются и хранятся сигналы прерываний и т.п. Конечный итог - вызов алгоритма реакции на конкретное прерывание, т.е. множественное ветвление по коду прерывания, где нагрузка каждой ветви - икона Вставка с именем алгоритма реакции (его машинный эквивалент - подпрограмма обработки прерывания). Полученная схема обработчика будет доступна из каждого целевого алгоритма, сочиняемого для данного исполнителя; при этом некоторые реакции сочинитель может визуализировать заново (для подмены стандартных на время выполнения целевого алгоритма). Временной аспект обработки также зависит от архитектуры машины: есть техническая возможность запустить обработчик отдельно - показываем его как процесс, параллельный исполнению целевого алгоритма; можно запустить отдельно только некоторые реакции (скажем, как программы каналов) - показываем только их как параллельные; и т.д. (хотя здесь детали я, возможно, трактую приблизительно). Затем выполняем оператор, предписанный целевой дракон-схемой.
Для немашинного исполнителя (обычно человека) прерывание также возможно; тогда "систему прерываний" описываем неформально. Получается просто, что на каждом операторе возможен контроль наступления внешних событий: разбили один оператор на несколько - стало столько же контрольных точек; в пределе какие-то части этого алгоритма поручаются машине, детализируются до уровня "одна икона - одна машинная команда" и приходим к тому, с чего начали эти рассуждения - реакции на прерывания в каждом командном цикле процессора (разумеется, если он имеет систему прерываний).

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

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


Вложения:
Kagan - EVM - ComCycle.png
Kagan - EVM - ComCycle.png [ 41.93 КБ | Просмотров: 8474 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 13 Ноябрь, 2009 10:07 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Сейчас вдумываться в Ваш текст некогда, но любые взаимодействия (события принимаемые и инициируемые) я лично изображаю с помощью знаков ввода-вывода.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 13 Ноябрь, 2009 23:16 

Зарегистрирован: Суббота, 16 Февраль, 2008 07:58
Сообщения: 236
Откуда: Россия, Стерлитамак
Я тоже за то, что Развилка должна либо без дополнительных обозначений подразумевать Вставку, либо иметь для этого какие-либо графические отличия.
Обоснование: вычисление логической функции перед Развилкой может быть затратно по времени, а для быстрой схемы вычислений логических условий, эта функция может и не вызываться, либо вообще второе и далее условия могут не иметь смысла (ну это конечно исправимо, но не всегда удобно).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 14 Ноябрь, 2009 09:51 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
При желании, обосновать можно всё, что угодно. Например, если условие в развилке простое и незатратно по времени, то Развилка должна подразумевать Действие. Мне кажется, что такое направление низводит логику Дракона до маразма. Весьма важно расставить приоритеты:
что получаем и куда идём с этим после развилки
или
как вычисляем куда идти дальше.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 14 Ноябрь, 2009 10:29 

Зарегистрирован: Суббота, 16 Февраль, 2008 07:58
Сообщения: 236
Откуда: Россия, Стерлитамак
Хотя подумал, и понял, что вы правы, действительно правильнее разграничить, действие и условие, т.к. дракон по определению, это маршрутная часть алгоритма


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

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


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

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


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

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