DRAKON.SU
https://forum.drakon.su/

Преобразование графов
https://forum.drakon.su/viewtopic.php?f=148&t=3184
Страница 4 из 5

Автор:  igor [ Вторник, 22 Март, 2011 18:27 ]
Заголовок сообщения:  Re: Преобразование графов

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

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

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

Автор:  Илья Ермаков [ Вторник, 22 Март, 2011 18:57 ]
Заголовок сообщения:  Re: Преобразование графов

Alexey_Donskoy писал(а):
Вот, к примеру, ветка А изображает самый частый путь (9 из 10 прерываний, например), а ветка Б - основную работу, которая, однако, выполняется 1 из 10 раз. Ну и как расставлять приоритеты? ;)


Авторское право. Я всегда рассматриваю программу как передачу информации от автора к читателю:) Выбранный способ представления должен как можно ярче выражать, доносить идею. Разумеется. идея всегда в чём-то субъективна. Расставляйте приоритеты именно как ВЫ видите важным :)

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

Просто пример на "выражение идеи":
я всегда пишу INC(count); m[count-1] := newElem. С чьей-то чисто-программёрской точки зрения можно даже назвать это безграмотным. Но я хочу явно выражать то, что у нас стало на один элемент больше, и что мы кладём его на последнюю позиции массива (а последняя всегда с -1 пишется).

Автор:  Alexey_Donskoy [ Вторник, 22 Март, 2011 19:16 ]
Заголовок сообщения:  Re: Преобразование графов

Илья Ермаков писал(а):
я всегда пишу INC(count); m[count-1] := newElem. С чьей-то чисто-программёрской точки зрения можно даже назвать это безграмотным. Но я хочу явно выражать то, что у нас стало на один элемент больше, и что мы кладём его на последнюю позиции массива (а последняя всегда с -1 пишется).
Платформная зависимость. Это плохо.

Да, оно само собой в большинстве случаев так выходит (List.Add; with List[List.Count-1] do ...). Но плохо.
Равно как ничем не лучше было бы m[count]:=newElem; inc(count);
К тому же, кое-где массивы организованы по-другому. Особенно строки в Дельфи - там с 1 нумерация ;)

Что-то вроде with List.Add do ... было бы прозрачнее. Без явного юзания count.

Но всё это существенно выходит за рамки темы...

А к теме ближе вот что.
Какой бы авторской ни была программа, вся эта информация а) дополнительная; б) не очевидной полезности.

Алгоритм - квинтэссенция. Его топология неизменна. И может быть автоматически оптимизирована.

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

Автор:  Илья Ермаков [ Вторник, 22 Март, 2011 19:31 ]
Заголовок сообщения:  Re: Преобразование графов

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

Автор:  Владислав Жаринов [ Среда, 23 Март, 2011 07:07 ]
Заголовок сообщения:  Re: Преобразование графов

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

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

Возможно, разрешить знак "переход на адрес" в середине схемы, чтобы не тянуть линию вниз, с пересечениями?
Вы имеете в виду подобное тому, что описано здесь как "БП-соеднинители"?

Автор:  Владислав Жаринов [ Среда, 23 Март, 2011 07:21 ]
Заголовок сообщения:  Re: Преобразование графов

Alexey_Donskoy писал(а):
...
Алгоритм - квинтэссенция. Его топология неизменна. И может быть автоматически оптимизирована.

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

Автор:  Владислав Жаринов [ Среда, 23 Март, 2011 07:29 ]
Заголовок сообщения:  Re: Преобразование графов

Alexey_Donskoy писал(а):
Ну-с, продолжим ;)
Показан кусочек алгоритма обработки некоего прерывания.

Вложение:
q3m.PNG


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

Все вопросы успешно решаются, если отменить ограничение на пересечения.
Если же не отменять, то уж я не знаю, что делать...
Тут два вопроса по поводу "как делать":
1. А не рассматривать ли алгоритм целиком, а не по кусочкам?
2. А не привлечь ли при преобразованиях структуры маршрутов текст вершин, - т.е., перейти от "слепыш-метода" к "графит-методу"? и поискать при этом укладку на плоскости, не пытающуюся упорядочить то, для чего не находится критерия упорядочения :wink: - а просто укладывающую граф маршрутов? :)

