DRAKON.SU

Текущее время: Пятница, 05 Март, 2021 12:51

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




Начать новую тему Ответить на тему  [ Сообщений: 376 ]  На страницу Пред.  1 ... 9, 10, 11, 12, 13, 14, 15 ... 19  След.
Автор Сообщение
СообщениеДобавлено: Среда, 16 Апрель, 2008 11:21 

Зарегистрирован: Понедельник, 14 Апрель, 2008 16:14
Сообщения: 5
Здравствуйте

Уважаемый Владимир Данилович, большое спасибо, за высказанные замечания.
Владимир Паронджанов писал(а):
Ваш «алгоритм» описывает не то, что асанщик ДЕЛАЕТ, а то, что с ним (асанщиком) ПРОИСХОДИТ.
В таком случае Вы используете Дракон за рамками его полномочий.

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

Владимир Данилович, Вы даже не представляете как близко Вы "попали в яблочко"! Если Вы, человек, судя по всему, далекий от йоги смогли сделать правильные выводы, значит схема дает хоть какое-то правильное представление.
Т.е. создаются условия, и далее все происходит само собой, без моего участия. Именно поэтому схема содержит столько комментариев, это просто фиксация происходящего. Вообще йога это на 99% эмпирика по принципу черного ящика. Это работает, а почему это работает можно сказать весьма и весьма приблизительно.
Замечания 1-3 приняты и осознанны, спасибо. :)
Владимир Паронджанов писал(а):
Замечание 4. Имеет место «неразбериха» между иконой «действие» и иконой «комментарий».

Нет, Владимир Данилович, я понимаю разницу. Почему пришлось нарисовать именно так, я постарался объяснить в первом обзаце. По замечанию 5 я также вынужден адресовать к первому абзацу. :oops:

Замечание 6. Действительно, йог именно ждет сигналов выхода из асаны.
Заменание 7 почти принято (т.к. в исходном тексте это называлось именно так - "базовый алгоритм") и осознанно. :)
Владимир Паронджанов писал(а):
У меня есть и другие замечания. Но на первый раз хватит. Если хотите усовершенствовать свой алгоритм, я готов Вам помочь. Предлагаю делать это методом последовательных приближений. Вы подправляете (если захотите). А я буду высказывать очередную порцию замечаний.

Владимир Данилович, было бы здорово. Давайте я перерисую алгоритм в дракон редакторе и посмотрим, что получится. :)
Еще раз спасибо!

Alexey_Donskoy писал(а):
КИЕ писал(а):
- зона ответственности подразделений;

вот тут... как Вы это делаете в Драконовских алгоритмах? Просто, выделяя и группируя действия?


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

Так это да, воз и ныне там.
Alexey_Donskoy писал(а):
инструмент должен поддерживать весь проект в актуальном состоянии, чтобы быстро и точно отражать вплоть до кода быстро меняющиеся требования внешней среды...
Насколько точно Вам удаётся поддерживать актуальность разработанных схем?

Алексей, боюсь я создал у Вас неправильное представление, извините. В нашей организации нет альбома технологических карт по всем бизнес процессам. Увы это так. Описанное мной достигло стадии промышленной реализации в трех продуктах разработанных практически с нуля. Естественно, поддерживать актуальность по трем продуктам получается довольно просто. Что касается инструмента, я видел, пару лет назад, одну АБС, в которой было реализованно нечто похожее, где простым изменением схемы менялся весь ворк флоу :) Но дальше презентации там, похоже дело не пошло. Алексей, удачи!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Апрель, 2008 11:27 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Alexey_Donskoy писал(а):
Вниманию Владимира Паронджанова!

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

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


Разрыв должен заканчиваться гиперссылкой на продолжение.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Апрель, 2008 12:27 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1096
Откуда: Россия, Чебоксары
Сергей Прохоренко писал(а):
Разрыв должен заканчиваться гиперссылкой на продолжение.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Апрель, 2008 12:34 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Alexey_Donskoy писал(а):
Давайте попробуем найти принципиально новое решение!

Разрыв должен заканчиваться гиперссылкой на продолжение.

