Ну, как я понял, вы оба о разных материалах сайта. Сначала ведь обсуждали "П без П", а потом перешли к "Э без Э"... и к нему-то и относится оценка В.Д... Там, действительно, можно предъявить некоторые претензии, даже не имея допуска к первоисточникам...
Например:
1. Это утверждение:
...
Ну и третий вариант, когда без разницы, использовался «Дракон» или нет. Это когда в НПИЦАП им. Пилюгина практикуют не только «программирование без программистов», но и «электронику без электронщиков».
Похоже, что последнее наиболее вероятно.
Их неправильно установили на «Протон»
- вызывает вопрос: "А на каком предприятии установили?". Вроде как ракету окончательно собирают как раз в НПО Хруничева (где-то в репортажах после аварии утверждалось)? значит, и датчики "по месту" ставит не НПЦ АП? Тогда к чему связка с вакансиями у автора статьи?
2. Теперь это:
... И вполне резонный вопрос: применяются ли Дракон-схемы при сборке, подключении и тестировании тех злополучных датчиков? Варианты тут могут быть такими:
Нет, Дракон-схемы не применялись. НПИЦАП им. Пилюгина не доверяет разработке собственных сотрудников
- здесь автор, похоже, смешивает две возможности применения ДРАКОНа как нотации для алгоритмических процессов в части потока управления:
* при разработке кода для управляющих машин - как всем известно, здесь он применяется в составе среды ГРАФИТ-ФЛОКС (в своей части общего решения);
* при производстве системы управления на базе этих машин и далее - ракеты как законченного продукта - и вот тут что-то не припомню, чтобы В.Д. утверждал о записи маршрутов техпроцессов производства на ДРАКОНе...
Тогда какая же к этому языку претензия? Он что, обязан быть везде в НПЦ АП внедрён?
Кстати, и В.Д. говорил, что в Центре и для разработок ПО применяются разные среды (с существенно разными, возможно, подходами)... И из открытого дайджеста корпоративного журнала
здесь это можно понять...
Да, использованная в описанной здесь работе система RunaWFE тоже применяется (в одном из филиалов НПЦ)... и между прочим, насколько я знаком с её описаниями, как раз штука весьма интересная... отчасти подходящая к тому, о чем говорил Усов, обсуждая тут другое предложение по применению ДРАКОНа...
И из этого совсем не должно следовать, что в НПЦ АП не доверяют своим разработкам...
Другое дело - что это всё можно понимать и как закономерную реакцию на позиционирование ДРАКОНа, так сказать, его "контекст продвижения"... В частности:
1. Да, пусть предприятия разные. Но важен подход к делу. И Илья
выше справедливо обратил внимание на одну из возможностей... Ну а Алексей вслед за этим - на другую... И тут давайте вспомним, что в годы войны качественно работали ведь не за зарплату "на уровне рынка труда"... и делали тем не менее вооружение, технику и много чего... В чём дело?
А обратимся к такой схеме. Не замечаете, как оргсистема связана со внешней средой (метасистемой)? Вот и я не замечаю... 
или чего-то упустил? А какова роль реального работника? И если такой подход применять, не будет ли он сам по себе "демотиватором" (и может даже при приличных зарплатах)?..
Откуда это? А вот
отсюда. И так, оказывается, можно определять применимость ДРАКОНа...
2. А почему бы, действительно, не применить ДРАКОН для представления техпроцессов? Но для ответа нужно будет снова к сказанному Усовым вернуться... и начать с теории деятельности, из которой будут следовать её модели... а дальше уже формировать выразительные средства для представления этих моделей...
И тут можно вернуться к первой статье.
Сначала к некоторым, всё-таки, думаю, некорректностям автора:
... Но есть ли в нём что-то новое, принципально отличающее его от блок схем? Таковым является такие правила маршрутизации алгоритма, которые исключают пересечение этих маршрутов. В традиционных «текстовых» языках программирования это равносильно исключению из программ операторора «goto». Вот и вся новизна «Дракона».
- во-первых, полной равносильности нет, как можно понять по результатам Ермакова-Жигуненко, в частности. Во-вторых, от блок-схем ДРАКОН отличается не только этим (уже говорил).
Ну и теперь о некоторых вещах, также требующих раскрытия с разных сторон
1. О теории и её реализации:
...
Если бы существовал «Дракон», созданный В.Паронждановым. Но его не существует! Т.е. он где-то есть, на неких мифических для большинства людей компьютерах «Бисер» (хотелось бы фото в студию! Хоть «Бисера», хоть «Дракона» на «Бисере»). Но на самом деле его нет, потому что этот «Дракон» с «Бисером» никто не может купить.
...
- с одной стороны, автору можно бросить упрёк в том, что он смешивает реализацию "от создателя" со сторонними.
Но с другой, претензии автора можно понимать в виде такой формулы:
ДРАКОН = ГРАФИТ - ФЛОКСкоторая лишь конкретизирует формулу, топиковую для этой ветки.
Иначе говоря - в НПЦ АП реализовано комплексное представление алгоритмических процессов для исполнения "Бисером". Как раз не противоречащее "базису трёх абстракций" Кауфмана... Это
одна причина, почему там подход с графами только для потока управления работает...
А известные "открытые" реализации до такого же комплекса представление восполняют... У Тышова по-своему, у Митькина по-своему...
2. А теперь - какие проблемы возникают из-за игнорирования этого:
...
В. Паронджанов: все идентификаторы глобальные
Ему возражают: Глобальные идентификаторы — это крайне ужасно. Про параллелизм можно забыть сразу. А современная тенденция в программировании, и задача, которую не могут пока достаточно эффективно решить — это как максимально делать алгоритмы параллельными. В случае с глобальными идентификаторами хотя бы состояний — без шансов. Как мне сварить параллельно N каш? Да и даже если без параллелизма — тоже будут весьма интересные эффекты при многократном вызове какого либо алгоритма из разных мест.
Далее:...Еще ужаснее. Нет, на современных языках тоже можно считать, что идентификаторов десятки тысяч. Тоже группировка по неймспейсам, пакетам, модулям. Но по крайней мере ограничения доступа и видимости есть, в результате эти десятки тысяч превращаются просто в сотни, а то и меньше. От глобальных переменных начали избавляться наверно в 50-х годах. Сейчас 2012.
...
- это к тому же, что vdimas говорил...
Ну, более подробно можно у Потёмкина найти... в Главе 5, в частности...
Более точно - подход, предлагаемый не только ДРАКОНом, а любой формализацией "от потока управления" можно определить как:
НЕ важен(деятельность,результат) И важен(деятельность,процесс)- и тут это не в ироническом смысле, как у Жванецкого, а в чисто формальном - потому и записано в ПРОЛОГоподобной форме.
А именно - уделяется внимание разработке порядков действий в отвлечении от результатов действий.
Тогда опять же почему для "Бисера" это нормально кодировать не мешает?
Другая причина, думаю, в том, как формализуют задачи управления.
Исторически сложилось, что моделью СУ ракет служит... ну, грубо говоря, "командоаппарат", который ставят в стиральные машины, скажем. Раньше он был на электромеханической основе (первые ракетные СУ, по-моему, тоже), теперь чисто электронный. Но суть одна - задача решается по циклограмме. Где всё заранее расписано. Такое решение получается способом "как сделать, чтобы..." на основе достаточного знания предметики (ну там, баллистики своё посчитали, прочнисты своё, кибернетики-автоматики своё). Кстати, это прослеживается и в языке (та же реализация только отправки сообщения параллельному процессу).
Короче, разработчики должны заранее определить "последовательный алгоритм" управления. Для этого, действительно, сосредоточение на потоках управления д.б. оправданно. При условии не сильно типизированных данных (когда наборы значений величин ограничены, смысл их хорошо определён, ясны зависимости между значениями, смысл их комбинаций). Так оно в данной сфере и есть. Что при условии разработки способом "как сделать, чтобы..." и даёт преимущества.
Это можно принять за условия "программирования без программистов"... и возможной ниши языка в различных предметных областях...
Есть другой способ получить решение - "что будет, если...". Тут надо при разработке много экспериментировать, в т.ч. вычислительно. А если заложить этот способ в разрабатываемую систему, то ей надо передать формальную модель, "что бывает". И там надо будет для этого реализовать... правильно, опять то, о чём Усов говорил - орграф деятельности, включая системное управление процессами. Тут "командоаппаратом" не обойдёшься... нужна теория деятельности...
Мы по-прежнему говорим о СУ ракеты. Есть такая теория для этой области? Есть - взять хотя бы исчисление УА РВ Калентьева-Тюгашева, реализованное в ГРАФКОНТе.
А если без теории? Ну, тогда известный подход к формализации - запустим кучу процессов, пусть они как-то нагружают процессор[ы] и периферию... а если "программа выполнит недопустимую операцию, то она будет закрыта"... По тем данным, что опубликованы в связи с "Фобос-Грунтом", там этим путём и пошли... результаты известны... 
Но основательна ли претензия автора статьи, что здесь ДРАКОН виноват?.. Ведь опять это не НПЦ АП... и нет данных, что там этим языком пользовались... А вот если для "Бисера" будем так кодировать - рискуем получить то же самое... что с применением ДРАКОНа, что без...
А что тут важно в части процессов?
Можно указать на это:
... не удивляет качество ПО в нашей космической отрасли, которое не реагирует на перелив полутора тонн топлива. А вот 29 октября 1988 года программное обеспечение отменило запуск «Бурана» (он был перенесён на 15 ноября): оно среагировало на нештатную ситуацию. Это ПО было написано на PL/I, без «Дракона»; ...
- дело опять же не в языке, а в подходе к формализации задачи. Ну не подумали о всех возможных случаях:
По поводу отказов программ.
Чем дальше, тем все более отчетливо у меня проявляется осознание того, что возможные отказы и реакцию на них надо ПРОЕКТИРОВАТЬ.
Важно, что реакцию на отказы необходимо проектировать.
Проектирование покажет возможные варианты реакции на отказы.
...
- может, и тут "демотиватор" сработал?.. кто знает...
А также это:
В. Паронджанова, «Как улучшить работу ума», глава 1, «Полная декомпозиция программ»:
Цитата:
...Проектирование программ до последнего момента может вестись независимо от языка и лишь на последнем этапе осуществляется переход к нужному языку...
Из этого утверждения следует, что алгоритм решения задачи является независимым от языка программирования, применяемого внутри иконок «Дракона».
...
- тут в общем-то о том, что раскрытие решения происходит постепенно. И язык представления будет разным для разной степени формализации. В частности, гибридный язык ДРАКОН-Х, если его применить для записи алгоритмических процедур, должен иметь сменный (причём закономерно) Х-синтаксис.
И ещё это (формат мой):
...
Умение разбить программу на части — это основа основ профессии программиста. Эти части могут быть функциями, классами, модулями. Программисту зачастую не важно, что там у них внутри. Главное, что они решают ровно ту задачу, которую должны решать. Поставленная задача кажется сложной? Её надо разбить на части! Получившиеся куски опять сложны? Значит надо разбивать ещё! В итоге мы получим множество мелких несложных задач, которые решаются легко. Рисовать же блок-схемы для несложных задач — лишняя трата времени. В итоге «Дракон» не нужен.
Существует легенда, что в фирме IBM в эпоху текстовых дисплеев (80 x 25 символов) существовало негласное правило, что функция должна целиком помещаться на экран. Возможно ли такое? Конечно, если научиться сводить одну большую проблему к нескольким маленьким.
- и об этом Илья
тоже говорил...
Это к чему? А к тому, что важным становится представление структур декомпозиции, отношений между её единицами (здесь - процедурами).
Так что, хотя автор статей не во всём корректен, позиции igor это не затрагивает... с каковой и я согласен... Сначала определиться с целями, способами решения, а потом выбирать языки... Для представления и алгоритмов, и структур данных... и исполнителей...
Вход
FAQ
Поиск