Автор:  Alexey_Donskoy [ Среда, 23 Март, 2011 08:45 ]
Заголовок сообщения:  Re: Преобразование графов

Драконограф писал(а):
Вы хотели сказать, что есть смысл чего-то (в данном случае - алгоритмической части знания о деятельности), формируемый мысленно сочинителем ("квинтэссенция", исходящая из понимания, для чего эта деятельность, и неизменно выражающая одну и ту же структуру маршрутов - пока это самое понимание не изменится) - и есть (по крайней мере, д.б. :wink:) разные возможности сочинителю выразить этот смысл вовне (записав на разных визуальных/текстовых языках)?
Так.
И ещё несколько замечаний.
1) К сожалению, пока рассматриваемые визуальные технологии (включая Дракон) никак не помогают решать главную задачу - проектирование программной системы. К тем вопросам, которые А.Седов ставил в Фидо ещё 15 лет назад, и близко не подошли.
2) Дракон помогает уменьшить издержки в ряде частных случаев. Но также и вводит дополнительные издержки в других местах. Средняя температура по больнице не изменяется.
3) Элементарная (в смысле лоической целостности) алгоритмическая задача с точки зрения оптимизации может иметь один или несколько экстремумов (наиболее оптимальных алгоритмических решений). Топология этих алгоритмов не зависит ни от представления, ни от "мысленных построений сочинителя".
4) Ориентированный граф наиболее математически точно описывает топологию алгоритма.
5) Для удобства человека этот граф можно представлять в разных проекциях (на разных языках), в том числе визуально изобразить на плоскости.

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

Задача-максимум: исходя из соображений когнитивной эргономики, построить эффективную методику проектирования программных систем.

Автор:  Владислав Жаринов [ Среда, 23 Март, 2011 08:49 ]
Заголовок сообщения:  Re: Преобразование графов

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

Автор:  Alexey_Donskoy [ Среда, 23 Март, 2011 09:16 ]
Заголовок сообщения:  Re: Преобразование графов

Драконограф писал(а):
А от чего зависит? От заданных свойств предполагаемого исполнителя решения? ещё от чего-то?
От задачи :)
Вернее, от модели, используемой для её решения...

Автор:  Владислав Жаринов [ Среда, 23 Март, 2011 10:28 ]
Заголовок сообщения:  Re: Преобразование графов

Alexey_Donskoy писал(а):
...
1) К сожалению, пока рассматриваемые визуальные технологии (включая Дракон) никак не помогают решать главную задачу - проектирование программной системы. К тем вопросам, которые А.Седов ставил в Фидо ещё 15 лет назад, и близко не подошли.
...

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

Автор:  alexus [ Среда, 23 Март, 2011 10:43 ]
Заголовок сообщения:  Re: Преобразование графов