Сергей, без обид только...
Ну неужели "принципиально новое решение" - это уровень гиперссылок и т.п.? Это представление (отображение, из MVC), там можно ввести многое, без особого труда... Но какая модель будет внутри заложена - так всё и поплывёт :-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Апрель, 2008 12:40 

Зарегистрирован: Среда, 09 Апрель, 2008 17:42
Сообщения: 21
Некоторые неудобства нотации ДРАКОН:
1. представление таймеров:
ДРАКОН - отличный инструмент для представления конечных автоматов. Конечных автоматов может быть несколько параллельно действующих. При этом таймер представляет собой простую задержку (типа: ЖДАТЬ 5 МИН.).
Во-первых, не предусмотрено досрочного выхода из ожидания.
Во-вторых, как должны работать параллельные автоматы в этом случае? Даже при использовании многозадачной ОС возникает вопрос: как их сихнхронизовать?
Вывод: мы в своих реальных проектах не используем таймеры в первоначальном виде.

2. поддерживаю предыдущее сообщение:
Бывают проблемы с пересечением состояний.
Пример:
Код:
switch (state_value)
{
  case FIRST:
   return NEW_STATE;
  case SECOND:
...
}

Внутри ветки ПЕРЕКЛЮЧАТЕЛЬ может быть адресная метка (выход из состояния).
Что делать?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Апрель, 2008 12:40 

Зарегистрирован: Среда, 09 Апрель, 2008 17:42
Сообщения: 21
Возражение А. Донскому:
Цитата:
Цитата:
Владимир Паронджанов писал(а):
Чтобы устранить отмеченные погрешности, надо:
• Три иконы ВЫХОД ИЗ АСАНЫ превратить в три иконы «Адрес» и прицепить их к нижней горизонтальной линии.
• Добавить справа еще одну ветку. В иконе «Имя ветки» написать ВЫХОД ИЗ АСАНЫ.
• Ниже поместить икону «Действие». И написать в ней «Выйти из асаны». Еще ниже поместить икону «Конец» и написать в ней слово Конец.

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

Целостность восприятия не нарушается:
1. Надпись остается прежней.
2. Схема становится единообразнее - меньше разнотипных значков внизу.
3. Выход из асаны может содержать какие-то действия.

4. (самое главное) пониманию алгоритма способствует его разбиение на логические блоки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Апрель, 2008 13:50 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Илья Ермаков писал(а):
Сергей Прохоренко писал(а):
Alexey_Donskoy писал(а):
Давайте попробуем найти принципиально новое решение!

Разрыв должен заканчиваться гиперссылкой на продолжение.

Сергей, без обид только...
Ну неужели "принципиально новое решение" - это уровень гиперссылок и т.п.? Это представление (отображение, из MVC), там можно ввести многое, без особого труда... Но какая модель будет внутри заложена - так всё и поплывёт :-)


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


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1096
Откуда: Россия, Чебоксары
TMX писал(а):
Целостность восприятия не нарушается:
1. Надпись остается прежней.
2. Схема становится единообразнее - меньше разнотипных значков внизу.
3. Выход из асаны может содержать какие-то действия.
4. (самое главное) пониманию алгоритма способствует его разбиение на логические блоки.

Начать с того, что, разумеется, "конец" должен быть в схеме один, исходная картинка с тремя выходами даже не рассматривается.
п.3 поддерживается полностью, п.4 - частично. На мой взгляд, не всегда декомпозиция оправдана. Спорный вопрос.
В любом случае, мне кажется, предпочтительнее будет декомпозиция не по плоскости, а по масштабу, иерархии (см. также у Раскина о масштабируемости интерфейса).
Иначе любые преобразования плоской проекции (читай - попытка показать объёмный граф на плоскости) приведут к пересечениям... или того хуже... Вот, кстати, к вопросу о пересечении vs. шина - какое представление удобнее и понятнее:
Вложение:
bus.PNG
bus.PNG [ 2.98 КБ | Просмотров: 11563 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Апрель, 2008 14:15 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Мне кажется (в двух словах):
а) для представления структурированного(!) алгоритма двух измерений без пересечений необходимо и достаточно (вертикаль - последовательность действий, горизонталь - ветвление по принятию решений).
б) для представления логики действий в наиболее общем виде (но наименее структурированном) - автоматном - используются Драконовские ветки. Если логика не сложна, то этого достаточно. А если уже возникают "проблемы разрывности", то просто нужно дополнять дракон-схему графом автомата. Т.е. дракон-редактор должен показывать такую "подсказку".

