DRAKON.SU

Текущее время: Пятница, 29 Март, 2024 15:14

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




Начать новую тему Ответить на тему  [ Сообщений: 7 ] 
Автор Сообщение
 Заголовок сообщения: Самодостаточность алгоритма
СообщениеДобавлено: Воскресенье, 16 Февраль, 2014 09:41 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Самодостаточность. Длинное слово. Хотя подразумевает полноту.
Отсюда: http://www.b17.ru/article/3934/

Медицинские алгоритмы в книге, не представляются самодостаточными.
Здесь алгоритмы застывшие и представляют собой памятник автору.
Пользователю отведена роль безвольного исполнителя.
Алгоритм в книге сковывает и не позволяет адаптироваться исполнителю к обстоятельствам.

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

Здесь мы имеем регресс в развитии языка Дракон.

======

Пример требований к самодостаточности алгоритма:
http://modis.ispras.ru/seminar/wp-content/uploads/2012/10/Practice_Information.pdf


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Самодостаточность алгоритма
СообщениеДобавлено: Воскресенье, 16 Февраль, 2014 12:56 

Зарегистрирован: Вторник, 13 Декабрь, 2011 15:31
Сообщения: 113
Геннадий Тышов писал(а):
Самодостаточность. Длинное слово. Хотя подразумевает полноту.
Отсюда: http://www.b17.ru/article/3934/

Медицинские алгоритмы в книге, не представляются самодостаточными.
Здесь алгоритмы застывшие и представляют собой памятник автору.
Пользователю отведена роль безвольного исполнителя.
Алгоритм в книге сковывает и не позволяет адаптироваться исполнителю к обстоятельствам.

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

Здесь мы имеем регресс в развитии языка Дракон.

======

Пример требований к самодостаточности алгоритма:
http://modis.ispras.ru/seminar/wp-content/uploads/2012/10/Practice_Information.pdf


Если я Вас правильно понял, неполнота ДРАКОН-а в медицине в бумажном виде, заключается в невозможности изменить бумажный вариант ДРАКОН-схем при необходимости. То есть, дана схема которой нужно четко следовать и бумажный вариант не позволяет изменять последовательность действий в соответствии с изменяемыми обстоятельствами.
В медицине используется большое количество описаний последовательности действий в бумажном виде. В использовании везде компьютера для ДРАКОН-схем нет необходимости. Один из главных плюсов ДРАКОН-а, по сравнению с бумажным вариантом, это однозначность трактования последовательности действий, то есть не допускает отклонения от заданного алгоритма, и это большой плюс ДРАКОН-а. Если автор схемы не предусмотрел какой либо из вариантов или обстоятельств, то это вина автора схемы, а не ДРАКОН-а. В Америке для врачей выпускаются Guidelines, четкие инструкции к действию в тех или иных обстоятельствах. Они очень высокого качества и алгоритм в них не надо менять, нужно только четко следовать алгоритму.
Необходимость изменения схемы бывает в том случае, если в нем изначально не предусмотрели все обстоятельства. То есть нужно тщательнее составлять документацию, чтобы не было необходимости другим его менять. То есть, я думаю нужно составлять документацию так, чтобы его не надо было в будущем каждому врачу адаптировать под себя, она должна подходить без изменения для 95% случаев. В этом случае бумажный вариант ДРАКОН-схем даже предпочтительнее чем компьютерный.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Самодостаточность алгоритма
СообщениеДобавлено: Вторник, 18 Февраль, 2014 17:05 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Если отбросить скрытый контекст призыва применения Дракон-редактора, то по сути можно сказать следующее.

Медикам проще, поскольку они имеют дело с "псевдоалгоритмами" (или с "нормализованным описанием", согласно зтой темы, или по Звереву -- "частично определенными", часть алгоритмов будут "квазиалгоритмами"), т.к. "реальный" алгоритм (по Звереву, например, здесь, Теоретическая и фундаментальная информатика, гл.7 (выдержка определения неполная)):
Зверев Г.Н. писал(а):
...В остальном задание технологического алгоритма и его общие свойства мало отличаются от математического алгоритма: на технологическом языке по строго формализованным правилам задается последовательность шагов процесса с указанием fsr-объектов для каждого этапа процесса, входные и выходные объекты данные, f-объекта, предусловия и постусловия и действия при их нарушении, что и составляет программу процесса, т.е. точную инструкцию на технологическом языке без предположений о “догадливой, изобретательной и умной” системе, которая сама решит, домыслит что делать, если описание алгоритма неполное...