Alexey_Donskoy писал(а):
1) К сожалению, пока рассматриваемые визуальные технологии (включая Дракон) никак не помогают решать главную задачу - проектирование программной системы. К тем вопросам, которые А.Седов ставил в Фидо ещё 15 лет назад, и близко не подошли.
Дракон позволяет описывать алгоритмы, но не системы. Вы напрасно ставите знак равенства между этими понятиями. Алгоритм - это представление действия, но действие - это не система.
Alexey_Donskoy писал(а):
2) Дракон помогает уменьшить издержки в ряде частных случаев. Но также и вводит дополнительные издержки в других местах. Средняя температура по больнице не изменяется.
Издержки... разные бывают... большие и маленькие, например. :) Если применять Дракон именно для записи алгоритмов, то издержки невелики. А если пытаться на нем формализовать поиск решения... то...
Alexey_Donskoy писал(а):
3) Элементарная (в смысле лоической целостности) алгоритмическая задача с точки зрения оптимизации может иметь один или несколько экстремумов (наиболее оптимальных алгоритмических решений). Топология этих алгоритмов не зависит ни от представления, ни от "мысленных построений сочинителя".
Может, но это ничего не меняет в самом языке. Запись алгоритма помимо самого языка, включает в себя следование определенным правила, традициям и т.п. Вот о правилах, как я понял, здесь и была полемика.
Alexey_Donskoy писал(а):
4) Ориентированный граф наиболее математически точно описывает топологию алгоритма.
Для большинства задач - это так, но есть и меньшинство... Например, результатов действия алгоритма может быть много. Можно вырезать из исходного листа материала, например, столешницу... а можно (на обрабатывающем центре) вырезать сразу несколько деталей. Ни одна из полученных, в результате раскроя листа, деталей не может быть "главной". Мы идем в магазин за покупками, но всегда ли есть главная покупка в списке? Аналогично в алгоритме могут достигаться несколько равноценных результатов. Как построим орграф?
Если вернуться к системам, то там есть элементы и связи. Связи (каналы, например) часто могут быть двунаправленными. И здесь могут возникнуть проблемы с построением орграфа. Но и это еще не все... Часто правила выбора дальнейшего пути решается не с помощью жестко заданного алгоритма, а с помощью набора правил, которые интерпретируются во время исполнения. Орграф? И т.д.
Alexey_Donskoy писал(а):
5) Для удобства человека этот граф можно представлять в разных проекциях (на разных языках), в том числе визуально изобразить на плоскости.
А почему именно на плоскости? А что будет если, например, обработку исключений вынести на другую плоскость? Получим пространственную модель. Может она будет проще восприниматься...
Alexey_Donskoy писал(а):
Задача-минимум: исходя из соображений когнитивной эргономики, найти оптимальное для большинства практических случаев представление топологии алгоритма. Обсуждаемый кандидат - Дракон - имеет один плюс: это первая попытка решить задачу-минимум в такой формулировке. Минусов тоже имеет много, о чём и говорю в данной теме.
Обозначенные минусы относятся не к языку, а к правилам оформления схем... (или я что-то пропустил?)
Alexey_Donskoy писал(а):
Задача-максимум: исходя из соображений когнитивной эргономики, построить эффективную методику проектирования программных систем.
Пытался это предложение понять... не получилось.

Автор:  Info21 [ Среда, 23 Март, 2011 10:45 ]
Заголовок сообщения:  Re: Преобразование графов

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

"исходя ..." -- это доп. ограничение на решение. Причем сильное. Что затрудняет решение.

Любопытно было бы посмотреть на решения этой задачи БЕЗ таких ограничений.

Рассуждение сугубо формальное, конечно, но....

Автор:  Владислав Жаринов [ Среда, 23 Март, 2011 10:57 ]
Заголовок сообщения:  Re: Преобразование графов

Info21 писал(а):
Alexey_Donskoy писал(а):
Задача-максимум: исходя из соображений когнитивной эргономики, построить эффективную методику проектирования программных систем.
Интересно.

"исходя ..." -- это доп. ограничение на решение. Причем сильное. Что затрудняет решение.

Любопытно было бы посмотреть на решения этой задачи БЕЗ таких ограничений.

Рассуждение сугубо формальное, конечно, но....
Вот кстати первое дело - как понимать методику. Если как алгоритмически строгий процесс для машинного исполнителя - то не задача ли "построить алгоритм построения любого мыслимого алгоритма" получится? :)

Автор:  Владислав Жаринов [ Среда, 23 Март, 2011 11:19 ]
Заголовок сообщения:  Re: Преобразование графов