в) поддерживаю идею таблиц решений. Они нужны, даже, мне кажется, как отдельный оператор в Драконе. Типа переключателя, но с табличкой "да-нетных вопросов" сверху.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Апрель, 2008 15:46 

Зарегистрирован: Среда, 09 Апрель, 2008 17:42
Сообщения: 21
Цитата:
Иначе любые преобразования плоской проекции (читай - попытка показать объёмный граф на плоскости) приведут к пересечениям... или того хуже... Вот, кстати, к вопросу о пересечении vs. шина - какое представление удобнее и понятнее:

1. Шина на ДРАКОН-схемах уже есть: она соединяет адресные метки.
2. В шине должен присутствовать идентификатор цепи - фактически, мы возвращаемся от графического представления к текстовому.

На мой взгляд, ДРАКОН тем и хорош, что заставляет приводить графы алгоритмов к плоскому представлению.


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

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

в) поддерживаю идею таблиц решений. Они нужны, даже, мне кажется, как отдельный оператор в Драконе. Типа переключателя, но с табличкой "да-нетных вопросов" сверху.


Таблицы решений безусловно нужны, но только их недостаточно:

1. Вместо больших разреженных таблиц решений удобнее база данных/ массив строк (первое состояние, второе состояние, условие перехода от первого состояния ко второму, другие поля)
2. Для моделей, соответствующих дереву, а не произвольному графу, удобнее древовидные списки состояний

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Апрель, 2008 16:36 

Зарегистрирован: Среда, 09 Апрель, 2008 17:42
Сообщения: 21
Цитата:
В любом случае, мне кажется, предпочтительнее будет декомпозиция не по плоскости, а по масштабу, иерархии (см. также у Раскина о масштабируемости интерфейса).

Такой подход реализован в иерархических машинах состояний (Miro Samek).
Вложение:
calc.JPG
calc.JPG [ 68.57 КБ | Просмотров: 11509 ]


и главное: все наглядно и понятно :D

Кстати, предлагаю открытый конкурс:
сделать схему на ДРАКОН с той же функциональностью


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

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
TMX писал(а):
Цитата:
В любом случае, мне кажется, предпочтительнее будет декомпозиция не по плоскости, а по масштабу, иерархии (см. также у Раскина о масштабируемости интерфейса).

Такой подход реализован в иерархических машинах состояний (Miro Samek).

и главное: все наглядно и понятно :D

Кстати, предлагаю открытый конкурс:
сделать схему на ДРАКОН с той же функциональностью


Ненаглядно и непонятно. Уверен, что на Дракое будет так же. Блок-схемы плохи тем, что однотипные смысловые переходы могут располагаться в совершенно непредсказуемых местах и иметь непредсказуемое направление. Да и блоки располагаются где угодно, лишь бы уместиться. Нет жесткого единого направления движения, а есть только благие пожелания иметь такие направления с туманными принципами упорядочивания действий. Как только на блок-схему накладываются жесткие требования по направлениям движения, сразу же начинаются проблемы: разреженность, разрывы, чрезмерная вытянутость в одном каком-то измерении, увеличение уровней иерархии и количества страниц и т.п.

Для декомпозиции по иерархии нужна не блок-схема, а иерархический список!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Апрель, 2008 18:40 

Зарегистрирован: Среда, 09 Апрель, 2008 17:42
Сообщения: 21
Цитата:
Ненаглядно и непонятно.

да ну? :)

