Владимир Паронджанов писал(а):
...
Эти 12 тезисов сформулировал я на основании статьи Сергея Ефанова.
Я старался очень точно передать основной смысл статьи. Но я, конечно, мог допустить неточности.
Если кто-нибудь обнаружит неточности, просьба указать на них и подсказать, что именно надо исправить.
Я обязательно исправлю.
Ну, здесь вижу смысл не столько исправлять (для своей ситуации Сергей, считаю, прав) - сколько уточнить реалистичный контекст справедливости тех или иных утверждений. Значит, так...
Цитата:
Тезис 1. Написание программы на языке ДРАКОН распадается на два этапа:
— разработка алгоритма,
— собственно программирование.
Ну, это так не только для конкретного языка - следует, скажем, из определения формализации/моделирования как двуединоого процесса... Только первый этап не сводится к разработке только алгоритма - имея в виду снова целостность результата. Уже говорилось об этом:
... когда алгоритмизация выполнена, программировать тоже ещё рано. В программных системах большая часть решений сегодня ложится на архитектуру - структуру компонентнов, их связей, структуру информационного обмена и т.п.
И только потом - программирование.
Вероятно, наиболее очевидный ответ на это "почему" - потому, что тем самым вполне реализуется сказанное здесь (курсив мой):
...
Однако речь именно об алгоритмике – о программировании, очищенном от всего случайного.
...
Здесь прежде всего мы видим, что алгоритмика понимается не как определение одного лишь потока управления процесса, описываемого программно строго, т.е. для исполнителя-"машины". Но как определение процесса решения в целом.
...
Почему у Сергея проще? Очевидный ответ - в силу простоты решаемых задач. Если смотреть глубже - дело также м.б. в том, что программы не рассматриваются как системы в смысле Усова.
Цитата:
...
Тезис 2. Алгоритм проектируют (рисуют) в графической форме, то есть составляют из графических элементов. Это гораздо легче. Не требуется такое сосредоточение, как обычно.
Первое. Легче - тому, кому естественнее/привычнее не с текстом работать. Надо думать, это случай Сергея.
Второе. Про то, какое сосредоточение требуется, уже говорил А. Донской - всё зависит от реализации транзакций редактирования. Можно понять, что конкретно Сергея Ты-решение устраивает. Если и не очень - то ему м.б. настолько легче формализовать на осноове маршрутного графа программы, что это перевешивает неудобства. У Kori, как можно видеть из
этого поста, не перевешивает - он хотя и внедрил в практику, но фактически настаивает на доработке того, что "спустя полгода ещё вызывает активный протест" - и готов подключиться сам (это к проприетарному-то изделию
)...
Цитата:
...
Тезис 3. Так как нарисованный алгоритм очень понятен — работу можно спокойно прервать в любой момент. Потом легко вернуться к её продолжению.
Тезис 4. Когда весь алгоритм нарисован и «отлизан», переходим к программированию.
Тезис 5. При написании текста программы алгоритм уже не надо держать в голове, как это делается при обычном программировании.
Строго говоря, это не достоинство языка шампур-"слепышей" - а конкретной реализации на его базе. Следующей принципу разделения аспектов "управленческого", "алгоритмического", программного - по сути, по степени формальности содержания вершины. Что предполагает стандарт разметки вершин "слепыша" записями для каждого аспекта и использования каждого типа записи при редактировании и трансляции.
Естественно, это не критика - сам подход, считаю, плодотворен. Единственное что - принятое выделение аспектов не единственно возможное. Кроме того, в реальном применении оно как бы сочетает в себе и детализацию - а в общем случае это другое измерение содержания предмета описания, чем степень формальности. И в сложных проектах м.б. оправданно дать возможность независимо детализировать и устрожать - но надо думать, как.
Пока же детализация возможна как последовательное усложнение схемы - была одна вершина, стал подграф. Ну и текст где-то разносится (что предполагает активный копипаст), где-то перерабатывается.
Цитата:
...
Тезис 7. В чём теперь заключается программирование? В том, что для каждой иконы нужно написать код, который выполнит то, что написано на этой иконе. Как правило это 1 строчка.
Как раз достижение такого соответствия в общем случае и требует той самой детализации схемы.
Однако при простых и типовых проектах опять же можно дублировать и редактировать схемы, а также копипастить куски...
Только придётся, например, перебивать ручками имена величин, не такие же в новом проекте... с риском ошибиться... и схемная запись этого не упростит... особенно когда часть текста скрыта в примечааниях...
Цитата:
...
На высоких уровнях иерархии проекта — это может быть вызов одной функции, или одного метода класса (заметим, что все функции и классы тоже нарисованы на ДРАКОНЕ). На нижнем уровне — это может быть изменение одного бита.
Заметим, что функции (в части потока управления) на ДРАКОНе действительно "нарисованы" (структура схемная)... а вот классы на ДРАКОНе прежде всего "написаны" (определены текстом в отдельных вершинах) - без представления их структуры так же ясно, как и структур управления...
Вот у Мейера классы в ЭС-реализации Эйффеля действительно нарисованы...
Цитата:
...
Тезис 8. В чём сложность программирования? В сложных взаимосвязях между частями программы.
"И этот тезис не вызывает у меня возражений"
- и не только у меня:
1) Я думаю, что эффект от графового представления есть только тогда, когда оно делает явным что-то, что оказывается неявным в тексте. Граф управления для реактивных программ проясняет структуру поведения программы - все возможные маршруты, "грамматику событий". Для вычислительных программ в структуре поведения прояснять особо нечего. Зато там может быть полезным прояснять структуру зависимостей данных при вычислениях. Так что.... можно на эту тему поразмышлять.
2) Говорить "контроль за соблюдением структурности программы остается за исполнителем (программистом)" (утв. П. Приклонского - В.Ж.) я думаю, некорретктно. Очень мутное высказывание.
3) Возможности выражения не-вложенно-блочных структур в программе в текстовом представлении, конечно, ограничены. И тут, опять же, сфера применения - оно бывает очень нужно в "поведенческих" алгоритмах (потому что сильно их проясняет), но совершенно не актуально в обычных.
- но тут же указывается и на условия применимости.
Опять же можно видеть, что т.к. Сергей разрабатывает управляющие программы - то запись импер-части в форме шампур-силуэта ему должна дать кое-что существенное для восприятия проекта. А т.к. проекты сравнительно просты - то и насчёт контроля он фактически согласен с Приклонским (проекты которого, возможно, бывают и посложнее - т.к. там присутствует управляющая проограмма - но она типовая и всё равно объём ограничен адресацией МК).
Цитата:
...
Тезис 9. Сложные взаимосвязи между частями программы полностью показаны в дракон-схеме алгоритма.
Тезис 10. Поэтому на этапе программирования икон об этих сложностях думать уже не надо. (Совсем. Вообще. Никак. Не надо, и всё тут!)
Опять же это потому, что объёмы/архитектура программ у Сергея позволяют управлять сложностью теми средствами, какие имелись в Ты-реализации (на момент написания его поста - в 2011 году - в настоящее время, как мы знаем, Г.Н. уже думает о новых возможностях).
Цитата:
...
Тезис 11. Всё, что нужно — аккуратно запрограммировать ОДНУ икону. Только ОДНУ! Когда будем программировать другую — про предыдущую уже можно не вспоминать.
А что значит - программировать только текущую икону? Это значит - что для каждой иконы требования к программной части (аспекту) уже продуманы. И тут вот какая штука. Если их не записали в проект (ну или на бумагу начерно, скажем) - то, получается, всё равно держат в голове (противоречие с Тезисом 5). А если записали - то, получается, дали столь исчерпывающую спецификацию (скажем, в алгоритмическом приложении), что осталось только переложить её на синтаксис прогязыка разработки...
Цитата:
...
Тезис 12. Программирование на этом этапе превратилось в чисто техническую процедуру. Несложную.
А здесь уже вопрос серьёзный возникает, если попытаться перенести на общий случай механически...
Потому что для простых программ с этим можно согласиться - сочинитель имеет целостную модель решения и реализует её.
А для сложных, где есть, как говорит Илья, "неочевидное из текста программы"?.. Тут придётся вспомнить кое-что из цитированного Владимиром Даниеловичем
здесь:
Рассмотрим еще один инцидент с Therac-25, которому суждено было стать последним. Он произошел в Yakima Valley Memorial Hospital (штат Вашингтон) в январе 1987 г. Пациенту было предписано сначало проделать два рентгеновских снимка с дозой в 4 и 3 рад соответственно, а затем произвести в фотонном режиме облучение в 86 рад. Все это и было выполнено, однако, как потом было установлено, пациент получил переоблучение фотонной дозой до 10000 рад. (Установлено было "потом", а не сразу - оператор, сделав снимки, забыл вынуть рентгеновскую пленку из-под пациента, из-за чего у него на консоли горели все те же 7 рад; однако, и правильная индикация уже выданной дозы была бы здесь как - в буквальном смысле слова - мертвому припарки).
Что же произошло? Выявленная в итоге расследования проблема выходит далеко за пределы частного случая еще одной программистской ошибки. В данном случае не сработала блокировка, реализованная программно позволившая прибору действовать (испускать поток фотонов) при ошибочной установке параметров. Ситуация возникла в момент, когда введенные параметры уже верифицированы подпрограммой Datent и монитор Treat в соответствии со значением переменной Tphase = 3 вызвал подпрограмму Set Up Test.
Во время установки и подгонки параметров подпрограмма Set Up Test вызывается несколько сотен раз - пока все параметры не будут установлены и верифицированы, о чем эта подпрограмма судит по нулевому значению разделяемой переменной F$mal. Если же значение ненулевое - цикл повторяется. F$mal, в свою очередь, устанавливается подпрограммой Chkcol (Check Collimator) из критической задачи Housekeeper, проверяющей, все ли с коллиматором нормально; а вызывает Chkcol другая подпрограмма задачи Housekeeper под названием Lmtchk (analog-to-digital limit checking), и вызов этот происходит, только если значение разделяемой переменной Class3 ненулевое. А ненулевым его делает как раз сама Set Up Test, которая (пока F$mal=0) каждый раз выполняет над Class3 операцию инкремента.
Эта переменная - однобайтовая, следовательно каждый 256-й проход заставляет ее сбрасываться в ноль. А ведь этот ноль - свидетельство, что все параметры, наконец, установлены. Если повезет, что именно в этот момент оператор нажмет клавишу "set" для запуска установки коллиматора в надлежащую позицию (а он это может сделать в любой момент, так как уверен, что система позволит коллиматору начать позиционироваться, только если все параметры заданы и верифицированы), то основываясь на случайно возникшем нулевом значении Class3, подпрограмма Lmtchk уже не станет вызывать Chkcol, а значит установить ненулевое значение F$mal будет некому. Иными словами, в ситуации, когда параметры не установлены должным образом (в данном конкретном случае "челюсти" коллиматора были еще раскрыты слишком широко), программная блокировка не сработала: Set Test Up установила Tphase = 2, что позволило монитору Treat прекратить цикл вызова Set Up Test, а инициализировать подпрограмму Set Up Done, по существу запускающую процесс излучения, который и потек бурным потоком, а не узеньким ручейком, как предполагалось.
Коррекция этой ошибки также выполняется просто - вместо выполнения инкремента переменной Class3 следует просто присваивать фиксированное ненулевое значение. Вот от каких, казалось бы, мелких и чисто технических ляпсусов программиста может зависеть жизнь человека!
Вот как раз случай того самого "неявного". Для анализа ситуации разработчику как минимум нужно было иметь "схему подключений по вызовам" для процедур - то, что у меня ДМ-схема. Но, с учётом сказанного далее:
Можно долго перечислять проявившиеся в этом проекте проблемы, например, касающиеся принципов построения человеко-машинного интерфейса (выдаваемые оператору сообщения о критических с точки зрения безопасности ситуациях выглядели как рутинные; при этом не включалась блокировка, препятствующая дальнейшей деятельности оператора и т.д.). Все это является отражением того факта, что - как позволяет утверждать ставшая доступной информация о проектных и технологических особенностях разработки - квалификация коллектива разработчиков и организация их работы не позволяли реализовать столь сложный и тонкий проект с обеспечением безопасности функционирования, необходимой в данной предметной области.
Что же до системной "глобальной особенности", то к ней можно отнести принципиальную переусложненность построения мультизадачной управляющей системы. С чисто программистской точки зрения можно отметить, что для реализации тонкой синхронизации параллельных процессов был выбран механизм разделения переменных, требующий очень внимательной проработки (это именно та область, где необходимо выполнять формальное доказательство правильности алгоритма, благо соответствующие методы разработаны и могут считаться рутинными - для тех, кто ими владеет); получилось же так, что потенциально опасные в плане возникновения "race conditions" операции типа "set" и "test" не были сделаны "неделимыми" (indivisible), что и привело к наложению друг на друга их "критических секций" и - соответственно - к печальным последствиям.
- и этого недостаточно - нужна схема потоков работ... вроде той, что обсуждается сейчас в
этой теме ...
А главное - где же здесь простота кодирования? Да, сказано: "Коррекция этой ошибки также выполняется просто - вместо выполнения инкремента переменной Class3 следует просто присваивать фиксированное ненулевое значение." - и что? К этому так легко прийти?.. тем более не "проявив неявное" за пределами отдельно взятых алгоритмов?..
Так что сформулированное для относительно простых случаев - нельзя переносить на общий. Иначе и получим то самое:
...
Торжествует "good enough software", когда критерии качества не имеют столь высокого приоритета, как удобство пользования, простота освоения и дешевизна - и все это в сочетании с избыточной функциональностью, пожирающей компьютерные ресурсы, и отсутствием у производителя стимула выбрасывать на рынок действительно отлаженный продукт. Весьма взрывчатая смесь. В обозримом будущем мы можем оказаться свидетелями катастрофических ситуаций, в которые попадут пользователи массовых продуктов, и, похоже, что только это способно сдвинуть ситуацию с ее нынешнего печального положения.
К тому же, функционирующий в соответствии с законами "массовой культуры" рынок обрастает глашатаями того же розлива, обслуживающими тех, кто заказывает музыку. Как и положено в шоу-бизнесе, музыка играет громко и агрессивно. К сожалению, именно в России, по сравнению с западными странами, нарушен баланс между "популярной" компьютерной периодикой и той, что ориентирована на программистов-профессионалов, которым не так просто найти материалы, полезные для совершенствования. В результате размываются критерии, и энтузиасты (которых можно, в зависимости от точки зрения отнести и к "хакерам", и к "чайникам"), освоившие какой-нибудь новомодный инструмент "за 21 день", считают себя готовыми к серьезной работе. А если найдутся менеджеры того же пошиба, которые им эту работу действительно доверят?
Небезынтересно в этом контексте упомянуть, что та же Microsoft пытается проникнуть на рынок "ответственных" систем; во всяком случае, она не прочь получить подряд на поставку большой партии Window NT для федеральных организаций, чья работа завязана на "обеспечение национальной безопасности". А для этого надо сертифицировать эту ОС на соответсвие одному из базовых уровней безопасности компьютерных систем С2 (в соответствии с критериями, определенными в "Оранжевой книге" Агенства Национальной Безопасности США). Хотелось бы, конечно, надеяться, что осваивая сегмент рынка с принципиально иными требованиями к продуктам, производители массового ПО поднимут планку качества и в своей традиционной вотчине. А ну как окажется наоборот?
...
- о чём писал и Голубицкий:
...
...взятки далего не гладки и если фриварная карта GPS сбросит машину пользователя с обрыва, то при достаточном врении - если конечно получится после падения выжить! - пользователь вытрясет из фриварного гоблина всю душу ничуть не хуже, чем из гоблина коммерциализированного. Если уж не прикрывают даже ... дискламеры, которыми коммерческие гоблины любят обкладывать свои продукты, то что говорить о битниковской дурашливости "по баблу ко мне не в кассу".
Тут интересное "смешение жанров", думаю, произошло. Совершенно верно ставится вопрос о том, что полнота ответственности создателя чего-либо зависит не от того, чего он требует за свой труд, а от того, "критическая" ли предметка применения его создания. Однако тут же вместе с упоминанием о проблемах коммерческого ПО утверждается, что только бесплатное "... культивирует тотальную безответственность разработчика перед потребителем". А то "дисклаймеры" не для того изобретались, чтобы ни за что не отвечать...
А есть ещё стратегия вначале открытой разработки с последующим закрыванием... примеры чему, думается, участники могут привести...
...
- и если не следовать инженерной дисциплине разработки - то нельзя рассчитывать избежать подобных последствий...
И ещё раз - дедуктивная верификация является лишь одним из возможных направлений. И она как раз требует жёсткой структурности - иначе практическое осуществление становится проблематичным. Об этом говорил Лавров в Гл. 2
своей книги. Так что тут пойдёт только вывод вложением из структурных атомов.
Тогда как проверка моделей по сути своей метод имитационный - и потому в принципе может допускать отступления от структурности. Здесь уже возможны и операции с лианами.
В общем, крупные системы запрограммировать "по одной вершине" проблематично - во всяком случае, для этого надо иметь не только полноценное представление всех составляющих её содержания, но и ещё вспомогательные представления.
Сие, впрочем, из материальной инженерии известно хорошо - можно посмотреть хотя бы в Гл. 5 у
Каминского...
Вход
FAQ
Поиск
1. Проблема программных ошибок (проблема корректности программ) — фундаментальная проблема. Лучшие умы бились