alexus писал(а):
... Дракон позволяет описывать алгоритмы, но не системы. Вы напрасно ставите знак равенства между этими понятиями. Алгоритм - это представление действия, но действие - это не система.
Да... вот даже если включить в модель взаимодействие человека с [программируемой] машиной... то из этого примера хотя бы видно, что не так просто представить систему... деятельность человека так легко не информатизуешь :)
alexus писал(а):
Издержки... разные бывают... большие и маленькие, например. :) Если применять Дракон именно для записи алгоритмов, то издержки невелики. А если пытаться на нем формализовать поиск решения... то...
... получится попытка "алгоритмизации изобретения"? :)
alexus писал(а):
Может, но это ничего не меняет в самом языке. Запись алгоритма помимо самого языка, включает в себя следование определенным правила, традициям и т.п. Вот о правилах, как я понял, здесь и была полемика.
Ну да... кроме языка, есть ещё технология его применения... можно "гнездить" циклы, а можно вывести эквивалентный ЦД; можно разрывать цикл ДЛЯ между ветками, а можно не разрывать (хотя здесь уже сомнительно, что и то, и другое допустимо шампур-методом :wink:); можно делать подстановку "по логике", а можно "по физике"; и т.д.
alexus писал(а):
Для большинства задач - это так, но есть и меньшинство... Например, результатов действия алгоритма может быть много. Можно вырезать из исходного листа материала, например, столешницу... а можно (на обрабатывающем центре) вырезать сразу несколько деталей. Ни одна из полученных, в результате раскроя листа, деталей не может быть "главной". Мы идем в магазин за покупками, но всегда ли есть главная покупка в списке? Аналогично в алгоритме могут достигаться несколько равноценных результатов. Как построим орграф?
Ну, тут как раз сказывается, что алгоритм - это ещё не вся деятельность. Сразу несколько деталей образуют структуру объектов (данных), описываемую отдельно. Если достигаются не сразу несколько результатов, а поодиночке - то при отсутствии очевидного критерия предоставляем выбор человеку или вводим искусственное правило.
alexus писал(а):
Если вернуться к системам, то там есть элементы и связи. Связи (каналы, например) часто могут быть двунаправленными. И здесь могут возникнуть проблемы с построением орграфа. Но и это еще не все... Часто правила выбора дальнейшего пути решается не с помощью жестко заданного алгоритма, а с помощью набора правил, которые интерпретируются во время исполнения. Орграф? И т.д.
Ну, каналы взаимодействия алгопроцессов вроде реализуемы... и визуализируемы (именно в виде системы графов процессов-элементов деятельности - и графов процессов связи, т.е. обслуживания каналов)... или что-то другое имелось в виду?
А набор правил - он откуда берётся?
alexus писал(а):
Alexey_Donskoy писал(а):
5) Для удобства человека этот граф можно представлять в разных проекциях (на разных языках), в том числе визуально изобразить на плоскости.
А почему именно на плоскости? А что будет если, например, обработку исключений вынести на другую плоскость? Получим пространственную модель. Может она будет проще восприниматься...
Ну да... как и подстановки... и взаимодействия... и наконец, системы схем по ЕСКД.

Автор:  Alexey_Donskoy [ Среда, 23 Март, 2011 13:58 ]
Заголовок сообщения:  Re: Преобразование графов

alexus писал(а):
Дракон позволяет описывать алгоритмы, но не системы. Вы напрасно ставите знак равенства между этими понятиями. Алгоритм - это представление действия, но действие - это не система.
Естественно. Я как раз не ставлю знак равенства, а обращаю внимание на задачу-максимум.

Цитата:
"Задача-максимум: исходя из соображений когнитивной эргономики, построить эффективную методику проектирования программных систем."
Пытался это предложение понять... не получилось.
Ну дык, наивно хочется механизировать искусство! ;)

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

info21 писал(а):
"исходя ..." -- это доп. ограничение на решение. Причем сильное. Что затрудняет решение.
Любопытно было бы посмотреть на решения этой задачи БЕЗ таких ограничений.
Мне тоже было бы любопытно посмотреть на "серебряную пулю"! ;)
Но, если строительство такого... гм... здания... вообще возможно, то лучше бы его направлять сразу.
А иначе "получится, как всегда" - задача вроде бы решена, но пользоваться решением до того муторно, что прощё выкинуть! ;)

И потом - почему именно пугает ограничение? Ограничения в любом случае есть (критерии решения задачи).

Цитата:
Если применять Дракон именно для записи алгоритмов, то издержки невелики. А если пытаться на нем формализовать поиск решения... то...
Так в этой теме вылезает, что даже для записи алгоритмов издержки неприемлемые ;)
Кроме того, полезность чисто алгоритмической проекции программной системы как-то... сомнительна ;)