Цитата:
Уверен, что на Дракое будет так же. Блок-схемы плохи тем, что однотипные смысловые переходы могут располагаться в совершенно непредсказуемых местах и иметь непредсказуемое направление. Да и блоки располагаются где угодно, лишь бы уместиться. Нет жесткого единого направления движения, а есть только благие пожелания иметь такие направления с туманными принципами упорядочивания действий. Как только на блок-схему накладываются жесткие требования по направлениям движения, сразу же начинаются проблемы: разреженность, разрывы, чрезмерная вытянутость в одном каком-то измерении, увеличение уровней иерархии и количества страниц и т.п.


1. ДРАКОН - не блок-схемы, а сочетание диаграммы состояний с диаграммой деятельности, что очень удобно. Поэтому я не уверен и предложил попробовать.
2. Я беру лист побольше - и все умещается.
3. Да, заполнение листа неравномерное - обычно внизу чаще, вверху реже.
во-первых, ну и что?
во-вторых, это место можно использовать для комментариев, пояснений и т.п.

Цитата:
Для декомпозиции по иерархии нужна не блок-схема, а иерархический список!

Проблема иерархии - достаточно частая при рисовании на ДРАКОНе.
Пример из жизни: разрабатывали противоугонную систему. Интерфейс пользователя - кнопка, тумблер и ключ зажигания. Интерфейс реализуется на нескольких автоматах с 20-50 состояниями каждый. При рассмотрении схемы сразу и не понять сколько раз куда жать. В итоге одновременно сделали диаграмму макросостояний с переходами по сложным действиям, типа: "нажать кнопку три раза и повернуть ключ в течение 10 сек."
Проблема в том, что если мы имеем один автомат, то можно сгруппировать состояния (кстати, в нотации это не предусмотрено). Мы использовали иерархию в названии меток. Это можно изобразить, свернув состояния в одно макросостояние - в общем нормально и можно сделать формально.
Однако, если совокупность состояний нескольких автоматов определяет общее состояние системы, непонятно, что делать. Можно ли здесь использовать иерархический список, и если да, то как?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Апрель, 2008 22:46 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Это пример Дракон-схемы сформированной в Дракон-редакторе:
Изображение

Получите:
1. Архивированный каталог с выходным файлом Дракон-редактора и скрытыми файлами
промежуточных состояний формирования Дракон-схемы -
http://forum.oberoncore.ru/download/file.php?mode=view&id=109
Разархивируйте.
2. Графический файл Дракон-схемы -
http://forum.oberoncore.ru/download/file.php?mode=view&id=110
Поместите в каталог.
3. Архивированный исполнительный файл Дракон-редактора
http://forum.oberoncore.ru/download/file.php?mode=view&id=108
Разархивируйте в каталог.

В Дракон-редакторе последовательность формирования можно просмотреть в меню кнопками "<", ">".

Это пример алгоритма из жизни. Т.е. для тех, кому есть что сказать и кто хочет быть понятым.
Книга называется:
Паронджанов В.Д. Как улучшить работу ума. Алгоритмы без программистов — это очень
просто!(Новые средства для образного представления знаний, развития интелекта и
взаимопонимания). М.: Дело, 2001. — 360 с. — Илл.: 154.

Относитель программирования на языке ДРАКОН В.Паронджанов сказал на форуме:
24 февраля 2008 - Так что язык программирования Дракон существует не "в принципе",
а НА ДЕЛЕ, но только в ракетном огороде.
13 марта 2008 - Да, действительно, в моей книге есть примеры программ на гибридных
языках Дракон-Си, Дракон-Модула, Дракон-Паскаль. Но эти системы (нами) не были
реализованы, они не существуют в природе.
4 апреля 2008 - ФИЛОСОФИЯ ЯЗЫКА ДРАКОН
-Любой императивный язык (СИ, ПАСКАЛЬ, АДА, МОДУЛА, БЕЙСИК и т. д.) можно разбить
на три части, три относительно самостоятельных языка: маршрутный, командный и
декларативный.
-Маршрутный язык — совокупность управляющих операторов.
-Командный язык содержит все неуправляющие операторы, например оператор
присваивания, правила записи арифметических и логических выражений,
идентификаторов, ключевые слова и т. д.
-Декларативный язык служит для описания данных, классов и др.
-13 марта 2008 - Не ждать у моря погоды, а стать хозяином положения. То есть сделать
редактор самому. Или в составе команды — вместе с друзьями и единомышленниками.

