DRAKON.SU

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

Такая схема достаточна для однозначного понимания, между технологом и программистом (или между заказчиком и исполнителем), алгоритма работы оборудования.

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

Пример нормализованной схемы:

Все побочные «ненормальные» ветви алгоритма описываются или словами и\или небольшими схемами, описывающими реакции на типовые события.

Например для иконы «Проверка предусловий»:

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

Эдуард Владимирович!

1. Вы открыли исключительно важную тему. Спасибо.

2. Вы предложили один из возможных способов борьбы со сложностью (но не единственный).

3. Вы согласовали предложенный способ с другими участниками трудового процесса.
И получили их одобрение. Это большое достижение.

4. Вы описали реальный производственный процесс. Это очень важно.

5. Насколько я понял, Ваше предложение принято производственниками.
И будет включено в состав технической документации. Верно?

6. Вы ввели понятие "нормализованный алгоритм".
Это хорошее понятие и хороший термин.

ВЫВОДЫ

1. Сделан шаг в новую область исследований и получен важный производственный результат.

2. В научно-производственную деятельность введено новое понятие "нормализованный алгоритм".

3. Нормализованный алгоритм достаточен для однозначного понимания сложного производственного процесса в простейшем режиме функционирования, то есть при отсутствии серьезных отказов оборудования . Имеется в виду взаимопонимание между технологом и программистом (или между заказчиком и исполнителем).

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

Не могу согласиться с этим утверждением:

Выход из положения состоит в следующем.
Надо делать не один, а два комплекта документации.

1. Первый комплект -- это Ваш нормализованный алгоритм.

2. Второй комплект -- это полный алгоритм, описывающий все граничные условия, реакции на аварии и прочее.

Сегодня Вы достигли понимания и взаимопонимания на уровне нормализованного алгоритма. И это очень хорошо.
Поработайте с ним, привыкните к нему (вместе с технологом).

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

Это можно и нужно сделать. Причем ничего "дикого" при этом не происходит.

Никакого предложения не было : )

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

Схемы будут включены в состав техдока самым естественным образом, как иллюстрации алгоритма работы оборудования.

При прорисовке алгоритмов были найдены проектные ошибки.

По отрисованному алгоритму было сделано словесное описание (так заказчику привычнее : )


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

Заказчика и технолога интересует только то, какие ошибки будут обрабатываться. Как это будет реализовано – не интересно.

Программисту же достаточно нормализованного алгоритма, списков пред и пост условий, уставок, регистрируемых сообщений и т.п.

Вместо второго комплекта (подробных дракон-схем) - текст программы.

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

В данном случае правильнее говорить об "укрупнённом алгоритме", или даже "принципиальной схеме алгоритма"

А по сути это есть не что иное, как техзадание, которое предполагает затем дальнейшую детализацию.

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

Справедливое замечание.

Я посмотрел русскую и английскую Википедии (нормализация).
Действительно, смысл иной.

Вот (например) цитата из статьи "Нормализация URL":
http://ru.wikipedia.org/?oldid=54560348

Вот еще одна цитата из Википедии:
http://ru.wikipedia.org/?oldid=58312125


Подробнее см. английский раздел Википедии https://en.wikipedia.org/wiki/Normalized

Спасибо за уточнение, Алексей Николаевич

Я согласен, что "нормализованный" не идеальный термин. Но, он хотя бы намекает что алгоритм насажен на некую нормаль : )


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


Да. Но это не обязательно должна быть детализация дракон-схемы дракон-схемами.

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

По всей видимости грани для космоса, и грани для трубопроводов немного отличаются.

Выделено мною.

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


Нормализация схемы алгоритма предназначена для обеспечения демонстрации логики работы устройств при нормальных рабочих условиях.

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

P.S. Производственники не различают алгоритм и схему алгоритма : )

Справедливо.
Всё-таки я больше склонен рассматривать дракон-схему как метаинформацию, а не программу. Потому справедливо.

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

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

Да. Поэтому и достаточно "нормализованной" схемы. И им понятно и программисту.

Кто будет отвечать за адекватность обработки ошибок, если скрывать подробности от заказчика?
Зачастую при такой, казалось бы, сугубо технической, работе могут обнаруживаться такие ляпы в организации процесса и в оборудовании, которые выходят за рамки самостоятельного "решения" программистом... Поэтому говорить об этом надо, показывать надо, согласовывать надо - инструмент должен позволять это. Жклательно не только в краткизх текстовых дополнениях.

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

Согласен. Поэтому и говорил:

К сожалению, картинку приложить не могу : (
Не загружается на форум.

Да. Описано здесь.

Схема приведённая в начале топика прекрасно уложилась на три листа формата А4 с ориентацией альбом.

Вытянутая горизонтальная форма отлично преобразуется в последовательность листов различных форматов.

Например, для условной схемы, можно получить такую последовательность (в зависимости от насыщенности графикой и логических областей):
лист 1 (А4 портрет), лист 2 (А4 альбом), листы 3 и 4 (А3 альбом), лист 5 (А4 портрет).

Какое другое средство Вы можете предложить, которым можно было бы удобно графически изображать алгоритм?

Вот одна из типовых схем:

И эта схема производственникам не нужна.
Им достаточно упоминания: "В случае аварии или ошибки, соответствующее сообщение выводится на экран диспетчера".

1. Спасибо, теперь буду знать.

2. Чтобы отображать удобнее в Драконе? Пока идей не возникло.

Нет. Чтобы без Дракона.

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

У меня ветки размещает автомат. Между самой правой иконой левой ветки и самой левой иконой правой ветки всегда одно и то же расстояние. Поэтому разрез делаю в том месте, которое обеспечивает лучшую укладываемость в заданный формат. Если рисунок не укладывается в формат его можно и поджать на 10-15%.

Схема из начала топика разбита на три листа формата А4 альбом и вставлена в документ Word'a.

А поподробнее, пожалуйста, расскажите - что за автомат?

Самопальная программка.
Для общественности временно недоступная : )