Вот любимое наше ООП как раз и занимается тем, что пытается алгоритмику со структурой данных объединить, а не разделять...

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

Цитата:
Например, результатов действия алгоритма может быть много... Мы идем в магазин за покупками, но всегда ли есть главная покупка в списке? Аналогично в алгоритме могут достигаться несколько равноценных результатов. Как построим орграф?
Честно говоря, не понял... У нас ведь в алгоритме исполнитель всегда один, точка активности одна... А если не одна (параллельные процессы, сети Петри и т.п.), так всё равно для большинства практических целей (включая низкоуровневые кирпичики) приводится к одной (временная последовательность действий, очередь транзакций в кошельке и т.п.). О каких "результатах алгоритма" речь?

Цитата:
Если вернуться к системам, то там есть элементы и связи. Связи (каналы, например) часто могут быть двунаправленными. И здесь могут возникнуть проблемы с построением орграфа.
А, возможно, он там и не нужен, орграф-то? :roll:

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

Цитата:
А почему именно на плоскости? А что будет если, например, обработку исключений вынести на другую плоскость? Получим пространственную модель. Может она будет проще восприниматься...
Ну, хвала Всевышнему! Наконец-то в области обсуждения Дракона это прозвучало!!! :D

Цитата:
Обозначенные минусы относятся не к языку, а к правилам оформления схем...
Дык, а "правила оформления" - это ж и есть язык!

Автор:  alexus [ Среда, 23 Март, 2011 19:28 ]
Заголовок сообщения:  Re: Преобразование графов

Драконограф писал(а):
Да... вот даже если включить в модель взаимодействие человека с [программируемой] машиной... то из этого примера хотя бы видно, что не так просто представить систему... деятельность человека так легко не информатизуешь :)
В мире нет ничего, что нельзя было бы сделать еще более трудным для понимания... Хотя я не уверен в том, что надо к этому стремиться. :)
Несколько лет я, как мог, боролся с теми, кто ходил по предприятиям и... описывал бизнес-процессы. Процесс формализации/отчуждения знаний - это частный случай подобного бизнес-процесса. То, что это трудно, я понимаю... однако, это трудности начала пути. Потом трудностей станет гораздо больше. Поскольку этот путь... в никуда. Чем больше решений удастся описать... тем больше будет тех решений, которые еще не описаны.
Драконограф писал(а):
alexus писал(а):
Издержки... разные бывают... большие и маленькие, например. :) Если применять Дракон именно для записи алгоритмов, то издержки невелики. А если пытаться на нем формализовать поиск решения... то...
... получится попытка "алгоритмизации изобретения"? :)
Да, только это задача не для Дракона.
Драконограф писал(а):
alexus писал(а):
Может, но это ничего не меняет в самом языке. Запись алгоритма помимо самого языка, включает в себя следование определенным правила, традициям и т.п. Вот о правилах, как я понял, здесь и была полемика.
Ну да... кроме языка, есть ещё технология его применения... можно "гнездить" циклы, а можно вывести эквивалентный ЦД; можно разрывать цикл ДЛЯ между ветками, а можно не разрывать (хотя здесь уже сомнительно, что и то, и другое допустимо шампур-методом :wink:); можно делать подстановку "по логике", а можно "по физике"; и т.д.
Под "правилами" я имел ввиду несколько иное. Скажем, Алгол ввел в практику правило использования отступов для вложенных блоков. Здесь говорят о правилах "шампур"-метод, отсутствие пересечений и т.п. Но возводить "правила" в ранг "закона" (обязательного для исполнения)... является ошибкой, IMHO. Должен признаться, что я до сих пор пользуюсь GoTo, там, где мне это кажется оправданным.
Драконограф писал(а):
alexus писал(а):
Для большинства задач - это так, но есть и меньшинство... Например, результатов действия алгоритма может быть много. Можно вырезать из исходного листа материала, например, столешницу... а можно (на обрабатывающем центре) вырезать сразу несколько деталей. Ни одна из полученных, в результате раскроя листа, деталей не может быть "главной". Мы идем в магазин за покупками, но всегда ли есть главная покупка в списке? Аналогично в алгоритме могут достигаться несколько равноценных результатов. Как построим орграф?
Ну, тут как раз сказывается, что алгоритм - это ещё не вся деятельность. Сразу несколько деталей образуют структуру объектов (данных), описываемую отдельно. Если достигаются не сразу несколько результатов, а поодиночке - то при отсутствии очевидного критерия предоставляем выбор человеку или вводим искусственное правило.
Зачем нужны суррогаты?.. Описание объектов - это одно (они и в конструкторской документации, при деталировке, описываются отдельно), а получение результатов - это совсем другое. Конструкторам безразлично, как будут получены детали, главное чтобы они соответствовали документации. А вот планово-экономическому отделу и производственникам - не безразлично. То есть, речь идет скорее о технологии производства и последующем планировании, чем о конструировании.
Драконограф писал(а):
alexus писал(а):
Если вернуться к системам, то там есть элементы и связи. Связи (каналы, например) часто могут быть двунаправленными. И здесь могут возникнуть проблемы с построением орграфа. Но и это еще не все... Часто правила выбора дальнейшего пути решается не с помощью жестко заданного алгоритма, а с помощью набора правил, которые интерпретируются во время исполнения. Орграф? И т.д.
Ну, каналы взаимодействия алгопроцессов вроде реализуемы... и визуализируемы (именно в виде системы графов процессов-элементов деятельности - и графов процессов связи, т.е. обслуживания каналов)... или что-то другое имелось в виду?
А набор правил - он откуда берётся?
Речь о том, что орграф - это частное решение, приложение системы к решению конкретной задачи. Это не совсем то же самое, что проектирование системы.
Драконограф писал(а):
alexus писал(а):
А почему именно на плоскости? А что будет если, например, обработку исключений вынести на другую плоскость? Получим пространственную модель. Может она будет проще восприниматься...
Ну да... как и подстановки... и взаимодействия... и наконец, системы схем по ЕСКД.
Системы документирования (ЕСКД, в частности) морально устарели с появлением систем трехмерного моделирования и конструирования. Производителям тех же печатных плат не нужны чертежи по ЕСКД, им подавай файлы в формате PCAD... Они из этих файлов автоматически получают и фотошаблоны, и программы сверления, и пр., и пр. Чертежи на бумаге... уходят в прошлое.