Геннадий Тышов 6 апреля 2008 писал(а):
Сообщаю ссылку реального Дракон-Редактора:
http://narod.ru/disk/55428000/DRT.rar
Все (почти) по книге В.Д. Паронджанова "Как улучшить работу ума".
Имеется ряд дополнений для полноты функционирования.

Геннадий Тышов 9 апреля 2008 писал(а):
3. Если область деятельности виртуально
переносится в компьютер, то приступать к программированию компьютера следует
после завершения написания алгоритма в виде Дракон-схемы. Программировать
следует в среде программирования.
4. Данная версия Дракон-редактора имеет дополнение в виде примечаний к элементам
и уэлам. Программисту можно рекомендовать в примечаниях писать фрагменты
декларативных и командных частей программного кода. Маршрутную часть кода писать
не следует, т.к. она наглядно отображена Дракон-схемой.

Геннадий Тышов 9 апреля 2008 писал(а):
Илья Ермаков писал(а):
Да, но кто мешает делать "знания" непосредственно исполняемыми? Никто. Имеет смысл
рассматривать это как цель.

Это проблема, не для Дракон-редактора, а для интегрирования производственного
процесса. Элементами интеграции являются: заказчик, разработчики, документация,
программисты, средства программирования, исполняющий компьютер, система отладки
программ и управляемого оборудования. Примером является система "Графит-флокс",
о чем нам рассказал В. Паронджанов.

Вспомните о детях, которые учились и учиться по книге В. Пароджанова "Занимательная
информатика". Книга с 1998 года выдержала 3 издания. Дети ждут Дракон-Редактор.
Чтобы язык ДРАКОН и Дракон-редактор пришли в школу и высшую школу вместе с
языком Компонентный Паскаль, надо рассказать о них на сайте "Информатика-21"
http://www.inr.ac.ru/~info21/.

Программисты тоже не забыта, я писал выше. Можно создать программу, которая
обработает выходной файл Дракон-редактора -.drt и сформирует текст программного
кода.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 17 Апрель, 2008 09:24 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1096
Откуда: Россия, Чебоксары
TMX писал(а):
Такой подход реализован в иерархических машинах состояний (Miro Samek)

