DRAKON.SU

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

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




Начать новую тему Ответить на тему  [ Сообщений: 132 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7
Автор Сообщение
СообщениеДобавлено: Понедельник, 03 Сентябрь, 2012 07:38 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Ильченко Эдуард писал(а):
Понятно какие функции (процессы) самих ИСПОЛНИТЕЛЕЙ принимают участие в данном процессе.
С точки зрения когнитивной эргономики один плюс - всё сосредоточено на одной схеме. Жа и тот плюс не очевиден.
То есть я хочу сказать, что:
- использование переключателя для такой цели (фактически - декларация методов объекта) не считаю удачнымю Потому что перепутываются конструкции алгоритмические со структурно-декларативными;
- сам элемент "Переключатель" имеет неэргономичную форму (много лишних РАЗРОЗНЕННЫХ деталей).

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

Цитата:
Уже сейчас можно пользоваться такими схемами, например, используя ИС Дракон.
Лучше сделать более адекватный способ визуального представления.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 03 Сентябрь, 2012 11:15 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Alexey_Donskoy писал(а):
Лучше сделать более адекватный способ визуального представления.

Не могли бы Вы поподробнее объяснить про "более адекватный способ визуального представления"?


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Ильченко Эдуард писал(а):
Alexey_Donskoy писал(а):
Лучше сделать более адекватный способ визуального представления.

Не могли бы Вы поподробнее объяснить про "более адекватный способ визуального представления"?
Не могли бы. Если бы мог себе позволить отвлекаться на исследования, давно бы предложил что-нибудь работающее..

Но просто достаточно очевидно, что один имеющийся Дракон пихать во сферы только потому, что он есть - неверный подход.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 03 Сентябрь, 2012 14:23 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Alexey_Donskoy писал(а):
... давно бы предложил что-нибудь работающее..

Давно работающее уже есть. UML, BPWin, IDEFы, куча всякоразных под задачи «только для себя» и т. д. и т.п.

Alexey_Donskoy писал(а):
Но просто достаточно очевидно, что один имеющийся Дракон пихать во сферы только потому, что он есть - неверный подход.

Конечно, Вы правы.
Но, например, я пытаюсь применить его там, где, по-моему мнению он сможет работать не хуже, а может и лучше других. Тем самым можно определить сферу применения ДРАКОНа.

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

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

Alexey_Donskoy писал(а):
Узкие места всех предлагаемых вариантов вроде обозначил в комментариях (от смешивания имеративных конструкций с декларативными до никуда не годной эргономики имеющихся визуальных представлений).

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

Ильченко Эдуард писал(а):
Не могли бы Вы поподробнее объяснить про "более адекватный способ визуального представления"?

Alexey_Donskoy писал(а):
Не могли бы.


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

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

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

Цитата:
Жаль, что «годную эргономику» (похоже Вы знаете, что это такое) от Вас я не увижу.
Если б знал, писал бы книги, как Паронджанов, и соответствующий продукт разрабатывал :)

Но ряд предложений в смежных темах и здесь озвучил ведь:
- плавные линии, закруглённые контуры (вместо острых прямоугольников и изломов);
- масштабирование (тут где-то упомянули термин drill down/up), где при наведении мыши, клике и т.п. разворачивается/сворачивается детализация внутри элементов;
- обозначение масштабирования, где фокус внимания изображён чётко, а контекст (например, структура) размыто и сильно приглушённым контрастом (вместо одинаковых чёрных линий, от которых чертёж хочется повесить на стену... обратной стороной...); сюда же предложение на некоторых масштабах вообще отказаться от контуров элементов, оставив равномерно закрашенные фигуры;
- чётко (в том числе визуально) разделить маршрутные линии от потоков данных (да, потоки данных ещё и ввести надо ;) );
- оптимизировать базовые алгоритмические элементы (особенно развилку и переключатель - который вообще состоит из раздельных, визуально слабо связанных элементов);
- чётко отделять структурную метаинформацию (в т.ч. декларативную) от алгоритмической (так, идея методов объектов на ветках "силуэта" вроде хороша, но сам силуэт никуда не годится. Алгоритмический "силуэт" - можно оставить как есть, а декларативный (с методами, например) изобразить вообще не линиями, а, скажем, вертикальными градиентными полосами);
- да, и вообще запретить "силуэт", как создающий ненужные и вредные разрывы :lol:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 03 Сентябрь, 2012 18:58 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
В целом согласен с Алексеем.
Некоторые мысли:

1) Линии на твёрдых копиях м.б. неодинаковыми так, как и положено в ЕСКД - блоки основной толщины, связи - тонкие. Также играем цветом - но, как я думаю, прежде всего не графики, а содержания.
На видеограммах, безусловно, можно больше разнообразить форматирование...

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

3) Что делать с силуэтом - наверное, лучше Александр Сергеевич знает... вот только спрашивать его надо не здесь... и не так, как иногда делается... в стиле кавалера "Большого креста германского орла" (типа: "Вы же согласны, что тачка м.б. любого цвета при условии, что этот цвет - чёрный?")... :wink: :|


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 03 Сентябрь, 2012 19:29 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Ну, теперь к конкретике.
Ильченко Эдуард писал(а):
Владислав Жаринов писал(а):
Логика схемы, кстати, довольно понятна... и соответствует логике выбора операций в головном визуале для этой задачи ...

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

1) Данное расширение языка имеет ту же область оптимальной применимости, что и исходный технооязык - представление импер-составляющей для случая с единственной РТ. Именно потому изначальное приложение к "Задаче на перспективу" и вышло таким - для многих РТ оптимально не получается. Причины лучше изложил Алексей в той же теме.

2) В расширении Вы фактически подошли к дейкстралу со стороны "автоматчиков" (и Info21) - через эмуляцию вложением LOOP(CASE) - подобно ЦС у Дмитрия_ВБ. Луп у Вас - это "пустой" цикл ДЛЯ, кейс - вложенный силуэт специального вида. О том, что ЦД не есть лучшее средство для представления логики программы как системы, говорил Усов здесь... И это в любом случае представление для единственной РТ...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 08 Сентябрь, 2012 20:21 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Alexey_Donskoy писал(а):
..вообще запретить "силуэт", как создающий ненужные и вредные разрывы :lol:
смотрите на него, как на развёртку вырожденного тора. И ненавистные разрывы исчезнут! :lol:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 08 Сентябрь, 2012 20:34 
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Сентябрь, 2012 20:48 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Схема-пример (отсюда)
Вложение:
b3.png
b3.png [ 70.31 КБ | Просмотров: 12357 ]

alignat писал(а):
А как быть, если явно требуется указать генерируемый документ?

та же схема в другой нотации

Вложение:
rpud1.png
rpud1.png [ 13.56 КБ | Просмотров: 12357 ]

Вложение:
rpud2.png
rpud2.png [ 66.86 КБ | Просмотров: 12357 ]

Вложение:
rpud3.png
rpud3.png [ 62.71 КБ | Просмотров: 12357 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Сентябрь, 2012 16:49 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Alexey_Donskoy в viewtopic.php?p=74302#p74302 писал(а):
...
- чётко (в том числе визуально) разделить маршрутные линии от потоков данных (да, потоки данных ещё и ввести надо ;) );
...
Ага, только это будет уже не ДРАКОН... а комплексная нотация... :)

Чтобы комплексность не была "с-ложной" - можно было бы ограничиться принципом операторных схем - только с вариантами, как сказано здесь (в п. 1): viewtopic.php?p=75098#p75098. В предположении, задаваемом подходом Усова, что переход между действиями определяется получением нужного результата труда - вьюшка будет вполне подходящей, думаю... в конкретных случаях...


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

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Вот такая схема (описание здесь)
Вложение:
b1.png
b1.png [ 71.17 КБ | Просмотров: 12083 ]

с учётом замечания
Владимир Паронджанов писал(а):
Мне нравится (хотя и не полностью) дракон-схема Эдуарда Ильченко в пункте 8 сообщения http://forum.oberoncore.ru/viewtopic.php?p=75290#p75290

вот в таком исполнении:
Вложение:
apng01.png
apng01.png [ 69.71 КБ | Просмотров: 12083 ]


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

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


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

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


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

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