Автор:  Peter Almazov [ Среда, 23 Март, 2011 19:51 ]
Заголовок сообщения:  Re: Преобразование графов

alexus писал(а):
Несколько лет я, как мог, боролся с теми, кто ходил по предприятиям и... описывал бизнес-процессы.
Вероятно, Вы предлагали что-то взамен описаний бизнес-процессов. Что же именно?

Автор:  alexus [ Среда, 23 Март, 2011 21:41 ]
Заголовок сообщения:  Re: Преобразование графов

Alexey_Donskoy писал(а):
alexus писал(а):
Alexey_Donskoy писал(а):
Задача-максимум: исходя из соображений когнитивной эргономики, построить эффективную методику проектирования программных систем.
Пытался это предложение понять... не получилось.
Ну дык, наивно хочется механизировать искусство! ;)
Это не наивно... Механизация и автоматизация искусства давно происходит. Одно дело руками прорисовывать каждый кадр мультфильма, совсем другое дело компьютерная анимация... То же самое относится ко многим другим видам искусства. Сейчас даже скульпторы... получают сначала 3D-модели... Техническая часть искусства автоматизируется весьма успешно, но порой в ущерб содержательной/творческой части.
Alexey_Donskoy писал(а):
Так или иначе, опыт всё-таки бывает полезен. Следовательно:
- формализовать полученные вместе с опытом знания; оформить их в виде какого-либо словаря (типовых решений, паттернов);
Законы? Методики?
Alexey_Donskoy писал(а):
- автоматизировать (для начала хотя бы механизировать) получение новых знаний о системе (гипотезы, теории, проверка, поиск и т.п.);
Вроде бы за эти утопии уже нобелевские премии давать начали...
Alexey_Donskoy писал(а):
Цитата:
Если применять Дракон именно для записи алгоритмов, то издержки невелики. А если пытаться на нем формализовать поиск решения... то...
Так в этой теме вылезает, что даже для записи алгоритмов издержки неприемлемые ;)
Кроме того, полезность чисто алгоритмической проекции программной системы как-то... сомнительна ;)
Сомнительна? Не факт, что она вообще существует... как цельное и самоценное... длительное время.
Alexey_Donskoy писал(а):
Цитата:
Запись алгоритма помимо самого языка, включает в себя следование определенным правилам, традициям и т.п. Вот о правилах, как я понял, здесь и была полемика.
Дык, а что у нас первично? Задача или правила, по которым её невозможно (неудобно) решать? ;)
С моей точки зрения, задача важнее... но для "ревнителей чистоты"... в общем, однозначного ответа для любого случая жизни у меня нет.
Alexey_Donskoy писал(а):
Цитата:
Например, результатов действия алгоритма может быть много... Мы идем в магазин за покупками, но всегда ли есть главная покупка в списке? Аналогично в алгоритме могут достигаться несколько равноценных результатов. Как построим орграф?
Честно говоря, не понял... У нас ведь в алгоритме исполнитель всегда один, точка активности одна...
Все правильно. Исполнитель один, а результатов много. Это давняя дискуссия. Например, что делать, если из функции надо вернуть более одного значения? Создавать временные структуры? Вводить формальные var параметры? Костыли?..
Alexey_Donskoy писал(а):
А если не одна (параллельные процессы, сети Петри и т.п.), так всё равно для большинства практических целей (включая низкоуровневые кирпичики) приводится к одной (временная последовательность действий, очередь транзакций в кошельке и т.п.). О каких "результатах алгоритма" речь?
Программа, в конечном итоге, это некоторая модель... Модель должна быть адекватной... В жизни бывает так, что сериализация не помогает.
Alexey_Donskoy писал(а):
Цитата:
Если вернуться к системам, то там есть элементы и связи. Связи (каналы, например) часто могут быть двунаправленными. И здесь могут возникнуть проблемы с построением орграфа.
А, возможно, он там и не нужен, орграф-то? :roll:
Именно.
Alexey_Donskoy писал(а):
Цитата:
Но и это еще не все... Часто правила выбора дальнейшего пути решается не с помощью жестко заданного алгоритма, а с помощью набора правил, которые интерпретируются во время исполнения. Орграф?
А то.
Правила - те же данные. В них может быть всё, что угодно. А в исполнителе этих правил всё же есть алгоритм, на так ли? ;)
Нет, не так, если под алгоритмом понимать заданную последовательность действий. Чтобы было понятнее, попробую пояснить. Перед пользователем на экране монитора "висит" форма. Что на этой форме в следующий момент времени нажмет, введет, отметит пользователь? Неизвестно. Является ли форма алгоритмом? В систему из разных источников поступает много самой разной информации, которая внутри системы как-то обрабатывается, и в результате получается некая реакция. Является ли система алгоритмом?
Alexey_Donskoy писал(а):
Цитата:
А почему именно на плоскости? А что будет если, например, обработку исключений вынести на другую плоскость? Получим пространственную модель. Может она будет проще восприниматься...
Ну, хвала Всевышнему! Наконец-то в области обсуждения Дракона это прозвучало!!! :D
Так я Вам еще раньше намекал на 3D очки...
Alexey_Donskoy писал(а):
Цитата:
Обозначенные минусы относятся не к языку, а к правилам оформления схем...
Дык, а "правила оформления" - это ж и есть язык!
Нет, ни в коем случае... Есть язык, а есть правила оформления отступов, правила комментирования, правила использования GoTo и т.д. и т.п. К языку это прямого отношения не имеет.

Автор:  alexus [ Среда, 23 Март, 2011 21:43 ]
Заголовок сообщения:  Re: Преобразование графов

Peter Almazov писал(а):
alexus писал(а):
Несколько лет я, как мог, боролся с теми, кто ходил по предприятиям и... описывал бизнес-процессы.
Вероятно, Вы предлагали что-то взамен описаний бизнес-процессов. Что же именно?
Я предлагал воспринимать предприятие, как систему...

Страница 4 из 5 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/