В данном случае вынужден согласиться с Сергеем Прохоренко - ненаглядно и непонятно. По очень простой причине - слишком много объектов на рисунке. Никак не 7 чанков, а все 700 ;) Кстати, если раскрасить блоки, то наглядность вырастет на порядок (!), в то время как в исходном изображении слишком много линий, и приходится прикладывать усилия, чтобы выделить (и потом находить снова) отдельные блоки. Естественно, что на восприятие взаимосвязи блоков сил уже не остаётся :(

Да, такая полная схема удобна для ручной отладки (пройти по всем линиям).
Нет, такая схема не годится для понимания задачи и пути её решения.

Парадокс в том, что для понимания сути задачи строго формальное описание ПЛОХО, поскольку добавляет сложности и затрудняет понимание. Неформальное описание значительно лучше. А строго формальное описание нужно только на этапе конкретной реализации. То есть иерархия и инкапсуляция нужны не только в группировке на плоскости, но и по оси времени (если угодно, причинности) - по этапам пути решения задачи.

Илья Ермаков писал(а):
для представления структурированного(!) алгоритма двух измерений без пересечений необходимо и достаточно (вертикаль - последовательность действий, горизонталь - ветвление по принятию решений).

Разительно напоминает войну, объявленную goto... Избавиться от пересечений - не должно быть самоцелью и даже обязательным условием.

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

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

TMX писал(а):
Интерфейс реализуется на нескольких автоматах с 20-50 состояниями каждый. При рассмотрении схемы сразу и не понять сколько раз куда жать. В итоге одновременно сделали диаграмму макросостояний с переходами по сложным действиям, типа: "нажать кнопку три раза и повернуть ключ в течение 10 сек."

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 17 Апрель, 2008 09:57 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
TMX писал(а):
1. ДРАКОН - не блок-схемы, а сочетание диаграммы состояний с диаграммой деятельности, что очень удобно. Поэтому я не уверен и предложил попробовать.
2. Я беру лист побольше - и все умещается.
3. Да, заполнение листа неравномерное - обычно внизу чаще, вверху реже.
во-первых, ну и что?
во-вторых, это место можно использовать для комментариев, пояснений и т.п.


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

Цитата:
Цитата:
Для декомпозиции по иерархии нужна не блок-схема, а иерархический список!

Однако, если совокупность состояний нескольких автоматов определяет общее состояние системы, непонятно, что делать. Можно ли здесь использовать иерархический список, и если да, то как?


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


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

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

Это правильная идея! Потому что размерность должна быть адекватна.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 17 Апрель, 2008 11:32 

Зарегистрирован: Среда, 09 Апрель, 2008 17:42
Сообщения: 21
Цитата:
В данном случае вынужден согласиться с Сергеем Прохоренко - ненаглядно и непонятно.

От сердца отлегло. Значит, не зря мы отказались от такого представления в пользу ДРАКОНа.

Цитата:
Цитата:
TMX писал(а):
Интерфейс реализуется на нескольких автоматах с 20-50 состояниями каждый. При рассмотрении схемы сразу и не понять сколько раз куда жать. В итоге одновременно сделали диаграмму макросостояний с переходами по сложным действиям, типа: "нажать кнопку три раза и повернуть ключ в течение 10 сек."

Вот ещё один пример, до чего может довести бессистемная борьба со сложностью... Называется, хотели как лучше :wink:

Результат нас устраивает.
Как происходит работа над встроенной системой:
сначала определяется общая архитектура, программные интерфейсы, требования к РВ.
Один человек рисует алгоритмы.
В это время другой человек реализует драйверы на мк.
Одновременно еще один реализует драйверы на ПК.
Электронщик паяет.
Еще несколько человек реализуют приложения РВ на мк автономно (документация на ДРАКОНе).

Рисовальщик отдает алгоритмы программисту ПК - он их реализует на С один в один и отлаживает (на один алгоритм уходит один день). Тестирует. Алгоритмист согласовывает результат с заказчиком (обычно уходит не один день :) )

Одновременно тестируются приложения РВ на целевой платформе.
Затем происходит сборка - перенос на целевую платформу с ПК (один день).
И сдача.

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

Да, идея реализуема. Ну и что?
Для тестирования в РВ полезно знать о конкретной реализации. И ДРАКОН для этого - самая подходящая вещь.

Цитата:
Почему бы не сделать условие перехода "пароль верен", и раскрыть его реализацию подробно на отдельной диаграмме?

Что-то подобное и сделано.
Представьте, что пароль проверяется не мгновенно. За это время могут произойти события в других автоматах: автозапуск двигателя, например. Или этот пароль набирает злоумышленник, а владелец пытается издалека брелоком ему воспрепятствовать.
Опять же, с точки зрения пользователя, система должна выглядеть как один автомат, иначе он запутается в ее поведении. А с точки зрения программиста может быть удобнее рассматривать ее как набор. Например, специальный автомат следит за набором пароля. Проще реализация - проще наладка. Но есть проблемы.

Я довольно много времени посвятил изучению реализации и изображению конечных автоматов - в чисто практических целях.
И выбрал ДРАКОН.
Да, у него есть недостатки, о которых я упоминал. И я бы хотел найти пути их решения для дальнейшей работы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 17 Апрель, 2008 13:09 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1096
Откуда: Россия, Чебоксары
TMX писал(а):
Представьте, что пароль проверяется не мгновенно. За это время могут произойти события в других автоматах: автозапуск двигателя, например. Или этот пароль набирает злоумышленник, а владелец пытается издалека брелоком ему воспрепятствовать.
Опять же, с точки зрения пользователя, система должна выглядеть как один автомат, иначе он запутается в ее поведении. А с точки зрения программиста может быть удобнее рассматривать ее как набор. Например, специальный автомат следит за набором пароля. Проще реализация - проще наладка. Но есть проблемы.

Другими словами, Вы про механизм сессий? Это правильно. А в чём тут проблемы?


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

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


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

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


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

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