В случае попытки массовой реализации "настоящих" алгоритмов медицина вынуждена будет искать пути обхода хронически нерешаемых вопросов, например:

- как адекватно задавать "параллельные" алгоритмы (причём не только на базе парадигмы "fork-join");

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

- как правильно организовывать "веточные" циклы, и, в целом, как найти нужный градус, под которым смотреть на произвольные веточные переходы, особенно в контексте эргономичного согласования графической и иной формы представления алгоритма;

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

- как мириться с некоторыми артефактами когнитивных правил Дракона, например, затронутых здесь. В википедии, "когнитивная графика", есть пример решения уравнения:
Вложение:
kogn1.PNG
kogn1.PNG [ 15.75 КБ | Просмотров: 7037 ]

В случае вынужденного применения декомпозиции (из-за ликвидации возникающих пересечений), разнесения тесно связанных элементов по разным схемам или веткам, можем получить такую "степень когнитивности":
Вложение:
kogn2.PNG
kogn2.PNG [ 18.93 КБ | Просмотров: 7037 ]

Конечно, пример несколько преувеличен, но тенденция нарушения эргономики имеется. Частично могли бы помочь отсутствующие структурные блоки.

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

Циркуляр Морского Технического Комитета от ноября 29 дня 1910 г.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Самодостаточность алгоритма
СообщениеДобавлено: Пятница, 21 Февраль, 2014 18:56 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
PSV100 писал(а):
- как мириться с некоторыми артефактами когнитивных правил Дракона, например, затронутых здесь.
Не могу согласиться. Уважаемый PSV100 пишет о несуществующей проблеме. Повторяю. Нет такой проблемы.

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

Повторяю, нет никаких артефактов. Это несуществующие артефакты. По моему мнению, это разговор ни о чем.

О чем говорят здесь?
Уважаемый PSV100 полагает, что там говорят о чем-то дельном. У меня другое мнение. Если бы это был дельный разговор, в конце следовало сделать вывод: Ага! — с помощью теории графов мы обнаружили в ДРАКОНе ужасную, чудовищную, роковую ошибку.

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

Но ведь этого не произошло... Даже шило на мыло не поменяли.

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

Но чем?
Тем, что он позволил ГЛУБЖЕ понять природу той ранее неведомой области, которая называется дракон.

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

PSV100 писал(а):
В википедии, "когнитивная графика", есть пример решения уравнения:
Этот пример не имеет НИКАКОГО отношения в ДРАКОНу. Ни малейшего. В огороде бузина, а в Киеве дядька.

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

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

Со временем будут появляться все более совершенные инструменты... Надо подождать, пока наступит эта эпоха.

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

=======================

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Самодостаточность алгоритма
СообщениеДобавлено: Среда, 26 Февраль, 2014 17:31 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Даниелович,

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

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

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

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

В отношение блоков необходимо дать два важных замечания:

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

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Самодостаточность алгоритма
СообщениеДобавлено: Четверг, 27 Февраль, 2014 07:50 
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Самодостаточность алгоритма
СообщениеДобавлено: Понедельник, 14 Апрель, 2014 12:36 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
http://www.rg.ru/2014/04/03/solncev.html#

Цитата:
Российскую космонавтику в последние годы преследовали неудачи. А как удалось добиться, что двигатели РД-180 работают в составе ракет-носителей "Atlas" без замечаний?

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

Так и в ИС Дракон все документирование алгоритма производится в электронной форме.

Этим ИС Дракон отличается от бумажного варианта языка Дракон, реализуемого уважаемым Владимиром Даниеловичем Паронджановым, нет у него электронного документирования алгоритмов вне НПЦАП.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 7 ] 

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


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

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


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

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